varför affärs-och funktionskrav är avgörande för ett projekts framgång

i en produktutvecklingsprocess är en av de viktigaste aspekterna av ett projekts framgång att få kraven rätt. Och många projekt misslyckas eftersom intressenter inte förstår skillnaden mellan affärskrav och funktionella krav.

den ultimata framgången och misslyckandet av något projekt beror på kvaliteten på kraven. Även om det sällan anges så enkelt, misslyckas de flesta mjukvaruprojekt på grund av att mindre tonvikt läggs på kravhantering.

i September 1999 förlorade NASA sin $125 miljoner Mars Climate Orbiter när den försökte komma in i banan, bara 100 kilometer för nära Mars. Uppdraget misslyckades på grund av dålig kravhantering: det diskuterades inte tidigare i scenen om ’navigationsprogramvaran’ krävde metriska enheter eller kejserliga enheter.

resultatet: inkompatibla SPECIFIKATIONER; attitydkontrollsystemet specificerades med imperial-enheter men dess navigationsprogramvara använde metriska enheter.

således, att få kraven rätt och utnyttja dem till fullo är avgörande för ett projekts framgång.

inom mjukvaruutveckling ökar betydelsen och relevansen av ordet ’krav’ med den växande populariteten hos smidiga mjukvaruutvecklingsmetoder. Även en av de punkter som nämns i Agile manifest förklarar metodiken som en som värderar:

”fungerande programvara över omfattande dokumentation”

att få kraven rätt är avgörande, oavsett om du arbetar med Agile eller Waterfall methodology.

Business vs funktionella krav-Definition och dess typer

innan vi gräva djupare i affärskrav vs funktionella krav låt oss titta på definitionen och typer.

enligt International Institute of Business Analysis är ett krav:

• ett villkor eller förmåga som en intressent behöver för att lösa ett problem eller uppnå ett mål.
• ett villkor eller förmåga som måste uppfyllas eller innehas av ett system eller systemkomponent för att uppfylla ett kontrakt, standard, specifikation eller andra formellt införda dokument.
• en dokumenterad representation av ett tillstånd eller förmåga som i (1) eller (2)

baserat på problemdomänen och den metod som en affärsanalytiker (BA) arbetar med är följande de olika kraven, varav de viktigaste är: affärskrav och funktionskrav.

i den här bloggen kommer vi att undersöka skillnaden mellan affärskrav och funktionskrav. Det är absolut nödvändigt att förstå skillnaden så att vi erbjuder verksamheten en idealisk lösning som verkligen kommer att ta hand om problemet.

Vad är affärskrav

Varför behöver en klient en app?

denna information kan låta onödig för många eftersom kunden är redo att betala dig för att bygga en app. Så varför skulle det vara viktigt för dig att få orsakerna?

Tja, om du brinner för att bygga kvalitetsprodukter och leverera sömlösa upplevelser till dina kunder, bör du bry dig om ’whys’ lika mycket som du gör om ’whats’ och ’hows.’

och när du börjar fokusera på ’varför’ – delen av ett projekt betyder det att du tar hand om affärskraven.

affärskrav för mjukvaruutveckling livscykel handlar om krav på hög nivå eller önskemål från en organisation, vilket gör att verksamheten kan uppnå sina slutmål, vision och mål.

de beskriver vanligtvis vad ett system eller en lösning ska göra. De ger omfattningen av ett affärsbehov eller ett problem som bör åtgärdas av ett visst projekt eller en uppgift.

affärskrav exempel

ParcelKiosk är en av våra kunder som kontaktade oss för att få en webbapplikation designad och utvecklad för att erbjuda bättre paketleveranstjänster till kunder. När de närmade oss började vi diskussionen med en viktig parameter: analysera affärsbehoven.

Vad tror du att affärskravet kan vara för denna webbapptjänst för paketleverans?

du kan komma med en viktig parameter som säkerhet. Men även om säkerhet är en viktig faktor är det inte ett affärskrav. Du behöver inte bygga en tjänst som ParcelKiosk utan säkerhet i åtanke, men att skapa tjänsten bara för att ge säkerhet-är inte slutmålet.

vad sägs om att ansluta en rad budtjänster och kunder?

detta är bättre meningsfullt som ett affärskrav jämfört med säkerhet eftersom det beskriver vad tjänsten kommer att göra. Men är det anledningen till att webbtjänsten byggs, eller är det verkligen en funktion av tjänsten?

här är några möjliga orsaker (affärskrav) för att bygga ParcelKiosk:

• erbjuda en smartare lösning för att mäta, välja och skicka paket
• ge möjligheter att spåra och hantera sina leverans-och hämtningstjänster
• leverans i tid och kundfeedback

ser du skillnaden mellan att ansluta en rad budtjänster och kunder eller säkerhet och de faktiska affärskraven?

följande punkter kan noteras här w.r. t affärskrav:

• affärskraven skrivs alltid ur kundens synvinkel.
• de är breda systemkrav på hög nivå men ändå detaljorienterade.
• de är inte organisatoriska mål utan hjälper en organisation att uppnå sina mål. Genom att uppfylla dessa affärskrav uppnår organisationen sina breda mål.

det är helt klart nu att affärskraven förklarar’ varför ’del av ett projekt: ’varför’ ett visst projekt behöver byggas, dvs. vilka fördelar organisationen syftar till att uppnå genom genomförandet av ett specifikt projekt.

Business Requirements Document (BRD)

ett business Requirements Document beskriver affärsbehoven på hög nivå. Den primära målgruppen för en BRD är kunden och användarna. Affärskraven dokumenteras i BRD. Ett välskrivet dokument om affärskrav hjälper till att uppnå det önskade målet att bygga en framgångsrik produkt inom den angivna tidsgränsen.

den har följande element:

• projektets vision
• projektets mål
• projektets sammanhang eller bakgrund
• projektets omfattning
• identifiering av intressenter
• detaljerade affärskrav
• lösningens omfattning
• projektbegränsningar: Tidsram, kostnaden för projektet och tillgängliga resurser

affärskrav Dokumentexempel – varför Chrysler PT Cruiser märktes ’Hero to Zero’

Chrysler Group fokuserade inte mycket på BRD och fortsatte med produktionen av deras PT Cruiser, vilket resulterade i många huvudvärk för organisationen. Låt oss ta en titt på hur deras affärskrav dokument misslyckades:

• identifiering av intressenter: Chrysler Group identifierade de flesta intressenterna ganska bra. De var ombord med leverantörer och produktionsteamet för PT Cruiser. De två viktiga intressenterna som de saknade inkluderade dock slutkunden som köpte fordonet och återförsäljarna som sålde Kryssaren.
• Projektbegränsningar: Chrysler gjorde ett bra jobb när det gällde intressenter på toppnivå som levererade och övervakade byggnaden. Men vad de missade ifrågasatte tidslinjen för produktion, svarade på kundernas frågor eller av återförsäljarna som pris, modelltillgänglighet och efterfrågan.

Antag att Chryslers BRD inkluderade alla intressenters krav, de oförutsedda förseningarna i produktleveransen (målet att leverera bilar till återförsäljare senast 2001) kunde ha blivit svängda i god tid före produktionen, och slutanvändarnas behov skulle ha varit motiverade.

Tips för att skriva en affärskrav dokumentmall (BRD)

nu när du har en grundläggande förståelse för vad en BRD ska åstadkomma, kan du följa nedanstående tips för att se till att du skriver ett utestående affärskrav dokument.

• öva starka krav elicitation
• använd vanligt språk utan passiv röst och jargong
• forskning tidigare projekt
• validera dokumentationen
• integrera visuella

Vad är funktionella krav

funktionella krav, som namnet antyder, beskriva funktionerna i programvara eller programvara en produkt. Det här är de funktioner som systemet måste utföra för att uppfylla affärskraven.

de innehåller tekniska detaljer, beräkningar, datamanipulation och bearbetning och annan speciell funktionalitet som kännetecknar vad ett ramverk ska uppnå.

om du inte har tydliga funktionella krav för att förstå projektets tekniska egenskaper, kommer du under projektet inte att kunna svara på om besluten från utvecklings – /design – /testteamen är korrekta.

”att inte skriva en spec är den enskilt största onödiga risken du tar i ett mjukvaruprojekt.”~Joel Spolsky

om en funktionell detalj är feljusterad till affärsmålen kan det leda till att projektet misslyckas.

funktionskrav exempel

en av de stora FMCG-aktörerna kontaktade Net Solutions för ett utvecklingsprojekt för mobilappar som kunde förbättra effektiviteten i deras leveranskedja.

denna FMCG-jätte startade ett projekt 2001, som syftade till att stärka landsbygdskvinnor genom att skapa möjligheter för dem att sälja produkter och tjäna försörjning.

kunden ville att vårt projektteam skulle göra om sin befintliga mobilapp på ett sätt som skulle automatisera deras leveranskedja och beställningsprocessen genom att föra landsbygdskvinnorna och distributörerna till en enda digital plattform.

de syftade till att förbättra antagningsgraden, digitalt möjliggöra entreprenörerna och lösa friktionen i den befintliga kundresan (alla dessa är affärskrav).

när det gäller funktionskrav började vi diskutera de nödvändiga appfunktionerna med klienten, som var:

• Integration med tredjepartsleverantörer
• lageruppdateringar i realtid
• orderplacering

kunden antog att dessa funktioner skulle räcka för att lösa friktionen i den aktuella kundresan och därigenom förbättra antagningsgraden.

men när vi diskuterade de funktionella kraven med vår klient insåg vi att om vi inte identifierar friktionen i en befintlig kunds resa och mäter den digitala läskunnigheten för de nya appanvändarna, skulle det vara meningslöst att utveckla en app.

lösningen som Net Solutions levererade

vi tillämpade Design Thinking-metoden och genomförde etnografisk forskning för att bedöma entreprenörernas digitala beredskap och förstå luckorna i resan för den befintliga appens användare.

vi tillbringade en dag med alla intressenter för att ytterligare identifiera sina problem.

med hjälp av Design Thinking-metoden kunde vi ta reda på vilka funktioner som skulle gå i den nya appen. Dessutom fick detta tillvägagångssätt vår klient att förstå att det bästa sättet att gå vidare med projektledningen är att genomföra det på ett ’fasat sätt’.

resultatet:

den etnografiska forskningen och kartläggningen inom vår design thinking – metodik hjälpte oss att bygga en ny app med funktioner som designats och validerats av intressenterna som i slutändan kommer att använda den-vilket gör den till ett av de anmärkningsvärda funktionella kravexemplen.

följande punkter kan noteras här med funktionella krav:

• funktionella krav skrivs alltid ur systemets och intressenternas synvinkel.
• funktionella kravspecifikationer är mycket mer detaljerade.
• det är genom uppfyllandet av de funktionella kraven som en effektiv lösning som uppfyller kundens affärsbehov och mål utvecklas.

därför förklarar funktionskraven hur en del av ett projekt, dvs. programvarukraven och hur lösningen ska kunna tillgodose organisationens behov.

funktionella kravdokument

funktionella kravdokument beskriver de funktioner som krävs för att uppnå affärsbehoven. Dessa funktioner dokumenteras i dokumentet funktionella krav (FRD) eller dokumentet funktionella kravspecifikationer (FRS).

en välskriven FRD visar varje processflöde för varje aktivitet och kopplar samman beroenden.

FRD innehåller följande element:

• projektets syfte
• projektets omfattning
• detaljerade funktionella krav
• antaganden/begränsningar
• Representation av funktionella krav med hjälp av informationsarkitektur

Tips för att skriva en funktionell Kravdokumentmall (FRD)

skapa ett dokument som enlists de tekniska funktioner som krävs för en framgångsrik leverans av en programvara/produkt är precis som att skriva ett meddelande till alla inblandade teammedlemmar om de tekniska uppgifter du vill att de ska utföra.

följande tips skulle hjälpa dig att skriva en effektiv funktionella krav dokument:

• dubbelkolla dina fakta
• Använd enkelt språk
• Lägg till illustrationer eller diagram
• Observera tidsramar

affärskrav vs funktionskrav: viktiga utmaningar att skriva ett dokument

det är en stor utmaning att skriva ”bra” eller ”giltiga” affärs-och funktionskrav. De vanligaste utmaningarna som uppstår när man bygger dessa kravdokument inkluderar:

• en ofullständig förståelse av kravet, utan att begära förtydligande.
• felaktig tolkning av kravet; tillämpa personliga filter på den information som förändrar avsikten.
• skriva om implementering (hur) istället för krav (vad).
• genomförandebeslut bör skjutas upp till så sent som möjligt i Kravutlösningsprocessen.
• använda felaktig meningsstruktur.
• vikten av att bedöma kravkvalitet i mjukvaruproduktutveckling.

vilka är icke-funktionella krav?

icke-funktionella krav definierar och specificerar systemets funktion. Det påverkar dock inte systemets funktionalitet som namnet antyder. Därför kan systemet fortsätta att fungera även om dess icke-funktionella krav inte uppfylls. Anledningen till att icke-funktionella krav är väsentliga är på grund av deras användbarhet och eftersom de hjälper till att bestämma faktorer som påverkar användarupplevelsen.

vad som skiljer funktionella och icke-funktionella krav är att medan den förra bestämmer produktegenskaper och användarkrav, fokuserar den senare på produktegenskaper och användarnas förväntningar.

affärskrav vs funktionella krav – slutsats

från ovanstående jämförelse är det uppenbart att kraven är ryggraden i varje företag. Både affärs-och funktionskrav utgör grunden för effektiv affärsanalys. Affärskrav förklarar ”varför” och ” vad ”för ett projekt, och de funktionella kraven förklarar” hur ” för projektet.

en periodisk översyn och benchmarking av de (utvecklade) funktionella kraven med affärskraven säkerställer projektets övergripande framgång. Här är ett avslutande uttalande som kommer att gå långt för att hjälpa dig att tydligt skilja affärskrav från funktionella krav – utgångspunkten för varje affärsanalys är att förstå kundens affärskrav (vad och varför) och omvandla dem till funktionella krav (hur).