Hvorfor Forretnings-Og Funksjonelle Krav Er Avgjørende for Et Prosjekts Suksess

i en produktutviklingsprosess er et av de viktige aspektene ved et prosjekts suksess å få kravene riktig. Og mange prosjekter mislykkes fordi interessenter ikke klarer å forstå forskjellen mellom forretningskrav vs funksjonelle krav.

den ultimate suksess og fiasko for ethvert prosjekt avhenger av kvaliteten på kravene. Selv om det sjelden er sagt så enkelt, mislykkes de fleste programvareprosjekter på grunn av mindre vekt på kravstyring.

I September 1999 mistet NASA Sin $125 millioner Mars Climate Orbiter da DEN prøvde å gå inn i bane, bare 100 kilometer for nær Mars. Oppdraget mislyktes på grunn av dårlig krav ledelse: det ble ikke diskutert tidligere i scenen om ‘navigasjonsprogramvare’ nødvendig metriske enheter eller britiske enheter.

Resultatet: Inkompatible spesifikasjoner; attitude-control-systemet ble spesifisert ved hjelp av britiske enheter, men navigasjonsprogramvaren brukte metriske enheter.

dermed er det avgjørende for et prosjekts suksess å få kravene riktig og utnytte dem i størst mulig grad.

innen programvareproduktutvikling øker betydningen og relevansen av ordet ‘Krav’ med den økende populariteten til agile programvareutviklingsmetoder. Selv et av punktene nevnt I Agile Manifesto forklarer metodikken som en som verdier:

«Arbeider programvare over omfattende dokumentasjon»

Å få kravene riktig er avgjørende, enten du jobber Med Agile eller Waterfall-metodikk.

Business vs Funksjonelle Krav – Definisjon Og Dens Typer

før vi grave dypere Inn I Forretningskrav vs Funksjonelle Krav la oss se på definisjonen og typer.

Ifølge International Institute Of Business Analysis er et krav:

• en tilstand eller evne som trengs av en interessent for å løse et problem eller oppnå et mål.
• en betingelse eller evne som må være oppfylt eller besatt av et system eller systemkomponent for å tilfredsstille en kontrakt, standard, spesifikasjon eller andre formelt pålagte dokumenter.
• en dokumentert representasjon av en tilstand eller evne som i (1) eller (2)

Basert på problemdomenet og metodikken Som En Bedriftsanalytiker (BA) jobber med, er følgende de ulike kravene, hvorav de viktigste er: forretningskrav og funksjonskrav.

i denne bloggen vil vi utforske forskjellen mellom forretningskrav og funksjonelle krav. Det er viktig å forstå forskjellen slik at vi tilbyr virksomheten en ideell løsning som virkelig vil ta seg av problemet.

Hva Er Forretningskrav

Hvorfor trenger en klient en app?

denne informasjonen kan høres unødvendig for mange fordi klienten er klar til å betale deg for å bygge en app. Så hvorfor skal det være viktig for deg å få grunnene?

vel, Hvis du er lidenskapelig om å bygge kvalitetsprodukter og levere sømløse opplevelser til kundene dine, bør du bry deg om ‘whys’ så mye som du gjør om’ hva ‘ og ‘ hows.’

Og når du begynner å fokusere på’ hvorfor ‘ – delen av et prosjekt, betyr det at du tar vare på forretningsbehovene.

Forretningskrav for programvareutvikling livssyklus avtaler med høyt nivå krav eller ønsker av en organisasjon, som gjør det mulig for virksomheten å oppnå sine mål, visjon og mål.

de beskriver vanligvis hva et system eller en løsning skal gjøre. De gir omfanget av et forretningsbehov eller et problem som bør løses av et bestemt prosjekt eller en oppgave.

Eksempel På Forretningskrav

ParcelKiosk er en av våre kunder som kontaktet oss for å få en webapplikasjon designet og utviklet for å tilby bedre pakkeleveringstjenester til kunder. Da de nærmet seg oss, startet vi diskusjonen med en viktig parameter: analysere forretningsbehovene.

hva tror du forretningskravet kan være for denne pakken levering web app service?

Du kan komme opp med en viktig parameter som sikkerhet. Men selv om sikkerhet er en viktig faktor, er det ikke et forretningskrav. Du bygger ikke en tjeneste som ParcelKiosk uten sikkerhet i tankene, men å skape service bare for å gi sikkerhet-er ikke sluttmålet.

hva med å koble sammen en rekke budtjenester og kunder?

dette gir bedre mening som et forretningsbehov sammenlignet med sikkerhet fordi det beskriver hva tjenesten vil gjøre. Men er det grunnen til å få webtjenesten bygget, eller er det virkelig en funksjon av tjenesten?

her er noen mulige årsaker (forretningskrav) for å bygge ParcelKiosk:

• Tilby en smartere løsning for å måle, velge og sende pakker
• Gi muligheter til å spore og administrere leverings-og hentetjenester
• levering på tid og tilbakemeldinger fra kunder

ser du forskjellen mellom å koble til en rekke budtjenester og kunder eller sikkerhet og de faktiske forretningskravene?

følgende punkter kan noteres her w.r. t forretningskrav:

• forretningskravene er alltid skrevet fra klientens synspunkt.
• de er brede systemkrav på høyt nivå, men likevel detaljorienterte.
• de er ikke organisatoriske mål, men hjelper en organisasjon med å nå sine mål. Ved å oppfylle disse forretningskravene oppnår organisasjonen sine brede mål.

det er helt klart nå at forretningskravene forklarer hvorfor-delen av et prosjekt :hvorfor må et bestemt prosjekt bygges, dvs. hvilke fordeler organisasjonen har som mål å oppnå gjennom oppfyllelsen av et bestemt prosjekt.

Business Requirements Document (BRD)

Et Business Requirements Document beskriver forretningsbehovene på høyt nivå. DEN primære målgruppen FOR EN BRD er kunden og brukerne. Forretningskravene er dokumentert I BRD. Et godt skrevet forretningskrav dokument bidrar til å oppnå ønsket mål om å bygge et vellykket produkt innen den fastsatte fristen.

den har følgende elementer:

• prosjektets visjon
• Prosjektets mål
• Kontekst eller bakgrunn
• Prosjektets Omfang
• interessentidentifikasjon
• Detaljerte Forretningskrav
• Løsningens Omfang
• prosjektbegrensninger: Tidsramme, Kostnader For Prosjektet, Og Tilgjengelige ressurser

Business Krav Dokument Eksempel – Hvorfor Chrysler PT Cruiser Ble Merket’Hero To Zero’

Chrysler Group ikke fokusere mye PÅ BRD og gikk videre med produksjon av DERES PT Cruiser, noe som resulterer i mange hodepine for organisasjonen. La oss ta en titt på hvordan deres forretningskrav dokumentet mislyktes:

• Interessentidentifikasjon: Chrysler Group identifiserte de fleste interessentene ganske bra. De var om bord med leverandører og PRODUKSJONSTEAMET TIL PT Cruiser. De to viktige interessentene de savnet, inkluderte imidlertid sluttkunden som kjøpte kjøretøyet og forhandlerne som solgte Cruiser.
• Prosjektbegrensninger: Chrysler utførte en god jobb når det gjaldt interessenter på toppnivå som leverte og overvåket bygningen. Men det de savnet var å stille spørsmål ved tidslinjen for produksjon, svare på kundenes spørsmål eller forhandlerne som pris, modell tilgjengelighet og etterspørsel.

Anta At Chryslers BRD inkluderte alle interessentenes krav, de uforutsette forsinkelsene i produktleveransen (målet om å levere biler til forhandleren innen 2001) kunne ha blitt svekket i god tid før produksjonen, og sluttbrukernes behov ville vært berettiget.

Tips For Å Skrive En Forretningskravsdokumentmal (BRD)

Nå som du har en grunnleggende forståelse av hva EN BRD skal oppnå, kan du følge de nedenfor nevnte tipsene for å sikre at du skriver et fremragende forretningskravsdokument.

• Praksis sterke krav elicitation
• Bruk vanlig språk uten passiv stemme og sjargong
• Forskning tidligere prosjekter
• Validere dokumentasjonen
• Integrere visuelle

Hva Er Funksjonelle Krav

Funksjonelle Krav, som navnet antyder, beskrive funksjonaliteten til programvare eller et produkt. Dette er funksjonene som systemet må utføre for å oppfylle forretningskravene.

de inkluderer tekniske detaljer, beregninger, datamanipulering og behandling, og annen spesiell funksjonalitet som karakteriserer hva et rammeverk skal oppnå.

hvis du ikke har klare funksjonelle krav for å forstå prosjektets formalitet, vil du i løpet av prosjektet ikke kunne svare på om beslutningene fra utviklings – / design – / testteamene er riktige.

«Unnlatelse av å skrive en spec er den største unødvendige risikoen du tar i et programvareprosjekt.»~Joel Spolsky

hvis en funksjonell detalj er feiljustert til forretningsmålene, kan det føre til feil i prosjektet.

Eksempel På Funksjonskrav

en av DE store FMCG-aktørene nærmet Seg Nettløsninger for et mobilapputviklingsprosjekt som kunne forbedre effektiviteten i forsyningskjeden.

DENNE FMCG-giganten startet et prosjekt i 2001, som tok sikte på å styrke landlige kvinner ved å generere muligheter for dem til å selge produkter og tjene et levebrød.

kunden ønsket at prosjektteamet vårt skulle re-gjøre sin eksisterende mobilapp på en måte som ville automatisere forsyningskjeden og bestillingsprosessen ved å bringe landlige kvinner og distributører på en enkelt digital plattform.

de hadde som mål å forbedre adopsjonsraten, digitalt muliggjøre entreprenørene og løse friksjonen i den eksisterende kundereisen (alt dette er forretningskrav).

når det gjelder funksjonelle krav, begynte vi å diskutere de nødvendige appfunksjonene med klienten, som var:

• Integrasjon med tredjepartsleverandører
• sanntids lageroppdateringer
• ordreplassering

klienten antok at disse funksjonene ville være nok til å løse friksjonen i den nåværende kundereisen, og dermed forbedre adopsjonsraten.

men mens vi diskuterte funksjonskravene med kunden vår, innså vi at med mindre vi identifiserer friksjonen i en eksisterende kundes reise og måler digitale leseferdighetsnivåer for de nye appbrukerne, ville det være meningsløst å utvikle en app.

Løsningen Som Net Solutions Leverte

vi brukte Design Thinking-tilnærmingen og gjennomførte etnografisk forskning for å vurdere entreprenørens digitale beredskap og forstå hullene i reisen til de eksisterende appens brukere.

vi brukte en dag med alle interessenter for å identifisere sine problemer ytterligere.

Ved Hjelp Av Design Thinking-tilnærmingen kunne vi finne ut hvilke funksjoner som skulle gå i den nye appen. Videre, denne tilnærmingen gjort vår klient forstår at den beste måten å gå videre med prosjektledelse er å gjennomføre det i en ‘faset måte’.

Resultatet:

etnografisk forskning og journey mapping i vår design thinking-metodikk hjalp oss med å bygge en ny app med funksjoner designet og validert av interessentene som til slutt skal bruke den – noe som gjør den til en av de bemerkelsesverdige funksjonelle kraveksemplene.

følgende punkter kan noteres her w.r. t funksjonelle krav:

• Funksjonelle krav er alltid skrevet ut fra systemets synspunkt og interessenter.
• Funksjonskrav spesifikasjonen er langt mer detaljert.
• det er gjennom oppfyllelsen av funksjonelle krav at en effektiv løsning, som oppfyller kundens forretningsbehov og mål, utvikles.

derfor forklarer funksjonskravene hvordan-delen av et prosjekt, dvs. programvarekravene og hvordan løsningen vil kunne møte organisasjonens behov.

Dokument Om Funksjonskrav

Dokumentet Om Funksjonskrav beskriver funksjonene som kreves for å oppnå forretningsbehovene. Disse funksjonene er dokumentert I Functional Requirements Document (Frd) eller Functional Requirements Specifications (FRS) dokumentet.

en velskrevet FRD viser hver prosessflyt for hver aktivitet, og knytter sammen avhengighetene.

FRD inneholder følgende elementer:

• Formål med prosjektet
• prosjektets omfang
• Detaljerte funksjonskrav
• Forutsetninger/begrensninger
• Representasjon av funksjonskravene ved Hjelp Av Informasjonsarkitektur

Tips For Å Skrive En Dokumentmal For Funksjonskrav (FRD)

Opprette et dokument som verver de tekniske funksjonene som kreves for vellykket levering av en programvare/produkt, er Akkurat som å skrive en melding til alle involverte teammedlemmer om de tekniske oppgavene du vil at de skal utføre.

følgende tips vil hjelpe deg med å skrive et effektivt Funksjonskrav Dokument:

• Dobbeltsjekk fakta
• Bruk enkelt språk
• Legg til illustrasjoner eller diagrammer
• Følg tidsrammer

Forretningskrav vs Funksjonelle Krav: Viktige Utfordringer Ved Å Skrive Et Dokument

det er en stor utfordring å skrive «gode» eller «gyldige» forretnings-og funksjonskrav. De vanligste utfordringene som oppstår mens du bygger disse kravene dokumenter inkluderer:

• en ufullstendig forståelse av kravet, unnlater å be om avklaring.
• Uriktig tolkning av kravet; bruk av personlige filtre på informasjonen som endrer hensikten.
• Skrive om implementering (hvordan) i stedet for krav (hva).
• Implementeringsbeslutninger bør utsettes til så sent et punkt i Kravfremkallingsprosessen som mulig.
• Bruker feil setningsstruktur.
• Viktigheten av å vurdere kravkvalitet i programvareproduktutvikling.

Hva er ikke-funksjonelle krav?

Ikke-funksjonelle krav definerer og spesifiserer systemets drift. Det påvirker imidlertid ikke funksjonaliteten til systemet som navnet antyder. Derfor kan systemet fortsette å utføre selv om dets ikke-funksjonelle krav ikke er oppfylt. Grunnen til at ikke-funksjonelle krav er avgjørende er på grunn av deres brukervennlighet og siden de bidrar til å bestemme faktorer som påvirker brukeropplevelsen.

det som skiller funksjonelle og ikke-funksjonelle krav er at mens førstnevnte bestemmer produktegenskaper og brukerkrav, fokuserer sistnevnte på produktegenskaper og brukerforventninger.

Forretningskrav vs Funksjonelle Krav-Konklusjon

fra sammenligningen ovenfor er det klart at kravene er ryggraden i enhver bedrift. Både forretnings-og funksjonelle krav danner grunnlaget for effektiv forretningsanalyse. Forretningskrav forklarer» hvorfor «og» hva «av et prosjekt, og de funksjonelle kravene forklarer» hvordan » av prosjektet.

en periodisk gjennomgang og benchmarking av de (utviklede) funksjonelle kravene med forretningskravene sikrer total suksess for et prosjekt. Her er en avsluttende uttalelse som vil gå langt i å hjelpe deg med å tydelig skille forretningskrav fra funksjonelle krav – utgangspunktet for enhver forretningsanalyse er å forstå kundens forretningskrav (hva og hvorfor) og forvandle dem til funksjonelle krav (hvordan).