MARE NOSTRUM. Del 2 Kravspesifikasjon

Transkript

1 MARE NOSTRUM Del 2

2 Forord Kravenes hensikt og utforming Kravene i kravspesifikasjonen utformet slik at de skal imøtekomme oppdragsgivers krav, ønsker og spesifikasjoner på best mulig måte. Hensikten med kravspesifikasjonen for prosjektet, er å sørge for at både gruppen og oppdragsgiver har en felles forståelse for hva som faktisk skal med i produktet. Dette skal igjen sørge for at oppdragsgiver faktisk får et produkt som på en hensiktsmessig måte inneholder all funksjonalitet de ønsker seg. Flere av kravene er formulert av oss, på bakgrunn av vurdering gjort etter å ha hørt hva oppdragsgiver ønsker. Dette gjelder alle de ikke-funksjonelle kravene og en del av de funksjonelle. Alle kravene er utformet med tanke på at de skal være minste funksjonalitet som er nødvendig for at produktet skal fungere slik oppdragsgiver ønsker. ens målgruppe ens målgruppe slik vi har tenkt, er hovedsakelig oppdragsgiveren og gruppen. Den er imidlertid også designet slik at en utenforstående også lett skal kunne se nøyaktig hva som er minimums funksjonalitet for det endelige produktet. Vi har også designet selve kravene med tanke på at det skal kreve så lite bakgrunnskunnskap som mulig, noe som er i tråd med de prinsipielle retningslinjene for hvordan kravene skal utformes. 2

3 Innholdsfortegnelse 1 Lederveiledning Krav Funksjonelle krav: Kjernefunksjonalitet, høyest prioritet: Tilleggsfunksjonalitet(lavere prioritet): Ikke-funksjonelle krav Use case Sekvensscenarioer Kjernefunksjonalitet Scenario 1 (Schedule-parser): Scenario 2 (AIS-parser) Tilleggsfunksjonalitet

4 1 Lederveiledning Kravene nedenfor er delt opp i to deler etter hvilke type krav de er: funksjonelle krav og ikkefunksjonelle krav. De er utformet etter standard retningslinjer for hvordan kravene skal defineres. De funksjonelle kravene tar for seg alle kravene som går direkte på funksjonaliteten til programmet, eller med andre ord hva programmet skal kunne gjøre. De ikke-funksjonelle kravene tar for seg krav for hvordan programmet og dets omgivelser(som dokumentasjon) skal være oppbygd. Videre har vi også definert de funksjonelle kravene i to kategorier: kjernefunksjonalitet og tilleggsfunksjonalitet. Kjernefunksjonalitetene er ment å være de viktigste kravene, og er det absolutte minimum som må være med for at prosjektet skal kunne karakteriseres som vellykket. Tilleggsfunksjonaliteten tar for seg krav som bygger på kjernefunksjonaliteten. Disse kravene har verdi for oppdragsgiver, men anses for å være mye mindre viktig enn kravene i under kjernefunksjonaliteten. I kapittel tre har vi med de brukerscenariene som vi har brukt til å utforme programmet. Dette ligger under overskriften Sekvensscenarier. Disse er utformet og tilpasset etter hva oppdragsgiver sier de ønsker, og i forhold til hvordan vi ser for oss at programmet skal virke i funksjonell forstand. Disse scenarioene spesifiserer hvordan vi har sett for oss at kravene skal implementeres eller innføres, og er ment å fungere som en erstatning for use-case beskrivelser. Som nevnt i prosessrapporten(5.2) har vi valgt å kalle disse scenarier istedenfor use-case beskrivelser, fordi vi egentlig ikke har noen nevneverdige interaksjoner mellom system og bruker/aktør. Vi har også i tillegg valgt å lage et enkelt use-case diagram som beskriver interaksjonen mellom systemet og aktørene. Det er som tidligere nevnt veldig begrenset med interaksjon, så vi har valgt å bare enkelt kommentere use-casediagrammet istedenfor å lage fulle use-casebeskrivelser. 4

5 2 Krav 2.1 Funksjonelle krav: Kjernefunksjonalitet, høyest prioritet: 1. Systemet skal kunne ta imot informasjon om et skip og dets posisjon fra en av Xeneta sine leverandører. Informasjonen skal mottas gjennom en UDP-server 2. Systemet skal kunne lagre informasjon om skip i en database. Systemet skal kunne lagre posisjonsdata om skipenes reiser mens de er underveis. Systemet skal kunne lagre informasjon om hvert skips navn i databasen. Systemet skal kunne lagre informasjon om hvert skips dimensjoner i database. Systemet skal kunne lagre hvert skips destinasjon i database. Systemet må så sant det er mulig kunne lagre tidspunktet for når dataene er opprettet. Systemet skal kunne filtrere bort irrelevant informasjon, blant annet om skip som ikke er fraktskip. 3. Systemet skal sørge for at informasjon om skipene og informasjon om reiserutene er forenlige. Dataene skal kunne kobles sammen. 4. Systemet skal kunne gjenkjenne en mail med schedule blant innkommende epost. 5. Systemet skal kunne lagre eller om nødvendig oppdatere schedules for hvert skip som mottas via mail. Systemet skal kunne se og avgjøre om oppdatering av schedule er forsvarlig/riktig. 6. Systemet må kunne avgjøre i hvilket land eller verdensdel destinasjonen ligger Tilleggsfunksjonalitet(lavere prioritet): 1. Systemet skal kunne finne ut når et skip er kommet til en havn (destinasjon) med minst mulige feil. 2. Systemet skal finne ut når et skip drar (avgang) 3. Systemet skal kunne beregne hvor lang tid et skip bruker mellom havner 5

6 4. Systemet skal kunne beregne forsinkelser ved å sammenligne det reelle/aktuelle tidsbruken på reisen mot det som står i skipets reiseplan (schedule). 5. Systemet skal kunne holde rede på hvilke skip hvert registrert rederi eier. 6. Systemet skal finne gjennomsnittlig punktlighet til rederier. 7. Kundene til Xeneta skal kunne hente ut en rangert list over rederienes punktlighet. 8. Systemet skal kunne vise statistikk over punktligheten til rederier gjennom alle tider. 9. Systemet skal kunne vise statistikk over den gjennomsnittlige punktligheten til et rederi for en måned og et år i form av diagrammer/grafer. Lavest prioritet. 2.2 Ikke-funksjonelle krav Alle de ikke-funksjonelle kravene er designet av gruppen for å sette en målbarhet for hvordan vi ønsker at systemet skal kunne yte når det står ferdig. De er ikke blitt utformet i samarbeid med oppdragsgiver, men er utformet med tanke på hvilke kvalitetsstandarder vi mener er nødvendig for at produktet skal kunne møte oppdragsgivers funksjonelle krav og behov. 1 Pålitelighet -Systemet skal designes med tanken på at det skal ha minst mulig feil som fører til at systemet krasjer. Antall timer nedetid på grunn av systemet sin programvaren skal være på maksimalt 2 timer per måned. 2 Effektivitet -Systemet skal være designet med hensyn på effektivitet. Alle komponentene i systemet skal til enhver tid bruke minst 30 % av total CPU-tid på systemet det kjører på. Systemet skal kunne lagre informasjonen slik at det går raskt å finne den fram igjen. 3 Kvalitet -Systemet skal være designet med tanke på kvalitet Minst 95 % av alle mulige feil skal være kartlagt før systemet taes i bruk Minst 90 % av alle mulige feil skal være fikset før systemet taes i bruk Maximum 10 % av systemets komponenter skal være avhengig av kode fra eksisterende systemer. 6

7 4 Utvidbarhet -Systemets kapasitet skal enkelt kunne utvides etter behov Systemets mest ressurskrevende(hardwarekrevende) komponenter skal designes med tanke på at det skal være enkelt å legge til støtte for parallellisering. -Systemet skal være designet slik at koden og systemet lett kan endres. Systemet skal være delt inn slik at komponentene skal kunne kjøres og testes uavhengig av hverandre(objekt orientert). 5 Robusthet - Systemet skal være slik at det kan håndtere ufornuftig eller feilaktig input Systemet skal kunne håndtere all skadelig, uleselig eller ugyldig inputdata på en hensiktsmessig måte, slik at programmet ikke krasjer. 6 Testbarhet -Systemet skal være slik at det er enkelt å teste Hver komponent i systemet skal være slik at det på en hensiktsmessig måte, skal være mulig å teste dem for seg selv med fornuftig inputdata. Løsningen skal gi fornuftige feilmeldinger(exeptions) ved 100 % av kritiske steder i programmet under en test 7 Dokumentasjon - Systemet skal være dokumentert på en hensiktsmessig måte. Dokumentasjonen skal være så presis som overhodet mulig Dokumentasjonen skal ikke inneholde ufornuftige repetisjoner Dokumentasjonen skal være saklig og mest mulig objektiv Dokumentasjonen skal bygges opp etter UML-standard, men tilpasses der det er behov. Systemet skal inneholde kommentarer i kode ved alle viktige funksjoner eller moduler. Alle modulene og klassene skal inneholde docstrings. Dette er en type dokumentasjon som er ment å beskrive hva en metode/klasse eller modul gjør. 7

8 3 Use case Figur Use-casediagram som beskriver hele systemet. Legg merke til at det ikke er spesifisert hvem aktør er. Dette er fordi oppdragsgiver ikke er helt sikker på hvem som skal bruke systemet, og faktisk se denne informasjonen. Vi har også valgt å ikke navngi leverandørene, fordi det er usikkert hvem som faktisk kommer til å ende opp med å bli leverandør av dataene. Diagrammet i figur 3.1 over viser hvordan de forskjellige aktørene samhandler med systemet. Vi vil gjerne påpeke at vi ikke har brukt use-casediagrammene under prosjektet fordi use-casene har vært svært få og ukompliserte. Det bør nevnes at for at brukeren skal kunne oppnå den interaksjonen med systemet på en hensiktsmessig måte som beskrevet her, bør alle kravene i kravspesifikasjonen være oppfylt. 8

9 4 Sekvensscenarioer Fordi vi av mangel på aktører for systemet og ikke får noe ut av å sette opp relasjoner mellom bruker og system, har vi valgt å bruke scenarier. Istedenfor fokus på aktører i disse beskrivelsene har vi heller fokus på hva systemet gjør og utførelsessekvensene. Vi har bygd opp komponentene i systemet etter hver av disse scenariene. 4.1 Kjernefunksjonalitet Scenario 1 (Schedule-parser): Systemet lagrer alle rutetabellene (schedules) i databasen ved å parse schedule-filen som blir sendt fra ShipmentLink ( Informasjon om alle reisene lagres i en historikk-collection og skipsreisene for den førstkommende uken lagres i databasen. Den sistnevnte listen skal fungere som en cache slik at det blir enklere og mer effektivt å lage informasjon om rederienes punktlighet. Prebetingelse: E-postmeldingen med rutetabellfilene (schedule-filen) fra ShipmentLink. Postbetingelse: Skipsrutetabellfilen er parset og rutetabellene, både for historikkdelen og reisene for neste uke, er lagret i databasen. Collections: schedules.historic og schedules.current. Hovedscenario: 1. Åpner schedule-filen (i txt-format) for lesing. 2. Leser filen til den kommer til en handelsrutegruppe. 3. Lager en liste over havnene. 4. Finner havnekoden til havnen. Repeter steg 3-4 for hver havn. 5. Leser inn en linje og registrerer skipsnavn og reiseinformasjon for dette skipet, Repeter steg 5 til all reiseinformasjon for denne gruppen er registrert. Repeter steg 2-5 til det ikke finnes flere reiseplaner. 6. Registrere alle rutetabeller i en historikk-collection. 7. Registrerer alle reisene for den førstkommende uken i en annen collection som skal som fungere som en cache Scenario 2 (AIS-parser) Systemet mottar og parser kodet(encodede) AIS-data, dekoder dem og filtrer irrelevant data og sender dem til meldingskøen(mq/celery) for innlegging i database. 9

10 Prebetingelse: Dataene som serveren må være i AIVM format. En liste (collection) av skip som skal reise den førskommende uken er lagret i en egen collection. Nettverksportene som brukes må være ledige. Collections: ship.static og ship.voyagedata. Hovedscenario: 1. Mottar rådata (AIS-data) gjennom UDP-server og legger dem i en array 2. Repeter punkt 1 hvis arrayen ikke er fullt. 3. Velger en datalinje fra arrayen. 4. Sjekker at data er gyldig og kan dekodes. 5. Dekoder data. 6. Legger inn ferdig dekodet data i database dersom det er data for et tankskip eller frakteskip. 7. Gå til punkt 3 dersom det fremdeles er flere data fra arrayet som ikke er dekodet/gjennomgått Utvidelser og unntak: 1a. Dersom arrayet er fullt, legg dataet i et annet array 2a. Dersom data på siste plass i arrayet er ufullstendig (består av 2 linjer, men kun en linje finnes) utvid arrayet med 1 plass og gå punkt 1a. 4a. Dersom data er ugyldig/uleselig, skriv ut eventuelt feilmelding og gå til punkt 3. 7a. hvis alle data i arrayet er dekodet/gjennomgått gå til punkt Tilleggsfunksjonalitet Scenario 1 (Rederistatistikkoppdaterer): Systemet lagrer faktiske avgangs- og ankomsttid til skip og oppdaterer punktlighetsstatistikker for rederier. Prebetingelse: Listen over skip som skal reise denne uken eller er på vei til en havn finnes i databasen (Scenario 1 i avsnitt 4.1.1). Skipsposisjoner og statisk informasjon om skip er lagret i databasen. Lister over skip rederier eier finnes i databasen. Postbetingelse: Informasjon om når et skip begynte å reise fra eller ankom en havn er lagret i databasen. Antall forventede reisedager og antall timers avvik fra ETA-en for avsluttede reise er lagret i databasen. Punktlighetsstatistikker for rederier er oppdatert. Collections: voyages.traveling og voyages.arrivals Hovedscenario: 1. Trekker ut reiseplanene for denne uken (se scenario 1 i avsnitt 4.1.1)til et skip fra listen som ligger i databasen. 2. Finner MMSI-nummeret til skipet. 3. Trekker ut siste posisjon til skipet. 4. Registrerer når skipet begynte å reise fra havnen. 10

11 5. Lagrer informasjon om faktisk avgangstid til skipet i egen collection. Lagrer både estimert og faktisk ankomsttid samt annet relevant informasjon (se prebetingelse). Reper steg 1-5 til alle skipene er behandlet. 6. Sletter reiseplaner for reiser der skipet er på vei fra uke-collection (se scenario 1 i avsnitt 4.1.1). 7. Trekker ut dokumentet for et skip som er på vei ( voyages.traveling ). 8. Trekker ut siste posisjon til skipet. 9. Registrerer når skipet er ankommet havn. 10. Lagrer informasjon om faktisk ankomst/avgangstid til skipet i egen collection (lagrer både estimert og faktisk ankomsttid samt andre tilhørende data). 11. Oppdaterer rederipunktlighetsstatistikk for det rederiet som eier skipet. Repeter steg 7-11 til alle skipene er behandlet. 10. Sletter dokumentene i voyages.traveling for skip som er ankommet bestemmelsesstedet. Utvidelser og unntak: 3a. Skipsposisjonen eksisterer ikke eller er for gammelt (Eldre enn tiden mellom hver gang denne jobben kjøres, altså 1 time.). 1. Hopper over til neste skip i listen (steg 1). 4a. Skipet er ikke i bevegelse: 1. Hopper over til neste skip i listen (steg 1) 8a. Skipsposisjonen eksisterer ikke eller er for gammelt (Eldre enn tiden mellom hver gang denne jobben kjøres, altså 1 time.). 1. Hopper over til neste skip i listen (steg 7). 9a. Skipet har ikke ankommet havn. 1. Hopper over til neste skip i listen (steg 7). Scenario 2 (Webside): Bruker får opp en web-side som inneholder punktlighetsstatistikker for alle registrerte rederier. Prebetingelse: Det finnes rederier som det er registrert skipsreiser og statistikker på. Postbetingelse: Rederiene er listet på web-siden og er rangert etter punktlighet. Web-siden inneholder også grafer som viser punktlighetsstatisk over tid for de siste 18 månedene. Hovedscenario: 1. Systemet henter totalstatistikk for alle rederier. 2. Systemet henter forsinkelsesprosentdata og kumulativ forsinkelsesprosentdata for alle rederier. 3. Systemet henter avviksprosentdata og kumulativ avviksprosentdata for alle rederier. 4. Systemet fyller inn tabellen over rederipunktlighetsstatistikker med data fra steg HTML-siden blir generert og sendt til brukeren. 6. Grafene med data hentet i steg 2 og 3 blir generert. 7. Resten av siden blir generert. 11