De Kern:

Requirements zijn formuleringen van eisen en wensen voor procesverbetering zonder daarbij de mogelijke  oplossingen te benoemen. Oplossingen worden later apart bekeken. Zo kan een organisatie haar behoeften verduidelijken zonder al op voorhand in de richting van slechts één van de mogelijke oplossingsrichtingen te worden bewogen. De mogelijke oplossingsrichtingen worden vervolgens ‘gewogen’, waarbij een deel van de oplossingsrichtingen afvalt. Uiteindelijk blijft een beperkt aantal mogelijkheden over, waaruit de stuurgroep een keuze moet maken.

Dit is in vogelvlucht de weg van requirements naar alternatieven. In figuur 1  worden de requirements geformuleerd in het probleemgebied. De oplossingsrichtingen worden verzameld in het ideeëngebied. Uit de verzamelde oplossingsrichtingen worden alternatieven opgesteld en gewogen in het evaluatiegebied. Uiteindelijk wordt een keuze gemaakt voor één van de alternatieven in het selectiegebied.

Figuur 1 laat zien dat behoefteanalyse (of requirementsanalyse) en alternatievenanalyse in onderlinge samenhang worden toegepast. Het is een iteratief proces, waarbij aanvankelijk divergentie te zien is, en later weer convergentie.

Figuur 1: Behoefteanalyse en alternatievenanalyse

Figuur 1: Behoefteanalyse en alternatievenanalyse

In een project worden doorgaans beperkte selecties van nog openstaande business requirements aangepakt. De Bia (businessinformatieanalist) analyseert welke oplossingsrichtingen mogelijk zijn, en welke prioriteit erop van toepassing is. Daar worden dan weer alternatieven uit samengesteld. Een eenvoudig voorbeeld om de weg van requirements naar alternatieven te illustreren zien we in figuur 2. Er zijn twee requirements, r1 en r2, met elk twee oplossingsrichtingen: o1a en o1b voor r1, en o2a en o2b voor r2. Theoretisch kunnen daarmee al veel alternatieven worden geformeerd, bijvoorbeeld: o1a met o2a, o1a met o2b, o1b met o2a, alleen o2b enzovoort. Deze zullen niet allemaal realistisch zijn. In de praktijk blijven slechts enkele (2 of 3) alternatieven over. In figuur 2 zijn dat a1 en a2.

 Van requirements naar alterrnatieven

Figuur 2: Requirements, oplossingen, alternatieven en besluit

Beide alternatieven worden van een plan van aanpak en een business case voorzien, om ze onderling goed te kunnen vergelijken en wegen. De maatregelen die in een alternatief worden voorgesteld moeten met elkaar een consistent en haalbaar geheel vormen. De Bia draagt één alternatief (in figuur 2 is dat a1) als voorstel (proposal) aan. Het is aan de stuurgroep om dit voorstel al dan niet over te nemen. Het is mogelijk dat de stuurgroep het voorstel overneemt, maar nog wel enkele wijzigingen laat doorvoeren. Nadat deze verwerkt zijn, kan het project worden voortgezet. De stuurgroep kan het project ook beëindigen door geen van de alternatieven aan te nemen.

Samenvatting:

In dit blog wordt de weg beschreven van requirements naar alternatieven, onder verwijzing naar het boek ‘Informatieanalyse voor Requirements Engineering en Management’. Dit boek legt de weg uitvoerig uit aan de hand van een casus in een supermarkt. Daarbij worden soorten maatregelen benoemd die we in oplossingsrichtingen tegenkomen en criteria voor prioritering van deze maatregelen en weging van alternatieven.

Doelgroep:

De inhoud van dit blog is bestemd voor de business analist, de informatieanalist, de business process manager, de business consultant, de (business-) informatiemanager, de functioneel systeemontwerper, de ERP-consultant en de web-designer.

Auteur blog: Wiel Pollaert

informatieanalyse_voor_Requirements_Engineering_en_ManagementTitel: Informatieanalyse voor Engineering en Management van Requirements (dutch version)
ISBN: 978940180029711

Auteur: Wiel Pollaert
Prijs: € 25,00 (VAT

 

Please wait...

X
Added to your cart