Requirements Engineering/het werk/werkstuk/2013-14/Groep 06

 

ABC Bank

Werkstuk Requirements Engineering

Thomas Welten, Twan Cuijpers, Matthias Vogelaar, Bart Timmermans

Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen

---

version 18 februari 2022

---

De inhoud is opgebouwd als volgt.

Introduction

Onze opdrachtgevers zijn de eigenaren van ABC Bank. De ABC Bank is een bank met een bestaansgeschiedenis van al 2500 jaar. Momenteel heeft ABC Bank 120 filialen wereldwijd en is druk bezig met plannen om in de Asian Pacific voeten aan de grond te krijgen.

ABC Bank is koploper wat betreft internetbankieren, dit is een positie die ze graag willen behouden. Specifieker wil de bank inzetten op internetbankieren via tablets en telefoons. Momenteel worden voor het internetbankieren Random Readers gebruikt, maar de ABC Bank wil af van het gebruik van deze Random Readers. Om deze reden vragen ze om een nieuw systeem voor internetbankieren dat geen gebruik hoeft te maken van Random Readers. Voor de opdrachtgevers is het erg belangrijk om zo snel mogelijk een nieuw systeem in te voeren om daarmee veel nieuwe klanten bij de ABC Bank te kunnen verwelkomen.

Onze klant, ABC Bank, kan uit dit document afleiden wat onze oplossingen zijn voor de problemen die ons voorgelegd zijn. Bij het opstellen van dit document in in hoofdlijnen de methode aangehouden zoals die getoond wordt in het boek 'Use Cases: requirements in context' van Kulak & Guiney. In dit document zal eerst begonnen worden met het beschrijven van het probleem dat zich in de huidige situatie voordoet, in het zogenaamde 'Problem statement'. De betrokkenen bij dit probleem staan genoemd in de 'Stakeholder analysis'. Onze missie en ons doel bij dit project kan onze klant vinden in het 'Mission en vision statement'. Het overgrote deel van dit document bestaat uit 'Use cases', dit zijn uitwerkingen van sub-problemen door de ogen van de gebruiker van het systeem. In deze use cases is te vinden wat de normale gang van zaken is in de interactie met het systeem in de BCoE (Basic Course of Events), maar aangezien niet alles naar verwachting kan verlopen zijn er ook Alternative paths en Exception paths aanwezig. In die laatste twee paden is te zien hoe de interactie met het systeem verloop in een situatie die afwijkt van de gewoonlijke situatie. Per use case is ook te zien aan wat voor voorwaarden vooraf voldaan moet worden en welke voorwaarden na het uitvoeren van de use case gelden. Onder de uitgewerkte use cases zijn in dit document de 'Domain models' te vinden, dit zijn diagrammen in ORM die tonen hoe de gegevens, die bij een bepaalde case gebruikt worden, gestructureerd zijn. Ook zijn er 'Scenario's' aanwezig, dit zijn concrete voorbeelden hoe een use case doorlopen kan worden. Tenslotte, zijn de 'non-functional requirements' te vinden, een overzicht van de geldende 'Business rules' in de organisatie en definities van gebruikte termen in dit document.

Problem statement

De ABC Bank is koploper op het gebied van internetbankieren en wil vanzelfsprekend op deze positie blijven. Met de stijgende mobiele markt, wil de ABC Bank ook op smartphones de koploper in internetbankieren blijven. Daarvoor wil de bank echter af van het systeem met apparaatjes als de Random Reader.
Er is dus een systeem nodig dat niet meer afhankelijk is van een ander apparaat buiten je smartphone om te kunnen betalen. Ook moet er software komen die zorgt voor snelle en veilige betalingsmogelijkheden voor internetbankieren op een smartphone.
Tot slot moet er ook een mogelijkheid zijn om rekeningnummers te vinden aan de hand van een telefoonnummer/e-mailadres. Zo kan iemand optimaal gebruik maken van bankieren op een smartphone door met contacten van de telefoon geld over te maken.

Case analysis

Stakeholder analysis

Naam	Rol
Sander van Dam	CEO. Hoofd van het bedrijf. Moet uiteindelijk tevreden zijn.
Sjuul Follings	CFO. Hoofd van financiën bij het bedrijf. Regelt dus ook begroting voor dit project.
Klanten	De uiteindelijke eindgebruikers. Kunnen gebruikt worden om te achterhalen wat 'fijn' gevonden wordt bij het gebruik van het programma.

Opmerking: het systeem is volledig gericht op de Klant, de manier van werken voor de 'gewone medewerkers' wordt dus niet beïnvloed.

Mission and vision statement

Mission

Software creeren voor mobiel bankieren, waarmee de klant veilig en snel kan internetbankieren zonder allerlei apparaten daarbij nodig te hebben. Bovendien moet het makkelijker gemaakt worden voor klanten om rekeningnummers te vinden.

Vision

Het eindproduct moet een software systeem worden voor smartphones, dat gemakkelijk in de omgang is voor gebruikers, maar tevens veilig is en betrouwbaar. Tevens zal er een manier moeten zijn om rekeningnummers te vinden aan de hand van telefoonnummers/email-adressen. Het is belangrijk dat er geen extra apparaten nodig zijn voor het bankieren.

Statement of work

Deliverable	DeliverbleType	Façade	Filled	Focused	Comment
Introduction	Contextual	Preliminary version	Preliminary version	Complete	Keep it short at first, only a sketch; nice, clear and complete at the end.
Status:		100%	100%	100%	-
Problem statement	Key deliverable	As good as possible	As good as possible	Complete
Status:		100%	100%	100%	-
Stakeholder list/analysis	Contextual	As good as possible	As good as possible	Complete
Status:		100%	100%	100%	-
Mission-Vision-(Values)	Contextual	Complete	Complete	Complete
Status:		100%	100%	100%	-
Statement of Work	Contextual	Complete, and up-to-date	Complete, and up-to-date	Complete, and up-to-date
Status:		100%	100%	100%	-
Risk Analysis	Contextual	Complete, and up-to-date	Complete, and up-to-date	Complete, and up-to-date
Status:		100%	100%	100%	-
Use Case Survey	Key deliverable	As good as possible	Nearly complete	Complete
Status:		100%	100%	100%	-
Integrated UC Diagram	Key deliverable	Complete (though preliminary)	Complete	Complete	One for whole project
Status:		100%	100%	100%	-
Use Cases	Key deliverable	Not yet!	"Filled" level	Complete
Status:			100%	100%	-
Scenarios	Key deliverable	Not yet!	Several for each UC	Complete ("focused" level)
Status:			100%	100%	-
Domain Models	Key deliverable	Not yet!	Partially complete	Complete	One for each UC
Status:			100%	100%	-
Business rules per UC	Key Deliverable	Not yet!	Partially complete	Complete
Status:			1000%	100%
Integrated Domain Model	Key deliverable	Not yet!	First draft	Complete	One for whole project
Status:			100%	100%	-
Busines Rules Catalogue	Key deliverable	Not yet!	Partially complete	Complete
Status:			100%	100%	-
Non-functional Requirements	Key deliverable	Notes	Partially complete	Complete
Status:		100%	100%	100%	-
Terminological Definitions	Key deliverable	Notes	Partially complete	Complete
Status:		100%	100%	100%	-
Executive sponsor viewpoint	Implicit deliverable	Complete	Complete	Complete	Integrated in M-V-(V)!
Status:		100%	100%	100%	-
Use case tests	Implicit deliverable	Notes	As good as possible	Complete	Integrated in scenarios; to be done, but not written down explicitly as a separate item
Status:		100%	100%	100%
Business process definitions	Optional appendix	If available / relevant	If relevant	If relevant	Use existing definitions/models or make them yourself: optional!
Status:		nvt	nvt	nvt	-
GUI metaphors / storyboards	Optional appendix	If relevant	If relevant	If relevant
Status:		nvt	nvt	nvt	-

Risk analysis

#	Category	Risk	Solution needed by	Status	Days lost	Expectancy factor	Risk factor
01	Groepsleden	Uitval	z.s.m	n.v.t.	0	5%	7
02	Groepsleden	Afwezigheid	direct	n.v.t.	0	30%	2
03	Planning	Meer tijd nodig	n.v.t.	Enkele keer	1	40%	5
04	Communicatie	Miscommunicatie binnen de groep	voor deadline	n.v.t.	0	40%	5
05	Communicatie	Onduidelijkheid case	z.s.m	Case deels herschreven	1	60%	6
06	Technisch	Verlies van Data	voor deadline	n.v.t.	0	10%	8
07	Technisch	Wiki niet beschikbaar	voor deadline	n.v.t.	0	20%	2

Requirements

Use cases

Use Case Diagram

Use case survey

#	Name	Description	Initiating actor
01	Accountaanvraag	Gebruiker wil account aanvragen	Klant
02	Inloggen	Gebruiker wil inloggen in het bankiersysteem	Klant
03	Saldo-opvragen	Gebruiker wil saldo opvragen	Klant
04	Geld overmaken	Gebruiker wil geld overmaken naar een andere rekening	Klant
05	Investeringsportefeuille	Gebruiker wil zijn Investeringsportefeuille bekijken	Klant

Individual use cases

Use Case 1

Use Case:	Accountaanvraag
#	01
Use case diagram
Description	Het aanvragen van een account door een klant
Trigger	Klant geeft aan internetbankieren te willen aanvragen
Version	2.2
Basic course of events	Klant geeft aan internetbankieren te willen aanvragen. Systeem vraagt naar naam, geboortedatum en rekeningnummer van de klant. Klant geeft volledige naam, geboortedatum en rekeningnummer. Systeem toont de klant de gegenereerde gebruikersnaam en vraagt de klant in tweevoud een wachtwoord in te voeren dat voor internetbankieren gebruikt zal worden. Klant geeft in tweevoud een wachtwoord in. Systeem vraagt de klant om mobiel telefoonnummer. Klant geeft een mobiel telefoonnummer. Systeem geeft aan dat aanvraag voltooid is en dat de klant zich dient te melden bij een kantoor van de ABC Bank om daar een geldig identiteitsbewijs te tonen.
Alternate paths	n.v.t.
Exception paths	Door klant gegeven naam, geboortedatum en rekeningnummer ongeldig. 4. Systeem geeft aan dat naam, geboortedatum en rekeningnummer ongeldig zijn. De Use Case gaat verder bij 2. Klant heeft een wachtwoord ingevoerd dat niet overeenkomt met de gestelde eisen. 6. Systeem geeft aan dat er geen geldig wachtwoord is ingevoerd. De Use Case gaat verder bij 4. Klant heeft twee verschillende wachtwoorden ingevoerd. 6. Systeem geeft aan dat er geen geldig wachtwoord is ingevoerd. De Use Case gaat verder bij 4. Klant heeft geen geldig telefoonnummer gegeven. 8. Systeem geeft aan dat er geen geldig telefoonnummer gegeven is. De Use Case gaat verder bij 6.
Assumptions	De klant heeft al een rekening bij de ABC Bank maar die rekening kan nog niet gebruikt worden voor internetbankieren.
Preconditions	Het systeem is beschikbaar. Het apparaat dat de actor gebruikt om in te loggen heeft een op dat moment een actieve internetverbinding.
Postconditions	De rekening van de klant is te gebruiken voor internetbankieren nadat de klant zich heeft gemeld bij een kantoor van ABC Bank om een geldig identiteitsbewijs te tonen.
Related business rules	BR4 BR5
Author	Twan Cuijpers

Use Case 2

Use Case:	Inloggen
#	02
Use case diagram
Description	De gebruiker probeert in te loggen
Trigger	De actor geeft aan bij het systeem dat hij in wil loggen
Version	1
Basic course of events	De actor kiest de optie inloggen. Het systeem laat het inlogvenster zien. De actor voert zijn gebruikersnaam en wachtwoord in. Het systeem toont de actor een melding dat hij ingelogd is
Alternate paths	De actor besluit dat hij toch niet in wil loggen 2. Het systeem laat het inlogvenster zien. 3. De actor breekt het inloggen af. 4. Het systeem sluit het inlogvenster. De use-case wordt afgebroken. De opgegeven gebruikersnaam is geen bestaande gebruikersnaam. 3. De actor voert zijn gebruikersnaam en wachtwoord in. 4. Het systeem geeft een foutmelding en laat het inlogvenster zien. De use-case gaat verder bij 3. Het opgegeven wachtwoord komt niet overeen met de gebruikersnaam. 3. De actor voert zijn gebruikersnaam en wachtwoord in. 4. Het systeem geeft een foutmelding en laat het inlogvenster zien. De use-case gaat verder bij 3.
Exception paths	De actor voert voor de derde maal een verkeerde gebruikersnaam/wachtwoord combinatie in. 3. De actor voert zijn gebruikersnaam en wachtwoord in. 4. Het systeem deelt de actor mee dat het apparaat wat de actor gebruikt tijdelijk geblokkeerd is. De use-case wordt afgebroken. De actor voert voor de vijfde maal een verkeerde gebruikersnaam/wachtwoord combinatie in. 3. De actor voert zijn gebruikersnaam en wachtwoord in. 4. Het systeem deelt de actor mee dat het account van de gebruikersnaam die de actor heeft ingevoerd geblokkeerd is, en dat het systeem een e-mail naar de desbetreffende gebruiker gestuurd heeft. De use-case wordt afgebroken. Het apparaat dat de actor gebruikt blijkt geblokkeerd te zijn. 1. De actor kiest de optie inloggen. 2. Het systeem toont een melding waarin staat dat het apparaat dat de actor gebruikt tijdelijk geblokkeerd is. De use-case wordt afgebroken. Het account dat de actor opgegeven heeft blijkt geblokkeerd te zijn. 3. De actor voert zijn gebruikersnaam en wachtwoord in. 4. Het systeem meldt de actor dat er een fout is opgetreden.
Assumptions	De actor heeft een account. De actor kent zijn gebruikersnaam en wachtwoord.
Preconditions	Het systeem is beschikbaar. Het apparaat dat de actor gebruikt om in te loggen heeft een op dat moment een actieve internetverbinding.
Postconditions	De gebruiker is ingelogd.
Related business rules	BR6 BR7
Author	Matthias Vogelaar

Use Case 3

Use Case:	Saldo opvragen
#	03
Use case diagram
Description	Een gebruiker vraagt zijn saldo op.
Trigger	De gebruiker geeft aan zijn saldo te willen opvragen.
Version	1.0
Basic course of events	De gebruiker geeft aan zijn saldo('s) te willen opvragen. Het systeem laat de gebruiker tussen zijn spaar- of betaalrekening kiezen. De gebruiker maakt een keuze uit de rekeningen. Het systeem toont de gebruiker het saldo van de gekozen rekening.
Alternate paths	Meer rekeningen: 2. Het systeem laat de gebruiker tussen zijn verschillende rekeningen kiezen. 3. De gebruiker maakt een keuze uit de rekeningen. 4. Het systeem toond de gebruiker naam en saldo van de gekozen rekeningen Ander tijdstip: 5. De gebruiker geeft aan het saldo op een vroeger tijdstip te willen bekijken. 6. Het systeem geeft de gebruiker gelegenheid een datum in te vullen 7. De gebruiker geeft deze datum in. 8. Het saldo van de gekozen rekening op het gekozen tijdstip verschijnt op het scherm.
Exception paths	n.v.t.
Assumptions	De gebruiker heeft een account.
Preconditions	De gebruiker is ingelogd.
Postconditions	De gebruiker heeft zijn rekening saldo gezien.
Related business rules	BR2
Author	Thomas Welten

Use Case 4

Use Case:	Geld overmaken
#	04
Use case diagram
Description	Geld overmaken naar een andere rekening.
Trigger	Klant geeft aan dat hij geld wil overmaken.
Version	1.2
Basic course of events	Basic Path Klant geeft over te maken bedrag en rekeningnummer ontvanger in. Systeem vraagt de klant om bevestiging van overmaken. Klant bevestigt de overmaking (mogelijk met gebruik van wachtwoord/PIN). Systeem toont de klant dat de overmaking succesvol is.
Alternate paths	Alternative path 1 (Gebruiker wil overmaken m.b.v. telefoonnummer/e-mailadres) Klant geeft over te maken bedrag in en geeft telefoonnummer/e-mailadres ontvanger in. Systeem wijst gebruiker op eventuele risico's van het zoeken met telefoonnummer/e-mail en vraagt bevestiging om door te gaan. Gebruiker bevestigt dat hij de risico's erkent. Systeem vraagt de gebruiker om bevestiging van overmaken. Klant bevestigt de overmaking (mogelijk met gebruik van wachtwoord/PIN). Systeem toont de klant dat de overmaking succesvol is. Alternative path 2 (Gebruiker annuleert overboeking) Klant geeft over te maken bedrag en rekeningnummer ontvanger in. Systeem vraagt de klant om bevestiging van overmaken. Gebruiker geeft aan niet door te willen gaan met de overboeking. Systeem verwijdert de overboeking uit systeem en begint weer opnieuw bij 1.
Exception paths	Exception path 1 (Klant voert ongeldige waardes in) Als de gebruiker bij stap 1 ongeldige waardes ingevoerd hebben zal dat bij stap 2 ontdekt worden, zodra dit ontdekt is zal het systeem deze overboeking annuleren en opnieuw beginnen. 2. Systeem wijst klant op invoer van ongeldige waardes. 3. Klant bevestigd dat hij het bericht gezien heeft. 4. Systeem begint opnieuw bij 1. Exception path 2 (Klant heeft onvoldoende saldo) 2. Systeem wijst klant dat hij onvoldoende saldo heeft. 3. Klant bevestigd dat hij het bericht gezien heeft. 4. Systeem begint opnieuw bij 1. Exception path 3 (Ontvanger bestaat niet) 2. Systeem wijst klant op het niet bestaan van de ontvanger. 3. Klant bevestigd dat hij het bericht gezien heeft. 4. Systeem begint opnieuw bij 1. Exception path 4 (Bevestiging niet in orde) 3. Gebruiker geeft geen/ongeldige bevestiging. 4. Systeem wijst klant ongeldige bevestiging. 5. Klant bevestigd dat hij het bericht gezien heeft. 6. Systeem begint opnieuw bij 1.
Assumptions	Gebruiker heeft een account
Preconditions	Gebruiker is ingelogd Gebruiker is geverifieerd door de bank.
Postconditions	De opgegeven hoeveelheid geld is overgemaakt en de opgegeven ontvanger heeft/gaat het geld ontvangen.
Related business rules	BR1 BR3 BR8
Author	Bart Timmermans

Use Case 5

Use Case:	Investeringsportefeuille bekijken
#	05
Use case diagram
Description	Een gebruiker wil zijn investeringsportefeuille bekijken.
Trigger	Een gebruiker geeft aan zijn investeringsportefeuille te willen bekijken.
Version	1.0
Basic course of events	De gebruiker geeft aan de investeringsportefeuille te willen bekijken. Het systeem toont de huidige investeringen aan de gebruiker.
Alternate paths	De gebruiker wil de accountmanager, die voor zijn investeringen verantwoordelijk, is bereiken. 1. De gebruiker geeft aan zijn accountmanager te willen bereiken. 2. Het systeem toont de contactgegevens van de accountmanager.
Exception paths	n.v.t.
Assumptions	De gebruiker heeft een account. De gebruiker heeft een investeringsportefeuille.
Preconditions	De gebruiker is ingelogd.
Postconditions	De gebruiker heeft zijn portefeuille kunnen zien of de contactgegevens van zijn accountmanager gezien
Related business rules	BR2 BR8
Author	Thomas Welten

Domain Model per Use Case

DM01

DM02

DM03

DM04

DM05

Scenarios

Use Case 01 - Accountaanvraag

SC01.1

Scenario	Basic Course of Events
Beschrijving	Peter R. de Diepvries vraagt een account voor internetbankieren aan. Dit lukt hem.
Actor	Peter R. de Diepvries
Verloop	Gebruiker Peter geeft aan internetbankieren te willen aanvragen. Het systeem vraagt Peter naar zijn naam, geboortedatum en rekeningnummer. Peter geeft zijn naam, geboortedatum en rekeningnummer. Systeem toont Peter de gegenereerde gebruikersnaam en vraagt Peter in tweevoud een wachtwoord in te voeren dat voor internetbankieren gebruikt zal worden. Peter voert twee keren hetzelfde wachtwoord in. Het systeem vraagt om het mobiele nummer van Peter. Peter geeft zijn mobiele nummer. Het systeem geeft aan dat aanvraag voltooid is en dat Peter zich dient te melden bij een kantoor van de ABC Bank om daar een geldig identiteitsbewijs te tonen.

SC01.2

Scenario	Ongeldige naam, geboortedatum en rekeningnummer
Beschrijving	Peter R. de Diepvries probeert een account aan te vragen maar typt een ongeldig naam, geboortedatum en rekeningnummer in.
Actor	Peter R. de Diepvries
Verloop	Gebruiker Peter geeft aan internetbankieren te willen aanvragen. Het systeem vraagt Peter naar zijn naam, geboortedatum en rekeningnummer. Peter geeft ongeldige naam, geboortedatum en rekeningnummer in. Systeem geeft aan dat naam, geboortedatum en rekeningnummer ongeldig zijn. Het systeem vraagt Peter naar zijn naam, geboortedatum en rekeningnummer. Peter geeft geldige naam, geboortedatum en rekeningnummer in. Systeem toont Peter de gegenereerde gebruikersnaam en vraagt Peter in tweevoud een wachtwoord in te voeren dat voor internetbankieren gebruikt zal worden. Peter voert twee keren hetzelfde wachtwoord in. Het systeem vraagt om het mobiele nummer van Peter. Peter geeft zijn mobiele nummer.

SC01.3

Scenario	Wachtwoord voldoet niet aan de gestelde eisen
Beschrijving	Peter R. de Diepvries probeert een account aan te vragen maar typt een wachtwoord in dat niet voldoet aan de gestelde eisen in.
Actor	Peter R. de Diepvries
Verloop	Gebruiker Peter geeft aan internetbankieren te willen aanvragen. Het systeem vraagt Peter naar zijn naam, geboortedatum en rekeningnummer. Peter geeft zijn naam, geboortedatum en rekeningnummer. Systeem toont Peter de gegenereerde gebruikersnaam en vraagt Peter in tweevoud een wachtwoord in te voeren dat voor internetbankieren gebruikt zal worden. Peter voert twee keren een identiek wachtwoord in dat niet voldoet aan de gestelde eisen. Systeem toont Peter de gegenereerde gebruikersnaam en vraagt Peter in tweevoud een wachtwoord in te voeren dat voor internetbankieren gebruikt zal worden. Peter voert twee keren hetzelfde wachtwoord in, dat voldoet aan de gestelde eisen. Het systeem vraagt om het mobiele nummer van Peter. Peter geeft zijn mobiele nummer.

SC01.4

Scenario	Twee verschillende wachtwoorden ingevoerd
Beschrijving	Peter R. de Diepvries probeert een account aan te vragen maar twee verschillende wachtwoorden in.
Actor	Peter R. de Diepvries
Verloop	Gebruiker Peter geeft aan internetbankieren te willen aanvragen. Het systeem vraagt Peter naar zijn naam, geboortedatum en rekeningnummer. Peter geeft zijn naam, geboortedatum en rekeningnummer. Systeem toont Peter de gegenereerde gebruikersnaam en vraagt Peter in tweevoud een wachtwoord in te voeren dat voor internetbankieren gebruikt zal worden. Peter voert twee verschillende wachtwoorden in. Het systeem geeft aan dat het wachtwoord ongeldig was en vraagt in tweevoud naar zijn gewenste wachtwoord. Peter voert twee keren hetzelfde wachtwoord in, dat voldoet aan de gestelde eisen. Het systeem vraagt om het mobiele nummer van Peter. Peter geeft zijn mobiele nummer.

Use Case 02 - Inloggen

SC02.1

Scenario	Basic Course of Events
Beschrijving	Henk de Steen probeert in te loggen bij de ABC Bank. In dit scenario lukt hem dat.
Actor	Henk de Steen
Verloop	Gebruiker Henk kiest de optie inloggen. Het systeem laat het inlogvenster zien. Henk voert zijn gebruikersnaam en wachtwoord in. Het systeem toont Henk een melding dat hij ingelogd is.

SC02.2

Scenario	Inloggen Afbreken
Beschrijving	Henk de Steen probeert in te loggen, maar besluit dat dit niet nodig is en stopt met inloggen.
Actor	Henk de Steen
Verloop	Gebruiker Henk kiest de optie inloggen Het systeem laat het inlogvenster zien. Henk wil toch niet inloggen en breekt het inloggen af. Het systeem sluit het inlogvenster.

SC02.3

Scenario	Ongeldige gebruikersnaam
Beschrijving	Henk maakt de eerste keer een typefout bij het intypen van zijn gebruikersnaam. Het inloggen mislukt dan, maar Henk herstelt dit met een tweede poging.
Actor	Henk de Steen
Verloop	Gebruiker Henk kiest de optie inloggen Het systeem laat het inlogvenster zien Henk voert een niet bestaande gebruikersnaam en een wachtwoord in. Het systeem geeft een foutmelding en laat het inlogvenster zien. Henk voert zijn gebruikersnaam en wachtwoord in. Het systeem toont Henk een melding dat hij ingelogd is.

SC02.4

Scenario	Ongeldig wachtwoord
Beschrijving	Henk typt zijn wachtwoord verkeert in waardoor het inloggen mislukt. Bij de tweede poging typt hij zijn wachtwoord wel correct in.
Actor	Henk de Steen
Verloop	Gebruiker Henk kiest de optie inloggen Het systeem laat het inlogvenster zien Henk voert zijn gebruikersnaam en een verkeerd wachtwoord in. Het systeem geeft een foutmelding en laat het inlogvenster zien. Henk voert zijn gebruikersnaam en wachtwoord in. Het systeem toont Henk een melding dat hij ingelogd is.

SC02.5

Scenario	Apparaat blokkeren
Beschrijving	Henk gelooft niet dat ABC Bank zijn telefoon tijdelijk de toegang tot zijn account van internetbankieren kan ontzeggen. Daarom typt Henk met opzet drie maal een verkeerd wachtwoord in om te kijken wat er gebeurt.
Actor	Henk de Steen
Verloop	Gebruiker Henk kiest de optie inloggen. Het systeem laat het inlogvenster zien. Henk voert zijn gebruikersnaam en een verkeerd wachtwoord in. Het systeem geeft een foutmelding en laat het inlogvenster zien. Henk voert zijn gebruikersnaam en een verkeerd wachtwoord in. Het systeem geeft een foutmelding en laat het inlogvenster zien. Henk voert zijn gebruikersnaam en een verkeerd wachtwoord in. Het systeem geeft een foutmelding en deelt Henk mee dat zijn apparaat tijdelijk geblokkeerd is. Henk kiest de optie inloggen. Het systeem toont een melding dat het apparaat tijdelijk geblokkeerd is.

SC02.6

Scenario	Account Blokkeren
Beschrijving	Henk de Steen probeert zijn account te blokkeren door vijf maal een verkeerd wachtwoord te gebruiken.
Actor	Henk de Steen
Verloop	Henk kiest de optie inloggen. Het systeem laat het inlogvenster zien. Henk voert zijn gebruikersnaam en een verkeerd wachtwoord in. Het systeem geeft een foutmelding en laat het inlogvenster zien. Henk voert zijn gebruikersnaam en een verkeerd wachtwoord in. Het systeem geeft een foutmelding en laat het inlogvenster zien. Henk voert zijn gebruikersnaam en een verkeerd wachtwoord in. Het systeem geeft een foutmelding en deelt Henk mee dat zijn apparaat tijdelijk geblokkeerd is. Henk verwisselt zijn telefoon voor zijn tablet, start de applicatie op, en kiest de optie inloggen.# Het systeem laat het inlogvenster zien Henk voert zijn gebruikersnaam en een verkeerd wachtwoord in. Het systeem geeft een foutmelding en laat het inlogvenster zien. Henk voert zijn gebruikersnaam en een verkeerd wachtwoord in. Het systeem deelt de actor mee dat het account van de gebruikersnaam die de actor heeft ingevoerd geblokkeerd is en dat het systeem een e-mail naar de desbetreffende gebruiker gestuurd heeft.

SC02.7

Scenario	Poging inloggen geblokkeerd apparaat
Beschrijving	Henk probeert nu met zijn geblokkeerde telefoon in te loggen
Actor	Henk de Steen
Verloop	Gebruiker Henk kiest de optie inloggen. Het systeem toont een melding waarin staat dat het apparaat dat Henk gebruikt tijdelijk geblokkeerd is.

SC02.8

Scenario	Poging inloggen geblokkeerd account
Beschrijving	Henk probeert nu met zijn geblokkeerde account in te loggen.
Actor	Henk de Steen
Verloop	Henk kiest de optie inloggen. Het systeem laat het inlogvenster zien. Henk voert zijn gebruikersnaam en wachtwoord in. Het systeem meldt Henk dat er een fout is opgetreden.

Use Case 03 - Saldo opvragen

SC03.1

Scenario	Saldo opvragen: BCoE
Beschrijving	Henk de Steen bekijkt het saldo van zijn betaalrekening
Actor	Henk de Steen
Verloop	Henk de Steen geeft aan zijn saldo op te willen vragen. Het systeem geeft Henk de keuze tussen betaal en spaarrekening. Henk de Steen kiest de betaalrekening. Het huidige saldo van de betaalrekening wordt aan Henk getoond.

SC03.2

Scenario	Saldo opvragen: Alternate Path 1
Beschrijving	Henk de Steen bekijkt de saldi van zijn rekeningen
Actor	Henk de Steen
Verloop	Henk de Steen geeft aan zijn saldo op te willen vragen. Het systeem laat Henk tussen zijn verschillende rekeningen kiezen. Henk besluit het Saldo van zijn normale betaalrekening, zijn normale spaarrekening en zijn Zwitserse bankrekening bij de ABC Bank te willen zien. Het systeem toond Henk naam en saldo van de gekozen rekeningen

SC03.3

Scenario	Saldo opvragen: Alternate Path 2
Beschrijving	Henk de Steen bekijkt wat het saldo van zijn betaalrekening was op een eerder tijdstip
Actor	Henk de Steen
Verloop	Henk de Steen geeft aan zijn saldo op te willen vragen. Het systeem geeft Henk de keuze tussen betaal en spaarrekening. Henk de Steen kiest de betaalrekening. Het huidige saldo van de betaalrekening wordt aan Henk getoond. Henk geeft aan het saldo op een vroeger tijdstip te willen bekijken. Het systeem vraagt Henk om een Datum. Henk vult 24.7.2012 in. Het systeem toond Henk zijn Saldo op dat Datum, namelijk 3.000.000 €

Use Case 04 - Geld overmaken

SC04.1

Scenario	BCoE
Beschrijving	De klant wil geld overmaken naar een andere partij, zoals dit standaard in werking gaat.
Actor	Klant
Verloop	De klant wil €15,- overmaken als cadeau naar een vriend De klant geeft aan dat hij geld wil overmaken. De klant vult als bedrag 15,00 in en het rekeningnummer van zijn vriend in. Er wordt aan de klant een bevestiging voor de overmaking met zijn wachtwoord gevraagd. De klant voert zijn wachtwoord in en bevestigt. Het systeem toont een bericht dat het bedraagt succesvol is overgemaakt.

SC04.2

Scenario	Alternative Path
Beschrijving	De klant wil geld overmaken naar een andere partij, zoals dit in het alternative path 1 in werking gaat.
Actor	Klant
Verloop	De klant wil €50,- overmaken die hij nog schuldig was, hij heeft echter geen rekeningnummer De klant geeft aan dat hij geld wil overmaken. De klant vult als bedrag 50,00 in en vult het telefoonnummer en email adres van de ontvanger in. Er wordt aan de klant een bevestiging gevraagd omdat deze techniek risico's bevat. De klant klikt op bevestigt dat hij toch door wil gaan. Er wordt aan de klant een bevestiging voor de overmaking met zijn wachtwoord gevraagd. De klant voert zijn wachtwoord in en bevestigt. Het systeem toont een bericht dat het bedraagt succesvol is overgemaakt.

SC04.3

Scenario	Alternate path 2
Beschrijving	De klant begint met het proces van geld overmaken, maar annuleert dit proces vervolgens.
Actor	Klant
Verloop	De klant wil €15,- overmaken als cadeau naar een vriend De klant geeft aan dat hij geld wil overmaken. De klant vult als bedrag 1,50 in en vult het rekeningnummer van zijn vriend in. Er wordt aan de klant een bevestiging voor de overmaking met zijn wachtwoord gevraagd. De klant ziet nu dat hij slechts 1,50 heeft ingevuld als bedrag en annuleert de overboeking. Systeem verwijdert de overboeking uit het systeem en begint opnieuw.

SC04.4

Scenario	Exception path 1
Beschrijving	De klant voert abusievelijk of opzettelijk een ongeldige waarde in.
Actor	Klant
Verloop	De gebruiker vult -4000,00 in bedrag om de bank geld proberen af te troeven. De klant geeft aan dat hij geld wil overmaken. De klant vult als bedrag -4000,00 in en vult een willekeurig rekeningnummer in. Het systeem wijst de klant op invoer van ongeldige waardes. De klant bevestigt dat hij dit bericht gezien heeft. Systeem begint opnieuw.

SC04.5

Scenario	Exception path 2
Beschrijving	De klant wil meer geld overmaken dan dat hij heeft.
Actor	Klant
Verloop	De klant wil €400,- overmaken naar een winkel om iets te kopen. De klant geeft aan dat hij geld wil overmaken. De klant vult als bedrag 400,00 in en vult het rekeningnummer van de winkel in. Het systeem wijst de klant erop dat hij onvoldoende saldo heeft. Systeem begint opnieuw.

SC04.6

Scenario	Exception path 3
Beschrijving	De klant wil geld overmaken naar een niet bestaande andere partij.
Actor	Klant
Verloop	De klant wil €15,- overmaken als cadeau naar een vriend, maar vergist zich per ongelijk in een nummer De klant geeft aan dat hij geld wil overmaken. De klant vult als bedrag 15,00 in en vult het rekeningnummer van zijn vriend in, maar vergist zich in 1 nummer. Het achterliggende systeem wijst de gebruiker op een niet bestaand rekeningnummer. De klant bevestigt dat hij dit bericht gezien heeft. Systeem begint opnieuw.

SC04.7

Scenario	Exception path 4
Beschrijving	De klant bevestigt de overmaking niet op de juiste manier.
Actor	Klant
Verloop	De klant wil €20,- overmaken, maar bevestigd niet juist De klant geeft aan dat hij geld wil overmaken. De klant vult als bedrag 20,00 in en vult het rekeningnummer van de ontvanger in. Het systeem vraagt aan de klant een bevestiging met zijn wachtwoord. De klant voert zijn wachtwoord in (maar maakt hierbij dus een fout) en klikt op bevestigen. Het systeem ziet dat de bevestiging niet klopt en wijst de gebruiker hierop De klant bevestigt dat hij dit gezien heeft. Systeem begint opnieuw.

Use Case 05 - Investeringportefeuille bekijken

SC05.1

Scenario	Investeringportefeuille bekijken
Beschrijving	Henk de Steen bekijkt zijn investeringen.
Actor	Henk de Steen
Verloop	Henk de Steen geeft aan zijn Investeringen te willen bekijken. Henk de Steen zijn investeringen verschijnen op het scherm, namelijk zijn Griekse staatsobligaties, gekocht in 2007.

SC05.2

Scenario	Alternate path
Beschrijving	Henk de Steen wil de accountmanager, die voor zijn investeringen verantwoordelijk is, bereiken.
Actor	Henk de Steen
Verloop	Henk de Steen geeft aan zijn accountmanager te willen bereiken. Het systeem toont de contactgegevens van de accountmanager aan Henk de Steen.

Non-functional Requirements

• Beschikbaarheid: Het systeem mag niet meer dan 10 uur per maand voor onderhoud offline zijn.
• Veiligheid: De communicatie tussen de applicatie en de servers van de bank verloopt versleuteld. Deze versleuteling is voorzien van een sleutel die minstens 512 bits lang is.
• Veiligheid: Lokale filialen hebben geen toegang tot gebruikersgegevens. Alle wijzigingen dienen door het hoofdkantoor afgehandeld te worden.
• Veiligheid: Gebruikersgegevens worden versleuteld opgeslagen. De wachtwoorden woorden gehasht en voorzien van een salt.
• Veiligheid: Het moet moeilijk zijn om in te breken in een account. Maximaal mag er bij 1 op de 100.000 gebruikers ingebroken worden, zonder dat de aanvaller de inlog en het wachtwoord van het aangevallen account weet.
• Snelheid: Het systeem moet bij een belasting van 1000 actieve gebruikers betrouwbaar blijven. Dat wil zeggen, bewerkingen moeten binnen 5 seconden afgerond zijn. Bij meer dan 2000 actieve gebruikers mag er in 5% van de gevallen een maximale vertraging van 15 seconden zijn.
• Gebruikersvriendelijkheid: Er wordt een consistent interface gebruikt, dat van te voren bij een testgroep van gebruikers getest wordt
• Compatibiliteit: De applicatie is beschikbaar voor Android-, iOS- en Windows Phone-besturingssystemen.

Addendum

Integrated Domainmodel

Business Rules Catalogue

#	Rule Definition	Type of Rule	Static/Dynamic	Source
BR1	0,1% van het te overmaken bedrag wordt in rekening gebracht als winst voor de bank	Calculations	Static	Bestuursbeleid
BR2	Gebruikers die meer dan 50 keer per uur inloggen worden onderzocht door de beveiligingsafdeling	Action triggering	Static	Bestuursbeleid
BR3	Maximum bedrag dat voor een overboeking op een mobiel zonder extra apparaat gemaakt mag worden mag niet overschreden worden (initieel 2000 euro; aan te passen door Klant in overleg met ABC Bank).	Structural facts	Dynamic	Bestuursbeleid
BR4	Een gebruikersnaam is een unieke, computergegenereerde string die maar een keer in het systeem voorkomt.	Structural facts	Static	Bestuursbeleid
BR5	Een wachtwoord moet minimaal uit 8 karakters bestaan, één hoofdletter bevatten, één cijfer bevatten en één leesteken.	Structural facts	Static	Bestuursbeleid
BR6	Na drie maal een verkeerde combinatie van gebruikersnaam en wachtwoord ingevoerd te hebben op hetzelfde apparaat, dan wordt dat apparaat tijdelijk geblokkeerd.	Action triggering	Static	Bestuursbeleid
BR7	Na vijf maal een verkeerde combinatie van gebruikersnaam en wachtwoord ingevoerd te hebben voor één en hetzelfde geldige gebruikersnaam, wordt het account van die gebruiker geblokkeerd.	Action triggering	Static	Bestuursbeleid
BR8	Als vijf transacties snel achter elkaar uitgevoerd worden, dan vindt er een extra controle met wachtwoord plaats.	Action triggering	Static	Bestuursbeleid

Terminological Definitions

Klant:

persoon die een product heeft bij de ABC Bank

Gebruiker:

klant die toegang heeft tot internetbankieren bij de ABC Bank

Medewerker:

persoon die werkt bij de ABC Bank, ongeacht zijn functie binnen de organisatie

Bankproduct:

product dat door een een klant bij de ABC Bank wordt afgenomen

Investeringsportefeuille:

bankproduct dat aandelen kan bevatten

Bankrekening:

bankproduct een spaarrekening of betaalrekening is

Spaarrekening:

bankproduct dat geld kan bevatten, bedoeld om mee te sparen

Betaalrekening:

bankproduct dat geld kan bevatten, bedoeld om mee te betalen

Accountmanager:

medewerker die verantwoordelijk is voor de investeringsportefeuille van een klant