9.November, 2018 · 4 min lese
i samsvar med hver av detaljene og kravene som er definert i programvareprosjektet som utføres, er de store målene Som En Utvikler må oppnå for å møte forventningene til sine kunder og gjøre prosjektet vellykket. Hvordan kan en utvikler lage systemer som oppfyller alle kravene til sine kunder? Det kan være et av dine første spørsmål.saken er at det er mange faktorer som påvirker suksessen til programvareprosjektet. Men i dag skal vi snakke om et viktig dokument som bør utarbeides i de tidlige stadiene av produktutviklingen. Vi snakker om Kravspesifikasjonsdokumentet For Programvare.
PROGRAMVAREKRAV Spesifikasjon (SRS) er utvilsomt regnet som en av de mest kritiske faser av programvare/produktutvikling. SRS-Programvarekrav Spesifikasjon-en spesiell programvaredokumentasjon som inneholder informasjon om hvordan systemet selv skal oppføre seg, hvilke funksjoner det skal utføre, hvilken belastning den skal tåle, og så videre. Produktkravsdokument er stedet der egenskapene og kravene til programvare, produkt, program eller sett med programmer er beskrevet. Disse elementene er uttrykt i naturlig språk, uten hensyn eller tekniske termer.
- Du kan få et nøyaktig estimat av kostnader, risiko og tidskostnader.
- klienten vil kunne danne sin visjon om prosjektet tydeligere.
- kunden og entreprenøren vil ha samme ide om produktet.
- Det vil bidra til å identifisere det optimale settet av funksjoner.
- det tjener som grunnlag for dannelsen av annen teknisk dokumentasjon.
- utviklingsprosessen vil bli optimalisert og tid minimert.
- det blir ingen duplisering av oppgaver.
- lar deg strukturere problemer for å løse dem enklere og raskere.
det har blitt veldig tydelig at en dårlig spesifikasjon av programvarekrav kan føre til mislykkede prosjekter. Derfor blir denne disiplinen stadig viktigere.
hvordan lage et produktkrav dokument?
følgende mal følger retningslinjene fastsatt i ieee 830-standarden, i henhold til hvilke kravspesifikasjonen for programvare skal inneholde beskrivelsen av applikasjonens funksjonalitet, forholdet til eksterne systemer og ikke-funksjonelle krav som ytelse, tilgjengelighet, responstid og vedlikehold mellom andre.
malen for å klargjøre krav til programvare er delt inn i følgende deler:
formål:
du bør legge til et navn eller tittel på et produkt som er angitt i papiret, inkludert versjonsnummer eller utgivelse. Beskriv hvilke elementer eller deler av omfanget av programvaren som er inkludert i dokumentet, fastslå om det dekker hele programvaren, bare en del av den, delsystem eller undergruppe av prosesser.
omfanget av programvaren:
det bør være en kort beskrivelse av omfanget av programvaren som blir spesifisert, inkludert formål eller generelle mål, fordeler gitt til virksomheten og organisasjon området, forholdet mellom programvare mål med bedriftens mål og forretningsstrategier. Du kan henvise til andre dokumenter.
her kan du inkludere andre trykte dokumenter, elektroniske dokumenter eller elektroniske adresser som utfyller produktkravsdokumentet.
produktfunksjoner:
hver funksjon kan bestå av ett eller flere funksjonelle programvarekrav. Bare en nummerert liste over de viktigste funksjonene bør inkluderes.
Brukeregenskaper:
i denne delen bør du beskrive at brukere som skal bruke dette produktet. Klassifiser dem på grunnlag av regelmessig bruk, en gruppe funksjoner som brukes, sikkerhetsrettigheter, erfaringsnivå og andre parametere.
Driftsmiljø:
miljøet der systemet, programvaren, modulen eller funksjonsgruppen skal utvikles, bør også inkluderes. Nevn slike aspekter som versjoner av operativsystemet, maskinvareplattformen og andre systemer eller elementer som den må sameksistere med.
Funksjonelle krav:
Oppgi funksjonene, og for hver av dem, merk de funksjonelle kravene. De kan også dokumenteres i en krav sporbarhet matrise.
Forretningsregler:
Denne delen inneholder de prinsippene som må gjelde for hele settet av programvarespesifikasjoner som er oppført i dokumentet. For eksempel forklare hvilke individer som kan spille en bestemt rolle under visse omstendigheter.
Krav Til Eksterne grensesnitt:
dette kapittelet omfatter grensesnitt med maskinvaren, grensesnitt med andre systemer og kommunikasjonsgrensesnitt, egenskaper og attributter for brukergrensesnitt (GUI).
Ikke-funksjonelle krav:
de angir kriterier for å evaluere driften av en informasjonsteknologi tjeneste, i motsetning til de funksjonelle kravene som definerer spesifikk atferd.
Andre krav:
Inkluderer de kravene som ikke er forklart i noen annen del av produktkravsdokumentet. Det kan være database krav, internasjonalisering, juridiske og gjenbruk mål av programvarekomponenter.
Ordliste:
Legg til en beskrivelse av vilkår og akronymer som er nødvendige for å forstå det opprettede dokumentet.
tips for å skrive sps
- beskriv alt veldig kort og tydelig så mye som mulig.
- ikke ta med ting som kanskje ikke må dokumenteres.
- Skriv Uten vage beskrivelser. En person som leser SRS må forstå nøyaktig hva som er skrevet, og ikke noe annet.
- Visualiser. Bruk FOR eksempel dfd-diagrammer (dataflytdiagrammer). Spesifikasjonen kan ikke være komplett hvis vi ikke vet hva som er ved inngangen til den beskrevne programvaren, og hva som er på utgangen. Alt må inkluderes.
Nå har du alle de viktigste elementene som vil hjelpe Deg å lage Programvare Krav Spesifikasjon. Gå for det!