Hur snabba ska funktionerna vara? Hur gör systemet om databasen rasar? Hur hanteras säkerhet för användare? Vi brukar, lite slarvigt, beskriva icke funktionella krav som HUR-krav. Men hur viktigt är det med denna typ av krav? Och hur gör du för att lyckas formulera och hantera icke funktionella krav?
Bygg en prototyp för att samla in icke funktionella krav
Att bygga en prototyp är ett underskattat sätt att samla in krav. Den behöver inte vara komplicerad för att du ska kunna fånga behoven. Ger den en bild av användargränssnittet kan det vara nog så kraftfullt, i synnerhet när det kommer till icke funktionella krav. För det är först när vi ser eller kanske interagerar prototypen med systemet som frågorna som rör icke funktionella krav kan ställas:
Kommer det ta lång tid att söka? Kommer webbgränssnittet fungera i Chrome? Skickas mina inloggningsuppgifter krypterat?
Med en prototyp kan icke funktionella kraven samlas in på ett relativt tidigt stadium och kraven kan uppdateras för att skapa maximal kundnytta för produkten. Alternativet är att dessa krav ställs när produkten är ”nästan färdig”. Då blir ändringar antingen betydligt dyrare eller kanske omöjliga att genomföra inom projektets ramar.
Ladda ner vår guide "Så lyckas du med din kravinsamling"
Anpassa efter feedback från slutanvändare
För att uppnå kvalitet på produkter och tjänster är feedback en otrolig förbättringspotential i många organisationer. Vi har fortfarande inte sett en organisation som hanterar återkoppling från slutanvändaren in i kraven på ett bra sätt, information som är livsviktig för kundnöjdheten och den levererade affärsnyttan. Detta gäller givetvis inte bara icke funktionella krav, men dessa krav har en dold talang i att glömmas bort eller på andra sätt lämnas utanför allmän kännedom. Feedbacken från marknaden ska naturligtvis också ha effekt på kommande uppdateringar. Inte bara på produkten i fråga, utan på hela portföljen och sättet organisationen jobbar.
Vill du ha ekonomiska incitament finns en mängd undersökningar som visar på att det är dyrare att rätta fel i produktion än i kravställning. En studie från NASA visar till exempel att kostnaden för felrättning ökar med en faktor på 1000!
Rätt nivå även på icke funktionella kraven
Icke funktionella krav kan ofta beskrivas som tekniska eller designrelaterade begränsningar i ett projekt. Till exempel är krav på stöd för en viss plattform sällan ett valbart krav, utan en absolut begränsning som projektet måste förhålla sig. Det gör det ännu viktigare att tidigt identifiera vilka icke funktionella krav som innebär begränsningar för det projekt du är aktiv i, eftersom begränsningarna påverkar både andra krav och tidsestimat. Balansgången ligger i att identifiera begränsningarna samtidigt som du bör vara noga med att specificera kraven på rätt detaljnivå. För i ivern att vara detaljerade, kristallklara och utförliga är det lätt att låsa in sig och stänga ute lösningar som kanske möter de verkliga behoven bättre, än den lösning som beskrivits i detaljspecifikationen. Här gäller det att inse och acceptera att krav har olika abstraktionsnivåer.
Vill du lära dig mer och skapa ännu bättre förutsättningar för att lyckas med din kravhantering?
Ladda ner vår guide.
