Requirements Engineering/het werk/werkstuk/2013-14/Groep 03
Requirements Tandartspraktijk De Wortel (Case groep 4)
Werkstuk Requirements Engineering
Ivar Derksen, Tom Nies, Abdullah Rasool, Bjorn Goedhard, Roel van der Burg
Onderwijsinstituut voor Informatica en Informatiekunde
Radboud Universiteit Nijmegen
version 18 februari 2022
Inhoud
Introduction
Het volgende document beschrijft de resultaten omtrent het process Requirements Engineering met betrekking tot de client case: automatisering planning en gegevens, tandartspraktijk ‘De wortel’. In deze sectie wordt de client case bondig omschreven. Daarnaast leveren we een overzicht van de structuur van het document.
Het team constateert dat er bij de client verschillende discrepanties zijn met betrekking tot de automatisering van zowel processen als databehandeling. Na overleg met de client omtrent de mogelijkheden en kosten van eventuele oplossing is besloten slechts een deel van discrepanties te verhelpen. In dit document construeren we de Requirements en oplossing met betrekking tot de volgende discrepanties: Het digitaal invoeren of wijzigen van gegevens door klanten of personeel, het plannen van afspraken door klanten of personeel.
Allereerst behandelen we het problem statement van de client. Centraal in deze sectie staat een verklaring met betrekking tot de benoemde discrepanties. Daarop volgend leveren we een korte beschrijving en analyse van de relevante stakeholders. De sectie ‘ Mission Vision and Values’ zal een relatie leggen tussen de te verhelpen discrepanties, het uiteindelijke product en de motivaties voor het uiteindelijke product als oplossing voor het aangewezen probleem. Vervolgens beschrijven we een log van de relevante taakvervulling en ontwikkeling binnen het project. In de sectie ‘Risk Analysis’ beschrijven we de door ons voorziene risico’s met betrekking tot de constructie en implementatie van het systeem. De daaropvolgende sectie beschrijven de belangrijkste karakteristieken van ‘Use Cases’ en de cases zelf. Dit onderdeel van het document biedt een duidelijk inzicht in de randvoorwaarden van- en de gewenste interactie tussen de gebruiker en het systeem. De sectie ‘Scenarios’ biedt vervolgens een concrete beschrijving van de cases op het instance level. Voor een overzicht op het betreffende domein gebruiken we een ORM constructie en relateren deze aan de data karakteristieken van de case. Afsluitend bespreken we de van toepassing zijnde ‘Business Rules’ en ‘Non-functional Requirements‘.
Problem statement
Om de competitiviteit en de rendabelheid van de cliënt te kunnen garanderen dient zekere mate van efficiëntie gewaarborgd te worden. Het is de visie van zowel de klant als auteurs dat het huidige systeem te veel discrepanties vertoont met betrekking tot de optimale mogelijkheden. Het grootste probleem vormt de omgang met planning en persoonsgegevens. Het doel van dit project is dan ook een zo verregaand mogelijke automatisering van bedrijfsprocessen met betrekking tot planning en persoonsgegevens.
Het doel van dit project is dan ook het implementeren van IT applicaties die de efficiëntie van het bedrijf verhogen en de rendabelheid van de cliënt te waarborgen. De administratie van persoonsgegevens dient als robuuste digitale database vorm te krijgen. Dit zal de kwetsbaarheid van de gegevens verlagen, tevens maakt dit invoer en mutaties van data efficiënter te verwerken. Via een internet applicatie dient de klant toegang te krijgen tot diens plan en persoonsgegevens. Eventuele invoer of mutatie kan hierdoor ook sneller volbracht worden.
Stakeholder Anaylsis
| Rol | Belanghebbende(n) | Omschrijving |
|---|---|---|
| Eigenaar Tandartspraktijk | Willie Wortel | Tandarts en eigenaar van de tandartspraktijk. Wortel wil zijn vaste kosten verlagen door het werk van de receptionisten te automatiseren middels ons systeem. |
| Receptionist | Twee receptionisten in loondienst voor de praktijk | Hebben geen belang in het slagen van het systeem. Door automatisering staat hun baan in het geding. |
| Overige medewerkers | Bestaande uit tandartsen, assistenten en mondhygiënisten | Algehele kostenbesparing door de automatisering kan voor hen positief uitpakken. |
Mission Vision Values
De missie van auteurs en cliënt betreft het verhelpen van discrepanties zoals beschreven in de sectie problem statement. Elk van de genoemde discrepanties heeft een negatieve relatie tot de efficiëntie van de cliënt. De auteurs bezitten de vereiste knowhow en ervaring om de geconstateerde discrepanties binnen een redelijke te verhelpen. Het is de overtuiging van de auteurs dat de totale kosten van het project op termijn opwegen tegen het efficiëntie verlies dat wordt verholpen.
Het uiteindelijke product van het project kan opgesomd worden in de volgende functionaliteiten, mogelijk gemaakt door de gebouwde en geïmplementeerde systemen. Het eindproduct omvat:
- een database
- een kalender
- Gegevens tool/applicatie
Met deze producten dient de cliënt na afronden van het project over de volgende functionaliteiten te beschikken:
- Een personeelslid kan met de applicatie een nieuwe klant aanmaken in de database.
- Een personeelslid kan met de interne applicatie de gegeven van een nieuwe klant verifiëren om een account voor de applicatie aan te maken.
- Een geverifieerde klant kan een account aan maken voor de applicatie.
- De klant kan planninggegevens in de agenda wijzigen met behulp van de applicatie.
- De klant kan persoonsgegevens in de database wijzigen met behulp van de applicatie.
- Een personeelslid kan planninggegevens in de agenda wijzigen met behulp van de applicatie.
- Een personeelslid kan persoonsgegevens in de database wijzigen met behulp van de applicatie.
- Een personeelslid kan persoonsgegevens in de database wijzigen met behulp van de applicatie.
Auteurs en overige medewerkers verklaren in dit document zich primair te richtten op de belangen van de klant. Het project dat in dit document wordt beschreven dient te resulteren in een product dat bovengenoemde discrepanties op een optimale manier verhelpt. Het waarborgen van de cliënt als een efficiënte solide en betrouwbare onderneming is het uiteindelijke hoofddoel van dit project. In de projectomvang is rekening gehouden met de meest rendabele investering voor de cliënt, en de huidige scope van het project is hier dan ook op aangepast.
Statement of Work
Scope
Het systeem betreft een administratiesysteem waarmee tandartspraktijk De Wortel hun klantenadministratie en planning administratie bij kan houden.
Objectives
Het doel van het systeem is het digitaliseren van de klantenadministratie, de planning administratie en het verminderen van kosten die hiervoor door de tandartspraktijk gemaakt worden.
Door het digitaliseren van de klantenadministratie hoeven receptionisten geen administratie meer op papier bij te houden en bij te werken. Daarnaast hoeven de receptionisten niet meer de telefoon op te nemen als een klant een afspraak wil maken. Doordat de receptionisten minder werk hoeven te doen zal het uiteindelijk mogelijk zijn receptionisten te ontslaan en hierdoor de kosten voor de tandartspraktijk verder te verminderen.
Application overview
Het systeem maakt het voor een nieuwe klant mogelijk om een account aan te maken en hier zijn gegevens in te voeren. De klantgegevens worden daarna geverifieerd door een receptionist.
Daarnaast moet het voor een bestaande klant mogelijk zijn om een nieuwe afspraak in te plannen. De afspraak wordt daarna geverifieerd door een receptionist. Het moet voor de klant mogelijk zijn om zijn eigen gegevens te bewerken of om zijn eigen afspraak te bewerken. Dit moet ook door een receptionist gedaan kunnen worden.
User demography
Het bedrijf bestaat uit twaalf medewerkers. Twee daarvan zijn receptionistes, vier tandartsen, acht assistenten en twee mondhygiënisten. Twee van de assistenten werken af en toe ook als receptionistes.
Constraints
Een van de beperkingen van het systeem is dat het niet mogelijk is om het systeem de klantgegevens te laten controleren. Het controleren van de klantgegevens zal door een receptionist moeten gebeuren. Hierdoor zal een nieuwe klant, na het online aanmelden en invullen van de klantgegevens, zijn gegevens moeten laten verifiëren door een receptionist.
Assumptions
Er wordt aangenomen dat tandartspraktijk De Wortel beschikt over een werkende internetverbinding om verbinding te kunnen maken met het systeem. Daarnaast wordt aangenomen dat tandartspraktijk De Wortel beschikt over voldoende computers voor de medewerkers om gebruik te kunnen maken van het systeem.
Expected duraton
Deadlines:
14-03-14: Filled Iteration deliverable
04-04-14: Case Project deliverable
Use Case Survey
Use case 1:
|
Use case name: |
Nieuwe klant aanmaken |
|
Initiating Actor: |
De klant |
|
Description: |
Het invoeren van een nieuwe klantgegevens en het aanmaken van een account voor deze klant. |
|
Completeness: |
Full |
|
Source: |
Deze use case is gebaseerd op de wensen van de klant (Tandartspraktijk De Wortel). Er werd aangegeven dat er een efficiëntere manier gevonden moest worden voor het registeren van klanten en dat realiseert deze use case. |
|
Comments: |
Na het doorlopen van deze use case zullen de desbetreffende klantgegevens in het systeem worden opgenomen en dus zal de account worden aangemaakt. De klant wenst echter ook een controle op deze gegevens, dus voordat de account geactiveerd wordt en dus bruikbaar, moet eerst use case 2 door een medewerker doorlopen worden voor deze klant om de account te verifiëren. |
Use case 2:
|
Use case name: |
Nieuwe klant verifiëren |
|
Initiating Actor: |
Het personeel |
|
Description: |
De ingevoerde gegevens van de klant worden geverifieerd door het personeel. |
|
Completeness: |
Full |
|
Source: |
Deze use case is ook gebaseerd op een wens van de klant (Tandartspraktijk De Wortel). Zij eisen dat accountgegevens uit use case 1 gecontroleerd worden door een medewerker alvorens de account gebruikt kan worden. |
|
Comments: |
Na het voltooien van deze use case is de desbetreffende account geactiveerd en zal de bijbehorende klant een activatiemail krijgen met een initieel wachtwoord. |
Use case 3:
|
Use case name: |
Gebruiker meldt zich aan |
|
Initiating Actor: |
Een gebruiker (klant of personeel) |
|
Description: |
Een gebruiker meldt zich aan voor de online tool. |
|
Completeness: |
Full |
|
Source: |
Om het systeem te laten voldoen aan alle non-functional requirements is deze use case noodzakelijk. |
|
Comments: |
Een gebruiker kan alleen met de juiste inloggegevens in het systeem komen. Hierbij kan een klant alleen zijn eigen gegevens inzien en een medewerker alle gegevens. Deze use case is alleen te gebruiken voor mensen die al geldige inloggegevens hebben. Een personeelslid moet dus in het systeem staan en een klant moet use case 1 en 2 doorlopen hebben. |
Use case 4:
|
Use case name: |
Klantgegevens muteren |
|
Initiating Actor: |
Een gebruiker (klant of personeel) |
|
Description: |
De gebruiker kan klantgegevens muteren. |
|
Completeness: |
Full |
|
Source: |
Tandartspraktijk De Wortel wenst een digitaal patiëntendossier voor klantgegevens, dus naar eigen inzicht lijkt het ons ook logisch dat die gegevens aanpasbaar moeten zijn in verband met gegevenswijzigingen. |
|
Comments: |
Een klant mag alleen zijn eigen gegevens aanpassen en het personeel mag alle gegevens wijzigen. Hiervoor is authenticatie nodig en daarom moet use case 3 al doorlopen zijn voordat deze use case gebruikt kan worden. |
Use case 5:
|
Use case name: |
Klant muteert planninggegevens |
|
Initiating Actor: |
De klant |
|
Description: |
Het is voor de klant mogelijk om zijn/haar eigen agenda gegevens te zien en zo nodig te muteren. |
|
Completeness: |
Full |
|
Source: |
Tandartspraktijk De Wortel wenst dat er een gemakkelijk systeem moet komen voor klanten om zelf afspraken in te plannen. Dit bleek uit de casusbeschrijving en het eerste overleg. |
|
Comments: |
Een klant mag alleen zijn eigen planninggegevens muteren en mag alleen afspraken toevoegen op tijden waarop de desbetreffende tandarts/mondhygiënist en de desbetreffende klant niet al een andere afspraak hebben. Voor deze use case is authenticatie nodig en daarom moet use case 3 al doorlopen zijn voordat deze use case gebruikt kan worden. |
Use case 6:
|
Use case name: |
Personeel muteert planninggegevens en behandelgegevens |
|
Initiating Actor: |
Het personeel |
|
Description: |
Het personeel kan de agenda- en behandelgegevens inzien en muteren van de desbetreffende klant. |
|
Completeness: |
Full |
|
Source: |
Tandartspraktijk De Wortel wenst dat er een gemakkelijk systeem waarin ook medewerkers gemakkelijk planningen kunnen bijwerken en behandelgegevens kunnen bijhouden. Dit bleek uit de casusbeschrijving en het eerste overleg. |
|
Comments: |
Een medewerker mag alleen afspraken toevoegen op tijden waarop de desbetreffende tandarts/mondhygiënist en de desbetreffende klant niet al een andere afspraak hebben. Voor deze use case is authenticatie nodig en daarom moet use case 3 al doorlopen zijn voordat deze use case gebruikt kan worden. |
Overzicht use cases
|
# |
Name |
Description |
Initiating actor |
|
01 |
Nieuwe klant aanmaken. |
Het invoeren van nieuwe klantgegevens en het aanmaken van een account voor deze klant. |
De klant |
|
02 |
Nieuwe klant verifiëren. |
De ingevoerde gegevens van de klant worden geverifieerd door het personeel. |
De klant |
|
03 |
Gebruiker meldt zich aan |
De klant meldt zich aan voor de online tool. |
De klant |
|
04 |
Klantgegevens muteren |
De gebruiker kan klantgegevens muteren. |
De klant |
|
05 |
Klant muteert planning gegevens |
Het is voor de klant mogelijk om zijn/haar eigen agenda gegevens te zien en zo nodig te muteren. |
De klant |
|
06 |
Personeel muteert planningsgegevens en behandelgegevens. |
Het personeel kan na de agendagegevens inzien en muteren van de desbetreffende klant. |
De klant |
Integrated use case diagram
Individual Use Cases
|
Use Case: |
01 – Nieuwe klant aanmaken |
|
Description |
Het invoeren van een nieuwe klantgegevens en het aanmaken van een account voor deze klant. |
|
Iteration |
Focused |
|
Triggers |
De klant geeft aan een account aan te willen maken. |
|
Actors |
De klant |
|
Basic Course of Events |
1. Het systeem laat een formulier zien; 2. De klant vult het formulier in; 3. Het systeem vertelt dat de gegevens succesvol zijn opgeslagen en verzoekt de klant om een keer langs te komen op de praktijk om de ingevulde gegevens te verifiëren. |
|
Alternative Paths |
Alternative Path 1: Bij stap 2 zijn de ingevulde gegevens onjuist 2.1 Het systeem geeft aan dat er gegevens onjuist zijn ingevuld en laat zien welke gegevens onjuist zijn; 2.2 De klant vult vervolgens de onjuiste gegevens opnieuw in; De resterende stappen worden vervolgens vervolgd vanaf stap 3. |
|
Exception Paths |
Exception Path 1: Het database systeem is niet bereikbaar 1. Het systeem zal aangeven dat er problemen zijn en verzoekt de klant om het later opnieuw te proberen. |
|
Preconditions |
De klant heeft internetverbinding tot zijn/haar beschikking |
|
Postconditions |
De gegevens van de klant zijn opgenomen in het systeem. |
|
Related Business Rules |
01-NKA-Aut Voor fraude preventie dienen identiteit- en verzekeringsgegevens door een personeelslid worden geverifieerd, dit op basis van geldige documenten. 02-NKA-Pri De klant mag alleen zijn/haar directe gegevens inzien en niet die van andere klanten. |
|
Use Case: |
02 – Nieuwe klant verifiëren |
|
Description |
De ingevoerde gegevens van de klant worden geverifieerd door het personeel. |
|
Iteration |
Focused |
|
Triggers |
De klant die langskomt bij de praktijk. |
|
Actors |
Het personeel |
|
Basic Course of Events |
1. Het personeel meldt zich aan op het systeem (Use Case 03 – AP2); 2. Het systeem toont een deel van de klanten; 3. Het personeel zoekt de klant op in het systeem; 4. Het systeem toont de gegevens van de klant; 5. Het personeel bestempeld de gegevens als geverifieerd in het systeem; 6. Het systeem stuurt een wachtwoord naar het emailadres van de klant. |
|
Alternative Paths |
Alternative Path 1: Bij stap 3 blijkt de klant niet in het systeem voor te komen. 3.1 Het personeel geeft aan een nieuwe klant te willen toevoegen; 3.2 Het systeem toont het formulier; 3.3 Het personeel vult het in (aan de hand van de gegevens van de klant); 3.4 Het systeem vertelt dat de gegevens succesvol zijn opgeslagen; 3.5 Het personeel verifieert de gegevens van de klant; 3.6 Het systeem stuurt een wachtwoord naar het emailadres van de klant. Alternative Path 2: Bij stap 4 blijkt dat de gegevens van de klant (uit het formulier) niet overeenkomen met die uit de documenten. 4.1 Het personeel gaat de gegevens van de klant muteren, dat is Use Case 03 – Klantgegevens muteren |
|
Exception Paths |
Exception Path 1: Het database systeem is niet bereikbaar 1. Het systeem zal aangeven dat er problemen zijn en verzoekt om het later te proberen. |
|
Preconditions |
We gaan er van uit dat de noodzakelijke documenten geldig zijn ( geldigheidsdatum niet is verstreken ) en dat de klant ze heeft meegenomen naar de praktijk.
|
|
Postconditions |
De gegevens van de klant zijn geverifieerd in het systeem en de klant beschikt over een wachtwoord om vervolgens mee in te kunnen loggen in het systeem. |
|
Related Business Rules |
01-NKA-Aut Voor fraude preventie dienen identiteit- en verzekeringsgegevens door een personeelslid worden geverifieerd, dit op basis van geldige documenten. |
|
Use Case: |
03 – Gebruiker meldt zich aan |
|
Description |
De gebruiker meldt zich aan voor de online tool. |
|
Iteration |
Focused |
|
Triggers |
De gebruiker die probeert om zich aan te melden voor het systeem |
|
Actors |
De klant of het personeel |
|
Basic Course of Events |
1. Het systeem toont een aanmeldscherm; 2. De klant vult zijn aanmeldgegevens in; 3. Het systeem geeft de klant toegang tot het systeem en toont informatie over de klant. |
|
Alternative Paths |
Alternative Path 1: Bij stap 2 blijkt de klant zijn/haar inloggegevens is verloren 2.1 De gebruiker geeft aan zijn/haar klantgegevens te zijn verloren; 2.2 Het systeem controleert of het bekend is met deze gebruiker en stuurt vervolgens een nieuw wachtwoord naar de gebruiker’s emailadres. De resterende stappen vanaf stap 3 worden gevolgd. Alternative Path 2: Bij stap 1 wilt het personeel inloggen op het systeem. 1.1 Het systeem toont een aanmeldscherm; 1.2 Het personeel vult zijn aanmeldgegevens in; 1.3 Het systeem geeft het personeel toegang tot het systeem en toont een deel van het klantenoverzicht.
|
|
Exception Paths |
Exception Path 1: Het database systeem is niet bereikbaar 1. Het systeem zal aangeven dat er problemen zijn en verzoekt om het later te proberen. |
|
Preconditions |
De klant heeft een account voor het online systeem en die is ook geverifieerd, Use Case 01 en 02 zijn succesvol doorlopen of het personeelslid heeft geldige aanmeldgegevens.
|
|
Postconditions |
De klant is ingelogd in het systeem. |
|
Related Business Rules |
02-NKA-Pri De klant mag alleen zijn/haar directe gegevens inzien en niet die van andere klanten.
|
|
Use Case: |
04 – Klantgegevens muteren |
|
Description |
De gebruiker kan klantgegevens muteren. |
|
Iteration |
Focused |
|
Triggers |
De gebruiker wilt zijn klantgegevens muteren. |
|
Actors |
De klant of het personeel |
|
Basic Course of Events |
1. De klant meldt zich aan op het systeem (Use Case 03); 2. Het systeem toont informatie van de klant; 3. De klant geeft aan zijn/haar klantgegevens te willen muteren; 4. Het systeem toont de klantgegevens van de klant; 5. De klant muteert de gewenste gegevens; 6. Het systeem laat weten dat de mutaties succesvol zijn doorgevoerd en stuurt ter bevestiging een e-mail naar de klant; |
|
Alternative Paths |
Alternative Path 1: Bij stap 1 blijkt de klant zijn/haar inloggegevens is verloren 1.1 De klant geeft aan zijn/haar klantgegevens te zijn verloren; 1.2 Het systeem controleert of het bekend is met deze klant en stuurt vervolgens een nieuw wachtwoord naar de klant’s emailadres. De resterende stappen vanaf stap 2 worden gevolgd. Alternative Path 2: Bij stap 5 blijkt/blijken de ingevulde mutaties niet geldig te zijn. 5.1 Het
systeem geeft aan dat de gegevens onjuist zijn; 1.1 Het
personeel meldt zich aan op het systeem (Use Case 3); |
|
Exception Paths |
Exception Path 1: Het database systeem is niet bereikbaar 1. Het systeem zal aangeven dat er problemen zijn en verzoekt om het later te proberen. |
|
Preconditions |
De klant heeft een account voor het online systeem en die is ook geverifieerd, Use Case 01 en 02 zijn succesvol doorlopen.
|
|
Postconditions |
De klantgegevens zijn gemuteerd. |
|
Related Business Rules |
02-NKA-Pri De klant mag alleen zijn/haar directe gegevens inzien en niet die van andere klanten. |
|
Use Case: |
05 – Klant muteert planninggegevens |
|
Description |
Het is voor de klant mogelijk om zijn/haar eigen agenda gegevens te zien en zo nodig te muteren. |
|
Iteration |
Focused |
|
Triggers |
De klant die zijn/haar planning gegevens/behandelgegevens wilt inzien en of muteren. |
|
Actors |
De klant |
|
Basic Course of Events |
1. De klant meldt zich aan op het systeem (Use Case 03); 2. Het systeem toont informatie van de klant; 3. De klant geeft aan zijn/haar planninggegevens te willen muteren; 4. Het systeem toont de planninggegevens van de klant; 5. De klant muteert de gewenste gegevens; 6. Het systeem laat weten dat de mutaties succesvol zijn doorgevoerd en stuurt ter bevestiging een e-mail naar de klant; |
|
Alternative Paths |
Alternative Path 1: Bij stap 1 blijkt de klant zijn/haar inloggegevens is verloren 1.1 De klant geeft aan zijn/haar klantgegevens te zijn verloren; 1.2 Het systeem controleert of het bekend is met deze klant en stuurt vervolgens een nieuw wachtwoord naar de klant’s emailadres. De resterende stappen vanaf stap 2 worden gevolgd. Alternative Path 2: Bij stap 5 blijkt/blijken de ingevulde mutaties niet geldig te zijn. 5.1 Het
systeem geeft aan dat de gegevens onjuist zijn; |
|
Exception Paths |
Exception Path 1: Het database systeem is niet bereikbaar 1. Het systeem zal aangeven dat er problemen zijn en verzoekt om het later te proberen. |
|
Preconditions |
De klant heeft een account voor het online systeem en die is ook geverifieerd, Use Case 01 en 02 zijn succesvol doorlopen.
|
|
Postconditions |
De planninggegevens zijn gemuteerd. |
|
Related Business Rules |
02-NKA-Pri De klant mag alleen zijn/haar directe gegevens inzien en niet die van andere klanten.
03-PMP-TTA: Op één dag mogen afspraken/planning gegevens niet teveel achter elkaar worden gezet, er moet minstens een kwartier tussen afspraken zitten. Voor het geval van uitval/uitloop van afspraken.
|
|
Use Case: |
06 – Personeel muteert planninggegevens en behandelgegevens |
|
Description |
Het personeel kan de agenda- en behandelgegevens inzien en muteren van de desbetreffende klant. |
|
Iteration |
Focused |
|
Triggers |
De klant die het personeel verzocht heeft om zijn/haar planning gegevens/behandelgegevens te muteren. |
|
Actors |
Het personeel |
|
Basic Course of Events |
1. Het personeel meldt zich aan op het systeem (Use Case 03); 2. Het systeem toont een deel van de klanten; 3. Het personeel zoekt de klant op in het systeem; 4. Het systeem toont de planning- en behandelgegevens van deze klant; 5. Het personeel voert mutaties uit / voegt beschrijvingen toe aan de behandeling; 6. Het systeem geeft aan dat de gegevens succesvol zijn gemuteerd en stuurt ter bevestiging een e-mail naar de klant; |
|
Alternative Paths |
Alternative Path 1: Bij stap 3 blijkt de klant niet bekend te zijn in het systeem. 3.1 Het personeel geeft aan een nieuwe klant te willen toevoegen; 3.2 Het systeem toont het formulier; 3.3 Het personeel vult het in (aan de hand van de gegevens van de klant); 3.4 Het systeem vertelt dat de gegevens succesvol zijn opgeslagen; 3.5 Het personeel verifieert de gegevens van de klant; 3.6 Het systeem stuurt een wachtwoord naar het emailadres van de klant. De resterende stappen vanaf stap 4 worden gevolgd. Alternative Path 2: Bij stap 5 blijkt/blijken de ingevulde mutaties niet geldig te zijn. 5.1 Het
systeem geeft aan dat de gegevens onjuist zijn; |
|
Exception Paths |
Exception Path 1: Het database systeem is niet bereikbaar 1. Het systeem zal aangeven dat er problemen zijn en verzoekt om het later te proberen. |
|
Preconditions |
De klant heeft een account voor het online systeem en die is ook geverifieerd, Use Case 01 en 02 zijn succesvol doorlopen.
|
|
Postconditions |
De planninggegevens / behandelgegevens zijn gemuteerd. |
|
Related Business Rules |
03-PMP-TTA : Op één dag mogen afspraken/planning gegevens niet teveel achter elkaar worden gezet, er moet minstens een kwartier tussen afspraken zitten. Voor het geval van uitval/uitloop van afspraken.
|
Domain Models
Models per Use Case
Use Case 1 & 4
Use Case 2
Use Case 3
Use Case 5
Use Case 6
Integrated Domain Model
Scenario's
Scenario 1 – Een nieuwe klant aanmaken
- Anita Meyer navigeert zich naar het webadres van de tandartspraktijk en klinkt op de link voor het aanmaken van een nieuw account.
- Het systeem toont Anita een formulier voor het invullen van haar persoonsgegevens.
- Anita vult haar persoonsgegevens in.
[Anita Meyer
Nijmegen Groesbeeksedwarsweg 105
6573 BH
BSN-Nummer
Telefoonnummer
Geboortedatum
E-mailadres]. - Na het succesvol invullen van deze gegevens toont het systeem een bevestigende melding.
- Anita krijgt via haar zojuist ingevulde e-mailadres een notificatie binnen om de zojuist ingevulde gegevens te komen verifiëren op tandartspraktijk ‘De Wortel’.
Scenario 1 – Alternative path
- Anita vult haar persoonsgegevens in op het formulier via de website.
- De persoonsgegevens zijn foutief ingevuld.
- Het systeem herkent de fout en toont Anita een foutmelding.
- Anita vult haar persoonsgegevens opnieuw in.
Scenario 2 – Nieuwe Klant verifiëren
- Anita Meyer is aanwezig in Tandartspraktijk de Wortel en komt haar persoonsgegevens verifiëren bij een personeelslid.
- Anita toont haar identificatiebewijs aan het personeelslid.
- Het personeelslid zoekt Anita op in het klantenbestand van het systeem en verifieert Anita’s gegevens.
- Het systeem verstuurd een inlognaam en bijbehorend wachtwoord naar het e-mailadres van de klant.
Scenario 3 – Gebruiker meldt zich aan
- Anita navigeert zich naar het inlogscherm van tandartspraktijk de Wortel via de website van de praktijk.
- Anita vult haar gebruikersgegevens; bestaande uit inlognaam en wachtwoord in.
- Het systeem toont haar de beschikbare informatie over haar als klant. Deze bestaan uit haar persoons- en planning gegevens.
Scenario 4 Klantgegevens muteren (door klant)
- De klant (Anita) navigeert zich naar de webpagina van tandartspraktijk de Wortel en klikt de link aan om in te loggen in het systeem.
- Het systeem toont de persoonsgegevens van Anita.
- Anita geeft aan haar persoonsgegevens te willen muteren door op een link te klikken.
- De persoonsgegevens worden succesvol gemuteerd door Anita.
- Het systeem toont een bevestigende melding voor het doorvoeren van de mutaties in persoonsgegevens.
- Anita krijgt via email een bevestigende melding voor de mutaties van de klantgegevens.
Scenario 5 – Klant muteert planning- en behandelgegevens
- De klant Anita meldt zich aan op het systeem met haar inloggegevens, inlognaam en bijbehorend wachtwoord.
- Het systeem toont een link die de planningsgegevens toont van Anita. Hierbij wordt de datum, respectievelijke behandeling en aanwezigheidstijd weergegeven.
- Anita geeft aan haar planningsgegevens te willen muteren door een link te selecteren.
- De klant muteert de gewenste gegevens.
- Het systeem toont een bevestigende melding voor het doorvoeren van de mutaties in planningsgegevens.
- Anita krijgt via email een bevestigende melding voor de mutaties van de klantgegevens.
- Een personeelslid krijgt een notificatie van de doorgevoerde wijzigingen.
Scenario 6 – Personeel muteert planning gegevens en behandel gegevens
- Een personeelslid meldt zich aan in het systeem met behulp van haar inloggegevens, bestaande uit inlognaam en wachtwoord.
- Het systeem toont een link die het klantbestand van de tandartspraktijk weergeeft.
- Het personeelslid zoekt de klant op wiens gegevens gemuteerd dienen te worden.
- De desbetreffende klant en/of planning gegevens worden gemuteerd.
- Het systeem geeft een melding dat de gegevens succesvol zijn gemuteerd.
- De klant krijgt via email een notificatie over de doorgevoerde mutatie
Non-functional requirements
Archival:
De data van gemaakte afspraken moet tot 1 jaar na het verlopen van de afspraak beschikbaar zijn voor de documentatie. Klantgegevens moeten beschikbaar blijven tot 1 jaar na uitschrijving van de klant of tot 1 jaar na het overlijden van de klant.
Auditability:
Het systeem moet van elke medewerker bijhouden welke wijzigingen de medewerker in het afgelopen jaar in het systeem heeft doorgevoerd.
Authentication:
Gebruikers moeten altijd ingelogd zijn als ze het systeem willen gebruiken.
Availability:
Het systeem mag hoogstens één keer per maand voor 2 uur lang offline zijn voor onderhoud tijdens de openingstijden van de tandartspraktijk. Buiten de openingstijden mag het systeem maximaal drie keer per maand offline zijn voor een maximale tijdsperiode van 5 uur per keer en maximaal 10 uur per maand in totaal.
Compatibility:
Het systeem moet gebruik maken van een standaard SQL-systeem waardoor het later eventueel gekoppeld kan worden aan een factuursysteem.
Data integrity:
Er mag niet onbedoeld data verloren gaan, daarom moet er altijd een back-up beschikbaar zijn die maximaal een week oud is.
Installability:
Het systeem hoeft alleen te draaien onder Microsoft Windows.
Personalization:
Het systeem biedt de gebruiker geen mogelijkheid om het systeem te personaliseren.
Privacy:
Klanten kunnen alleen hun eigen afspraken en klantgegevens bekijken en bewerken. Werknemers van de tandartspraktijk hebben de mogelijkheid om alle afspraken en klantgegevens te bekijken.
Robustness:
Voor elke bewerking en aanvraag van gegevens moet het systeem controleren of de gebruiker nog steeds ingelogd is en of de gebruiker de juiste rechten heeft voor de betreffende handeling.
Security:
Alle afspraak- en klantgegevens moeten versleuteld verstuurd en opgeslagen worden. Voor wachtwoorden van gebruikers geldt dat slechts de SHA-256 hash wordt opgeslagen.
Upgradeability:
Het systeem moet zodanig snel te updaten zijn dat dit binnen de grenzen blijft van de eisen die in de 'Availability' gesteld zijn.
Useability:
Het mag voor klanten, die het systeem voor de eerste keer gebruiken, maximaal 10 minuten kosten om door te hebben hoe het systeem werkt. Voor werknemers van de tandartspraktijk, die het systeem voor de eerste keer gebruiken, is maximaal een training van 1 uur nodig.
Risk Analysis
|
No. |
Category |
Risk |
Resolution Needed By |
Status |
Days Lost If It Occurs |
Likelihood It Will Happen |
Riskrating |
|
001 |
Gebruikersbelangen |
Door de ontwikkeling van het systeem zullen er ontslagen vallen bij de receptionisten. Hierdoor zullen zij mogelijk niet mee willen werken aan het project. |
27 maart 2014 |
Unresolved |
7 |
80% |
5,6 |
|
002 |
Uitbreiding Systeem |
Het systeem zal misschien zodanig uitgebreid moeten worden dat het gekoppeld kan worden aan het factuursysteem. |
27 maart 2014 |
Unresolved |
14 |
20% |
2,8 |
|
003 |
Projectteam |
Een belangrijk lid van het projectteam verlaat het team. Hierdoor ontbreken bepaalde inzichten en gaat informatie die niet is vastgelegd verloren. |
Binnen 7 dagen |
Unresolved |
14 |
35% |
4,9 |
|
004 |
Projectteam |
Een lid van het projectteam is afwezig door ziekte. Hierdoor loopt het project vertraging op. |
Binnen 7 dagen |
Unresolved |
7 |
60% |
4,2 |
|
005 |
Documentatie |
Sommige informatie wordt voor algemeen bekend aangenomen, terwijl dit niet algemeen bekend is. Hierdoor wordt deze informatie niet gedocumenteerd. |
Zo snel mogelijk |
Unresolved |
14 |
70% |
9,8 |
|
006 |
Communicatie |
Er ontstaat een miscommunicatie. |
Zo snel mogelijk |
Unresolved |
3 |
50% |
1,5 |
|
007 |
Communicatie |
Er ontstaat storing bij een van de communicatie systemen (bijv. email). |
Zo snel mogelijk |
Unresolved |
2 |
1% |
0,02 |
|
008 |
Planning |
Een afspraak moet onverwachts verzet worden. |
Zo snel mogelijk |
Unresolved |
7 |
30% |
2,1 |
Business Rules Catalog
|
No. |
Rule definition |
Type of Rule |
Static/Dynamic |
Source |
|
01-NKA-Aut |
Voor fraude preventie dienen identiteit- en verzekeringsgegevens door een personeelslid worden geverifieerd, dit op basis van geldige documenten. |
Structural facts |
Static |
Federal law |
|
02-NKA-Pri |
De klant mag alleen zijn/haar directe gegevens inzien en niet die van andere klanten. |
Action restricting |
Static |
Federal law |
|
03-PMP-Tta |
Op één dag mogen afspraken/planning gegevens niet teveel achter elkaar worden gezet, er moet minstens een kwartier tussen afspraken zitten. Voor het geval van uitval/uitloop van afspraken. |
Structural facts |
Dynamic |
Management policy |
Terminologische definities
Gebruiker:
Een gebruiker is een verzameling van alle menselijke actoren. Dit betreft hier de klant en het personeel.
Personeelslid:
Een personeelslid is een actor die volledige toegang heeft tot het systeem en al zijn gegevens. (Als groep ook wel Personeel genoemd).
Klant:
Een klant is een actor met beperkte toegang tot het systeem en kan alleen zijn eigen gegevens inzien en zijn eigen planninggegevens veranderen.
Tandarts/Mondhygiënist:
Dit is een specialisatie van een Personeelslid en dit betreft alleen de personeelsleden met de functie Tandarts of de functie Mondhygiënist.
Datum:
Een datum is hier gespecificeerd als een dag (dd-mm-yyyy) en een tijdstip (hh:mm).
Tijdsduur:
De tijdsduur van een behandeling in minuten.
Doorverwijzing:
Een doorverwijzing is een behandelgegeven die alleen door tandartsen en mondhygiënisten kan worden bijgewerkt bij elke behandeling en bevat het soort externe behandeling waarmee wordt doorverwezen en de instelling naar waar is doorverwezen.
Klantnummer:
Een klantnummer is het identificatienummer van een klant binnen het bedrijf. Ook het bsn-nummer is identificerend, maar vanwege privacygevoeligheid is het door de klant niet gewenst om dit universeel te gebruiken.
Klantgegevens:
Hier betreft het de gegevens Voornaam, Tussenvoegsel, Achternaam, Telefoonnummer, Adres (Straat, Huisnummer, Woonplaats, Postcode), Geboortedatum, Geslacht, BSN-nummer, Verzekeringsgegevens (verzekerdennummer, UZOVI-code) en het klantnummer. Dit laatste wordt tijdens de inschrijving door het systeem bepaald.
Aanmeldgegevens:
Dit zijn de gegevens die ingevoerd moeten worden op het inlogscherm. Dit betreft voor een klant het klantnummer en het wachtwoord en voor een medewerker zijn naam en het wachtwoord.
Behandeling:
Een behandeling is een afspraak tussen de patiënt en een Tandarts/Mondhygiënist op een bepaalde datum. Elke behandeling heeft een identiek behandelingsnummer.
Planninggegevens:
Hier betreft het de gegevens omtrent het agenda-systeem, waarin de behandelingen zijn opgenomen. Hierbij horen dus de gegevens Tandarts/Mondhygiënist die een afspraak heeft op een bepaalde datum en tijd met een bepaalde patiënt (Tandarts/Mondhygiënist, Datum, Patiënt) met daarbij de tijdsduur van de behandeling en de behandelingscodes.
Behandelgegevens:
Dit betreft de andere gegevens die bij een behandeling kunnen worden opgeslagen, zijnde een beschrijving van de behandeling en de eventuele doorverwijzingen die tijdens de behandeling gemaakt zijn.
Behandelingstype:
Elke behandeling heeft in dit systeem een identieke code. Deze codes werden al gebruikt in de administratie van de praktijk. Bij elke code wordt ook het bedrag opgeslagen dat zo’n behandeling kost en ook een omschrijving om de administratie iets overzichtelijker te maken. b>
