Brontekst bekijken van 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 =

{| class="wikitable"
|-
! 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)?