Samenhang Analyse, Requirements, Ontwerp en Test

Requirements is een onderwerp wat sterk samenhangt met Business- of Informatie Analyse. En beiden vormen de noodzakelijke basis voor het ontwerp traject. Business Analyse gaat over de organisatie en business aspecten zoals bedrijfsprocessen, bedrijfsobjecten, bedrijfsregels etc. Requirements gaat over de eisen aan de oplossing.

Business Analyse

geeft de noodzakelijke context, achtergrond en begrip om de juiste requirements op te kunnen stellen en het juiste product te kunnen maken. De bedrijfsprocessen maken duidelijk welke activiteiten worden uitgevoerd waarin het systeem en de functionaliteit daarvan moet passen. De bedrijfsobjecten maken duidelijk over welke dingen, concepten de bedrijfsprocessen gaan en welke informatie daarover van belang is. Heel belangrijk: een goede definitie van begrippen en termen in een Glossary.

Requirements

gaat over de eisen aan de oplossing, bezien vanuit de business als geheel (de business requirements), de betrokken stakeholders (de stakeholder requirements) en komt samen tot een pakket eisen aan het benodigde systeem of product (system requirements).

Requirements kunnen worden beschreven op verschillende manieren. Elke requirement kan een tekstuele beschrijving hebben, bijv. zoals een methode als Volere dat laat zien. Functionele requirements kunnen worden uitgewerkt met Use Cases zoals verschillende methoden en standaarden voorschrijven. En requirements kunnen een hele globale vorm hebben met User Stories zoals gebruikelijk is in Agile methoden zoals Scrum. Wat in alle gevallen voor systeem requirements voor een software product erg prettig werkt is het gebruik van scherm beschrijvingen, schetsen of prototypes. Een ruwe schets van welke schermen er zijn, hoe ze samenhangen (storyboarding), en wat er aan onderwerpen en informatie op een scherm te zien is en wat je ermee kunt doen. Ook de relatie tussen schermen en de uiteindelijke gebruikers of de onderkende soorten gebruikersrollen is goed om te specificeren. Per rol kan worden vastgesteld of alle voor die rol en taken benodigde functionaliteit beschikbaar is.

Of er nu gebruik wordt gemaakt van tekstuele requirements, Use Cases, User Stories, Schermschetsen, belangrijk is dat deze zijn gebaseerd zijn op de business modellen en met name de bedrijfsprocessen. Een bedrijfsproces model is meestal een decompositie waarbij de hoofd activiteiten of functies van een organisatie worden uitgewerkt tot het niveau waarop deze herkenbaar zijn voor de individuele medewerkers en hun rollen en taken. Op het laagste niveau worden elementaire processen onderkend. Dat is het niveau waarop een activiteit door één persoon op één moment in de tijd wordt uitgevoerd (User Transactions). En dat is ook het niveau waarop Functionele requirements en Use Cases of User Stories worden onderkend.

Ontwerp en Test

: Business Analyse en Requirements worden in een project gebruikt om ontwerpen uit te werken en software te maken. Daarbij is belangrijk dat traceerbaar is of en hoe de requirements zijn uitgewerkt. Voor elke requirement, Use Case of User Story: waar zien we de realisatie daarvan terug in ontwerp en/of gebouwde software onderdelen zoals schermen. Dat biedt hulp voor het beoordelen, reviewen en testen van het systeem. En hoe zit het met de test gevallen, zijn voor alle requirements testgevallen voor de integratie en acceptatietesten aanwezig? Voor de business objecten: waar zien we de relatie naar software classes en/of database tabellen terug. Onderstaande figuur laat de samenhang zien met het ontwerp, realisatie en test.

This entry was posted in Requirements and tagged , , , . Bookmark the permalink.

Geef een reactie

Je e-mailadres wordt niet gepubliceerd.

De volgende HTML tags en attributen zijn toegestaan: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>