De meest complete gids voor vereistenbeheer en traceerbaarheid
De do's en don'ts voor het schrijven van vereisten
Inhoudsopgave
Als je net als de meeste mensen bent, hou je waarschijnlijk niet van het schrijven van vereisten. Het is niet het meest opwindende ter wereld, maar het is een cruciaal onderdeel van productontwikkeling. Een beter document met vereisten kan uw organisatie een fortuin besparen met duidelijke communicatie tussen de ontwikkelaar en de belanghebbenden bij het product. Dit weerspiegelt zich op zijn beurt in de hele organisatie, waaronder meer transparantie, minder nabewerking en verbeterde productiviteit.
Hoewel elke organisatie andere vereisten en methodologieën heeft, blijven de basisprincipes voor het schrijven van vereisten hetzelfde. In dit artikel zullen we enkele tips delen die u kunnen helpen bij het verbeteren van uw schrijfvaardigheid en die u kunnen helpen bij het schrijven van duidelijke en scherpe eisenspecificaties.
Wat is Vereistenspecificatie?
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.
Wat betekenen 'Best Practices' in Requirements Management?
Ik vind het zo interessant dat iedereen het heeft over het willen trainen in 'best practices'. Deze term wordt vaak gebruikt om het soort advies te beschrijven dat we ook kunnen bieden. Wat betekent dat echt? Ik geloof dat we allemaal de mythe hebben gevoed dat best practices de basis kunnen vormen voor het trainen van individuen. Best practices worden niet getraind, maar ervaren.
Als we de best practice-benadering vergelijken met de natuur, weten we dat niet alleen de sterkste, maar ook de meest productieve soorten overleven. Dat is een van de redenen waarom het zo moeilijk is om processen in een organisatie te veranderen. Denk daar even over na. De sterkste en meest productieve beschrijven waarschijnlijk de meerderheid van de individuen die u in vrijwel elke groep in uw organisatie heeft. Ik heb dit keer op keer gezien op het gebied van System Engineering. De sterkste en meest productieve ingenieurs doen hun werk vaak al vele jaren en hebben een specifieke manier waarop ze dit werk doen. Hen vragen om nieuwe technieken en tools uit te proberen is vaak zinloos, omdat ze niet weten hoe dit het toch al geweldige werk dat ze doen, zal verbeteren. Hun praktijk zal overleven als we hen een best-practice-benadering blijven opdringen.
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.
10 do's en don'ts bij het schrijven van vereisten:
Doe #1. 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.
Niet #1. 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.
Doe #2. 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.
Niet #2. Geen uitzonderingen – Een eis mag geen ontsnappingsclausule hebben. Bijvoorbeeld: "Het systeem bepaalt het aantal inlogpogingen, behalve wanneer de gebruiker duidelijk een onjuiste gebruikersnaam heeft ingevoerd".
Doe #3. uitvoerbaar – Zorg ervoor dat het projectbudget en de tijdlijn haalbaar zijn, samen met de beschikbare middelen. Als deze voorwaarde de vereiste kan ondersteunen, is het mogelijk om verder te gaan met het plan.
Niet #3. Zeg nee tegen "verhuurde" clausules – Probeer uit de buurt te blijven van uitspraken als maar, behalve en alleen als dat nodig is.
Doe #4. 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.
Niet #4. Geen afkortingen – Elke eis moet een volledige zin zijn zonder acroniemen of jargon.
Doe #5. Actieve stem – Schrijf altijd met een actieve stem en zorg ervoor dat een van de acteurs het onderwerp is van elke zin.
Niet #5. Wees niet dubbelzinnig – Gebruik geen dubbelzinnige termen zoals ongeveer, enz., en meer van dat soort termen in het vereistendocument. Leg de vereisten zo uit dat alle betrokkenen ze goed begrijpen. Vage uitspraken kunnen leiden tot verkeerde interpretaties en kunnen leiden tot conflicten tussen verschillende belanghebbenden.
Doe #6. Onderwerp & predikaat – Voor elke eis moet er een onderwerp (gebruiker/systeem) en een predikaat (beoogd resultaat, handeling of voorwaarde) zijn.
Niet #6. 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.
Doe #7. 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.
Niet #7. 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.
Doe #8. Correct – Zorg ervoor dat elke zin compleet en grammaticaal correct is met een correct onderwerp, werkwoord en predikaat.
Niet #8. Praat niet in toekomstige tijd – Verwijs niet naar een nog nader te bepalen eis. Uw doel is om het document zo prettig mogelijk te maken om te lezen.
Doe #9. Focus – Vestig de focus door gerommel, te lange zinnen en verwijzingen naar verouderde documenten te elimineren.
Niet #9. 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.
Doe #10. 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.
Niet #10. Gebruik geen onbekende termen – Gebruik geen onbekende termen als "gebruiksvriendelijk, veelzijdig en robuust", aangezien dit problemen kan opleveren bij het definiëren van testgevallen. Deze woorden hebben vaak verschillende betekenissen voor verschillende mensen.
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
Het specificeren van vereisten is een cruciaal proces bij softwareontwikkeling, maar het kan een uitdaging zijn om goede vereisten te schrijven. De 20 tips die we hebben gegeven, zouden u moeten helpen betere vereisten te schrijven, waardoor het proces voor alle betrokkenen soepeler verloopt. Als je het schrijven van requirements naar een hoger niveau wilt tillen, overweeg dan om een tool als Visure Requirements ALM Platform te gebruiken. Vraag een Gratis 30-dagproef vandaag nog en zie hoe ons platform u kan helpen bij het stroomlijnen van uw vereistenverzamelings- en beheerprocessen.
Vergeet dit bericht niet te delen!
