Funktionella och icke funktionella krav: Identifierar de behov som finns för en specifik produkt

Det övergripande slutmålet för de flesta typer av projekt är att kunna leverera en produkt av hög kvalitet som möter vart och ett av de krav som ställdes på produkten från början, om det så var av en kund eller av en annan uppdragsgivare. Precis som de flesta branscher och industrier så har också ingenjörer, programmerare och projektledare typiska ord och begrepp vilka kan vara förvirrande för experter så väl som för användare och nybörjare.

 

Två sådana begrepp är till exempel funktionella och icke funktionella krav, båda vilka ofta är med på kundens lista över olika behov som de har för en produkt. Funktionella och icke funktionella krav är en del av så kallad kravhantering, vilket är det arbete som system utför för att möta och uppfylla olika sorters behov som ställs på systemet i fråga. Kravhantering är en viktig aspekt av programmering och utveckling av programvara. Att förstå skillnaden mellan de funktionella och de icke funktionella sortens krav kan vara viktigt och till stor hjälp både för projektgruppen och den IT-ansvarige såväl som för kunden, eftersom att det då blir lättare för alla inblandade att förstå kraven.

En klar förståelse för funktionella och icke funktionella typer av krav kan leda till att man blir bättre på att ringa in och definiera sitt projekt, optimera kostnader och såklart också skapa gladare och nöjdare kunder. För att ett projekt ska gå vägen så måste det ha en logisk och komplett samling av både funktionella och icke funktionella krav. Samtliga krav måste vara ordentligt genomtänkta, balanserade och tydliga för alla som är en del av projektet, och det är därtill mycket viktigt att man inte ger upp eller släpper på vissa av kraven innan projektet är helt färdigt. Den här texten reder ut skillnaden mellan de funktionella och icke funktionella kraven.

Vad är Funktionella krav?

Inom programmering och utveckling av mjukvara så är ett funktionellt krav något som definierar ett system eller en komponent av ett system. En vedertagen definition av ett funktionellt krav är ”de tjänster och funktioner som ett system ska tillhandahålla sin användare”. Det funktionella kravet beskriver en funktion som en programvara måste kunna utföra, det vill säga hur ett specifikt system ska interagera med sina användare. Ett systems funktion är egentligen inget mer än en input, beteendet eller uppgiften och så outputen som skapas. Det kan exempelvis vara en beräkning, registrering av betalningar, en manipulation av data, en affärsprocess, interaktioner med användaren, eller någon något annat som definierar och bestämmer vilken typ av funktion som ett specifikt system ska utföra. I ett system så är det oftast de funktionella kraven som är de mest uppenbara att urskilja, vilket gör att det också oftast är dem som får mest uppmärksamhet i början av de flesta typer av projekt.

Exempel på funktionella krav

Här följer några exempel på vanliga typer av funktionella krav:

  • En användare som köper en biljett ska få en bekräftelse på sitt köp via e-post
  • Programvaran ska automatiskt validera kunder mot ett visst system
  • Försäljningssystemet ska tillåta sina användare att registrera kundens försäljning
  • Alla fönster i en viss applikation ska ha en blå bakgrundsfärg
  • Det är endast anställda på ledningsnivå som har rätt att se datan över intäkter
  • Programvarans system bör integreras ihop med bank-API

Andra vanliga funktionella krav inkluderar:

  • Företagsregler
  • Rättelser, ändringar och avbrott av transaktioner
  • Administrativa funktioner
  • Autentisering
  • Behörighetsnivåer
  • Granskning och spårning
  • Externa gränssnitt
  • Certifieringskrav
  • Rapporteringskrav
  • Historisk data
  • Juridiska krav

Fördelar med funktionella krav

  • De hjälper till att kontrollera om en applikation verkligen erbjuder alla de funktioner som nämndes i listan med de funktionella kraven för just den applikationen.
  • Ett dokument med de funktionella kraven hjälper till att definiera hur funktionellt eller användbart ett system eller en del av ett större system är.
  • Funktionella krav i kombination med en kravanalys hjälper till att identifiera krav som man missat eller glömt bort att inkludera. Det gör så att man man definiera de exakta förväntningarna för systemets funktioner, tjänster och beteende.
  • De fel som man lyckas upptäcka under tiden som man samlar ihop alla de funktionella kraven är oftast de lättaste och billigaste felen att rätta till.
  • De funktionella kraven verkar stöttande för ett projekts mål, uppgifter och aktiviteter och gör därmed projektledning enklare.

Vad är Icke funktionella krav?

En vanligt förekommande definition av icke funktionella krav inom programmering och utveckling av mjukvara är ”egenskaper som ett system bör uppfylla men som inte kan karaktäriseras som tjänster och funktioner, utan som har att göra med effektivitet, kapacitet och säljbarhet”. De icke funktionella kraven gör således precis det som namnet avslöjar, de beskriver inte en funktion som ett system har. Istället så definierar de icke funktionella kraven de egenskaper som ett system har som inte har att göra med vad systemet praktiskt kan utföra.

Sådana egenskaper kan till exempel vara användarvänlighet, tillförlitlighet, prestanda, tillgänglighet eller mer konkret hur snabbt en hemsida kan laddas. De icke funktionella kraven är grundläggande för att hela mjukvaran ska fungera som den ska, och om man misslyckas med att möta de icke funktionella kraven så kan det resultera i att systemet inte klarar av att möta kundens eller användarens förväntningar och behov.

Exempel på icke funktionella krav

De icke funktionella kraven är inte alltid lika enkla att förstå som de funktionella kraven, vilket framför allt beror på att de som sagt inte är lika uppenbara i ett system. De är dock minst lika viktiga, så här följer en något mer detaljerad beskrivning av olika exempel på icke funktionella krav:

  • Underhållsbarhet: I begreppet underhållsbarhet så ingår olika former av förvaltning inom systemet. Det kan till exempel vara förbättringar och korrigeringar av fel och systemets prestanda eller konfigurationer.
  • Flexibilitet: Flexibilitet gör så att man kan ändra ett helt system, till exempel bygga ut det. För att det ska bli så enkelt som möjligt så brukar man strukturera systemet i mindre delar, i så kallade komponenter, vilka sen är enkla att ändra och byta ut.
  • Utrustningsoberoende: När en organisation förändras, till exempel när dess struktur går från att vara en centraliserad till att vara en decentraliserad, eller om en organisation utvecklas och växer eller ingår ett partnerskap med en annan organisation så används den här typen av icke funktionella krav för att flytta programvara mellan olika enheter och plattformar. Därefter kan de olika systemen eller plattformarna arbeta tillsammans.
  • Återanvändbarhet: Den här typen av icke funktionella krav kommer till nytta när man längre fram i tiden kan behöva använda sig av gamla analyser, system, designs eller liknande igen. Det gör man för att spara pengar, eftersom att återanvändningen innebär att man till exempel inte behöver göra om samma analys på nytt. När man använder sig av en gammal analys så vet man också från början att den fungerar.
  • Interoperabilitet: Genom den här typen av icke funktionella krav så kan olika system kommunicera direkt med varandra.
  • Testbarhet: Testbarheten gör så att man kan se till så att ett specifikt system fungerar som det ska, vad gäller allt ifrån administrativa funktioner till tidsförlopp och synkronisering.
  • Effektivitet: Inom effektivitet så ingår även prestanda, vilken kan vara kopplad till et systems kapacitet och lagringsvolym, samt hastigheter för bearbetning och kommunikation.
  • Säkerhet: Dessa krav ger ett skydd mot obehörig åtkomst av systemets program och data.

Här följer några mer konkreta exempel på icke funktionella typer av krav:

  • Användare måste ändra sitt tilldelade lösenord direkt efter att de har loggat in för första gången. Det första lösenordet får aldrig användas igen.
  • Varje försök som inte fungerade när någon försöker komma åt en viss typ av data ska registreras.
  • En hemsida ska kunna hantera 20 miljoner användare utan att hemsidans prestation påverkas.

Kvalitetskrav

Det finns många ord som används synonymt med icke funktionella krav, vilka kan göra det enklare att förstå konceptet bättre. Några sådana synonymer är kvalitetsattribut, kvalitetsegenskaper och framför allt kvalitetskrav. Kvalitetskrav är en synonym som fångar in arbetet med de icke funktionella kraven väldigt bra. Det beror på att kraven i slutändan leder till en högre kvalitet, eftersom att syftet bakom användning av icke funktionella krav är att fånga upp de behov som finns på en specifik produkt eller på en viss verksamhet och sedan omvandla de till konkreta kvalitetshöjande krav. När man använder sig av ordet kvalitet i det här sammanhanget så brukar det vara viktigt att inkludera en beskrivning av vem som gör vad, när det ska göras, varför det behöver göras, vad det är som ska göras samt hur.

Fördelar med icke funktionella krav

  • De icke funktionella kraven säkerställer och garanterar att programvaran följer alla relevanta lagar och regler.
  • De icke funktionella kraven säkerställer och upprätthåller programvarans tillförlitlighet, tillgänglighet och prestanda.
  • De icke funktionella kraven skapar en bra användarupplevelse och gör därtill programvaran enkel att använda.

Tips för kravarbetet

Innan man har börjat arbeta med kravhantering så kan det kännas som en utmaning. Men om man låter det ta den tid det tar så kommer det att löna sig i längden. Det är ju viktigare att det blir rätt än att det går extra fort. När man introducerar kravarbetet i organisationen eller i ett viss projekt så är det viktigt att man belyser betydelsen med kraven och att man redan från början tar fram en given process som ska vägleda allt arbete när det kommer till att utveckla både de funktionella och de icke funktionella kraven. Därtill så bör man försöka att involvera och engagera så många relevanta individer som möjligt i det här arbetet. Det gäller även individer som kan visa sig vara användbara först längre fram i tiden, eftersom att de kan hjälpa till att se till så att kravarbetet även tar hänsyn till en potentiellt annorlunda framtid. Frågor så som hur snabbt de funktionella och de icke funktionella kraven ska arbeta, hur man hanterar säkerhet och hur man formulerar sina krav kan vara trixigt till en början men brukar klarna allt eftersom att man arbetar mer med kravhanteringen. Nedan följer två ytterligare tips för att komma igång med kravarbetet, framför allt när det gäller de icke funktionella kraven.

Skapa en prototyp

För att samla in sina icke funktionella krav så kan man börja med att bygga en prototyp. Då behöver man inte vänta ända tills produkten är helt färdig innan man kan ta emot feedback från kunden eller uppdragsgivaren, eller innan det blir tydligt vilka de icke funktionella kraven är. Om man istället väntar med att samla in kraven när produkten är nästan helt färdig så kommer eventuella ändringar eller justeringar att bli betydligt dyrare att utföra.

Lyssna på feedbacken

Att ta till sig av den feedback som man får från kunden eller från produktens slutanvändare är helt avgörande för att man ska kunna nå produktens fulla potential. Det gäller alla krav men tyngd bör ligga på de icke funktionella kraven eftersom att de som sagt ofta hamnar i skymundan och riskerar att glömmas bort.

De icke funktionella kraven innebär ofta begränsningar

De icke funktionella kraven verkar ofta begränsande när det gäller ett projekts utformande, design eller teknik. Samtidigt är det viktigt att ta hänsyn till hur de olika begränsningar som kraven kan skapa påverkar andra krav och eventuellt projektets övergripande tidsplan. Kraven bör alltid vara så specifika som möjligt.

Skillnaden mellan funktionella och icke funktionella krav

När man börjar arbeta med kravarbetet så kan det kännas onödigt eller svårt att separera mellan de funktionella kraven och de icke funktionella kraven. Men att skilja på de två koncepten och kategorierna av krav hjälper en att göra ett bättre jobb på flera olika sätt. Att ha en god förståelse för de olika sorternas krav gör att man i slutändan kan skapa en bättre produkt som så gott det går möter kundens behov och krav. Det är huvudsakligen med hjälp av de funktionella kraven som kunden kan kommunicera och förmedla sina behov till arbetsgruppen.

De funktionella kraven som förmedlas ser till att samla ihop arbetsgruppen så att alla arbetar i samma riktning mot samma målbild av en slutprodukt. Om man istället saknar det viktiga dokumentet som listar alla de funktionella kraven så är risken stor att ens slutprodukt inte lever upp till kundens förväntningar, eftersom att man antagligen har misslyckats med att definiera arbetet, produkten och dess omfång och detaljer. De icke funktionella kraven hjälper vidare till att ringa in de behoven som kunden har som inte är lika konkreta och tydliga. Tillsammans så hjälper de funktionella och de icke funktionella kraven till att hålla nere kostnaderna samtidigt som man kan producera en högkvalitativ produkt som kunden lär blir väldigt nöjd med.

Här är fler, lite mer distinkta skillnader mellan de funktionella och de icke funktionella kraven:

  • Ett funktionellt krav definierar ett system eller dess komponenter, medan ett icke funktionellt krav definierar en programvaras eller ett systems egenskaper eller prestationsattribut.
  • De funktionella kraven, ofta tillsammans med en kravanalys, hjälper till att identifiera krav som man har missat att inkludera medan de icke funktionella kraven hjälper en att höja användarvänligheten av programvaran.
  • Ett funktionellt krav är ofta ett verb medan ett icke funktionellt krav är en beskrivning eller ett attribut.

Så samlar man in sina krav

En av de bästa metoderna för att samla in både de funktionella och de icke funktionella kraven är genom en guidad brainstorming. Man bör bjuda in alla relevanta aktörer, kunder och användare för att delta i brainstormingen så att man inkluderar alla potentiella perspektiv och infallsvinklar.  Det är särskilt viktigt att bjuda in de användare som utgör den bästa informationskällan för de icke funktionella kraven. Man kan under brainstormingen vidare dela upp de funktionella kraven i fyra stycken grupper:

  • Affärs- och företagskrav: De här kraven inkluderar det slutgiltiga målet för projektet, så som till exempel en fysisk produkt, ett ordersystem eller en internetkatalog.
  • Administrativa funktioner: Dessa krav är de som definierar de mest rutinmässiga funktionerna så som rapportering, med mera.
  • Användningskrav: De här kraven är de som definierar vad en användare av systemet kan göra, så som att lägga in en order eller bläddra igenom internetkatalogen.
  • Systemkrav: Det här är exempelvis mjukvarans eller hårdvarans specifikationer, som definierar hur ett system ska svara eller agera.

När man har samlat in och specificerat de funktionella kraven så går man vidare till de icke funktionella kraven:

  • Användning: Den här kategorin av krav fokuserar på systemets utseende och hur människor kommer att interagera med det.
  • Pålitlighet/tillgänglighet: Hur ser kraven ut på tidsmässigt, det vill säga ska systemet fungera alla dygnets timmar?
  • Tillväxt: Kan systemet hantera ett växande behov?
  • Prestanda: Hur snabbt måste systemet kunna arbeta?

Slutsats

Funktionella och icke funktionella krav förmedlar och identifierar de behov som finns för en specifik produkt eller system, till exempel en programvara. De funktionella kraven är de som beskriver systemets funktioner och tjänster, det vill säga sådana saker som ett system i praktiken kan utföra. De icke funktionella kraven handlar istället om mer osynliga aspekter men som är minst lika viktiga, så som hur användarvänligt systemet är. Tillsammans så ser de olika kraven till så att man tar fram en produkt som möter kundens specifika behov och som lever upp till deras förväntningar.

Vera Kristen

Vera Kristen

Vera är Content Editor på Projektledning.se. Hon är utbildad inom projektledning, reklam och PR med en examen från Stockholms Universitet. Vera har arbetat som projektledare på flera företag.