Visure-løsninger


Support
Tilmeld
Login
Start gratis prøveversion

Vedtagelse af EARS-notation for Requirements Engineering

Vedtagelse af EARS-notation for Requirements Engineering

Indholdsfortegnelse

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!

Top