Hoe implementeren we de eisenanalyse?

Hoe ziet het planningsproces eruit?

De eisenanalyse maakt deel uit van het planningsproces, dat er als volgt uit moet zien:

1. A project visie die de uiteindelijke product worden gemaakt.
2. Een algemeen actieplan of idee dat aangeeft wat er moet gebeuren om onze doelen te bereiken.
3. Lijst met basistaken die de werkfasen van het project bepalen.
4. Tijdsplanning, waarin we bepalen wat en wanneer moet worden geleverd.
5. Gedetailleerde planning van individuele taken die tijdens de derde fase zijn gemaakt.

De eisenanalyse omvat de eerste drie punten van het planningsproces.

Projectvisie

In dit stadium moeten we onszelf enkele basisvragen stellen:

1. Wat willen we doen?

Zeker, op dit moment weten we al waar we naar streven en het projectidee is al lang gepresenteerd en doordacht, maar het is de moeite waard om er dieper over na te denken. Misschien ontdekken we nieuwe kwesties die de moeite waard zijn om uit te leggen. De volgende punten kunnen hierbij van pas komen:

• Welk probleem moet dit project oplossen?
• Wie wordt de eindgebruiker?
• Maken we een interface voor gebruikers? Is de creatie ervan gepland in de toekomst? Is het type interface dat we maken (desktop of mobiel) bepaald? Geven we om RWD?
• Zijn er vergelijkbare toepassingen? Wat zijn hun voor- en nadelen?
• Zijn er al eerste ontwerpen of mockups van het project gemaakt?
• Is het project afhankelijk van externe toepassingen? Hebben of kennen we hun beperkingen?
• Weten we iets over de verwachte prestaties en het beveiligingsniveau?

2. Wat zijn de vereisten?

Nu is het tijd om een lijst met vereisten voor het project op te stellen. Naast functionele eisen specificeren we eisen die niet gerelateerd zijn aan functionaliteiten: bruikbaarheid, reactiesnelheid, snelheid, prestaties en beveiliging.

Laten we controleren of elk van de vereisten voldoet aan de volgende criteria:

• is compleet - we hebben het volledige plaatje,
• correct is - waarheidsgetrouw en verwacht,
• haalbaar is - haalbaar en andere vereisten dit niet teniet doen,
• is noodzakelijk - het is nodig om het systeem te laten werken of wordt vereist door de klant,
• ondubbelzinnig is - leesbaar en onmogelijk verkeerd te interpreteren,
• verifieerbaar is - na implementatie, door observatie en testen, is het mogelijk om vast te stellen of aan deze eis is voldaan of niet.

3. Wat is het uiteindelijke doel?

Het is de moeite waard om hier een eenvoudige visualisatie van de werking van het project te maken. Niets helpt om het idee van het project volledig te begrijpen zoals het tekenen van een basisstroom of gewoon in punten op het bord schrijven wat er achtereenvolgens moet gebeuren. In het geval van een applicatie met een gebruikersinterface is het ideaal om zelfs de eenvoudigste mockups te hebben.

4. Wat zijn de prioriteiten?

Net als bij het bouwen van een huis, moeten IT-projecten aan het begin bij nul beginnen en dan gericht zijn op wat je het meest nodig hebt. Aan het begin is het daarom nodig om op basis van de lijst met vereisten een lijst op te stellen van alle mogelijke functies die een bepaald project zal uitvoeren en vervolgens af te spreken welke daarvan de hoogste prioriteit hebben en zo snel mogelijk moeten worden uitgevoerd en welke van het type "nice-to-have" zijn.

Het resultaat van de hele projectvisualisatiefase zou een algemeen beeld moeten zijn van hoe het project zou moeten werken, hetzij door middel van mockups of de getekende stroom van activiteiten. We zouden ook een lijst moeten krijgen van alle mogelijke functies die een bepaald project moet vervullen en ook moeten weten welke prioriteit elk van hen heeft.

Projectvisualisatie is een belangrijk moment tijdens de analyse van de vereisten. Het helpt om de essentie van het probleem grondig te begrijpen en hoe beter de materialen die het probleem illustreren, hoe efficiënter de volgende fasen van de planning.

Actieplan

In dit stadium bepalen we al hoe we ons de werking van het project als geheel voorstellen. Het is goed om een paar ideeën voor de uitvoering te hebben, over elk ervan na te denken en te discussiëren, en hun zwakke en sterke punten te benadrukken. Het is ook de moeite waard om een gekozen idee hier gedetailleerd uit te werken, zo niet alle.

Dit stadium is ook het moment om na te denken over puur technologische kwesties, niet alleen in welke taal of in welk framework het project geschreven zal worden, maar ook welke aanvullende tools we nodig hebben, besluiten we bijvoorbeeld om de AWS stack te gebruiken of misschien iets anders. Als we twijfelen tussen bepaalde technologieën of geen idee hebben wat te gebruiken, dan is het de moeite waard om zo'n beslissing op tijd te verschuiven en te delegeren naar een onderzoekstaak. Natuurlijk kunnen we dit alleen doen als verdere planning niet wordt geblokkeerd door dergelijk onderzoek. Anders kunnen we ze veilig koppelen aan de taken in de sprint.

Belangrijkste taken

Zodra we het projectplan hebben opgesteld, gaan we verder met het definiëren van de hoofdtaken, die vervolgens in detail worden besproken en opgesplitst in kleinere taken door de ontwikkeling team bij het plannen van een nieuwe sprint. Het is belangrijk om elke taak zo nauwkeurig mogelijk te beschrijven.

Samenvatting

Zoals eerder gezegd, hangt het proces van eisenanalyse af van de complexiteit van het project. Er zijn makkelijkere en moeilijkere problemen, en er zijn ook problemen die al door iemand zijn opgelost en compleet nieuwe problemen waar je langer bij stil moet staan. Hoe dan ook, er zijn enkele belangrijke tips om in gedachten te houden:

• Communicatie. Dit is het belangrijkste onderdeel van elke projectlevenscyclus; alles moet duidelijk gedefinieerd en uitgelegd worden.
• Het probleem snel begrijpen. Het is geweldig om projectdocumentatie geschreven te hebben, maar laten we onthouden dat het zo beknopt mogelijk moet zijn en geen duizend pagina's in beslag moet nemen. Elk lid van de ontwikkelingsteam moet er toegang toe hebben en moet de projectvisie snel kunnen begrijpen.
• Eenvoud boven alles. Laten we proberen wat we plannen zo eenvoudig mogelijk te maken, eenvoudigere oplossingen kiezen die in de toekomst gemakkelijk kunnen worden ontwikkeld, of ze opgeven wanneer de noodzaak zich voordoet.
• Je zult het niet nodig hebben. Aangezien we ons bij het programmeren laten leiden door het YAGNI-principe, hebben we het hier achter in het hoofd en versnellen we niet te veel.
• Veranderingen. Laten we er niet bang voor zijn; vroeg of laat heeft elk project ze nodig. Laten we onszelf ook niet wijsmaken dat wat we vandaag plannen voor altijd zal werken. Tegelijkertijd moeten we veranderingen niet behandelen als iets slechts en ongewenst. Veranderingen moeten synoniem zijn met verbetering en dat is wat we willen: dat het project het beste is.
• Tijd. Laten we de planning niet te lang laten duren. Als we een probleem hebben dat ons blokkeert, laten we dan buiten naar oplossingen zoeken of de gemakkelijkste optie kiezen.

De bovenstaande aspecten zijn altijd de moeite waard om te onthouden bij het analyseren van de vereisten, en dan zal het soepel verlopen en de basis vormen van een goed gepland project.

Lees meer:

• Wat is de beste projectmanagementaanpak voor softwareontwikkeling?
• Codest's goede praktijken voor het bouwen van software. Onze aanpak van het klanttraject
• Een beknopte gids voor het bouwen en ontwikkelen van je eigen marktplaats. Wat is de moeite waard om te weten?