De meest complete gids voor vereistenbeheer en traceerbaarheid

Vereisten Status & Wijzigingen aanvragen

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. 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!

Vergeet dit bericht niet te delen!