Hvordan skrive en programvarekrav dokument
Før arbeidet starter for design og utvikling av programvare, skaper en teknisk forfatter en programvare kravspesifikasjon (SRS). Dette dokumentet setter kundens forventninger og sørger for at en organisasjon og dens klient forstår kravene. Den inneholder presise beskrivelser av funksjoner og funksjonalitet at søknaden må gi. SRS er kilden for alle prosjektrelaterte dokumenter, for eksempel charter, prosjektplan og design spesifikasjoner. Dens mål er blant annet å gi tilbakemelding til kunder, identifisere programvareutvikling komponenter og gir testing og validering strategier. Det tilbyr ikke virksomhet eller teknologiske løsninger.
bruksanvisning
bruksanvisning
1 Skriv en innledning som forklarer hensikten med dokumentet. For eksempel viser at dokumentet definerer de funksjonelle og ikke-funksjonelle krav av programvaren. Funksjonelle egenskaper av programvaren oppstår i programmet, og ikke-funksjonelle egenskaper forholde seg til hva som skjer utenfor programmet.
2 Identifisere den tiltenkte publikum på SRS. For eksempel kan publikum inkluderer senior og avdelingsledelsen.
3 Indikerer omfanget. For eksempel: "Dette omfatter utskifting av eksisterende regnskapssystem med en ny web-basert program." Vanligvis må du angi hva som er ute av omfanget for å eliminere misforståelser. For eksempel: "Non-regnskap programmer berørt av utskifting av eksisterende programvare ikke vil bli erstattet."
4 Gi perspektiv. For eksempel viser hva programmet vil gi, for eksempel Internett-baserte dataregistrering og rapportering av regnskapstransaksjoner. Gi funksjonelle og ikke-funksjonelle beskrivelser av programvaren. For eksempel: "Regnskaps transaksjoner behandles interaktivt" (funksjonell); og "Eksterne brukere har tilgang til programmet" (ikke-fungerende).
5 Indikerer avhengigheter og forutsetninger knyttet til programvaren, for eksempel søknad vil ha en fem års livssyklus. Indikerer avhengige applikasjoner integrert med eksisterende programvare. Disse berørte programmer kan kreve modifikasjoner for å fortsette å fungere som den skal.
6 Identifisere hvordan brukere vil få tilgang til programmet. For eksempel, vil brukerne bruke en nettleser til grensesnitt med søknaden. Indikerer den nødvendige maskinvare, programvare og kommunikasjon for å gi tilgang.
7 Indikerer en liste over viktige funksjoner, som for eksempel sikkerhet som gjør at bare autoriserte brukere å få tilgang til programmet. Hvis programvaren inneholder hjelp, inkludere dette i listen over funksjoner. Men kanskje mindre funksjoner overflaten etter at prosjektet kommer i gang. Dette kan føre til budsjettoverskridelser.
8 Definer ikke-data spesifikasjoner, for eksempel brukertilgang ytelse, krav til kvalitetssikring, forretningsregler, krav til sikkerhet og brukerdokumentasjon. For eksempel angi at all brukerdokumentasjon er tilgjengelig på bedriftens filserver.
9 Indikere krav som faller utenfor spesifikasjons kategorier store. For eksempel angi at eksisterende regnskapsprogram vil ha sine data flyttet inn i ny programvare database.
10 Definer tvetydige vilkår knyttet til søknaden i en ordliste. For eksempel, "bruker" kan bety de som er internt og eksternt til selskapet.
11 Inkluder vedlegg som bidrar til å klargjøre aspekter av programvare, for eksempel dataflytdiagrammer. Ettersom prosjektet kommer i gang, inkludere flere vedlegg som nødvendig.