Krav – funktionella, ickefunktionella, och helt fel?
Jag kanske är helt korkad i huvudet, men trots att jag i över tio års tid plöjt systemspecifikationer fattar jag faktiskt inte vad det är för skillnad på funktionella och ickefunktionella krav.
Typexempel på funtionellt krav: ”Sökfunktionen ska klara av trunkerade sökningar”
Typexempel på ickefunktionellt krav: ”Det ska vara möjligt att nå sökfunktionen från alla delar av systemet”
Att sökfunktionen ska vara nåbar överallt är ett funktionellt krav, som jag ser det – det har att göra med hur funktionen ska ”funka’.
Trots det skulle ovanstående exempel kunna vara taget från i princip vilken kravspec som helst.
Inte konstigt att IT-bolag levererar kajko lösningar när det blir viktigare att tillgängliggöra en sökfunktion än att leverera nån typ av nytta.
Ett typiskt ickefunktionellt krav borde, enligt mitt sätt att se det, vara ett överordnat krav som säkerställer nyttan i systemet. Ett ickefunktionelt krav är ”användarna ska kunna hitta relevant material oavsett var de befinner sig på webbplatsen”. Eller ”webbplatsen ska minska behovet av telefonsupport med 1500 samtal om dygnet”.
Sedan drar man streck från dessa övergripande och målstyrande krav och till allt detdär som belamrar en normal kravspec men som borde vara en del av systemspecifikationen – beskrivning av hur man ska möta kraven.
*skakar på huvudet*
Men vad vet jag.
Det finns säkert nån bra anledning till att man gör sådär.
Fast andelen lyckade IT-projekt totalt sett får mej att tvivla…
Pella Bergquist
Ylva Betinakis
Maria
Christer Rindebäck
Hej!
För mig som är utvecklare känns dessa gränser rätt tydliga (och det är väl det som är problemet…)
Funktionellt krav: Funktion som en utvecklare behöver bygga (eller hitta något som någon redan byggt)
Icke funktionellt krav: Allt annat, tex sånt som gör att man nå de funktionella funktionerna
Nån behöver väl bygga detdär som gör att de fantastiskt funktionella funktionerna kan nås, också?
Sökfunktionen ska inte bara fungera, den ska ligga i sidhuvudet, och någon måste bygga den visningen.
Dethär är precis i gränslandet mellan traditionell systemutveckling och frontend/gränssnittsutveckling, där det senare inte ses som ”riktig” utveckling och därför hanteras styvmoderligt i metodik och genomförande.
De ”ickefunktionella” krav man har att hantera handlar idag allt oftare om tillgänglighet och användbarhet, som har tydliga kopplingar till arkitekturella ställningstaganden men också anger hur man ska utveckla, och då blir det ännu tydligare att benämningen inte riktigt stämmer.
Tycker jag.
Ett typexempel på vad som kan hända är att utvecklarna läser alla funktionella krav, för det är ju de kraven som berör dem, eller hur, men hoppar över de ickefunktionella ”för dom har ju bara med färg o sånt att göra” och däför missar de kravet ”tjänsten ska vara tillgänglig för användare med olika funktionsnedsättningar”, något som vi ju alla vet i allra högsta grad påverkar utvecklarna.
Jag tror helt enkelt att det inte råder någon som helst konsensus om vad som är ett ickefeunktionellt respektive funktionellt krav. Folk bara tittar på malarna och tänker ”jaha, nu gäller det att chansa rätt”.
Stoppa in allt i samma dokument så försvinner i allafall DET problemet.
Jag kan hålla med om att det finns en gråzon mellan funktionella och icke funktionella krav men i många (de flesta) fallen är det ganska klart vilket som är vilket. Det är svårt att hitta ett bättre namn, men jag har sett begreppet ”arkitekturella krav” som jag nog föredrar.
Mitt förslag är att använda andra bättre rubriker som inte kan missförstås. Användbarhet. Tekniska krav. Prestanda m.m.
Mats