Proton NMR spectroscopie

Werkstuk Requirements Engineering

Eamonn Cassidy, Rob Thijssen, Niek Wolfkamp, Iris Trepels

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 universiteit dient er voor onderzoeks- en onderwijsdoeleinden gebruik gemaakt te worden van een spectroscoop. Dit is een apparaat dat vrij duur is om aan te schaffen en het gebruik hiervan kan aanzienlijk veel tijd in beslag nemen. Hier komt nog bij dat studenten vanalles kapot kunnen maken, omdat zij onbekend zijn met de daadwerkelijke spectroscoop. Nu is het geval dat er steeds meer studenten zijn die moeten leren werken met een spectrometer. Vanwege bovengenoemde factoren bij het gebruik van een spectroscoop zou het niet efficiënt en tevens niet haalbaar zijn om elke student hiermee te laten werken. Daarom is er een simulator van een spectroscoop gemaakt. Dit prototype van de simulator heeft als doel om de werking van de echte spectroscoop zo goed mogelijk na te bootsen.

Behalve studenten zullen ook docenten, wetenschappers en beheerders gebruik maken van deze simulator, welke overigens web-based zal zijn. Het prototype is echter nog niet toereikend en daarom is het doel om een nieuwe simulator te ontwerpen. Deze moet naast het voldoen aan de eisen van alle belanghebbenden ook realistisch werken. Een experiment zal dus de tijd in beslag nemen zoals dat ook bij de echte spectrometer gaat, ditzelfde geldt op het gebied van kosten. De uiteindelijke simulator zal qua werking en gebruik identiek moeten zijn aan een echte spectrometer.

Hier zullen wij allereerst het probleem uitvoerig analyseren en definiëren via problem statement, mission, vision, value. Vervolgens gaan wij in op het verloop van het project, statement of work, risk analysis. Hierna volgen de requirements, o.a. in beschrijvingen maar ook in een model.

Problem statement

Het probleem is dat er veel studenten zijn, die allemaal op een kostbare machine moeten werken om overweg te kunnen met een spectroscoop. Behalve het kostenaspect, speelt ook het tijdsaspect mee: studenten gebruiken tijd om te oefenen, die gebruikt kan worden voor echt onderzoek. Om dat de studenten direct uit een theorievak worden geconfronteerd met een echte situatie doen zij soms "domme" dingen, en de docent heeft daar geen zicht op.

Omdat er geen groot budget is, en omdat de stakeholders op zoek zijn naar een "open" software project, moet er een geheel nieuw computerprogramma komen om de deze studenten te laten oefenen met een gesimuleerde spectroscoop.

Case analysis

Gebruikers

Studenten:

De groep studenten is de grootste groep gebruikers. Deze groep heeft echter ook de minste rechten. De studenten kunnen monsters aanmaken, experimenten uitvoeren, tests analyseren en hun resultaten opslaan. Dit alles is echter in een realistische tijdssetting, en afhankelijk van een vooraf ingesteld budget. Verder kunnen ze hun eigen resultaten en monsters verwijderen.

Docenten:

De groep docenten heeft een aantal meer rechten dan de groep studenten, en is ook kleiner. De docenten kunnen moleculen aanmaken, monsters aanmaken, monsters toewijzen aan studenten, budget instellen en wijzigen, studenten en groepen aanmaken en aanpassen en de resultaten van studenten bijhouden.

Wetenschappers:

De wetenschappers kunnen het systeem gebruiken voor een snelle analyse, in plaats van een daadwerkelijk (duur) experiment uit te voeren. De wetenschappers kunnen moleculen en monsters aanmaken, experimenten uitvoeren, tests analyseren en resultaten opslaan. Dit is echter zonder budgettaire en tijdsgerelateerde beperkingen.

Beheerders:

De beheerders zijn de mensen die alle gegevens van gebruikers en groepen kunnen aanpassen. Zij kunnen gebruikers aanmaken en/of verwijderen, groepen aanmaken, aanpassen en verwijderen, en de database wijzigen.

Stakeholder analysis

Stakeholderlist:

Executive sponsor:
- Dirk van der Linden: Projectleider, sponsor
- LCJM Peters: Collega van Dirk op scheikundig gebied
- Dr. Marco Tessari: Docent
- Erik Arends: Collega van Dirk op natuurkundig gebied

Mission and vision statement

Mission: De voornaamste missie van het project is om de requirements van een Proton NMR spectroscoop - simulator op te stellen. Deze simulator heeft als doel om ervoor te zorgen dat studenten ervaring op kunnen doen en kunnen leren over hoe ze met een spectrometer moeten werken. Hiervoor is een simulator nodig omdat een daadwerkelijke spectrometer erg duur is, en de universiteit er maar een beperkt aantal in haar bezit heeft. Het programma moet ook te gebruiken zijn voor onderzoekers, zonder de tijds- en budget beperkingen die voor studenten wel gelden.

Vision: Het eindproduct zal bestaan uit requirements die een complete beschrijving geven voor het uitprogrammeren van een simulator. De visie van wat deze simulator zal worden is dat het een computerprogramma dat de interactie tussen de gebruiker en de spectrometer simuleert. Er moet een monster geprepareerd kunnen worden door de docent die de studenten dan moeten kunnen analyseren. Zij moeten de instellingen voor de spectrometer kunnen instellen en aanpassen. Vervolgens moet er uit de database voor het monster in kwestie, en de gekozen instellingen, een spectrum berekend worden. De docent moet stap voor stap kunnen zien wat de student allemaal gedaan heeft en wat de resultaten van deze student waren. Er moet ook een bericht naar de docent gestuurd worden als de student “domme” dingen doet met het programma. Onderzoekers moeten ook met deze simulator kunnen werken, zonder dat ze beperkt worden door de “realistische” beperkingen die voor de studenten gelden.

Values: De leden zullen proberen met een oog voor aandacht deze requirements op te stellen. Echter, er is een grote beperking in de hoeveelheid tijd die beschikbaar is voor het project. Daarom zullen er regelmatig keuzes genomen moeten worden mbt wel of niet uitmodelleren van bepaalde functionaliteit. De leden hanteren dus ook een prioriteitsprincipe, de basisfunctionaliteit wordt verkozen boven mooie franjes van minder nut.

Statement of work

Facade iteratie: 27 oktober 9:00 uur
Filled iteratie: 3 december 9:00 uur
Focused iteratie: 5 januari 9:00 uur

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

V = afgerond
X = nog niet aan begonnen
~ = mee bezig
- = nog niet nodig

Risk analysis

#	Category	Risk	Solution needed by	Status	Days lost	Expectancy factor	Risk factor
01	Teamprobleem	Ziek teamlid	meteen		1~5	75%	3.5
02	Teamprobleem	Teamlid mist vergadering	meteen		1 dag	100%	1
03	Teamprobleem	Teamlid stopt met het vak	meteen		~10 dagen	10%	1
04	Opdrachtgeverprobleem	Executive sponsor verandert van gedachten	meteen		5~10	10%	1
05	Opdrachtgeverprobleem	(Gedeelte van) usecases worden afgekeurd	2 dagen	Twee maal	2~5 dagen	20%	1
06	Materiaalprobleem	PC loopt vast	meteen		0.5	50%	0.5
07	Materiaalprobleem	Wiki onbereikbaar	1 dag	meerdere malen gebeurd	1	5%	0.05

Requirements

Use cases

Use case survey

#	Name	Description	Initiating actor
01	Beheren gebruikers	In deze Use Case worden alle mogelijkheden beschreven voor het beheer van de gebruikers, dus het aanmaken/verwijderen van gebruikers, het indelen in groepen en het toekennen van rechten.	Beheerder, Docent
02	Creëren monster	In deze Use Case worden alle mogelijkheden beschreven voor het aanmaken en/of verwijderen van de monsters.	Wetenschapper, Docent, Student
03	FID signaal genereren	In deze use-case laat de gebruiker aan de hand van instellingen een FID signaal genereren.	Student, Docent, Beheerder, Beheerder
04	Fourier Transformatie	In deze use-case laat de gebruiker aan de hand van een eerder opgeslagen FID signaal een Fourier transformatie uitvoeren.	Student, Docent, Beheerder, Beheerder
05	Opgave opstellen	Hier wordt beschreven hoe (de docent) een opgave maakt in het systeem en kan uittesten met het systeem.	Docent
06	Molecuul beheer	Hier wordt beschreven hoe moleculen kunnen worden toegevoegd, gewijzigd en verwijderd.	Wetenschapper, Docent, Beheerder
07	Monster beheer	Hier wordt beschreven hoe monsters kunnen worden gewijzigd en verwijderd.	Wetenschapper, Student, Docent, Beheerder

Integrated use case diagram

Individual use cases

01 Beheren gebruikers

Use Case:	Beheren gebruikers
Iteration:	Focused 0.1
Summary:	In deze Use Case worden alle mogelijkheden beschreven voor het beheer van de gebruikers, dus het aanmaken/verwijderen van gebruikers, het indelen in groepen en het toekennen van rechten.
Basic Course of Events:	Gebruiker wijzigt eigenschappen van een gebruiker: Systeem vraagt gebruiker van welke gebruiker hij de eigenschappen wil bewerken of dat hij een nieuwe gebruiker wil toevoegen. Gebruiker selecteert de gewenste gebruiker. Systeem vraagt gebruiker of hij deze eigenschappen wil wijzigen of verwijderen. Gebruiker selecteert wijzigen. Systeem geeft de eigenschappen van de betreffende gebruiker weer. Gebruiker wijzigt de eigenschappen. Gebruiker geeft aan om de eigenschappen op te slaan. Systeem controleert de eigenschappen. Systeem vraagt om bevestiging Gebruiker geeft aan zeker te weten om de eigenschappen van de betreffende gebruiker op te willen slaan. Systeem slaat alle eigenschappen op.
Alternative Paths:	Gebruiker voegt een gebruiker toe: Systeem vraagt gebruiker van welke gebruiker hij de eigenschappen wil bewerken of dat hij een nieuwe gebruiker wil toevoegen. Gebruiker geeft aan dat hij een nieuwe gebruiker wil toevoegen. Systeem vraagt eigenschappen van de toe te voegen gebruiker. Gebruiker voert de eigenschappen in. Gebruiker geeft aan om de eigenschappen op te slaan. Systeem controleert de eigenschappen. Systeem vraagt om bevestiging. Gebruiker geeft aan zeker te weten om de betreffende gebruiker toe te voegen. Systeem slaat alle eigenschappen op Gebruiker verwijdert een gebruiker: Vanaf stap 3 in BcoE. Gebruiker selecteert verwijderen. Systeem vraagt welke gebruiker hij wil verwijderen. Gebruiker geeft aan welke gebruiker hij wil verwijderen. Systeem vraagt om bevestiging. Gebruiker geeft aan zeker te weten dat hij de betreffende gebruiker wil verwijderen. Systeem verwijderd de betreffende gebruiker. Gebruiker voert onjuiste eigenschappen in voor een gebruiker: Vanaf stap 8 in BcoE. Systeem constateert dat de eigenschappen onjuist zijn
Exception Paths:
Extension Points:
Triggers:	De gebruiker triggert door middel van het gaan beheren (wijzigen/verwijderen/toevoegen) van een gebruiker
Assumptions:	Er staan altijd gebruikers in de database (tenminste 1 beheerder). Het systeem herkent onjuiste eigenschappen
Preconditions:	De gebruiker is gemachtigd/ingelogd om de bewerkingen uit te voeren.
Postconditions:	Eigenschappen van gebruiker gewijzigd Gebruiker toegevoegd Gebruiker verwijderd
Related Business Rules:	Gebruikers mogen geen onjuiste eigenschappen invoeren.
Author:	Niek Wolfkamp
Date:	27-12-2008
ORM:
UC Diagram:

02 Creëren monster

Use Case:	Creëren monster
Iteration:	Focused 0.1
Summary:	In deze use-case maakt een gebruiker een monster aan.
Basic Course of Events:	De gebruiker geeft een naam op voor het monster Systeem geeft lijst met oplosmiddelen in de database weer Gebruiker kiest oplosmiddel en klikt op verder gaan Systeem geeft lijst met scheikundige stoffen in de database weer Gebruiker kiest de scheikundige stoffen Systeem controleert samenstelling op domme fouten Systeem berekent kosten van het monster Gebruiker bevestigt dat hij het monster wil opslaan Systeem slaat monster en kosten op
Alternative Paths:	Gebruiker kiest alleen een oplosmiddel (blanco) Systeem gaat verder met BCoE vanaf het berekenen van kosten
Exception Paths:
Extension Points:	De usecase is uit te breiden door het te koppelen aan een "toevoegen aan database" functie.
Triggers:	De gebruiker triggert door te klikken op "monster aanmaken".
Assumptions:	De gebruiker is geauthorizeerd om monsters aan te maken. In het geval van studenten, moeten zij voldoende balans hebben om het monster te kunnen betalen.
Preconditions:	Er staan oplosmiddelen en scheikundige stoffen in de database.
Postconditions:	Een geldig monster staat opgeslagen, bestaande uit samenstelling van het monster(oplosmiddel, scheikundige stoffen, naam) en kosten.
Related Business Rules:	Studenten mogen geen domme monsters maken Een monster bevat precies een oplosmiddel Een monster bevat geen of meerdere scheikundige stoffen Een monster heeft precies een unieke naam Elk element (in een molecuul) heeft precies een lading
Author:	Rob Thijssen
Date:	3-1-2009
ORM:
UC Diagram:

03 FID signaal genereren

Use Case:	FID signaal genereren
Iteration:	Focused 0.1
Summary:	In deze use-case laat de gebruiker aan de hand van instellingen een FID signaal genereren.
Basic Course of Events:	Systeem begint met loggen van de invoer van de gebruiker. Systeem vraagt gebruiker waardes voor de instellingen in te voeren. Gebruiker voert waardes in. Gebruiker geeft aan een FID signaal te willen genereren. Systeem berekent of het genereren mogelijk is aan de hand van financiële beperkingen Systeem controleert of ingevoerde waardes correct zijn. Systeem geeft voortgangsscherm genereren. Systeem geeft aan klaar te zijn, en toont gegenereerd FID signaal. Gebruiker slaat FID signaal op. Systeem slaat log op.
Alternative Paths:	Vanaf stap 5 in BcoE. Systeem constateert dat het genereren niet mogelijk is vanwege ontoereikende financiën. Systeem slaat log op. Vanaf stap 6 in BcoE. Systeem constateert dat het genereren niet mogelijk is vanwege ‘domme’ waardes. Systeem slaat log op. Vanaf stap 8 in BcoE. Systeem slaat log op.
Exception Paths:
Extension Points:
Triggers:	De gebruiker triggert door aan te geven een FID signaal te willen generen.
Assumptions:	De gebruiker weet wat de instellingen moeten zijn. Het systeem weet wat ‘domme’ waardes zijn.
Preconditions:	De gebruiker is ingelogd.
Postconditions:	Afhankelijk van de gekozen stappen: Een opgeslagen FID signaal De invoer van de gebruiker staat in de log van desbetreffende gebruiker.
Related Business Rules:	Schaal van waardes voor de instellingen (minimum en maximum). Student heeft beperkte financiën. Wetenschapper, docent en beheerder hebben onbeperkte financiën.
Author:	Niek Wolfkamp
Date:	29-12-2008
ORM:
UC Diagram:

04 Fourier Transformatie

Use Case:	Fourier Transformatie
Iteration:	Focused 0.1
Summary:	In deze use-case laat de gebruiker aan de hand van een eerder opgeslagen FID signaal een Fourier transformatie uitvoeren.
Basic Course of Events:	Systeem begint met loggen van de invoer van de gebruiker. Systeem vraagt gebruiker waardes voor de instellingen in te voeren. Gebruiker voert waardes in. Gebruiker geeft aan transformatie uit te willen voeren. Systeem controleert of ingevoerde waardes correct zijn. Systeem geeft voortgangsscherm transformatie. Systeem geeft aan klaar te zijn en toont gegenereerde spectrum. Gebruiker slaat spectrum op. Systeem slaat log op.
Alternative Paths:	Vanaf stap 7 in BcoE. Systeem slaat log op.
Exception Paths:	Systeem begint met loggen van de invoer van de gebruiker. Systeem vraagt gebruiker waardes in te voeren voor instellingen. Gebruiker vult verkeerde waardes in. Gebruiker geeft aan transformatie uit te willen uitvoeren. Systeem berekent of meting mogelijk is aan de hand van geldige waardes. Systeem geeft foutmelding. Systeem slaat log op.
Extension Points:
Triggers:	De gebruiker triggert door aan te geven een Fourier Transformatie te willen maken.
Assumptions:	De gebruiker weet wat de instellingen moeten zijn.
Preconditions:	De gebruiker is ingelogd. De gebruiker heeft een FID signaal beschikbaar.
Postconditions:	Afhankelijk van de gekozen stappen: Een al dan niet opgeslagen spectrum. De invoer van de gebruiker staat in de log van desbetreffende gebruiker.
Related Business Rules:	Schaal van waardes voor de instellingen (minimum en maximum).
Author:	Eamonn Cassidy
Date:	29-12-2008
ORM:
UC Diagram:

05 Opgave opstellen

Use Case:	Opgave opstellen
Iteration:	Filled 0.1
Summary:	In deze use-case wordt beschreven hoe het maken van een opdracht voor de student in zijn werk gaat.
Basic Course of Events:	Het systeem vraagt de gebruiker een monster uit te kiezen uit de database. Gebruiker kiest monster uit de database. Systeem vraagt de gebruiker of er nog meer monsters gebruikt moeten worden. Gebruiker geeft aan dat er geen andere monsters gebruikt worden. Systeem vraagt de gebruiker om studenten toe te wijzen aan het monster, of om zelf in te delen. Gebruiker geeft aan de verdeling door het systeem te laten doen Systeem vraagt de gebruiker om deelnemerslijst. Gebruiker geeft aan welke gebruikers de opdracht moeten maken. Systeem verdeelt de opdracht.
Alternative Paths:	Het systeem vraagt de gebruiker een monster uit te kiezen uit de database. Gebruiker kiest monster uit de database. Systeem vraagt de gebruiker of er nog meer monsters gebruikt moeten worden. Gebruiker geeft aan dat er nog een ander monsters gebruikt wordt. Vanaf stap 5 in BcoE. Gebruiker geeft aan de verdeling te doen. Systeem vraagt de gebruiker om deelnemerslijst. Gebruiker geeft aan welke gebruikers de opdracht moeten maken. Systeem vraagt de gebruiker om aan te geven welke student welke opdracht doet. Gebruiker geeft de opdrachten in.
Exception Paths:
Extension Points:
Triggers:	De gebruiker geeft aan een opdracht te willen opstellen.
Assumptions:
Preconditions:	De gebruiker dient ingelogd te zijn op het systeem als Docent.
Postconditions:	De opdracht is verdeeld over een groep studenten.
Related Business Rules:
Author:	Eamonn Cassidy
Date:	29-11-2008
ORM:
UC Diagram:

06 Molecuul beheer

Use Case:	Molecuul beheer
Iteration:	Focused 0.1
Summary:	In deze use case wordt beschreven hoe moleculen aangemaakt, bewerkt en verwijderd kunnen worden.
Basic Course of Events:	Gebruiker maakt molecuul aan: De gebruiker geeft aan een molecuul te willen aanmaken. Gebruiker geeft de naam van het molecuul. Gebruiker voert de gegevens van het molecuul in. Gebruiker geeft aan het molecuul op te willen slaan. Systeem vraagt om bevestiging. Gebruiker bevestigt. Systeem slaat molecuul op.
Alternative Paths:	Gebruiker bewerkt molecuul: Gebruiker geeft aan een molecuul te willen bewerken. Gebruiker selecteert het te bewerken molecuul. Gebruiker wijzigt de eigenschappen van het molecuul. Gebruiker geeft aan de wijzigingen op te willen slaan. Systeem vraagt om bevestiging. Gebruiker bevestigt. Systeem slaat wijzigingen op. Gebruiker verwijdert molecuul: Gebruiker geeft aan een molecuul te willen verwijderen. Gebruiker selecteert het te verwijderen molecuul. Systeem vraagt om bevestiging. Gebruiker bevestigt. Systeem verwijdert molecuul.
Exception Paths:
Extension Points:
Triggers:	De gebruiker triggert door aan te geven dat hij/zij een moleculen wil beheren.
Assumptions:
Preconditions:	De gebruiker heeft zichzelf geauthenticeerd als beheerder, docent, of wetenschapper.
Postconditions:	Gebruiker maakt molecuul aan: er is een molecuul aangemaakt. Gebruiker wijzigt molecuul: er is een molecuul gewijzigd. Gebruiker verwijdert molecuul: er is een molecuul verwijderd.
Related Business Rules:
Author:	Iris Trepels
Date:	27-12-2008
ORM:
UC Diagram:

07 Monster beheer

Use Case:	Monster beheer
Iteration:	Focused 0.1
Summary:	In deze use case wordt beschreven hoe monsters bewerkt en verwijderd kunnen worden.
Basic Course of Events:	Gebruiker wijzigt monster: Gebruiker geeft aan een monster te willen wijzigen. Gebruiker selecteert het te wijzigen monster. Gebruiker wijzigt de eigenschappen van het monster. Gebruiker geeft aan de wijzigingen op te willen slaan. Systeem vraagt om bevestiging. Gebruiker bevestigt Systeem controleert samenstelling op domme fouten. Systeem berekent de kosten van het monster. Systeem slaat de wijzigingen en de kosten op.
Alternative Paths:	Gebruiker verwijdert monster: Gebruiker geeft aan een monster te willen verwijderen. Gebruiker selecteert het te verwijderen monster. Systeem vraagt om een bevestiging. Gebruiker bevestigt. Systeem verwijdert monster.
Exception Paths:	Gebruiker voert "domme" instellingen in: Gebruiker geeft aan een monster te willen wijzigen. Gebruiker selecteert het te wijzigen monster. Gebruiker geeft "domme" eigenschappen. Gebruiker geeft aan de wijzigingen op te willen slaan. Systeem vraagt om bevestiging. Gebruiker bevestigt. Systeem controleert samenstelling op domme fouten. Systeem geeft foutmelding. Systeem keert terug naar punt 3.
Extension Points:
Triggers:	De gebruiker triggert door aan te geven dat hij/zij een monster wil bewerken.
Assumptions:	Het systeem weet wat "domme" instellingen zijn.
Preconditions:	Er staan oplosmiddelen, moluculen en monsters in de database. Gebruiker heeft zich geauthenticeerd als student, docent, wetenschapper, of beheerder.
Postconditions:	Gebruiker wijzigt monster: er is een monster gewijzigd. Gebruiker verwijdert monster: er is een monster verwijderd.
Related Business Rules:	Gebruikers mogen geen domme monsters maken.
Author:	Iris Trepels
Date:	27-12-2008
ORM:
UC Diagram:

Integrated domain model

Scenarios