Systeemanalyse en Databanken
Meda Mikoliunaite 2/1/2026
Inleiding
DE ANALIST ALS BUSINESS PROBLEM SOLVER
• Een analist : meer een bedrijfskundig probleemoplosser dan een programmeur.
o Begrijpt bedrijfskundige problemen en processen.
o Zoekt oplossingen via informatiesystemen.
o Begeleidt en leidt de implementatie van deze oplossingen in de organisatie.
ANALIST ALS SYSTEEMONTWIKKELAAR
Analyse : Proces van begrijpen en gedetailleerd specificeren wat het informatiesysteem moet doen.
• Kritische succesfactor voor een succesvolle IS-ontwikkeling.
• Vereist kennis, technieken én ervaring.
Ontwerp : Proces gedetailleerd uitwerken hoe de componenten van het IS technisch worden
geïmplementeerd (analist begeleidt het ontwerp of werkt er zelf actief aan mee).
Implementatie : Begeleidt de invoering van het systeem, soms ook zelf betrokken bij de uitvoering.
→Kan gebeuren via zowel een gestructureerde aanpak als een objectgeoriënteerde (OO) aanpak.
Systeemanalist = een business professional die analyse- en ontwerptechnieken gebruikt om
bedrijfskundige problemen op te lossen met behulp van informatietechnologie (IT)
CONCLUSIES
• Analyse = bedrijfsproblemen oplossen met behulp van informatiesystemen.
• De analist voert de analyse uit en begeleidt eventueel ook ontwerp en implementatie.
• Vereist een combinatie van bedrijfskundige én technische vaardigheden.
Hoofdstuk 3: Vereisten verzamelen
LEERDOELEN
• De activiteiten in de analysefase kunnen uitleggen
• BPR kunnen uitleggen
• Uitleggen hoe stakeholders moeten geidentificeerd worden
• Technieken voor informatieverzameling kunnen uitleggen
• Validatie en verificatie van vereisten kunnen uitleggen
DE ANALYSEFASE IN DE LEVENSCYCLUS
Activiteit 1: Informatieverzameling
Doel: expert worden in het domein.
Belang van bedrijfseconomische kennis:
,Meda Mikoliunaite 2/1/2026
• Om de echte noden te kunnen bepalen.
• Om geloofwaardigheid op te bouwen (die is in het begin bijna nul).
• Om een nieuw perspectief aan te brengen.
Belangrijk : Gebruikers zitten vaak vast in verouderde processen en kennen hun eigen vereisten niet
altijd goed.
Analyse is dus een leerproces voor beide partijen: zowel voor de analist als voor de gebruikers.
Activiteit 2: Modelleren : Het gestructureerd weergeven van processen, gegevens en vereisten.
Zie hoofdstuk 4 e.v.
Activiteit 1: Informatieverzameling
STAKEHOLDERS (BELANGHEBBENDEN)
=personen of groepen die belang hebben bij het systeem of erdoor beïnvloed worden.
Stap 1: Identificeren
• Bepalen wie de belanghebbenden zijn.
• Als je hier fouten maakt, kan het project al mislukken i/h begin.
• In tijden van AI kan ook jobbehoud een gevoelig punt zijn→ weerstand mogelijk.
Deze fase is vaak nog vaag, omdat veel methodologieën zijn ontwikkeld door mensen met een sterk
technische achtergrond, die meer focussen op implementatie dan op vroege analyse.
Stap 2: Medewerking garanderen
• Stakeholders moeten meewerken en informatie geven.
• Zonder medewerking geen correcte analyse.
• Vertrouwen opbouwen is cruciaal.
Categorieën van stakeholders (checklist):
1. Gebruikers
• Eindgebruikers → “Creëer een order”
• Zij werken dagelijks met het systeem.
• Weten vaak niet exact wat ze willen→ analyse is ook voor hen een leerproces.
2. Management : Focus op rapportering: “Hoeveel orders deze week?”
3. Executive management : Strategische vragen: “Wat is ons marktaandeel?”
4. Externe partners : Leveranciers→ “Hoeveel bedraagt de voorraad?”
5. Opdrachtgever (klant) : Vaak degene die het project initieert.
6. Stakeholders die het budget beheren : Bepalen hoeveel middelen beschikbaar zijn.
• Hun belang kan botsen met dat van eindgebruikers.
• Wat gebruikers willen is soms te duur, en onderhoudskosten zijn vaak een v/d grootste
kostenposten.
7. Technici / ontwikkelaars
,Meda Mikoliunaite 2/1/2026
• Willen bouwen wat de gebruiker vraagt.
• Maar willen ook hergebruik van software maximaliseren.
• Kleine verschillen in vereisten tss bedrijven kunnen leiden tot 2x werk en minder
herbruikbaarheid.
Belangrijk:
• Gebruikers willen functionaliteit
• Budgethouders willen kosten beperken
• Technici willen efficiëntie en herbruikbaarheid
• Analist moet hier bruggenbouwer zijn
STAKEHOLDERS IDENTIFICEREN
Centraal : het informatiesysteem dat je gaat bouwen.
1.Hoeveel stakeholders betrek je?
• Kies je enkel de 3 belangrijkste?
• Of betrek je er 8 of meer, omdat het systeem complex is?
Meer stakeholders = meer input
Maar ook meer tijd, kosten en mogelijk conflicten
Dus: Het aantal betrokken stakeholders beïnvloedt het eindresultaat.
2.Volgorde van ondervraging : De volgorde maakt ook uit!
Onderhandelingstechniek:
• Begin met stakeholders die jou steunen.
• Zo verzamel je sterke vereisten en bouw je momentum op.
• Stakeholders die weinig kennis of weinig concrete eisen hebben, kan je later betrekken.
→Dit bespaart tijd en kosten voor de analist.
Integratieaspect : Een informatiesysteem is zelden voor één afdeling.
• Het moet vaak geïntegreerd worden met:
o Marketing
o Finance
o Accountancy
o Logistiek en etc..
• Dus: wie bewaakt de organisatiebrede integratie?
o De CEO heeft overzicht, maar houdt zich meestal niet bezig met operationele details.
o Vaak is er geen natuurlijke eigenaar.
o Tegenwoordig wordt dit vaak opgenomen door een Enterprise Analyst (meer vanuit IT),
die over departementen heen denkt.
• Stakeholderanalyse gaat niet alleen over wie belangrijk is,
maar ook over:
o hoeveel mensen je betrekt
o in welke volgorde
o en wie de integratie over de hele organisatie bewaakt
TECHNIEKEN VOOR INFORMATIEVERZAMELING
, Meda Mikoliunaite 2/1/2026
Doel: Een set vereisten opstellen die correct, volledig, consistent en ondubbelzinnig is
Verplichte eigenschappen van vereisten:
• Volledig : Alles wat het systeem moet kunnen moet op de lijst staan
o Een onvolledige lijst zorgt later voor extra kosten
o De opdrachtgever zal anders vragen waarom het project duurder wordt dan voorzien
• Consistent : Geen tegenstrijdigheden tussen vereisten
o De analist moet verschillen tussen stakeholders zelf uitfilteren
o Conflicten mogen niet doorgeschoven worden naar de programmeur
• Ondubbelzinnig : Elke vereiste moet duidelijk en eenduidig geformuleerd zijn
o Geen ruimte voor interpretatie
Optionele eigenschappen:
• Geprioriteerd : Vereisten worden gerangschikt volgens belangrijkheid
o Minder belangrijke vereisten kunnen bij tijdsdruk geschrapt worden
• Haalbaar : Moeilijke of risicovolle vereisten eerst analyseren
o Als iets niet haalbaar is, kan het project vroeg worden stopgezet
o Dit voorkomt grote tijd- en geldverliezen
• Aanpasbaar : Vereisten moeten eenvoudig gewijzigd kunnen worden
o Het document moet onderhoudbaar blijven
• Traceerbaar : Het moet duidelijk zijn van welke stakeholder een vereiste komt
o Je moet kunnen volgen waar en hoe een vereiste wordt geïmplementeerd
o Gebruik van duidelijke referenties of koppelingen helpt hierbij
SOORTEN VEREISTEN
• Functionele vereisten : Beschrijven wat het systeem moet doen (concrete functies en acties)
o Bv : order aanmaken, rapport genereren
• Niet-functionele vereisten : Beschrijven hoe het systeem moet werken (kwaliteitskenmerken
• Belangrijke types van NF-vereisten:
o Technische vereisten:
▪ Hardware, software, platform, infrastructuur
o Performantie: resultaat binnen bepaalde tijd opleveren
▪ Bijvoorbeeld responstijd of verwerkingssnelheid
o Gebruiksvriendelijkheid:
▪ Eenvoudig en intuïtief in gebruik
▪ Logische navigatie en duidelijke interface
o Betrouwbaarheid:
▪ Systeem werkt correct onder verschillende omstandigheden
▪ Weinig fouten of crashes
▪ Vaak duur om hoog niveau van betrouwbaarheid te garanderen
Functioneel = wat het systeem doet
Niet-functioneel = hoe goed het systeem het doet
TECHNIEKEN VOOR INFORMATIEVERZAMELING:
Interviews:
• Doel v/d interviews:
o Begrijpen wat gebruikers nodig hebben