Aanwijzingen voor het opstellen van eisen aan software Een
checklist voor gebruik bij D-opdrachten Leerstoel
Informatiesystemen, Faculteit Informatica, Universiteit Twente
Versie 1.2, 09.03.2001
InleidingBij D-opdrachten Bedrijfsinformatietechnologie komt het
vaak voor dat het opstellen van eisen aan een te ontwerpen of aan
te schaffen systeem een belangrijk deel van de opdracht vormt. Ook
als van de student gevraagd wordt een oplossing te ontwerpen is het
van wezenlijk belang om eerst zicht te krijgen op het probleem dat
moet worden opgelost. Dit document heeft tot doel studenten (en
docenten) te helpen omgaan met deze lastige materie. Voor de goede
orde: dit is niet een leidraad voor een geheel afstudeerproject,
het geeft alleen aanwijzingen voor het gedeelte dat zich bezighoudt
met het opstellen van eisen. Dit document geeft een lijst met
punten om aan te denken en tips hoe je te werk kan gaan. Er zijn
bekende valkuilen die je niet door schade en schande hoeft te
leren.
Een stappenplan als raamwerkOm een duidelijk lijn aan te houden
is de tekst gegoten in de vorm van een algemeen stappenplan, dat in
principe op ieder probleem van toepassing is. In de praktijk zijn
echter alle problemen anders; niet altijd kunnen de stappen
duidelijk gescheiden worden en niet alles wat hier staat is van
toepassing en er kunnen andere dingen van vitaal belang zijn die
hier niet genoemd zijn. Het stappenplan zal waarschijnlijk nooit
precies in deze vorm doorlopen worden, maar het geeft structuur aan
een checklist van punten om op te letten en tips om aan te denken.
In het proces van opstellen van eisen onderscheiden we vijf
stappen. Na deze inleiding volgt een overzicht met voor iedere stap
alleen de belangrijkste vragen (de denkwijze). De aanpak van deze
vragen wordt in de rest van dit document verder uitgewerkt.
Twee centrale ideen Om de eisen aan een systeem te modelleren,
moet de omgeving waarin het systeem opereert begrepen worden. Er
wordt dus in elke stap aan twee modellen gewerkt: een
omgevingsmodel en een systeemmodel. Beide modelleringsprocessen
(omgevingsmodellering en systeemmodellering) zijn iteratief.
TerminologieHet document waarin de eisen worden vastgelegd heeft
in het Nederlands definitie van eisen en in het Engels requirements
specification. Het proces van achterhalen en opschrijven van eisen
wordt in het Engels requirements analysis genoemd. Een goede
Nederlandse term is er eigenlijk niet, gemakshalve heet het vaak
requirements analyse. Wij hebben het over het opstellen van eisen.
Men dient zich echter te realiseren dat eisen niet alleen harde
eisen zijn, maar ook wensen en mogelijkheden m.b.t. een te
implementeren systeem. Alle partijen die direct of indirect belang
hebben bij de invoering van een systeem worden vaak stakeholders
genoemd. Wij hebben het over belanghebbenden.
Checklist eisen aan software
versie 1.2 09.03.2001
Vrije vakgroepsopdrachtHet is mogelijk extra studiepunten te
verdienen met een vrije vakgroepsopdracht requirements engineering.
In dat geval wordt o.a. verwacht dat je een verslag schrijft waarin
je reflecteert op het doorlopen proces van requirements analyse.
Meer informatie hierover is te verkrijgen bij Roel Wieringa of
Klaas Sikkel
Terugkoppeling op dit documentHet ligt in de bedoeling dit
document aan de hand van opgedane ervaringen bij te stellen.
Terugkoppeling is welkom. Voor vragen en opmerkingen kun je terecht
bij Klaas Sikkel, INF 3102, tel. 4003, email:
[email protected]
Inhoud Het raamwerk Fasering Stap 1: De huidige situatie Stap 2:
Het ideale doel Stap 3: Het haalbare doel Stap 4: Definitie van
eisen, eerste versie Stap 5: Definitie van eisen, iteratie
Bijlagen1. Context-free questions for assessing the current
situation 2. Techniques for finding requirements 3. Structuring
requirements 4. Techniques for writing requirements 5. Diagram
techniques
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
2
Checklist eisen aan software
versie 1.2 09.03.2001
Het Raamwerk1. De huidige situatie
q q
Wat zijn de verbeterpunten (doelen, wensen, problemen)? Wie zijn
de belanghebbenden?
Wat zijn de oorzaken van de problemen (resp. wat zal het gevolg
zijn van het voldoen aan de wensen)?
2. Het ideale doelHet is aan te raden om het in kaart brengen
van de gewenste situatie in twee stappen te doen: eerst de wensen
inventariseren en de ideale situatie bekijken, en pas daarna wensen
en mogelijkheden op elkaar afstemmen. Dit helpt om het doel voor
alle betrokkenen duidelijk te krijgen.
q q
Wat is het essentile (onderliggende) probleem? Wat is een goede
oplossing voor het essentile probleem?
Formuleer in overleg met belanghebbenden een mission statement
voor het ideale systeem
3. Het haalbare doelNadat duidelijk is geworden wat men wl wil
is het tijd om rekening te houden met wat er kan.
q q
Wat is een realistisch doel? Hoe verloopt de migratie van de
huidige naar de nieuwe situatie?
Formuleer in overleg met belanghebbenden een realistisch mission
statement voor het systeem. Eigenschappen die wel gewenst zijn,
maar niet gerealiseerd zullen worden, worden expliciet als
uitsluitingen vermeld. Geef, indien zinvol, een schets van een
migratietraject.
4. Definitie van eisen, eerste versieKies een techniek voor het
opstellen van eisen en een notatie voor een definitie van eisen die
bij het project past. Belangrijke vragen bij het formuleren en
herformuleren van eisen zijn:
q q q
Welke belangrijke eisen zou je gemist kunnen hebben? Welke eisen
zijn met elkaar in conflict? (Het is geen bezwaar dat de eisen
conflicteren, maar voor het stellen van prioriteiten dient dit wel
onderkend te worden) Zijn de eisen correct, helder en eenduidig
geformuleerd?
Als er een toonbare eerste versie is, zorg dan voor
terugkoppeling van relevante belanghebbenden
5. Definite van eisen, verfijningDe eerste versie kan in n of
meer iteraties verfijnd worden. Er zijn verschillende soorten van
verfijning mogelijk. Richtinggevende vragen zijn:
q q q
Zijn de eisen toetsbaar, resp. toetsbaar te maken? Zijn de eisen
precies genoeg om als specificatie van een systeem te kunnen
dienen? Zijn er delen van het systeem waarvoor voor nadere eisen
uitgewerkt dienen te worden? 3
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
Checklist eisen aan software
versie 1.2 09.03.2001
FaseringHoeveel tijd er in totaal aan het opstellen van eisen
besteed moet worden hangt natuurlijk af van omvang en complexiteit
van het gevraagde systeem, en zal van geval tot geval moeten worden
bekeken. De volgende tabel dient om een globale indruk te geven
hoeveel tijd er in de verschillende stappen gaat zitten. 0.
Opstarten 1. De huidige situatie 2. Het ideale doel 3. Het haalbare
doel 4. Definitie van eisen, eerste versie 5. Definitie van eisen,
iteratie 6. Afronding 7. Onverwacht 5% 20% 5% 10% 20% 20% 5% 15%
100% Opmerkingen:
Het is mogelijk om een planning te maken hoe lang je ergens mee
bezig bent, maar het is niet te voorspellen welke problemen er
optreden. Stap 7, onverwacht, dient om ruimte in het schema te
hebben om problemen op te vangen. In het uitzonderlijke geval dat
zich geen problemen voordoen kan deze tijd besteed worden aan het
beter opschrijven van de bestaande documenten. Het is vaak niet
mogelijk de stappen strikt gescheiden te houden. Bijvoorbeeld als
je een bijeenkomst belegt met verschillende belanghebbenden komen
elementen van stappen 1 t/m 4 allemaal aan de orde. Probeer wel uit
elkaar te houden wat bij welke stap hoort. Iedere stap levert een
voorlopig resultaat, dat als het nodig is vaak het geval, hangt er
ook vanaf hoe het project gemanaged wordt later weer aangepast moet
worden. Daarom is 40% van de tijd voor het opschrijven van de eisen
niet te veel; voortschrijdend inzicht kan leiden tot aanpassing van
de analyse van de huidige situatie en het doel van het systeem.
Mocht de situatie veel ingewikkelder blijken te zijn dan gedacht
(bijvoorbeeld: er is geen overeenstemming over het werkelijke doel)
dan heeft het geen zin met alle macht het tijdschema aan te houden;
het bedrijf is meer geholpen met een goed inzicht in de situatie
dan met een definitie van eisen voor een systeem dat niet het
juiste probleem oplost. In principe is de handleiding bedoeld voor
afstudeerprojecten waarbij een substantieel deel van de opdracht
(45 maanden) besteed wordt aan het achterhalen van de eisen voor
een systeem. Een stage (12 weken) is aan de krappe kant; het gehele
proces van opstellen van eisen kan alleen doorlopen worden als het
een vrij eenvoudig probleem is. Een andere mogelijkheid voor een
stage zou zijn om de stappen 03 onverkort te doorlopen, en
vervolgens alleen een schets van een oplossing aan te bieden. Ook
hier geldt: een bedrijf is meer geholpen met een goede analyse van
het probleem en enig zicht op een oplossingsrichting dan met een
nader uitgewerkte specificatie van de verkeerde oplossing.
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
4
Checklist eisen aan software
versie 1.2 09.03.2001
Stap 1: De huidige situatieDoel van deze stapIn deze stap maak
je een eerste omgevingsmodel door in kaart te brengen welke
belanghebbenden er zijn en welke verbeterpunten er volgens die
belanghebbenden bestaan. Verbeterpunten kunnen in de omgeving van
het systeem bestaan of over het systeem zelf gaan.
Wat zijn de vragen? (denkwijze)
q q q
Wat zijn de verbeterpunten (doelen, wensen, problemen)? Wie zijn
de belanghebbenden? Wat zijn de oorzaken van de problemen (resp.
wat zal het gevolg zijn van het voldoen aan de wensen)?
Hoe breng je dit in kaart? (methode)Verbeterpunten kan je in
kaart brengen door mensen te interviewen. Stel met je begeleider
binnen het bedrijf een lijst van te interviewen personen op. Het
kan nuttig zijn je eerst engiszins in het applicatiedomein te
verdiepen voordat je op pad gaat. Misschien zijn er stukken waarvan
het goed is dat je ze eerst bekijkt. Als je zelf weet waar het over
gaat, gaat het gesprek vlotter en dieper en krijg je betere
antwoorden. De lijsten met context-free questions van appendix 1
vormen een universeel startpunt voor elk requirementsproject.
Appendix 2 geeft een aantal technieken die gebruikt kunnen worden
bij het analyseren van de huidige omgeving. Op de volgende paginas
staan een aantal aandachtspunten waar je rekening mee zou kunnen
houden (echter, niet alles is altijd van toepassing). Het is nuttig
om de lijst af en toe eens door te nemen om te zien of er iets
belangrijks aan je aandacht ontsnapt is.
Wat schrijf je op? (product)Maak een schriftelijk verslag van je
probleemanalyse. Doelgroep van dit verslag zijn de belanghebbenden.
Zij moeten met weinig moeite kunnen nagaan of hun problemen en
wensen goed zijn weergegeven. Daarom is van groot belang dat het
beknopt, leesbaar en overzichtelijk is. (Merk op dat het schrijven
van een goed kort stuk meer tijd kost dan het schrijven van een
lang stuk. Maar als je terugkoppeling wilt is het een goede
investering.)
Wat gebeurt er met dit document?(1) Laten lezen door je
begeleiders (2) Voorzover nodig en mogelijk terugkoppeling vragen
van verschillende betrokkenen (3) Bijstellen (4) Opnemen als
hoofdstuk in je afstudeerverslag
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
5
Checklist eisen aan software
versie 1.2 09.03.2001
Aandachtspunten bij stap 1: de huidige situatieDe neutrale term
"verbeterpunt" kan slaan op doelen, wensen, eisen, problemen, etc.
Belanghebbenden horen niet graag dat ze een probleem hebben; wel is
het acceptabel dat er punten voor verbetering vatbaar zijn. In het
onderstaande wordt over problemen gesproken, maar let op dat je de
juiste woorden gebruikt in het contact met de belanghebbenden. 1.1.
1.1.1. Algemene probleemanalyse Probleem op welk niveau? 1.1.3.
Prioriteit van problemen Niet alle problemen zijn even belangrijk.
Een mogelijke manier om een indicatie van het belang van een
probleem te krijgen is aan de hand van de volgende vragen. Kosten
en baten hoeven niet noodzakelijk in geld uitgedrukt te worden. wat
kost het als het probleem niet wordt opgelost? wat levert het op
als het probleem wel wordt opgelost? wat kost het als het probleem
wel wordt opgelost? wat levert het op als het probleem niet wordt
opgelost? Een indruk van de urgentie van een probleem krijg je door
dezelfde vragen te stellen, maar nu met als het probleem niet nu
maar over n jaar wordt opgelost 1.2. 1.2.1. Organisatorische
context Doelen Om een duidelijk overzicht te krijgen is het handig
een tabel te maken in de volgende vorm: Belanghebbende Probleem
probleem X probleem Y ... A B ...
Als je gaat vragen krijg je vaak het antwoord dat eigenschappen
van het bestaande systeem (of het ontbreken daarvan) een probleem
zijn. Dit wordt als het directe probleem ervaren, maar het
werkelijke probleem is dat men een bepaalde taak niet goed of niet
efficint kan uitvoeren. De beste oplossing is niet noodzakelijk het
verbeteren van de systeemfunctie die nu als problematisch wordt
ervaren; misschien is er wel een hele andere oplossing denkbaar.
Daarnaast zijn er natuurlijk ook gewoon technische problemen (bijv.
storingen). Vraag niet alleen naar wat de problemen zijn maar
waarom dit als probleem wordt ervaren. Dit helpt om dichter bij de
werkelijke problemen te komen. 1.1.2. Wie heeft er een probleem?
Verschillende belanghebbenden hebben verschillende doelen en dus
ook verschillende problemen. Het is van belang deze verschillen
goed te onderkennen. In de eerste plaats moet je er achter komen
wie de verschillende belanghebbenden zijn. Houd er rekening mee dat
binnen n bedrijf verschillende personen en afdelingen tegengestelde
belangen kunnen hebben. Mogelijke belanghebbenden zijn:
Opdrachtgever (degene die het resultaat in ontvangst neemt en
goedkeurt). Namens wie zegt die op te treden; is dat ook zo?
Sponsor: degene die betaalt (bij non-profit organisaties niet
noodzakelijk dezelfde als de opdrachtgever) Eindgebruikers: degenen
die direct met het systeem interacteren met toetsenbord en
beeldscherm Indirecte gebruikers: degenen die de informatie uit het
systeem gebruiken (vaak de gebruikers genoemd) Kopers (als het
systeem voor de markt geproduceerd wordt). N.B.: Consumenten zijn
zowel kopers als gebruikers.
Een probleem is een probleem omdat het verhindert dat een
bepaald doel wordt bereikt. In een ideale wereld zou je beginnen
met eerst de doelen op te schrijven, en daarna de problemen aan
doelen te relateren. Het achterhalen van doelen is een stuk
moeilijker dan het maken van een lijstje met de problemen die
belanghebbenden noemen. Niet iedereen kan of wil precies onder
woorden brengen welke doelen hij werkelijk nastreeft. Probeer voor
jezelf inzicht te krijgen in de volgende punten welke
bedrijfsdoelen zijn gediend welke (meestal verborgen) persoonlijke
doelen spelen mee wat zijn de doelen van de afdelding sporen die
met de doelen van andere afdelingen De officile doelen van het
bedrijf (in de regel: het optimaal laten verlopen van het primaire
proces) geven een zekere houvast, en kunnen in het
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
6
Checklist eisen aan software
versie 1.2 09.03.2001
verslag gebruikt worden om te motiveren waar het probleem zit en
waarom er een oplossing nodig is. Houd echter een open oog voor wat
er verder aan de hand is. Doelen kunnen in kaart gebracht worden in
een boomstructuur, met afgeleide doelen als takken van het
hoofddoel, enz. 1.2.2. Hoe is het project gesitueerd in de
organisatie Hoe past het project in de strategie van de organisatie
Wat is de houding van het management (commitment) Wie draagt/dragen
verantwoordelijkheid voor het te ontwikkelen product en wie is
1.3.
verantwoordelijk voor het ontwikkelingsproces (organisatorische
inbedding) Het systeem
Bij vervanging van een bestaand of invoering van een nieuw
systeem zijn de volgende punten de moeite waard om aan te denken.
Afbakening: wat zijn de grenzen van het nieuwe/vernieuwde systeem
Is het een bedrijfskritisch systeem; wat kost het als het uitvalt?
Legacy: aan welke applicaties moet het systeem gekoppeld kunnen
worden?
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
7
Checklist eisen aan software
versie 1.2 09.03.2001
Stap 2: Het ideale doelDoel van deze stapNadat de problemen in
kaart gebracht zijn wordt de gewenste situatie beschreven. Het is
aan te raden dit in twee stappen te doen. Eerst de ideale situatie
bekijken en pas daarna ingaan op praktische beperkingen. We
onderscheiden doelen voor de omgeving van doelen voor het
systeem.
Het systeemdoel is een korte beschrijving van wat het systeem
moet bereiken. Een systeem dat aan dat doel voldoet, draagt bij aan
de oplossing van de geidentificeerde problemen. Het omgevingsdoel
fungeert als motivatie van het systeemdoel: om het omgevingsdoel te
bereiken, is het nodig om een systeem te hebben dat aan het
systeemdoel voldoet.
Het is makkelijk, maar niet gewenst, om je bij het stellen van
een systeemdoel te laten leiden door allerlei praktische
beperkingen. Daarom is het verstandig om (kort) in te gaan op wat
in principe de goede oplossing is. Om haalbaarheid te kunnen
garanderen zijn wellicht compromissen nodig, maar die komen
later.
Wat zijn de vragen? (denkwijze)
q q
Wat is het essentile (onderliggende) probleem? Wat is een goede
oplossing voor het essentile probleem?
Hoe breng je dit in kaart? (methode)Appendix 2 geeft een
overzicht van verschillende technieken, die gebruikt kunnen worden
om oplossingen te vinden. Om goede ideen te krijgen voor een
oplossing zou je, als het probleem en bedrijf er zich voor leent,
een brainstorm of focus-groep met verschillende betrokkenen kunnen
houden. Merk op: als mensen de moeite nemen om naar een bijeenkomst
te komen willen ze niet alleen over stap 2 praten, maar ook over
problemen (stap 1) en wat haalbaar is (stap 3). Daar is niks mis
mee, maar probeer tijdens de bijeenkomst deze stappen gescheiden te
houden. Een andere mogelijk is (zelf) een doelenanalyse (zie stap
1) te maken, maar nu voor de voorgestelde oplossing. Dat laat zien
welke problemen opgelost worden en voor wie, welke gentroduceerd
worden en voor wie, en wie er dus wel/geen belang bij die oplossing
hebben. Als er n duidelijk probleem is, is het vrij simpel aan te
geven wat de ideale oplossing voor het probleem is. Heeft de
analyse van belanghebbenden en problemen echter verschillende
problemen boven water gebracht, dan zal hier een keuze gemaakt moet
worden. Een systeem dat verschillende problemen tegelijk moet
oplossen wordt zelden een goed systeem!
Wat schrijf je op? (product)Een korte tekst (maximaal n a4tje,
een half kantje is beter) met
q q
Een mission statement (zie hieronder) Een toelichting waarom
bepaalde dingen er wel/niet in staan en welke keuzes er zijn
gemaakt.
Als er een groepsbijeenkomst is geweest heb je natuurlijk ook
een lijst met genventariseerde problemen en oplossingen. De
toelichting moet dan duidelijk maken waarom dt het essentile
probleem is dat aangepakt moet worden.
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
8
Checklist eisen aan software
versie 1.2 09.03.2001
Wat gebeurt er met dit document?Dit is geen officieel document
(het ideale doel wordt niet nagestreefd), maar wel het
belangrijkste a4tje in het hele proces van het opstellen van eisen.
Ga informeel na of de verschillende belanghebbenden zich erin
kunnen vinden. Zo ja, dan is men het erover eens wat het probleem
is en in welke richting een oplossing gezocht moet worden. Maar het
komt ook voor dat nu pas blijkt dat men het er niet over eens was
wat nu eigenlijk het essentile probleem is. Is dat het geval, dan
heb je het eerste succes al binnen; je hebt aangetoond dat de zaak
ingewikkelder ligt dan de opdrachtgever dacht en daarmee een
mislukking voorkomen!
Aandachtspunten bij stap 2: het ideale doel2.1. Mission
statement beyond doubt if necessary, in court what these terms were
at the time the contract was made. The E-Terms consortium wishes to
address this problem by establishing an E-Terms repository. When a
business party submits terms to the repository, the consortium
guarantees that the applicable terms can be retrieved unaltered by
any interested party at any future moment. In this project [naam]
will develop a prototype of an E-Terms repository. The purpose of
the prototype is to serve as a proof of concept, aimed at showing
the possibility of creating a repository and functioning as a guide
for the development towards a final version. Furthermore, the
prototype will be used in the external promotion of the concept to
potential users, submitters and developers. It should serve both to
increase the interest in the E-Terms service and to gather relevant
feedback from interested parties. Efficiency and reliability
requirements envisaged for the final product need not be met by the
prototype repository. [iets over verschillende verschillende
soorten van gebruik van E-terms die door de repository ondersteund
worden.] Opmerkingen: De inleiding stond er in het originele
mission statement niet bij omdat het mission statement alleen
circuleerde binnen het genoemde consortium. Het kan echter geen
kwaad het er als context bij te zetten. Het genoemde doel is niet
het bedrijfsdoel van de opdrachtgever (hier in de inleiding) maar
het doel van dt project. Dat erbij staat welk gebruik men voor ogen
heeft is ontzettend belangrijk om in het vervolgtraject de juiste
ontwerpbeslissingen te kunnen nemen. Dit maakt ook duidelijk waarom
bepaalde uitsluitingen op voorhand logisch zijn (in stap 3 komen
evt. andere uitsluitingen aan de orde).
Er zijn verschillende definities van hoe een mission statement
eruit moet zien. [Wie99, 5.2] geeft het mission statement volgens
Yourdon. Wij hanteren hier een iets ander formaat; de voorgestelde
oplossing hoeft hier niet beperkt te zijn tot een computersysteem.
Het beschreven systeem kan ook mensen en werkprocedures bevatten,
en misschien wel helemaal geen computersysteem. Een mission
statement bevat de volgende punten Wat voor soort systeem is het
(alleen computersysteem, of maken de mensen rond de hard/software
ook deel uit van het systeem) Wat is het doel van het systeem (welk
probleem wordt er opgelost) en wat zijn de uitsluitingen (welke
problemen worden niet opgelost) hoe wordt het probleem opgelost Er
kan een toelichting bij geschreven worden waarin uitgelegd wordt
waarom bepaalde dingen er wel/niet in staan. De toelichting is geen
deel van het mission statement. Hebben verschillende
belanghebbenden verschillende interesses, en zie je de bui al
hangen, dan kan je evt. verschillende misson statements ter keuze
voorleggen. Als in het mission statement het compromis al
ingebakken zit heb je een halfslachtig doel, en dat leidt nooit tot
een goede oplossing. Het uiteindelijke mission statement moet
bekend, begrepen en geaccepteerd zijn bij alle stakeholders. Dat
betekent niet dat iedereen hetzelfde wil of het met elkaar eens is,
dat betekent wel dat iedereen het erover eens is dat dit het
mission statement voor dit project is. voorbeeld van een mission
statement A problem to be solved in electronic commerce is the
specification of terms of delivery in such a way that can it can be
established
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
9
Checklist eisen aan software
versie 1.2 09.03.2001
Stap 3: Het haalbare doelDoel van deze stapHet ideale
systeemdoel wordt nu omgezet in haalbaar systeemdoel.
Wat zijn de vragen? (denkwijze)
q q
Wat is een realistisch doel? Hoe verloopt de migratie van de de
huidige naar de nieuwe situatie?
Hoe breng je dit in kaart? (methode)Er kunnen allerlei redenen
zijn waarom een goede oplossing toch niet haalbaar is. Een beperkt
budget is meestal een hard gegeven. Moeilijker ligt dat bij het
draagvlak voor een oplossing. Als verschillende belanghebbenden om
wat voor reden dan ook tegen een mogelijke oplossing zijn, dan is
het geen goede oplossing. Het draagvlak voor een verandering kan
soms echter aanmerkelijk vergroot worden door de juiste personen op
de juiste manier bij het project te betrekken. Moeten er
ingrijpende keuzes gemaakt worden, dan is het aan de opdrachtgever
en niet aan jou om die keuzes te maken. Je kan hierbij wel helpen
door duidelijk de alternatieven (met de daarbij behorende
consequenties) aan te geven. Aandachtspunten om rekening mee te
houden:
q q q q q q
Welke factoren zijn van belang voor het welslagen van het
project; Welke middelen (resources) zijn beschikbaar voor het
project; Hoe is de houding van de gebruikers voor wie het product
is bedoeld (acceptatie, motivatie); Welke middelen zijn beschikbaar
voor de migratie (resources, cursussen, e.d.);
Wat schrijf je op? (product)Formuleer een realistisch mission
statement voor het systeem. Eigenschappen die wel gewenst zijn,
maar niet gerealiseerd zullen worden, worden als uitsluitingen
opgenomen. Geef, indien zinvol, een mogelijke schets van een
migratietraject van de huidige naar de nieuwe situatie.
Het migratietraject hoeft in dit stadium niet uitgewerkt te
zijn, en hoeft alleen te worden opgenomen als dit mogelijk tot
problemen zou kunnen leiden. In dat geval is het nuttig om
eventuele problemen vroegtijdig te onderkennen.
Wat gebeurt er met dit document?Het mission statement is een
formeel document en wordt opgenomen in de uiteindelijke definitie
van eisen. Laat het zien aan alle belanghebbenden (wat tot het
nodige bijschaven aanleiding kan geven) en laat het goedkeuren door
de opdrachtgever.
Verdere aandachtspunten:De aandachtspunten van stap 2 zijn ook
hier van toepassing.
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
10
Checklist eisen aan software
versie 1.2 09.03.2001
Stap 4: Definitie van eisen, eerste versieDoel van deze
stapTussen doel en realisatie staan nog een aantal stappen. Wat
moet er gebeuren om het doel te halen? Dit valt uiteen in (1) De
definitie van eisen voor het nieuwe systeem (2) Een plan voor een
overgang van de oude naar de nieuwe situatie (migratie) (3) Het
creren of vergroten van draagvlak voor het plan (4) De uitvoering
van het plan Wij houden ons vooral bezig met (1), het opschrijven
van de definitie van eisen, maar het is goed om bij het opstellen
van eisen zicht te houden op de andere genoemde punten, die mede
bepalend zijn voor het succes van het systeem. Als bijproduct van
het opschrijven van de systeemeisen ontstaat een verfijning van het
omgevingsmodel.
Wat zijn de vragen? (denkwijze)Twee belangrijke vragen om
voortdurend in het achterhoofd te houden zijn
q q
Welke belangrijke eisen zou ik gemist kunnen hebben? Welke eisen
zijn met elkaar in conflict?
Het is geen bezwaar dat eisen met elkaar in conflict zijn bij
niet-functionele eisen zou het raar zijn als er geen conflict is
maar het gaat er om deze te onderkennen, zodat in een later stadium
verantwoorde keuzes gemaakt kunnen worden. Zijn de eisen correct,
helder en eenduidig geformuleerd?
Hoe breng je dit in kaart? (methode)De eerste versie van de
eisen wordt altijd in natuurlijke taal opgeschreven. Systeemeisen
zijn altijd onder te verdelen in kwaliteitseisen en functionele
eisen. Maak steeds onderscheid tussen systeemeisen en aannames over
de omgeving die daarbij gemaakt worden. Appendix 3 licht dit
onderscheid verder toe en geeft een nadere classificatie van
soorten eisen.. Voor aanwijzingen voor het schrijven van een goed
leesbare definitie van eisen zie [MSW01]. Reken er op dat aan de
eerste versie van de definitie van eisen een paar nul-versies
voorafgaan; het lukt nooit om ze in n keer goed op papier te
krijgen. Het is daarom belangrijk ze zo duidelijk en ondubbelzinnig
mogelijk op te schrijven, zodat ze gemakkelijk door de
verschillende belanghebbenden geverifieerd kunnen worden.
Wat schrijf je op? (product)Over de vorm die een definitie van
eisen moet hebben wordt verschillend gedacht. Verschillende auteurs
raden een standaardformaat aan (bijv. ANSI/IEEE 830, zie [vdB99]);
Kovitz [Kov99] stelt dat je je eerst om de inhoud moet bekommeren
en de vorm moet laten sturen door de inhoud. Beide mag, maar wij
voelen meer voor het laatste.
q q
Schrijf niet alleen de eisen op, maar ook de redenen ervoor (en
op gezag van wie ze zijn opgenomen)
Wat gebeurt er met dit document?Zorg voor terugkoppeling van
relevante belanghebbenden. Je kan vragen naar commentaar
(makkelijk) of met betrokkenen bespreken (levert meer op)
afhankelijk van de situatie.
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
11
Checklist eisen aan software
versie 1.2 09.03.2001
Aandachtspunten bij stap 4: definitie van eisen4.1. Technieken
voor het opschrijven van eisen omgevingsgrenzen: waar moet het
systeem zijn gewenste effecten hebben. Deel van de wereld waar de
effecten van het systeem niet bestaan/ niet relevant zijn, is het
deel van de wereld dat niet meer beschouwd hoeft te worden. Dat
ligt buiten de omgeving. Er moet een soort contextdiagram van de
omgeving gemnaakt worden. Wat zijn de gewenste effecten van het
systeem. Wat voor soort systeem wordt gevraagd/verwacht:
informatievoorziening sturend monitoring communicatie-intensief
representerend (entiteiten bestaan ook zonder dat systeem bestaat)
of virtueel (entiteiten bestaan alleen dankzij systeem)
Als de definitie van eisen nog onvoldoende gestabiliseerd is, in
de eerste versie(s), is natuurlijke taal het meest flexibel en het
makkelijkst te begrijpen. Het gebruik van natuurlijke taal maakt
het schrijven van eisen niet gemakkelijker maar moeilijker. Het is
niet gemakkelijk om eisen helder en eenduidig op te schrijven
zodaning dat alle belanghebbenden goed begrijpen wat de sie is. Zie
[MSW01] voor technieken om eisen op te schrijven. Een diagram
(contextdiagram, eintiteitenmodel) kan de zaak verhelderen, maar
zorg ervoor dat het lezerspubliek (de belanghebbenden) begrijpt wat
het diagraam voorstelt. Voeg aan elk diagram een leganda toe, die
de gebruikte symbolen uitlegt. 4.2. Gebruik vs. gedrag 4.3. Eisen
kunnen op verschillende niveaus van abstractie beschreven worden.
Er is een onderscheid te maken tussen Het gebruik van het systeem:
wat wil men er mee doen. Dit levert eisen van de vorm het systeem
stelt de account manager in staat om .... Het gedrag van het
systeem: wat gaat erin en komt eruit. Dit levert eisen van de vorm
als ... laat het systeem de volgende klantgegevens zien: .... In
het Engels wordt het verschil aangegeven door te praten over user
requirements (gebruik) en system requirements (gedrag). Bij een
volledige definitie van eisen denkt men aan het tweede. Voor een
eerste versie is het verstandiger om je vooral te bewegen op het
eerste niveau. Het feitelijke gedrag is dan nog niet gespecifieerd,
maar het levert wel een document waar de belanghebbenden meer mee
kunnen. Een vollediger specificatie van systeemgedrag kan later
toegevoegd worden; de beschrijving van het gebruik kan er bij
blijven staan om later te kunnen nagaan waarom en hoe dit gedrag in
de definitie van eisen terecht is gekomen. 4.3. Het systeem in
context
Interoperabiliteit: met welke andere systemen moet samengewerkt
kunnen worden? Nadere analyse van de eisen
4.3.1. Functionele eisen Een functionele eis beschrijft een
gewenste functie van het systeem. Een systeemfunctie is een in het
systeem te implementeren interactie tussen het systeem en zijn
omgeving die nuttig is voor die omgeving. Breakdowns zijn ook
interacties tussen het systeem en zijn omgeving, maar dat zijn geen
systeemfuncties. En onverwacht en onbedoeld gebruik van een systeem
door zijn omgeving (bijvoorbeeld een nijptang als hamer gebruiken)
noemen we een ``affordance'', iets nuttigs dat het de omgeving met
het systeem kan doen, maar niet een functie. Kenmerk van een
systeemfunctie is dat hij bij het systeemontwerp gespecificeerd is.
Alle functies samen worden gemotiveerd door het systeemdoel. De
lijst met systeemfuncties kan gezien worden als een verfijning van
de systeemmissie. 4.3.2. Kwaliteitseisen Kwaliteitseisen, ook wel
niet-functionele eisen genoemd, beschrijven algemene eigenschappen
van het systeem. Kwaliteitseisen zeggen iets over hoe goed een
systeem zijn functies moet vervullen. Het is vaak erg lastig deze
eisen scherp op papier te krijgen. Wanneer is een systeem
bruikbaar, en wanneer niet? Bij de eerste versie van de definitie
van eisen is het goed om op te schrijven welke kwaliteitseisen van
belang zijn, en welke minder, zonder dit precies te willen
kwantificeren. Verschillende kwaliteitseisen zijn vaak met elkaar
in conflict; meer veiligheid betekent vaak minder
Let of de volgende begrippen (vgl [Wie99]) systeemgrenzen: deel
van de wereld dat gegeven is ligt buiten het systeem; deel dat mag
veranderen door jouw acties, ligt binnen het systeem.
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
12
Checklist eisen aan software
versie 1.2 09.03.2001
gebruikersvriendelijkheid; hogere betrouwbaarheid kan ten koste
gaan van de efficintie. De belangrijkste algemene
kwaliteitscriteria zijn: betrouwbaarheid (reliability) prestatie
(performance) veiligheid (security) bruikbaarheid (usability)
onderhoudbaarheid (maintainability) Zie ook [Win99]. 4.3.3. Zijn
het de juiste eisen? Ga na of de eisen in overeenstemming met de
missie van het systeem Ga na of er eisen tussen zitten die alleen
cosmetische toevoegingen beschrijven ('gold plating') en niet
essentieel zijn voor de kern van het systeem. Verdeel de eisen in
strikt noodzakelijk, gewenst, handig of ongewenst ("must",
"should", "could", "won't"). Ongewenste eisen ook expliciet
documenteren. Ga na of de eisen realistisch zijn. 4.3.4. Zijn er
conflicten en afhankelijkheden? Ga na welke eisen met elkaar in
conflict zijn. Voeg een lijst van conflicten toe aan de voorlopige
definitie van eisen. Dit zijn punten van discussie/onderhandeling
voor het vaststellen van een definitieve specificatie van eisen.
Eisen hangen soms met elkaar samen. Als de eisen veranderen moeten
daarvan afhankelijke eisen meeveranderen. Documenteer de onderlinge
afhankelijkheden tussen verschillende eisen. 4.3.5. Zijn de eisen
correct geformuleerd? Ga na welke eisen niet zozeer een
specificatie van eisen zijn, maar een indicatie
van oplossing of technologie. Herformuleer of verwijder deze
eisen. Ga na welke eisen zuivere gemeenplaatsen zijn (bijv. "het
systeem gedraagt zich correct"). Maak deze eisen concreet of
verwijder ze. Ga na of bij kwantificeerbare eisen een omvang en een
eenheid gespecificeerd zijn die overeenkomen met de aangegeven
grootheid (bijv. eisen m.b.t. performance). Controleer de
inhoudelijke consistentie van verschillende lijsten eisen (bijv.
t.a.v. processen en gegevens). Zijn de eisen begrijpelijk en
eenduidig?
4.3.6.
De leesbaarheid van een definitie van eisen voor de
belanghebbenden is van niet te onderschatten belang! Als men het
document niet begrijpt omdat het te technisch, te ingewikkeld of te
langdradig is heb je misschien formeel gelijk als er later
conflicten onstaan, maar is de kans dat de klant tevreden zal zijn
vrij laag. De eisen moeten eenduidig geformuleerd zijn en niet voor
meerderlei uitleg vatbaar. Degene die dat het slechtst kan
beoordelen ben je zelf, omdat je er al te diep in zit. Het helpt
altijd om de definitie van eisen een keer te laten lezen door
iemand die niet bij het project betrokken is, om te kijken of hij
of zij begrijpt wat er bedoeld wordt. Als het van belang is dat de
eisen precies en eenduidig op papier staan, raden Gause en Weinberg
[GW89] het volgende experiment aan: Breng een groepje mensen die
bij het opstellen van de eisen betrokken zijn bij elkaar, neem de
papieren weg, en laat ze uit hun hoofd opschrijven wat ze zich
herinneren dat in de definitie van eisen staat. Wijken de
formuleringen sterk af van wat er werkelijk stond, dan is waren de
eisen niet duidelijk genoeg.
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
13
Checklist eisen aan software
versie 1.2 09.03.2001
Stap 5: Definite van eisen, verfijningDoel van deze stapIn stap
4 is een definitie van eisen opgesteld die waarschijnlijk nog niet
volledig is, maar die wel communiceerbaar is. Er is veel aandacht
besteed aan of het de juiste eisen zijn, en of ze z geformuleerd
zijn dat belanghebbenden er mee uit de voeten kunnen. Is voor deze
eerste versie voldoende draagvlak verkregen. De eerste versie kan
vervolgens in n of meer iteraties verfijnd worden, zodanig dat de
eisen precies genoeg zijn om op zoek te gaan naar een systeem dat
aan de eisen voldoet of zelfs om het systeem zelf te bouwen. Om de
eisen precieser op te schrijven kan gebruik gemaakt worden van
diagramtechnieken. Er zijn drie verschillende soorten van
verfijning mogelijk, zoals aangegeven in onderstaande vragen.
Wat zijn de vragen? (denkwijze)
q q q
Zijn de eisen geoperationaliseerd, d.w.z, kan later worden
bepaald of het systeem aan de eisen voldoet? Zijn de eisen
specifiek, d.w.z., zijn de eisen precies genoeg om als specificatie
van een systeem te kunnen dienen? Zijn de eisen gedecomponeerd,
d.w.z. zijn er delen van het systeem waarvoor voor nadere eisen
uitgewerkt dienen te worden?
Hoe breng je dit in kaart? (methode)Hoe kan later worden bepaald
of het systeem aan de eisen voldoet? Ga na welke eisen toetsbaar
zijn en welke niet. Probeer, als het kan, de niet-toetsbare eisen
zodanig aan te scherpen dat ze wel toetsbaar worden. Het welslagen
van een project kan alleen aan de hand van toetsbare eisen bepaald
worden. Geven de eisen een specificatie van het systeem? Het is
verstandig om in de eerste versie meer aandacht te besteden aan de
gebruikseisen (wat moet men er mee kunnen) dan aan de systeemeisen
(wat is het precieze input/output-gedrag); zo nodig worden de
systeemeisen in een tweede versie aangevuld. Gedetailleerdere
invulling van het gewenste systeem. Naarmate de eisen duidelijker
worden neemt het inzicht in het op te leveren systeem toe. Het
opstellen van eisen en het maken van een systeemontwerp zijn in
principe verschillende activiteiten, die in de praktijk echter vaak
niet voor 100 % te scheiden zijn. Het is denkbaar dat in de tweede
versie de eisen aan het systeem gedetailleerder worden.
Wat schrijf je op? (product)
q q q
Een, twee, of meer verfijningen van de eerste versie van de
definitie van eisen.
Wat gebeurt er met dit document?De uiteindelijke versie wordt
goedgekeurd door de opdrachtgever Het wordt als bijlage opgenomen
in je afstudeerverslag
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
14
Checklist eisen aan software
versie 1.2 09.03.2001
Verdere aandachtspuntenAlle aandachtspunten van stap 4 zijn ook
hier van toepassing. In het bijzonder is de structuur van het
omgevingsmodel en van de definitie van eisen zoals aangegeven in
appendix 3 belangrijk. In appendix 4 staat een opsomming van
diagramtechnieken die gebruikt kunnen worden. Vraag je bij elk
diagramtype af wat het lezerspubliek is en of dat publiek dit
diagram goed begrijpt. Tenslotte is het belangrijk om de eisen op
te schrijven in een helder en goed gestructureerd document.
Hiervoor is een aparte notitie met richtlijnen [MSW01]
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
15
Checklist eisen aan software
versie 1.2 09.03.2001
Literatuur[BCN92] C. Batini. S. Ceri and S.B. Navathe. Database
Design: An Entity-Relationship Approach. Benjamin/Cummings, 1992.
[BH98] [Ckl81] H. Beyer and K. Holtzblatt. Contextual design:
Defining Customer-Centered Systems. Morgan Kaufmann, 1998. P.B.
Checkland. Systems Thinking, Systems Practice. Wiley, 1981.
[MSW01] E. de Maat, K. Sikkel, R. Wieringa. Richtlijnen voor het
schrijven van een definitie van eisen. Leerstoel
Informatiesystemen, Universiteit Twente, maart 2001 [GW89] D.C.
Gause, G.M. Weinberg. Exploring Requirements: Quality Before
Design. Dorset House, New York, NY, 1989 [HC88] [KK92] J.R. Hause,
D. Clausing. The house of quality. Harvard Business Review, 66(3),
MayJune 1988. Pages 63-73. K.E. Kendall and J.E. Kendall. Systems
Analysis and Design. Second edition.PrenticeHall, 1992.
[Kov99] B.L. Kovitz. Practical Software Requirements: A Manual
of Content and Style. Manning Publications, Greenwich, CT, 1999
[Inc92] D. Ince. Prototyping in J.A. McDermid, Software Engineers
Reference Book, pp. 40/140/12.Butterworth/Heinemann, 1992.
[Lau98] S. Lauesen: Software Requirements Styles and Techniques.
Samfundslitteratur, Frederiksberg, Denemarken, 1998. [Lun81] M.
Lundeberg, G. Goldkuhl and A. Nilsson. Information Systems
Development -A Systematic Approach. Prentice-Hall, 1981. [Mcl96]
[Pre97] [Ret94] [RE95] L. Macaulay. Requirements Engineering.
Springer, 1996. R.S. Pressman: Software Engineering, A
Practitioners Approach. Fourth Edition, European Adaptation,
McGraw-Hill, New York, 1997 M. Rettig, Prototyping for tiny
fingers. Communications of the ACM, 37(4), April 1994. Pages 21-27.
N.F.M. Roozenburg and J. Eekels. Product design: Fundamentals and
Methods. Wiley, 1995.
[vdB99] K. van den Berg. Software Engineering course notes.
Universiteit Twente, 1999 [Wie99] R.J. Wieringa. Design Methods for
Reactive Systems. Course notes. Universiteit Twente, 1999 [Win99]
J.J. Wintraecken. Kwaliteit van de Informatievoorziening. Course
notes. Universiteit Twente, 1999
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
16
Checklist eisen aan software
versie 1.2 09.03.2001
Appendix 1 Context-free questions for assessing the current
situationWhen you first enter an organization for which you are to
do requirements work you may be overwhelmed by the number of
potentially relevant people, departments, systems, goals and
problems. This appendix lists some simple questions that you can
always start with. They are called context-free because they apply
to all kinds of problems, independent of the particular problem
context.
The business
q q q q q q q
What kind of business is this? What is the structure of the
business? Which departments of the business are involved in the
system? What are the mission and goals of the business and its
relevant departments? Related projects
ProblemsWat are the problems? For each problem: What is the real
reason for wanting to solve this problem? Can a solution to this
problem be obtained elsewhere? Which organizational goal is served
by solving this problem? How bad is the problem? (Quantify if
possible) How urgent is it?
Stakeholders
q q
Who are the stakeholders? For each stakeholder: What is his/her
relation to the system? What are the responsibility relations
between the stakeholders? Who is responsible for improving the
system? Is management committed to improving the system?
Problem analysis
q q
Which stakeholders have which problems? For each
stakeholder/problem combination: How much is it worth to this
stakeholder to solve the problem? How bad is it for the stakeholder
if the problem is not solved? How urgently should this problem be
solved? How bad is it if this problem is solved one year later?
What is the trade-off between time and value?
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
17
Checklist eisen aan software
versie 1.2 09.03.2001
The current system
q q q q q
What problems are solved by the current system? For whom? What
problems are introduced by the current system? For whom? Does the
system fit into the business strategy? Is the system
mission-critical? How bad is it if the system breaks down? Does the
system interface with legacy systems?
SourcesUseful context-free starting questions are given by Gause
and Weinberg [GW89]. The problem identification and analysis
questions have also been borrowed from ISAC [Lun81].
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
18
Checklist eisen aan software
versie 1.2 09.03.2001
Appendix 2 Techniques for finding requirementsDuring
requirements work, you must find the goals, desires and wishes of
the stakeholders. This appendix lists some techniques that you can
use for this. It is important to distinguish requirements
elicitation from requirements creation. In requirements
elicitation, you are like a scientist studying the behavior of the
planets: You observe what happens but you do not participate in it.
Requirements elicitation is simply writing down the requirements as
they are told to you by stakeholders. In requirements creation, on
the other hand, you work with the customer to identify the
requirements. You join the customer in the search for goals to
achieve and problems to solve. In the first case, the customer
knows what the requirements are and you help him or her to write
these down. In the second case, the customer does not know what the
requirements are and you work with him or her to determine what
they are. Requirements elicitation in its pure form does not exist.
All techniques listed below are requirements creation technques. A
second important distinction is that between the environment and
the system: Are the requirements that you find desired properties
of the environment or of the system? The requirement that a daily
backup be made of a database is a desired property of the system.
But this property is motivated by the requirement that the customer
does not want to lose more than one days work, and that is a
propery of the environment, not of the system.
System requirements tell us what system is needed,
environment requirements tell us why the system is needed. In
any requirements process, you must make a model of the environment,
that tells us, among others, what requirements exist in the
environment, as well as a model of the system, that tells us what
the desired system properties are. Finding out about current
environment and its goals, and about current system.The following
techniques are useful for fact-finding. They are closer to
elicitation than to creation.
q q q q q q
Interviews. Asking stakeholders what they currently do and how
they would like to change this. Kendall and Kendall [KK92] give a
useful introduction to interview techniques for information
analysis. Observation of current work. Observing what stakeholders
actually do, as opposed to what they say they do. Beyer and
Holtzblatt [BH98] give an excellent survey of models to make when
observing stakeholders at work (models of flow, sequence,
artifacts, culture and the physical situation), how to make them
and how to create requirements from them. Participation in current
work to actually experience what the current envirlnment does.
There is no literature on this: Just join the stakeholders in doing
their work. Take your time doing this. Questionnaires. Sending out
forms with questions to stakeholders about the current environment.
Kendall and Kendall [KK92] give a useful introduction to the
construction of questionnaires for information analysis. Study
current system documentation. There is no literature on this. Brace
yourself to digest a mountain of information. Study current forms
(paper forms, screen forms). Analyzing forms in use by the current
system to discover data structures and work procedures hidden in
them. Batini, Ceri and Navathe [BCN91] give a useful introduction
to uncovering data structures from forms.
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
19
Checklist eisen aan software
versie 1.2 09.03.2001
Problem AnalysisThe following techniques help you to analyze
problems identified during fact-finding.
q q
Soft Systems Methodology (SSM). A method defined by Checkland
[Ckl81] to analyze exceptionally vague problems (problems where the
problem is that the problem is not known). Macaulay [Mcl96] gives a
handy introduction. Stakeholder analysis. Set off stakeholders
against problems and analyze each problem on severity (quantify!)
and urgency. Gause and Weinberg [GW89] give useful hints.
Creating requirements for new systemThe following techniques can
be used to create new ideas about possible solutions to
problems.
q q q q q
Brainstorm. Generating wild ideas in a group without criticizing
any idea, followed by a rationalization of the ideas. Roozenburg
and J. Eekels [RE95] give a very useful introduction to
brainstorming for product design, including its variations, such as
brainwriting (in which participants anonymously submit their ideas
in writing). Focus groups. Let a group of users discuss
requirements with each other. Macaulay [Mcl96] gives a short
introduction to the use of focus groups for requirements
engineering. JAD workshops. Bring stakeholders from the customer
and developer sides together and let them jointly do the design.
Macaulay [Mcl96] gives a short introduction to the use of JAD
workshops for requirements engineering. Visiting similar companies.
Visit companies with similar problems to get an idea about the
desirable properties of solutions to these problems. Quality
Function Deployment (QFD). Maintain traceability tables that match
user requirements with system requirements. Attach weights to
indicate priorities, and indicate conflicts between requirements
that. Discuss with all stakeholders and agree on choices based on
this traceability information. Hausaer and Clausing [HC88] give a
good introduction and Macaulay [Mcl96] provides a very short
summary. Goal-means analysis. Make a goal tree. Indicate for each
requirement the goals that it serves, and indicate for each goal
the desired system properties that would help reaching that goal.
Lauesen [Lau98] gives an example.
q
Techniques for refining system requirements and corresponding
environment modelsThe following techniques all assume that you
alrerady have some idea about system requirements and allow you to
improve them.
q q
Collecting supplier information. Collect documentation from
suppliers, let them give demos in order to get an idea of which
system requirements can actually be realized with current
commercially available technology. Throw-away protototypes.
Constructing a software system that implements a few of the system
requirements, and letting users experiment with it to give them the
occasion to form more concrete ideas about what they really want.
After experimenting, the improved requirements are written down and
the prototype is thrown away. Any software engineering book
contains a section about throw-away prototyping. Ince [Inc92] is
one of the many overviews. Less well-known is a description of
low-tech prototyping, involving pencil, paper, glue, and role
playing, described by Rettig [Ret94], that in many cases is more
efficient and at least as effective as high-tech prototyping. Pilot
project. Implementi the system in a part of the organization where
it is not critical, in order to get experience with real use of the
system. This should lead to improved requirements.
q
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
20
Checklist eisen aan software
versie 1.2 09.03.2001
Appendix 3 Structuring RequirementsThis appendix describes a
number of structures that can be found in most requirements. For
example, requirements can always be partitioned into environment
requirements and system requirements. It is possible to structure
the requirements specification (the text that describes the
requirements) to reflect the structure of the requirements.
However, often it is necessary to conform to company standards,
that prescribe a particular structure for the requirements
specification (e.g. IEEE 830). It is also usually necessary to
present the requirements in a particular order for didactic
reasons. For example, it is not useful to first present the entire
environment model before presenting any system requirement. Rather,
these two kinds of requirements will be presented in an interleaved
way in order to improve understandability of the document, and in
many cases the environment model need not be presented completely.
This appendix does not present a preferred structure of a
requirements specification, but it does present a structure of the
requirements itself that we claim is always present.
q
q
Environment model Business as it is now: mission, goals,
structure, stakeholders, problems. Business requirements: desired
way of working in the business. Also called user requirements.
Business process model (e.g. workflow, task models) Relevant
business communications Embedding in organizational structure
System context Subject domain entities Subject domain behavior
Communication context of the system (observers, actors, feedback
loops etc.) System requirements Functional model System mission
System functions Stimulus-response behavior Architectural model
High-level parts of the system (subsystems, databases, etc.) and
their communication Contribution of the system parts to the system
requirements (functional and quality) Quality attributes
Reliability Performance Security Usability Maintainability
Remarks:1. Business modeling is only necessary in as far as it
is needed to understand the reason for the system requirements.
Business requirements should have been determined before system
requirements are determined; although here too there may be a
feedback from system requirements to improve or operationalize
business requirements. 2. Business process modeling may become part
of system requirements modeling when parts of this business process
must be automated, as in workflow automation.
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
21
Checklist eisen aan software
versie 1.2 09.03.2001
3. The communication model of the context represents the
environment as well as part of the functional system requirements
4. We consider high-level system architecture to be part of system
requirements. All business have a network of software and hardware
that is impossible to regard as a black box. 5. The first version
of the system requirements usually contains mostly quality
attributes. Detailed functional requirements become only apparent
later. In the requirements process, quality attributes must be
attached to system functions as much as possible.
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
22
Checklist eisen aan software
versie 1.2 09.03.2001
Appendix 4 DiagramtechniekenDit appendix is bedoeld voor
BIT-studenten aan de UT. Het geeft een overzicht van de technieken
die in de studie aan de orde gekomen zijn.
Gewenste functionaliteit
q
Missiestatement. Geeft bestaansreden van systeem weer,
belangrijkste functies plus dingen die het systeem niet zal doen.
Goed voor het management van verwachtingen en het voorkomen van
doelverschuiving. ISM. Functieverfijningsboom. Hierarchische lijst
met gewenste functies van een systeem. Handig als praatplaat. ISM.
Use case model. Gestructureerde beschrijvingen van gewenste
systeemfunctionaliteit. Eventueel geillustreerd met een use case
diagram dat de communicaties van elke use case (functionaliteit)
beschrijft. ISM, SE
q q
Communicatie
q q q q
Context diagram. Geeft communicatie tussen systeem en externe
entiteiten weer. IS, SE, ISM Informatie Flow Diagram (IFD).
Representatie van input en output informatiesytromen van een
informatiesysteem. Alternatief voor contextdiagram. AOIS en BISO.
Use case diagram. Beschrijft communicatie tussen systeem en
omgeving per use case. Alternatief voor contextdiagram. SE, ISM
Data flow diagram (DFD). Beschrijft de communicaties tussen
processen, stores en externe entiteiten. Vaak zijn de processen
applicaties en de stores databases. Maar processen in een DFD
kunnen ook bedrijfsactiviteiten weergeven; of subsystemen van een
programma; etc. IS, SE, ISM, AOIS, BISO. LANO-matrix Beschrijft
interfaces tussen activiteiten. Equivalent aan een DFD zonder
stores. AOIS, BISO. Collaboratiediagram. Beschrijft een scenario
waarin een aantal objecten met elkaar communiceren. Laat zien welke
links er tussen de objecten moeten zijn. ISM sequence diagram.
Zelfde als communicatiediagram, maar nu zonder de links en met een
tijdsas (van boven naar beneden).
q q q q q
ISM
GedragEvent list. Lijst met gebeurtenissen en de acties die ze
moeten triggeren. IS, ISM
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
23
Checklist eisen aan software
versie 1.2 09.03.2001
q q q q q
toestandsovergangstabel. Tabel waarin voor elke gebeurtenis en
huidige toestand staat wat de volgende toestand en de getriggerede
acties is. ISM Toestandsovergangsdiagram. Grafische representatie
van toestandsovergangstabel. IS, SE, ISM Tijdslogica. Formele taal
om eigenschappen vvan systemen in te specificeren. Discrete
wiskunde en logica (151050) Z. Formele taal om pre- en
postcondities van operaties te beschrijven. Specificatiemethoden.
Activiteitendiagram. Representeert activiteiten en de volgorde
waarin die uitgevoerd worden. Bevat constructies voor keuze en
parallelisme. Bedoeld voor de representatie van workflows. ISM
Decompositie
q
Entity-relationship diagram (ERD). Declaratie van types
entiteiten en hun cardinaliteitseigenschappen. Kan gebruikt worden
om de struktuur van het subjectdomein te representeren maar ook om
een conceptuele gegevensstruktuur te representeren. IS,
Gegevensbanken, SE, ISM. BISO NIAM diagram (ook wel binair
gegevensmodel genoemd). Versie van ERD waarin alle relaties binair
zijn. Ook de relatie tussen en entiteit en een attribuut is binair.
AOIS en BISO Static structure diagram (SSD) (soms class diagram of
object diagram genoemd) Declaratie van classes objecten en hun
multipliciteitseigenschappen. Kan gebruikt worden om de structuur
van OO software aan te geven. Verschil met ERD is dat SSD aangeeft
welke objecten welke diensten (services, operaties, signalen)
hebben. IS, SE, ISM.
q q
Universiteit Twente, Faculteit Informatica, Leerstoel
Informatiesystemen
24