Affärskrav

Affärskrav , även känd som intressentkravsspecifikationer (StRS), beskriver egenskaperna hos ett föreslaget system ur systemets slutanvändares synvinkel som en CONOPS . Produkter, system, mjukvara och processer är sätt att leverera, tillfredsställa eller uppfylla affärskrav. Följaktligen diskuteras affärskrav ofta i samband med utveckling eller upphandling av mjukvara eller andra system.

Förvirring uppstår av tre huvudsakliga skäl.

1. En vanlig praxis är att hänvisa till mål, eller förväntade fördelar, som "affärskrav."
2. Människor använder vanligtvis termen "krav" för att beskriva egenskaperna hos produkten, systemet, programvaran som förväntas skapas.
3. En allmänt känd modell hävdar att dessa två typer av krav endast skiljer sig åt i sin detaljnivå eller abstraktion - där "affärskrav" är högnivåiga, ofta vaga och bryts ner i de detaljerade produkt-, system- eller mjukvarukraven.

Sådan förvirring kan undvikas genom att inse att affärskrav inte är mål, utan snarare möter mål (dvs ger värde) när de är uppfyllda. Affärskrav vad som inte bryts ner till produkt-/system-/mjukvarukrav hur . Snarare representerar produkter och deras krav ett svar på affärskrav – antagligen hur man tillfredsställer vad . Affärskrav finns inom affärsmiljön och måste upptäckas, medan produktkrav är mänskligt definierade (specificerade). Affärskrav är inte begränsade till existens på hög nivå, utan måste drivas ner till detaljer. Oavsett deras detaljnivå är affärskraven alltid affärsmässiga leveranser, det som ger värde när de är uppfyllda; Att driva ner dem till detaljer förvandlar aldrig affärskrav till produktkrav.

I system- eller mjukvaruutvecklingsprojekt kräver affärskrav vanligtvis auktoritet från intressenter. Detta leder vanligtvis till skapandet eller uppdateringen av en produkt, ett system eller en programvara. Produkt-/system-/mjukvarakraven består vanligtvis av både funktionskrav och icke-funktionella krav . Även om de vanligtvis definieras i samband med produktens/systemets/programvarans funktionalitet (funktioner och användning), återspeglar icke-funktionella krav ofta en form av affärskrav som ibland anses vara begränsningar. Dessa kan inkludera nödvändiga prestanda, säkerhet eller säkerhetsaspekter som gäller på affärsnivå.

Affärskrav anges ofta i ett affärskravsdokument eller BRD. Tyngdpunkten i en BRD ligger på processen eller aktiviteten för att korrekt få tillgång till planering och utveckling av kraven, snarare än på hur man uppnår det; detta delegeras vanligtvis till en systemkravsspecifikation eller -dokument (SRS eller SRD), eller annan variant, såsom ett funktionsspecifikationsdokument. Förvirring kan uppstå mellan en BRD och en SRD när man bortser från distinktionen mellan affärskrav och systemkrav. Följaktligen beskriver många BRD faktiskt krav på en produkt, ett system eller en programvara.

Översikt

Affärskrav i samband med mjukvaruutveckling eller mjukvaruutvecklingslivscykeln , är konceptet att framkalla och dokumentera affärskrav från affärsanvändare som kunder, anställda och leverantörer tidigt i utvecklingscykeln för ett system för att vägleda framtidens design. systemet. Affärskrav fångas ofta upp av affärsanalytiker , som analyserar affärsaktiviteter och processer och ofta studerar "i befintligt skick"-process för att definiera en målprocess för "att vara".

Affärskrav inkluderar ofta

• Affärskontext, omfattning och bakgrund, inklusive skäl till förändring
• Viktiga affärsintressenter som har krav
• Framgångsfaktorer för en framtida/målstat
• Restriktioner som åläggs av verksamheten eller andra system
• Affärsprocessmodeller och analys, ofta med flödesschemanotationer för att skildra antingen "i befintligt skick" och "blivande" affärsprocesser
• Konceptuella datamodeller och dataordboksreferenser
• Ordlistor över affärstermer och lokal jargong
• Dataflödesdiagram för att illustrera hur data strömmar genom informationssystemen (till skillnad från flödesscheman som visar algoritmiskt flöde av affärsaktiviteter)

Ämnen för affärskrav

Fördelar

Beskrivning
Minska projektfel	Strukturerad förklaring av en affärsprocess eller metod som definierats tidigt i livscykeln hjälper till att minska projektmisslyckanden som uppstår på grund av felinriktade eller felaktiga krav som leder till misslyckande med användarnas förväntningar.
Kopplar till bredare affärsmål	Väldefinierade affärskrav hjälper till att lägga ut ett projektcharter, ett kritiskt steg i att genomföra affärsstrategi eller affärsmål, och att ta det till nästa logiska steg att utveckla det till ett IT-system. Detta hjälper till att övervaka projektets övergripande hälsa och ger positiv dragning med nyckelprojektintressenter inklusive sponsorer.
Konsensusskapande och samarbete	Fördelen med ett strukturerat format som är typiskt för affärskravsdokumentation hjälper till att skapa positiv samsyn och bättre samarbete där företagsintressentgruppen kan vara ett stort tvärfunktionellt team, fördelat geografiskt.
Sparar kostnader	God kvalitet på affärskrav när de fångas upp tidigt förbättrar inte bara framgången för ett projekt utan sparar också totala kostnader förknippade med ändringsförfrågningar och relaterade investeringar i utbildning, infrastruktur, etc.

Roller

Affärskrav definieras vanligtvis av affärsanalytiker i samarbete med andra projektintressenter .

Båda parter kan ansvara för att fastställa affärskraven och utveckla tekniska lösningar. Affärsanalytiker tenderar att vara involverade i att utveckla implementeringsmetoden och hantera inverkan på alla affärsområden, inklusive engagemang för intressenter och riskhantering.

Formatera

Traditionell BRD-struktur -
Titel Version Beskrivning av förändring Författare Datum Innehåll Introduktion Syfte Omfattning Bakgrund Referenser Antaganden och begränsningar Dokumentöversikt Metodik Funktionskrav Sammanhang Användarkrav Dataflödesdiagram Logisk datamodell / dataordbok Andra krav Gränssnittskrav Krav på datakonvertering Krav på hårdvara/mjukvara Driftskrav Bilaga A -

Det mest populära formatet för att registrera affärskrav är affärskravsdokumentet ( BRD). Avsikten bakom BRD är att definiera vilka resultat som skulle önskas av ett system, hur det så småningom kan utformas. Därför kompletteras BRD-dokument med ett systemreferensdokument (SRD) ELLER Technical Design Document (TDD) som beskriver design, teknisk prestanda och infrastrukturförväntningar, inklusive eventuella tekniska krav (icke-funktionella) som hänför sig till tjänstens kvalitet, såsom prestanda. , underhållsbarhet, anpassningsförmåga, tillförlitlighet, tillgänglighet, säkerhet och skalbarhet.

Fullständighet

Prototypframställning med testning i ett tidigt skede kan bedöma fullständigheten och noggrannheten hos infångade affärskrav. Intressenter kommer in tidigt för att hjälpa till att definiera kraven, och resultatet skickas till projektutvecklingsteamen som bygger affärssystemet; andra intressenter testar och utvärderar det slutgiltiga systemet. Tydlighet kräver att man håller reda på kraven och deras lösning, med en formell process för att bestämma lämplig mall användning. Omfattningen av affärskrav är inte nödvändigtvis begränsad till stadiet för att definiera vad som behöver byggas som ett affärssystem. Det går längre än att föreställa sig hur ett löpande affärssystem hanteras och underhålls, och att säkerställa att det bibehålls i linje med affärsmål eller strategi. Ett affärskravsdokument måste ständigt revideras på ett kontrollerat sätt. Att ha ett standardiserat format, eller mallar som är designade för specifika affärsfunktioner och domäner, kan säkerställa fullständighet i affärskraven, förutom att hålla omfattningen i fokus.

Även om det vanligtvis anses vara ett sätt att utvärdera krav, flyttar prototyper vanligtvis uppmärksamheten från affärskrav till produkten, systemet eller programvaran som byggs. Prototyper är fungerande mjukvara, vilket innebär att de är tre steg (produkt/system/mjukvarukrav, ingenjörsmässig/teknisk design av nämnda produkt/system/mjukvara och implementering av designen i programkod) borttagna från affärskraven. Prototyper är preliminära versioner av programvaran som utvecklaren avser att implementera. Eftersom prototyper är ganska konkreta kan intressenter som provar prototypen ge mer meningsfull feedback angående vissa aspekter av vad utvecklaren skapar, vilket är utvecklarens tolkning av ett sätt att tillfredsställa affärskraven, inte affärskraven. Dessutom, för att skapa en prototyp tidigt och snabbt, betonas det grafiska användargränssnittet (GUI) och "moten" är genväg. Magen är huvuddelen av programmets logik, och det är där de flesta affärskrav skulle tillgodoses. Med andra ord, frågor som prototyper avslöjar är mycket osannolikt att involvera affärskrav.

Det är viktigt att känna igen förändringarna av kraven, dokumentera dem och hålla definitionen av krav uppdaterad. Affärskraven tenderar dock inte att förändras så mycket som medvetenheten om dem. Ett affärskrav kan vara närvarande, men inte erkänns eller förstås av intressenter, analytiker och projektteam. Förändringar är mer påtagliga när det gäller vad som vanligtvis kallas "kravändringar" - kraven på produkten/systemet/mjukvaran. Dessa tenderar att återspegla de förmodade sätten att tillfredsställa otillräckligt identifierade affärskrav. Många av svårigheterna som tillskrivs att uppnå affärskrav återspeglar i själva verket den vanliga praxisen att ägna nästan alla "krav" ansträngningar åt vad som faktiskt är högnivådesign av en produkt, ett system eller en mjukvara. Detta beror på att inte först adekvat definiera de affärskrav som produkten/systemet/mjukvaran måste uppfylla för att ge värde. Utvecklingsmetoder fortsätter vanligtvis att revidera produkten/systemet/mjukvaran tills de så småningom "tillbaka till" en lösning som verkar göra det som behövs, dvs uppenbarligen tillgodoser ett affärsbehov. Sådana kostsamma försök och fel sätt att identifiera affärskrav är grunden för mycket av "iterativ utveckling", inklusive populära agila utvecklingsmetoder, som utses som "bästa praxis".

Mallar hjälper till att få frågor om särskilda ämnen som ofta kan vara relevanta för affärskrav. De kan främja standardiserad dokumentation om affärskrav, vilket kan underlätta förståelsen. Mallar säkerställer inte att affärskraven är riktiga eller fullständiga. Faktum är att mallar ofta missbrukas negativt påverkar kravforskningen, eftersom de tenderar att främja ytlighet och främst mekanisk definition utan meningsfull analys.

Svårigheter

Verksamhetens krav skärps ofta i förtid på grund av den stora intressentbas som är involverad i att definiera kraven, där det finns en potential för intressekonflikter. Processen att hantera och skapa konsensus kan vara känslig och till och med politisk till sin natur. En mindre utmaning, även om den är vanlig, är den med distribuerade team med intressenter på flera geografiska platser. Det är naturligt att säljarna är närmare sina kunder, medan produktionspersonalen är närmare tillverkande enheter; ekonomi och HR , inklusive ledande befattningshavare, ligger närmare det registrerade huvudkontoret. Ett system som till exempel involverar försäljnings- och produktionsanvändare kan se syftet med konflikter – en sida kan vara intresserad av att erbjuda maximala funktioner, medan den andra kan fokusera på lägsta produktionskostnad . Den här typen av situationer slutar ofta i en konsensus med maximala egenskaper för en rimlig, lönsam kostnad för produktion och distribution.

För att möta dessa utmaningar uppnås intressentköp i ett tidigt skede genom demonstration av prototyper och gemensamt arbete. Workshops för intressenter är vanliga, antingen som underlätta sessioner eller enkla diskussioner, för att hjälpa till att uppnå konsensus, särskilt för känsliga affärskrav och där det finns potentiella intressekonflikter. En affärsprocess komplexitet är en faktor. Detta kan innebära specialiserad kunskap som krävs för att förstå juridiska eller regulatoriska krav, interna företagsomfattande riktlinjer såsom varumärkesbyggande eller företags åtaganden om socialt ansvar. Analys av affärskrav handlar inte bara om att fånga "vad" i en affärsprocess tillsammans med "hur" för att tillhandahålla dess sammanhang. Översättning till att designa och bygga ett fungerande system kan behöva åtgärdas. I detta skede måste affärskrav erkänna tekniska detaljer och genomförbarhet.

En specialbyggd lösning krävs inte alltid för varje ny uppsättning affärskrav. Det finns ofta standardiserade processer och produkter, som med viss justering eller anpassning kan tjäna till att möta affärskraven. Målverksamhetssystemet begränsas ofta av ett specifikt teknikval, budget eller tillgängliga produkter som redan är implementerade.

Slutligen kan standardisering av format orsaka svårigheter. Flera projekt med flera format som leder till variation i struktur och innehåll i ett kravdokument gör dessa ineffektiva ur ett spårbarhets- och hanterbarhetsperspektiv. Faktum är att när man skapar en mall för användning i en tvärfunktionell kravinsamlingsövning kan olika roller med kompletterande kunskap ha svårt att arbeta inom ett gemensamt format. Det är därför avgörande att tillåta icke-specialister eller icke-experta intressenter att tillhandahålla ytterligare krav genom bilagor och ytterligare bilagor för att täcka deras specifikationsområde. Att ta itu med olika nyanser och komma fram till den bästa passformen är fortfarande den enskilt största utmaningen för effektiva krav.

Identifiera affärsbehov

Inkluderar följande steg:

1. Affärsdefinition
2. Förstå företagsdomän(er)
3. Organisationens mål
4. Kärnkompetens

Se även

• Systemutveckling livscykel
• Systemteknik
• Mjukvaruutvecklingsprocess
• Affärsanalytiker
• Programvarukravspecifikation
• Kravanalys
• Krav
• Prototypframställning
• Programvaruprototyper
• Affärsanalys

Bibliografi

• Beal, Adriana. Krav är vad vi måste göra för att uppnå ett mål www.bealprojects.com , 2012
• Goldsmith, Robin F. Upptäcker verkliga affärskrav för framgång i mjukvaruprojekt . Artech House, 2004.
• Robertson, Suzanne och James C. Robertson. Bemästra kravprocessen . 2:a upplagan, Addison-Wesley, 2006.