Exempel på olika typer av krav: funktionella/icke-funktionella

Här går vi igenom olika typer av krav, funktionella och icke-funktionella. Samt olika sätt att beskriva krav – med hjälp av use case (användningsfall) eller user stories (användarberättelser).

Vad är Funktionella krav?

Funktionella krav beskriver hur systemet interagerar med användarna. Exempel på formulering av ett funktionellt krav: ”en kund som bokar en evenemangsbiljett via webbportalen ska få ett epostmeddelande som bekräftelse på sin bokning”.

Vad är icke-funktionella krav?

Krav som inte beskriver något som någon/något vill göra i/med systemet kallas för icke-funktionella krav. Till exempel krav på prestanda, tillgänglighet mm. Icke-funktionella krav är ett väl etablerat språkbruk, men på beställarsidan leder det lätt tanken fel.

Finns det bättre alternativ? Jadå…

Kvalitetsegenskaper och kvalitetskrav

Kvalitetskrav, kvalitetsegenskaper och även kvalitetsattribut används synonymt med icke-funktionella krav. Vår erfarenhet ger vid handen att Kvalitetskrav bättre beskriver vad det handlar om.

Kravarbetets syfte är att fånga verksamhetens faktiska behov och översätta dessa till krav, så att resulterande system levererar enligt förväntan. Centralt för begreppet kvalitet är just att kunna beskriva vad som görs, hur det görs, när det görs, vem som gör det och varför det görs.

Ett exempel på kvalitetsegenskaper är att systemet ska klara minst 200 användare som bokar evenemangsbiljetter samtidigt. Kvalitetsegenskaper brukar brytas ner i två huvudkategorier: Observerbara under exekvering och Ej observerbara under exekvering. Kraven som inte går att observera under exekvering bryts ner i tre underkategorier: utvecklingsrelaterade, verksamhetsrelaterade och arkitekturella.

Kvalitetskrav påverkar ofta varandra. I bilden till höger så visar den gröna vad som händer med andra egenskaper när man maximerar prestanda.

Exempel på hur krav påverkar varandra
Exempel på hur krav påverkar varandra

Prestandan påverkar nästan alla andra egenskaper negativt. Vad som i praktiken händer när man maximerar prestanda är att man minimerar kommunikation och slår ihop så mycket som möjligt till en monolit. Ett sådant system är svårt att modifiera, svårt att portera, det brukar bli svårt att få till all funktionalitet och användbarheten brukar bli lidande. Säkerheten handlar många gånger om kryptering, certifikat, brandväggar och allt det tar prestanda.

Designbegränsningar

Designbegränsningar är tekniska, verksamhets- eller avtalsmässiga begränsningar för systemet och/eller den process som används för att utveckla systemet. Exempelvis: använd CSS v2.1 för alla stylesheets på webbsidor. Systemet ska kunna köras på den gamla plattformen.

Hur formulerar man kvalitetskrav?

”Systemets svarstider utifrån användarens perspektiv skall i 90% av fallen understiga 2 sekunder vid normalbelastning (200 samtidiga användare). I resterande fall skall svarstiderna inte överstiga 10 sekunder.” Är ett exempel på hur kvalitetskrav kan formuleras. Observera att kraven på ett kvalitetskrav, =), är att det ska vara mätbart och förutsättningarna för normalbelastning ska framgå.

Ett annat sätt att uttrycka detta kan vara genom user stories: ”Som kund så ska bokningsformuläret laddas på mindre än 20 sekunder i 99 fall av 100 och aldrig mer än 30 sekunder. Så att jag inte blir frustrerad och går till en konkurrent”.

Ladda hem dokument

Från behov till krav

  • Bocka för de dokument du vill ladda ner
                • Hidden
                • Hidden
                • Detta fält används för valideringsändamål och ska lämnas oförändrat.

                Olika sätt att uttrycka krav

                IEEE 830

                Från början var många av kraven av typen ”en-rads-krav”, som följer en standard som heter IEEE 830. Varje ”formulering” skulle avse ett krav, summan av alla krav blev kravspecifikationen. Problemet med denna typ av kravspecifikationer är att det är svårt att överblicka vad system kommer att leverera för användarupplevelse. Särskilt inte för de verksamhetspersoner som är med för första gången för att bidra med sina behov och direktiv.

                Exempel på IEEE 830 krav – varje krav ska ha en formulering

                • Pinkoden skall bestå av fyra siffror.
                • Om tillgängligt belopp i bankomaten är mindre än 50 000 SEK, skall max uttagsbelopp vara 1 500 SEK per transaktion.
                • Uttagsbelopp skall vara ett jämt hundratal (ex 100, 200, 300).
                • Bankkort skall tas av kund innan kontanter matas ut.

                Use-Case – Vad är användningsfall?

                Användningsfall (use case) lanserades av Ivar Jacobson och beskriver den kommunikation som sker mellan aktören (som använder systemet) och systemet. Med detta som underlag kan utvecklarna konstruera ett system. Fördelarna med detta är stora. Framför allt det faktum att användningsfall har ett sammanhang och en tidsaspekt (först sker detta, och sen det här, och sen det här, …) vilket gör att en verksamhetsperson har mycket större möjligheter att läsa och förstå.

                Fortfarande är det dock så att mycket tid läggs på att författa krav. Krav som kravställaren kanske inte har full insikt.

                Exempel på användningsfall:

                1. Systemet uppmanar kunden att ange sin pinkod och trycka klar.
                2. Kunden anger sin fyrsiffriga pinkod.
                3. Systemet kontrollerar kort och kod.
                4. Systemet uppmanar kunden att välja belopp att ta ut (måste vara ett jämt hundratal) och trycka klar
                5. etc.

                Vad är User stories?

                En user story beskriver kortfattat vad en användare ska kunna göra i systemet och det värde som skapas. Konceptet omfattar tre delar, en beskrivning av ”storyn” som underlag för planering, vidare diskussioner om detaljer i storyn samt kriterier för att avgöra när en story är färdigutvecklad/kravet uppfyllt.
                User Stories bygger till skillnad från IEEE 830 och användningsfall inte upp någon kravdokumentation. Istället fungerar varje User Story som en minneslapp för diskussioner som ska föras mellan produktägaren och utvecklingsteamet för att blottlägga alla de krav som rör User Storyn. En User Story är därför egentligen inte ett krav utan ett löfte om diskussioner om krav och ska kunna rymmas på en post-itlapp.

                User stories introducerades av den agila metoden Extreme Programming (XP) och är ett centralt koncept i Scrum.

                Exempel på en user story

                • Som kund vill jag kunna ta ut kontanter

                Utbildning

                Här hittar du en utbildning i agil kravhantering med user stories. Är du intresserad av att lära dig mer om användningsfall och att ta fram krav ur verksamhetsmodeller rekommenderas vi vår grundkurs i kravanalys.
                Här hittar du hela vårt utbud av utbildning i kravhantering

                Utbildning för kravanalytiker

                Program som ger både bredd & spetskompetens inom krav

                • Heltäckande kompetens inom krav: ta dig an komplexa arbetsuppgifter och öka möjligheterna till nya, mer utmanande, uppdrag
                • Behärska agil metodik, verksamhetsanalys i stora organisationer såväl som kvalitetskrav
                • Kartlägg, analysera och strukturera den information människor behöver för att kunna arbeta effektivt

                 

                Aaron Haglund

                Aaron Haglund

                Psst! Artikeln är en sammanställning av gammalt Astrakanmaterial. Om du är redo för något mer modernt kika på vår utbildning i kravhantering.