Overleg:Requirements Engineering/het werk/werkstuk/2008-9/Groep 02 Spectrometer

overwegingen met betrekking tot de use case survey

Bij deze een lijstje gewenste interactie's met het systeem per actor/rol

Student

Moet monsters kunnen samenstellen

Moet eigen monsters kunnen wijzigen

Moet eigen monsters kunnen verwijderen

Moet monster kunnen opslaan

Moet een meting kunnen uitvoeren door een monster te kiezen, te kiezen voor een bepaalde set van instellingen.

Moet signaal zo kunnen bewerken dat er een spectrum uitkomt dat interpreteerbaar is.[Deze laatste ben ik niet zeker van. Het zou kunnen dat dit automatisch gebeurt en dat het tweaken op het niveau van het kiezen van de instellingen bij de meting gebeurt]

Moet de resultaten van zijn meting, eventueel met een afschrift van monster en instellingen, kunnen opslaan in een soort dossier

Moet opdracht kunnen maken en inleveren [ gebeurt dit binnen het systeem of gewoon op papier?]

Docent

Moet moleculen te kunnen voegen aan het systeem

Moet moleculen kunnen verwijderen uit het systeem

Moet moleculen kunnen veranderen

Moet monsters kunnen samenstellen

Moet monsters kunnen opslaan

Moet eigen monsters kunnen verwijderen

Moet eigen monsters kunnen aanpassen

Moet opdracht kunnen samenstellen

Moet opdracht kunnen opslaan

Moet eigen opdracht kunnen wijzigen

Moet opdracht kunnen toewijzen aan groep studenten

Moet meting kunnen uitvoeren door een monster en instellingen te kiezen

Moet signaal zo kunnen bewerken dat er een spectrum uitkomt dat interpreteerbaar is.[Deze laatste ben ik niet zeker van. Het zou kunnen dat dit automatisch gebeurt en dat het tweaken op het niveau van het kiezen van de instellingen bij de meting gebeurt]

Moet resultaten van een meting met monsterkeuze en instellingen kunnen opslaan

Moet resultaten van een meting kunnen verwijderen

Moet resultaten van een meting kunnen wijzigen [ dit onderdeel is alleen zinvol en gewenst als ook de wiskundige bewerkingen van het oorspronkelijke signaal bij de resultaten opgeslagen moeten worden. Als dat zo is dan zou je verschillende mogelijke bewerkingen kunnen maken en opslaan en daar dan later nog een nieuwe aan toe voegen]

Moet gebruiker met rol student kunnen aanmaken

Moet gegevens van gebruiker met rol student kunnen wijzigen [hieronder valt ook het beheer van het budget van studenten]

Moet gebruikers met rol student kunnen verwijderen

Beheerder

Moet alles kunnen wat de andere twee kunnen

Moet gebruikers ongeacht de rol kunnen toevoegen

Moet gebruikers ongeacht de rol kunnen verwijderen

Moet gegevens die m.b.t. een gebruiker zijn opgeslagen kunnen wijzigen

Dit zijn veel meer gewenste interacties met het systeem dan de 5-9 use cases die we moeten/mogen maken. Een deel van deze veelheid zit m in duplicaten en een deel in bijna duplicaten die vooral afwijkend zijn m.b.t. de inperking van rechten afhankelijk van de rol die de interactie heeft.

Hieronder een lijstje waaruit dit overschot is weggewerkt en waaruit dus ook de ordening per rol is verdwenen.

Moet moleculen kunnen toevoegen Moet moleculen kunnen wijzigen Moet moleculen kunnen verwijderen

Moet gebruikers kunnen toevoegen Moet gebruikers [d.w.z de gegevens die m.b.t. een gebruiker zijn opgeslagen] kunnen wijzigen Moet gebruikers kunnen verwijderen

Moet monsters kunnen samenstellen Moet monsters kunnen opslaan Moet monsters kunnen wijzigen Moet monsters kunnen verwijderen

Moet meting kunnen uitvoeren Moet meting kunnen opslaan Moet meting kunnen wijzigen [d.w.z. de wiskundige transformatie van het signaal] Moet meting kunnen verwijderen

Moet opdracht kunnen samenstellen Moet opdracht kunnen opslaan Moet opdracht kunnen toewijzen Moet opdracht kunnen wijzigen Moet opdracht kunnen verwijderen Moet opdracht kunnen inzenden

Dit zijn er 20 en dat is nog stevig meer dan de 5-9 waar we naar moeten streven. We zouden kunnen overwegen om de 5 groepen te nemen die onstaan door mijn ordening van de interacties aan de hand van het centrale object wat er betrokken is in de interactie

Moleculen

Gebruikers

Monsters

Metingen

Opdrachten

Dat betekent niet dat we elementen weggooien maar dat de use cases groter en complexer worden. We kunnen ons ook afvragen of de uitgebreide ondersteuning die ik me hier voorstel voor het verspreiden, maken en inleveren van opdrachten wel de bedoeling is en misschien kunnen we die geheel of gedeeltelijk schrappen. Een mogelijke use case of gewenste interactie die ik helemaal nog niet genoemd heb en waarvan ik ook nog niet weet of we die in andere use cases verbergen, appart opnemen of misschien wel buiten dit systeem willen plaatsen is het inloggen. Voorlopig moeten we er denk ik van uit gaan dat we boven genoemde 5 use cases hebben die ik dan als volgt zou noemen:

moleculen beheer

gebruikers beheer

monster beheer

metingen

opdrachten

[We kunnen ons ook afvragen of het wel een simulatie is die gewenst is. Misschien is het eigenlijk alleen een interface voor de reeds gemaakte simulatie maar dat is een hele andere discussie].

Els says: Moeilijk inderdaad. Alle 20 is wel een beetje gortig, maar deze 5 worden wel weer heel ingewikkeld met absurd veel alternative paths. Voorlopig maar zo laten en kritiek afwachten?

Nog een puntje: in de hoofdpagina van onze wiki staat dat studenten ook gebruikers beheer kunnen doen, hoort dat? Bedoel je dan dat ze hun eigen gegevens kunnen aanpassen? Om dat preciezer aan te geven zouden we eigenlijk wel alle 20 use-cases in het diagram willen zetten, maar om duidelijke redenen willen we dat ook niet.

Ik stem voorlopig voor het houden van de 5 use-cases en het, voor de duidelijkheid, verwijderen van gebruikersbeheer uit de lijst van dingen die een student mag doen. (Dit is wss mijn laatste internetcontact tot maandag, dus schroom niet om beslissingen te nemen zonder mij)

...Continued, na reflectie facade iteration

Voorstellen (Els says):

1) moleculen beheer zo laten

2) opsplitsen gebruikersbeheer in rol-specifieke varianten

3) monster beheer zo laten

4) metingen laten staan, hieronder valt alleen het doen van een meting en het uitvoeren van een DFT

5) toevoegen van 'analyse', waaronder valt het bewerken (uitvergroten ed) van het bij 4 verkregen spectrum

6) opdrachten: ??

Dit geeft ons 8 use-cases, er van uitgaande dat we opdrachten niet opsplitsen (wat waarschijnlijk wel het geval gaat zijn). Collegae, uw mening?

(niels says):

helemaal mee eens. opdrachten inderdaad spliten maar de vraag is hoe precies en ik weet ook niet of de splitsing van gebruikersbeheer naar actor geen haken en ogen zal hebben. kortom helemaal mee eens en inderdaad analyse toevoegen

(Els says):

Opsplitsen van gebruikersbeheer wordt, als we gewoon recht toe recht aan opsplitsen, heel inefficient, wegens grote overlap tussen zeg maar bewerk student en bewerk docent. Eventueel kunnen we gezamelijke functionaliteit in een later stadium een eigen usecaseje geven en includen in de andere drie, maar dat is meer iets voor de focused iteration.

Wat betreft opdrachten: wat valt hieronder? Het 1) opzetten/maken van een opdracht*, 2) toewijzen van een opdracht, 3) ?? Als dit alles is zie ik twee duidelijke usecases, maar ik heb het idee dat ik wat vergeet...

• bestaat een opdracht alleen uit een monster, of ook een stuk tekst (uitleg ed)? Ik kan me voorstellen dat elke student uit een bepaalde groep dezelfde opdracht-tekst krijgt, maar een ander monster. Als dat zo is, zou een opdracht dan niet alleen bestaan uit een monster, waarbij de bijbehorende tekst op een andere manier wordt verspreid? Als dat zo is, is het maken van een opdracht gelijk aan het maken van een monster.

(do 20-11. Niels says:) Als we inderdaad nu gaan werken met de volgende indeling in usecases dan bij deze ook een voorstel voor de verdeling van de gewenste interacties.

geplande use cases

1) moleculen beheer

moleculen toevoegen

moleculen verwijderen

moleculen wijzigen

initierende actor: docent of beheerder

2) gebruikersbeheerBeheerder

gebruikers toevoegen

gebruikersgegevens wijzigen

gebruikers verwijderen

3) gebruikersbeheerDocenten

studententoevoegen

studentengegevens wijzigen

studentenverwijderen

4) beheer eigengegevens Ik stel voor een use case in te voeren voor het beheren van eigen gegevens. Die kan dan gebruikt worden door docenten en studenten om "hun eigen gegevens" te beheren. eigen gegevens zijn niet alle gegevens die mbt tot hun (hen?) opgeslagen is maar alleen die gegevens waarvoor zij de wijzigings rechten hebben. Dit is eigenlijk een ander soort beheer dan het gebruikers beheer. dit is beheer door de gebruiker en niet beheer van gebruikers.

5) monster beheer

monsters maken

monsters wijzigen

monsters verwijderen

6) metingen

meting uitvoeren

signaal transformeren

gegevens mbt tot een meting verwijderen

7) Analyse

weergave van spectrum wijzigen

(misschien is het ook slim om de een weergave te kunnen opslaan in de vorm van een aantal instellingen)

8) opdrachten

opdracht maken

opdracht distribueren

misschien willen we wel helemaal geen usecase opdrachten. Het is zoals Els terecht heeft opgemerkt een mogelijkheid om de de distributie te beperken tot de distributie van monsters en de opdrachttekst of wat er verder nog bijhoort buiten het systeem om te doen. Als we de mogelijkheid toevoegen om monsters te bewaren als bestand dan kunnen we zelfs de distributie van de monsters buiten het systeem om doen via bB of mail oid. Ik moet zeggen dat ik denk dat dat mooier is en het maakt het systeem ook simpeler. Dan verwijderen we usecase 8 en houden we er 7 over.

Als jullie me niet tegenhouden ga ik alvast wat doen aan de invulling van deze 7 usecases en een datamodel en ik begin bovenaan.

...Continued, na eerste bespreking filled iteration

De use cases zijn als volgt geworden:

1) Moleculen beheer:

Uitwerken:

• moleculen toevoegen;
• moleculen verwijderen;
• moleculen wijzigen.

2) Gebruikers beheer:

Uitwerken: Roy

• gebruikers toevoegen;
• gebruikers gegevens wijzigen;
• gebruikers verwijderen.

3) Gegevens beheer:

Uitwerken:

• toegankelijkheid monsters wijzigen;

4) Monster beheer:

Uitwerken:

• monster maken;
• monster wijzigen;
• monster verwijderen;

5) FID aanmaken:

Uitwerken:Els

• meting uitvoeren;

6) FT aanmaken

Uitwerken:Els

• transformatie uitvoeren;

7) Analyse:

Uitwerken:Els

• analyse FT;
• weergave wijzigen;
• exporteren;

8) Opdrachten toewijzen:

Uitwerken:

• toewijzen;

To-do Lijst Focused

ID	Omschrijving	Uitvoerende	Klaar?
001	Geint. Use Case consiteren	R	Done
002	Use Case template verwijderen	R	Done
003	Stijn Mailen voor use case test en executive sponsor	R	Zie schema van Stijn.
004	Non-functionals toevoegen/aanpassen	R	Done
005	Technische foutafhandelingen verwijderen in use cases	E	Done
006	Domein modellen integreren	N
007	Business Rules toevoegen	R	Was al gedaan. (dacht dat ik dat deed (E))
008	Schrijfstijl aanpassen use cases naar "actieve" stijl	E	Done
009	Nummeringen consisteren use cases	E	Done
010	Triggers + stap 1 BCOE herschrijven naar "actieve" stijl	E	Done
011	Configuratie management verwijderen	R	Done
012	UC 7) Titel veranderen naar Analyse FID	E	Done
013	UC 3) Gegevens beheer aanpassen / uitbreiden	N
014	FID opslaan toevoegen + exp mult	E	ehm, ik denk done...
015	Term lijst gebruiken ipv termen als tabel, overzicht etc	E	done

Extra keuzes:

• Wordt het molecuulbeheer of moleculenbeheer? Dit geldt voor meerdere use cases, ev of mv.
• Wat wordt de naam van de analyse? Blijft dit visuele weergave manipuleren of misschien DFT analyseren?
• Wat zijn de kosten van de non functionals (zie non functionals)?