Hvorfor er det vigtigt at skrive gode krav?

At skrive store krav er et væsentligt skridt for at sikre, at et projekt bliver vellykket. Klare, velstrukturerede krav giver en køreplan for hele projektet og hjælper med at guide teams til det ønskede resultat. Ved at dokumentere alle aspekter af projektet, før det begynder, kan teams sikre, at alle involverede har en fælles forståelse af, hvad der skal gøres. Velskrevne krav reducerer også forvirring og minimerer fejl ved at give klare definitioner og forventninger omkring omfang, tidslinjer, leverancer og nødvendige ressourcer. Endelig er de med til at sikre, at interessenter holdes ajour med eventuelle ændringer eller problemer, som de opstår i hele projektets livscyklus. I sidste ende hjælper det at skrive store krav organisationer med at forblive organiseret og forblive på sporet med deres projekter, mens de mindsker risici forbundet med ændrede krav og uventede forsinkelser.

Hvordan vedtager man EARS-notation for Requirements Engineering?

EARS ville være en effektiv metode her. Det står for Easy Approach to Requirements Syntax. I denne metode skriver vi et klart, kortfattet og forståeligt sprog. Dette forbedrer hele den tekniske arbejdsgang og forenkler arbejdet ved at gøre tingene ret nemme at forstå. For at opnå dette er her nogle principper, som du skal huske på, mens du skriver kravene. De involverer: Hvert krav skal være i form af en hel sætning. Der må ikke bruges punkttegn, akronymer, forkortelser eller buzzwords. Prøv at lave korte, direkte og komplette sætninger. Sørg for, at hvert krav har et korrekt emne, prædikat og verbum. Emnet ville være brugertypen eller det system, vi taler om. Prædikatet ville være de betingelser eller handlinger eller ønskede resultater, vi forventer. Vi skal bruge ord som 'skal', 'vil' og 'skal' for at udtrykke en form for nødvendighed, og ord som 'må' til at udtrykke valgfrihed i kravet. Hvert krav skal effektivt forklare det slutresultat, vi ønsker fra systemet. Kravet skal også beskrive den kvalitet, vi forventer af systemet. Det hjælper, når vi måler slutresultatet og ser, om kravet er korrekt implementeret eller ej.

Den mest komplette guide til kravstyring og sporbarhed

Vedtagelse af EARS-notation for Requirements Engineering

Introduktion

Requirements engineering er en kritisk fase i softwareudviklingen, der lægger fundamentet for hele projektet. Nøjagtige og veldefinerede krav er afgørende for at levere et succesfuldt softwareprodukt, der opfylder brugernes behov. For at opnå dette, bruger softwareprofessionelle ofte forskellige metoder og notationer, og en sådan notation, der vinder popularitet, er EARS-notationen (Easy Approach to Requirements Syntax). I denne artikel vil vi udforske EARS-notationen, dens fordele, og hvorfor adoption af den kan forbedre kravkonstruktionsprocessen.

Forståelse af EARS-notation

Hvad er EARS?

EARS, som står for Easy Approach to Requirements Syntax, er en notation designet til at lette indfangning og dokumentation af krav på en klar og kortfattet måde. Det er udviklet af forskere som et svar på kompleksiteten og tvetydigheden, der ofte er forbundet med traditionelle kravdokumentationsmetoder. EARS forenkler kravkonstruktionsprocessen ved at tilbyde en struktureret måde at udtrykke krav på ved hjælp af naturligt sprog.

Nøgleelementer i EARS

EARS-notation omfatter flere nøgleelementer, hvilket gør det til et alsidigt og effektivt værktøj til kravudvikling:

Mål: Kernen i EARS er mål, som repræsenterer mål på højt niveau, som softwaresystemet bør opnå. Mål udtrykkes i naturligt sprog og tjener som udgangspunkt for kravspecifikation.
Softgoals: Softgoals er ikke-funktionelle krav eller kvalitetsegenskaber, der er afgørende for projektets succes, men som måske ikke er let kvantificerbare. Eksempler inkluderer brugervenlighed, vedligeholdelsesvenlighed og skalerbarhed.
Opgaver: Opgaver repræsenterer specifikke handlinger eller aktiviteter, der skal udføres for at nå et mål. De er ofte beskrevet i et verb-objekt-format, hvilket gør dem nemme at forstå.
Operander: Operander bruges til at give yderligere information og begrænsninger relateret til opgaver. De hjælper med at afklare, hvordan en opgave skal udføres eller under hvilke forhold.
Domæneantagelser: EARS opfordrer til dokumentation af antagelser om det domæne, hvor softwaren vil fungere. Disse antagelser giver kontekst og hjælper med at sikre, at kravene stemmer overens med scenarier i den virkelige verden.

Fordele ved at adoptere EARS-notation

Forbedret klarhed og præcision

En af de primære fordele ved at bruge EARS-notation er den forbedrede klarhed og præcision, det giver kravdokumentation. Ved at strukturere krav som mål, opgaver og softgoals gør EARS det nemmere for interessenter at forstå, hvad der forventes af softwaresystemet. Denne klarhed reducerer tvetydighed og fejlfortolkning, hvilket i sidste ende fører til mere præcise krav.

Naturligt sprogudtryk

EARS udnytter naturligt sprog, hvilket gør det tilgængeligt for en bred vifte af interessenter, herunder ikke-tekniske medlemmer af teamet. Denne rummelighed sikrer, at alle involverede i projektet kan bidrage til og forstå kravene, hvilket fremmer samarbejde og en fælles vision.

Fleksibilitet og tilpasningsevne

EARS er en fleksibel notation, der kan skræddersyes til at passe til et projekts specifikke behov. Uanset om du udvikler et sikkerhedskritisk system eller en brugercentreret applikation, kan EARS imødekomme en række forskellige kravtyper. Denne tilpasningsevne gør det til et værdifuldt værktøj til forskellige softwareudviklingssammenhænge.

Sporbarhed og forandringsledelse

Sporbarhed er et afgørende aspekt af kravudvikling, der sikrer, at hvert krav er knyttet til dets kilde og kan spores gennem hele udviklingens livscyklus. EARS-notation giver en klar struktur for sporbarhed, hvilket gør det nemmere at håndtere ændringer og vurdere virkningen af ændringer på andre krav.

Tilpasning til bedste praksis

EARS-notation stemmer overens med bedste praksis inden for kravudvikling. Det tilskynder til adskillelse af funktionelle og ikke-funktionelle krav, fremmer brugen af klart sprog og understreger vigtigheden af at indfange domæneantagelser – som alle bidrager til mere succesfulde softwareprojekter.

Hvad er INCOSE?

INCOSE, eller International Council on Systems Engineering, er en international non-profit medlemsorganisation, der leverer standarder og retningslinjer for at hjælpe organisationer med at skabe bedre systemtekniske processer. INCOSE System Requirements Standard (SRS) indeholder et sæt regler og standarder, der er designet til at hjælpe organisationer med at evaluere kraverklæringer, før de implementeres. SRS er blevet vedtaget af en række større virksomheder såvel som statslige agenturer rundt om i verden og kan bruges i mange forskellige industrier til forskellige applikationer. Det er vigtigt for interessenter som f.eks. softwareudviklere, forretningsanalytikere, projektledere, testere, IT-afdelingspersonale og andre teammedlemmer at have en stærk forståelse af disse krav, før de begynder at arbejde med en systemkravserklæring eller et projekt.

I sidste ende indebærer at skrive gode krav en omhyggelig balance mellem at være detaljeret og kortfattet, samt at sikre, at kravet er testbart og gennemførligt. INCOSE SRS tilbyder principper og retningslinjer, så teams kan skrive kvalitetskrav og hjælpe med at sikre, at deres projekter bliver succesfulde. Dette vil hjælpe med at undgå dyre fejl under udvikling eller efter implementering og derved hjælpe organisationer med at skabe bedre systemer på kortere tid.

Hvad er INCOSE-reglerne?

Kraverklæringer evalueres gennem reglerne i INCOSE. Disse standarder hjælper organisationer med at vurdere gennemførligheden og kvaliteten af krav, før de implementeres. Evalueringsprocessen omfatter fire hovedkriterier:

Tydelige – De skriftlige krav skal være klare, lette at læse og forståelige. Angiv tydeligt oplysningerne ved hjælp af bekræftende sætninger, der skal udveksles mellem aktørerne. Ethvert krav skal beskrive klare succeskriterier. Prøv at bruge et simpelt ordforråd og undgå forkortelser. For eksempel "Brugeren skal være i stand til at se revisionslograpporten".
Atomic – Hvert krav skal behandles som et diskret testtilfælde. Konjunktioner som og, eller og så videre bør ikke bruges, fordi de kan føre til at man går glip af krav. Dette er især afgørende, da udtryk som disse kan få softwareudviklere og testere til at overse kravene. At opdele komplicerede behov i mindre dele, indtil hver enkelt kan testes separat, er en måde at forhindre dette i at ske.
Entydig – Uklare, ufuldstændige eller modstridende krav kan føre til fejl og omarbejde. For at forhindre dette i at ske, bør kravene gennemgås af alle interessenter, før de færdiggøres. Dette vil hjælpe med at identificere eventuelle huller tidligt, som derefter kan løses.
Verificerbar – Alle i udviklingsteamet bør have adgang til dokumentet, så de kan referere til det så ofte som nødvendigt. Fordi kravene skal være klare, ønsker teammedlemmer ikke mere information. De skal alle være tilgængelige i SRS-dokumentet.
Nødvendigt – Hvert krav skal dokumentere noget, som brugerne virkelig har brug for eller noget, der kræves for at opfylde et standard- eller integrationsbehov på grund af eksistensen af en ekstern grænseflade. Det er også vigtigt for hvert krav at have en autoriseret kilde.
Designuafhængig – Hvert krav skal definere, hvad der er nødvendigt, ikke hvordan det skal implementeres. Kravene skal definere systemets egenskaber, der skal observeres eksternt, ikke de interne detaljer.
Gennemførligt – Hvert krav skal være teknisk eksekverbart og bør implementeres under hensyntagen til budgettet, deadline og andre begrænsninger, der påvirker projektet. Kravene bør afspejle den faktiske situation, herunder omkostninger, tidslinje og teknologi. De bør ikke være betingede af fremtidige teknologiske fremskridt.
Fuldstændig – Kravdokumentet bør indeholde tilstrækkelig information til, at dit udviklingsteam og testere kan færdiggøre produktet og sikre, at det opfylder brugerens krav uden fejl.
Korrekt – Kravene specificeret i dokumenterne bør være meget præcise for at undgå enhver form for forvirring. De må ikke have smuthuller, tvetydigheder, subjektivitet, superlativer eller sammenligninger. For at kunne skrive korrekte krav skal vi derfor indhente korrekte oplysninger og korrekt dokumentere de indsamlede oplysninger.

Vedtagelse af EARS i din kravkonstruktionsproces

For at anvende EARS-notation effektivt i din kravkonstruktionsproces skal du overveje følgende trin:

Træning og fortrolighed: Sørg for, at dit team er bekendt med EARS-notationen. Sørg for træning og ressourcer for at hjælpe dem med at forstå nøgleelementerne og principperne.
Skabeloner og værktøjer: Brug skabeloner og softwareværktøjer, der understøtter EARS-notation. Disse værktøjer kan strømline kravdokumentationsprocessen og lette samarbejdet mellem teammedlemmer.
Retningslinjer og standarder: Etabler retningslinjer og standarder for brug af EARS i din organisation. Definer navngivningskonventioner, dokumentstruktur og bedste praksis for at opretholde konsistens.
Samarbejde: Fremme samarbejde mellem interessenter, herunder slutbrugere, forretningsanalytikere og udviklere. EARS-notationens naturlige sprogtilgang fremmer bedre kommunikation og fælles forståelse.
Gennemgang og validering: Implementer en gennemgang og valideringsproces for at sikre, at krav, der er optaget ved hjælp af EARS, er fuldstændige, konsistente og i overensstemmelse med projektets mål.

Konklusion

Ved at bruge EARS-notation til kravteknik giver det adskillige fordele, herunder forbedret klarhed, naturligt sprogudtryk, fleksibilitet, sporbarhed og tilpasning til bedste praksis. Ved at omfavne EARS kan softwareudviklingsteams forbedre deres kravdokumentationsproces og øge sandsynligheden for at levere succesfulde softwareprojekter, der opfylder brugernes behov og forventninger. Uanset om du er en erfaren kravingeniør eller ny på området, er det et skridt i retning af mere effektiv kravudvikling at overveje EARS som en notationsmulighed.

Glem ikke at dele dette opslag!