Vi har tidigare diskuterat de fyra viktigaste aktiviteterna inom kravhantering.

Kravhantering är en process för att samla in och definiera vilka tjänster som ska tillhandahållas av systemet.

Det fokuserar på att bedöma om systemet är användbart för verksamheten (genomförbarhetsstudie), upptäcka krav (inhämtning och analys), omvandla dessa krav till något standardformat (specifikation) och kontrollera att kraven definierar det system som kunden vill ha (validering).

I praktiken är kravutformning inte en sekventiell process, det är en iterativ process där aktiviteterna är interfolierade.

Till exempel itererar man först på användarkraven; elicitering, specifikation och validering, och upprepar samma steg för systemkraven.

I början av processen läggs det mesta arbetet på att förstå affärs- och användarkrav på hög nivå. Senare i processen kommer mer arbete att läggas på att ta fram och förstå detaljerade systemkrav.

Vissa personer anser att kravutformning är en process där man tillämpar en strukturerad analysmetod, t.ex. objektorienterad analys. Detta innebär att man analyserar systemet och utvecklar en uppsättning grafiska systemmodeller, t.ex. användningsfallsmodeller, som sedan fungerar som en systemspecifikation.

Och även om strukturerade metoder har en roll att spela i processen för kravutformning finns det mycket mer i kravutformningen än vad som täcks av dessa metoder.

Objektsorienterad analys och design kommer att diskuteras i en annan serie handledningar.

Användar- och systemkrav

Typiskt sett presenteras kraven i två detaljnivåer; användar- och systemkrav, där användaren behöver en högnivåuttalande av kraven, medan systemutvecklare behöver en mer detaljerad systemspecifikation. Så användar- och systemkrav hänvisar bara till olika detaljnivå.

Att ha olika detaljnivå är användbart eftersom det kommunicerar information om det system som utvecklas för olika typer av läsare.

Så, slutanvändare kommer inte att bry sig om detaljerna, de behöver ett generiskt, abstraherat skriftligt krav.

Vidare de personer som är involverade i utvecklingen, de behöver exakt vad systemet ska göra.

Du kommer förmodligen att hamna i en massa problem och missförstånd om du inte hade en tydlig separation mellan de olika detaljerna på olika nivåer.

Användarkrav

Det beskriver de tjänster som systemet ska tillhandahålla och de begränsningar under vilka det måste fungera. Vi förväntar oss inte att se någon detaljnivå, eller vad exakt systemet ska göra, Det är mer av generiska krav.

Det är vanligtvis skrivet på ett naturligt språk och levereras genom diagram.

Vi kommer att diskutera olika sätt att specificera kraven senare i den här serien.

Systemkrav

Systemkraven innebär en mer detaljerad beskrivning av systemtjänsterna och de operativa begränsningarna, t.ex. hur systemet kommer att användas, och utvecklingsbegränsningarna, t.ex. programmeringsspråken.

Denna detaljnivå behövs av dem som är involverade i systemutvecklingen, som ingenjörer, systemarkitekter, testare etc.

Funktionella & Icke-funktionella krav

Mjukvarukraven klassificeras i funktionella krav och icke-funktionella krav.

Funktionella krav

Det täcker de viktigaste funktionerna som ska tillhandahållas av systemet. När de uttrycks som användarkrav beskrivs de vanligtvis på ett abstrakt sätt.

Men mer specifika funktionella systemkrav beskriver systemets funktioner, dess ingångar, bearbetning; hur det kommer att reagera på en viss ingång, och vad som är det förväntade resultatet.

Non-funktionella krav

Dessa är begränsningarna av de funktioner som tillhandahålls av systemet.

Begränsningarna, t.ex. hur många processer systemet kan hantera (prestanda), vilka säkerhetsfrågor systemet måste ta hand om, t.ex. SQL-injektioner …

Felprocenten (tillförlitlighet), vilka språk och verktyg som kommer att användas (utveckling), vilka regler som måste följas för att se till att systemet fungerar inom ramen för organisationens lagar (lagstiftning).

Nonfunktionella krav är ofta kritiska än enskilda funktionella krav. Användarna kan oftast hitta sätt att arbeta runt en systemfunktion som inte riktigt uppfyller deras behov. Men om ett icke-funktionellt krav inte uppfylls kan det innebära att hela systemet blir oanvändbart.

Till exempel, om ett flygplan inte uppfyller sina tillförlitlighetskrav kommer det inte att vara säkert att använda, eller om ett inbyggt kontrollsystem inte uppfyller sina prestandakrav kommer kontrollfunktionerna inte att fungera korrekt.

Inte-funktionella krav bör vara mätbara

När det är möjligt bör vi skriva icke-funktionella krav kvantitativt, så att de kan testas. Man kan mäta dem när systemet testas för att kontrollera om systemet uppfyller sina icke-funktionella krav.

I praktiken har kunderna till ett system ofta svårt att översätta sina mål till mätbara krav. De förstår inte vad någon siffra som definierar den erforderliga hastigheten eller tillförlitligheten. För vissa mål, till exempel underhållbarhet, finns det inga mätvärden som kan användas.

Kostnaden för att verifiera mätbara icke-funktionella krav kan vara mycket hög och kunderna kanske inte tycker att dessa kostnader är motiverade.

Non-funktionella och funktionella krav är beroende

Non-funktionella krav står ofta i konflikt med varandra, interagerar eller genererar till och med andra funktionella eller icke-funktionella krav.

Ett användarkrav som handlar om säkerhet, t.ex. att begränsa åtkomsten till auktoriserade användare, kan generera andra krav som är funktionella, t.ex. behovet av att inkludera användarautentiseringsmöjligheter i systemet.

Skillnaden mellan funktionella och icke-funktionella krav

I praktiken är det svårt att separera funktionella och icke-funktionella krav. Skillnaden är inte så tydlig som deras definitioner antyder.

Skillnaden mellan funktionella och icke-funktionella krav

Om de icke-funktionella kraven anges separat från de funktionella kraven kan förhållandet mellan dem vara svårt att förstå.

Däremot bör vi uttryckligen lyfta fram krav som är tydligt relaterade till framväxande systemegenskaper, t.ex. prestanda eller tillförlitlighet.

Framväxande egenskaper är egenskaper hos systemet som helhet snarare än egenskaper som kan härledas från egenskaperna hos de enskilda systemkomponenterna.