De meest complete gids voor vereistenbeheer en traceerbaarheid

Eisen moeten kwaliteit hebben om het project succesvol te laten zijn. Door normen en voorwaarden te stellen, kunnen teams hun voortgang bij het bereiken van die doelen evalueren. De gebruikte statistieken zullen verschillen, afhankelijk van het werk dat wordt gedaan; enkele algemene indicatoren voor trackingvereisten zijn echter:

Dekking testen – Hoeveel functies van elk systeem zijn getest?
Beoordelingsnauwkeurigheid – Is er een hoge mate van juistheid in de specificaties?
Functionaliteit Volledigheid – Zijn alle functionaliteiten voldoende gedetailleerd gespecificeerd?
Acceptatiecriteria Duidelijkheid – Zijn de acceptatiecriteria van de gebruiker gemakkelijk te herkennen aan de documentatie?
Verander verzoeken - Hoeveel wijzigingsverzoeken zijn er ingediend sinds de specificaties zijn geschreven?

Door deze kwalitatieve factoren regelmatig te meten, kunt u vaststellen waar uw team zich op moet concentreren en de kwaliteit van uw projecten moet verbeteren.

Hoe de kwaliteit van eisen te meten

Waarom is het belangrijk om de kwaliteit van requirements te beoordelen?

We moeten eerst bepalen of we een vereistenprobleem hebben en hoe groot het probleem precies is, om nauwkeurig te kunnen berekenen hoeveel moeite het kost om onze ontoereikende middelen om te zetten in bevredigende middelen.
Als supervisors streven we ernaar om ervoor te zorgen dat ons team productief werkt tijdens het opstellen van een vereistenspecificatie of het uitvoeren van een vereistenanalyse. Behalen ze hun doelstellingen?
Rekening houdend met de diverse scenario's, hebben we een maatstaf opgesteld voor onze vereistenspecificaties in termen van de waarde van een kwaliteitsmaatstaf. We hebben vier waarden ingesteld om elke situatie respectievelijk weer te geven:
- Een originele roman maken in een moeilijke omgeving is geen sinecure.
- Een innovatief verhaal creëren zonder enige druk of beperking.
- Mondaine ontwikkeling
- Verwerving van niet-ontwikkelingsgerelateerde items
Om de hoogste kwaliteit voor onze projecten te garanderen, stellen we een benchmark op voor beoordelingen van systeemvereisten en beoordelingen van softwarevereisten.

Als het gaat om technische metrieken, is een kwaliteitsmaatstaf voor vereisten een van de krachtigste tools die beschikbaar zijn. Historisch gezien is het immers een veelvoorkomend probleem geweest voor ingenieurs om iets anders te ontwikkelen dan aanvankelijk de bedoeling was. Hoewel het gebruik van een objectieve standaard niet altijd perfecte resultaten garandeert, kan het potentiële risico's en gebreken in het eindproduct drastisch verminderen.

Product afmetingen

Inzicht in het aantal vereisten in een project is essentieel. Dit kan worden bereikt door middel van use cases, functionele vereisten, gebruikersverhalen, functiebeschrijvingen, event-responstabellen of analysemodellen. De keuze van uw team om deze vereisten te vertegenwoordigen, heeft echter geenszins invloed op hun primaire functie: het implementeren van systeemgedrag op basis van specifieke voorwaarden en functionele behoeften.

Begin uw vereistenbeoordelingsproces door de individuele functionele vereisten te tellen die zijn toegewezen aan een productrelease of ontwikkelingsiteratie. Als verschillende individuen geen vergelijkbare resultaten kunnen krijgen als ze tellen, is het essentieel om rekening te houden met andere soorten misverstanden en onduidelijkheden die in de toekomst kunnen ontstaan. U moet op de hoogte zijn van het aantal vereisten waaruit een release bestaat om de voortgang van uw team nauwkeurig bij te houden. Zonder deze kennis heb je geen enkele manier om te meten wanneer je klaar bent met het project! Door in de gaten te houden hoeveel werk er nog in uw backlog zit, zorgt u ervoor dat iedereen begrijpt wat er moet gebeuren voordat het voltooid is.

Om ervoor te zorgen dat uw functionele vereisten een nauwkeurige maatstaf zijn voor de systeemomvang, is het essentieel voor analisten om ze op een consistent detailniveau te creëren. Een goede manier om dit te doen, is door vereisten op hoog niveau op te splitsen in kleinere onderliggende componenten die afzonderlijk kunnen worden getest. Met andere woorden, testers moeten eenvoudige tests ontwerpen die kunnen vaststellen of elke vereiste correct is geïmplementeerd of niet. Dit zorgt ervoor dat alle taken evenveel implementatie- en testinspanningen vergen, ongeacht hun complexiteit. Om ervoor te zorgen dat de ontwikkelaars en testers elke vereiste goed kunnen implementeren en testen, is het belangrijk om bij te houden hoeveel onderliggende vereisten er zijn. Andere alternatieve dimensioneringsmethoden zijn use case-punten en verhaalpunten, die allemaal de geschatte inspanning meten die nodig is voor een bepaald gedefinieerd stuk functionaliteit.

Hoewel functionele vereisten essentieel zijn, mogen ook niet-functionele vereisten niet over het hoofd worden gezien. Deze specifieke eisen vereisen meer inspanning om effectief te ontwerpen en te implementeren. Bepaalde functionaliteit is afhankelijk van de vermelde niet-functionele behoeften, zoals beveiligingsproblemen, die moeten worden weergegeven in de geschatte omvang van functionele kenmerken. Alle niet-functionele verlangens zullen hier echter niet verschijnen - het is van cruciaal belang om zeker te zijn dat u rekening houdt met hun invloed op uw inschatting! Denk aan de volgende situaties:

Het bieden van meerdere manieren om een bepaalde functie te gebruiken, verbetert de gebruikerservaring; een dergelijke onderneming vergt echter meer tijd en energie van ontwikkelaars dan wanneer er slechts één toegangsmethode beschikbaar is.
Zelfs als u geen nieuwe productfuncties implementeert, kunnen geforceerde ontwerp- en implementatiebeperkingen, zoals externe interfaces om tegemoet te komen aan een bestaande besturingsomgeving, de benodigde hoeveelheid interfacewerk aanzienlijk vergroten.
Om maximale prestaties te garanderen, kan nauwgezet algoritme- en databaseontwerp nodig zijn om snelle reacties te garanderen.
Om aan strenge beschikbaarheids- en betrouwbaarheidseisen te voldoen, is het noodzakelijk om failover- en gegevensherstelmechanismen te bouwen die tijdrovend kunnen zijn. Bovendien kan de systeemarchitectuur die u kiest, ook door deze eisen worden beïnvloed.

Door de toename van de vereisten in de loop van de tijd bij te houden, ongeacht de maatstatistiek die wordt gebruikt, krijgt u nuttige inzichten. Mijn klant merkte dat hun projecten voorafgaand aan de oplevering meestal met zo'n vijfentwintig procent toenamen. Bovendien liepen de meeste van hun projecten minstens vijfentwintig procent langer dan verwacht! Geen toeval hier - het is duidelijk dat er een verband is tussen deze twee trends.

Vereisten Kwaliteit

Neem de tijd om de kwaliteit van uw vereisten te meten door er inspecties op uit te voeren. Documenteer alle defecten die je tegenkomt en verdeel ze in verschillende categorieën, zoals ontbrekende vereisten, onjuiste vereisten, overbodige vereisten, vaagheid, enz. Analyseer daarna deze soorten defecten samen met hun hoofdoorzaak, zodat toekomstige verzoeken van begin tot eind correct worden uitgevoerd. Gebruik deze gegevens als een kans voor verbetering om de efficiëntie van uw aanvraagproces te verhogen! Als u bijvoorbeeld vaststelt dat ontbrekende vereisten meestal een terugkerend probleem zijn, moeten uw elicitatiemethoden worden gewijzigd. Het is mogelijk dat uw bedrijfsanalisten niet genoeg of niet de juiste vragen stellen, of misschien moet u nog meer passende gebruikersvertegenwoordigers betrekken bij het ontwikkelen van behoeften.

Als het team weinig tijd heeft om al hun documentatie met vereisten te onderzoeken, is een efficiëntere optie om een paar pagina's te inspecteren en vervolgens de gemiddelde dichtheid van defecten te berekenen - het aantal defecten per specificatiepagina. Ervan uitgaande dat dit voorbeeld het hele document nauwkeurig weergeeft (wat nogal een aanname kan zijn), kan het vermenigvuldigen met niet-geïnspecteerde pagina's ons een schatting geven van hoeveel verborgen bugs er in onze specificaties kunnen blijven. Onervaren inspecteurs zijn mogelijk niet in staat alle gebreken op te sporen, dus gebruik het geschatte aantal onontdekte gebreken als een minimale schatting. Door gebruik te maken van inspectiesteekproeven kunt u de kwaliteit van het document beoordelen en beslissen of het financieel haalbaar is om de rest van de eisenspecificatie te inspecteren – wat ongetwijfeld ja zal zijn!

Bovendien worden defecten in vereisten vastgelegd die zijn ontdekt nadat de basislijn is vastgesteld. Deze problemen zouden onopgemerkt zijn gebleven tijdens de kwaliteitscontrole tijdens het ontwikkelen van de vereisten. Bereken het succespercentage van uw team bij het vinden van deze fouten in dit vroege stadium - het zal veel kosteneffectiever zijn dan proberen ze te herstellen wanneer het ontwerp en de codering al zijn voltooid!

Inspectiegegevens kunnen u twee zeer waardevolle statistieken opleveren: efficiëntie en effectiviteit. Efficiëntie kwantificeert het gemiddelde aantal gedetecteerde defecten per arbeidsuur, terwijl effectiviteit aangeeft welk deel van alle bestaande gebreken via inspectie is geïdentificeerd - een maatstaf die een indicatie geeft van hoe succesvol uw inspecties (of andere kwaliteitsborgingspraktijken) zijn geweest. Efficiëntie stelt u in staat om de kosten van het ontdekken van een defect door middel van inspectie in te schatten. U kunt deze kosten afwegen tegen het bedrag dat u besteedt aan het afhandelen van defecten in vereisten die later in de ontwikkeling of na oplevering worden gevonden, zodat u kunt bepalen of het verbeteren van de kwaliteit van uw vereisten financieel de moeite waard is.

Vereistenstatus

Om op de hoogte te blijven van het project, volgt u elke vereiste gedurende de hele levensduur. U kunt zelfs een attribuutwaarde toewijzen om die informatie op te slaan voor extra beveiliging en nauwkeurigheid. Dit type statusregistratie helpt het veelvoorkomende dilemma bij softwareprojecten te verminderen – ten onrechte beweren dat het “negentig procent klaar” is. Elke vereiste moet gedurende een bepaald tijdsbestek een van deze statussen hebben:

Bepleit (iemand steunde het krachtig)
Het goedkeuringsproces is succesvol verlopen en de toewijzing is op een baseline geplaatst.
Na het zorgvuldig ontwerpen, scripten en testen van de code, hebben we deze geïmplementeerd.
Nadat de vereiste de tests had ondergaan en doorstaan, werd gecontroleerd of deze met succes in het product was geïntegreerd.
Aan deze eis zal later worden voldaan.
U besluit het te verwijderen en niet te implementeren.
Afgewezen (het concept kreeg nooit groen licht)

Naast de bovengenoemde statusopties zijn er ook andere statussen denkbaar. Sommigen kiezen misschien voor de status "Beoordeeld" om hun vereisten te valideren voordat ze worden toegevoegd aan basisconfiguraties. Als alternatief kunnen organisaties "Geleverd aan klant" gebruiken om te verifiëren dat ze de vereiste intact en correct hebben vrijgegeven.

Als je informeert naar de voortgang van een ontwikkelaar, kan hij antwoorden dat er 87 vereisten zijn voor dit specifieke project. 61 zijn al bevestigd en 9 zijn van kracht, maar wachten nog op verificatie, terwijl 17 nog moet worden afgerond. Het is echter belangrijk op te merken dat deze verzoeken niet allemaal overeenkomen als het gaat om omvang of effect op klanttevredenheid; ze kunnen ook verschillende hoeveelheden inspanning vergen. Als projectmanager zou ik er niet aan twijfelen dat we een goed beeld hadden van de omvang van het subsysteem en hoe dicht het bij voltooiing was. Dit is veel effectiever dan simpelweg zeggen: "Ik ben voor ongeveer negentig procent klaar". Met een algemeen beeld van de voortgang kan ik vol vertrouwen zeggen "het ziet er geweldig uit!"

Verander verzoeken

Om tot succesvol eisenbeheer te komen, moet uw organisatie aandacht besteden aan elke toevoeging, verwijdering en wijziging van eisen. Zo kunt u de status en de implicaties van alle wijzigingsverzoeken volgen. U kunt deze gegevens ook gebruiken om verschillende onderzoeksvragen te beantwoorden, zoals:

Hoeveel wijzigingsverzoeken zijn er gedaan binnen de gestelde termijn?
Hoeveel van de verzoeken zijn beantwoord en hoeveel blijven onopgelost?
Wat was het goedkeuringspercentage voor verzoeken en welk percentage werd geweigerd?
In hoeverre heeft het team energie gestoken in het uitvoeren van elke geautoriseerde wijziging?
Wat is de gemiddelde tijdsduur dat verzoeken open blijven?
Hoeveel items (bijv. vereisten of artefacten) worden gemiddeld beïnvloed door elk ingediend wijzigingsverzoek?

Zorg ervoor dat u alle wijzigingen die tijdens het ontwikkelingsproces zijn aangebracht, bijhoudt na het instellen van een basislijn voor elke release. Bedenk dat één wijzigingsverzoek effect kan hebben op tal van eisen van verschillende aard (gebruikersgericht, functioneel en niet-functioneel). Om te beoordelen hoeveel wijzigingen er in een bepaalde periode zijn doorgevoerd, deelt u het aantal wijzigingen door het totale aantal vereisten voorafgaand aan deze periode (zoals bij het definiëren van uw basislijn).

We willen de volatiliteit van vereisten niet volledig wegnemen. Er is immers vaak een legitieme reden om ze te wijzigen. Maar tegelijkertijd moeten we ervoor zorgen dat ons project veranderingen aankan en aan zijn verplichtingen blijft voldoen. Dichter bij voltooiing komen brengt extra kosten met zich mee wanneer er regelmatig wijzigingen worden aangebracht; dit maakt het moeilijk om te bepalen wanneer u uw product op de wereld loslaat! Naarmate de ontwikkeling vordert, zouden de meeste projecten beter bestand moeten zijn tegen veranderingen; met andere woorden, de mate van acceptatie van wijzigingen zou geleidelijk moeten afnemen totdat deze nul bereikt wanneer de release is voltooid. Een iteratieve aanpak geeft teams meerdere kansen om verbeteringen in latere iteraties op te nemen, terwijl ze toch op schema blijven met de tijdlijn van elke cyclus.

Als uw team wordt overspoeld met wijzigingsverzoeken, is de kans groot dat het elicitatieproces niet alomvattend was of dat er ideeën blijven ontstaan naarmate het project vordert. Als zodanig is het essentieel om bij te houden waar deze veranderingen vandaan komen van marketing, gebruikers, verkopers, managementteams enz. Door deze informatie in de gaten te houden, kunt u bepalen wie en wat aandacht nodig heeft om over het hoofd geziene vereisten te minimaliseren en miscommunicatie in de toekomst te voorkomen.

Wanneer wijzigingsverzoeken gedurende een langere periode onopgelost blijven, is dit een duidelijke indicatie dat uw wijzigingsbeheerproces enige aandacht behoeft. Ik ben persoonlijk getuige geweest van een organisatie die verbeteringsverzoeken had die meerdere jaren oud waren en nog in behandeling waren. Om ervoor te zorgen dat de projectmanager prioriteit geeft aan de belangrijkste items in de backlog, moet dit team specifieke openstaande verzoeken toewijzen aan geplande onderhoudsreleases en andere langlopende uitgestelde wijzigingen omzetten in afgewezen wijzigingen. Op deze manier kunnen ze gemakkelijker eerst aanpakken wat essentieel en urgent is, voordat ze minder dringende zaken aanpakken.

Tijd en moeite

Om optimale prestaties te garanderen, raden we u ten zeerste aan om de hoeveelheid tijd die uw team besteedt aan requirements engineering-taken bij te houden. Dit omvat het opstellen van kwaliteitseisen en het beheren van wijzigingen, het volgen van de voortgang, het creëren van traceerbaarheidsgegevens en andere activiteiten die verband houden met dit proces.

Mensen vragen me vaak hoeveel tijd en energie er moet worden besteed aan de benodigdheden van een project. Dit antwoord hangt sterk af van de grootte, het team, de organisatie die het heeft gebouwd en het doel ervan. Door uw inspanningen bij te houden die zijn geïnvesteerd in kritieke taken voor projecten als deze, kunt u toekomstige projecten beter plannen met nauwkeurige schattingen.

Als uw team eerder een project heeft voltooid en 10% van zijn tijd heeft besteed aan de vereisten, heeft u bij nader inzien misschien gemerkt dat de kwaliteit van die vereisten veel kan worden verbeterd. Als de projectmanager wordt geconfronteerd met een ander soortgelijk project, zou het verstandig zijn om ervoor te zorgen dat er meer moeite wordt gedaan om grondige specificaties op te stellen - meer dan tien procent van de totale beschikbare middelen zou voldoende moeten zijn!

Terwijl u gegevens verzamelt en analyseert, vergelijkt u de projectontwikkelingsinspanning met een maatstaf voor de productomvang. Uw gedocumenteerde vereisten geven een idee van de totale omvang. Om preciezer te zijn, u kunt de inspanning correleren om testbare individuele specificaties te tellen, casuspunten of functiepunten te gebruiken - alles wat in verhouding staat tot de afmetingen van uw product. Verwijzen naar figuur 1 levert in deze context een meetlat op voor het evalueren van de capaciteiten van uw ontwikkelteam, wat verder helpt bij het voorspellen van release-inhoud en bij het nauwkeurig bepalen ervan! Door groottegerelateerde gegevens voor uw product te verzamelen en de bijbehorende implementatie-inspanningen te noteren, kunt u nauwkeurige schattingen formuleren ter voorbereiding op soortgelijke toekomstige projecten.

Angst kan in de hoofden van velen blijven hangen; vrees dat het ontwikkelen van een softwarematig meetprogramma kostbare tijd zal wegnemen van essentiële taken. Integendeel, het implementeren van een efficiënt en gericht metriek stelsel kost niet al te veel moeite of energie. Het enige dat u hoeft te doen, is een basisinfrastructuur bouwen voor het verzamelen en analyseren van gegevens, en uw teamleden aanmoedigen om enkele relevante details over hun werkactiviteiten vast te leggen. Wanneer je binnen je bedrijf een cultuur creëert op basis van metrics, is het verbazingwekkend wat je via deze methode kunt leren!

Conclusie

Eisen opsporen en analyseren zijn essentiële componenten van softwareontwikkeling. Zonder hen kan een project mislukken vanwege ontbrekende of onjuiste specificaties, wat leidt tot kostbare nabewerking en mogelijk onbevredigende resultaten. Daarom is het belangrijk om ervoor te zorgen dat u over een efficiënt proces beschikt voor het verzamelen van vereisten en het verifiëren van de nauwkeurigheid gedurende de hele projecttijdlijn. Met goed beheer kunnen teams succes behalen door gedetailleerde vereisten te creëren die nauwkeurig alle gewenste functionaliteit beschrijven, zodat niets over het hoofd wordt gezien. Door bestaande processen en statistieken regelmatig te evalueren voor elke onderneming, kunnen teams beter begrijpen wat voor hen het beste werkt bij het zoeken naar feedback van gebruikers tijdens ontwikkelingscycli. Dit zal helpen om projecten op schema te houden en bij te dragen aan resultaten van hogere kwaliteit.

Vergeet dit bericht niet te delen!