Powerpoint 1.
Uitgangspunt voor het verkrijgen van de eisen: het begrip “probleem” dat moet worden opgelost:
- Ontevredenheid over de huidige situatie.
- Nieuwe zakelijke kansen.
- Verminderen van kosten, tijd, resourcegebruik.
Taken van de requirements engineer:
- Probleemidentificatie
o Welk probleem moet worden opgelost?
o Waar is het probleem?
o Wiens probleem is het?
o Waarom moet het probleem opgelost worden?
o Hoe kan het systeem helpen?
o Wanneer moet het opgelost zijn?
o Wat zou de oplossing in de weg kunnen staan?
- Anticipeer op veranderingen
o Geef duidelijkheid over de kosten.
o Belanghebbenden denken vaak dat requirements gemakkelijk kunnen veranderen.
- Expert in het probleemdomein.
Zwakste link in het v-model.
- Verkeerde requirements zijn erg duur om te repareren als ze worden geïmplementeerd.
- Requirements onderzoek is lastig, vanwege:
o Verspreide kennis welke schaars is over vele bronnen, zelden expliciet.
- Conflicten door verschillende bronnen:
o Mensen hebben verschillende drijfveren en doelen.
o Mensen hebben verschillende opvattingen over het probleem.
- Stakeholders hebben het te druk met het huidige systeem.
- Mensen zijn niet vrij om alles te vertellen.
- Mensen zijn niet bereid je alles te vertellen.
, De drie stappen van requirementsonderzoek:
- Vereisten verzamelen (probleem begrijpen).
- Analyseren (conflictoplossing, onderhandeling).
- Documenteren (communiceren).
Hoe verzamel je requirements?
- Interviews met stakeholders.
- User stories.
- Vragenlijsten.
- Sessie voor gezamenlijke vereistenontwikkeling.
- Documentanalyse, voor IT-infrastructuur:
o Business case.
o Zakelijke requirements.
o Programma van eisen.
Problemen met het verzamelen van requirements.
Gebruikersproblemen:
- Weten niet wat ze willen.
- Doen niet mee in vergaderingen, slechte communicatie.
- Niet technisch onderlegd.
- Begrijpen niet dat ontwikkeling tijd en moeite kost.
- Geen idee van wat technisch mogelijk is.
Problemen met engineers/developers:
- Andere taal dan gebruikers.
- Proberen in het huidige systeem te realiseren.
- Voeren vaak de requirements analyse uit, terwijl een specialist dat zou moeten doen.
Checklist requirements:
Zijn de eisen:
- Ondubbelzinnig.
- Niet tegenstrijdig.
- Gepartitioneerd.
o Beschrijving van componenten / services, met functie / bediening en status.
- Geclassificeerd als gebruikers-, systeem- en softwarevereisten.
Manieren om haalbaarheid te checken:
- Prototyping (PoC).
- Use cases (UML).
- Agile methodiek.
- Simulatie.
- Functioneel modelleren.
Uitgangspunt voor het verkrijgen van de eisen: het begrip “probleem” dat moet worden opgelost:
- Ontevredenheid over de huidige situatie.
- Nieuwe zakelijke kansen.
- Verminderen van kosten, tijd, resourcegebruik.
Taken van de requirements engineer:
- Probleemidentificatie
o Welk probleem moet worden opgelost?
o Waar is het probleem?
o Wiens probleem is het?
o Waarom moet het probleem opgelost worden?
o Hoe kan het systeem helpen?
o Wanneer moet het opgelost zijn?
o Wat zou de oplossing in de weg kunnen staan?
- Anticipeer op veranderingen
o Geef duidelijkheid over de kosten.
o Belanghebbenden denken vaak dat requirements gemakkelijk kunnen veranderen.
- Expert in het probleemdomein.
Zwakste link in het v-model.
- Verkeerde requirements zijn erg duur om te repareren als ze worden geïmplementeerd.
- Requirements onderzoek is lastig, vanwege:
o Verspreide kennis welke schaars is over vele bronnen, zelden expliciet.
- Conflicten door verschillende bronnen:
o Mensen hebben verschillende drijfveren en doelen.
o Mensen hebben verschillende opvattingen over het probleem.
- Stakeholders hebben het te druk met het huidige systeem.
- Mensen zijn niet vrij om alles te vertellen.
- Mensen zijn niet bereid je alles te vertellen.
, De drie stappen van requirementsonderzoek:
- Vereisten verzamelen (probleem begrijpen).
- Analyseren (conflictoplossing, onderhandeling).
- Documenteren (communiceren).
Hoe verzamel je requirements?
- Interviews met stakeholders.
- User stories.
- Vragenlijsten.
- Sessie voor gezamenlijke vereistenontwikkeling.
- Documentanalyse, voor IT-infrastructuur:
o Business case.
o Zakelijke requirements.
o Programma van eisen.
Problemen met het verzamelen van requirements.
Gebruikersproblemen:
- Weten niet wat ze willen.
- Doen niet mee in vergaderingen, slechte communicatie.
- Niet technisch onderlegd.
- Begrijpen niet dat ontwikkeling tijd en moeite kost.
- Geen idee van wat technisch mogelijk is.
Problemen met engineers/developers:
- Andere taal dan gebruikers.
- Proberen in het huidige systeem te realiseren.
- Voeren vaak de requirements analyse uit, terwijl een specialist dat zou moeten doen.
Checklist requirements:
Zijn de eisen:
- Ondubbelzinnig.
- Niet tegenstrijdig.
- Gepartitioneerd.
o Beschrijving van componenten / services, met functie / bediening en status.
- Geclassificeerd als gebruikers-, systeem- en softwarevereisten.
Manieren om haalbaarheid te checken:
- Prototyping (PoC).
- Use cases (UML).
- Agile methodiek.
- Simulatie.
- Functioneel modelleren.
