kan være en spændende proces med kreativ problemløsning, design og teknik. Men under de skinnende apps og polerede sider ligger det mindre kønne, men alligevel så vigtige stillads, der muliggør gode resultater: dokumentation.dokumentation sikrer, at teams og individuelle interessenter er på samme side med hensyn til et produkts eller programs mål, omfang, begrænsninger og funktionelle krav.

desværre kan processen med at oprette og dokumentere disse krav være kedelig, forvirrende og rodet.dokumenter kan hurtigt blive lange, uhåndterlige, teksttunge dokumenter, hvilket gør dem særligt sårbare over for fejl, uoverensstemmelser og fejlfortolkninger. På grund af dette kan skrivning og brug af disse dokumenter være tidskrævende og føre til dyre (og undgåelige) designfejl.

så hvad skal produktledere, programmelteams og virksomhedsledere gøre?

selvom der ikke er nogen En-størrelse-passer-alle-regel for programmeludviklingsmetoder, er der måder at reducere fejl, spare tid og skabe effektive resultater.

nedenfor gennemgår vi målene og fordelene ved programkravsdokumenter og et par bedste fremgangsmåder, der hjælper dig med at sømme processen fra start til slut.

hvad er programkrav dokumenter?

et programkravsdokument (også kaldet programkravspecifikationer) er et dokument eller et sæt dokumentation, der skitserer funktionerne og den tilsigtede opførsel af et program.med andre ord beskriver PROGRAMKRAVSDOKUMENTET (SRD) virksomhedens eller organisationens forståelse af slutbrugerens (typisk kundens) behov og afhængigheder samt eventuelle begrænsninger på systemet.

Hvad er inkluderet i en SRD?

mens SRD fungerer som en plan for styring af omfanget af et projekt, definerer det i sidste ende kun funktionelle og ikke-funktionelle krav til et system. Dokumentet skitserer ikke design-eller teknologiløsninger. Disse beslutninger træffes senere af udviklerne.

en velskrevet SRD bør:

• Opdel problemet i håndterbare dele.
• tjene som reference for test og validering.
• Informer designspecifikationerne (dvs.SRD ‘ et skal indeholde tilstrækkelige oplysninger om programmets krav for at gøre et effektivt design).
• giv feedback til klienten (slutbrugeren).SRD ‘ et viser klienten, at din organisation forstår det problem, de ønsker at blive løst, og hvordan man løser disse problemer gennem programmelløsninger. Da klienter ofte er direkte interessenter, er det især vigtigt at udarbejde dokumentationen klart i lægmandens termer (undgå teknisk jargon).

  igen, hvordan du skriver din SRD afhænger af den tilgang og metode, dit team eller organisation abonnerer på. IEEE-standardorganisationen anbefaler dog, at typiske SRD ‘ er skal dække følgende emner:

  • grænseflader
  • funktionelle kapaciteter
  • ydelsesniveauer
  • datastrukturer/elementer
  • sikkerhed
  • pålidelighed
  • Sikkerhed/privatliv
  • kvalitet
  • begrænsninger og begrænsninger

  Hvis hvert af disse emner er tydeligt behandlet og skitseret i din dokumentation, vil du have et mere komplet billede af de oplysninger, der er nødvendige for at udvikle din ansøgning.

  sådan sømmer du dit programkravsdokument

  uanset hvilken tilgang du tager til dokumentation, skal du følge disse bedste fremgangsmåder for at skabe en effektiv og effektiv SRD.

  hold det organiseret

  navnet på spillet er organisation. Før du begynder at dokumentere, skal du sørge for at starte med en organisationsstrategi for alle dokumenter, herunder hvor dine dokumenter er gemt, hvordan du sikrer konsistens, og hvordan bidragydere og samarbejdspartnere nemt kan holde dokumenter opdaterede. For at være effektiv, bør et program krav dokument være organiseret og klar. Mange organisationer er afhængige af husskabeloner for at opretholde konsistens på tværs af projekter. Skabeloner er en fantastisk måde at spare tid på (bare udfyld de forudorganiserede sektioner) og forblive konsistente i din dokumentationsproces.

  dokumentskabeloner forstærker dog ofte problemet med langvarige, teksttunge krav. For at undgå at blive kørt fast i sider med tekst, overveje at supplere din dokumentationsproces med visuelle data.

  

  sørg for, at kravene er komplette

  for at et krav skal være” komplet”, skal det indeholde alle de nødvendige oplysninger for at gennemføre kravet. Det betyder, at når designerne og udviklerne går for at opbygge funktionen, er de ikke tilbage med antagelser eller gæt om kravet.

  lad os for eksempel sige, at du udvikler en hjemmeside. Et af de skitserede krav er, hvad der skal ske i tilfælde af en fejl. Et ufuldstændigt krav kan sige noget som “i tilfælde af fejl skal systemet afslutte glat.”

  i dette tilfælde er “glat” ikke defineret og overlades til fortolkning. Denne tvetydighed kan føre til fejlagtig fortolkning af de ønskede resultater (og mere arbejde for at gå tilbage og rette det).

  for at undgå dette skal du skrive et komplet krav, der definerer, hvordan en vellykket funktion ser ud:

  “i tilfælde af fejl skal systemet vise en fejlside med følgende meddelelse:

  Uh-oh! Det ser ud til, at noget gik galt. Prøv igen om et par minutter. Hvis problemet fortsætter, kontakt vores supportteam på [email protected]. ”

  ved at definere et komplet krav er der mindre tvetydighed og et klart resultat for udviklingsholdet at arbejde på.

  gør krav testbare

  Dette er en ret allestedsnærværende standard, men alt for ofte undlader organisationer at skrive krav, der fuldt ud opfylder denne regel.

  Krav skal være verificerbare. Ellers er der ingen objektiv måde at vide, om kravet blev implementeret tilfredsstillende.

  for hvert krav, du skriver, skal du sørge for, at det er valideret på en eller flere af følgende måder:

  • inspektion
  • Demonstration
  • gennemgang
  • Test

  Krav på højt niveau gennemgår ofte inspektion eller brugertest, så de er typisk afhængige af mere generelle specifikationer. Men krav på lavere niveau, der gennemgår programmelprøvning, vil sandsynligvis have brug for mere detaljerede specifikationer.

  Anvend implementeringsneutrale funktionelle krav

  som vi bemærkede tidligere, er en SRD ikke et designdokument. Det definerer ikke og bør ikke definere, hvordan de funktionelle krav skal implementeres ud fra et designmæssigt synspunkt.

  derfor bør alle funktionelle krav være implementeringsneutrale. Med andre ord skal kravene angive, hvad systemet skal gøre, men ikke hvordan det skal gøre det.

  der er flere fordele ved implementeringsneutrale krav, herunder:

  • en mere effektiv designproces
  • modificerbare krav, der ikke er afhængige af et specifikt implementeringsdesign
  • mindre konflikt mellem krav som følge af modstridende implementeringsdetaljer

  eventuelle begrænsninger for implementering bør forbeholdes systemets ikke-funktionelle krav.

  Evaluer dokumentation med interessenter

  når alle programkravene er dokumenteret, Bed alle relevante interessenter evaluere den endelige dokumentation, inden udviklingen begynder.

  interessenter bør omfatte designere og udviklere, testere, der vil validere kravene, ingeniører, slutbrugerrepræsentanter og klienten.

  ved at få alle interessenter til at gennemgå og godkende dokumentationen, inden du begynder udviklingen, forbedrer du tilfredsheden på tværs af holdene og øger sandsynligheden for, at kravene imødekommer deres behov.hjælp udviklere og deres teams med at blive på samme side med rutediagrammer, der effektivt og elegant kortlægger dine specifikationer for programkrav. Se efter en diagramløsning, der kan hjælpe dig:

  • Organiser dine krav i et rutediagram for at holde dine komponenter forskellige, dine afhængigheder klare og interessenterne tydelige.
  • brug svømmebaner til visuelt at beskrive, hvilke hold der er ansvarlige for hvert kravsæt.
  • hurtigt ændre krav eller andre data som projektets behov udvikler sig.Link data (herunder yderligere dokumenter) for at understøtte og informere dit igangværende projekt.
  • del dokumentationen (og eventuelle ændringer) øjeblikkeligt med relevante interessenter.

  dokumentation behøver ikke at være en opgave. Med Lucidchart kan du nemt dokumentere processer, brugerhistorier og programkrav på et sted. Ved visuelt at definere dine kravspecifikationer vil du og dit team være i stand til at finde og handle på information hurtigt og samtidig reducere mulighederne for fejl, uoverensstemmelser og fejlfortolkninger.

  

  begynd at dokumentere

  få synlighed i dine eksisterende tekniske systemer med Lucidchart i dag.

  Lær hvordan