Samenvatting BM&RE 2014
Hoorcollege 1
Requirements
Een requirement is iets wat een product moet doen, een kwaliteit die het moet hebben. Het type
product vereist bepaalde functies of kwaliteiten, terwijl de klant vaak ook wil dat het product aan
bepaalde eisen voldoet.
Er zijn 3 soorten requirements:
1. Functionele requirements: dit zijn dingen die het product moet doen. Functionele
requirements beschrijven wat het product moet doen om het werk of proces tot een goede
uitvoer te brengen, en zijn onafhankelijk van enige technologie die gebruikt worden door het
product. Denk bij functionele requirements aan het laten zien van de tijd en datum voor een
horloge.
2. Non-functionele requirements: dit zijn kwaliteiten die het product moet hebben. Non-
functionele requirements beschrijven het karakter van het product. Ze beschrijven het
uiterlijk van het product, bepalen of het gebruiksvriendelijk moet zijn, hoe
snel/veilig/nauwkeurig het moet zijn etc.
3. Constraints: constraints gelden voor het gehele product en beperken de oplossingsruimte tot
relevante dingen. Het zijn beperkingen in wat er wel of niet kan/mag. Er zijn twee soorten
constraints:
Business constraints zijn per bedrijf verschillend, en worden opgelegd door het
management van het bedrijf. Denk hierbij aan een tijdschema, budget etc.
Technical constraints zijn beperkingen die opgelegd worden door de technologie. Is
een bepaalde oplossing of product wel realistisch? Kan het wel gemaakt worden?
Ook dit is per bedrijf verschillend, aangezien technical constraints specifiek zijn voor
de huidige en gewenste ICT-situatie van een organisatie.
Fit criteria
Een “fit criterium” is een onmiskenbaar doel dat het product moet halen. Ieder requirement heeft
een maatstaf waaraan getest kan worden of het product voldoet of niet.
Denk hierbij aan uitspraken als “90 procent van alle mensen die muziek willen kopen moet ieder
muziekstuk binnen 6 seconden kunnen vinden, waarbij ze niet meer dan 3 acties uitvoeren” of
“Binnen 3 maanden na het introduceren van het product zal 60 procent van de gebruikers het
product gebruiken om het afgesproken werk uit te voeren. Van die gebruikers zal 75 procent het
product goedkeuren.” Dit zijn testen die gemakkelijk zijn na te gaan.
Hoorcollege 2
Context analyse
Een context analyse geeft je inzicht in bepaalde relaties. Zo kun je interne en externe
belanghebbenden identificeren, en zien op welke manier zij het bedrijf (en het bedrijf hun)
beïnvloeden.
De notatie is als volgt: jij of je project/afdeling is een centrale ellips. De overige betrokken partijen
zijn ellipsen daar omheen. De relaties met betrokken partijen worden aangegeven door gerichte
,pijlen tussen de middelste ellips en de betreffende partij. Dit kan beide kanten opgaan. Bij elke pijl
schrijf je wat de invloed in die richting precies inhoudt.
Cause-Effect graphs
Met een cause-effect graph kun je de echte problemen identificeren. Hierbij maak je verschil tussen
problemen en de oorzaken ervan. Dus: een bibliotheek gaat over het budget heen. Dit komt omdat
ze documenten (boeken e.d.) aan moeten schaffen. Dit komt door het feit dat er documenten kwijt
raken, zowel omdat het een open bedrijf is, alsmede door de procedure van het terugbrengen.
Je moet wel de lijst met problemen in de gaten houden. Verwijder alle ongerelateerde problemen,
alle duplicaat-problemen en alle problemen die niet op te lossen zijn.
Requirements gathering
Het verzamelen van de requirements begint bij het in kaart brengen van business events en use
cases. Het werk van de cliënt moet verbeterd worden. Een business event is een real-life gebeurtenis
die ervoor zorgt dat er iets gebeurt (een auto die langs een flitspaal rijdt, bijvoorbeeld). Een business
use case is een onafhankelijke partitie van het werk, wat zich duidelijk in een bepaald domein van het
werk bevindt en wat veroorzaakt wordt door een business event (het checken van een
kentekenplaat).
Het doel van een business use case: het verkrijgen van een high-level overzicht van hoe het systeem
functioneert of het gewenste werk uitvoert.
Een use case diagram bestaat uit de volgende onderdelen:
“Actors”, gebruikers/instanties die interactie hebben met het systeem;
“Use cases”, specifiek(e) gebruik/functie van het systeem;
“Use case relationships”: relaties tussen de use cases. Er zijn drie vormen hiervan: Include,
die herhaling van dezelfde functie voorkomt, Generalization, die variatie op normaal gedrag
van een functie biedt, en Extends, die hetzelfde doet als Generalization (maar dan wat
explicieter beschreven).
Er zijn vele manieren om requirements te verzamelen. Zo kun je ook mensen gaan interviewen. Een
interview is een één-op-één gesprek, simpel en direct. In een interview kun je doorvragen als je iets
niet snapt, je kunt kijken of je iets begrijpt door het samen te vatten in je eigen woorden.
Je kunt ook een workshop houden. Een workshop is een soort interview met meerdere mensen
tegelijk. Je brengt alle belanghebbenden bij elkaar en praat met zijn allen erover, iedereen mag zijn
of haar zegje doen. Dit zorgt voor een discussie tussen alle belanghebbenden en kan het
beslissingsproces versnellen. Er moet wel aan een aantal randvoorwaarden voldaan worden:
Begin en eindig de bijeenkomst op tijd
Stel de regels van de bijeenkomst vast en hou je er ook aan
Laat van tevoren de doelen en agenda van de bijeenkomst weten
Hou het team op de rails
Focus op het maken van beslissingen, voorkom dat je zelf in het onderwerp mee doet
Bewaak de problemen met lunch e.d., zodat de focus op de agendapunten blijft
Maak jezelf zeker van het feit dat iedereen zijn zegje kan doen en zich gehoord voelt
Voorkom onproductief gedrag
, Hoorcollege 3
Business models
Een business model is een vereenvoudigd overzicht van een bedrijf. Het bestaat uit views (een view
bevat informatie vanuit een bepaald oogpunt), en views bestaan op hun beurt weer uit diagrammen
(die een bepaald aspect visualiseren). Redenen voor een business model: je wilt een bedrijf begrijpen
om veranderingen of verbeteringen door te voeren, of om een abstract overzicht van een bedrijf te
verkrijgen.
Business Architecture
Een business architecture is (uit: Business Modeling with UML) “een georganiseerde verzameling
elementen met duidelijke onderlinge relaties, die samen een geheel vormen... de elementen
representeren de organisatorische structuur van het bedrijfssysteem.”
Een business architecture vat het echte bedrijf zo correct en waarheidsgetrouw mogelijk samen. Het
focust op de belangrijkste processen en structuren van het bedrijf.
Mintzberg’s theory of organizations
Een bedrijf bestaat uit een operational core en een strategic top. De operationele kern wordt
gevormd door de werknemers die de producten maken, of die de klanten helpen. De strategische top
bestaat uit een managementteam, de CEO, of de eigenaar; kortom, de hoogste baas. Tussen deze
twee zit vaak nog een groep managers die de strategische top en de operationele kern verbinden:
het zogenoemde middle management. Naast deze ‘ladder’ heb je nog twee groepen: de staff, die de
strategic top helpen bij het maken van beslissingen (denk hierbij aan interne adviseurs), en de
support, die het mogelijk maken dat de operationele kern hun werk gewoon kan uitvoeren.
Hieronder vallen ICT-afdelingen, accountants etc.
Organization charts
Een organization chart beschrijft de algemene structuur van een bedrijf en laat zien wie er aan wie
rapporteert.
Dit kan op verschillende manieren worden weergegeven: per productlijn (denk aan Philips, die een
lampendivisie hebben, een divisie voor medische systemen en een divisie voor Customer
Electronics), geografisch (per land/continent) of voor een klantsegment (denk aan mannen-
/vrouwen-/kinderkleding voor een H&M).
Een organisatiestructuur moet het doel van een organisatie weergeven. Wat voor product/dienst het
aanbiedt, zo duidelijk mogelijk. Ook moet het zo plat mogelijk zijn. Iedere laag maakt het geheel
gecompliceerder. Als je een organogram niet begrijpt en het niet kunt uitleggen, dan is er iets mis
mee.
Een organogram wordt bepaald door vier dingen:
1. Het portfolio bepaalt de structuur en de manier waarop het bedrijf bestuurd wordt. De
structuur laat zien in wat voor markt het bedrijf zich bevindt, de eigenschappen van die
markt en de eigenschappen van het product wat geleverd wordt. Het bestuurmodel wordt
bepaald door de diversiteit van het portfolio.
Er zijn vier verschillende structuren: functioneel (bedrijven die één product(groep)
aanspreken, één primair proces hebben, kunnen het opdelen in dingen als Verkoop,
Hoorcollege 1
Requirements
Een requirement is iets wat een product moet doen, een kwaliteit die het moet hebben. Het type
product vereist bepaalde functies of kwaliteiten, terwijl de klant vaak ook wil dat het product aan
bepaalde eisen voldoet.
Er zijn 3 soorten requirements:
1. Functionele requirements: dit zijn dingen die het product moet doen. Functionele
requirements beschrijven wat het product moet doen om het werk of proces tot een goede
uitvoer te brengen, en zijn onafhankelijk van enige technologie die gebruikt worden door het
product. Denk bij functionele requirements aan het laten zien van de tijd en datum voor een
horloge.
2. Non-functionele requirements: dit zijn kwaliteiten die het product moet hebben. Non-
functionele requirements beschrijven het karakter van het product. Ze beschrijven het
uiterlijk van het product, bepalen of het gebruiksvriendelijk moet zijn, hoe
snel/veilig/nauwkeurig het moet zijn etc.
3. Constraints: constraints gelden voor het gehele product en beperken de oplossingsruimte tot
relevante dingen. Het zijn beperkingen in wat er wel of niet kan/mag. Er zijn twee soorten
constraints:
Business constraints zijn per bedrijf verschillend, en worden opgelegd door het
management van het bedrijf. Denk hierbij aan een tijdschema, budget etc.
Technical constraints zijn beperkingen die opgelegd worden door de technologie. Is
een bepaalde oplossing of product wel realistisch? Kan het wel gemaakt worden?
Ook dit is per bedrijf verschillend, aangezien technical constraints specifiek zijn voor
de huidige en gewenste ICT-situatie van een organisatie.
Fit criteria
Een “fit criterium” is een onmiskenbaar doel dat het product moet halen. Ieder requirement heeft
een maatstaf waaraan getest kan worden of het product voldoet of niet.
Denk hierbij aan uitspraken als “90 procent van alle mensen die muziek willen kopen moet ieder
muziekstuk binnen 6 seconden kunnen vinden, waarbij ze niet meer dan 3 acties uitvoeren” of
“Binnen 3 maanden na het introduceren van het product zal 60 procent van de gebruikers het
product gebruiken om het afgesproken werk uit te voeren. Van die gebruikers zal 75 procent het
product goedkeuren.” Dit zijn testen die gemakkelijk zijn na te gaan.
Hoorcollege 2
Context analyse
Een context analyse geeft je inzicht in bepaalde relaties. Zo kun je interne en externe
belanghebbenden identificeren, en zien op welke manier zij het bedrijf (en het bedrijf hun)
beïnvloeden.
De notatie is als volgt: jij of je project/afdeling is een centrale ellips. De overige betrokken partijen
zijn ellipsen daar omheen. De relaties met betrokken partijen worden aangegeven door gerichte
,pijlen tussen de middelste ellips en de betreffende partij. Dit kan beide kanten opgaan. Bij elke pijl
schrijf je wat de invloed in die richting precies inhoudt.
Cause-Effect graphs
Met een cause-effect graph kun je de echte problemen identificeren. Hierbij maak je verschil tussen
problemen en de oorzaken ervan. Dus: een bibliotheek gaat over het budget heen. Dit komt omdat
ze documenten (boeken e.d.) aan moeten schaffen. Dit komt door het feit dat er documenten kwijt
raken, zowel omdat het een open bedrijf is, alsmede door de procedure van het terugbrengen.
Je moet wel de lijst met problemen in de gaten houden. Verwijder alle ongerelateerde problemen,
alle duplicaat-problemen en alle problemen die niet op te lossen zijn.
Requirements gathering
Het verzamelen van de requirements begint bij het in kaart brengen van business events en use
cases. Het werk van de cliënt moet verbeterd worden. Een business event is een real-life gebeurtenis
die ervoor zorgt dat er iets gebeurt (een auto die langs een flitspaal rijdt, bijvoorbeeld). Een business
use case is een onafhankelijke partitie van het werk, wat zich duidelijk in een bepaald domein van het
werk bevindt en wat veroorzaakt wordt door een business event (het checken van een
kentekenplaat).
Het doel van een business use case: het verkrijgen van een high-level overzicht van hoe het systeem
functioneert of het gewenste werk uitvoert.
Een use case diagram bestaat uit de volgende onderdelen:
“Actors”, gebruikers/instanties die interactie hebben met het systeem;
“Use cases”, specifiek(e) gebruik/functie van het systeem;
“Use case relationships”: relaties tussen de use cases. Er zijn drie vormen hiervan: Include,
die herhaling van dezelfde functie voorkomt, Generalization, die variatie op normaal gedrag
van een functie biedt, en Extends, die hetzelfde doet als Generalization (maar dan wat
explicieter beschreven).
Er zijn vele manieren om requirements te verzamelen. Zo kun je ook mensen gaan interviewen. Een
interview is een één-op-één gesprek, simpel en direct. In een interview kun je doorvragen als je iets
niet snapt, je kunt kijken of je iets begrijpt door het samen te vatten in je eigen woorden.
Je kunt ook een workshop houden. Een workshop is een soort interview met meerdere mensen
tegelijk. Je brengt alle belanghebbenden bij elkaar en praat met zijn allen erover, iedereen mag zijn
of haar zegje doen. Dit zorgt voor een discussie tussen alle belanghebbenden en kan het
beslissingsproces versnellen. Er moet wel aan een aantal randvoorwaarden voldaan worden:
Begin en eindig de bijeenkomst op tijd
Stel de regels van de bijeenkomst vast en hou je er ook aan
Laat van tevoren de doelen en agenda van de bijeenkomst weten
Hou het team op de rails
Focus op het maken van beslissingen, voorkom dat je zelf in het onderwerp mee doet
Bewaak de problemen met lunch e.d., zodat de focus op de agendapunten blijft
Maak jezelf zeker van het feit dat iedereen zijn zegje kan doen en zich gehoord voelt
Voorkom onproductief gedrag
, Hoorcollege 3
Business models
Een business model is een vereenvoudigd overzicht van een bedrijf. Het bestaat uit views (een view
bevat informatie vanuit een bepaald oogpunt), en views bestaan op hun beurt weer uit diagrammen
(die een bepaald aspect visualiseren). Redenen voor een business model: je wilt een bedrijf begrijpen
om veranderingen of verbeteringen door te voeren, of om een abstract overzicht van een bedrijf te
verkrijgen.
Business Architecture
Een business architecture is (uit: Business Modeling with UML) “een georganiseerde verzameling
elementen met duidelijke onderlinge relaties, die samen een geheel vormen... de elementen
representeren de organisatorische structuur van het bedrijfssysteem.”
Een business architecture vat het echte bedrijf zo correct en waarheidsgetrouw mogelijk samen. Het
focust op de belangrijkste processen en structuren van het bedrijf.
Mintzberg’s theory of organizations
Een bedrijf bestaat uit een operational core en een strategic top. De operationele kern wordt
gevormd door de werknemers die de producten maken, of die de klanten helpen. De strategische top
bestaat uit een managementteam, de CEO, of de eigenaar; kortom, de hoogste baas. Tussen deze
twee zit vaak nog een groep managers die de strategische top en de operationele kern verbinden:
het zogenoemde middle management. Naast deze ‘ladder’ heb je nog twee groepen: de staff, die de
strategic top helpen bij het maken van beslissingen (denk hierbij aan interne adviseurs), en de
support, die het mogelijk maken dat de operationele kern hun werk gewoon kan uitvoeren.
Hieronder vallen ICT-afdelingen, accountants etc.
Organization charts
Een organization chart beschrijft de algemene structuur van een bedrijf en laat zien wie er aan wie
rapporteert.
Dit kan op verschillende manieren worden weergegeven: per productlijn (denk aan Philips, die een
lampendivisie hebben, een divisie voor medische systemen en een divisie voor Customer
Electronics), geografisch (per land/continent) of voor een klantsegment (denk aan mannen-
/vrouwen-/kinderkleding voor een H&M).
Een organisatiestructuur moet het doel van een organisatie weergeven. Wat voor product/dienst het
aanbiedt, zo duidelijk mogelijk. Ook moet het zo plat mogelijk zijn. Iedere laag maakt het geheel
gecompliceerder. Als je een organogram niet begrijpt en het niet kunt uitleggen, dan is er iets mis
mee.
Een organogram wordt bepaald door vier dingen:
1. Het portfolio bepaalt de structuur en de manier waarop het bedrijf bestuurd wordt. De
structuur laat zien in wat voor markt het bedrijf zich bevindt, de eigenschappen van die
markt en de eigenschappen van het product wat geleverd wordt. Het bestuurmodel wordt
bepaald door de diversiteit van het portfolio.
Er zijn vier verschillende structuren: functioneel (bedrijven die één product(groep)
aanspreken, één primair proces hebben, kunnen het opdelen in dingen als Verkoop,
