En av de viktigaste delarna av alla programvaruutvecklingsprojekt är att skapa detaljerade, exakta krav. Utan en tydlig förståelse för vad som behöver byggas är det omöjligt att skapa en slutprodukt av hög kvalitet. Att skriva bra krav är tyvärr ofta lättare sagt än gjort. Den främsta anledningen till att folk skriver dåliga krav är att de inte har haft någon utbildning eller erfarenhet av att skriva bra krav. Om du eller din personal har problem med att skriva bra krav kan du ha nytta av vägledning om hur du skriver bra krav. Genom att ta dig tid att lära dig att skriva bättre krav kan du förbättra den övergripande kvaliteten på dina programvaruutvecklingsprojekt – och spara dig själv mycket huvudvärk på vägen.

Varför misslyckas systemtekniska projekt?

Varför misslyckas projekt i hårt reglerade branscher? Många forskare har undersökt varför system och mjukvaruprojekt misslyckas. Standish-gruppen genomförde forskning 2009, som visar att de flesta anledningar till att projekt misslyckas är relaterade till krav.

Det är en av de främsta anledningarna till att skriva bra krav är avgörande för att projektet ska lyckas. Att skriva bra krav ger dessutom många andra fördelar mellan teamen.

Vad är kravspecifikation?

Kravspecifikation är en process där krav definieras, dokumenteras och analyseras. Det är en viktig del av mjukvaruutveckling eftersom det säkerställer att alla intressenter är överens om mjukvarans funktionalitet innan utvecklingen påbörjas. Genom att göra detta minskar sannolikheten för missförstånd och omarbetningar senare.

Kravspecifikation, även känd som dokumentation, är en process där man antecknar eller skriver alla system- och användarkrav i form av ett dokument. Dessa krav måste vara tydliga, fullständiga, heltäckande och konsekventa.

Krav Engineering Process

Det finns några aktiviteter som vi möter när vi arbetar med kraven. I Requirements Engineering-cykeln finns det fem huvudaktiviteter, nämligen,

1. Krav Elicitation – Det här är processen att samla, granska och förstå intressenternas och användarnas behov och begränsningar för säsongen. Användare behöver domäninformation, befintlig systeminformation, förordningar, standarder etc. Baserat på denna information framkallar vi kraven. Efter detta går vi över till kravanalys och förhandling. 
2. Kravanalys och förhandling – Analys är processen att förfina användarnas behov och begränsningar på basis av insamlad och framkallad information. Sedan går vi till dokumentationsaktiviteten. 
3. Krav Dokumentation/Specifikation – Efter att ha fått kravspecifikationerna går vi till dokumentationsdelen. Vi dokumenterar användarnas behov och begränsningar tydligt och exakt. 
4. Krav Validering – Slutligen, i valideringsaktiviteten, infogar vi att säsongskraven är fullständiga, koncisa och tydliga. 
5. Kravhantering – Kravhantering är ett sätt att samla, analysera, förfina och prioritera alla produkter eller krav i utvecklingsfasen. Under denna fas etableras också gedigen spårbarhet mellan kraven och informationskällorna. 

När vi slutför dessa fem aktiviteter upprepar vi dem gång på gång tills vi får en uppsättning överenskomna kravdokument som är formella specifikationer.

Varför är det viktigt att skriva bra krav?

Det finns många fördelar med att ha bra kravspecifikationer. Några av dem är listade nedan:

• Bidrar till att alla intressenter har en gemensam förståelse för det system som ska utvecklas. Detta undviker alla missförstånd under senare utvecklingsstadier.
• Fungerar som en referenspunkt för alla intressenter under utvecklingsprocessen.
• Hjälper till att identifiera eventuella luckor i kraven i ett tidigt skede.
• Minskar den totala kostnaden och tiden för utveckling eftersom det undviker omarbetning på grund av förändringar i krav.

Vad uppnår vi genom att skriva stora krav?

Det finns många saker som stora krav hjälper till att uppnå. Några av dem är listade nedan:

• Stora krav bidrar till att systemet som utvecklas möter användarnas behov.
• De fungerar som underlag för att testa systemet för att säkerställa att det fungerar som förväntat.
• De hjälper till att minska den totala kostnaden och tiden för utveckling genom att undvika omarbetning på grund av förändringar i krav.
• Stora krav bidrar till att göra utvecklingsprocessen mer effektiv och ändamålsenlig.

Utmaningar när du skriver krav

Det finns olika utmaningar människor möter när de skriver krav.

Dåligt pappersarbete – I vissa organisationer är dokumentation av processer antingen obefintlig eller inte i nivå. I det här fallet blir kravinsamlingen en process i två steg: först omvända den befintliga processen och sedan identifiera områden som behöver förbättras och optimeras. För att bekräfta att kraven är konkretiserade och korrekta är det viktigt att identifiera nyckelintressenter och ämnesexperter och kontakta dem direkt. Att rita affärsprocesskartor och visualisera arbetsflöden är två utmärkta sätt att göra det. Detta hjälper till att eliminera felaktiga antaganden samtidigt som det ger en komplett bild. Att rita processkartor och visa processer är två användbara tillvägagångssätt för detta ändamål.

Motstridiga krav – När intressenter har olika prioriteringar för sina affärsmål leder det till krav som står i konflikt med varandra. I fall som dessa är det en affärsanalytikers ansvar att dokumentera alla krav i detalj, identifiera vilka förfrågningar som står emot varandra och ge intressenter möjlighet att bestämma vad som prioriteras.

Du kan inte fatta beslut utan att höra intressenternas synpunkter och som affärsanalytiker kanske du har några idéer om vad som bör prioriteras. Det är fortfarande viktigt att höra intressenternas perspektiv. Att skapa en omröstning kan vara en av metoderna för att få klarhet i vad som är viktigast för majoriteten av intressenterna.

Otillgänglighet för användarinmatning – Några orsaker kan bidra till att slutanvändarna inte är tillgängliga, och var och en kräver sin egen lösning. Till exempel är slutanvändare ibland så upptagna av sitt dagliga arbete att de inte är villiga att delta i kravinsamlingsaktiviteter.

I sådana fall är det bästa en affärsanalytiker kan göra att begränsa antalet och längden på engagemang. Inför mötet kommer att göra så mycket research som möjligt för att göra diskussionen mer organiserad och informativ. Det är nästan som att förvandla kravinsamling till kravvalideringssessioner. definiera fokusgrupper och identifiera de mest lämpliga slutanvändarna för varje grupp

Fokusera på gränssnitt istället för erfarenhet – Många intressenter och slutanvändare har en tydlig vision om hur den nya lösningen ska se ut, men de vet inte vad den ska åstadkomma. Alla systems användargränssnitt är avgörande, men det bör inte definiera eller störa funktionaliteten.

Affärsanalytiker bör alltid komma ihåg att hålla design- och funktionskrav åtskilda i sin dokumentation. Genom att använda mer allmänna verktyg som diagram, användarberättelser eller low-fi-prototyper snarare än designutkast, kan de behålla fokus på de funktionella aspekterna av kravinsamling.

Intressenter – När intressenter eller slutanvändare försöker tala om för designers hur systemet ska fungera istället för vad systemet ska göra, kan det leda till suboptimala konstruktioner. För att avvärja detta, validera varje potentiellt "falskt krav" genom att fråga "varför?" tills du kommer fram till det verkliga problemet som behöver lösas.

Kommunikationsfrågor – Bland de frågor som kan leda till felkommunikation mellan en affärsanalytiker och andra parter är språkbarriärer, felaktiga antaganden, otillräckligt förklarat ordförråd och överanvändning av tekniska termer.

Den idealiska metoden för att undvika detta problem är att interagera ofta och utveckla tvåvägskonversationer. Dokumentera behoven som du har upptäckt och skicka in dem för expertgranskning och kritik till en mängd ämnesspecialister, skapa en ordlista med jargong och dubbelkolla lokaler.

Standarder för skrivkrav?

EARS skulle vara en effektiv metod här. Det står för Easy Anärma sig RKRAV Syntax, av Alastair Marvin. I den här metoden skriver vi ett tydligt, kortfattat och begripligt språk. Detta förbättrar hela kravtekniska arbetsflödet och förenklar arbetet genom att göra saker ganska lätta att förstå. 

För att uppnå detta, här är några principer som måste hållas i åtanke när du skriver kraven. De involverar:

• Varje krav måste vara i form av en fullständig mening. Inga punkter, akronymer, förkortningar eller buzzwords ska användas. Försök att göra korta, direkta och fullständiga meningar. 
• Se till att varje krav har ett korrekt subjekt, predikat och verb. Ämnet skulle vara användartypen eller systemet som vi talar om. Predikatet skulle vara de villkor eller handlingar eller önskade resultat vi förväntar oss. Vi måste använda ord som 'ska', 'vilja' och 'måste' för att uttrycka någon form av nödvändighet, och ord som 'kan' för att uttrycka valfrihet i kravet. 
• Varje krav måste effektivt förklara det slutresultat vi önskar från systemet. 
• Kravet ska också beskriva den kvalitet vi förväntar oss av systemet. Det hjälper när vi mäter slutresultatet och ser om kravet är korrekt implementerat eller inte.

Viktiga komponenter i ett kravdokument:

Huvuddelarna i en kravspecifikation för programvara är:

• Yrkesförare – Anledningarna till att kunden funderar på att bygga ett system beskrivs i detta avsnitt. Detta avsnitt innehåller vidare de problem kunden står inför med det nuvarande systemet och de möjligheter som det nya systemet kommer att ge.
• Affärsmodell – Den affärsmodell som systemet ska stödja diskuteras i detta avsnitt. Den innehåller vidare olika andra detaljer som organisations- och affärssammanhang, huvudsakliga affärsfunktioner och processflödesdiagram för systemet.
• Funktions- och systemkrav – Det här avsnittet beskriver vanligtvis krav som är organiserade i en hierarkisk struktur. Funktionskraven är på toppnivå och de detaljerade systemkraven listas som underposter.
• Systemanvändningsfall – Det här avsnittet består av ett Unified Modeling Language (UML) användningsfallsdiagram som förklarar alla viktiga externa enheter som kommer att interagera med systemet och de olika användningsfallen de måste utföra.
• Tekniska krav – Det här avsnittet diskuterar alla icke-funktionella krav som utgör den tekniska miljön och de tekniska begränsningar som programvaran kommer att fungera inom.  
• Systemkvaliteter – I det här avsnittet definieras systemets många kvaliteter som tillförlitlighet, servicebarhet, säkerhet, skalbarhet, tillgänglighet och underhållsbarhet.
• Begränsningar och antaganden – Alla begränsningar som läggs på systemdesignen ur kundens synvinkel beskrivs i detta avsnitt. De olika antagandena från ingenjörsteamet om vad man kan förvänta sig under utvecklingen diskuteras också här.
• Godkännande kriterier – Detaljer om alla villkor som ska uppfyllas innan systemet överlämnas till slutkunderna diskuteras i detta avsnitt.

Egenskaper för ett programvarukravspecifikationsdokument:

• Rensa – De skriftliga kraven ska vara tydliga, lättlästa och begripliga. Ange tydligt informationen med hjälp av bekräftande meningar som ska utbytas mellan aktörerna. Varje krav måste beskriva tydliga framgångskriterier. Försök att använda enkla ordförråd och undvik förkortningar. Till exempel, "Användaren ska kunna se revisionsloggrapporten".
• Atomic – Varje krav bör behandlas som ett diskret testfall. Konjunktioner som och, eller, och så vidare bör inte användas eftersom de kan leda till att kraven går miste. Detta är särskilt viktigt eftersom termer som dessa kan få mjukvaruutvecklare och testare att förbise kraven. Att dela upp komplicerade behov i mindre delar tills var och en kan testas separat är ett sätt att förhindra att detta händer.
• Entydig – Otydliga, ofullständiga eller motsägelsefulla krav kan leda till fel och omarbetningar. För att förhindra att detta händer bör kraven ses över av varje intressent innan de slutförs. Detta kommer att hjälpa till att tidigt identifiera eventuella luckor som sedan kan åtgärdas.
• kontrollerbara – Alla i utvecklingsteamet bör ha tillgång till dokumentet så att de kan referera det så ofta som krävs. Eftersom kraven måste vara tydliga vill teammedlemmarna inte ha mer information. De ska alla vara tillgängliga i SRS-dokumentet.
• Nödvändigt – Varje krav ska dokumentera något som användarna verkligen behöver eller något som krävs för att uppfylla ett standard- eller integrationsbehov på grund av att det finns ett externt gränssnitt. Det är också viktigt för varje krav att ha en auktoriserad källa.
• Designoberoende – Varje krav måste definiera vad som är nödvändigt, inte hur det ska implementeras. Kraven måste definiera egenskaperna hos systemet som ska observeras externt, inte de interna detaljerna.
• Möjlig – Varje krav måste vara tekniskt genomförbart och bör implementeras med hänsyn till budget, deadline och andra restriktioner som påverkar projektet. Kraven bör återspegla det faktiska tillståndet, inklusive kostnad, tidslinje och teknik. De bör inte vara beroende av framtida tekniska framsteg.
• Komplett – Kravdokumentet bör innehålla tillräckligt med information för att ditt utvecklingsteam och testare ska kunna slutföra produkten och säkerställa att den uppfyller användarens krav utan buggar.
• Correct – De krav som anges i dokumenten bör vara mycket exakta för att undvika all form av förvirring. De får inte ha några kryphål, tvetydigheter, subjektivitet, superlativ eller jämförelser. För att kunna skriva korrekta krav måste vi därför skaffa korrekt information och korrekt dokumentera den information som samlas in.

Regler för uppsättningen av korrekta krav

Det finns vissa regler som kraven måste följa för att kallas "Korrekt".

• Komplett – Kravdokumentet bör innehålla tillräckligt med information för att ditt utvecklingsteam och testare ska kunna slutföra produkten och säkerställa att den uppfyller användarens krav utan buggar.
• Konsistens – Håll en jämn detaljnivå. Till exempel, för användarkrav, bör en slutanvändare vara föremål för varje mening. På samma sätt, för systemkrav, bör ett system vara föremål för varje mening.
• Modifierbarhet – Kraven kan förändras under projektets livscykel. Kravloggen ska lagras och analys av inverkan av ändringar som görs i den på andra krav och projektmoment bör vara möjlig.
• Prioritering – Kraven måste klassificeras ur betydelsesynpunkt. Inte alla egenskaper som önskas för ett system är lika viktiga. För det skulle det vara bra att upprätta en regel för att definiera kravprioriteringar på organisationsnivå och anpassa den till varje projekt. Och arbeta med användarna så att de kan prioritera kraven.

Visurkrav ALM-plattform

Visure är en av de mest pålitliga plattformarna för hantering av applikationslivscykeln som är specialiserade på kravhantering för organisationer av alla storlekar över hela världen. Visures största partners är affärskritiska och säkerhetskritiska företag. Företaget integrerar genom hela Application Lifecycle Management-processerna inklusive riskhantering, problem- och defektspårning, spårbarhetshantering, förändringshantering och olika andra områden som kvalitetsanalys, kravversionering och kraftfull rapportering.  

Om du letar efter ett kravhanteringsverktyg som hjälper dig med både funktionella och icke-funktionella krav, kolla in Visure Requirements. Med denna plattform kan du enkelt skapa, hantera och spåra alla dina projekts krav på ett ställe.

Slutsats

För att kunna producera bra mjukvara är det viktigt att ha en välskriven kravspecifikation. Detta dokument beskriver kundens behov och vad systemet måste göra för att möta deras förväntningar. Men att skriva bra krav kan vara utmanande. Det finns många standarder och riktlinjer som måste följas, och det finns många olika sätt att skriva dem beroende på vilket språk och vilka verktyg du använder. Visure Requirements ALM Platform erbjuder en kurs som lär dig hur du skriver effektiva kravspecifikationer med hjälp av bästa praxis och branschstandarder. Kursen tar upp alla väsentliga komponenter i ett kravdokument, från struktur till formatering, samt hur man använder olika språk för skrivkrav. Det lyfter också fram egenskaperna hos stora krav så att du kan skapa dokument som ditt team kommer att älska att arbeta med. Om du vill lära dig mer om att skriva effektiva krav, prova Kravspecifikationskurs av Visure Requirements ALM Platform idag!