De meest complete gids voor vereistenbeheer en traceerbaarheid
Hoe geweldige vereisten te schrijven
Inhoudsopgave
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.
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.
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 voorkomen, is door regelmatig te communiceren en tweerichtingsgesprekken te voeren. Documenteer de behoeften die je hebt ontdekt en leg ze voor collegiale toetsing en kritiek voor aan verschillende vakspecialisten, maak een verklarende woordenlijst van jargon en controleer de uitgangspunten.
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.
20 tips om betere vereisten te schrijven
Elke organisatie heeft een andere manier van werken en dus ook andere eisen. Daarom kan het proces van requirementsmanagement ook variëren. Maar een ding dat consistent blijft, zijn de basisprincipes van schrijfvereisten. Hieronder staan 20 tips om betere requirements te schrijven.
- Een per keer – 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.
- Spreek "wat" niet "hoe" – De focus moet liggen op wat het systeem zal doen, niet hoe het het doet. Vermijd bovendien dat u te diep in ontwerponderwerpen gaat, zoals veldnamen, programmeertaalobjecten en softwareobjecten. Als u merkt dat u deze onderwerpen bespreekt in het document met vereistenspecificaties, doe dan een stap terug - dit betekent waarschijnlijk dat u te specifiek wordt.
- te verifiëren – Een ander ding om in gedachten te houden bij het organiseren van requirements is dat ze altijd toetsbaar moeten zijn. Dit betekent dat gecontroleerd moet kunnen worden of het systeem aan de betreffende eis voldoet. Dit verwijst ook naar ons volgende punt: traceerbaarheid. Als een eis vol vage termen staat, wordt het moeilijker om te analyseren en te verifiëren of het systeem daadwerkelijk aan deze normen voldoet. Streef daarom zoveel mogelijk naar duidelijkheid en precisie in uw taal, zodat het verzamelen van vereisten geen dubbelzinnig proces is.
- Traceerbaarheid – Traceerbaarheid in projectmanagement verwijst naar het zorgen dat eisen worden gekoppeld aan andere componenten in het project. Hierdoor kunnen projectmanagers, ontwikkelaars en belanghebbenden de volledige levenscyclus van een vereiste volgen, van begin tot eind, in alle richtingen en met andere delen van het systeem. Als je de traceerbaarheid goed beheert, vermijd je code die aan geen enkele eis voldoet ('stray'-code) en zorg je ervoor dat elke testcase minimaal één eis dekt. U kunt requirements traceerbaar maken door ze te labelen met een unieke identifier en informatie over hun bron te verstrekken in een centrale repository die toegankelijk is voor alle teamleden.
- uitvoerbaar – Zorg ervoor dat het projectbudget en de tijdlijn haalbaar zijn, samen met de beschikbare middelen. Als deze voorwaarden de eis kunnen ondersteunen, is het mogelijk om verder te gaan met het plan.
- 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.
- Uitzonderingen – Een eis mag geen ontsnappingsclausule hebben. Bijvoorbeeld: "Het systeem bepaalt het aantal inlogpogingen, behalve wanneer de gebruiker duidelijk een onjuiste gebruikersnaam heeft ingevoerd".
- Actieve stem – Schrijf altijd met een actieve stem en zorg ervoor dat een van de acteurs het onderwerp is van elke zin.
- Zeg nee tegen "verhuurde" clausules – Probeer uit de buurt te blijven van uitspraken als maar, behalve en alleen als dat nodig is.
- Geen afkortingen – Elke eis moet een volledige zin zijn zonder acroniemen of jargon.
- Onderwerp & predikaat – Voor elke eis moet er een onderwerp (gebruiker/systeem) en een predikaat (beoogd resultaat, handeling of voorwaarde) zijn.
- Clarity – Vermijd dubbelzinnigheid veroorzaakt door het gebruik van acroniemen zoals, enz., ca. en dergelijke.
- Gebruik de juiste voorwaarden – Onbekende termen als gebruiksvriendelijk, veelzijdig en robuust kunnen problemen opleveren bij het definiëren van testgevallen. Deze woorden hebben vaak verschillende betekenissen voor verschillende mensen.
- Speculaties kunnen schade veroorzaken – niet raden; maak geen lijsten met functies die uitgesloten zijn. Zeggen dat u wilt dat een systeem alle onverwachte storingen aankan, is pure fantasie, aangezien geen enkel systeem ooit 100 procent zal zijn wat u wilt dat het is. Vermijd dubbele en tegenstrijdige verklaringen.
- Vermijd opties – Bied geen ideeën of opties aan. Je kunt deze herkennen in elke uitspraak die de zinsdelen mag, zou, zou of zou moeten bevatten.
- Georganiseerd papierwerk doet wonderen – Houd de vereisten op één plek georganiseerd om de leesbaarheid van uw document te verbeteren en verspil geen tijd aan kruisverwijzingen naar meerdere bronnen.
- Praat met wat we hebben – Verwijs niet naar een nog nader te bepalen eis. Uw doel is om het document zo prettig mogelijk te maken om te lezen.
- Wat moet worden gebruikt en waar? – "Zal" moet worden gebruikt waar eisen worden gesteld, "Zal" moet worden gebruikt om feiten weer te geven; & “Moeten” om een te bereiken doel te vertegenwoordigen.
- Correct – Zorg ervoor dat elke zin compleet en grammaticaal correct is met een correct onderwerp, werkwoord en predikaat.
- Focus – Vestig de focus door gerommel, te lange zinnen en verwijzingen naar verouderde documenten te elimineren.
Visuele vereisten ALM-platform
Visuele vereisten ALM-platform is een van de meest vertrouwde platformen voor het beheer van de levenscyclus van applicaties die gespecialiseerd zijn 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!
Vergeet dit bericht niet te delen!
