Gruppenavn. Prosjektnavn Kravdokument For Navn på systemet. Versjon <1.0>

Transkript

1 Gruppenavn Prosjektnavn Kravdokument For Navn på systemet Versjon <1.0>

2 Revisjonshistorie Dato Versjon Beskrivelse av endring Forfatter <dd/mmm/yy> <x.x> <beskrivelse> <navn>

3 Innhold 1. Innledning Dokumentets hensikt Avgrensning Definisjoner og forkortelser Referanser Oversikt over innholdet 4 2. Bakgrunn og oversikt Use-case UML-diagram Forutsetninger og avhengigheter 4 3. Detaljerte krav Use-Case beskrivelser Tilleggsspesifikasjon av krav (Supplementary Specification) 5 4. System sekvensdiagram 5 5. Problem domenemodell 5 6. Tillegginformasjon 5

4 1. Innledning Kravdokument Innledningen til dokumentet skal fortelle leseren hva som er hensikten med dokumentet og hva det inneholder. Han skal også forstå i hvilken forbindelse dette dokumentet er skrevet. Innledningen har følgende underpunkter: 1.1 Dokumentets hensikt Hensikten med dette dokumentet er å gi en logisk beskrivelse av det systemet som skal utvikles. Beskrivelsen skal vise hvilke krav brukerne har til systemet. 1.2 Avgrensning Her finner vi en kortfattet beskrivelse av det aktuelle prosjektet slik at det går klart frem hva dette dokumentet dekker. Hvis dokumentet dekker deler av det fremtidige systemet må det gå klart frem. Eventuelle relasjoner til andre systemer eller delsystemer beskrives. 1.3 Definisjoner og forkortelser Alle begreper og forkortelser må defineres når dette er nødvendig for å forstå innholdet i dokumentet. NB! Husk at dette dokumentet skal leses også av brukerne. Vurder å veldikeholde en ordbok i prosjektet. Dette bør da være et eget dokument som refereres her. 1.4 Referanser Alle dokumenter som refereres andre steder i dette dokumentet skal listes opp her. 1.5 Oversikt over innholdet Her forteller vi leserne hva dette dokumentet inneholder og hvordan det er organisert (hva han finner hvor) 2. Bakgrunn og oversikt Her skal vi beskrive alt som er viktig å vite om bakgrunnen for de kravene som dokumenteres i resten av dokumentet. Vi tar med informasjon om brukerne, om rammebetingelser, om forutsetninger og om avhengigheter. Hensikten er å gjøre det lettere å forstå brukerkravene og sette dem inn i den rette konteksten. Hensikten er også å kunne vurdere brukerkravene på nytt om noe av det som beskrives her endrer seg. 2.1 Use Case UML-diagram Her finner vi det komplette Use Case UML-diagrammet for den delen av systemet som dokumentet dekker. Det vil si alle aktører og alle Use Case og relasjonene mellom aktører og Use Case i diagramform. Det kan være ett eller flere diagrammer, avhengig av hva vi finner hensiktsmessig. NB! Use Case beskrivelsen kommer senere i dokumentet. Husk å ta med en innledning som forklarer hva dette diagrammet viser og relasjonene til andre deler i dokumentet. Vurder om aktører og Use Case må defineres eller forklares. 2.2 Forutsetninger og avhengigheter Her beskriver vi så nøyaktig som mulig de forutsetningene som beskrivelsene i dette dokumentet bygger på. Videre beskriver vi så nøyaktig som mulig hvilke avhengigheter vi har, for eksempel til andre systemer. 3. Detaljerte krav Her skal vi beskrive alle brukerkravene til systemet. Beskrivelsene skal være så detaljerte at vi på bakgrunn av dem kan utforme (designe) systemet. Beskrivelsene skal også senere være utgangspunkt for testing, slik at vi gjennom testing kan vurdere om systemet oppfyller brukernes krav. NB! Dette står ikke i motsetning til at bade beskrivelsen av brukerkravene og design av systemet skjer inkrementelt, i iterasjoner. Beskrivelsen består av følgende deler:

5 3.1 Use Case beskrivelser For hvert av Use Case-ene i oversiktsdiagrammet skal det utformes en Use Case beskrivelse. De ikkefunksjonelle kravene som naturlig hører til et Use Case beskrives her. Husk å ta med en kort innledning som forklarer hva beskrivelsene gjelder og beskriv relasjonene mellom disse beskrivelsene og andre deler av dokumentet. 3.2 Tilleggsspesifikasjon av krav (Supplementary Specification) Alle krav som ikke beskrives gjennom et Use Case skal beskrives her. Det vil være alle ikke-funksjonelle krav som gjelder hele systemet. Det kan også være funksjonelle krav som ikke naturlig beskrives som Use Case. Hvis det er mange slike krav kan det være naturlig å ha tilleggsspesifikasjonen som et eget dokument, det refereres da her. 4. Systemsekvensdiagram For hvert Use Case som er med i kapittel 3.1, skal vi her ha med et system sekvensdiagram som viser hvilke meldinger som går mellom systemet og aktørene for å realisere Use Case. Det kan være naturlig å ha et sekvensdiagram for hver alternativ flyt. Husk å ta med en kort innledning som forklarer hva diagrammene beskriver og forklar relasjonene mellom disse diagrammene og andre deler av dokumentet (Use Case beskrivelsene). 4.1 Kontrakter Vurder behovet for å skrive kontrakter (detaljerte beskrivelser av meldingene kan være nødvendig for de meldingene som er kompliserte). 5. Problemdomenemodell Her utformer vi en domenemodell som viser de sentrale objektene i problemområdet og relasjonene mellom dem. Husk å ta med en kort innledning som forklarer hva modellen beskriver og forklar relasjonene mellom modellen og andre deler av dokumentet. 6. Tilleggsinformasjon Evt. annen informasjon som vi ønsker å ta med for å øke forståeligheten og tilgjengeligheten av det som er dokumentert.