Programvareutvikling kan være en spennende prosess med kreativ problemløsning, design og engineering. Men under de skinnende appene og polerte nettsidene ligger de mindre sexy, men så viktige stillasene som gjør gode programvareutfall mulig: dokumentasjon.

Dokumentasjon sikrer team og individuelle interessenter er på samme side om et produkt eller program mål, omfang, begrensninger og funksjonelle krav.Dessverre kan prosessen med å opprette og dokumentere disse kravene være kjedelig, forvirrende og rotete.

dokumenter Med Programvarekrav kan raskt bli lange, uhåndterlige, teksttunge dokumenter, noe som gjør dem spesielt sårbare for feil, inkonsekvenser og feiltolkninger. På grunn av dette kan skriving og bruk av disse dokumentene være tidkrevende og føre til kostbare (og unødvendige) designfeil.

Så hva skal produktledere, programvareteam og bedriftsledere gjøre?

selv Om det ikke finnes noen regel for alle størrelser for programvareutviklingsmetoder, finnes det måter å redusere feil, spare tid og drive effektive resultater.

nedenfor går vi gjennom mål og fordeler av programvare krav dokumenter og noen beste praksis som vil hjelpe deg spikre prosessen fra start til slutt.

hva er dokumenter for programvarekrav?

et kravdokument for programvare (også kalt kravspesifikasjoner for programvare) er et dokument eller et sett med dokumentasjon som skisserer funksjonene og den tiltenkte oppførselen til et program.MED andre ord beskriver programvarekravsdokumentet (SRD) virksomheten eller organisasjonens forståelse av sluttbrukerens (typisk kundens) behov og avhengigheter, samt eventuelle begrensninger på systemet.

hva er inkludert i EN SRD?

MENS SRD fungerer som en blåkopi for å administrere omfanget av et prosjekt, definerer DET til slutt bare funksjonelle og ikke-funksjonelle krav til et system. Dokumentet skisserer ikke design-eller teknologiløsninger. Disse beslutningene fattes senere av utviklerne.

EN velskrevet SRD bør:

• Bryte problemet i håndterbare deler.
• Tjener som referanse for testing og validering.
• Informer designspesifikasjonene(DVS. SRD må inneholde tilstrekkelig informasjon om kravene til programvaren for å gi en effektiv design).
• Gi tilbakemelding til klienten (sluttbruker).

SRD demonstrerer til klienten at organisasjonen forstår problemet de ønsker å bli løst og hvordan å løse disse problemene gjennom programvareløsninger. Fordi klienter er ofte direkte interessenter, er det spesielt viktig å utarbeide dokumentasjonen klart i lekmann vilkår (unngå teknisk sjargong).

igjen, hvordan du skriver SRD vil avhenge av tilnærming og metodikk teamet eller organisasjonen abonnerer på. IEEE standards organization anbefaler imidlertid at Typiske Srd-Er skal dekke følgende emner:

• Grensesnitt
• Funksjonelle Evner
• Ytelsesnivåer
• Datastrukturer/Elementer
• Sikkerhet
• Sikkerhet/Personvern
• Kvalitet
• Begrensninger og Begrensninger

hvis hvert av disse emnene er tydelig adressert Og skissert i dokumentasjonen, vil du FÅ ET mer komplett bilde Av Informasjonen Som Er Nødvendig for å utvikle søknaden din.

slik spiker du programvarekravsdokumentet

uansett hvilken tilnærming du tar til dokumentasjon, følg disse beste praksisene for å skape en effektiv OG effektiv SRD.

Hold det organisert

navnet på spillet er organisasjon. Før du begynner å dokumentere, må du huske å starte med en organisasjonsstrategi for alle dokumenter, inkludert hvor dokumentene dine er lagret, hvordan du sikrer konsistens og hvordan bidragsytere og samarbeidspartnere enkelt kan holde dokumenter oppdatert. For å være effektiv, bør en programvare krav dokumentet være organisert og klart. Mange organisasjoner er avhengige av husmaler for å opprettholde konsistens på tvers av prosjekter. Maler er en fin måte å spare tid på (bare fyll ut de forhåndsorganiserte delene) og vær konsekvent i dokumentasjonsprosessen.

dokumentmaler forsterker imidlertid ofte problemet med langvarige, teksttunge krav. For å unngå å bli overbelastet i sider med tekst, bør du vurdere å supplere dokumentasjonsprosessen med visuelle data.

Sørg for at kravene er fullstendige

for at et krav skal være «komplett», bør det inneholde all nødvendig informasjon for å implementere kravet. Dette betyr at når designere og utviklere går for å bygge ut funksjonen, blir de ikke igjen med antagelser eller gjetninger om kravet.

la oss for eksempel si at du utvikler en nettside. Et av kravene som er skissert er hva som skal skje i tilfelle en feil. Et ufullstendig krav kan si noe som «i tilfelle feil, bør systemet gå ut jevnt.»

I dette tilfellet er» jevnt » ikke definert og overlates til tolkning. Denne tvetydigheten kan føre til feiltolkning av de ønskede resultatene (og mer arbeid for å gå tilbake og fikse det).

for å unngå dette, skriv et komplett krav som definerer hvordan en vellykket funksjon ser ut:

«ved feil må systemet vise en feilside med følgende melding:

Uh-oh! Det ser ut som noe gikk galt. Vennligst prøv igjen om noen minutter. Hvis problemet vedvarer, kontakt Vårt Supportteam på [email protected]. »

ved å definere et komplett krav, er det mindre tvetydighet og et klart utfall for utviklingsteamet å jobbe med.

Gjør krav testbare

dette er en ganske allestedsnærværende standard, men altfor ofte organisasjoner ikke klarer å skrive krav som fullt ut oppfyller denne regelen.

Kravene må være verifiserbare. Ellers er det ingen objektiv måte å vite om kravet ble implementert tilfredsstillende.

For hvert krav du skriver, må du kontrollere at det er validert gjennom en eller flere av følgende måter:

• Inspeksjon
• Demonstrasjon
• Walk-through
• Testing

krav på høyt nivå gjennomgår ofte inspeksjon eller brukertesting, slik at De vanligvis er avhengige av mer generelle spesifikasjoner. Men lavere nivå krav som gjennomgår programvare testing vil trolig trenge mer detaljerte spesifikasjoner.

Bruk implementeringsnøytrale funksjonskrav

SOM vi nevnte tidligere, ER EN SRD ikke et designdokument. Det definerer ikke og bør ikke definere hvordan funksjonelle krav må implementeres fra et designsynspunkt.

derfor bør alle funksjonelle krav være implementeringsnøytrale. Med andre ord, krav bør angi hva systemet skal gjøre, men ikke hvordan det skal gjøre det.

det er flere fordeler med implementeringsnøytrale krav, inkludert:

• En mer effektiv designprosess
• Modifiserbare krav som ikke er avhengig av en bestemt implementeringsdesign
• Mindre konflikt mellom krav som følge av motstridende implementeringsdetaljer

eventuelle begrensninger på implementering bør reserveres for de ikke-funksjonelle kravene til systemet.

Evaluer dokumentasjon med interessenter

når alle programvarekravene er dokumentert, må alle relevante interessenter evaluere den endelige dokumentasjonen før utviklingen starter.Interessenter bør inkludere designere og utviklere, testere som vil validere kravene, ingeniører, sluttbrukerrepresentanter og klienten.

ved å få alle interessenter til å gjennomgå og godkjenne dokumentasjonen før de begynner å utvikle seg, forbedrer du tilfredsheten på tvers av teamene og øker sannsynligheten for at kravene vil møte deres behov.

Hjelp programvareutviklere og teamene deres å holde seg på samme side med flytskjemaer som effektivt og elegant kartlegger spesifikasjonene for programvarekrav. Se etter en diagramløsning som kan hjelpe deg:

• Organiser kravene dine i et flytskjema for å holde komponentene dine tydelige, avhengighetene dine klare og interessentene tydelige.
• Bruk swimlanes for å visuelt beskrive hvilke lag som er ansvarlige for hvert krav.
• raskt endre krav eller andre data som prosjektet trenger utvikle seg.
• Link data (inkludert tilleggsdokumenter) for å støtte og informere ditt pågående prosjekt.
• Del dokumentasjonen (og eventuelle endringer) umiddelbart med relevante interessenter.

Dokumentasjon trenger ikke å være et ork. Med Lucidchart kan du enkelt dokumentere prosesser, brukerhistorier og programvarekrav på ett sted. Ved å visuelt definere dine kravspesifikasjoner, vil du og teamet ditt kunne finne og handle raskt og samtidig redusere mulighetene for feil, inkonsekvenser og feiltolkninger.

begynn å dokumentere

Få innsyn i dine eksisterende tekniske systemer med Lucidchart i dag.

Lær hvordan