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

Uit Werkplaats
Ga naar: navigatie, zoeken

Requirements Engineering

 © comments



 






PGGM Risk Analysis



Werkstuk Requirements Engineering


Jan Martens, Nick Tönissen, Wietse Kuipers, Willem Boumans, Arjen Theunis



Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen






version 18 februari 2022

Page Break





Introduction

PGGM is een grote pensioenfondsbeheerder. Zij hebben op dit moment een administratie, die niet efficiënt genoeg is. Daarom hebben zij ons verzocht een nieuw systeem voor hun op te zetten. In dit document vind u de requirements van dit systeem. Allereerst worden de problemen met het huidige systeem opgenoemd. Verderop staan een aantal use cases, waarin men het systeem kan onderverdelen. Deze use cases gaan gepaard met een basic course of events en een ORM-schema. Voor ieder van deze use cases staan ook enkele scenario's beschreven. Achteraan vind men het globale ORM-schema, de business rules van PGGM en een verklarende woordenlijst.

Problem statement

Het bedrijf PGGM gebruikt op dit moment een Excel-bestand om beleggingsvoorstellen op te slaan en te beheren. Dit geeft een aantal problemen voor de afdeling, namelijk:

  • Groot, onoverzichtelijk bestand
  • Problemen zodra meerdere mensen aan het bestand moeten werken
  • Medewerkers kunnen in principe bij de voostellen van anderen

Case analysis

Stakeholder analysis

Stakeholder Bezigheden Omschrijving
Directeur
  • Controleren van alle beleggingsvoorstellen
  • Kan voorstellen annuleren
  • Begeleidende functie tijdens meetings
  • De baas van het bedrijf
Medewerker
  • Doen uiteindelijk de voorstellen
  • Rekenen alles door, en zetten dit in het systeem
  • Controleren de voorstellen
  • Risico-analysten
Klant
  • Hiervoor worden de voorstellen gedaan.
  • Heeft geen directe invloed op het systeem, maar heeft er wel baat bij dat voorstellen goed worden bijgehouden

Mission Statement

Het doel van dit project is om alle beleggingsvoorstellen op een overzichtelijke en handige manier samen te brengen. Dit is nodig omdat de huidige manier onoverzichtelijk en inefficiënt is. Met een nieuw systeem kan het risk-analysis team efficiënter en beter te werk gaan.

Vision statement

Met de nieuwe software kan de afdeling Risico-analyse sneller, overzichtelijker en ook netter werken. Het bijhouden van voorstellen wordt gemakkelijker voor de medewerkers, en beter bij te houden voor de directeur.
Het eindproduct heeft de volgende functies:

  • Een medewerker van de afdeling kan nieuwe voorstellen indienen
  • Medewerkers kunnen commentaar leveren op zo'n voorstel.
  • Medewerkers kunnen de status van een voorstel aanpassen
  • Medewerkers krijgen automatische mededelingen over voorstellen die aandacht nodig hebben en beleggingen die niet goed lopen
  • Medewerkers kunnen bij terminatie van een belegging een rapport in de database invoeren.
  • Het systeem controleert of de ingevoerde data correct is zover het dat kan

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% 0% 0% -
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% 0% 0% -
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% 50% 50% -
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: 100% 100% -
Integrated Domain Model Key deliverable Not yet! First draft Complete One for whole project
Status: 50% 50% -
Busines Rules Catalogue Key deliverable Not yet! Partially complete Complete
Status: 100% 100% -
Non-functional Requirements Key deliverable Notes Partially complete Complete
Status: 50% 50% 50% -

Risk analysis

# Category Risk Solution needed by Status Expectancy factor Risk factor
01 Planning Te kort voor de deadline beginnen Onmiddelijk Closed 45% 2
02 Fysieke Gezondheid Groepslid loopt fysiek letsel op en is niet meer in staat om te werken Onmiddelijk Closed 30% 3
03 Mentale Gezondheid Groepslid ziet het niet meer zitten Onmiddelijk Closed 25% 3
04 Groepsleden Groepslid houdt op, werkt niet mee Onmiddelijk Closed 25% 4
05 Communicatie Miscommunicatie tussen groepsleden (kan leiden tot 01, 03 en 06) Onmiddelijk Closed 30% 3
06 Groepsleden Conflict tussen groepsleden (kan leiden tot 02 en 03) Onmiddelijk Closed 20% 4
07 Werkplaats Problemen met het gebruik van de electronische werkplaats (kan leiden tot 08) Onmiddelijk Closed 99% 2
08 Dataverlies Verlies van data Onmiddelijk Closed 10% 5

Requirements

Use cases

Use case survey

# Name Description Initiating actor
01 Beleggingsvoorstel invoeren Een medewerker voert een beleggingsvoorstel in. Medewerker
02 Beoordeel voorstel Gebruiker beoordeelt beleggingsvoorstel Medewerker, Directeur
03 Inloggen Een gebruiker authenticeerd zich tegenover het systeem Medewerker, Directeur
04 Termineren voorstel Gebruiker termineert een geïmplementeerd voorstel. Medewerker, Directeur
05 Maandelijkse check-up Medewerker controleert de status van een geïmplementeerd voorstel. Medewerker

Integrated use case diagram

UC usecase.png

Individual use cases

Use case 1: Beleggingsvoorstel invoeren (Jan Martens)

Use Case: Beleggingsvoorstel invoeren
Beschrijving Een medewerker voert een beleggingsvoorstel in.
Actoren Medewerker
Versie 1
Basic course of events
  1. Medewerk geeft aan een voorstel te willen invoeren. (Trigger)
  2. Het systeem vraagt de gegevens van het voorstel.
  3. De medewerker geeft de gegevens van het voorstel.
  4. Het systeem vraagt om een verwachte cashflow tegen de tijd.
  5. De medewerker vult een cashflow in.
  6. Het systeem laat het investeringsvoorstel ter bevestiging zien.
  7. De medewerker bevestigt het voorstel.
Alternate paths

7. De medewerker geeft aan dat er iets niet klopt.

8. Het systeem vraagt of de medewerker iets wil bewerken of de use case wil termineren.

9. De medewerker geeft aan dat hij iets wil bewerken( ga verder met stap 2 ) of termineert de use-case.

Exception paths

3. De medewerker vult foute data in.
4. Het systeem geeft een foutmelding en herhaalt stap 2.

Assumptie De Medewerker is bevoegd voorstellen in te vullen.
Preconditions De Medewerker is ingelogd.
Postconditions

Er is een voorstel ingediend in het systeem.

Related business rules
Domain Model Orm usecase1.png

Use case 2: Beoordeel voorstel (Nick Tönissen)

Use Case: Beoordeel voorstel
Beschrijving Gebruiker beoordeelt beleggingsvoorstel
Actoren Medewerker

Directeur

Versie 1.1
Basic course of events
  1. De gebruiker geeft aan een voorstel te willen beoordelen. (Trigger)
  2. Het systeem geeft een lijst met de te beoordelen voorstellen.
  3. De gebruiker geeft aan welk van deze voorstellen hij wilt beoordelen.
  4. Het systeem opent het gekozen voorstel en laat deze aan de actor zien.
  5. De gebruiker geeft bevestiging voor het bewerken van dit voorstel.
  6. Het systeem vraag de medewerker een opmerking toe te voegen.
  7. De gebruiker typt een opmerking in het, door het systeem aangegeven, kader.
  8. Het systeem vraagt de gebruiker om een status toe te voegen aan het voorstel.
  9. De gebruiker vult een status in.
  10. Het systeem geeft als melding dat het voorstel bijgewerkt is.
Alternate paths -
Exception paths

10. Het systeem geeft als melding dat de ingevoerde status niet geldig is.<br\> 11. Terug naar 8.

Assumptie De gebruiker is bevoegd voorstellen te beoordelen.
Preconditions De gebruiker is ingelogd.
Postconditions

Er is een voorstel beoordeeld met een opmerkingen (optioneel voor de directeur)<br\> en er is een status aangegeven.

Related business rules 03
Domain Model UC ORM-schema Beoordeel voorstel.png

Use case 3: Inloggen (Arjen Theunis)

Use Case: Inloggen
Beschrijving Een gebruiker authenticeerd zich tegenover het systeem
Actoren Medewerker, Directeur
Versie 1.8
Basic Course of Events
  1. Gebruiker geeft aan in te willen loggen. (Trigger)
  2. Systeem geeft inlogscherm weer.
  3. Gebruiker vult zijn inloggegevens in.
  4. Systeem geeft een melding dat het inloggen is gelukt.
Alternate paths 3a. Gebruiker geeft aan niet meer in te willen inloggen.
Exception paths

3b1. Gebruiker vult verkeerde username wachtwoord koppel in.

3b2. Systeem geeft melding dat het inloggen is mislukt.

3b3. Terug naar stap 2.

Assumptie ---
Preconditions

Er is een verbinding met de server.

De Gebruiker is niet al ingelogd.

Postconditions De Gebruiker is ingelogd op het systeem.
Related business rules 01
Domain Model CaptureInloggen.PNG

Use case 4: Termineren voorstel (Willem Boumans)

Use Case: Termineren voorstel
Beschrijving Gebruiker termineert een geïmplementeerd voorstel.
Actoren Medewerker, Directeur
Versie 3.14
Basic course of events
  1. Een gebruiker geeft aan dat hij een voorstel wil termineren. (Trigger)
  2. Het systeem laat het voorstel zien.
  3. Een gebruiker beoordeelt of hij het voorstel definitief wil termineren.
  4. Het systeem vraagt om een bevestiging van terminatie.
  5. Een gebruiker bevestigt de terminatie.
  6. Het systeem vraagt om commentaar.
  7. Een gebruiker voegt commentaar toe.
  8. Het voorstel is getermineerd.
Alternate paths

5. Een gebruiker annuleert de terminatie.

Exception paths -
Assumptie De gebruiker is bevoegd om voorstellen te termineren, en doet dit alleen wanneer het nodig is.
Preconditions Gebruiker die een voorstel wil termineren, is ingelogd op het systeem.
Postconditions Het voorstel is getermineerd, of het termineren is geannuleerd.
Related business rules
Domain Model UC ORM-schema Termineren voorstel.png

Use case 5: Maandelijkse checkup (Wietse Kuipers)

Use Case: Maandelijkse checkup
Beschrijving Medewerker controleert de status van een geïmplementeerd voorstel.
Actoren Medewerker
Versie 1.2
Trigger Het systeem geeft aan dat een voorstel een maandelijkse checkup nodig heeft.
Basic course of events
  1. De medewerker vraagt de betreffende belegging op
  2. Het systeem geeft de gebruiker die belegging
  3. De medewerker analyseert de belegging en voegt commentaar toe
  4. Het systeem slaat het commentaar op en voegt de datum hieraan toe. Bij het voorstel is nu aangegeven dat het deze maand is gecheckt
Alternate path: Medewerker verandert de status 3. Gebruiker gaat naar use case 2, vanaf stap 4 met het het huidige voorstel.
Alternate path: Medewerker termineert het voorstel 3. Gebruiker gaat naar use case 4, met het huidige voorstel
Exception paths -
Preconditions Gebruiker is ingelogd.
Postconditions Commentaar is toegevoegd; als dit gewenst is, is de status ook veranderd.
Related business rules 02
Domain Model Groep2ORMUC5.jpg

Scenarios

Scenario 1 – Belegginsvoorstel invoeren

  1. Piet Janssen drukt op een knop in het programma dat aangeeft "beleggingsvoorstel indienen".
  2. Het systeem toont Piet een formulier voor de gegevens van het beleggingsvoorstel.
  3. Piet vult de naam van het beleggingsvoorstel in
    [Mijn miner
    Mijn miner is een bedrijf in de verkoop van miners .. etc
    10,000.- euro
    10/4/2014].
  4. Het systeem toont een formulier voor de cashflow.
  5. Piet vult een verwachte cashflow in

[ 10/5/2014 , 10,100.-
10/6/2014 , 10,210.-
10/7/2014 , 10,340.-
10/8/2014 , 10,500.-
].

  1. Het systeem laat piet een overzicht zien van de ingevulde gegevens.
  2. Piet bevestigd het voorstel.

Scenario 1.1 – Belegginsvoorstel invoeren alternative path

  1. Piet Janssen ziet bij het bevestigen dat er een spelfout zit in de beschrijving.
  2. Het systeem toont Piet het formulier met de gegevens.
  3. Piet fixt de fout.

Scenario 1.2 – Belegginsvoorstel invoeren exception path

  1. Piet Janssen vult in bij datum 10/4/2013.
  2. Het systeem laat zien dat piet een fout heeft gemaakt en de datum incorrect is.
  3. Piet vult een goeie datum in.


Scenario 2.1 - Voorstel beoordelen

  1. Klaas Janssen geeft aan een voorstel te willen beoordelen.
  2. Het systeem geeft een lijst met de te beoordelen voorstellen.
  3. Klaas Janssen geeft aan "Mijn miner" te willen beoordelen.
  4. Het systeem opent "Mijn miner" en laat deze aan Klaas Janssen zien.
  5. Klaas Janssen geeft bevestiging voor het bewerken van "Mijn miner".
  6. Het systeem vraagt Klaas Janssen een opmerking toe te voegen.
  7. Klaas Janssen typt "Lijkt me een bedrijf met kansen" in het, door systeem aangegeven, kader.
  8. Het systeem vraagt Klaas Janssen om een status toe te voegen aan het voorstel.
  9. Klaas Janssen vult in "Approved pending implementation".
  10. Het systeem geeft als melding dat het voorstel bijgewerkt is.


Scenario 2.2 - Voorstel beoordelen with exception path

  1. Klaas Janssen geeft aan een voorstel te willen beoordelen.
  2. Het systeem geeft een lijst met de te beoordelen voorstellen.
  3. Klaas Janssen geeft aan "Mijn miner" te willen beoordelen.
  4. Het systeem opent "Mijn miner" en laat deze aan Klaas Janssen zien.
  5. Klaas Janssen geeft bevestiging voor het bewerken van "Mijn miner".
  6. Het systeem vraagt Klaas Janssen een opmerking toe te voegen.
  7. Klaas Janssen typt "Lijkt me een bedrijf met kansen" in het, door systeem aangegeven, kader.
  8. Het systeem vraagt Klaas Janssen om een status toe te voegen aan het voorstel.
  9. Klaas Janssen vult in "Approved".
  10. Het systeem geeft als melding dat de status "Approved" niet geldig is.
  11. Het systeem vraagt Klaas Janssen om een status toe te voegen aan het voorstel.
  12. Klaas Janssen vult in "Approved pending implementation".
  13. Het systeem geeft als melding dat het voorstel bijgewerkt is.


Scenario 3.1 - Inloggen

  1. Jan Janssen geeft aan in te willen loggen.
  2. Het systeem geeft een inlogscherm weer.
  3. Jan Janssen vult "Jan Janssen" en "Pr0d@dm1n" in.
  4. Het systeem geeft een melding dat het inloggen is gelukt.


Scenario 3.2 - Inloggen - Alternative Path

  1. Jan Janssen geeft aan in te willen loggen.
  2. Het systeem geeft een inlogscherm weer.
  3. Jan Janssen geeft aan niet meer in te willen loggen.


Scenario 3.3 - Inloggen - Exception Path

  1. Jan Janssen geeft aan in te willen loggen.
  2. Het systeem geeft een inlogscherm weer.
  3. Jan Janssen vult "JanJassen" en "Proadmin" in.
  4. Het systeem geeft aan dat het inloggen is mislukt.
  5. Het systeem geeft een inlogscherm weer.
  6. Jan Janssen vult "Jan Janssen" en "Pr0d@dm1n" in.
  7. Het systeem geeft een melding dat het inloggen is gelukt.


Scenario 4 - Voorstel termineren

  1. Theo Janssen voert de gegevens van een voorstel in, en klikt op de knop "termineren".
    "Mijn miner, 2014, Oss"
  2. Het systeem laat een overzicht van het voorstel zien.
  3. Theo Janssen klikt op de knop "termineer".
  4. Theo Janssen drukt op "Ik weet het zeker".
  5. Het systeem geeft een formulier voor commentaar.
  6. Theo Janssen geeft commentaar in.
    "Mijn miner is financieel geen gezond bedrijf, en daarom moet PGGM hier geen geld in investeren."


Scenario 4.1 - Voorstel termineren

  1. Theo Janssen voert de gegevens van een voorstel in, en klikt op de knop "termineren".
    "Mijn miner, 2014, Oss"
  2. Het systeem laat een overzicht van het voorstel zien.
  3. Theo Janssen klikt op de knop "termineer".
  4. Theo Janssen drukt op "annuleren".
  5. Het systeem geeft de melding "Voorstel niet getermineerd" en gaat terug naar het hoofdmenu.


Scenario 5 - Maandelijkse checkup

  1. Henk de Jager krijgt een melding dat het voorstel Maatwerk Media BV gecontroleerd mot worden.
  2. Henk vraagt in het systeem dit voorstel op.
  3. Henk controleert het voorstel, en oordeelt dat het geen goede investering is.
  4. Henk geeft status 4(Rejected) mee en geeft als commentaar mee "Niet rendabel genoeg".
  5. Het systeem voert dit in het systeem in, en zet de datum erbij. Ook wordt aangegeven dat dit voorstel deze maand niet meer gecontroleerd hoeft te worden


Non-functional Requirements

Beschikbaarheid
Tijdens kantooruren moet het systeem beschikbaar zijn. Na kantooruren mag er onderhoud aan het systeem worden gepleegd.
Beveiliging
Alle informatie die in de database staat moet zijn versleuteld met blowfish.
Van wachtwoorden worden alleen de SHA-512 hashes met salt opgeslagen.
Privacy
Mensen die niet bij PGGM geregistreerd staan als gebruiker mogen geen toegang hebben tot informatie in het systeem.
Snelheid
Als het gehele risk-analyses team tegelijkertijd met het systeem werkt, moet de gevraagde informatie nog steeds binnen 1 seconde beschikbaar zijn.
Exporteerbaarheid
De datasets van beleggingsvoorstellen moeten kunnen worden geexporteerd naar word.
Compabiliteit
Het systeem hoeft alleen maar te kunnen draaien onder Windows 7.

Addendum

Integrated Domainmodel

Integrated domain.png

Business Rules Catalogue

onderschrift
No. Betekenis in natuurlijke taal Regeltype Statisch/Dynamisch Bron
01 Elke gebruiker heeft Inloggegevens. Structural fact Statisch Interview
02 Aan het begin van elke maand wordt van elk voorstel aangegeven dat het nog niet gecheckt is. Structural fact Statisch Ontwerp van het systeem
03 Als de ingelogde gebruiker de directeurs is dan mag stap 6 overgeslagen worden. Structural fact Statisch Client-case

Terminological Definitions

Gebruiker
Een medewerker of de directeur
Risico-analist
Een medewerker van de afdeling risicoanalyse van PGGM
Inloggegevens
Gebruikersnaam en wachtwoord
Overgenomen van "https://lab.cs.ru.nl/algemeen/index.php?title=Requirements_Engineering/het_werk/werkstuk/2013-14/Groep_02&oldid=252784"