Checklist DvE

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


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



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.


4


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


5


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


6


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?


7


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.


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.


8


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


9


versie 1.2 09.03.2001

Stap 3: Het haalbare doelDoel van deze stapHet ideale systeemdoel wordt nu omgezet in haalbaar systeemdoel.


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.


10


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.


11


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.


12


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.


13


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.


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


14


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]


15


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


16


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?


17


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].


18


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.


19


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


20


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.


21


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.


22


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


23


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


24

Checklist DvE

Documents

Transcript of Checklist DvE