Bijlagen A bij hoofdstuk III over Definitiestudie:

B3: Systematisch bouwen van informatiesystemen

Bijlagen A bij SDM-fase 1: Definitiestudie

Bijlagen ‘A’ bij hoofdstuk III over Definitiestudie: Bijlage DS - a) :

Gedetailleerde uitwerking van de aanpak bij activiteit 1.5

Je doet er goed aan je te realiseren dat op het moment dat met activiteit 1.5 begonnen wordt, reeds allerlei gegevens over het gewenste informatiesysteem beschikbaar zijn: - in activiteit 1.2 Gewenste informatievoorziening bepalen zijn gegevens (onder andere van de toekomstige gebruikers) verzameld die de gewenste informatievoorziening in kaart brengen; - in activiteit 1.3 Bepaling van de veranderingsbehoefte en de systeemeisen zijn deze gegevens vertaald in de veranderingen waaraan behoefte is, en de systeemeisen. Met deze gegevens in het achterhoofd gaan we nu een ontwerp in hoofdlijnen maken voor het te bouwen informatiesysteem. We maken dit ontwerp in hoofdlijnen door aan te geven welke de hoofdfuncties zijn die het te bouwen informatiesysteem moet bieden. We zullen de werkwijze toelichten, dit gebeurt deels aan de hand van het in een bijlage bij SDM-fase 0 reeds besproken voorbeeld over de factureringsafdeling ; de volledige uitwerking van dit voorbeeld is weer in een bijlage bij dit hoofdstuk terug te vinden.

Activiteit 1.5 - I) Het systeemconcept:

A

: de hoofdfuncties

SDM-fase 0: informatieplanning leverde inzicht in de bestaande situatie waarin het informatiesysteem gerealiseerd moet worden en in de beleidslijnen die er voor de toekomstige informatievoorziening zijn. De fase definitiestudie heeft tot nu toe gegevens geleverd over de gewenste toekomstige informatievoorziening (activiteit 1.2) en over gewenste veranderingen en de systeemeisen (activiteit 1.3). Op grond van deze gegevens kunnen de hoofdfuncties van het te bouwen informatiesysteem bepaald worden. Als de huidige en de toekomstige informatievoorziening sterk op elkaar lijken, dan zal uit de beschrijving van de huidige situatie (fase 0) zonder meer duidelijk zijn wat de hoofdfuncties moeten zijn waarbinnen de systeemeisen gerealiseerd moeten worden. Wijkt de toekomstige informatievoorziening belangrijk af van de huidige, dan zullen de hoofdfuncties op grond van een analyse van de gewenste veranderingen moeten worden bepaald: de hoofdfuncties zullen immers overeen moeten komen met wat in de systeemeisen is vastgelegd. Wij kunnen bij het vastleggen van het systeemconcept echter niet volstaan met alleen maar aan te geven wat de toekomstige hoofdfuncties zullen zijn; we moeten ook de relatie tussen de hoofdfuncties onderling en tussen hoofdfuncties en de buitenwereld aangeven. Dit kan (net zoals dat in de situatieanalyse gebeurd is voor de bestaande situatie) gebeuren door een SADT-diagram van de hoofdfuncties en hun relaties te maken. Echter: in de beschrijving van de hoofdfuncties van het te bouwen informatiesysteem en hun relaties speelt anders dan in de bestaande situatie - ook het centrale element van een informatiesysteem: de gegevensbank een rol. Wij moeten derhalve voor het te bouwen informatiesysteem de relaties aangeven tussen: - hoofdfuncties en de buitenwereld - hoofdfuncties onderling - hoofdfuncties en de gegevensbank. Het volgende diagram moet dus met die relaties (/interacties) worden aangevuld:

Hoofdfunctie 1

Gegevensbank

Hoofdfunctie 2

Hoofdfunctie 3

DS-bijlagen A blz. 1



In een andere bijlage bij dit hoofdstuk is voor ons concrete voorbeeld over de factureringsafdeling te vinden, dat het SADT-diagram van de daar van toepassing zijnde hoofdfuncties er als volgt komt uit te zien:

factureringsopdracht

factureringsgegevens

factureren

veranderopdracht

kopiefactuur

blanco kopie/opdracht-form. gegevensbank

te corrigeren fact.gegevens factuurgegevens verzendopdracht

verzenden

factuurgegevens

verzendgegevens

factuur met verzendgegevens

nieuwe of gewijzigde verzendgegevens blanko formulieren

nieuwe of gewijzigde

Hoewel er in dit SADT-diagram over de factureringsafdeling hoofdfuncties zijn opgenomen, die overeenkomen met de onderdelen van de afdeling facturering zijn er vanwege het feit dat we nu een informatiesysteem beschrijven in plaats van de bestaande situatie en vanwege de introductie van een gegevensbank een aantal zaken veranderd ten opzichte van het diagram waarin de huidige situatie van de afdeling was vastgelegd. We lopen de veranderingen na. Binnen een gecomputeriseerd informatiesysteem gaan geen goederen om, maar gegevens. In ons geval zullen we aannemen, dat alle in het informatiesysteem binnenkomende gegevens (pijlen die van links en van boven binnenkomen) via een toetsenbord worden ingetikt. Zo komen bijvoorbeeld de 'nieuwe of gewijzigde verzendgegevens' via een toetsenbord in de hoofdfunctie verzenden binnen; natuurlijk staan die gegevens in eerste instantie op papier en komen zo terecht bij degene die het intypen verzorgt, maar op het moment dat de ingetypte gegevens in de hoofdfunctie van het informatiesysteem binnenkomen zijn het 'papierloze' computergegevens geworden. Met behulp van een printer (afdrukeenheid) kunnen gecomputeriseerde informatiesystemen gegevens op papier afdrukken; dit betekent dat goederen (papier) met daarop afgedrukte gegevens door het informatiesysteem geproduceerd kunnen worden (het gaat in het SADT-diagram dan om pijlen die aan de rechterkant naar buiten komen). Natuurlijk kunnen de gegevens vóór deze worden afgedrukt ook eerst nog op een beeldscherm bekeken worden, maar het door het informatiesysteem af te leveren product is papier met daarop gegevens. Introductie van de gegevensbank leidt ook tot veranderingen ten opzichte van de oorspronkelijke situatie. In ons geval worden alle gegevens die in de hoofdfuncties een rol spelen, in de gegevensbank opgeslagen. De gegevensbank functioneert als bewaarplaats van de door de hoofdfunctie facturering geproduceerde factuurgegevens, waaruit de hoofdfunctie verzenden weer put; ook de verzendgegevens worden in de gegevensbank bewaard. Een harde eis van de directie van de groothandel (de opdrachtgever) is dat er in de huidige wijze van functioneren van de onderdelen van de factureringsafdeling geen enkele wijziging mag optreden. Deze eis heeft als gevolg dat het informatiesysteem nadat factuurgegevens zijn opgeslagen in de gegevensbank, een seintje (een papieren verzendopdracht) moet geven aan het personeel van het onderdeel verzenden om aan te geven dat de gegevens van een bepaalde factuur voor verzending gereed zijn. Na ontvangst van dit (papieren) seintje moet het personeel de hoofdfunctie verzenden van het informatiesysteem in werking zetten door de verzendopdracht in te tikken.




Samenvattend over de hoofdfuncties: Het te bouwen informatiesysteem bevat een aantal hoofdfuncties die het mogelijk maken de gewenste informatievoorziening te realiseren. Indien de veranderingsbehoefte binnen de organisatie beperkt is, zullen deze hoofdfuncties vaak samenvallen met de onderdelen van de organisatie die in de situatieanalyse beschreven zijn. De hoofdfuncties maken gebruik van gegevens van buiten het informatiesysteem en spelen gegevens aan elkaar door; in onze situatie worden de gegevens in het informatiesysteem ingevoerd door deze via een toetsenbord in te typen. De hoofdfuncties kunnen gegevens produceren op een beeldscherm of via een printer afgedrukt op papier. Voor de opslag van gegevens maakt het informatiesysteem gebruik van een gegevensbank. De door hoofdfuncties geproduceerde gegevens worden in onze situatie altijd in de gegevensbank opgeslagen, ook al gaat het misschien om tussenresultaten die door een andere hoofdfunctie gebruikt moeten worden of om gegevens die ook op papier worden afgedrukt.

Activiteit 1.5 - II)

Het systeemconcept:

B : de interacties

Het eerste onderdeel in activiteit 1.5 heeft als resultaat een SADT-diagram opgeleverd waarin van het te bouwen informatiesysteem de hoofdfuncties zijn aangegeven evenals de relaties tussen de hoofdfuncties onderling en met de buitenwereld. In dit tweede onderdeel van activiteit 1.5 maken we voor later gebruik een inventarisatie van de relaties: de interacties van de hoofdfuncties met de buitenwereld en de interacties binnen het informatiesysteem. Het idee achter het maken van deze inventarisatie is, dat een (SADT-)diagram wel erg goed en prettig werkt voor het verkrijgen van een snel overzicht, maar dat het erg moeilijk is om alle details uit het diagram in de gaten te houden. Zo'n inventarisatie van alle details (hier: interacties) wordt ons erg gemakkelijk gemaakt omdat in het SADT-diagram alle interacties reeds met pijlen staan aangegeven; we hoeven ze alleen maar na te lopen en overzichtelijk te rangschikken. Dat rangschikken doen we via de volgende hoofdindeling: - Interacties met de buitenwereld: pijlen waarlangs ingetikte besturingsgegevens binnen komen, pijlen waarlangs ingetikte grondstofgegevens binnenkomen, pijlen waarlangs via het beeldscherm of via de printer geproduceerde productgegevens naar buiten komen; - Interacties binnen het informatiesysteem: pijlen waarlangs gegevens tussen de hoofdfuncties en de gegevensbank getransporteerd worden, pijlen van de ene hoofdfunctie naar de andere waar gegevens langs getransporteerd worden. Van deze beide types kunnen we ook weer subtypes aangeven (zie daarvoor echter de uitgewerkte rapporten in de bijlagen bij dit hoofdstuk). Samenvattend over de interacties: Aan de hand van het SADT-diagram dat de hoofdfuncties van het informatiesysteem beschrijft, kunnen we de interacties van het informatiesysteem met de buitenwereld inventariseren, evenals de interacties binnen het informatiesysteem tussen de hoofdfuncties onderling en tussen hoofdfuncties en gegevensbank. Er zijn besturingsinteracties, grondstofinteracties en productinteracties.

Activiteit 1.5 - III)

Het systeemconcept :

C : de gegevens

(1e deel: C.1)

Welke gegevens spelen een rol in ons informatiesysteem en naar welke objecten (personen, begrippen, dingen) in de werkelijkheid verwijzen deze? En wat is de onderlinge relatie tussen deze objecten in de werkelijkheid? Op deze belangrijke vragen proberen we in dit onderdeel van activiteit 1.5 een antwoord te vinden. De gegevens die in de gegevensbank van het informatiesysteem worden opgeslagen, zijn tezamen de weerslag van een deel van de werkelijkheid in de wereld buiten het informatiesysteem. De gegevens van de Informatiseringsbank in Groningen geven een beeld van het deel van de werkelijkheid waar het om studeren en studiefinanciering gaat. De gegevens in de gegevensbank van een NS-baliecomputer zijn de neerslag van het spoorwegnet in Nederland en de door de NS gehanteerde tariefstructuur. Het is van veel belang dat de gegevens in het informatiesysteem in overeenstemming zijn en blijven met het deel van de werkelijkheid dat zij beschrijven. Fouten in de gegevens leiden onvermijdelijk tot interpretaties die in de werkelijkheid niet kloppen; omdat over het algemeen wordt aangenomen dat door het informatiesysteem geleverde gegevens correct zijn, kan de interpretatie van incorrecte gegevens tot vervelende toestanden aanleiding geven. Ieder kent wel voorbeelden uit haar of zijn omgeving waarin 'de computer' de schuld van een fout was.




Bij het ontwerp van een informatiesysteem worden de objecten in de werkelijkheid die horen bij de gegevens die in het informatiesysteem bewaard gaan worden, geanalyseerd om kenmerken te ontdekken die deze objecten altijd hebben. Deze kenmerken spelen een belangrijke rol in ontwerp en bouw van het informatiesysteem. Door rekening te houden met het altijd geldig moeten zijn van deze kenmerken, kan de kwaliteit van een informatiesysteem verbeterd worden. Het analyseren van de objecten die bij de gegevens in het informatiesysteem horen, staat bekend onder de naam: informatieanalyse. In dit onderdeel van activiteit 1.5 (de gegevens) maken we een begin met de informatieanalyse. Eerst worden de gegevens die in het informatiesysteem een rol spelen geïdentificeerd. Daarna worden de bij deze gegevens behorende objecten in de werkelijkheid in onderlinge samenhang geplaatst. De uitleg gaat weer aan de hand van het voorbeeld van de factureringsafdeling.

Voorbeeld: factureringsafdeling De resultaten uit de vorige twee onderdelen van activiteit 1.5 (de hoofdfuncties en de interacties) maken het ons gemakkelijk om te bepalen welke categorieën van gegevens in de gegevensbank van het informatiesysteem bewaard zullen worden. In het SADT-diagram uit activiteit 1.5, de hoofdfuncties, geven de pijlen naar en van de gegevensbank aan welke gegevens naar de gegevensbank gaan en er ook weer uitgehaald worden. In activiteit 1.5, de interacties, is hier nog weer eens een inventarisatie van gemaakt. Uit de eerdere resultaten van activiteit 1.5 zien we dat in het voorbeeld van de factureringsafdeling de volgende categorieën van gegevens in de gegevensbank zitten: - factuurgegevens - verzendgegevens. Nu dringt zich echter de vraag op: "Welke gegevens zitten er nu precies in die categorieën?". Om die vraag te kunnen beantwoorden moeten we gaan kijken in de werkelijkheid van de factureringsafdeling. Hoe ziet een factuur eruit en wat zijn de verzendgegevens die aan de factuur moeten worden toegevoegd? Hieronder geven we het (blanco) factuurformulier van de firma "En Masse":

Groothandel "En Masse" Industrieweg 44 2021 WF Amsterdam 020 - 5577880

FACTUU R

Klantnummer: .....................

.

Datum: ..... / ..... / ..... Factuurnummer: ...................

............. ...

Artikelnummer: ........ FACTUUR Klantnummer: ..................... ................... . Factuurbedrag: ...................

.......... .. Datum: ..... / ..... / .....

GroothandelFactuurnummer: "En Masse" is even bij de Kamer van ................... ingeschr Koophandel te Amsterdam onder nummer: - 13a A39744

Artikelnummer:

...................

Factuurbedrag: ...................

Groothandel "En Masse" is ingeschreven bij de Kamer van Koophandel te Amsterdam onder nummer: A39744 - 13a




En hierna volgt een voorbeeld van een ingevulde factuur waarop zowel de factuurgegevens alsook de verzendgegevens zijn ingevuld:

Groothandel "En Masse" Industrieweg 44 2021 WF Amsterdam 020 - 5577880

Firma K. Klaassens Westeinde 12 6521 PP Nijmegen

FACTUUR

Klantnummer: 13572 Datum: 24 / 4 / 03

Factuurnummer: 240403127 Artikelnummer:

12015183

Factuurbedrag:

12081.94

Groothandel "En Masse" is ingeschreven bij de Kamer van Koophandel te Amsterdam onder nummer: A39744 - 13a

N.B. Mochten er in een aangetroffen situatie geen formulieren in omloop zijn, waaruit duidelijk blijkt wat er onder bepaalde gegevens wordt verstaan, dan moet je anders te werk gaan. Dit geval hoeft zich niet alleen voor te doen bij het ontwikkelen van een informatie-systeem voor een hele nieuwe toepassing; het kan ook zijn dat de in de huidige situatie gebruikte formulieren niet meer voldoen en vervangen moeten worden. Wanneer bij de analyse niet uit kan worden gegaan van bestaande formulieren, dan kunnen het beste in samenwerking met de toekomstige gebruiker(s) formulieren of beeldschermen ontworpen worden waaruit duidelijk blijkt wat onder bepaalde gegevens wordt verstaan. Het voordeel van het ontwerpen van formulieren of beeldschermen is dat met de toekomstige gebruikers van het informatiesysteem op een voor hen concrete manier gepraat kan worden over wat in hun werkelijkheid een rol speelt. De techniek van prototyping kan hier dus zeker tot zijn recht komen. In ons voorbeeld hebben we een bestaand formulier, dat er zoals op de vorige bladzijde(n) beschreven uitziet. Wij kunnen dit formulier zonder meer voor onze analyse gebruiken omdat er in de nieuwe situatie met informatiesysteem niets verandert ten opzichte van de oude situatie (er zijn geen veranderingsbehoeften). Een gedegen analyse van de inhoud van een (invul)formulier vertelt ons veel over de werkelijkheid waarin het gebruikt wordt. Wij voeren zo'n analyse uit.

Formulieranalyse - Objecten in de werkelijkheid van de factureringsafdeling Allereerst bekijken we het ingevulde formulier waarop zowel de factuurgegevens als de verzendgegevens staan. Wij gaan na welke gegevens in de gegevenscategorieën zitten. Deze inventarisatie levert het volgende op: factuurgegevens:

klantnummer, factuurnummer, datum, artikelnummer, factuurbedrag

verzendgegevens:

klantnaam, straatnaam en huisnummer, postcode, woonplaats




Deze gegevens verwijzen naar personen, begrippen of dingen in de werkelijkheid (deze personen, begrippen en dingen uit de werkelijkheid zullen we aanduiden met de verzamelnaam objecten). Hieronder staat aangegeven naar welke objecten uit de werkelijkheid verwezen wordt. Verwijzing naar objecten: factuurgegevens:

klantnummer, factuurnummer, datum, artikelnummer, factuurbedrag

verzendgegevens:

klantnaam, straatnaam en huisnummer, postcode, naam van woonplaats

Toelichting: - aan factuurbedrag is het interessante, dat het verwijst naar een bedrag; bedragen kun je optellen en aftrekken, etc. - straatnaam en huisnummer verwijzen naar een bepaald huis in een bepaalde straat. Wij hebben in de werkelijkheid van de factureringsafdeling de volgende objecten geïdentificeerd, waarnaar factuurgegevens en verzendgegevens verwijzen: factuurgegevens:

klant, factuur, datum, artikel, bedrag

verzendgegevens: klant, straat, huisnr, postcode, woonplaats.

Formulieranalyse - Hiërarchie van objecten van de factureringsafdeling Vaak zijn de geïdentificeerde objecten uit de werkelijkheid zelf weer te vangen onder een ander begrip (object) dat in de beschouwde werkelijkheid van belang is. Een voorbeeld hiervan vind je bij de objecten waarnaar de verzendgegevens verwijzen: adres |- - - - - - - - - - - - - - - - - - - - - - - - - - -| straat, huisnr, postcode, woonplaats Adres is een verzamelbegrip voor straat, huisnr, postcode en woonplaats tezamen. Dit begrip is in de wereld van de factureringsafdeling belangrijk. De objecten straat, huis, postcode en woonplaats vormen gezamenlijk het object adres. Als objecten in de werkelijkheid van de factureringsafdeling waarnaar verwezen wordt, hebben we nu dus gevonden: factuurgegevens:

klant, factuur, datum, artikel, bedrag

verzendgegevens: klant,

adres |- - - - - - - - - - - - - - - - - - - - - - - - - - -| straat, huisnr, postcode, woonplaats

Er is een hiërarchie ontstaan in de objecten: adres is een verzamelbegrip (object) voor vier andere objecten (straat, huisnr, postcode en woonplaats) en staat hoger in de hiërarchie. Nadere analyse van het factuurformulier levert nog meer hiërarchie in de objecten op. Wanneer je het oningevulde factuurformulier bekijkt, dan zie je dat er op een aantal plaatsen gegevens op het formulier moeten worden ingevuld. In ons voorbeeld staan op die plaats puntjes. Voor die puntjes staat een omschrijving van de (soort) gegevens die op die plaats moeten worden ingevuld. Er staan ook nog andere dingen dan gegevens en omschrijvingen op het formulier. Het betreft hier de tekst "FACTUUR" en de tekst met de naam en het adres van het bedrijf "En Masse" zelf, boven aan het formulier. Deze teksten komen, evenals de omschrijvingen, op alle facturen voor.




Wanneer je extra tekst standaard op een formulier tegenkomt (buiten omschrijvingen en gegevens) dan geeft die tekst meestal aan dat sommige gegevens belangrijker zijn dan andere; er is dan vaak sprake van een hiërarchie in gegevens. Voor de beschouwde werkelijkheid betekent dit, dat de daarin werkende en levende mensen bepaalde verbanden tussen bepaalde objecten (personen, begrippen of dingen) belangrijker vinden dan andere. Zo kun je uit het voorbeeldformulier opmaken dat in de wereld van groothandel "En Masse" vooral belangrijk gevonden wordt, dat een factuur voor een klant is. Je kunt dat aan de indeling en de opmaak van het formulier zien. In eerste instantie gaat het in de werkelijkheid van "En Masse" blijkbaar om klant en factuur; daarna pas om andere objecten waarvan het formulier gegevens bevat. Dit betekent niet dat de overige objecten (met bijbehorende gegevens op het formulier) niet van belang zijn, maar wel dat tussen de verschillende objecten (en gegevens) een hiërarchie van belangrijkheid bestaat. Je zou kunnen zeggen dat in deze hiërarchie het begrip factuur zowel een verzamelaanduiding is voor de objecten: datum, artikel en bedrag, die corresponderen met de gegevens 'datum', 'artikelnummer' en 'factuurbedrag '', als het object is dat hoort bij het gegeven 'factuurnummer '. Het begrip klant is het object dat hoort bij de gegevens 'klantnummer ' en 'klantnaam’. Het begrip adres is eigenlijk een object, dat in deze situatie niet los zal voorkomen, maar altijd deel zal uitmaken van klant. Eigenlijk hadden we op onze klompen kunnen aanvoelen dat in de wereld van een groothandel de klant èn het door hem te betalen geld centrale begrippen zijn! Het factuur-formulier is hiervan alleen maar een illustratie. In het algemeen moet je bij het uitvoeren van een ‘informatieanalyse’ op de hoogte proberen te geraken van de objecten die belangrijk zijn binnen die organisatie (ofwel: binnen hun UoD: ‘Universe of Discourse’) en van het door de medewerkers van die organisatie zèlf gebezigde taalgebruik met betrekking tot die objecten. Om te kunnen ontdekken wat de verbanden zijn tussen de verschillende in die organisatie van belang zijnde objecten/gegevenssoorten heb je vaak veel kennis nodig van de wereld waarin het informatiesysteem gebruikt wordt. Ook het kunnen vaststellen van de hiërarchisch gezien meest belangrijke objecten van zo’n UoD is iets waar je door ervaring met informatieanalyse op te doen en je in te kunnen leven in het betreffende soort organisatie, steeds handiger in wordt. Het is dus geen wonder dat men de noodzaak voelt een "informatiekundige" (iemand met verstand van zowel de betreffende wereld alsook van informatica) een belangrijke rol bij het ontwerpen van informatiesystemen te laten spelen. In ons geval betekent dit dat klant en factuur de meest centrale begrippen zijn in de werkelijkheid van de facturering; een ietwat minder centraal begrip is adres, dat meer gezien kan worden als een hulpobject van klant, waar die factuur naar toe gestuurd moet worden. Hiermee is de formulieranalyse afgerond. Als resultaat hebben we gevonden welke objecten in de werkelijkheid horen bij de gegevens op het formulier (dat zijn dezelfde gegevens als in de gegevensbank van ons informatiesysteem worden opgeslagen!) en in welke hiërarchie de objecten voorkomen. N.B. Let er op, dat weliswaar ieder gegeven naar een object verwijst, maar dat níet ieder object per se naar een hiërarchisch gezien 'hoger gelegen object' hoeft te verwijzen. Zo verwijzen bij de factuurgegevens 'artikelnummer' en 'factuurbedrag' respectievelijk (eerst) naar de objecten artikel en bedrag. Beide objecten verwijzen op hun beurt door naar het hoger gelegen object factuur. Daarentegen verwijst het gegeven 'factuurnummer' rechtstreeks naar het hoogstgelegen object factuur. Een hiërarchische gelaagdheid treedt alleen op indien binnen de betreffende organisatie (hier dus: de factureringsafdeling) duidelijk van die 'tussenobjecten' sprake is. Let daarom bij de formulieranalyse dus ook op het heersende taalgebruik binnen de organisatie! Voortzetting informatieanalyse Welke gegevens spelen een rol in ons informatiesysteem en naar welke objecten (personen, begrippen, dingen) in de werkelijkheid verwijzen deze? En wat is de onderlinge relatie tussen deze objecten in de werkelijkheid. Op deze belangrijke vragen proberen we in dit onderdeel van activiteit 1.5 een antwoord te vinden. De objecten die in de beschouwde werkelijkheid een rol spelen, kennen we inmiddels. En ook hun onderlinge hiërarchie is bekend.




Om nu op een systematische wijze de relaties, die tussen de verschillende objecten bestaan, in beeld te brengen, gaan we ons richten op de verwoordingen die binnen de organisatie gebruikelijk zijn om onderlinge relaties tussen de verschillende object-typen aan te geven. Aan de hand van een analyse van deze verwoordingen gaan we tot slot een grafisch model (een conceptueel schema of een informatie-structuurdiagram) maken van de relaties tussen de verschillende object-typen in het betreffende UoD.

Relaties in op NIAM gebaseerde informatieanalyse-methodes De relatie die tussen twee objecten uit de werkelijkheid bestaat, kan worden beschreven door zinnetjes waarin de namen van deze objecten voorkomen. Een relatie tussen twee (soorten) objecten wordt ook wel een 'binaire relatie' genoemd (binair betekent: twee-ig, tussen twee). Een relatie tussen drie (soorten) objecten wordt een 'ternaire relatie' genoemd. In het algemeen spreken we van 'n-aire relatie' als daar ‘n’ objectsoorten bij betrokken zijn. In de praktijk blijken binaire relaties het vaakst voor te komen en daarna ternaire relaties. Laten we eens kijken naar de binaire relatie tussen de uit ons voorbeeld van de factureringsafdeling bekende objecten klant en factuur. Een mogelijk zinnetje om een in dit UoD veel voorkomend feit aan te duiden is: "Een klant krijgt een factuur" De relatie die hierin beschreven wordt is: Een klant "krijgt" een factuur. De relatie wordt in de NIAM-methode een 'rol' genoemd: "krijgt" is bijvoorbeeld een aanduiding van zo'n rol. Wanneer je goed kijkt naar zo'n rol, bijvoorbeeld naar "krijgt" in: "Een klant krijgt een factuur" dan zie je dat er 'richting' in de rol zit: er geldt wèl dat: "Een klant krijgt een factuur" , maar nièt dat: "Een factuur krijgt een klant". Wel geldt dat:

"Een factuur 'is voor' een klant"

, met als rol: "is voor".

In een relatie tussen twee objecten (een binaire relatie) is er altijd sprake van tweerichtingsverkeer en dus van twee rollen. Het 'spiegelbeeld' van een rol noemen we een 'co-rol'. In een plaatje ziet dat er als volgt uit: rol

co-rol

object 1

object 2

Zo'n plaatje heet in de NIAM-methode een 'informatie-structuurdiagram'. Hier hebben we een wel heel eenvoudig diagram: er zijn maar twee objecten met één relatie ertussen. Veel vaker bevatten informatiestructuurdiagrammen een heleboel objecten met daartussen allerlei relaties. Voordeel van zo'n informatie-structuurdiagram is dat je snel kunt aflezen welke relaties er tussen de diverse object-typen bestaan. De relatie tussen klant en factuur, zoals boven, ziet er in een informatie-structuurdiagram als volgt uit: krijgt klant

is voor factuur

Je kan dit plaatje als volgt lezen: In deze relatie speelt het object klant de rol 'krijgt'. De co-rol 'is voor' wordt gespeeld door het object factuur.




De namen die we voor de rol en de co-rol hebben gekozen, lijken puur toevallig. Als we van een ander zinnetje waren uitgegaan, bijvoorbeeld: "Een klant heeft een factuur" of "Een klant met een factuur", dan hadden we een andere naam voor de rol en de co-rol gekregen.

ORM: Object Role Modeling ORM is een sterk ontwikkelde tak aan de stam van de boom van de informatieanalyse-methodes die gebaseerd zijn op NIAM. Onderdeel van die ORM-methode is, om de verwoording van de binnen het beschouwde UoD (Universe of Discourse) bestaande feiten/relaties wat formeler te maken. Voor het gemak laten we bij ORM [meestal] de lidwoorden uit verwoordingen weg. We hadden:

Een klant "krijgt" een factuur.

We schrijven dit in ORM als: Klant krijgt Factuur.

en/of:

Een factuur “is voor” een klant.

en/of:

Factuur is voor Klant.

We kunnen dit tot concrete voorbeelden omwerken, door [indien mogelijk] achter de objecttypen een voorbeeld-waarde te geven. Uit het getoonde, ingevulde factuurformulier halen we:

en/of:

Klant ‘13572’ krijgt Factuur ‘240403127’. Factuur ‘240402127’ is voor Klant ‘13572’.

Niet altijd is het mogelijk om zo achter elk objecttype een enkele identificerende waarde te plaatsen, maar als dat mogelijk is, dan kunnen we voorgaande voorbeeld ‘feitexpressies’ met hun ‘enkelvoudige’ identificatie formeler als volgt aangeven:

en/of:

Klant (klantnummer) krijgt Factuur (factuurnummer). Factuur (factuurnummer) is voor Klant (klantnummer).

We kunnen deze twee bij elkaar behorende feitexpressies samenvoegen tot de in ‘twee richtingen’ leesbare expressie: Klant (klantnummer) krijgt / is voor Factuur (factuurnummer). Zoals eerder gesteld, is de hierboven tweemaal toegepaste ‘enkelvoudige’ identificatie niet altijd mogelijk. Als voorbeeld daarvan nemen we als verwoordingen van de relatie tussen ‘klant’ en zijn/haar ‘adres’:

en/of:

"Een klant heeft een adres" “Het adres van de klant”

In formelere ORM-verwoordingsmanier kan wel weer ‘klant’ enkelvoudig geïdentificeerd worden, maar kan dat niet voor ‘adres’: Klant (klantnummer) heeft Adres. en/of: Adres van Klant (klantnummer). De tweezijdig-leesbare variant met samengevoegde feitexpressies is uiteraard: Klant (klantnummer) heeft / van Adres. In het ‘conceptuele schema’ (het ‘bollenschema’) worden de objecttypen Klant, Factuur en Adres met hun rol- en co-rol-aanduidingen weergegeven en indien mogelijk ook hun (identificerende) ‘referentie’-waarde:



Factuur (factuurnummer)


Klant (klantnummer)

is voor /krijgt

heeft / van

Adres

Correct !!! We bespreken later op welke wijze de identificatie van het objecttype Adres kan plaatsvinden.

N.B. 1.

Uiteraard moet je je steeds afvragen of het gevonden informatie-structuurdiagram wel het correcte is. Zo zou je bij ons voorbeeld over de factureringsafdeling je kunnen afvragen of het volgende informatie-structuurdiagram niet het juiste zou zijn: Factuur (factuurnummer)

is voor /krijgt

Klant (klantnummer)

heeft / van

Adres

Fout !!!! In dit diagram wordt met stippellijntjes een relatie tussen factuur en adres gesuggereerd. De formulieranalyse heeft via gebruikersverwoordingen opgeleverd dat er een directe relatie is tussen klant en adres. Tussen factuur en adres bestaat echter geen directe relatie! Een (indirecte) relatie tussen factuur en adres moet altijd via klant gelegd worden, zoals in het ‘oude’ diagram gebeurt. N.B. 2.

De gebruikte en geanalyseerde zinnetjes komen voort uit de werkelijkheid die "geautomatiseerd" moet worden. De zinnetjes moeten iets over de objecten zeggen, op een zodanige wijze dat ze begrijpelijk zijn voor de toekomstige gebruikers van het te bouwen informatiesysteem; tenslotte zeggen de zinnetjes iets over hùn werkelijkheid. Verder moet vast rekening worden gehouden met het feit dat het informatie-systeem straks informatie zal moeten gaan leveren over de in de zinnetjes vastliggende relaties tussen objecten. Het informatie-systeem moet opdrachten kunnen uitvoeren in de trant van: "Toon Klant met Factuur ..."

of

"Verwijder Factuur van Klant ...".

Kies daarom als rolnaam en als co-rolnaam zinvolle namen, passend in de wereld van de gebruiker. Het voordeel van een naamgeving van de rollen die zowel aansluit bij de activiteiten van het toekomstige informatiesysteem als bij de wereld van de gebruiker, ligt in de mogelijkheid die je er door krijgt om de gewenste informatievoorziening, zoals deze in fase 0: informatieplanning globaal beschreven is, concreter in te vullen. En wel op een wijze die de toekomstige gebruikers van het informatiesysteem aan zal spreken; bij de invulling maak je immers gebruik van objecten en relaties (rollen) met namen uit de werkelijkheid van die gebruikers. In deze fase wordt de gewenste informatievoorziening geconcretiseerd op het bovenste niveau van de objectenhiërarchie.

N.B. We hebben ons hier tot nu toe gericht op de belangrijkste objecttypen van dit Universe of Discourse (het UoD van de factureringsafdeling): Klant, Factuur en Adres. Verderop bij deel C.2 zullen we ook de relaties met de minder belangrijke objecttypen, zoals Straat, Woonplaats en (klant)Naam, analyseren en in het informatie-structuurdiagram plaatsen.

Activiteit 1.5 - IV)

D:

concretisering van de informatiewensen

Op grond van (het eerste deel van) onze informatieanalyse kunnen we de resultaten van activiteit 1.2 concreter invullen en krijg je de kans om de gewenste informatievoorziening duidelijker te omschrijven in




termen van de personen, begrippen en objecten (verzamelnaam objecten) die in de werkelijkheid van de toekomstige gebruiker van het informatiesysteem een rol spelen, en in termen van de relaties tussen deze objecten. Wij zeggen dat je de informatiebehoefte van de gebruikers van het informatiesysteem kan specificeren in termen van voor deze gebruikers herkenbare objecten en relaties (welke objecten spelen een rol in de beschouwde werkelijkheid en wat zou ik daarover willen weten). Dat heeft tot voordeel dat je een informatiebehoefte al in een vroeg stadium van het ontwerpproces heel precies kunt omschrijven, zelfs nog voordat je weet hoe de gegevens straks in de gegevensbank worden opgeslagen. Ook ingewikkelde informatiebehoeften laten zich zo gemakkelijk precies omschrijven. Met gegevens zijn slechts vier basisoperaties mogelijk: - toevoegen (aan de overige gegevens in een gegevensbank; - tonen (via beeldscherm of op papier of misschien zelfs op andere wijzen); - muteren (veranderen van de in de gegevensbank opgeslagen waarden); en: - verwijderen (uit de gegevensbank). Je kunt deze basisoperaties vergelijken met de SQL-opdrachten INSERT, SELECT, UPDATE en DELETE. Het is bij deze activiteit nu de bedoeling om alle bij activiteit 1.2 gevonden informatiewensen eenduidig vast te leggen in termen van deze vier basisoperaties en de namen van de (hoofd-) objecten en relaties uit het NIAM-schema. Om de correcte eenduidigheid te bereiken zul je vaak met de gebruiker/opdrachtgever moeten overleggen over hoe precies in termen van toevoegen/tonen/muteren/verwijderen de informatiewens vertaald moet worden.

Voorbeeld: factureringsafdeling Een onderdeel van de gewenste informatievoorziening, zoals gevonden bij activiteit 1.2, is: - de verzendgegevens kunnen bijwerken op grond van binnengekomen aanvullingen en veranderingen. Deze wens zou op grond van voorgaand informatie-structuurdiagram (dat alleen de belangrijkste objecten en de relaties daartussen bevat) concreet vertaald kunnen worden in iets als: Het informatiesysteem moet de volgende opdrachten kunnen uitvoeren: - Voeg toe Klant (met zijn adres ...) - Toon Klant (inclusief ...) - Muteer Klant (...) Hiermee is de gewenste informatievoorziening een stuk concreter ingevuld en kan een toekomstige gebruiker ook nagaan of alle gewenste voorzieningen wel aanwezig zijn. N.B. uit overleg met de gebruiker bleek dat er geen behoefte bestaat om een 'los' adres van een klant te kunnen verwijderen of toevoegen e.d. (blijkbaar bewaart men liever een oud adres van een klant, dan dat men opgeeft dat een klant 'spoorloos verdwenen' is). Een dergelijke concretisering moet je dus voor alle informatiewensen uitvoeren!

Als voorbeeld van een iets ingewikkelder informatiebehoefte kunnen we de vraag opschrijven: "Waar woont (wat is het Adres van) de Klant die Factuur ... heeft gekregen?" Of in de vertaling van het informatie-structuurdiagram: "Toon Adres van Klant met Factuur ...." N.B. Let erop, dat als je zegt “Toon Adres van Klant ..” je eigenlijk alle ‘onder Adres vallende’ gegevens (straatnaam, huisnr, postcode en plaatsnaam) wilt laten tonen. Hetzelfde geldt voor als je zou zeggen: “Toon Factuur van Klant ..” ; dan wil je zeer waarschijnlijk niet [alleen] het factuurnummer, maar [ook] alle ‘onder Factuur vallende’ gegevens, zoals datum, artikelnr en bedrag. Zoals je ziet kun je bij het specificeren van de informatiebehoefte gemakkelijk ‘door het informatie-structuurdiagram lopen’ wanneer je de rolnamen en co-rolnamen slim kiest. Een hulpmiddel voor het vinden van die namen is het (binnen de context van die bepaalde organisatie) maken van zinnetjes volgens het volgende stramien:




... is Klant Factuur ... ... is Factuur Klant ... Op de plaats van de puntjes kan je, wanneer je dat gemakkelijk vindt, voorbeeld-gegevens invullen zodat het zinnetje wat concreter wordt, bijvoorbeeld: "Groenhuizen is Klant met Factuur 884597" "884597 is Factuur van Klant Groenhuizen" De namen van en met komen relatief vaak als rolnamen voor, maar het zijn niet de enige mogelijkheden; hoofdcriterium is dat de rolnaam en co-rolnaam zinvol zijn in de wereld van de gebruiker van het informatiesysteem.

Vervolg informatie-analyse-deel: bij ‘het systeemconcept’: vervolg

C : de gegevens

(C.2)

Terug naar ons voorbeeld van de factureringsafdeling. Wij geven het informatie-structuurdiagram weer, dat hoort bij het tweede hiërarchische niveau van de verzendgegevens: Straat (straatnaam)

met /van

Huisnr

Adres met /van

Postcode met /van Woonplaats (plaatsnaam) met /van

De rolnamen kun je zoals hiervoor min of meer vrij kiezen, maar het is verstandig deze kort te houden en zodanig te kiezen dat deze in "zinnetjes" die informatiebehoeften omschrijven, gebruikt kunnen worden. De relaties tussen de objecten van het laagste hiërarchische niveau (straat, huis, postcode, woonplaats) worden altijd gelegd via het object adres, dat hiërarchisch hoger staat. We hebben er hier voor gekozen om de object-type (‘bollen’) gestippeld weer te geven. Daarmee willen we aangeven, dat we die beschouwen als ‘value’-typen, die verder géén eigenschappen zullen hebben (dan nu: ‘onderdeel van adres’ zijn). Van ‘straat’ en ‘woonplaats’ kun je je vrij gemakkelijk voorstellen dat je er ooit nog eens andere eigenschappen aan wilt hangen, zoals [handig voor de bezorgers]: of die ‘straat’ misschien een ‘laan’ is en gemakkelijk te herkennen is aan de bomen, of dat je [eveneens handig voor de bezorgers] bij een ‘plaats’ aan wilt geven in welke provincie hij ligt. Op dezelfde wijze kunnen we de relaties van het object-type ‘Factuur’ met de erbij behorende objecttypen aangeven: Artikel (artikelnr)

Bedrag

Datum

van

met

op

/ voor

/ van

/ van


Ook hier hebben we er voor gekozen om de objecttypen ‘Bedrag’ en ‘Datum’ als value-typen [gestippeld] aan te geven.




Evenzo vinden we: Klant (klantnummer)

Klantnaam met / van

Het informatie-structuurdiagram waar alle objecttypen in opgenomen zijn, ziet er als volgt uit: Artikel (artikelnr)

Bedrag

Datum

van

met

op

/ voor

/ van

/ van


is voor /krijgt

Klant (klantnummer)

Klantnaam met / van

heeft / van

Straat (straatnaam)

met / van

Huisnr

Adres met / van

Postcode met / van Woonplaats (plaatsnaam) met / van

Vervolg informatie-analyse-deel:

C.3 : de gegevens : ternaire (en i.h.a. ‘n-aire’) relaties

Tot nu toe hebben we slechts gekeken naar zogenaamde binaire relaties: relaties tussen twéé objecttypen. Aangezien dit de in de praktijk meest voorkomende relaties zijn, hebben we daar vaak voldoende aan. Toch willen we hier ook andersoortige relaties analyseren. Misschien bevreemdde het je, dat in ons factureringsafdelingvoorbeeld een factuur maar voor één artikel bedoeld was. Dat is dan blijkbaar de werkelijkheid van de besproken groothandel ‘Em Masse’, maar dat is beslist niet overal zo. Laten we als voorbeeld eens kijken naar de volgende verkoopbonnen die we bij het doen van aankopen bij een kledingzaak zouden kunnen meekrijgen: Kledingzaak “Modieus”

Verkoopnr: N307421

Kledingzaak “Modieus”

Verkoper: 3

Verkoper: 2

Datum: 20-03-2003

Datum: 20-03-2003

Aantal Artikelnr 2 1 2

A3024 A3072 B1035

Artikelnaam broek broek trui

Stukprijs

Bedrag

34,95 43,50 27,50

69,90 43,50 55,00

Totaalbedrag:

Aantal Artikelnr 1 3 2

168,40


A3024 H3452 B1035

Artikelnaam

Verkoopnr: N307422

Stukprijs

broek 34,95 sokken (paar) 2,15 trui 27,50 Totaalbedrag:

Bedrag 34,95 6,45 55,00 96,40



Blijkbaar gaat het om aankopen van verscheidene artikelsoorten, waarbij ook meerdere stuks van een aangegeven artikel kunnen worden aangekocht. Geldige verwoordingen zijn: Verkoop (verkoopnr) “N307421” gebeurde door / van Verkoper “3”. Verkoop (verkoopnr) “N307421” gebeurde op / van Datum “20-03-2003”. Verkoop (verkoopnr) “N307421” was in totaal voor / totaal van Bedrag “168,40”. Artikel (artikelnr) “A3024” heeft / van Artikelnaam “broek”. Artikel (artikelnr) “A3024” heeft stukprijs / stukprijs van Bedrag “34,95”. Of algemener: Verkoop (verkoopnr) gebeurde door / van Verkoper. Verkoop (verkoopnr) gebeurde op / van Datum. Verkoop (verkoopnr) was in totaal voor / totaal van Bedrag. Artikel (artikelnr) heeft / van Artikelnaam. Artikel (artikelnr) heeft stukprijs / stukprijs van Bedrag. Bovenstaande verwoordingen slaan steeds op binaire relaties. Echter: je kunt niet zeggen: Verkoop (verkoopnr) “N307421” had als Aantal “2”. Immers: bij deze aankoop zijn weliswaar 2 stuks van het artikel met artikelnummer A3024 verkocht, maar óók 2 stuks van artikel B1035 en maar één enkele broek met het artikelnummer A3072. Zo’n verwoording als ‘Verkoop (verkoopnr) had als Aantal ’ is daarom géén bruikbare ‘elementaire feitexpressie’; bij gebruik ervan gaat immers informatie over de geldende relaties binnen dit UoD verloren. Wél correct zijn de volgende (“elementaire”) feitexpressies: Verkoop (verkoopnr) “N307421” van Artikel (artikelnr) “A3024” betrof Aantal “2” stuks. Verkoop (verkoopnr) “N307421” van Artikel (artikelnr) “A3072” betrof Aantal “1” stuks. Verkoop (verkoopnr) “N307421” van Artikel (artikelnr) “B1035” betrof Aantal “2” stuks. Of algemeen: Verkoop (verkoopnr) van Artikel (artikelnr) betrof Aantal stuks. We zien hier een ternaire relatie tussen objecttypen optreden (ternair: drie). We kunnen deze relatie als volgt in een ORM-conceptueel schema opnemen: Artikel (artikelnr)

Verkoop (verkoopnr)

Aantal ...van ... betrof ... stuks

Let erop, dat in zo’n ternaire relatie 3 ‘rollen’ voorkomen, waarbij elke rol met een objecttype-bol is verbonden. De verwoording (elementaire feittype-expressie) kan worden [terug] gegenereerd door op de plaats van de stippeltjes de namen (met eventueel de identificerende gegevensnamen) in te vullen. Analoog aan het voorgaande geldt voor relatie tussen de in de rechterkolom van elke verkoopbon staande bedragen, dat deze te maken hebben met het artikel op die regel van de bon: Verkoop (verkoopnr) “N307421” van Artikel (artikelnr) “A3024” voor Bedrag “69,90”. Of algemeen: Verkoop (verkoopnr) van Artikel (artikelnr) voor Bedrag. Ook hier zien we weer een ternaire relatie tussen objecttypen. Schematisch:




Artikel (artikelnr)

Verkoop (verkoopnr)

Bedrag ... van ... voor ...

Ga voor jezelf na, dat het geheel van bestaande (binaire + ternaire) relaties binnen dit Universe of Discourse als volgt in een ORM-diagram kan worden weergegeven: Aantal ... van ... betrof ... stuks Artikelnaam Artikel (artikelnr)

heeft / van

heeft stukprijs / stukprijs van Bedrag Verkoop (verkoopnr)

... van ... voor ...

was in totaal voor

/ totaal van

Datum gebeurde op / van Verkoper gebeurde door / van

De hiërarchisch belangrijkste objecttypen in dit UoD lijken ‘Artikel’ en ‘Verkoop’ te zijn. Naast binaire en ternaire relaties kunnen ook andersoortige n-aire relaties optreden (zoals quaternaire [met 4 rollen], maar ook unaire [met slechts één rol]). Voor een bespreking hiervan verwijzen we graag naar de in hoofdstuk I bij ‘achtergrond-literatuur’ (1.8) voor informatie-analyse genoemde: ‘Guide to FORML’ en het achterliggende boek over ORM. N.B.

Meestal is een andere-dan-binaire relatie om te zetten in (meerdere) binaire relaties, door het introduceren van ‘tussenobjecten’. Als je in dit voorbeeld van de verkoopbon als tussen-objecttype een ‘Verkoopbonregel’ introduceert (in ons voorbeeld heeft elke verkoopbon 3 ‘verkoopbonregels’), dan kun je voor elke verkoopbonregel via binaire relaties een artikel, een aantal en een bedrag aangeven. Een op te lossen technisch probleem is dan hoe je een verkoopbonregel kunt identificeren. Belangrijker is echter de vraag of er binnen dit Universe of Discourse wordt gedacht in en gepraat over zo’n concept ‘verkoopbonregel’. Als daar zo’n begrip totaal onbekend is, kun je het over het algemeen ook beter niet opnemen in je datamodel. Baseer je liefst op bestaande begrippen en gangbare verwoordingen uit het UoD.

Samenvattend over gegevens/informatieanalyse + concretisering De gegevens die in het te bouwen informatiesysteem een rol zullen spelen, worden geïnventariseerd. De gegevens verwijzen naar objecten (personen, begrippen , dingen) in de werkelijkheid; deze objecten worden geïdentificeerd. De objecten staan vaak in een hiërarchische relatie tot elkaar, bijvoorbeeld zit het object adres hoger in de hiërarchie dan straat, huis, postcode, woonplaats. Op zijn beurt zit klant weer hoger in de hiërarchie dan adres. Het is vaak niet gemakkelijk om vast te stellen hoe zo'n hiërarchie precies in elkaar zit. De tussen de objecten bestaande relaties geven we weer in een informatie-structuurdiagram. Resultaten van activiteit 1.5 sub C + D (de gegevens + concretisering informatiewensen) zijn: - verwoordingen van de relaties tussen de verschillende objecttypen binnen dit ‘Universe of Discourse’; probeer de hiërarchie binnen de aangetroffen objecttypen duidelijk te krijgen; - een informatie-structuurdiagram waarin de objecten en hun onderlinge relaties zijn opgenomen; hiërarchie wordt bij voorkeur in het diagram ook zichtbaar gemaakt (dikkere lijnen, arcering, e.d.); - een concretisering van de in activiteit 1.2 bepaalde informatievoorziening op het bovenste niveau van de objectenhiërarchie; dit betekent dat nà activiteit 1.5 nogmaals teruggekeerd wordt naar activiteit 1.2.




Bijlage DS - b) Factureringsafdeling: rapport Definitiestudie (UITTREKSEL) Uitgangspunten Plan van aanpak Gewenste informatievoorziening: Deze omvat puur de automatisering van de bestaande situatie. Gewenst wordt derhalve: • aan kunnen brengen van binnengekomen factuurgegevens op een factuur met een uniek volgnummer, een kopiefactuur kunnen archiveren, • bestaande factuurgegevens kunnen corrigeren indien blijkt dat eerder foutieve gegevens zijn ingevoerd; • de factuur kunnen voorzien van verzendgegevens (zodat deze daarna in een vensterenvelop verzonden kan worden), • de verzendgegevens kunnen bijwerken op grond van binnengekomen aanvullingen en veranderingen. Veranderingsbehoefte en systeemeisen: - Veranderingsbehoefte: geen (in de werkwijze mag niets veranderen). - Als systeemeisen gelden: • het informatiesysteem moet een functie bevatten die een factuur vervaardigt en de gegevens van een factuur archiveert. • het informatiesysteem moet een functie bevatten die facturen van een verzendadres voorziet (die daarna nog in een gefrankeerde envelop moeten) en die de mogelijkheid biedt om de verzendgegevens bij te werken.

Systeemconcept - hoofdfuncties:

factureringsopdracht

factureringsgegevens

factureren

veranderopdracht

kopiefactuur

blanco kopie/opdracht-form. gegevensbank

te corrigeren fact.gegevens factuurgegevens verzendopdracht

verzenden

factuurgegevens

verzendgegevens

nieuwe of gewijzigde verzendgegevens blanko formulieren

nieuwe of gewijzigde


factuur met verzendgegevens



Systeemconcept - interacties: besturingsinteracties met de buitenwereld: Door via het toetsenbord besturingscommando's in te tikken kunnen gebruikers van het informatiesysteem de twee hoofdfuncties "in werking stellen": - intikken van het besturingscommando factureren leidt tot het in werking stellen van de hoofdfunctie factureren. De beoogde werking van factureren leidt er toe dat factureringsgegevens via het toetsenbord kunnen worden ingetikt, daarna produceert de hoofdfunctie een kopiefactuur en slaat de factuurgegevens op in de gegevensbank; tenslotte wordt een papieren seintje gegeven dat een bepaalde factuur verzonden kan worden. - intikken van het besturingscommando verzenden leidt tot het in werking stellen van de hoofdfunctie verzenden. De beoogde werking van verzenden leidt er toe dat via het toetsenbord kan worden aangegeven welke factuur met welke verzendgegevens uit de gegevensbank moet worden afgedrukt. - intikken van het besturingscommando veranderen leidt eveneens tot het in werking stellen van de hoofdfunctie verzenden. De beoogde werking van verzenden maakt het mogelijk gewijzigde of nieuwe verzendgegevens via het toetsenbord in te tikken waarna de gegevens in de gegevensbank worden aangepast. grondstofinteracties met de buitenwereld: - factureringsgegevens komen binnen via het toetsenbord; deze worden ingelezen als onderdeel van de uitvoering van de hoofdfunctie factureren. - verzendgegevens komen binnen via het toetsenbord; deze worden ingelezen als onderdeel van de uitvoering van de hoofdfunctie verzenden (besturingsopdracht veranderen ). - blanco kopiefacturen en verzendopdrachten productinteracties met de buitenwereld: - de hoofdfunctie factureren levert bij uitvoering een kopiefactuur op papier. - de hoofdfunctie verzenden levert bij uitvoering een factuur met verzendgegevens gedrukt op papier. grondstofinteracties met de gegevensbank: - de hoofdfunctie verzenden vraagt factuurgegevens en verzendgegevens op uit de gegevensbank. - de hoofdfunctie factureren vraagt eventueel te corrigeren factuurgegevens op uit de gegevensbank. productinteracties met de gegevensbank: - de hoofdfunctie factureren schrijft factuurgegevens ter bewaring naar de gegevensbank. - de hoofdfunctie verzenden schrijft nieuwe of gewijzigde verzendgegevens ter bewaring naar de gegevensbank. interacties tussen processen onderling: - de hoofdfunctie factureren levert bij uitvoering een verzendopdracht op papier, die naar de hoofdfunctie verzenden gaat.

Systeemconcept - gegevens: Op grond van een bestudering van het factuur-formulier is gebleken dat de objecttypen klant en factuur centrale begrippen zijn in de factureringsafdeling. Op een lager niveau komt ‘adres’ te staan. We geven hier de volgens ORM-leest geformuleerde verwoordingen van de relaties tussen de verschillende binnen de factureringsafdeling onderkende objecttypen en zoals ze besproken zijn met het afdelingshoofd: Klant (klantnummer) krijgt / is voor Factuur (factuurnummer). Klant (klantnummer) heeft / van Adres. Klant (klantnummer) heeft / van Klantnaam. Factuur (factuurnummer) op / van Datum. Factuur (factuurnummer) voor / van Artikel (artikelnr). Factuur (factuurnummer) met / van Bedrag. Adres met / van Straat (straatnaam). Adres met / van Huisnr. Adres met / van Postcode. Adres met / van Woonplaats (plaatsnaam).




Aan de hand van deze verwoordingen hebben we het volgende informatie-structuurdiagram opgesteld: Artikel (artikelnr)

Bedrag

Datum

van

met

op

/ voor

/ van

/ van


is voor /krijgt

Klant (klantnummer)

Klantnaam met / van

heeft / van met / van

Straat (straatnaam)

Huisnr

Adres met / van

Postcode met / van Woonplaats (plaatsnaam) met / van

Op grond van de informatieanalyse kan nu de gewenste informatievoorziening concreet vertaald worden in: - aan kunnen brengen van binnengekomen factuurgegevens op een factuur met een uniek volgnummer, een kopiefactuur kunnen archiveren . Voeg toe factuur van klant . Toon facturen van klant - bestaande factuurgegevens kunnen corrigeren indien blijkt dat eerder foutieve gegevens zijn ingevoerd . Verwijder factuur van klant . Muteer factuur van klant - de factuur kunnen voorzien van verzendgegevens (zodat deze in een vensterenvelop verzonden kan worden) . Druk af factuur van klant en: adres van klant - de verzendgegevens kunnen bijwerken op grond van binnengekomen aanvullingen en veranderingen: . Voeg toe klant (met zijn adres...) . Toon klant . Muteer klant N.B. ' . Verwijder klant' blijkt niet nodig te zijn! N.B.

Adreswijzigingen kunnen worden doorgevoerd via de '. Muteer klant' -mogelijkheid, die toe kan grijpen op de (hiërarchisch) 'onder' klant vallende objectgegevens.

(Alleen voor in de projectfase: zie de ontwikkelkostenraming volgens de FPA-methode in bijlage DS - g.)

Einde UITTREKSEL Rapport Definitiestudie factureringsafdeling N.B.

Hier dient nog een evaluatie van het verloop van de definitiestudie-activiteiten worden gegeven (waarbij o.a. de vergelijking tussen geplande en werkelijke taakverdeling/tijdsbesteding zit).


Bijlagen A bij hoofdstuk III over Definitiestudie:

Recommend Documents