waarom Business and Functional Requirements are Vital for a Project’ s Success

37% in September 1999 verloor NASA zijn $125 miljoen Mars Climate Orbiter toen het de baan probeerde te betreden, slechts 100 kilometer te dicht bij Mars. De missie faalde door slecht requirements management: er werd niet eerder in het stadium besproken of de ‘navigatiesoftware’ metrische eenheden of keizerlijke eenheden nodig had.

het resultaat: incompatibele SPECIFICATIES; het standregelsysteem werd gespecificeerd met behulp van imperiale eenheden, maar de navigatiesoftware gebruikte metrische eenheden.

daarom is het voor het succes van een project van cruciaal belang om de juiste vereisten te krijgen en ze zo volledig mogelijk te gebruiken.

op het gebied van softwareproductontwikkeling neemt het belang en de relevantie van het woord “vereisten” toe met de toenemende populariteit van agile softwareontwikkelingsmethoden. Zelfs een van de punten genoemd in het Agile Manifest verklaart de methodologie als een die waarden:

“werken software over uitgebreide documentatie”

het is van cruciaal belang om de juiste eisen te stellen, of u nu werkt in Agile-of Watervalmethodologie.

Business vs Functional Requirements-Definition and its Types

voordat we dieper graven in Business Requirements vs Functional Requirements laten we eens kijken naar de definitie en types.

volgens het International Institute of Business Analysis is een vereiste::

• een voorwaarde of capaciteit die een stakeholder nodig heeft om een probleem op te lossen of een doel te bereiken.
• een voorwaarde of mogelijkheid waaraan een systeem of systeemcomponent moet voldoen om te voldoen aan een contract, norm, specificatie of andere formeel opgelegde documenten.
• een gedocumenteerde weergave van een toestand of mogelijkheid zoals in (1) of (2)

gebaseerd op het probleemdomein en de methodologie waarmee een Business analist (BA) werkt, zijn de volgende verschillende vereisten, waarvan de belangrijkste zijn: business requirements en functional requirements.

In deze blog zullen we het verschil onderzoeken tussen business requirements en functional requirements. Het is noodzakelijk om het verschil te begrijpen, zodat wij bieden het bedrijf een ideale oplossing die echt zal zorgen voor het probleem.

Wat zijn zakelijke vereisten

Waarom heeft een cliënt een app nodig?

deze informatie kan voor velen onnodig klinken omdat de client klaar is om u te betalen om een app te bouwen. Dus, waarom zou het voor jou belangrijk zijn om de redenen te krijgen?

nou, als u gepassioneerd bent over het bouwen van kwaliteitsproducten en het leveren van naadloze ervaringen aan uw klanten, dan moet u zich net zoveel zorgen maken over het ‘waarom’ als over het ‘wat’ en het ‘hoe’.’

en wanneer u zich begint te concentreren op het ‘waarom’ deel van een project, betekent dit dat u zorgt voor de zakelijke behoeften.

Business Requirements for software development life cycle heeft betrekking op high-level eisen of wensen van een organisatie, die het bedrijf in staat stelt om zijn einddoelstellingen, visie en doelen te bereiken.

ze beschrijven gewoonlijk wat een systeem of oplossing zou moeten doen. Ze geven de omvang van een zakelijke behoefte of een probleem dat moet worden aangepakt door een bepaald project of taak.

Business Requirements voorbeeld

ParcelKiosk is een van onze klanten die ons benaderde om een webapplicatie te laten ontwerpen en ontwikkelen om betere pakketbezorgdiensten aan klanten aan te bieden. Toen ze ons benaderden, begonnen we de discussie met een belangrijke parameter: het analyseren van de bedrijfsbehoeften.

wat denkt u dat de zakelijke behoefte zou kunnen zijn voor deze Web app Service voor pakketbezorging?

u kunt een belangrijke parameter als beveiliging vinden. Echter, hoewel veiligheid is een vitale factor, het is niet een zakelijke eis. U hoeft niet bouwen van een dienst als ParcelKiosk zonder veiligheid in het achterhoofd, maar het creëren van dienst alleen maar omwille van het verstrekken van veiligheid—is niet het einddoel.

hoe zit het met het verbinden van een reeks koeriersdiensten en klanten?

dit is logischer als een zakelijke eis in vergelijking met beveiliging, omdat het beschrijft wat de Dienst zal doen. Echter, is dat de reden voor het krijgen van de webservice gebouwd, of is het echt een functie van de dienst?

hier zijn enkele mogelijke redenen (zakelijke vereisten) om ParcelKiosk te bouwen:

• een slimmere oplossing bieden voor het meten, selecteren en verzenden van pakketten
• mogelijkheden bieden voor het volgen en beheren van hun bezorg-en ophaaldiensten
• tijdige levering en feedback van klanten

ziet u het verschil tussen het verbinden van een reeks koeriersdiensten en klanten of beveiliging en de werkelijke zakelijke behoeften?

de volgende punten kunnen hier worden opgemerkt met betrekking tot zakelijke vereisten:

• de zakelijke vereisten worden altijd geschreven vanuit het oogpunt van de klant.
• het gaat om algemene systeemvereisten van hoog niveau, maar toch op details gericht.
• het zijn geen organisatorische doelstellingen, maar helpen een organisatie bij het bereiken van haar doelstellingen. Door het voldoen aan deze zakelijke vereisten, bereikt de organisatie haar brede doelstellingen.

het is nu duidelijk dat de zakelijke vereisten het ‘waarom’ deel van een project verklaren: ‘waarom’ een bepaald project moet worden gebouwd, d.w.z. welke voordelen De organisatie wil bereiken door de uitvoering van een specifiek project.

Business Requirements Document (BRD)

een Business Requirements Document beschrijft de zakelijke behoeften op hoog niveau. De primaire doelgroep van een BRD is de klant en de gebruikers. De business requirements zijn vastgelegd in de BRD. Een goed geschreven business requirements document helpt het gewenste doel van het bouwen van een succesvol product binnen de gestelde termijn te bereiken.

het heeft de volgende elementen:

• de visie van het project
• doelstellingen van het project
• Context of achtergrond van het project
• reikwijdte van het project
• Stakeholderidentificatie
• gedetailleerde zakelijke vereisten
• reikwijdte van de oplossing
• projectbeperkingen: Time Frame, Cost of the Project, and Available resources

Business Requirements Document Example-Why Chrysler PT Cruiser was Tagged ‘Hero to Zero’

Chrysler Group richtte zich niet veel op BRD en ging door met de productie van hun PT Cruiser, wat leidde tot veel hoofdpijn voor de organisatie. Laten we eens kijken naar hoe hun business requirements document mislukt:

• stakeholders identificatie: Chrysler Group identificeerde de meeste stakeholders vrij goed. Ze waren aan boord met verkopers en het productieteam van de PT Cruiser. De twee belangrijke belanghebbenden die zij echter misten, waren de eindklant die het voertuig kocht en de dealers die de Cruiser verkochten.
• Projectbeperkingen: Chrysler heeft goed werk verricht als het ging om stakeholders op topniveau die de bouw leverden en er toezicht op hielden. Echter, wat ze misten was het in vraag stellen van de tijdlijn voor de productie, het beantwoorden van vragen van klanten of van de dealers zoals prijs, model beschikbaarheid, en de vraag.Als Chrysler ’s BRD alle vereisten van de stakeholders bevatte, hadden die onvoorziene vertragingen in de levering van het product (doel om auto’ s tegen 2001 aan de dealer te leveren) ruim voor de productie kunnen worden beïnvloed en zouden de behoeften van de eindgebruikers gerechtvaardigd zijn geweest.

  

  

  Tips voor het schrijven van een Business Requirements Document Template (BRD)

  Nu u een basiskennis hebt van wat een BRD moet bereiken, kunt u de onderstaande tips volgen om ervoor te zorgen dat u een uitstekend business requirement document schrijft.

  • praktijk sterke vereisten elicitatie
  • gebruik Gewone Taal zonder passieve stem en jargon
  • onderzoek uit het verleden
  • Valideer de documentatie
  • integreer visuals

  Wat zijn functionele vereisten

  functionele vereisten, zoals de naam al doet vermoeden, beschrijven de functionaliteiten van software of een product. Dit zijn de functies die het systeem moet uitvoeren om aan de zakelijke vereisten te voldoen.

  zij omvatten technische details, berekeningen, gegevensmanipulatie en-verwerking, en andere specifieke functies die kenmerkend zijn voor wat een raamwerk moet bereiken.

  als u geen duidelijke functionele vereisten hebt om de technische aspecten van het project te begrijpen, kunt u tijdens het project niet antwoorden of de beslissingen van de ontwikkelings – /ontwerp – /testteams juist zijn.

  “het niet schrijven van een specificatie is het grootste onnodige risico dat u neemt in een softwareproject.”~Joel Spolsky

  als een functioneel detail verkeerd is afgestemd op de bedrijfsdoelstellingen, kan dit resulteren in het mislukken van het project.

  

  

  functionele vereisten voorbeeld

  een van de grote FMCG-spelers benaderde Net Solutions voor een ontwikkelingsproject voor mobiele apps dat de efficiëntie in hun toeleveringsketen zou kunnen verbeteren.

  deze FMCG-Reus startte in 2001 een project dat erop gericht was plattelandsvrouwen mondiger te maken door hen kansen te bieden om producten te verkopen en in hun levensonderhoud te voorzien.

  

  de klant wilde dat ons projectteam hun bestaande mobiele app opnieuw zou doen op een manier die hun supply chain en het bestelproces zou automatiseren door plattelandsvrouwen en distributeurs op één digitaal platform te brengen.

  ze hadden tot doel het adoptiepercentage te verbeteren, de ondernemers digitaal in staat te stellen en de wrijving in de bestaande customer journey op te lossen (dit zijn allemaal zakelijke vereisten).

  als het gaat om functionele vereisten, zijn we begonnen met het bespreken van de vereiste app-functies met de client, die waren:

  • integratie met externe leveranciers
  • real-time voorraadupdates
  • orderplaatsing

  de klant ging ervan uit dat deze functies voldoende zouden zijn om de wrijving in de huidige customer journey op te lossen, waardoor het acceptatiepercentage werd verbeterd.

  echter, tijdens het bespreken van de functionele vereisten met onze klant, realiseerden we ons dat het ontwikkelen van een app zinloos zou zijn, tenzij we de wrijving in de reis van een bestaande klant identificeren en de digitale geletterdheid voor de nieuwe app-gebruikers meten.

  de oplossing die Net Solutions leverde

  we hebben de Design Thinking-benadering toegepast en etnografisch onderzoek uitgevoerd om de digitale bereidheid van ondernemers te beoordelen en de hiaten in het traject van de gebruikers van de bestaande app te begrijpen.

  we brachten een dag door met alle belanghebbenden om hun problemen verder te identificeren.

  door gebruik te maken van de Design Thinking-benadering, konden we achterhalen welke functies in de nieuwe app zouden moeten gaan. Bovendien heeft deze aanpak onze klant duidelijk gemaakt dat de beste manier om verder te gaan met het projectmanagement is om het op een ‘gefaseerde manier’uit te voeren.

  

  

  het resultaat:

  het etnografisch onderzoek en journey mapping binnen onze design thinking methodologie hebben ons geholpen een nieuwe app te bouwen met functies die zijn ontworpen en gevalideerd door de stakeholders die het uiteindelijk gaan gebruiken – waardoor het een van de opmerkelijke voorbeelden van functionele vereisten is.

  de volgende punten kunnen hier worden opgemerkt met betrekking tot functionele eisen:

  • functionele eisen worden altijd geschreven vanuit het oogpunt van het systeem en de stakeholders.
  • de specificatie van functionele eisen is veel gedetailleerder.
  • door het vervullen van de functionele vereisten wordt een effectieve oplossing ontwikkeld die voldoet aan de zakelijke behoeften en doelstellingen van de klant.

  vandaar dat de functionele eisen het ” hoe ” deel van een project verklaren, dat wil zeggen de software-eisen en hoe de oplossing aan de behoeften van de organisatie kan voldoen.

  functionele vereisten Document

  het functionele vereisten Document schetst de functies die nodig zijn om aan de bedrijfsbehoeften te voldoen. Deze functies worden gedocumenteerd in het Functional Requirements Document (FRD) of het Functional Requirements Specifications (FRS) document.

  een goed geschreven FRD toont elke processtroom voor elke activiteit, waarbij de afhankelijkheden met elkaar worden verbonden.

  FRD bevat de volgende elementen:

  • doel van het project
  • reikwijdte van het project
  • gedetailleerde functionele vereisten
  • aannames/beperkingen
  • representatie van de functionele vereisten met behulp van informatiearchitectuur

  Tips for Writing a Functional Requirements Document Template (FRD)

  teamleden over de technische taken die u zou willen dat ze uit te voeren.

  de volgende tips helpen u bij het schrijven van een effectief Functional Requirements Document:

  • Controleer uw feiten
  • gebruik eenvoudige taal
  • voeg illustraties of diagrammen toe
  • observeer termijnen

  Business Requirements vs Functional Requirements: Key uitdagingen bij het schrijven van een Document

  het is een grote uitdaging om “good” of “valid” business and functional requirements te schrijven. De meest voorkomende uitdagingen die worden ondervonden bij het bouwen van deze vereisten documenten omvatten:

  • een onvolledig begrip van de eis, zonder om verduidelijking te vragen.
  • onjuiste interpretatie van de eis; het toepassen van persoonlijke filters op de informatie die de bedoeling verandert.
  • schrijven over implementatie (het hoe) in plaats van vereisten (het wat).
  • uitvoeringsbesluiten moeten worden uitgesteld tot een zo laat mogelijk punt in het proces voor het uitlokken van vereisten.
  • met behulp van onjuiste zinsstructuur.
  • belang van het beoordelen van eisen kwaliteit in software productontwikkeling.

  

  

  Wat zijn niet-functionele vereisten?

  niet-functionele eisen definiëren en specificeren de werking van het systeem. Het heeft echter geen invloed op de functionaliteit van het systeem, zoals de naam al doet vermoeden. Daarom kan het systeem blijven presteren, zelfs als niet aan de niet-functionele eisen wordt voldaan. De reden waarom niet-functionele eisen essentieel zijn, is vanwege hun bruikbaarheid en omdat ze helpen bij het bepalen van factoren die van invloed zijn op de gebruikerservaring.

  wat functionele en niet-functionele eisen onderscheidt, is dat, terwijl de eerste de kenmerken van het product en de gebruikerseisen bepaalt, de laatste zich richt op de eigenschappen van het product en de verwachtingen van de gebruiker.

  Business Requirements vs Functional Requirements-Conclusion

  uit bovenstaande vergelijking is het duidelijk dat de requirements de ruggengraat van elk bedrijf vormen. Zowel zakelijke als functionele eisen vormen de basis van effectieve bedrijfsanalyse. Business requirements verklaren het “waarom” en “wat” van een project, en de functionele requirements verklaren het ” hoe ” van het project.

  een periodieke evaluatie en benchmarking van de (ontwikkelde) functionele eisen met de zakelijke eisen zorgen voor het algehele succes van een project. Hier is een slotverklaring die een lange weg zal gaan om u te helpen duidelijk onderscheid te maken tussen business requirements en functionele requirements – het uitgangspunt van elke bedrijfsanalyse is om de business requirements (wat en waarom) van de klant te begrijpen en om te zetten in functionele requirements (hoe).