Requirements Engineering/het werk/werkstuk/2008-9/Groep 05 3J
Requirements for hNMR simulation system
Werkstuk Requirements Engineering
Jan Michels, Joost Janssen, Joost Timmerman
Onderwijsinstituut voor Informatica en Informatiekunde
Radboud Universiteit Nijmegen
version 18 februari 2022
Introduction
Several studies at Radboud University make use of hNMR spectrometers. These devices are expensive to acquire. This results in a limited amount of devices which again leads to limited resources which has to be divided among the users. However, for the students it is important to develop skills in using the hNMR. To overcome this problem the university developed a simulation software that is used to do this. However, the software used has several downsides and does not fulfil all requirements. Hence the university has decided to develop a new simulation software. For a thorough software development a proper gathering of requirements is essential. The students of the course 'Requirements Engineering' are taking part in this process and gather the requirements to get a realistic exercise.
Problem statement
Having an entire class practice the use of hNMR is complex and time-consuming because of many students need results from a limited amount of spectrometers and all samples need to be prepared. Also, students usually don't get the change to practice with exotic chemicals because they are to expensive to prepare.
Case analysis
| Stakeholder | Description |
|---|---|
| Dirk van der Linden |
|
| L.C.J.M. Peters |
|
Mission and vision statement
Mission — What the project will do (close to WHY)
hNMR spectrometres are expensive devices. Their usage has to be shared between several groups of users. Due to the limited availability of this equipment is it possible that students do not get enough practice using hNMR. In order to make hNMR training cheaper and more available and thus allow students to experiment more, a simulation will be used. Students can train hNMR techniques using inexpensive simulation so that they will be less likely to make mistakes in a real experiment.
Vision — What the end product will be (close to WHAT)
The end product will be the requirements that are needed to build such a system.
Value — What principles will guide the project members while they do what they do
- Utilitas: purposeful, usefullness, validity, realism
- Firmitas: durability, reliability, strength
- Venustas: amiability, beauty
Statement of work
| Deliverable | facade iteratie | Status | filled iteratie | Status | focused iteratie | 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 survey | 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 | Filled" level | |
Complete |
| ||||
| Scenarios | Several for each UC | |
Complete ("focused" level) |
| ||||
| Domain models | Partially complete | |
Complete |
| ||||
| Integrated domain model | Partially complete | |
Complete |
| ||||
| Business rules catalogue | 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 |
|---|---|---|---|---|---|---|---|
| 01 | Planning | An unexpected decision has to be made | Immediate - Query stakeholders | Unresolved | 4 | 40% | 16 |
| 02 | Stakeholder changes opinion | Immediate | Unresolved | 5 | 80% | 40 |
Requirements
Use cases
Use case survey
| # | Name | Initiating actor | Description | Completeness | Maturity | Source | Comments | |
|---|---|---|---|---|---|---|---|---|
| 01 | Add user | Administrator, Teacher | Actor creates new user | Complete | Filled | Dirk | None | |
| 02 | Modify user | Administrator, Teacher | Actor modifies or deletes an existing user | Complete | Filled | Dirk | None | |
| 03 | Add group | Administrator, Teacher | Actor adds new group | Complete | Filled | Dirk | None | |
| 04 | Modify group | Administrator, Teacher | Actor modifies or deletes a group | Complete | Filled | Dirk | None | |
| 05 | Add molecule | Administrator, Teacher, Scientist | Actor adds molecule to the system | Complete | Filled | L. Peters | None | |
| 06 | Modify molecule | Administrator, Teacher, Scientist | Actor deletes or modifies molecule | Complete | Filled | L. Peters | None | |
| 07 | Add sample | Administrator, Teacher, Scientist | Actor adds sample to system | Complete | Filled | L. Peters | None | |
| 08 | Modify sample | Administrator, Teacher, Scientist | Actor modifies or deletes an existing sample | Complete | Filled | L. Peters | None | |
| 09 | Conduct experiment | Administrator, Teacher, Scientist, Student | Actor conducts an experiment on a sample. | Complete | Filled | L. Peters | None | |
| 10 | Assign experiment | Administrator, Teacher, Scientist | Actor assigns samples to be distributed to the users in a group | Complete | Filled | L. Peters | None |
Integrated use case diagram
Individual use cases
For the sake of overview and improved readability the used cases are available on this page
Scenarios
Individual scenarios
For the sake of overview and improved readability the used cases are available on this page
Integrated domain model
This integrated domain model is a combination of the domain models found at the use-cases page.
Non-functional Requirements
- Scaleability
- Reliability
- Concurrency
- Authentification of users
Addendum
Business Rules Catalogue
| # | Rule definition | Type of rule | Static / dynamic | Source |
|---|---|---|---|---|
| 01 | Students have a limited budget | Action restricting | static | Policy |
| 02 | Students experiments take a realistic amount of time | Structural fact | static | Policy |
| 03 | When a student acts stupid the teacher gets warned | Calculation | dynamic | Policy |
| 04 | Budget is only applicable to users of type student | Restrictive | static | Stakeholders |
| 05 | Users of certain type can only be in groups with users of that type | Restrictive | static | Stakeholders |
| 06 | Actors of type student can only choose experiments that were assigned to them earlier | Restrictive | static | Policy |
| 07 | Actors that are NOT of type student can select any sample that exists in the system as an experiment | Restrictive | static | Policy |
| 08 |
|
Restrictive | static | Stakeholders |
User-(management-)related business rules: During our work on this project we have put a lot of thought into the handling of users and groups. We think that a well thought-out and logical way of user-administration is also a crucial point for good usability.
Terminological Definitions
- Experiment
- An experiment is one analysis of a sample by a student creating a FID.
- Sample
- A solution of at least two molecules of which at least one can be used as a solvent.
