Wat is vereiste analyse en verzamelen in SDLC?

deze Tutorial legt uit wat eisen analyse, eisen analyse stappen, voorbeelden, en doelen van eisen verzamelen in SDLC:

Software ontwikkeling is een gigantische taak die een werkend software product creëert.

het softwareproduct wordt gebouwd volgens de eis van de klant. Meestal voldoet dit Softwareproduct aan wat de eindklant/gebruiker had verwacht, terwijl dit product soms niet volledig voldoet aan wat de klant/eindgebruiker had verwacht.

Wat is Eisenanalyse?

laat ons de vereiste analyse begrijpen aan de hand van een voorbeeld.

verwachtingen van klanten/eindgebruikers:

klant / eindgebruiker ontvangen:

omdat u op basis van de bovenstaande afbeeldingen kunt analyseren dat het eindproduct niet overeenkomt met de verwachtingen van de klant. Dit kan te wijten zijn aan talloze redenen, namelijk. onjuiste uitvoering van de eisen van de klant, foutief ontwerp, een verkeerd begrip van de eisen van de klant door programmeurs en kwaliteit team, enz.

echter, zoals u kunt zien, ongeacht de reden voor verkeerde levering van het product, de belangrijkste reden gaat naar de eis. Daarom, als de juiste vereiste begrip, vastleggen, implementatie, en testen werden gedaan, het zou hebben geholpen om de onjuiste en onvolledige levering van het product aan de klant/eindgebruiker te beperken.

een goede levering van een product vereist een correcte verzameling van eisen, een efficiënt onderzoek van de eisen die worden verzameld, en tot slot een duidelijke documentatie van eisen, als voorwaarde. Dit hele proces wordt ook wel als vereiste analyse in Software Development Life Cycle (SDLC)

vereiste analyse fasen / stappen

zoals u kunt zien, eis analyse is de eerste activiteit in SDLC gevolgd door functionele specificatie en ga zo maar door. Vereiste analyse is een essentiële stap in SDLC als het resoneert met acceptatie testen die cruciaal is voor de aanvaarding van het product door klanten.

In deze tutorial zullen we uitleggen hoe vereiste analyse wordt gedaan in SDLC. We zullen ook zien de verschillende stappen betrokken, resultaten, uitdagingen, en corrigerende maatregelen in de eis analyse.

vereiste analyse begint met:

1. eis verzamelen welk ook heet elicitation.
2. dit wordt gevolgd door een analyse van de verzamelde vereisten om de juistheid en haalbaarheid te begrijpen van het omzetten van deze vereisten in een mogelijk product.
3. en ten slotte het documenteren van de verzamelde vereisten.

#1) Vereisten verzamelen

om ervoor te zorgen dat alle hierboven genoemde stappen naar behoren worden uitgevoerd, moeten duidelijke, beknopte en correcte vereisten worden verzameld van de klant. De klant moet in staat zijn om hun eisen goed te definiëren en de business analist moet in staat zijn om het te verzamelen op dezelfde manier als de klant van plan is het over te brengen.

vaak is het niet mogelijk dat het verzamelen van vereisten efficiënt wordt gedaan door business Analisten van de klant. Dit kan te wijten zijn aan de afhankelijkheid van veel mensen met betrekking tot het verwachte eindproduct, Gereedschap, omgeving, enz. Het is dus altijd een goed idee om alle belanghebbenden die het eindproduct kunnen beïnvloeden of kunnen beïnvloeden, erbij te betrekken.

de mogelijke Stakeholdergroep zou kunnen zijn Software Quality engineers (zowel QC als QA), elke derde partij die ondersteuning zou kunnen bieden in het project, eindgebruiker voor wie het product bestemd is, softwareprogrammeurs, een ander team binnen de organisatie dat een module of softwareplatform zou kunnen leveren, softwarebibliotheken, enz. voor productontwikkeling.

voorbeeld: in een organisatie ontwikkelen ze een ADAS-product (surround-view camerasysteem voor een prestigieuze OEM) dat Autosar-stack-en Bootloader-binaire bestanden nodig heeft die van een andere leverancier worden ontvangen.

het betrekken van verschillende stakeholders bij de fase van het verzamelen van vereisten helpt om verschillende afhankelijkheden van elkaar te begrijpen en elk mogelijk toekomstig conflict kan worden voorkomen.

soms is het een goed idee om een prototype van het geplande product te maken en het aan de klant te laten zien. Dit is een uitstekende manier om klanten over te brengen welk product ze verwachten en hoe het er later uit kan zien. Dit helpt de klant bij het visualiseren van het product dat ze verwachten en helpt hen om te komen met duidelijke eisen.

dit prototype is afhankelijk van twee soorten product:

1. een soortgelijk product dat klanten bedoeld, bestaat binnen de organisatie.
2. nieuw te ontwikkelen product.

(i) in het eerste geval is het gemakkelijker om de klant te laten zien hoe het eindproduct eruit zou zien en hoe het zou worden ontwikkeld. In automotive ADAS is het mogelijk om klanten een ander product te laten zien dat al op de markt is en binnen de organisatie is ontwikkeld.

bijvoorbeeld, een surround-view Camerasysteem ontwikkeld voor een OEM (GM, Volkswagen, BMW, enz.) en kan aan een andere OEM worden getoond.

het is niet verstandig om product/proto-product aan de klant te tonen die in ontwikkeling is, omdat het een schending kan zijn van een geheimhoudingsovereenkomst die is ondertekend met een andere klant voor wie dat product wordt ontwikkeld. Het kan ook resulteren in een onnodige juridische strijd.

een ander voorbeeld is het door de organisatie ontwikkelde infotainmentsysteem dat reeds op de markt is. Business analisten en andere stakeholders binnen een organisatie kunnen een workshop demo plannen voor de klant, met infotainmentsystemen met tastbare HMI, device connector poorten, sandbox, enz.

dit zal de klant helpen om te begrijpen hoe het eindproduct eruit zou zien en zal de behoeften veel duidelijker weergeven.

(ii) het tweede geval kan worden bereikt door het creëren van een basiswerkmodel door eenvoudige codering en assemblage (meestal zijn functies hier hardcoded in softwareprogramma ‘ s), of door het creëren van een stroomdiagram of diagram dat de klant zou kunnen overtuigen hoe het product eruit zou zien.

in ieder geval zou het een adempauze zijn voor het proces van het verzamelen van vereisten, aangezien de klant nu weet wat hij wil.

de business analist kan nu formele bijeenkomsten organiseren, waar alle stakeholders kunnen worden uitgenodigd en zo de verschillende eisen van de klant kunnen noteren (in sommige gevallen, als er meer stakeholders zijn, kan een afzonderlijke schrijver worden aangesteld om de eisen van de klant of de verhalen van de gebruiker op te merken, zodat business analist zich kan concentreren op het modereren van de vergadering).

de verzamelde vereisten kunnen bestaan uit gebruikersverhalen (in agile ontwikkeling), use cases, documenten in de natuurlijke taal van de klant, diagrammen, stroomdiagrammen, enz. Gebruikersverhalen worden populair in de moderne levenscyclus van softwareontwikkeling. Gebruikersverhalen zijn in principe een set van input van klanten in hun natuurlijke taal.

vereisten verzamelen voorbeeld: in het ADAS surround-view Camerasysteem zou een mogelijk gebruikersverhaal kunnen zijn: “als gebruiker zou ik in staat moeten zijn om te zien wat er in de achteruitkijkspiegel van mijn auto zit”.

er zouden veel “waarom” vragen kunnen worden gesteld over elk verhaal van de gebruiker, die de klant zal helpen bij het verstrekken van meer gedetailleerde informatie over de eis.

in de bovenstaande gebruiker verhaal, als een klant zegt “als een gebruiker, Ik moet in staat zijn om te zien wat er in de achteruitkijkspiegel van mijn auto”, het stellen van een vraag “waarom” zou kunnen geven “als een gebruiker, Ik moet in staat zijn om te zien wat er in de achteruitkijkspiegel van mijn auto, zodat ik mijn auto veilig kan parkeren”.

het stellen van de vraag “waarom” helpt ook bij het creëren van objectieve en atomaire vereisten op basis van gigantische natuurlijke taalverklaringen van de klant. Dit kan eenvoudig later in de code worden geïmplementeerd.

een andere manier om de eis te verzamelen is in de vorm van use cases. Een use case is een stapsgewijze aanpak om een bepaald resultaat te bereiken. Dit vertelt niet hoe de software zal werken op de input van de gebruiker in plaats van het zegt, wat wordt verwacht van de input van de gebruiker.

voorbeeld:

#2) Analyse van verzamelde vereisten

na het verzamelen van vereisten, begint de analyse van vereisten. In dit stadium zitten verschillende stakeholders en doen ze een brainstormsessie. Ze analyseren de verzamelde eisen en zoeken naar haalbaarheid om ze te implementeren. Ze bespreken met elkaar en elke dubbelzinnigheid wordt opgelost.

deze stap is om de volgende hoofdredenen belangrijk in het proces voor het analyseren van vereisten:

i) de klant kan eisen stellen die vanwege verschillende afhankelijkheden onmogelijk kunnen worden geïmplementeerd.

voorbeeld: klanten kunnen vragen om het camerasysteem te surround-view met een achteruitkijkcamera-functie die helpt bij het parkeren van de auto. De klant kan ook vragen om de trekhaak functie die ook gebruik maakt van de achteruitrijcamera om te werken.

als de klant de eis stelt dat achteruitkijkcamera voor parkeerhulp te allen tijde zonder uitzondering moet werken, dan zou de Aanhangwagenfunctie nooit werken en omgekeerd.

(ii) een business analist zou de eis van de klant anders hebben begrepen dan hoe een programmeur zou hebben geïnterpreteerd.

omdat programmeurs als technische deskundigen denken, is het altijd mogelijk dat de eisen van de klant onjuist worden omgezet in functionele specificaties die later onjuist zullen worden omgezet in architectuurdocumenten en ontwerpdocumenten en vervolgens in code. De impact is exponentieel en moet dus worden gecontroleerd.

een mogelijke corrigerende maatregel zou kunnen zijn door het volgen van een agile methode van softwareontwikkeling, het volgen van use cases die de klant verstrekt, enz.

# 3) documenteren van geanalyseerde vereisten

zodra de analyse van de vereisten is uitgevoerd, begint de vereiste documentatie. Uit de analyse van de vereisten komen verschillende soorten eisen voort.

enkele hiervan zijn:

(i) specificatie van de klantbehoefte.

(ii) vereiste softwarearchitectuur.

voorbeeld:

(iii) vereiste softwareontwerp.

voorbeeld:

(iv) specificatie van functionele eisen (rechtstreeks afgeleid van klantspecificaties.)

voorbeeld: “wanneer de gebruiker op het Bluetooth-pictogram op Infotainment HMI tikt, moet het Bluetooth-scherm worden weergegeven”

(v) niet-functionele Eisenspecificatie (d.w.z. prestaties, stress, belasting, enz.).

voorbeeld: “het zou mogelijk moeten zijn 15 Bluetooth-apparaten te koppelen aan het infotainmentsysteem zonder de prestaties van het systeem te verminderen”.

(vi) vereisten voor de gebruikersinterface.

voorbeeld: “On the Tuner FM screen, a button should be provided to select different stations”

de bovenstaande vereisten worden vastgelegd en gedocumenteerd in requirement management tools, zoals IBM DOORS, HP QC. Soms hebben organisaties hun op maat gemaakte requirement management tools om de kosten te verlagen.

laten we nu kijken naar het proces van het omzetten van Business requirements naar Software Requirements (functioneel en niet-functioneel).

het omzetten van zakelijke vereisten naar softwarevereisten

zakelijke vereisten, zoals hierboven besproken, zijn vereisten op hoog niveau die spreken over wat de eindgebruiker wil van een gedefinieerde actie op het softwaresysteem. Het ontwikkelen van het hele software systeem op basis van deze vereisten is niet mogelijk omdat een gedetailleerde beschrijving van hoe het software systeem of component zal worden geïmplementeerd niet wordt vermeld.

derhalve moeten bedrijfsvereisten worden uitgesplitst naar meer gedetailleerde softwarevereisten, die verder zullen worden uitgewerkt naar functionele en niet-functionele vereisten.

om dit te doen, kunnen de volgende stappen worden gevolgd:

1. Break down de high-level business requirements om gedetailleerde gebruikersverhalen.
2. een stroomschema opstellen om de stroom van activiteiten te definiëren.
3. de voorwaarde die de afgeleide gebruikersverhalen rechtvaardigt.
4. Wireframediagrammen om de workflow van objecten uit te leggen.
5. niet – functionele vereisten definiëren uit de bedrijfsvereisten.

laten we beginnen met een voorbeeld van het Automotive Infotainment system.

de zakelijke eis luidt: “de eindgebruiker moet toegang hebben tot de Navigatiewidgetbox van het infotainmentsysteem HMI en moet het bestemmingsadres kunnen instellen”.

de hierboven beschreven stappen kunnen dus worden geïmplementeerd als:

#1) Break down de high-level business requirements om gedetailleerde gebruikersverhalen.

laten we deze zakelijke eis omzetten in een high-level gebruiker verhaal, “als een gebruiker, Ik moet in staat zijn om toegang te krijgen tot de navigatie widget box, zodat ik het doel adres kan invoeren”. Dit gebruikersverhaal vertelt wat de eindgebruiker nodig heeft. We zullen proberen te bepalen hoe we deze eis kunnen uitvoeren.

laten we beginnen met het stellen van mogelijke vragen aan dit gebruikersverhaal:

1. Wie zijn de gebruikers?
2. Hoe kan ik toegang krijgen tot navigatie, onboard (vanaf SD-kaart), of vanaf SmartPhone?
3. wat voor soort doelitems kan ik invoeren?
4. mag ik de bestemming ook ingeven als de auto in de parkeergarage staat?

dit zijn meer gedetailleerde verhalen van gebruikers op het niveau, afgeleid van verhalen van gebruikers op hoog niveau en zouden ons helpen meer inzicht te krijgen in onze zakelijke vereisten.

op dit moment kunnen we een van de subverhalen van de gebruiker opnemen en vragen stellen. Laten we (nee. 3):

1. kan ik doelitems invoeren zoals Geo-coördinaten, Postadres, spraakherkenning, enz.?
2. heb ik GPS nodig voor het invoeren van Geo-coördinaten?
3. kan ik het huidige doeladres invoeren door te zoeken in de geschiedenis van adressen?

#2) een stroomdiagram opstellen om de stroom van activiteiten te definiëren.

nu kunnen we zien dat de zakelijke behoefte is onderverdeeld in zeer gedetailleerde use cases die kunnen worden gemarkeerd in het stroomdiagram zoals hieronder:

#3) voorwaarden bieden die afgeleide gebruikersverhalen rechtvaardigen.

we kunnen zien dat er meer gedetailleerde informatie opduikt als gevolg van de splitsing van de behoefte aan bedrijf op hoog niveau in gedetailleerde verhalen van gebruikers op laag niveau en het stroomdiagram. Uit dit stroomdiagram kunnen we de technische details krijgen die nodig zijn voor de implementatie, namelijk.

• de laadtijd van het scherm om het doelitem weer te geven moet 1 sec zijn.
• het doelitemtoetsenbord moet alfanumerieke tekens en speciale symbolen hebben.
• GPS aan/uit-schakelknop moet aanwezig zijn op het Navigatiereisdoelinvoerscherm.

bovenstaande informatie voldoet aan de gebruikersverhalen en maakt het mogelijk om de eis discreet en meetbaar te testen en verwarring met de eis te voorkomen terwijl deze als kenmerken wordt geïmplementeerd.

# 4) Wireframediagrammen om de workflow van objecten uit te leggen.

uit de bovenstaande use case zullen we een wireframe diagram afleiden dat de gebruikersinterface duidelijker zal maken.

#5) Het definiëren van niet-functionele eisen uit de zakelijke eisen.

het is noodzakelijk dat gedetailleerde software-eisen worden afgeleid van high-level business requirements, maar vaak worden alleen functionele eisen geïdentificeerd die aangeven hoe een systeem zich zal gedragen naar een bepaalde input/actie van de gebruiker.

functionele eisen verduidelijken echter niet de prestaties van systemen en andere kwalitatieve parameters zoals beschikbaarheid, betrouwbaarheid, enz.

voorbeelden:

A) We nemen het voorbeeld van het bovenstaande automotive infotainment system.

als de bestuurder (eindgebruiker) van de auto muziek afspeelt vanaf USB en navigatiebegeleiding aan de gang is, krijgt hij ook een inkomende oproep via Bluetooth in handsfree-modus en wordt het CPU-en RAM-verbruik tot een maximaal niveau geladen omdat er meerdere processen op de achtergrond draaien.

als de bestuurder op een touchscreen-interface van het infotainmentsysteem tikt om inkomende oproepen te weigeren via SMS-berichten Automatisch beantwoorden (op dezelfde manier als in onze mobiele telefoons), moet het systeem deze taak kunnen uitvoeren en mag het niet hangen of crashen. Dit zijn de prestaties van het systeem wanneer de belasting hoog is en we de beschikbaarheid en betrouwbaarheid testen.

b) een ander geval is het stressscenario.

neem een voorbeeld: het infotainmentsysteem ontvangt sms ‘ jes (misschien 20 SMS binnen 10 sec) via een verbonden Bluetooth-telefoon. Infotainment systeem moet in staat zijn om alle inkomende SMS-berichten af te handelen en op geen enkel moment mag een van de inkomende SMS-meldingen op Infotainment HMI missen.

bovenstaande voorbeelden zijn gevallen van niet-functionele eisen die niet alleen aan de hand van functionele eisen konden worden getest. Hoewel soms, klanten missen het verstrekken van deze niet-functionele eisen. Het is de verantwoordelijkheid van de organisatie om hen te voorzien van deze informatie, wanneer een product wordt geleverd aan de klant.

inzicht in niet-functionele vereisten Cases

in de onderstaande tabel worden niet-functionele vereisten uitgelegd:

Niet – functionele eisen, in tegenstelling tot de functionele eisen, neem de volledige levenscyclus van een project om geïmplementeerd te worden, omdat ze stapsgewijs worden geïmplementeerd in de respectievelijke Agile Sprints of in verschillende iteraties.

dit is dus hoe we softwarevereisten afleiden uit zakelijke vereisten.

verschil tussen Business Requirements en Software Requirements

we hebben hierboven gezien hoe Software requirements kunnen worden afgeleid uit high-level Business requirements. De softwarevereisten stellen de programmeur en de Testingenieur in staat om het systeem te ontwikkelen en efficiënt te testen. Dus, we weten nu dat zakelijke eisen zijn hoog niveau klant natuurlijke taal eisen terwijl software eisen zijn gedetailleerde low-level eisen die helpen bij de implementatie van het software systeem.

laten we het gedetailleerde verschil tussen de twee vereiste typen onderzoeken.

conclusie

Eisenanalyse is de ruggengraat van elk SDLC-model.

Een probleem gemist tijdens de analyse en gevangen op Unit testing kan kosten tienduizenden euro ‘ s aan een organisatie en deze kosten kunnen leiden tot miljoenen dollar als het afkomstig is van de markt als een callback (in 2017, verenigde staten gebracht airbag fabrikant, Takata een boete van $1 miljard door exploderende airbags).

de organisatie zou uiteindelijk schadebeheersingstaken uitvoeren zoals analyse van de onderliggende oorzaak, het voorbereiden van 5 Waarom-documenten, foutenboomanalyse, 8D-document, enz. in plaats van zich te concentreren op softwareontwikkeling en kwaliteit.

in het ergste geval zou de organisatie worden meegesleurd in rechtszaken die door de klant worden aangespannen als de betreffende functie betrekking heeft op beveiliging/veiligheid, zoals toegang tot de beveiliging, airbag, ABS (Antiblokkeersysteem), enz.