Bedrijfsvereisten: ontwikkelings- en ontwerpvoorbeelden

2024 Auteur: Howard Calhoun | [email protected]. Laatst gewijzigd: 2023-12-17 10:36

Zakelijke vereisten zijn specificaties die, eenmaal verstrekt, waarde bieden en de kenmerken van het voorgestelde systeem beschrijven, vanuit het perspectief van de eindgebruiker. Het wordt ook wel een lijst met toepassingen van belanghebbenden genoemd. Producten, software en processen zijn manieren om te voorzien in en te voldoen aan de behoeften van een onderneming. Daarom worden zakelijke vereisten vaak besproken in de context van het ontwikkelen of verwerven van software of andere systemen.

Definitie

Terminologieverwarring ontstaat om drie hoofdredenen:

1. Het is gebruikelijk om doelen of verwachte voordelen te labelen als zakelijke vereisten.
2. Mensen hebben de neiging om deze term te gebruiken om te verwijzen naar de kenmerken van een product, systeem of software die zouden moetencreëren.
3. Een algemeen geaccepteerd model stelt dat de twee soorten claims alleen verschillen in het niveau van detail of abstractie - waar zakelijke vereisten hoog niveau zijn, vaak vaag en ontleed in gedetailleerde claims op een onderdeel.

Een dergelijk misverstand kan worden voorkomen door te erkennen dat het gegeven concept geen doelen is, maar ze eerder beantwoordt (dat wil zeggen, waarde biedt) wanneer ze tevreden zijn. Zakelijke vereisten vallen niet uiteen in producten, systemen en software. Integendeel, alles gebeurt andersom. Producten en hun toepassingen zijn een antwoord op zakelijke vereisten - vermoedelijk om daaraan te voldoen. Dit concept bestaat in de productieomgeving en moet worden ontdekt, terwijl de eisen aan het product door de mens worden bepaald. De eisen voor een businessplan zijn niet beperkt tot het bestaan van een hoog niveau, maar moeten tot in detail worden teruggebracht. Ongeacht de hoeveelheid details, bieden biedingen altijd waarde als ze worden voldaan.

Productupdate

Systeem- of softwareontwikkelingsprojecten voor kleine bedrijven vereisen doorgaans de autoriteit van belanghebbenden. Zij zijn het die leiden tot het maken of bijwerken van het product. Zakelijke vereisten voor een systeem en software bestaan doorgaans uit functionele en niet-functionele vereisten. Natuurlijk worden ze meestal gedefinieerd in combinatie met de eerste optie van productmogelijkheden. De tweede weerspiegelt vaak het ontwerp van zakelijke vereisten, die soms als beperkingen worden gezien. Ze kunnen de nodige aspecten bevattenprestatie of veiligheid van toepassing op productieniveau.

Proceshoogtepunten

Aanvragen worden vaak vermeld in officiële documenten. De nadruk ligt op het proces of de activiteit van het nauwkeurig plannen en ontwikkelen van zakelijke vereisten, in plaats van op hoe deze te bereiken. Deze parameter wordt meestal gedelegeerd door de specificatie of het document met systeemclaims of een andere optie. Er kan verwarring tussen de twee ontstaan als niet alle verschillen in aanmerking worden genomen. Daarom beschrijven veel whitepapers de vereisten voor een product, systeem of software.

Overzicht

Zakelijke vereisten in de context van softwareontwikkeling of de levenscyclus ervan is het concept van het identificeren en documenteren van gebruikers. Bijvoorbeeld, zoals klanten, medewerkers en leveranciers, in de vroege stadia van de systeemontwikkelingscyclus om het ontwerp van de toekomst te sturen. Aanvragen worden vaak geregistreerd door analisten. Zij zijn degenen die de vereisten van het bedrijfsproces analyseren en het vaak bestuderen "zoals het is" om het doel "toekomst" te bepalen.

Samenstelling van applicaties

Vereisten voor bedrijfsprocessen omvatten vaak:

1. Context, gebied en achtergrond, inclusief redenen voor wijzigingen.
2. Belangrijke belanghebbenden die vereisten hebben.
3. Succesfactoren voor toekomstige of doelconditie.
4. Beperkingen opgelegd door zakelijke of andere systemen.
5. Modellen en procesanalyse vaakstroomdiagrammen gebruiken om alles "zoals het is" weer te geven.
6. Logisch datamodel en woordenboekreferenties.
7. Woordenlijsten van zakelijke termen en lokaal jargon.
8. Diagrammen van de gegevensstroom om te illustreren hoe deze door informatiesystemen stroomt (in tegenstelling tot stroomdiagrammen die de algoritmische stroom van bedrijfsactiviteiten weergeven).

Rollen

Het meest populaire formaat voor het schrijven van zakelijke vereisten is een document. Het doel hiervan is om te bepalen welke resultaten van het systeem worden verlangd, maar het kan uiteindelijk zonder aanvullende voorwaarden worden ontwikkeld. Daarom worden de documenten aangevuld met referentiemateriaal waarin de technologische prestaties en infrastructuurverwachtingen worden beschreven, inclusief eventuele professionele vereisten met betrekking tot de kwaliteit van de dienstverlening, bijvoorbeeld prestaties, onderhoudbaarheid, aanpasbaarheid, betrouwbaarheid, beschikbaarheid, beveiliging en schaalbaarheid.

Volledigheid

Prototyping in een vroeg teststadium stelt u in staat om de volledigheid en nauwkeurigheid van de geïdentificeerde zakelijke vereisten te evalueren. Belanghebbenden doorlopen eerst het proces om de structuur te helpen bepalen. En het resultaat wordt verzonden naar de ontwikkelingsteams voor bedrijfsvereisten van het project, die het systeem bouwen. Andere belanghebbenden testen en evalueren de uiteindelijke uitgevouwen projectie. Duidelijkheid vereist het volgen van aanvragen en deze oplossen met een formeel proces om de juiste sjabloon te bepalen.

Omvang van zakelijke vereisten optioneelbeperkt tot het stadium van het definiëren van wat als een systeem moet worden gebouwd. Dit gaat verder dan het managen en onderhouden van een bestaande strategie. En om ervoor te zorgen dat het blijft aansluiten bij de bedrijfsdoelen. Het vereistendocument moet voortdurend op een gecontroleerde manier worden herzien. Het hebben van een gestandaardiseerd formaat, of sjablonen die zijn ontworpen voor specifieke zakelijke functies en domeinen, kan de volledigheid van query's garanderen, naast het gericht houden van de reikwijdte.

Prototype

Ondanks wat gewoonlijk wordt beschouwd als een hulpmiddel voor het beoordelen van vereisten, verschuift prototyping meestal de aandacht naar het product of systeem dat wordt gebouwd. Prototypes zijn werkende software, wat betekent dat ze bestaan uit drie fasen (biedingen, engineering of technisch ontwerp en implementatie) die zijn verwijderd van zakelijke vereisten. En dit zijn ook voorbeeldversies die de ontwikkelaar van plan is te implementeren.

Omdat prototypes vrij specifiek zijn, kunnen belanghebbenden die ze uitproberen zinvollere feedback geven over een bepaald aspect van wat de ontwikkelaar maakt, wat een interpretatie is van de tevredenheidsmodus. Bovendien is de grafische gebruikersinterface onderstreept en bevat de binnenkant snelkoppelingen. Ze vormen het grootste deel van de programmalogica en zijn waar aan de meeste zakelijke vereisten zal worden voldaan. Met andere woorden, de problemen die prototypes detecteren, hebben waarschijnlijk geen betrekking op verzoeken.

Ontwikkeling

Het is belangrijk om veranderingen in applicaties te herkennen,documenteren en bijwerken. Zakelijke vragen veranderen echter meestal niet zoveel als de perceptie ervan. Een bedrijfsvereiste kan aanwezig zijn, maar niet worden herkend of begrepen door belanghebbenden, analisten en het projectteam.

Veranderingen weerspiegelen meestal de beoogde manieren om te voldoen aan onvoldoende gedefinieerde inhoud. Veel van de moeilijkheid om aan zakelijke vereisten te voldoen, weerspiegelt in feite de gangbare praktijk om bijna alle inspanningen om hen heen te concentreren op wat echt het ontwerp op hoog niveau van een product, systeem of software is. Dit is te wijten aan het niet adequaat definiëren van zakelijke vereisten om eerst waarde te bieden.

Beoefenaars van ontwikkelaars blijven een product meestal opnieuw bezoeken totdat ze uiteindelijk "terugvallen" op een oplossing die lijkt te doen wat nodig is, dat wil zeggen, blijkbaar voldoet aan de productiebehoeften. Indirect vallen en opstaan om de zakelijke vereisten te bepalen, vormt de basis voor een groot deel van "iteratieve ontwikkeling", inclusief populaire methoden die worden aangeprezen als "best practices".

Ontwerpvoorbeelden

Sjablonen helpen je om snel specifieke onderwerpen te doorzoeken die vaak relevant kunnen zijn voor zoekopdrachten. Ze kunnen gestandaardiseerde documentatie met betrekking tot zakelijke vereisten maken, waardoor deze gemakkelijker te begrijpen is. Sjablonen bieden geen garantie voor de juistheid of volledigheid van zoekopdrachten. Vaak misbruikte voorbeelden negatiefonderzoek beïnvloeden omdat het de neiging heeft om oppervlakkigheid en meestal mechanische definitie te bevorderen zonder zinvolle analyse.

Moeilijkheden

Bedrijfsvereisten worden vaak voortijdig aangescherpt vanwege de grote basis van belanghebbenden die betrokken zijn bij het bepalen waar er potentieel voor belangenverstrengeling is. Het proces van regeren en het bereiken van consensus kan delicaat en zelfs politiek van aard zijn. Een minder moeilijke, maar vaak voorkomende uitdaging zijn gedistribueerde teams met belanghebbenden op verschillende geografische locaties. Uiteraard staat het verkooppersoneel dichter bij hun klanten, en de productie - bij de respectievelijke eenheden. Financiën en personeelsbeheer, inclusief senior management, dichter bij het hoofdkantoor.

Er zijn bijvoorbeeld zakelijke vereisten nodig voor een systeem waarbij gebruikers betrokken zijn bij verkoop en productie. Het kan een conflict van doelen tegenkomen - de ene kant is geïnteresseerd in het bieden van het maximale aantal functies, terwijl de andere zich zal concentreren op de laagste productiekosten. Dergelijke situaties eindigen vaak in consensus met maximale mogelijkheden voor redelijke, gunstige prijzen en distributie.

Om deze problemen aan te pakken, wordt vroegtijdige betrokkenheid van belanghebbenden bereikt door middel van prototypedemonstraties en samenwerking. Praktische workshops, zowel in de vorm van georganiseerde sessies als eenvoudige discussies, helpen om consensus te bereiken, vooral met betrekking tot gevoelige kwesties.zakelijke vereisten en waar een mogelijk belangenconflict bestaat. De complexiteit van het proces is een belangrijke factor. Dit kan gespecialiseerde kennis vereisen om de wettelijke of regelgevende vereisten, interne richtlijnen zoals branding of maatschappelijk verantwoord ondernemen te begrijpen. Analyse gaat niet alleen over het vastleggen van het 'wat' van een bedrijfsproces, maar ook over 'hoe' de context ervan te presenteren.