Een van de belangrijkste onderdelen van elk softwareontwikkelingsproject is het opstellen van gedetailleerde, nauwkeurige vereisten. Zonder een duidelijk begrip van wat er gebouwd moet worden, is het onmogelijk om een ​​hoogwaardig eindproduct te maken. Helaas is het schrijven van goede requirements vaak makkelijker gezegd dan gedaan. De belangrijkste reden dat mensen slechte eisen schrijven, is dat ze geen training of ervaring hebben gehad met het schrijven van goede eisen. Als u of uw personeel problemen heeft met het schrijven van goede vereisten, kunt u baat hebben bij begeleiding bij het schrijven van goede vereisten. Door de tijd te nemen om te leren hoe u betere vereisten kunt schrijven, kunt u de algehele kwaliteit van uw softwareontwikkelingsprojecten verbeteren en uzelf een hoop kopzorgen besparen.

Waarom mislukken Systems Engineering-projecten?

Waarom mislukken projecten in sterk gereguleerde industrieën? Veel onderzoekers hebben onderzocht waarom systemen en softwareprojecten mislukken. De Standish Group heeft in 2009 onderzoek gedaan waaruit blijkt dat de meeste redenen waarom projecten mislukken, verband houden met vereisten.

Dat is een van de belangrijkste redenen waarom het schrijven van goede requirements cruciaal is voor projectsucces. Bovendien brengt het schrijven van goede vereisten vele andere voordelen voor teams met zich mee.

Wat is Vereistenspecificatie?

Eisenspecificatie is een proces waarin eisen worden gedefinieerd, gedocumenteerd en geanalyseerd. Het is een belangrijk onderdeel van softwareontwikkeling omdat het ervoor zorgt dat alle belanghebbenden het eens zijn over de functionaliteit van de software voordat de ontwikkeling begint. Door dit te doen, verkleint u de kans op misverstanden en latere bewerkingen.

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

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 verzamelen, beoordelen en begrijpen van de behoeften en beperkingen van belanghebbenden en gebruikers 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. In deze fase wordt ook gezorgd voor een solide traceerbaarheid tussen de eisen en informatiebronnen. 

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

Waarom is het belangrijk om goede requirements te schrijven?

Er zijn veel voordelen aan het hebben van goede specificaties voor vereisten. Sommigen van hen zijn hieronder opgesomd:

• Helpt ervoor te zorgen dat alle belanghebbenden een gemeenschappelijk begrip hebben van het te ontwikkelen systeem. Dit voorkomt misverstanden in latere ontwikkelingsstadia.
• Dient als referentiepunt voor alle belanghebbenden tijdens het ontwikkelingsproces.
• Helpt eventuele hiaten in de eisen in een vroeg stadium te signaleren.
• Vermindert de totale kosten en tijd van ontwikkeling, omdat herbewerkingen als gevolg van wijzigingen in de vereisten worden voorkomen.

Wat bereiken we met het schrijven van goede eisen?

Er zijn veel dingen die geweldige vereisten helpen bereiken. Sommigen van hen zijn hieronder opgesomd:

• Hoge eisen helpen ervoor te zorgen dat het systeem dat wordt ontwikkeld voldoet aan de behoeften van de gebruikers.
• Ze dienen als basis voor het testen van het systeem om ervoor te zorgen dat het werkt zoals verwacht.
• Ze helpen de totale kosten en tijd van ontwikkeling te verminderen door herbewerking als gevolg van veranderingen in vereisten te voorkomen.
• Grote eisen helpen om het ontwikkelingsproces efficiënter en effectiever te maken.

Uitdagingen bij het schrijven van vereisten

Er zijn verschillende uitdagingen waarmee mensen worden geconfronteerd bij het schrijven van vereisten.

Slecht papierwerk – In sommige organisaties is documentatie van processen niet aanwezig of voldoet deze niet. In dit geval wordt het verzamelen van vereisten een proces in twee stappen: eerst het bestaande proces reverse-engineeren en vervolgens gebieden identificeren die moeten worden verbeterd en geoptimaliseerd. Om te bevestigen dat de vereisten zijn uitgewerkt en nauwkeurig zijn, is het essentieel om de belangrijkste belanghebbenden en materiedeskundigen te identificeren en rechtstreeks met hen in contact te treden. Het tekenen van bedrijfsproceskaarten en het visualiseren van workflows zijn twee uitstekende manieren om dit te doen. Dit helpt bij het elimineren van onjuiste aannames en geeft tegelijkertijd een volledig beeld. Het tekenen van proceskaarten en het weergeven van processen zijn hiervoor twee bruikbare benaderingen.

Tegenstrijdige eisen – Wanneer belanghebbenden verschillende prioriteiten hebben voor hun bedrijfsdoelen, leidt dit tot eisen die met elkaar in strijd zijn. In dergelijke gevallen is het de verantwoordelijkheid van een bedrijfsanalist om alle vereisten in detail te documenteren, vast te stellen welke verzoeken elkaar tegenspreken en belanghebbenden de kans te geven te beslissen wat prioriteit heeft.

U kunt geen beslissingen nemen zonder de input van belanghebbenden te horen, en als bedrijfsanalist heeft u misschien enkele ideeën over wat prioriteit moet krijgen. Het is nog steeds cruciaal om het perspectief van belanghebbenden te horen. Het opzetten van een peiling kan een van de methoden zijn om duidelijkheid te krijgen over wat voor de meerderheid van de belanghebbenden het belangrijkst is.

Onbeschikbaarheid van gebruikersinvoer – Een paar redenen kunnen bijdragen aan het niet beschikbaar zijn van eindgebruikers, en elk heeft zijn eigen oplossing. Soms zijn eindgebruikers bijvoorbeeld zo in beslag genomen door hun dagelijkse werk dat ze niet bereid zijn deel te nemen aan het verzamelen van vereisten.

In dergelijke gevallen kan een bedrijfsanalist het beste het aantal en de duur van de opdrachten beperken. Door voorafgaand aan de bijeenkomst zoveel mogelijk onderzoek te doen, wordt de discussie overzichtelijker en informatiever. Het is bijna alsof u het verzamelen van vereisten verandert in sessies voor het valideren van vereisten. het definiëren van focusgroepen en het identificeren van de meest geschikte eindgebruikers voor elke groep

Focussen op interface in plaats van ervaring – Veel stakeholders en eindgebruikers hebben een duidelijke visie over hoe de nieuwe oplossing eruit moet zien, maar ze weten niet wat ze moet bereiken. De gebruikersinterface van elk systeem is cruciaal, maar het mag de functionaliteit niet definiëren of verstoren.

Bedrijfsanalisten moeten er altijd aan denken om ontwerp- en functionele vereisten gescheiden te houden in hun documentatie. Door meer algemene tools zoals diagrammen, gebruikersverhalen of low-fi prototypes te gebruiken in plaats van ontwerpconcepten, kunnen ze zich blijven concentreren op de functionele aspecten van het verzamelen van vereisten.

Invoer van belanghebbenden – Wanneer belanghebbenden of eindgebruikers ontwerpers proberen te vertellen hoe het systeem zou moeten werken in plaats van wat het systeem zou moeten doen, kan dit leiden tot suboptimale ontwerpen. Om dit te voorkomen, valideert u elke mogelijke 'valse vereiste' door te vragen 'waarom?' totdat je bij het echte probleem komt dat moet worden opgelost.

Communicatievraagstukken – Problemen die kunnen leiden tot miscommunicatie tussen een bedrijfsanalist en andere partijen zijn taalbarrières, verkeerde aannames, onvoldoende uitgelegd vocabulaire en overmatig gebruik van technische termen.

De ideale aanpak om dit probleem te vermijden, is door regelmatig te communiceren en tweerichtingsgesprekken te ontwikkelen. Documenteer de behoeften die je hebt ontdekt en dien ze voor peer review en kritiek in bij verschillende vakspecialisten, maak een woordenlijst van jargon en controleer de uitgangspunten.

Normen voor schrijfvereisten?

EARS zou hier een effectieve methode zijn. Het staat voor Ezo Anaderen tot REISEN Syntax, door Alastair Marvin. 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.

Essentiële onderdelen van een document met vereisten:

De belangrijkste secties van een specificatie van softwarevereisten zijn:

• Zakelijke stuurprogramma's – De redenen waarom de klant een systeem wil bouwen, worden in deze sectie beschreven. In deze paragraaf wordt verder ingegaan op de problemen die de klant ondervindt met het huidige systeem en de kansen die het nieuwe systeem biedt.
• Bedrijfsmodel – Het businessmodel dat het systeem moet ondersteunen, wordt in deze paragraaf besproken. Het bevat verder verschillende andere details, zoals de organisatorische en zakelijke context, de belangrijkste zakelijke functies en processtroomdiagrammen van het systeem.
• Functionele en systeemvereisten – In deze sectie worden doorgaans vereisten beschreven die in een hiërarchische structuur zijn georganiseerd. De functionele vereisten bevinden zich op het hoogste niveau en de gedetailleerde systeemvereisten worden vermeld als subitems.
• Systeemgebruiksscenario's – Deze sectie bestaat uit een Unified Modeling Language (UML) use case-diagram waarin alle belangrijke externe entiteiten worden uitgelegd die met het systeem zullen communiceren en de verschillende use-cases die ze moeten uitvoeren.
• Technische vereisten – In deze sectie worden alle niet-functionele vereisten besproken die deel uitmaken van de technische omgeving en de technische beperkingen waarin de software zal werken.  
• Systeemkwaliteiten – In deze paragraaf worden de talrijke kwaliteiten van het systeem gedefinieerd, zoals betrouwbaarheid, bruikbaarheid, veiligheid, schaalbaarheid, beschikbaarheid en onderhoudbaarheid.
• Beperkingen en veronderstellingen – Alle beperkingen die vanuit het oogpunt van de klant aan het systeemontwerp worden opgelegd, worden in deze sectie beschreven. Ook de verschillende aannames van het engineeringteam over wat te verwachten tijdens de ontwikkeling worden hier besproken.
• Acceptatiecriteria – Details over alle voorwaarden waaraan moet worden voldaan voordat het systeem aan de eindklanten wordt overgedragen, worden in deze sectie besproken.

Kenmerken van een specificatiedocument voor softwarevereisten:

• Clear – De schriftelijke vereisten moeten duidelijk, gemakkelijk leesbaar en begrijpelijk zijn. Geef duidelijk de informatie aan met behulp van bevestigende zinnen die tussen de actoren moeten worden uitgewisseld. Elke eis moet duidelijke succescriteria beschrijven. Probeer eenvoudige woordenschat te gebruiken en afkortingen te vermijden. Bijvoorbeeld: "De gebruiker moet het auditlogboekrapport kunnen bekijken".
• atomair – Elke eis moet worden behandeld als een afzonderlijke testcase. Voegwoorden zoals en, of, enzovoort mogen niet worden gebruikt, omdat ze ertoe kunnen leiden dat vereisten mislopen. Dit is met name cruciaal omdat dit soort termen ertoe kan leiden dat softwareontwikkelaars en testers vereisten over het hoofd zien. Het opsplitsen van gecompliceerde behoeften in kleinere delen totdat elk afzonderlijk kan worden getest, is een manier om dit te voorkomen.
• Ondubbelzinnig – Onduidelijke, onvolledige of tegenstrijdige eisen kunnen leiden tot fouten en herbewerking. Om dit te voorkomen, moeten de vereisten door elke belanghebbende worden beoordeeld voordat ze definitief worden. Dit zal helpen om eventuele hiaten in een vroeg stadium te identificeren, die vervolgens kunnen worden aangepakt.
• Verifieerbaar – Iedereen in het ontwikkelteam moet toegang hebben tot het document, zodat ze er zo vaak als nodig naar kunnen verwijzen. Omdat eisen duidelijk moeten zijn, willen teamleden niet meer informatie. Ze moeten allemaal toegankelijk zijn in het SRS-document.
• Nodig – Elke eis moet iets documenteren dat de gebruikers echt nodig hebben of iets dat nodig is om aan een standaard- of integratiebehoefte te voldoen vanwege het bestaan ​​van een externe interface. Het is ook belangrijk voor elke vereiste om een ​​geautoriseerde bron te hebben.
• Ontwerp onafhankelijk – Elke eis moet definiëren wat nodig is, niet hoe het zal worden geïmplementeerd. De vereisten moeten de kenmerken van het systeem definiëren die extern zullen worden geobserveerd, niet de interne details.
• uitvoerbaar – Elke eis moet technisch uitvoerbaar zijn en moet worden geïmplementeerd rekening houdend met het budget, de deadline en andere beperkingen die van invloed zijn op het project. De vereisten moeten de feitelijke stand van zaken weerspiegelen, inclusief kosten, tijdschema en technologie. Ze mogen niet afhankelijk zijn van toekomstige technologische vooruitgang.
• Volledige – Het vereistendocument moet voldoende informatie bevatten voor uw ontwikkelingsteam en testers om het product te voltooien en ervoor te zorgen dat het zonder bugs aan de vereisten van de gebruiker voldoet.
• Correct – De in de documenten gespecificeerde vereisten moeten zeer nauwkeurig zijn om elke vorm van verwarring te voorkomen. Ze mogen geen mazen, dubbelzinnigheden, subjectiviteit, superlatieven of vergelijkingen bevatten. Daarom moeten we, om de juiste vereisten te schrijven, de juiste informatie verkrijgen en de verzamelde informatie correct documenteren.

Regels voor de reeks juiste vereisten

Er zijn bepaalde regels waaraan de vereisten moeten voldoen om "Correct" te worden genoemd.

• Volledige – Het vereistendocument moet voldoende informatie bevatten voor uw ontwikkelingsteam en testers om het product te voltooien en ervoor te zorgen dat het zonder bugs aan de vereisten van de gebruiker voldoet.
• Consistentie - Zorg voor een consistent detailniveau. Voor gebruikersvereisten moet bijvoorbeeld een eindgebruiker het onderwerp zijn van elke zin. Evenzo moet voor systeemvereisten een systeem het onderwerp zijn van elke zin.
• aanpasbaarheid – Eisen kunnen veranderen gedurende de levenscyclus van het project. Het eisenlogboek moet worden opgeslagen en analyse van de impact van wijzigingen daarin op andere eisen en projectelementen moet mogelijk zijn.
• Prioritering – De eisen moeten worden geclassificeerd vanuit het oogpunt van belangrijkheid. Niet alle gewenste eigenschappen van een systeem zijn even belangrijk. Daarvoor zou het nuttig zijn om een ​​regel op te stellen om de prioriteiten van de vereisten op organisatieniveau te definiëren en aan te passen aan elk project. En werk samen met de gebruikers zodat ze de vereisten kunnen prioriteren.

Visuele vereisten ALM-platform

Visure is een van de meest vertrouwde platformen voor het beheer van de levenscyclus van applicaties die gespecialiseerd is in vereistenbeheer voor organisaties van elke omvang over de hele wereld. De belangrijkste partners van Visure zijn onder meer bedrijfskritische en veiligheidskritische bedrijven. Het bedrijf integreert via de hele Application Lifecycle Management-processen, inclusief risicobeheer, probleem- en defectopsporing, traceerbaarheidsbeheer, wijzigingsbeheer en verschillende andere gebieden zoals kwaliteitsanalyse, versiebeheer van vereisten en krachtige rapportage.  

Als u op zoek bent naar een tool voor vereistenbeheer die u helpt met zowel functionele als niet-functionele vereisten, bekijk dan Visure-vereisten. Met dit platform kunt u eenvoudig alle vereisten van uw project op één plek maken, beheren en volgen.

Conclusie

Om goede software te produceren, is het belangrijk om een ​​goed geschreven eisenspecificatie te hebben. Dit document schetst de behoeften van de klant en wat het systeem moet doen om aan hun verwachtingen te voldoen. Het schrijven van goede eisen kan echter een uitdaging zijn. Er zijn veel standaarden en richtlijnen die moeten worden gevolgd, en er zijn veel verschillende manieren om ze te schrijven, afhankelijk van de taal en tools die je gebruikt. Visure Requirements ALM Platform biedt een cursus die u leert hoe u effectieve requirementsspecificaties schrijft met behulp van best practices en industriestandaarden. De cursus behandelt alle essentiële componenten van een vereistendocument, van structuur tot opmaak, evenals het gebruik van verschillende talen voor het schrijven van vereisten. Het benadrukt ook de kenmerken van hoge eisen, zodat u documenten kunt maken waar uw team graag mee zal werken. Als je meer wilt weten over het schrijven van effectieve vereisten, probeer dan de Vereisten Specificatie Cursus: door Visure Vereisten ALM Platform vandaag!