Visuele oplossingen


Support
Registreren
Inloggen
Probeer gratis uit

Requirements engineering

Inhoudsopgave

Om een ​​kwaliteitsproduct te produceren, is het belangrijk om nauwkeurige eisen van de klant te hebben. Dit begint met het proces van requirements-engineering, dat in vijf stappen kan worden onderverdeeld: het verzamelen van requirements, het documenteren van requirements, het analyseren en verifiëren van requirements, het beheren van wijzigingen in de requirements en het afsluiten van de requirements-fase. In deze blogpost bespreken we elk van deze stappen in detail en laten we zien hoe ze helpen om een ​​product van hoge kwaliteit te produceren.

Wat zijn Requirements en Requirements Engineering?

Er zijn hier twee termen, "Requirement" en "Requirements Engineering". Een vereiste wordt nauwkeurig gedefinieerd als een voorwaarde of een mogelijkheid die een gebruiker nodig heeft om een ​​probleem op te lossen of een doel te bereiken. Met andere woorden, vereisten zijn voorwaarden of mogelijkheden waaraan een systeem moet voldoen of waarover een systeem moet beschikken om te voldoen aan een contract, normen, specificaties en andere formele documentatie. 

Requirements Engineering wordt gedefinieerd als het proces van het definiëren, documenteren en onderhouden van de eisen. De discipline omvat alle technieken, methoden en procedures met betrekking tot de definitie en het beheer van de behoeften van gebruikers met betrekking tot het systeem dat wordt bestudeerd. 

Al met al is Requirements Engineering een reeks activiteiten die zich bezighouden met het identificeren en communiceren van het doel van een systeem of software en de context waarin deze zal worden gebruikt. 

Daarom fungeert Requirements Engineering als een brug tussen de reële behoeften van de gebruikers, klanten en andere groepen die worden beïnvloed door software of systemen, en de mogelijkheden en kansen die worden geboden door de software-intensieve technologieën.

Wat zijn de principes van Requirements Engineering?

De twee basisprincipes van Requirements Engineering zijn het probleem en de oplossing van de requirements engineering. 

  • Het is handig om het probleem en de oplossing te scheiden bij het verzamelen van de eisen.
  • Deze scheiding kan in de praktijk nooit volledig worden bereikt.

Requirement engineering gaat over het bouwen van het juiste systeem. Kortom, het gaat om het bouwen van een systeem dat past bij de problemen van de gebruiker. Dit is een probleemgericht deel. Het gaat in feite over het ontwerpen, verifiëren, implementeren en onderhouden van het systeem dat is gemaakt om ervoor te zorgen dat het past bij de problemen van de gebruiker. Dit is het oplossingsgerichte deel.

Vereisten engineering proces

Er zijn een paar activiteiten waarmee we te maken krijgen bij het werken met de vereisten. In de cyclus van Requirements Engineering zijn er vijf hoofdactiviteiten, namelijk:

  1. Vereisten elicitatie: – dit is het proces van het beoordelen, documenteren en begrijpen van de belanghebbenden en gebruikersbehoeften en -beperkingen voor het seizoen. Gebruikers hebben domeininformatie, bestaande systeeminformatie, regelgeving, standaarden, etc. nodig. Op basis van deze informatie peilen wij de eisen. Hierna gaan we over naar de analyse en onderhandeling van de vereisten. 
  2. Vereistenanalyse en onderhandeling – analyse is het proces van het verfijnen van de gebruikersbehoeften en -beperkingen op basis van verzamelde en uitgelokte informatie. Vervolgens gaan we naar de documentatieactiviteit. 
  3. Vereisten Documentatie/specificatie – na het verkrijgen van de vereiste specificaties, gaan we naar het documentatiegedeelte. We documenteren de gebruikersbehoeften en -beperkingen duidelijk en nauwkeurig. 
  4. Validatie van vereisten – ten slotte voegen we in de validatieactiviteit toe dat de seizoensvereisten volledig, beknopt en duidelijk zijn. 
  5. Vereistenbeheer – Eisenmanagement is een manier om alle producten of eisen in de ontwikkelingsfase te verzamelen, analyseren, verfijnen en prioriteren.

Wanneer we deze vijf activiteiten afronden, herhalen we ze keer op keer totdat we een reeks overeengekomen vereiste documenten krijgen die formele specificaties zijn.

Vereisten elicitatie:

Zoals we eerder hebben besproken, is het uitlokken van vereisten het proces van het beoordelen, documenteren en begrijpen van de gebruikersbehoeften en -beperkingen voor het seizoen. Gebruikers hebben domeininformatie, bestaande systeeminformatie, regelgeving, standaarden, etc. nodig. Op basis van deze informatie peilen wij de eisen. We gebruiken het woord 'Elicitation' in plaats van 'Verzamelen' omdat verzamelen wordt geïnterpreteerd als het oppakken van de vereisten en deze in een document opnemen. Aan de andere kant is elicitatie een complexer proces. Je krijgt de vereisten niet zo gemakkelijk als tijdens het verzamelen. Het vraagt ​​extra inspanning. 

Tijdens elicitatie vraag je de gebruiker of klant:

  • Wat zijn hun doelstellingen voor het systeem/product? 
  • Wat valt er te bereiken?
  • Hoe passen de seizoensgebonden behoeften in de behoeften van het bedrijf?
  • Hoe moet het seizoensproduct/systeem regelmatig worden gebruikt?

Het klinkt eenvoudig, maar dat is het helemaal niet!

Volgens Ian Sommerville en Pete Sawyer is Requirements Elicitation het proces van het ontdekken van de vereisten voor een systeem door te communiceren met de klanten, systeemgebruikers en anderen die belang hebben bij de systeemontwikkeling. Omdat 'verzamelen' of 'vastleggen' niet erg nauwkeurig klinkt, gebruiken we het woord 'eliciteren'. 

" Ik weet dat je denkt dat je begreep wat je denkt dat ik zei, maar ik weet niet zeker of je beseft dat wat je hoorde niet is wat ik bedoelde " - Robert McCloskey, woordvoerder van het ministerie van Buitenlandse Zaken.

Wat hij bedoelde met zijn citaat is dat mensen soms verkeerd begrijpen wat andere mensen tegen hen zeggen. Soms is wat ze zeggen niet wat ze in gedachten hebben. Uiteindelijk leidde deze hele miscommunicatie tot het wangedrag van het verzamelen van vereisten.

Wat zijn de stappen tijdens de elicitatie?

STAP 1 

Bron van eisen:

Er zijn verschillende bronnen waaruit we onze wensen kunnen putten. Sommigen van hen omvatten:

  • Stakeholders
  • Bestaande systemen
  • Bestaande documenten
  • Concurrenten en andere soortgelijke systemen
  • Interfaces met de systemen
  • Wetten en normen
  • Bedrijfsbeleid

STAP 2

Stel de projectomvang in:

Om de scope van het project in te stellen, kunnen de volgende stappen worden doorlopen:

  1. Ontdek waarom het project is gestart 
  2. Vastgoed definieert de belangrijkste doelstellingen die door het project moeten worden bereikt 
  3. Maak een werkoverzicht voor het project dat u zal helpen het werk op de juiste manier onder de teamleden te verdelen
  4. Maak een lijst van de items die moeten worden geleverd aan het einde van het project
  5. Selecteer de belangrijkste mijlpalen die moeten worden bereikt
  6. Identificeer de belangrijkste beperkingen en beperkingen waarmee het team mogelijk te maken kan krijgen tijdens de ontwikkeling van het project
  7.  Maak een lijst met items die zijn uitgesloten van de lijst met scope-items
  8. Laat de belanghebbenden het scopedocument ondertekenen, aangezien het een bevestiging geeft dat ze op de hoogte zijn van het project en de inhoud ervan. 

STAP 3

Opwekkingstaken:

Uitlokking van de planning:

  • Waarom moet deze specifieke eis worden geïmplementeerd en welke voordelen biedt het? - Doelen van het project 
  • Wie zal verantwoordelijk zijn voor het maken ervan? – Professionals voor uitlokkingsinspanningen
  • Wanneer is de beste tijd om het uit te voeren? – Plan een schattingsbronnen 
  • Hoe zal het worden uitgevoerd? – Strategieën en procedures
  • En de risico's 

Tijdens uitlokking:

  • Bevestig de levensvatbaarheid van het project. Ontdek of het project echt de moeite waard is of niet
  • Begrijp de problemen en problemen vanuit het perspectief van een stakeholder
  • Haal de essentie uit de door de stakeholders gestelde eisen
  • Ontdek betere manieren om het werk voor de gebruikers te doen
  • Innovatie is de sleutel tot overwinning

Volgende uitlokking:

  • Analyseer de resultaten om de verzamelde informatie goed te begrijpen
  • Onderhandel over een coherent geheel van eisen die acceptabel zijn voor de belanghebbenden. Bepaal ook de prioriteiten
  • Leg de resultaten vast in de specificaties van de eisen

Elicitatie is een incrementeel proces. U moet deze stap zo vaak herhalen als nodig is. 

Selecteer nu een geschikte set technieken voor elke bron van vereisten. Bepaal deze techniek op basis van de bron, het te ontwikkelen systeem, enzovoort. Bedenk dat niet alle technieken in elke situatie kunnen worden toegepast. 

STAP 4

Documentatie van de vereisten – 

De laatste stap in het elicitatieproces is om alle vereisten in de vorm van een document af te ronden. Dit document bevat voornamelijk de opmerkingen en gebruikerswensen. En deze vereisten zullen onvolledig, inconsistent en ongeorganiseerd zijn. Maar dit is slechts het startpunt. Het document kan zo nu en dan worden bewerkt en er kunnen dingen worden toegevoegd of gewijzigd.

Vereistenanalyse en onderhandeling

Analyse van vereisten is typisch een procedure voor het analyseren, valideren en afstemmen van de vereisten die zijn gedocumenteerd tijdens de fase van het opsporen van vereisten. Met andere woorden, analyse van vereisten is een proces van het bestuderen en begrijpen van de vereisten die door de belanghebbenden worden gesteld. Analyse van vereisten vereist frequente communicatie met de belanghebbenden en eindgebruikers om de verwachtingen te definiëren, de conflicten op te lossen en ten slotte de belangrijkste vereisten te documenteren. De oplossingen kunnen betrekking hebben op zaken als:

  • Verschillende soorten instellingen voor de workflow in het bedrijf
  • Opzetten van een nieuw systeem dat vanaf nu gebruikt gaat worden, etc. 

Een ding om in gedachten te houden is dat Requirement Elicitation en Requirement Analysis samenwerken. Ze twee voeden elkaar. Wanneer we beginnen met het verzamelen van de eisen, lokken we ze uit en analyseren we ze tegelijkertijd.

Doelstellingen van behoefteanalyse

  1. Het eerste en belangrijkste doel van de analyse van de vereisten is om de vereisten en behoeften van de gebruikers te begrijpen 
  2. Wanneer we verschillende bronnen gebruiken om de vereisten te verzamelen, kunnen er enkele conflicten tussen deze bronnen zijn. Vereistenanalyse gaat over het vinden van die conflicten tussen de door de gebruikers gestelde eisen en het oplossen ervan. 
  3. Onderhandelen over de eisen met de gebruikers en belanghebbenden. Ons systeem kan op geen enkele manier aan alle vereisten voldoen op de exacte manier waarop ze worden uitgelegd door de belanghebbenden en gebruikers. 
  4. We zullen moeten onderhandelen en prioriteiten stellen. Sommige vereisten zijn misschien niet groot voor ons, maar ze kunnen behoorlijk belangrijk zijn voor de eindgebruikers. Om ze te begrijpen, moeten we de vereisten van de belanghebbenden analyseren en prioriteren. 
  5. We moeten de eisen die de gebruikers en het systeem stellen nader uitwerken. Dit helpt bij het documenteren van de vereisten in de vereistenspecificaties. Dit helpt de ontwikkelaars ook om beter te ontwikkelen, ontwerpen en testen, omdat ze de vereisten op een uitgewerkte en betere manier begrijpen. 
  6. We moeten de eisen indelen in verschillende categorieën en subcategorieën en die eisen verder toewijzen aan verschillende subsystemen. 
  7. Ook moeten we de eisen aan de door de organisatie gewenste kwaliteit evalueren. 
  8. Ten slotte moeten we ervoor zorgen dat we niets belangrijks over het hoofd zien.

Vereisten Documentatie/specificatie

Vereistenspecificatie, ook wel documentatie genoemd, is een proces waarbij alle systeem- en gebruikersvereisten in de vorm van een document worden vastgelegd. Deze vereisten moeten duidelijk, volledig, alomvattend en consistent zijn. 

Tijdens het vastleggen verzamelen we alle eisen uit verschillende bronnen. Tijdens de analyse- en onderhandelingsactiviteiten analyseren en begrijpen we die vereisten. Nu moeten we een formeel document opstellen waarin deze vereisten worden uitgelegd. Dat is wat de eisspecificatie is. Om precies te zijn, het is het proces waarbij alle gebruikers- en systeembehoeften en -beperkingen op een duidelijke en nauwkeurige manier worden gedocumenteerd. 

Methode voor het documenteren van vereisten

EARS zou hier een effectieve methode zijn. Het staat voor Eenvoudige benadering van vereistensyntaxis. Bij deze methode schrijven we heldere, beknopte en begrijpelijke taal. Dit verbetert de hele workflow voor requirements-engineering en vereenvoudigt het werk door dingen vrij eenvoudig te begrijpen te maken. 

Om dit te bereiken, volgen hier enkele principes die in gedachten moeten worden gehouden bij het schrijven van de vereisten. Het gaat om:

Elke eis moet de vorm hebben van een volledige zin. Er mogen geen opsommingstekens, acroniemen, afkortingen of modewoorden worden gebruikt. Probeer korte, directe en volledige zinnen te maken. 

Zorg ervoor dat elke vereiste een goed onderwerp, predikaat en werkwoord heeft. Het onderwerp zou het gebruikerstype of het systeem zijn waar we het over hebben. Het predikaat zou de voorwaarden of acties of gewenste resultaten zijn die we verwachten. We moeten woorden als 'zullen', 'willen' en 'moeten' gebruiken om een ​​of andere noodzaak uit te drukken, en woorden als 'kunnen' om optionaliteit in de vereiste uit te drukken. 

Elke eis moet het eindresultaat dat we van het systeem verlangen efficiënt uitleggen. 

Ook moet de eis de kwaliteit beschrijven die we van het systeem verwachten. Het helpt als we het eindresultaat meten en kijken of de eis goed wordt uitgevoerd of niet.

Validatie van vereisten

Validatie is een proces dat wordt gebruikt om te controleren of het systeem voldoet of niet. Validatie geeft antwoord op de vraag: "Bouwen we het juiste systeem?" Het gaat om het testen en valideren van het systeem en kijken of het door ons gebouwde systeem klopt of niet en of het aan de verwachtingen van de klant voldoet of niet. Verschillende methoden die worden gebruikt om het systeem te valideren, zijn onder meer black-box-testen, white-box-testen, integratietesten en unit-tests. Validatie komt altijd na verificatie. 

Verificatie is een proces dat wordt gebruikt om te controleren of het systeem de verwachte doelen bereikt of niet zonder bugs of problemen. Verificatie geeft antwoord op de vraag: "Bouwen we het product goed?" Het gaat om het testen en verifiëren of het systeem probleemloos aan zijn eisen voldoet. Verschillende methoden die worden gebruikt om het systeem te verifiëren, zijn onder meer beoordelingen, walkthroughs, inspecties en bureaucontroles. Verificatie is een handmatig proces dat vóór validatie wordt uitgevoerd.

Validatie technieken

Er zijn verschillende technieken die kunnen worden gebruikt om de vereisten te valideren. Ze bevatten:

  • Controles – Tijdens het controleren van de vereisten lezen we de vereistendocumenten na om er zeker van te zijn dat er geen uitlokkende opmerkingen worden gemist. Tijdens deze controles controleren we ook het traceerbaarheidsniveau tussen alle eisen. Hiervoor is het maken van een traceerbaarheidsmatrix vereist. Deze matrix zorgt ervoor dat alle eisen serieus worden overwogen en dat alles wat wordt gespecificeerd gerechtvaardigd is. Tijdens deze controles controleren we ook de vorm van eisen. We kijken of de eisen duidelijk en goed geschreven zijn of niet. 
  • Prototyping – Dit is een manier om een ​​model of simulatie te bouwen van het systeem dat door de ontwikkelaars moet worden gebouwd. Dit is een zeer populaire techniek voor het valideren van vereisten onder belanghebbenden en gebruikers, omdat het hen helpt om de problemen gemakkelijk te identificeren. We kunnen gewoon contact opnemen met de gebruikers en belanghebbenden en hun feedback krijgen. 
  • Test ontwerp – Tijdens het ontwerpen van tests volgen we een kleine procedure waarbij we eerst het testteam afronden en vervolgens enkele testscenario's bouwen. Functionele tests kunnen worden afgeleid uit de specificatie van de vereisten zelf, waarbij elke vereiste een bijbehorende test heeft. Integendeel, de niet-functionele vereisten zijn moeilijk te testen, omdat elke test moet worden herleid tot zijn vereiste. Het doel hiervan is om de fouten in de specificatie of de gemiste details te achterhalen. 
  • Beoordeling van vereisten – Tijdens de evaluatie van de vereisten analyseert een groep deskundige mensen de vereisten op een gestructureerde en gedetailleerde manier en identificeert ze de potentiële problemen. Daarna komen ze samen om de problemen te bespreken en een manier te vinden om de problemen aan te pakken. Er wordt een checklist opgesteld die bestaat uit verschillende normen en de reviewers vinken de vakjes aan om een ​​formele beoordeling te geven. Daarna vindt een definitieve goedkeuring van de goedkeuring plaats.

Vereistenbeheer

Volgens Ian Sommerville: "Vereistenbeheer is het proces van het beheren van veranderende vereisten tijdens het proces van vereisten-engineering en systeemontwikkeling."

Het belangrijkste doel van vereistenbeheer is om te zorgen voor duidelijke, beknopte en foutloze vereisten voor het engineeringteam, zodat ze fouten in het systeem kunnen detecteren en mogelijk de projectkosten en risico's kunnen verlagen. 

Belangrijkste zorgen van Requirements Management

Er zijn enkele zorgen over het beheer van vereisten. Ze bevatten:

  • Beheer van de wijzigingen in de overeengekomen eisen
  • De relatie tussen alle vereisten beheren
  • Het beheren van de afhankelijkheden tussen de vereistendocumenten die worden geproduceerd tijdens het systeemengineeringproces.

Soorten vereisten

Er zijn grofweg twee soorten vereisten:

  1. Systeem vereisten – Systeemvereisten kunnen de uitgebreide versie van de gebruikersvereisten worden genoemd. Systeemvereisten vormen het startpunt voor elk nieuw systeemontwerp. Deze eisen zijn een gedetailleerde beschrijving van de gebruikerseisen waaraan het systeem moet voldoen. 
  2. Gebruikers vereisten – Gebruikersvereiste is een combinatie van functionele en niet-functionele eisen. Deze gebruikersvereisten moeten zo worden ontworpen dat ze gemakkelijk te begrijpen zijn voor gebruikers die geen enkele technische kennis hebben. Daarom moeten ze in natuurlijke taal worden geschreven met behulp van eenvoudige tabellen, formulieren en diagrammen. Zorg er ook voor dat het document geen details bevat over systeemontwerp, software of formele aantekeningen.

Visuele vereisten ALM-platform

Visuele vereisten ALM-platform is een van de meest vertrouwde moderne ALM-platforms die gespecialiseerd zijn in vereistenbeheer voor organisaties van elke omvang over de hele wereld. 

Het is een onmisbare tool voor teams die complexe producten, systemen en software bouwen, die end-to-end traceerbaarheid vereisen, van concept tot testen en implementatie, tot aan de broncode, samen met naleving van de standaardcertificering.

Visure Requirements is een bewezen flexibele en complete Requirements Engineering tool, die in staat is om het software requirements proces te stroomlijnen als onderdeel van het hardware en mechanische definitieproces. Visure-vereisten helpen effectieve projectsamenwerking en verhogen de softwarekwaliteit door het vastleggen, analyseren, specificeren, valideren en verifiëren, beheren en hergebruiken van vereisten.

Visure Solutions kan helpen bij het overwinnen van de uitdagingen van product- en embedded ontwikkeling,

  • Verbeter de kwaliteit van de definitie als een essentiële eerste stap in het verbeteren van de softwarekwaliteit
  • Krijg weer controle over ontwikkelings- en regelgevingsprocessen
  • Standaardiseer en handhaaf de definitie van vereisten in de hele organisatie
  • Ondersteun effectief hergebruik van vereisten in projectteams en productlijnen en varianten
  • Formaliseer een gemeenschappelijke specificatiestructuur voor vereisten en behandel veranderingen gedurende de levenscyclus
  • Bereiken volledige traceerbaarheid door alle elementen, van vereisten tot testen tot uitvoering
  • Volg eenvoudig alle aspecten van ontwikkeling, van grafieken voor risicoberekeningen tot rapporten over weesvereisten
  • Vermijd valkuilen en beperk risico's op alle niveaus, van het schrijven van betere vereisten en het prioriteren van behoeften tot het wijzigen van de mogelijkheden voor impactanalyse.
ALM-softwaretools

Voordelen van het gebruik van Visure-vereisten voor product- en embedded ontwikkeling

  • Ondersteuning bij certificering voor: industriestandaarden, zoals DO-178B/C, IEC 61508, ISO 26262, IEC 62304, FMEA en GAMP5
  • Eén compleet platform voor alle vereistengerelateerde activiteiten
  • Proceshandhaving via een flexibele oplossing die verschillende procesmodellen ondersteunt, waaronder Automotive SPICE, CMMI, V-model, Agile en ad hoc
  • Verbeterde teamcommunicatie en samenwerking door op rollen gebaseerde mogelijkheden
  • Ondersteuning voor producten van betere kwaliteit en minder softwarefouten.

Bedrijven die Visure actief gebruiken, claimen een duidelijke impact met tijdige projectopleveringen, projectcompliance en een verlaging van ontwikkelkosten en cyclustijden.

Conclusie

Requirements engineering is een cruciaal proces om ervoor te zorgen dat de producten en systemen die we bouwen, zijn wat onze klanten nodig hebben. Het proces in vijf stappen dat in dit artikel wordt beschreven, kan u helpen uw project goed van start te laten gaan door vroeg en vaak feedback van belanghebbenden te krijgen en die feedback te gebruiken om duidelijke en beknopte vereisten te genereren. Als u op zoek bent naar een tool om u te helpen uw requirements engineering-proces te beheren, kan Visure Requirements ALM Platform u helpen. Vraag uw Gratis 30-dagproef om te zien hoe ons platform uw volgende project tot een succes kan maken.

Vergeet dit bericht niet te delen!

Top