Requirements: haalbaarheid, wenselijkheid en levensvatbaarheid
Het is belangrijk om aan het begin van elk onderzoeksrapport de requirements (vereisten) duidelijk te definiëren. Deze requirements vertegenwoordigen de specifieke criteria en verwachtingen die door de opdrachtgever en andere belangrijke belanghebbenden, zoals eindgebruikers, worden gesteld aan de oplossing die voor het probleem moet worden ontwikkeld.
De requirements moeten gevarieerd zijn en worden onderverdeeld in diverse ontwerpcriteria: haalbaarheid, wenselijkheid en levensvatbaarheid.
- Haalbaarheid onderzoekt of de voorgestelde oplossing technisch, financieel en operationeel uitvoerbaar is binnen de beschikbare middelen en tijdlijnen.
- Wenselijkheid beoordeelt in hoeverre de voorgestelde oplossing voldoet aan de behoeften en verwachtingen van belanghebbenden, inclusief gebruikers, klanten en andere betrokken partijen.
- Levensvatbaarheid omvat de duurzaamheid en effectiviteit van de oplossing op lange termijn, inclusief aspecten zoals marktpotentieel, concurrentiepositie en risicobeheer. Met andere woorden, levensvatbaarheid richt zich op de langdurige effectiviteit en continuïteit van de oplossing.
Door de vereisten eerst te benoemen en achteraf te evalueren aan de hand van de drie criteria, kunnen we de meest geschikte oplossing voor het probleem identificeren en de kans op succes bij de implementatie maximaliseren.
Requirements in een onderzoek/verslag/scriptie vermelden
De requirements moeten aan het begin van het onderzoek worden beschreven. Vervolgens is het belangrijk om onder het hoofdstuk “Methoden en Technieken” toe te lichten hoe deze requirements zijn getest. In het hoofdstuk Resultaten kan vervolgens worden besproken in hoeverre de geselecteerde oplossing (zoals bijvoorbeeld een proof of concept) voldoet aan de vereisten. Als hulpmiddel hiervoor kan een scoretabel worden gebruikt.
In het hoofdstuk Implementatieplan kan worden verwezen naar de stappen die nodig zijn om te nemen, zodat de criteria van wenselijkheid, haalbaarheid en levensvatbaarheid gewaarborgd blijven. Concreet betekent dit: hoe kan de opdrachtgever ervoor zorgen dat de oplossing (of proof of concept) wordt gerealiseerd, welke kosten komen erbij kijken om de haalbaarheid te bewijzen, en welke verdere stappen kan de opdrachtgever nemen om ervoor te zorgen dat de oplossing op lange termijn standhoudt? Wat zijn de aandachtspunten en risico’s (risicomanagement/risicobeheer), en zijn er eventuele aanbevelingen? Hierbij is het ook belangrijk om stil te staan bij mogelijke gevolgen en consequenties, evenals randvoorwaarden zoals wetgeving (waaronder AVG) en ethiek.
Lees ook deze blog over de criteria van een goed onderzoeksrapport.
Flexibiliteit en communicatie in onderzoek
Wees je ervan bewust dat een onderzoek geen lineair proces is. Wat je aan het begin van je onderzoek vaststelt, kan gaandeweg veranderen. Dit geldt ook voor de eisen en wensen (requirements). In het begin stel je deze requirements in overleg met je opdrachtgever vast, maar gedurende het onderzoek kun je deze aanpassen op basis van nieuwe inzichten die je verkrijgt. Dit kan bijvoorbeeld gebeuren door gesprekken met experts, doelgroepen en andere belangrijke stakeholders te houden. Daarom is het essentieel om goed te weten wie belangrijk is voor je onderzoek, zodat je de eisen en wensen nauwkeurig kunt afstemmen op hun behoeften. Wees dus vrij om gedurende je onderzoek requirements en andere noodzakelijke informatie aan te passen of aan te vullen met waardevolle gegevens. Dit zal de kwaliteit van je onderzoek versterken en je in staat stellen om met sterke bewijzen standpunten, resultaten en conclusies beter te onderbouwen.
Het is natuurlijk belangrijk om regelmatig, bijvoorbeeld eens per maand, met je opdrachtgever om tafel te zitten om de voortgang te bespreken en eventuele wijzigingen, zoals in de requirements, te bespreken. Op deze manier creëer je draagvlak en blijft je opdrachtgever op de hoogte van de voortgang. Dit kan leiden tot nieuwe inzichten of suggesties die je van je opdrachtgever kunt krijgen, wat de inhoud van je onderzoek nog verder kan verbeteren.
Requirements en kwaliteitseisen
Wees je ervan bewust dat requirements en kwaliteitseisen niet dezelfde betekenis hebben. Beide termen, kwaliteitseisen en requirements, worden vaak gebruikt in projectmanagement, product- en serviceontwikkeling, en softwareontwikkeling, maar hebben dus niet dezelfde betekenis:
- Kwaliteitseisen: Dit zijn de criteria waaraan een product of dienst moet voldoen om als van goede kwaliteit te worden beschouwd. Kwaliteitseisen zijn meestal breed en omvatten aspecten zoals betrouwbaarheid, gebruiksvriendelijkheid, prestaties, veiligheid, enzovoort. Ze beschrijven de algemene kenmerken van het eindproduct of de dienst die de klant of gebruiker verwacht.
- Requirements (eisen): Dit zijn specifieke functionaliteiten, kenmerken of prestaties die een product of dienst moet hebben om te voldoen aan de behoeften van de klant, opdrachtgever en andere stakeholders.
Kortom, kwaliteitseisen zijn meer algemene criteria die de algemene kwaliteit van het eindproduct definiëren, terwijl requirements specifieke functionaliteiten of kenmerken beschrijven die nodig zijn om aan die kwaliteitseisen en andere eisen te voldoen.
Voorbeelden van requirements
Hieronder volgen nog enkele voorbeelden van requirements per criterium. Houd er rekening mee dat hieronder slechts een aantal voorbeelden zijn gegeven, en dat ze niet allemaal in je onderzoek hoeven terug te keren. Stel dus altijd je requirements in samenspraak met stakeholders.
Haalbaarheid:
1. Technische haalbaarheid: Het gebruik van bestaande technologieën om een oplossing te implementeren.
2. Financiële haalbaarheid: Het beschikbare budget voor het ontwikkelen en implementeren van de oplossing.
3. Operationele haalbaarheid: Het vermogen om de voorgestelde oplossing te integreren in bestaande systemen en processen zonder verstoringen.
4. Tijdlijnhaalbaarheid: Het realistisch vaststellen van deadlines en mijlpalen voor het project.
5. Resourcehaalbaarheid: Beschikbaarheid van personeel, expertise en andere middelen die nodig zijn voor de uitvoering van het project.
6. Schaalbaarheid: De mogelijkheid om de oplossing aan te passen aan groeiende behoeften en omvang van het project.
7. Technologische infrastructuur: Het controleren van de beschikbaarheid en compatibiliteit van de benodigde infrastructuur.
8. Juridische en regelgevende haalbaarheid: Het voldoen aan wet- en regelgeving met betrekking tot privacy, beveiliging en andere relevante gebieden.
9. Risicobeheer: Identificeren en beheren van potentiële risico’s die de uitvoering van het project kunnen belemmeren.
10. Beschikbaarheid van leveranciers en partners: Het beoordelen van de beschikbaarheid en betrouwbaarheid van externe leveranciers en partners die nodig zijn voor het project.
Wenselijkheid:
1. Gebruiksvriendelijkheid: De mate waarin de oplossing intuïtief en gemakkelijk te gebruiken is voor eindgebruikers.
2. Klanttevredenheid: Het voldoen aan de verwachtingen en behoeften van klanten en belanghebbenden.
3. Functionaliteit: Het bieden van de juiste functies en mogelijkheden om aan de specifieke behoeften van gebruikers te voldoen.
4. Flexibiliteit: De mogelijkheid om de oplossing aan te passen aan veranderende eisen en omgevingen.
5. Esthetiek: Het visuele ontwerp en de presentatie van de oplossing om aantrekkelijk te zijn voor gebruikers.
6. Prestaties: De snelheid, betrouwbaarheid en responsiviteit van de oplossing tijdens gebruik.
7. Toegankelijkheid: Het verzekeren dat de oplossing toegankelijk is voor alle gebruikers, inclusief mensen met verschillende vaardigheden en beperkingen.
8. Compatibiliteit: De interoperabiliteit van de oplossing met verschillende apparaten, platforms en systemen.
9. Veiligheid en privacy: Het waarborgen van de veiligheid en bescherming van gevoelige gegevens en informatie.
10. Merkreputatie: Het behoud of verbeteren van de reputatie en perceptie van het merk bij de gebruikers en de markt.
Levensvatbaarheid:
1. Marktpotentieel: De omvang van de markt en de groeimogelijkheden voor de oplossing.
2. Concurrentiepositie: Het vermogen om te concurreren met andere vergelijkbare oplossingen op de markt.
3. Return on Investment (ROI): Het rendement dat wordt behaald door de investering in de ontwikkeling en implementatie van de oplossing.
4. Lange-termijnwinstgevendheid: De duurzaamheid van het verdienmodel en de winstgevendheid op lange termijn.
5. Schaalbaarheid van de business: Het vermogen om de oplossing uit te breiden naar nieuwe markten of doelgroepen.
6. Klantretentie: Het vermogen om klanten te behouden en hun loyaliteit op lange termijn te verzekeren.
7. Operationele efficiëntie: Het vermogen om de operationele kosten te verlagen en de efficiëntie te verhogen na implementatie.
8. Risicobeheer: Het vermogen om potentiële risico’s te identificeren en te beheren die de levensvatbaarheid van de oplossing kunnen bedreigen.
9. Innovatiepotentieel: De mogelijkheid om de oplossing voortdurend te innoveren en aan te passen aan veranderende marktomstandigheden.
10. Duurzaamheid: Het vermogen van de oplossing om positieve sociale en milieu-impact te genereren op lange termijn.
Goede requirements worden zoveel mogelijk SMART geformuleerd. SMART staat voor Specifiek, Meetbaar, Acceptabel, Realistisch en Tijdgebonden. Door requirements op deze manier te formuleren, kunnen ze duidelijk, concreet en haalbaar worden gedefinieerd, wat essentieel is voor een succesvol onderzoeksrapport.
MoSCoW-methode
Een handige methode om de vereisten te prioriteren is de MoSCoW-methode, die helpt om ze te classificeren op basis van hun urgentie en belang voor het project. Het opnemen van vereisten waarborgt dat het onderzoek zich richt op het vervullen van de behoeften van de belangrijkste belanghebbenden en dat de uiteindelijke oplossing effectief zal zijn in het aanpakken van het probleem. Bovendien kan later in het hoofdstuk Resultaten eenvoudiger worden aangetoond dat er aan gestelde eisen en wensen van verschillende stakeholders is voldaan, wat kan aantonen dat het gewenste effect met de gecreëerde oplossing kan worden gerealiseerd.
Over Moscow methodiek: De MoSCoW-methode is een techniek die vaak wordt gebruikt in projectmanagement en requirements engineering om de prioriteiten van eisen en vereisten te bepalen. De naam “MoSCoW” is een acroniem dat staat voor:
– Must have: Dit zijn de essentiële eisen die absoluut aanwezig moeten zijn in het eindproduct of de oplossing. Deze eisen zijn van cruciaal belang voor het succes van het project en vormen de kernfunctionaliteit.
– Should have: Dit zijn belangrijke eisen die sterk worden aanbevolen om op te nemen in het eindproduct of de oplossing. Hoewel ze niet essentieel zijn, dragen ze aanzienlijk bij aan de waarde en bruikbaarheid ervan.
– Could have: Dit zijn optionele eisen die wenselijk zijn maar niet van kritiek belang. Ze kunnen worden opgenomen als er voldoende tijd en middelen beschikbaar zijn, maar kunnen ook worden uitgesteld naar latere versies van het product.
– Won’t have (at this time): Dit zijn eisen die bewust zijn uitgesloten van de huidige scope van het project. Ze worden niet geïmplementeerd in de huidige fase, maar kunnen in de toekomst worden overwogen.
Door de eisen te categoriseren op basis van deze vier niveaus, helpt de MoSCoW-methode projectteams en belanghebbenden om duidelijkheid te krijgen over wat essentieel is en wat optioneel is, waardoor ze beter kunnen prioriteren en beslissingen kunnen nemen over de scope van het project. Dit draagt bij aan een effectieve resourceallocatie en helpt om te voldoen aan de belangrijkste doelstellingen van het project.
Effectief requirements vermelden
Het vermelden van requirements in een onderzoeksrapport, verslag of scriptie is zoals hierboven aangegeven van essentieel belang om duidelijkheid te bieden over de verwachtingen en criteria die moeten worden vervuld. Hieronder zijn enkele stappen iets meer gedetailleerd beschreven die je kunt nemen om requirements effectief te vermelden:
- Identificeer de vereisten: Analyseer de behoeften en verwachtingen van de opdrachtgever, belanghebbenden en eindgebruikers om de vereisten te identificeren die moeten worden opgenomen in het onderzoek.
- Wees specifiek: Formuleer de vereisten zo specifiek en meetbaar mogelijk. Gebruik indien mogelijk kwantitatieve maatstaven om de vereisten te definiëren.
- Organiseer de vereisten: Structuur de vereisten in categorieën of secties om ze gemakkelijker te begrijpen en te volgen. Dit kan bijvoorbeeld per functioneel gebied of per belanghebbendengroep zijn.
- Vermeld de vereisten in de inleiding: Neem een sectie op in de inleiding van het rapport waarin de belangrijkste vereisten worden vermeld. Dit geeft een overzicht aan de lezer van wat er van het onderzoek wordt verwacht.
- Onderbouw met literatuur: Onderbouw de vermelde vereisten met literatuur of relevante bronnen om de noodzaak en validiteit ervan te benadrukken.
- Toelichting in de methodologie: Beschrijf in de methodologie sectie hoe de vereisten zijn vastgesteld en gevalideerd, en welke methoden zijn gebruikt om ze te verzamelen en te analyseren.
- Inclusief in resultaten en discussie: Bespreek in de resultaten en discussie secties hoe de geselecteerde oplossing voldoet aan de vereisten. Geef indien mogelijk bewijsmateriaal of voorbeelden om deze evaluatie te ondersteunen.
- Reflecteer in conclusie, aanbevelingen en implementatieplan: Reflecteer in de conclusie en aanbevelingen secties op de mate waarin de vereisten zijn vervuld en doe aanbevelingen voor eventuele vervolgstappen om mogelijke tekortkomingen te adresseren. Neem daarnaast de vereisten op in een implementatieplan om een duidelijke strategie te bieden voor de praktische uitvoering van het project.
Door deze stappen te volgen, kan het vermelden van requirements in een onderzoeksrapport, verslag of scriptie helpen om de relevantie, validiteit en bruikbaarheid van het onderzoek te verbeteren.
BRONNEN
De volgende boeken hebben bijgedragen aan het schrijven van de bovengenoemde blog:
