hvorfor forretnings-og funktionskrav er afgørende for et projekts succes

i en produktudviklingsproces er et af de vitale aspekter af ethvert projekts succes at få kravene rigtige. Og mange projekter mislykkes, fordi interessenter ikke forstår forskellen mellem forretningskrav og funktionelle krav.

den ultimative succes og fiasko for ethvert projekt afhænger af kvaliteten af kravene. Selvom det sjældent er sagt så enkelt, mislykkes de fleste programmer på grund af mindre vægt på kravstyring.

i September 1999 mistede NASA sin $125 millioner Mars Climate Orbiter, da den forsøgte at komme ind i kredsløb, kun 100 kilometer for tæt på Mars. Missionen mislykkedes på grund af dårlig kravstyring: det blev ikke diskuteret tidligere på scenen, om ‘navigationsprogrammet’ krævede metriske enheder eller kejserlige enheder.

resultatet: inkompatible SPECIFIKATIONER; holdningskontrolsystemet blev specificeret ved hjælp af imperial-enheder, men dets navigationsprogram brugte metriske enheder.

således er det afgørende for et projekts succes at få kravene rigtigt og udnytte dem i videst muligt omfang.

inden for programmelproduktudvikling er betydningen og relevansen af ordet ‘krav’ stigende med den voksende popularitet af agile programmeludviklingsmetoder. Selv et af de punkter, der er nævnt i Agile Manifesto, forklarer metoden som en, der værdsætter:

“arbejdsprogram over omfattende dokumentation”

at få kravene rigtige er kritisk, uanset om du arbejder i Agile eller vandfald metode.

Business vs funktionelle krav – Definition og dens typer

før vi graver dybere ned i forretningskrav vs funktionelle krav lad os se på definitionen og typerne.

ifølge International Institute of Business Analysis er et krav:

• en betingelse eller evne, som en interessent har brug for til at løse et problem eller nå et mål.
• en betingelse eller kapacitet, der skal opfyldes eller besiddes af et system eller en systemkomponent for at opfylde en kontrakt, standard, specifikation eller andre formelt pålagte dokumenter.
• en dokumenteret repræsentation af en tilstand eller evne som i (1) eller (2)

baseret på problemdomænet og den metode, som en forretningsanalytiker (BA) arbejder med, er følgende de forskellige krav, hvoraf de vigtigste er: forretningskrav og funktionelle krav.

i denne blog vil vi undersøge forskellen mellem forretningskrav og funktionelle krav. Det er bydende nødvendigt at forstå forskellen, så vi tilbyder virksomheden en ideel løsning, der virkelig tager sig af problemet.

Hvad er forretningskrav

Hvorfor har en klient brug for en app?

disse oplysninger lyder muligvis unødvendige for mange, fordi klienten er klar til at betale dig for at oprette en app. Så hvorfor skulle det være vigtigt for dig at få grundene?

Nå, hvis du brænder for at opbygge kvalitetsprodukter og levere sømløse oplevelser til dine kunder, så skal du bekymre dig om ‘hvorfor’ lige så meget som du gør om ‘hvad’ og ‘hvordan’.’

og når du begynder at fokusere på ‘hvorfor’ – delen af et projekt, betyder det, at du tager dig af forretningskravene.

business krav til udvikling livscyklus omhandler høje krav eller ønsker af en organisation, som gør det muligt for virksomheden at nå sine endelige mål, vision og mål.

de beskriver normalt, hvad et system eller en løsning skal gøre. De giver omfanget af et forretningsbehov eller et problem, der skal løses af et bestemt projekt eller en opgave.

eksempel på forretningskrav

ParcelKiosk er en af vores kunder, der henvendte sig til os for at få en internetapplikation designet og udviklet til at tilbyde bedre pakkeleveringstjenester til kunder. Da de nærmede os, startede vi diskussionen med en vigtig parameter: analyse af forretningsbehov.

hvad tror du, at forretningskravet kan være for denne pakkeleveringstjeneste?

du kan komme med en vigtig parameter som sikkerhed. Men selvom sikkerhed er en afgørende faktor, er det ikke et forretningskrav. Du behøver ikke bygge en tjeneste som ParcelKiosk uden sikkerhed i tankerne, men at skabe service bare af hensyn til at yde sikkerhed—er ikke det endelige mål.

hvad med at forbinde en række kurertjenester og kunder?

dette giver bedre mening som et forretningskrav sammenlignet med sikkerhed, fordi det beskriver, hvad tjenesten vil gøre. Men er det grunden til at få internettjenesten bygget, eller er det virkelig en funktion af tjenesten?

her er nogle mulige årsager (forretningskrav) til at bygge ParcelKiosk:

• tilbyde en smartere løsning til at måle, vælge og sende pakker
• Giv kapaciteter til at spore og styre deres leverings-og afhentningstjenester
• levering til tiden og kundefeedback

kan du se forskellen mellem at forbinde en række kurertjenester og kunder eller sikkerhed og de faktiske forretningskrav?

følgende punkter kan noteres her med forretningskrav:

• forretningskravene er altid skrevet ud fra kundens synspunkt.
• de er brede systemkrav på højt niveau, men alligevel detaljerede.
• de er ikke organisatoriske mål, men hjælper en organisation med at nå sine mål. Ved opfyldelsen af disse forretningskrav opnår organisationen sine brede mål.

det er helt klart nu, at forretningskravene forklarer ‘hvorfor’ – delen af et projekt: ‘hvorfor’ et bestemt projekt skal bygges, dvs. hvilke fordele organisationen sigter mod at opnå gennem opfyldelsen af et specifikt projekt.

Forretningskravsdokument (BRD)

et Forretningskravsdokument beskriver forretningsbehov på højt niveau. Den primære målgruppe for en BRD er kunden og brugerne. Forretningskravene er dokumenteret i BRD. Et velskrevet forretningskravsdokument hjælper med at nå det ønskede mål om at opbygge et vellykket produkt inden for den fastsatte frist.

det har følgende elementer:

• projektets vision
• projektets mål
• projektets kontekst eller baggrund
• projektets omfang
• Interessentidentifikation
• detaljerede forretningskrav
• løsningens omfang
• projektbegrænsninger: Tidsramme, projektets omkostninger og tilgængelige ressourcer

eksempel på forretningskrav – hvorfor Chrysler PT Cruiser blev tagget ‘helt til nul’

Chrysler Group fokuserede ikke meget på BRD og gik videre med produktionen af deres PT Cruiser, hvilket resulterede i mange hovedpine for organisationen. Lad os se på, hvordan deres forretningskravsdokument mislykkedes:

• Stakeholders Identification: Chrysler Group identificerede de fleste af interessenterne ret godt. De var om bord med leverandører og produktionsteamet for PT Cruiser. De to vigtige interessenter, de savnede, omfattede imidlertid slutkunden, der købte køretøjet, og forhandlerne, der solgte krydseren.
• Projektbegrænsninger: Chrysler udførte et godt stykke arbejde, når det gjaldt interessenter på øverste niveau, der leverede og overvågede bygningen. Det, de gik glip af, var imidlertid at stille spørgsmålstegn ved tidslinjen for produktion, besvare kundernes forespørgsler eller forhandlerne som pris, modeltilgængelighed og efterspørgsel.

Antag, at Chryslers BRD omfattede alle interessenternes krav, de uforudsete forsinkelser i produktleverancen (mål om at levere biler til forhandler inden 2001) kunne have været påvirket i god tid før produktionen, og slutbrugernes behov ville have været berettiget.

Tips til at skrive en skabelon til forretningskrav (BRD)

nu hvor du har en grundlæggende forståelse af, hvad en BRD skal opnå, kan du følge nedenstående tip for at sikre dig, at du skriver et fremragende forretningskravsdokument.

• Øv stærke krav fremkaldelse
• brug almindeligt sprog uden passiv stemme og jargon
• Forskning tidligere projekter
• Valider dokumentationen
• Integrer visuals

Hvad er funktionelle krav

funktionelle krav, som navnet antyder, beskriver funktionaliteterne i programmel eller et produkt. Dette er de funktioner, som systemet skal udføre for at opfylde forretningskravene.

de omfatter tekniske detaljer, beregninger, datamanipulation og behandling og anden særlig funktionalitet, der karakteriserer, hvad en ramme skal opnå.

hvis du ikke har klare funktionelle krav til at forstå projektets tekniske karakter, vil du under projektet ikke være i stand til at svare på, om de beslutninger, der træffes af udviklings – /design – /testteamene, er korrekte.

“at undlade at skrive en spec er den største enkeltstående unødvendige risiko, du tager i et programprojekt.”~ Joel Spolsky

hvis en funktionel detalje er forkert justeret til forretningsmålene, kan det resultere i projektets fiasko.

eksempel på funktionelle krav

en af de store FMCG-spillere henvendte sig til Net Solutions til et udviklingsprojekt for mobilapps, der kunne forbedre effektiviteten i deres forsyningskæde.

denne FMCG-gigant startede et projekt i 2001, der havde til formål at styrke kvinder i landdistrikterne ved at skabe muligheder for dem at sælge produkter og tjene til livets ophold.

klienten ønskede, at vores projektteam skulle genoprette deres eksisterende mobilapp på en måde, der ville automatisere deres forsyningskæde og bestillingsprocessen ved at bringe landdistrikterne kvinder og distributører på en enkelt digital platform.

de havde til formål at forbedre adoptionshastigheden, digitalt muliggøre iværksættere og løse friktionen i den eksisterende kunderejse (alt dette er forretningskrav).

når det kommer til funktionelle krav, begyndte vi at diskutere de nødvendige appfunktioner med klienten, som var:

• Integration med tredjepartsleverandører
• lageropdateringer i realtid
• ordreafgivelse

klienten antog, at disse funktioner ville være nok til at løse friktionen i den aktuelle kunderejse og derved forbedre adoptionsgraden.

men mens vi diskuterede de funktionelle krav med vores klient, indså vi, at medmindre vi identificerer friktionen i en eksisterende kundes rejse og måler de digitale læsefærdigheder for de nye appbrugere, ville det være meningsløst at udvikle en app.

den løsning, som Net Solutions leverede

vi anvendte Designtænkningstilgangen og udførte etnografisk forskning for at vurdere iværksætternes digitale beredskab og forstå hullerne i rejsen for den eksisterende apps brugere.

vi tilbragte en dag med alle interessenter for yderligere at identificere deres problemer.

ved hjælp af Design Thinking-tilgangen var vi i stand til at finde ud af, hvilke funktioner der skulle gå i den nye app. Desuden fik denne tilgang vores klient til at forstå, at den bedste måde at gå videre med projektledelsen er at udføre den på en ‘trinvis måde’.

resultatet:

den etnografiske forskning og rejsekortlægning inden for vores designtænkningsmetode hjalp os med at opbygge en ny app med funktioner designet og valideret af de interessenter, der i sidste ende skal bruge den – hvilket gør det til et af de bemærkelsesværdige funktionelle kraveksempler.

følgende punkter kan noteres her med funktionelle krav:

• funktionelle krav er altid skrevet ud fra systemets og interessenternes synspunkt.
• funktionelle krav specifikation er langt mere detaljeret.
• det er gennem opfyldelsen af de funktionelle krav, at der udvikles en effektiv løsning, der opfylder kundens forretningsbehov og mål.

derfor forklarer de funktionelle krav ‘hvordan’ en del af et projekt, dvs.programmelkravene, og hvordan løsningen vil være i stand til at imødekomme organisationens behov.

dokument om funktionelle krav

dokumentet om funktionelle krav beskriver de funktioner, der kræves for at nå forretningsbehovet. Disse funktioner er dokumenteret i dokumentet om funktionelle krav (FRD) eller dokumentet om funktionelle kravspecifikationer (FRS).

en velskrevet FRD viser hver processtrøm for hver aktivitet, der forbinder afhængighederne.

FRD indeholder følgende elementer:

• Projektets formål
• projektets omfang
• detaljerede funktionelle krav
• antagelser/begrænsninger
• repræsentation af de funktionelle krav ved hjælp af informationsarkitektur

tip til skrivning af en skabelon til funktionelle krav (FRD)

oprettelse af et dokument, der hverver de tekniske funktioner, der er nødvendige for en vellykket levering af et program/produkt, er ligesom at skrive en besked til alle de involverede teammedlemmer om de tekniske opgaver, du vil have dem til at udføre.

følgende tips vil hjælpe dig med at skrive en effektiv funktionelle krav Dokument:

• dobbelttjek dine fakta
• brug simpelt sprog
• Tilføj illustrationer eller diagrammer
• Overhold tidsrammer

forretningskrav vs funktionelle krav: nøgleudfordringer ved at skrive et dokument

det er en stor udfordring at skrive “gode” eller “gyldige” forretnings-og funktionelle krav. De mest almindelige udfordringer, der opstår under opbygningen af disse kravdokumenter, inkluderer:

• en ufuldstændig forståelse af kravet, undlader at bede om afklaring.
• forkert fortolkning af kravet; anvendelse af personlige filtre på de oplysninger, der ændrer hensigten.
• skrivning om implementering (hvordan) i stedet for krav (hvad).
• Gennemførelsesbeslutninger bør udsættes til så sent et punkt i processen med fremkaldelse af krav som muligt.
• brug af forkert sætningsstruktur.
• betydningen af at vurdere krav kvalitet i produktudvikling.

hvad er ikke-funktionelle krav?

ikke-funktionelle krav definerer og specificerer systemets drift. Det påvirker dog ikke systemets funktionalitet, som navnet antyder. Derfor kan systemet fortsætte med at udføre, selvom dets ikke-funktionelle krav ikke er opfyldt. Årsagen til, at ikke-funktionelle krav er væsentlige, er på grund af deres anvendelighed, og da de hjælper med at bestemme faktorer, der påvirker brugeroplevelsen.

hvad der adskiller funktionelle og ikke-funktionelle krav er, at mens førstnævnte beslutter produktegenskaber og brugerkrav, fokuserer sidstnævnte på produktegenskaber og brugerforventninger.

forretningskrav vs funktionelle krav – konklusion

fra ovenstående sammenligning er det klart, at kravene er rygraden i enhver virksomhed. Både forretnings-og funktionelle krav danner grundlaget for effektiv forretningsanalyse. Forretningskrav forklarer” hvorfor “og” hvad “af et projekt, og de funktionelle krav forklarer” hvordan ” af projektet.

en periodisk gennemgang og benchmarking af de (udviklede) funktionelle krav med forretningskravene sikrer den samlede succes for et projekt. Her er en afsluttende erklæring, der vil gå langt i at hjælpe dig med klart at skelne forretningskrav fra funktionelle krav – udgangspunktet for enhver forretningsanalyse er at forstå kundens forretningskrav (hvad og hvorfor) og omdanne dem til funktionelle krav (hvordan).