Groep 01 NMR Spectrometer (Seaford)

Werkstuk Requirements Engineering

Sander Dorigo, Tim Holweg, Arjan van Dalen

Onderwijsinstituut voor Informatica en Informatiekunde

Radboud Universiteit Nijmegen

version 18 februari 2022

Page Break

Inhoud

1 Introduction
- 1.1 Problem statement
2 Case analysis
3 Requirements
4 Addendum
- 4.1 Business Rules Catalogue
- 4.2 Terminological Definitions

Introduction

Op de Radboud Universiteit in Nijmegen wordt veel gebruik gemaakt van NMR spectrometers. Professoren en onderzoekers gebruiken deze spectrometers om met behulp van magneetvelden en radiosignalen de eigenschappen van moleculen te meten. De gegevens die uit deze metingen voortkomen gebruiken zij in hun onderzoek. Daarnaast maken ook studenten gebruik van een spectrometer om meer ervaring met dit apparaat te krijgen.

Om studenten meer ervaring te laten krijgen in het werken met een spectrometer wil men een simulator van de spectrometer hebben. De reden hierachter is dat er niet altijd voldoende tijd is om studenten met de spectrometer bekend te laten raken. Het apparaat moet van te voren gereserveerd worden, en de tijd is schaars. Studenten kunnen dus niet zomaar een test uitvoeren, maar moeten dit zorgvuldig van te voren plannen en opzetten. Omdat daar veel kennis voor nodig is, gaat de didactische waarde van de spectrometer achteruit. In andere woorden, het is nu zo dat een student, om goed te kunnen meten met de spectrometer, een docent nodig heeft die alles voordoet zodat waardevolle tijd niet verloren gaat. Uiteraard alleen als deze student geen ervaring heeft. Het voordoen kost veel tijd, geld en energie, en bovendien kunnen reguliere gebruikers van de spectrometer daardoor in tijdnood raken. Daarnaast wil men nog niet dat iedereen direct met de spectrometer aan het werk gaat zonder enige ervaring.

Voor het gebruik van een spectrometer is dus veel inhoudelijke kennis nodig. Om eerstejaars studenten van scheikunde (SK) en Moleculaire Levenswetenschappen (MLW) toch de mogelijkheid te geven om te leren werken met een spectrometer is besloten om een virtuele spectrometer te realiseren. Hiervoor is eerder al een prototype simulator ontwikkeld. Deze simulator is realistisch in gebruik, maar is geen goede oplossing voor onderwijsgebruik. Alternatieven zijn onderzocht maar voldoen niet aan de eisen. Bovendien zijn deze oplossingen erg duur. Het is echter wel zo, dat dankzij dit prototype bepaald kon worden dat het maken van een goede simulator mogelijk is.

Het doel is om een nieuwe simulator te ontwerpen. Hierbij is het van belang om te voldoen aan de eisen die gesteld worden door de professoren en onderzoekers, maar ook om zelf enige punten aan te dragen. Uiteindelijk moet de spectrometer een exacte kopie zijn van de layout van een echte spectrometer.

In dit document analyseren we eerst het probleem en de al aangedragen oplossing. Daarna gaan we verder met de requirements, de use cases en de scenario's om op die manier een helder beeld te kunnen geven van ons plan.

Problem statement

In 2007 is een prototype ontwikkeld waarmee studenten vanaf een PC een puls acquisitie onderzoek op een spectrometer kunnen opzetten. Op deze manier wordt ze aangeleerd hoe ze om moeten gaan met een echte spectrometer.

Hiermee worden drie problemen opgelost:

Studenten kunnen geen onbedoelde schade veroorzaken aan de spectrometer;
Er zijn geen extra aanschafkosten mee gemoeid;
Er wordt geen tijd ingenomen van onderzoekers en promovendi.

Het prototype is in 2007 succesvol gebruikt tijdens de colleges. In 2008 is er een verbeterde versie in gebruik genomen.

Dit prototype is nooit goed uitgewerkt. De ontwikkelaars achter het huidige prototype zijn simpelweg begonnen aan de ontwikkeling van een virtuele spectrometer. Hierdoor heeft de applicatie nog de nodige gebreken. Mede door het gebruik van een concreet prototype zijn er veel nieuwe wensen ontstaan. Die hebben geleid tot de beslissing om een nieuwe nieuwe virtuele spectrometer uit te gaan werken.

Case analysis

Stakeholder analysis

Naam	Functie	E-mail	Kamer
Dirk van der Linden	Projectleider en primair aanspreekpunt	Dirk.vanderLinden@cs.ru.nl	HG00.112
Stijn Hoppenbrouwers	Docent Requirements Engineering	stijnh@cs.kun.nl
Laurens Peters	Collega van Dirk van der Linden	Lcjm.Peters@gmail.com
Erik Arends	Collega van Dirk van der Linden
Marco Tessari	Docent	tessari@nmr.ru.nl	HG03.334
Marinus van Herpen	Docent	Marinus.vanHerpen@science.ru.nl	HG00.112

Actors

Student
Onderzoeker
Instructeur
Beheerder

Mission and vision statement

Mission

Door middel van interviews en onderzoek zal een duidelijk beeld ontstaan van de eisen die gesteld worden aan de NMR spectrometer simulator om zo kwalitatief goede requirements af te kunnen leveren voor een zo realistisch mogelijke simulator.

Vision

Het eindproduct van dit project zijn duidelijke requirements waarmee een spectrometer simulator gebouwd kan worden die voldoet aan de eisen van de gebruikers en de stakeholders en waarmee een realistische spectrometer gesimuleerd kan worden.

Statement of work

Deliverable	Status in facade iteratie		Status in filled iteratie		Status in focused iteratie
		Onze status		Onze status		Onze status
Introduction	Preliminary version		Preliminary version		Complete
Problem statement	As good as possible		As good as possible		Complete
Stakeholder analysis	As good as possible		As good as possible		Complete
Mission-vision-values	Complete		Complete		Complete
Statement of work	Complete, and up-to-date		Complete, and up-to-date		Complete, and up-to-date
Risk analysis	Complete, and up-to-date		Complete, and up-to-date		Complete, and up-to-date
Use case survery	As good as possible		Nearly complete		Complete
Use case diagram(s)	As good as possible		Nearly complete		Complete
Integrated UC diagram	Complete (though preliminary)		Complete		Complete
Use cases	Not yet!		"Filled" level		Complete
Scenarios	Not yet!		Several for each UC	One for each UC	Complete ("focused" level)
Domain models	Not yet!		Partially complete		Complete
Integrated domain model	Not yet!		Partially complete		Complete
Business rules catalogue	Not yet!		Partially complete	Partially complete	Complete
Non-functional requirements	Notes		Partially complete		Complete
Terminological definitions	Notes		Partially complete		Complete
Executive sponsor viewpoint	Complete (integrated in M-V-V!)		Complete (integrated in M-V-V!)		Complete (integrated in M-V-V!)
Use case tests	Notes		As good as possible		Complete
Business process definitions	If available / relevant		If relevant		If relevant
GUI metaphors / storyboards	If relevant		If relevant		If relevant

Risk analysis

#	Category	Risk	Solution needed by	Status	Days lost	Expectancy factor	Risk factor
1	Tijd	Uitval projectmedewerkers	Scope aanpassen	-	Meer dan 12 projecturen	Laag	Gemiddeld
2	Informatie	Een stakeholder wordt ziek / is onbereikbaar voor lange tijd	Scope aanpassen	-	Meer dan 10 projecturen	Gemiddeld	Hoog
3	Gegevens	Verlies gegevens	Regelmatig een backup maken van de projectdata	-	Ongeveer 80 projecturen	Laag	Hoog
4	Informatie	Onvoldoende kennis over Requirements Engineering	Tijdig aangeven bij RE docent	-	Meer dan 10 projecturen	Laag	Laag
5	Tijd	Het project kost meer tijd dan verwacht	Scope aanpassen	-	Meer dan 10 projecturen	Gemiddeld	Laag

Requirements

Use cases

Use case survey

#	Naam	Initiator	Beschrijving	Compleetheid	Maturity	Afhankelijkheden	Bronnen	Commentaar
01	Creëer meting	Gebruiker, Instructeur	Het creëren van een meeting (instellen/opslaan van operationele instellingen)	Compleet	Zeer volwassen	-	-	-
02	Monster beheren	Gebruiker, Instructeur	Het maken en beheren van een monsters doormiddel van moleculen en oplosmiddel.	Compleet	Zeer volwassen	-	-	-
03	Moleculen beheren	Gebruiker, Instructeur	Het creëren en wijzigen van moleculen.	Compleet	Zeer volwassen	-	-	-
04	Start meting	Gebruiker, Instructeur	Het starten van een meting.	Compleet	Zeer volwassen	-	-	-
05	Analyseer meting	Gebruiker, Instructeur	Het analyseren van een meting.	Compleet	Zeer volwassen	-	-	-
06	Inloggen gebruiker	Gebruiker, Instructeur, Administrator	Het inloggen in het systeem.	Compleet	Zeer volwassen	-	-	-
07	Selecteer monster	Gebruiker, Instructeur	Het selecteren van een monster.	Compleet	Zeer volwassen	-	-	-
08	Beheer gebruiker	Administrator	Het aanmaken / verwijderen / wijzigen van een nieuwe gebruiker / rol in het systeem.	Compleet	Zeer volwassen	-	-	-
09	Monster toekennen	Instructeur	Het toekennen van een monster aan een onderzoek.	Compleet	Zeer volwassen	-	-	-

Voor 'Compleetheid' en 'Maturity' gelden de volgende terminologie, van sterk naar zwak:

Zeer volwassen
Volwassen
Bijna volwassen
Niet volwassen

Compleet
Praktisch compleet
Bijna compleet
Niet compleet

Integrated use case diagram

Individual use cases

Creëer meting

Use Case:	Creëer meting
Use case diagram
Versie / Iteratie	1.0, focused
Beschrijving	Deze use case beschrijft de interactie tussen de actoren en het systeem, die plaats vinden bij het creëren van een meting.
Basic course of events	1. De gebruiker selecteert een monster. 2. De gebruiker stelt de NMR-spectrometer in. 3. Het systeem berekent de kosten om een meting met de gekozen instellingen uit te voeren.
Alternative paths	3 / A5. Het budget is niet toereikend voor de meting. A1. Het systeem geeft aan dat het budget niet toereikend is voor de meting. A2. Het systeem toont de instellingen en de parameters. A3. De gebruiker wijzigt de door hem geselecteerde parameter(s). A4. Het systeem slaat de wijzigingen op. A5. Het systeem berekent de kosten van gemaakte instellingen en verrekent dit met het budget.
Exception paths
Extension points
Triggers	De gebruiker creëert een meting.
Assumptions
Preconditions	1. De gebruiker is ingelogd. 2. De gebruiker heeft een budget om de meting uit te voeren toegewezen gekregen. 3. De gebruiker heeft een monster toegewezen gekregen (Alleen bij studenten).
Postconditions	Postconditions: Basic course of events 1. De gebruiker heeft een meting gecreëert. 2. Het systeem heeft de kosten van de meting verrekend met het toegewezen budget. 3. De meting is opgeslagen. Postconditions: "3 / A5. Het budget is niet toereikend voor de meting." (Alternative path) 1. Het systeem heeft wijzigingen verwerkt. 2. Het systeem heeft de kosten van de wijzigingen verrekent met het budget.
Related business rules
Schrijver(s)	Arjan van Dalen, Tim Holweg, Sander Dorigo
Data	Aangemaakt: 6 november 2008 Laatst gewijzigd: 4 januari 2009
ORM Model

Monster beheren

Use Case:	Monster beheren
Use case diagram
Versie / Iteratie	1.0, focused
Beschrijving	Deze use case beschrijft de interactie tussen de actoren en het systeem, die plaats vinden bij het maken, verwijderen of wijzigen van een monster.
Basic course of events	1. De gebruiker maakt een nieuw monster aan. 2. Het systeem vraagt om een naam voor het nieuwe monster. 3. De gebruiker geeft het monster een naam. 4. Het systeem vraagt om de moleculen uit het moleculenmodel te selecteren. 5. De gebruiker selecteert de gewenste moleculen. 6. Het systeem vraagt om de concentraties van de gekozen moleculen in te stellen. 7. De gebruiker stelt de concentraties van het gekozen molecuul in. 8. Het systeem vraagt om een oplosmiddel toe te voegen aan het monster. 9. De gebruiker selecteert een oplosmiddel. 10. Het systeem slaat het monster op.
Alternative paths	1. Monster wijzigen. A1. De gebruiker wijzigt een monster. A2. Het systeem geeft overzicht van al bestaande monsters. A3. De gebruiker selecteert een monster. A4. Het systeem toont de instellingen van het geselecteerde monster. A5. De gebruiker wijzigt de instellingen van het monster. A6. Het systeem slaat de wijzigingen op. 1. Monster verwijderen. B1. De gebruiker verwijdert een monster B2. Het systeem geeft overzicht van monsters. B3. De gebruiker selecteert een monster. B4. Het systeem verwijdert het monster. B3. Selecteer een monster C1. Als het monster op dit moment in een meting wordt gebruikt, kan het monster niet verwijderd worden. Het systeem geeft een foutmelding en geeft de gebruiker de mogelijkheid om een ander monster te kiezen.
Exception paths
Extension points
Triggers	De gebruiker maakt, wijzigt of verwijdert een (nieuw) monster.
Assumptions
Preconditions	1. De gebruiker is ingelogd.
Postconditions	Postconditions: Basic course of events 1. Er is een monster aangemaakt. Postconditions: "1. Monster wijzigen." (Alternative path) 1. Er is een monster gewijzigd. Postconditions: "1. Monster verwijderen." (Alternative path) 1. Er is een monster verwijderd.
Related business rules
Schrijver(s)	Arjan van Dalen, Tim Holweg, Sander Dorigo
Data	Aangemaakt: 6 november 2008 Laatst gewijzigd: 4 januari 2009
ORM Model

Moleculen beheren

Use Case:	Moleculen beheren
Use case diagram
Versie / Iteratie	1.0, focused
Beschrijving	Het creëeren van nieuwe moleculen en het beheren van bestaande moleculen
Basic course of events	1. De gebruiker creëert een nieuw molecuul. 2. De gebruiker vult de gegevens van/over het molecuul in. 3. Het systeem slaat het nieuwe molecuul op.
Alternative paths	1. De gebruiker wijzigt een bestaand molecuul. A1. De gebruiker kiest het te wijzigen molecuul. A2. Het systeem opent het gekozen molecuul. A3. De gebruiker vult zijn wijzigingen in. A4. Het systeem slaat de wijzigingen op. 1. De gebruiker verwijdert een bestaand molecuul. B1. De gebruiker kiest het molecuul. B2. Het systeem verwijdert het molecuul.
Exception paths
Extension points
Triggers	De gebruiker maakt, wijzigt of verwijdert een (nieuw) molecuul.
Assumptions
Preconditions	1. De gebruiker is ingelogd.
Postconditions	Postconditions: Basic course of events 1. Er is een molecuul aangemaakt. Postconditions: "1. Molecuul wijzigen." (Alternative path) 1. Er is een molecuul gewijzigd. Postconditions: "1. Molecuul verwijderen." (Alternative path) 1. Er is een molecuul verwijderd.
Related business rules	Alle business rules
Schrijver(s)	Arjan van Dalen, Tim Holweg, Sander Dorigo
Data	Aangemaakt: 6 november 2008 Laatst gewijzigd: 4 januari 2009
ORM Model

Start meting

Use Case:	Start meting
Use case diagram
Versie / Iteratie	1.0, focused
Beschrijving	Deze use case beschrijft de interactie tussen de actoren en het systeem die plaats vinden als een actor een meting start.
Basic course of events	1. De gebruiker kiest een meting. 2. Het systeem berekent het FID signaal. 3. Het systeem geeft aan dat de meting is voltooid.
Alternative paths
Exception paths
Extension points
Triggers	De gebruiker start een meting.
Assumptions
Preconditions	1. De gebruiker heeft een meting toegekend gekregen of zelf een meting gecreëerd. 2. De gebruiker is ingelogd. 3. De gebruiker heeft voldoende budget om de meting uit te voeren.
Postconditions	Postconditions: Basic course of events 1. De meting is gestart.
Related business rules	1. Gebruiker krijgt een budget toegewezen waarmee de meting mee moet worden uitgevoerd.
Schrijver(s)	Arjan van Dalen, Tim Holweg, Sander Dorigo
Data	Aangemaakt: 6 november 2008 Laatst gewijzigd: 4 januari 2009
ORM Model

Analyseer meting

Use Case:	Analyseer meting
Use case diagram
Versie / Iteratie	1.0, focused
Beschrijving	Deze use case beschrijft de interactie tussen de actoren en het systeem die plaats vinden bij het analyseren van een meting.
Basic course of events	1. De gebruiker selecteert de meting die geanalyseerd moet worden. 2. Het systeem toont de standaardweergave van de meting. 3. Het systeem geeft de mogelijkheid tot het wijzigen van de analyseparameters en/of de weergaveopties. 4. De gebruiker geeft de instellingen op. 5. Het systeem geeft de meting weer met de gekozen parameters en weergave opties.
Alternative paths
Exception paths
Extension points
Triggers	De gebruiker analyseert een meting.
Assumptions
Preconditions	1. De use case "start meting" is succesvol voltooid voor de gekozen meting. 2. De gebruiker is ingelogd.
Postconditions	Postconditions: Basic course of events 1. De analyse wordt weergegeven.
Related business rules
Schrijver(s)	Arjan van Dalen, Tim Holweg, Sander Dorigo
Data	Aangemaakt: 6 november 2008 Laatst gewijzigd: 4 januari 2009
ORM Model

Inloggen gebruiker

Use Case:	Inloggen gebruiker
Use case diagram
Versie / Iteratie	1.0, focused
Beschrijving	Deze use case beschrijft de interactie tussen de actoren en het systeem, die plaats vinden bij het inloggen op het systeem.
Basic course of events	1. De gebruiker start de applicatie. 2. Het systeem (Applicatie) vraagt om een gebruikersnaam en het bijbehorende wachtwoord. 3. De gebruiker voert zijn gebruikersnaam en wachtwoord in. 4. Het systeem controleert de gebruikersnaam en het wachtwoord van de gebruiker. 5. Het systeem kent de juiste rechten toe aan de hand van de gebruikersgroep van de gebruiker.
Alternative paths
Exception paths	4. De gebruiker voert verkeerde inloggegevens in A1. Het systeem geeft melding dat gebruikersnaam en het wachtwoord niet geldig zijn. A2. Het systeem vraagt om de juiste inloggegevens.
Extension points
Triggers	De gebruiker heeft de applicatie gestart.
Assumptions
Preconditions
Postconditions	Postconditions: Basic course of events 1. Gebruiker is ingelogd met juiste rechten.
Related business rules	1. Een gebruiker moet geauthenticeerd zijn om gebruik te mogen maken van de NMR spectrometer.
Schrijver(s)	Arjan van Dalen, Tim Holweg, Sander Dorigo
Data	Aangemaakt: 6 november 2008 Laatst gewijzigd: 4 januari 2009
ORM Model

Selecteer monster

Use Case:	Selecteer monster
Use case diagram
Versie / Iteratie	1.0, focused
Beschrijving	Deze use case beschrijft de interactie tussen de actoren en het systeem die plaats vinden bij het selecteren van een monster.
Basic course of events	1. De gebruiker selecteert een monster. 2. Het systeem geeft aan dat het monster klaar staat voor de meting.
Alternative paths
Exception paths
Extension points
Triggers	De gebruiker selecteert een monster.
Assumptions
Preconditions	1. De gebruiker is ingelogd.
Postconditions	Postconditions: Basic course of events 1. Er is een monster geselecteerd.
Related business rules
Schrijver(s)	Arjan van Dalen, Tim Holweg, Sander Dorigo
Data	Aangemaakt: 6 november 2008 Laatst gewijzigd: 4 januari 2009
ORM Model

Beheer gebruiker

Use Case:	Beheer gebruiker
Use case diagram
Versie / Iteratie	1.0, focused
Beschrijving	Deze use case beschrijft de interactie tussen de actoren en het systeem die plaats vinden bij het beheren van gebruikers.
Basic course of events	1. De gebruiker maakt een nieuwe gebruiker aan. 2. Het systeem geeft de gelegenheid voor het aanmaken van een gebruiker. 3. De gebruiker vult alle gevraagde gegevens in en voert de nieuwe gebruiker in. 4. Het systeem controleert de ingevoerde gegevens. 5. Het systeem slaat de nieuwe gebruiker op.
Alternative paths	1. De gebruiker wijzigt een bestaande gebruiker. A1. Het systeem toont een lijst van bestaande gebruikers. A2. De gebruiker kiest de te wijzigen gebruiker. A3. Het systeem opent de gegevens van de gekozen gebruiker. A4. De gebruiker wijzigt de gegevens van de gebruiker. A5. Het systeem controleert de ingevoerde gegevens. A6. Het systeem slaat de wijzigingen op. 1. De gebruiker verwijdert een bestaande gebruiker. B1. Het systeem toont een lijst met bestaande gebruikers. B2. De gebruiker kiest de te verwijderen gebruiker. B3. Het systeem vraagt de gebruiker om verplaatsing naar archief of verwijdering. B4. De gebruiker kiest voor verwijdering van de gebruiker. B5. Het systeem verwijdert de gekozen gebruiker uit het systeem. 3. De gebruiker kiest voor annuleren. C1. Het systeem annuleert de wijziging(en) en gaat terug naar het menu. 4. Het systeem controleert ingevoerde gegevens. D1. Het systeem geeft melding aan de gebruiker welke gegevens incorrect zijn met daarbij de reden. D2. De gebruiker krijgt mogelijkheid om de gegevens aan te passen. 6. De gebruiker annuleert bevestiging. E1. Het systeem annuleert de wijziging en gaat terug naar het invoerscherm. B3. Het systeem vraagt de gebruiker om verplaatsing naar archief of verwijdering. F1. De gebruiker kiest ervoor om de geselecteerde gebruiker naar het archief te verplaatsen. F2. Het systeem plaatst de gebruiker in het archief.
Exception paths
Extension points
Triggers	De gebruiker maakt, wijzigt of verwijdert een (nieuwe) gebruiker.
Assumptions
Preconditions	1. De gebruiker is ingelogd. 2. De gebruiker is administrator.
Postconditions	Postconditions: Basic course of events 1. De beheerder heeft een nieuwe gebruiker aangemaakt. Postconditions: "1. De gebruiker wijzigt een bestaande gebruiker." (Alternative path) 1. De beheerder heeft een bestaande gebruiker gewijzigd. Postconditions: "1. De gebruiker verwijdert een bestaande gebruiker." (Alternative path) 1. De beheerder heeft een bestaande gebruiker verwijderd uit het systeem. Postconditions: "B3. Het systeem vraagt de gebruiker om verplaatsing naar archief of verwijdering." (Alternative path) 1. De beheerder heeft een bestaande gebruiker gearchiveerd.
Related business rules	Alle business rules
Schrijver(s)	Arjan van Dalen, Tim Holweg, Sander Dorigo
Data	Aangemaakt: 6 november 2008 Laatst gewijzigd: 4 januari 2009
ORM Model

Monster toekennen

Use Case:	Monster toekennen
Use case diagram
Versie / Iteratie	1.0, focused
Beschrijving	Deze use case beschrijft de interactie tussen de actoren en het systeem die plaats vinden bij het toekennen van een monster.
Basic course of events	1. Het systeem toont een overzicht van de door de instructeur aangemaakte monsters. 2. De instructeur selecteert een monster. 3. De instructeur selecteert een of meerderen studenten. 4. De instructeur bepaalt het budget per student. 5. Het systeem kent het monster aan geselecteerde student(en) toe.
Alternative paths
Exception paths
Extension points
Triggers	De gebruiker (instructeur) kent een monster toe aan één of meerdere studenten.
Assumptions
Preconditions	1. De gebruiker moet een instructeur zijn. 2. De gebruiker is ingelogd. 3. De gebruiker moet monsters (minimaal één) aangemaakt hebben.
Postconditions	Postconditions: Basic course of events 1. Het monster is toegekend.
Related business rules
Schrijver(s)	Arjan van Dalen, Tim Holweg, Sander Dorigo
Data	Aangemaakt: 6 november 2008 Laatst gewijzigd: 4 januari 2009
ORM Model

Scenarios