Wat is behoefteanalyse en -verzameling in SDLC?

what is requirement analysis

In deze zelfstudie wordt uitgelegd wat vereistanalyse, stappen voor vereisteanalyse, voorbeelden en doelen van het verzamelen van vereisten in SDLC is:

Softwareontwikkeling is een gigantische taak die een werkend softwareproduct creëert.

Het softwareproduct is gebouwd volgens de eisen van de klant. Meestal voldoet dit softwareproduct aan wat de eindklant / gebruiker had verwacht, terwijl dit product soms niet helemaal voldoet aan wat de klant / eindgebruiker had verwacht.

Wat je leert:

• Wat is een behoefteanalyse?
  • Vereiste analyse stadia / stappen
    • # 1) Verzamelen van vereisten
    • # 2) Het analyseren van verzamelde vereisten
    • # 3) Het documenteren van geanalyseerde vereisten
  • Zakelijke vereisten omzetten in softwarevereisten
  • Inzicht in gevallen van niet-functionele vereisten
  • Verschil tussen zakelijke vereisten en softwarevereisten
• Gevolgtrekking
  • Aanbevolen literatuur

Wat is een behoefteanalyse?

Laten we de behoefteanalyse begrijpen met behulp van een voorbeeld.

Verwachting van klant / eindgebruiker:

Klant / eindgebruiker ontvangen:

Zoals u aan de hand van de bovenstaande afbeeldingen kunt analyseren, is er een mismatch tussen het eindproduct en de verwachting van de klant. Dit kan te wijten zijn aan talloze redenen, namelijk. verkeerde implementatie van klanteisen, foutief ontwerp, verkeerd begrip van klanteisen door programmeurs en kwaliteitsteam, etc.

Zoals u echter kunt zien, of het nu een reden is voor een verkeerde levering van het product, gaat de primaire reden naar de vereiste. Als het juiste begrip, vastlegging, implementatie en testen van de vereisten was gedaan, zou dit hebben bijgedragen aan het verminderen van de foutieve en onvolledige productlevering aan de klant / eindgebruiker.

Een goede productlevering vereist het correct verzamelen van vereisten, het efficiënt onderzoeken van de vereisten die worden verzameld en ten slotte duidelijke documentatie van vereisten als voorwaarde. Dit hele proces wordt ook wel Vereiste analyse in de levenscyclus van softwareontwikkeling (SDLC)

Vereiste analyse stadia / stappen

Zoals u kunt zien, is Requirement Analysis de eerste activiteit in SDLC, gevolgd door functionele specificatie enzovoort. Vereiste-analyse is een cruciale stap in SDLC omdat het resoneert met acceptatietests die cruciaal zijn voor productacceptatie door klanten.

In deze tutorial leggen we uit hoe de behoefteanalyse wordt uitgevoerd in SDLC. We zullen ook de verschillende betrokken stappen, resultaten, uitdagingen en corrigerende maatregelen zien in de behoefteanalyse.

Vereiste analyse begint met:

1. Verzamelen van vereisten wat ook wel elicitatie wordt genoemd.
2. Dit wordt gevolgd door analyseren de verzamelde vereisten om de juistheid en haalbaarheid te begrijpen van het omzetten van deze vereisten in een mogelijk product.
3. En tenslotte, documenteren de verzamelde eisen.

# 1) Verzamelen van vereisten

Om ervoor te zorgen dat alle bovenstaande stappen op de juiste manier worden uitgevoerd, moeten duidelijke, beknopte en correcte vereisten worden verzameld bij de klant. De klant moet zijn vereisten goed kunnen definiëren en de bedrijfsanalist moet deze op dezelfde manier kunnen verzamelen als de klant het wil overbrengen.

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

De mogelijke groep van belanghebbenden kunnen softwarekwaliteitsingenieurs (zowel QC als QA) zijn, elke externe leverancier die ondersteuning zou kunnen bieden in het project, de eindgebruiker voor wie het product is bedoeld, softwareprogrammeurs, een ander team binnen de organisatie dat mogelijk een module of softwareplatform, softwarebibliotheken, enz. voor productontwikkeling.

Voorbeeld: In een organisatie ontwikkelen ze een ADAS-product (surround-view camerasysteem voor een prestigieuze OEM) dat nodig is Autosar-stapel en Bootloader binaire bestanden die zijn ontvangen van een andere leverancier.

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

Soms is het een goed idee om een ​​prototypemodel van het geplande product te maken en dit aan de klant te laten zien. Dit is een uitstekende manier om aan klanten duidelijk te maken welk product ze verwachten en hoe het er later uit kan zien. Dit helpt de klant bij het visualiseren van het product dat hij verwacht en helpt bij het bedenken van duidelijke eisen.

Het maken van dit prototype is afhankelijk van twee soorten producten:

1. Een soortgelijk product dat klanten bedoeld hebben, bestaat binnen de organisatie.
2. Nieuw te ontwikkelen product.

(ik) In het eerste geval is het gemakkelijker om de klant te laten zien hoe het eindproduct eruit zou zien en hoe het ontwikkeld zou worden. 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, etc.) en kan worden getoond aan een andere OEM.

Houd er rekening mee dat , is het niet verstandig om een ​​product / protoproduct aan de klant te laten zien dat in ontwikkeling is, aangezien het in strijd kan zijn met de 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 zou dat van het infotainmentsysteem kunnen zijn, dat door de organisatie wordt ontwikkeld en al op de markt is. Bedrijfsanalisten en andere belanghebbenden binnen een organisatie kunnen een workshop-demo voor de klant plannen, waarin infotainmentsystemen met tastbare HMI, apparaatconnectorpoorten, sandbox, enz. Worden weergegeven.

Dit zal de klant helpen te begrijpen hoe het eindproduct eruit zou zien en hun vereisten veel duidelijker kunnen geven.

(ii) Het tweede geval kan worden bereikt door een basiswerkmodel te creëren door eenvoudige codering en montage uit te voeren (de meeste functies zijn hier hard gecodeerd in softwareprogramma's), of door een stroomschema of diagram te maken dat de klant zou kunnen overtuigen hoe het product eruit zou zien.

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

De bedrijfsanalist kan nu formele bijeenkomsten voor het uitlokken van vereisten organiseren, waar alle belanghebbenden kunnen worden uitgenodigd en zo de verschillende vereisten van de klant kunnen noteren (in sommige gevallen, als er meer belanghebbenden zijn, kan een afzonderlijke schrijver worden aangesteld om de klant op te schrijven). vereisten of gebruikersverhalen, zodat bedrijfsanalisten zich kunnen concentreren op het modereren van de vergadering).

Verzamelde vereisten kunnen de vorm hebben van gebruikersverhalen (in agile ontwikkeling), use cases, natuurlijke taal documenten van klanten, diagrammen, stroomdiagrammen, etc. Gebruikersverhalen worden populair in de moderne levenscyclus van softwareontwikkeling. Gebruikersverhalen zijn in feite een reeks klantinvoer in hun natuurlijke taal.

Voorbeeld van het verzamelen van vereisten: In het ADAS surround-view camerasysteem zou een mogelijk gebruikersverhaal kunnen zijn: 'Als gebruiker zou ik moeten kunnen zien wat er in de achteruitkijkspiegel van mijn auto is'.

Er kunnen er veel zijn 'waarom,' vragen die bij elk gebruikersverhaal worden gesteld, die de klant zullen helpen bij het verstrekken van meer gedetailleerde informatie over de vereiste.

Als een klant in het bovenstaande gebruikersverhaal zegt: 'Als gebruiker zou ik moeten kunnen zien wat er in de achteruitkijkspiegel van mijn auto staat' en een vraag stellen 'waarom 'Zou kunnen geven' Als gebruiker zou ik moeten kunnen zien wat er in de achteruitkijkspiegel van mijn auto is, zodat ik mijn auto veilig kan parkeren ​

De vraag stellen 'waarom' helpt ook bij het creëren van objectieve en atomaire vereisten op basis van gigantische uitspraken in natuurlijke taal die door de klant worden gegeven. Dit kan later eenvoudig in de code worden geïmplementeerd.

de beste youtube naar mp4-converter

Een andere manier om de vereiste te verzamelen is in de vorm van use cases ​Een use case is een stapsgewijze aanpak om een ​​bepaald resultaat te bereiken. Dit zegt niet hoe de software zal werken op gebruikersinvoer, maar zegt wat er van gebruikersinvoer wordt verwacht.

Voorbeeld:

# 2) Het analyseren van verzamelde vereisten

Na het verzamelen van vereisten, begint de analyse van de vereisten. In dit stadium zitten verschillende belanghebbenden om een ​​brainstormsessie. Ze analyseren de verzamelde vereisten en zoeken naar haalbaarheid om ze te implementeren. Ze overleggen met elkaar en eventuele onduidelijkheden worden opgelost.

Deze stap is belangrijk in het proces van vereistenanalyse vanwege de volgende hoofdredenen:

(ik) De klant kan enkele vereisten verstrekken die vanwege verschillende afhankelijkheden onmogelijk kunnen worden geïmplementeerd.

Voorbeeld: Klantenkan vragen om het camerasysteem rondom te bekijken met een achteruitkijkcamerafunctie die kan helpen parkeren de auto. De klant kan ook vragen om het Aanhangwagen trekhaakfunctie die ook de achteruitrijcamera gebruikt om te werken.

Als de klant een eis stelt die achteruitkijkcamera voor parkeren hulp zou te allen tijde zonder uitzondering moeten werken, dan is de Aanhangwagen functie zou nooit werken en vice versa.

(ii) Een bedrijfsanalist heeft de vereiste wellicht begrepen uit de klant anders dan hoe een programmeur zou geïnterpreteerd hebben.

Omdat programmeurs denken als technisch experts, is het altijd mogelijk dat klanteisen foutief worden omgezet naar functionele specificaties die later foutief worden gemaakt naar architectuur- en ontwerpdocumenten en vervolgens naar code. De impact is exponentieel en moet dus worden gecontroleerd.

Een mogelijke remediërende maatregel zou kunnen zijn door een agile methode van softwareontwikkeling te volgen, gebruiksscenario's te volgen die de klant biedt, enz.

# 3) Het documenteren van geanalyseerde vereisten

Zodra de analyse van de vereisten is voltooid, begint de documentatie van de vereisten. Uit de analyse van de eisen komen verschillende soorten eisen naar voren.

Enkele hiervan zijn:

(ik) Specificatie van klantvereisten.

(ii) Software Architectuur vereiste.

Voorbeeld:

(iii) Vereiste softwareontwerp.

Voorbeeld:

(iv) Functionele vereiste specificatie (direct afgeleid van klantspecificaties.)

Voorbeeld: 'Wanneer de gebruiker op het Bluetooth-pictogram op de Infotainment-HMI tikt, moet het Bluetooth-scherm worden weergegeven'

(v) Niet-functionele specificatie van de eisen (nl. Prestatie, spanning, belasting, etc.).

Voorbeeld: 'Het zou mogelijk moeten zijn om 15 Bluetooth-apparaten aan het infotainmentsysteem te koppelen zonder dat de systeemprestaties achteruitgaan'.

(wij) Gebruikersinterface vereisten.

Voorbeeld: 'Op het Tuner FM-scherm zou een knop aanwezig moeten zijn om verschillende stations te selecteren'

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

Laten we nu eens kijken naar het conversieproces Zakelijke vereisten naar Softwarevereisten (functioneel en niet-functioneel).

Zakelijke vereisten omzetten in softwarevereisten

Zakelijke vereisten, zoals hierboven besproken, zijn vereisten op hoog niveau die praten over wat de eindgebruiker wil van een gedefinieerde actie op het softwaresysteem. Het is niet mogelijk om het hele softwaresysteem op basis van deze vereisten te ontwikkelen, aangezien er geen gedetailleerde beschrijving wordt gegeven van hoe het softwaresysteem of de component zal worden geïmplementeerd.

Zakelijke vereisten moeten dus worden opgesplitst in meer gedetailleerde softwarevereisten die verder worden uitgewerkt tot functionele en niet-functionele vereisten.

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

1. Verdeel de zakelijke vereisten op hoog niveau naar gedetailleerde gebruikersverhalen.
2. Een stroomschema afleiden om de stroom van activiteiten te definiëren.
3. De voorwaarde bieden die de afgeleide gebruikersverhalen rechtvaardigt.
4. Wireframe-diagrammen om de workflow van objecten uit te leggen.
5. Het definiëren van niet-functionele vereisten uit de zakelijke vereisten.

Laten we beginnen met een voorbeeld van een auto-infotainmentsysteem.

De zakelijke eis luidt: 'De eindgebruiker moet toegang hebben tot de navigatiewidget-box vanuit de HMI van het Infotainmentsysteem en moet het bestemmingsadres kunnen instellen'.

De bovenstaande stappen kunnen dus worden geïmplementeerd als:

# 1) Verdeel de zakelijke vereisten op hoog niveau naar gedetailleerde gebruikersverhalen.

Laten we deze zakelijke vereiste omzetten in een gebruikersverhaal op hoog niveau: ' Als gebruiker zou ik toegang moeten hebben tot het navigatiewidgetvenster, zodat ik het bestemmingsadres kan invoeren ​Dit gebruikersverhaal vertelt wat de eindgebruiker nodig heeft. We zullen proberen te definiëren hoe we deze vereiste kunnen implementeren.

wat is het beste idee voor python

Laten we beginnen met het stellen van mogelijke vragen aan dit gebruikersverhaal, namelijk.

1. Wie zijn de gebruikers?
2. Hoe krijg ik toegang tot navigatie, aan boord (vanaf SD-kaart) of vanaf SmartPhone?
3. Wat voor soort bestemmingsinvoer kan ik invoeren?
4. Moet ik de bestemming kunnen invoeren, zelfs als de auto in de parkeergarage staat?

Dit zijn meer gedetailleerde gebruikersverhalen op niveau die zijn afgeleid van gebruikersverhalen op hoog niveau en die ons zouden helpen meer inzicht te krijgen in onze zakelijke vereisten.

Op dit punt kunnen we een van de subverhalen van gebruikers opnemen en beginnen met vragen stellen. Laten we (nr. 3) nemen:

1. Kan ik bestemmingsinvoer invoeren, zoals geografische coördinaten, postadres, via spraakherkenning, enz.?
2. Heb ik gps nodig voor het invoeren van geografische coördinaten?
3. Kan ik het huidige bestemmingsadres invoeren door te zoeken in de geschiedenis van adressen?

# 2) Een stroomschema afleiden om de stroom van activiteiten te definiëren.

Nu kunnen we zien dat de bedrijfsvereiste is opgesplitst in zeer gedetailleerde use-cases die in het stroomschema kunnen worden gemarkeerd, zoals hieronder:

# 3) Voorwaarden bieden die afgeleide gebruikersverhalen rechtvaardigen.

We kunnen zien dat er meer gedetailleerde informatie naar voren komt als gevolg van de ontbinding van de zakelijke vereisten op hoog niveau in gedetailleerde gebruikersverhalen op laag niveau en het stroomschema. Uit dit stroomschema kunnen we de technische details krijgen die nodig zijn voor de implementatie, namelijk.

• De laadtijd van het scherm om de invoer van de bestemming weer te geven, moet 1 seconde zijn
• Het toetsenbord voor het invoeren van de bestemming moet alfanumerieke tekens en speciale symbolen bevatten.
• De schakelknop voor GPS in- / uitschakelen moet aanwezig zijn op het invoerscherm voor navigatiebestemmingen.

De bovenstaande informatie voldoet aan gebruikersverhalen en maakt het mogelijk om de vereiste discreet en meetbaar te testen, waardoor verwarring met de vereiste wordt vermeden terwijl deze als functies wordt geïmplementeerd.

# 4) Wireframe-diagrammen 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 vereisten uit de zakelijke vereisten.

Het is absoluut noodzakelijk dat gedetailleerde softwarevereisten worden afgeleid van zakelijke vereisten op hoog niveau, maar vaak worden alleen functionele vereisten geïdentificeerd die aangeven hoe een systeem zich zal gedragen bij een bepaalde gebruikersinvoer / actie.

Functionele vereisten geven echter geen duidelijkheid over de systeemprestaties en andere kwalitatieve parameters zoals beschikbaarheid, betrouwbaarheid, enz.

Voorbeelden:

a) We nemen het voorbeeld van het bovenstaande auto-infotainmentsysteem.

Als de bestuurder (eindgebruiker) van de auto muziek afspeelt vanaf USB en de navigatiebegeleiding aan de gang is, ook een inkomende oproep krijgt via Bluetooth in handsfree modus, dan wordt de belasting van de CPU en het RAM-verbruik verhoogd tot een maximaal niveau aangezien er meerdere processen zijn draait op de achtergrond.

Als de bestuurder op dit moment op de touchscreen-interface van een infotainmentsysteem tikt om een ​​inkomende oproep via automatisch antwoord-sms te weigeren (op dezelfde manier als bij onze mobiele telefoons), zou het systeem deze taak moeten 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 back-to-back sms'jes (misschien 20 sms'jes binnen 10 seconden) via een aangesloten Bluetooth-telefoon. Het infotainmentsysteem moet alle inkomende sms-berichten kunnen verwerken en mag op geen enkel moment een inkomende sms-melding op de infotainment-HMI missen.

De bovenstaande voorbeelden zijn gevallen van niet-functionele vereisten die niet alleen met functionele vereisten konden worden getest. Hoewel klanten soms niet aan deze niet-functionele vereisten voldoen. Het is de verantwoordelijkheid van de organisatie om deze informatie te verstrekken wanneer een product aan de klant wordt geleverd.

Inzicht in gevallen van niet-functionele vereisten

In de onderstaande tabel worden niet-functionele vereisten uitgelegd:

Niet-functionele vereisten nemen, in tegenstelling tot functionele vereisten, de volledige levenscyclus van een project in beslag om geïmplementeerd te worden, aangezien ze incrementeel worden geïmplementeerd in respectievelijke Agile Sprints of in verschillende iteraties.

Dit is dus hoe we softwarevereisten afleiden uit bedrijfseisen.

Verschil tussen zakelijke vereisten en softwarevereisten

We hebben hierboven gezien hoe softwarevereisten kunnen worden afgeleid uit zakelijke vereisten op hoog niveau. Softwarevereisten stellen de programmeur en testingenieur in staat om het systeem te ontwikkelen en efficiënt te testen. We weten nu dus dat zakelijke vereisten natuurlijke taalvereisten van klanten zijn op hoog niveau, terwijl softwarevereisten gedetailleerde vereisten op laag niveau zijn die helpen bij de implementatie van het softwaresysteem.

Laten we eens kijken naar het gedetailleerde verschil tussen de twee soorten vereisten.

Gevolgtrekking

Vereiste-analyse vormt de ruggengraat van elk SDLC-model.

Een probleem dat wordt gemist tijdens de analyse van de vereisten en wordt betrapt bij het testen van eenheden, kan een organisatie tienduizenden dollars kosten en deze kosten kunnen tot miljoenen dollars leiden als het uit de markt komt als een terugroepactie (in 2017 bracht de Amerikaanse fabrikant van airbags, Takata a boete van $ 1 miljard wegens exploderende airbags).

De organisatie zou uiteindelijk schadebeperkingstaken uitvoeren zoals oorzaakanalyse, 5 waarom-documenten voorbereiden, foutenboomanalyse, 8D-document, enz. In plaats van zich te concentreren op softwareontwikkeling en kwaliteit.

In het ergste geval zou de organisatie worden meegesleurd in juridische procedures die door de klant zijn aangespannen als de betreffende functie beveiligings- / veiligheidsgerelateerd is, zoals beveiligingstoegang, airbag, ABS (antiblokkeersysteem), enz.

Aanbevolen literatuur

• SDLC (Software Development Life Cycle) fasen, methodologieën, processen en modellen
• Kenmerken van functionele vereisten en niet-functionele vereisten
• Hoe de specificatie van softwarevereisten (SRS) testen?
• 5 dodelijke fouten in het beheer van vereisten en hoe deze te verhelpen
• Hoe een applicatie testen zonder vereisten?
• Maatregelen voor SSDLC (Secure Software Development Life Cycle)
• Spiraalmodel - Wat is het SDLC-spiraalmodel?
• Wat is het SDLC-watervalmodel?