Brontekst bekijken van Requirements Engineering/het werk/werkstuk/2010-11/Groep 01 (Controlegroep)/UC7


| 07 || {{markeer|Alarmering}} || Het systeem meldt de administratiemedewerker dat een act zijn betalingsdeadeline heeft overschreven. || Administratiemedewerker {{!|Patrick Schileffski||Bestaat deze UC nog steeds, ik dacht dat wij hem wilden eruit gooien en door een Business Rule wilden vervangen...Anders moet ik nog een DM voor deze UC aanmaken||Joeri Arendsen}}{{!|Liset Meijerman|| Ik geloof dat iedereen dat dacht, alleen Joeri wil het er niet uitgooien... En als Joeri niet wilt reageren dan lijkt het mij een goed idee om deze UC weg te halen. Dan is de UCS tenminste klaar en de UCD ook||Patrick Schileffski}}
{{!|Joeri Arendsen||Ehm... tja als we mijn commentaar gaan weghalen, dan wordt het ook wel erg moeilijk. Ik had netjes uitgelegd hoe en waarom ik deze use case er in wil houden. Een use case beschrijft de interactie tussen de gebruiker en het systeem, daarom hoort deze use case er gewoon bij. Dat hierbij de initiator niet zo duidelijk is is onhandig, maar nog geen reden om het dan maar te verstoppen in een Buisness rule. 

Zoals Christiaan al zegt, de initiating actor is nu adm.medewerker en daarmee zou alle weerstand moeten zijn opgegeven en kan deze use case gewoon blijven bestaan. Ik heb ook nog geen goed argument gehoord om er een BR van te maken. Wel een slecht argument, namelijk: "Als Joeri niets van zich laten horen dan verwijderen we het maar." --- Komt dit door gaarheid of wat ging er door je heen? O_o}}
{{!|Patrick Schileffski||
# Kunnen wij aub. inhoudelijk blijven? De vraag over gaarheid zou ik namelijk ook aan je kunnen stellen aangezien je niet erg netjes op Lisets commentaar reageert.
# Je kunt de alarmering als onderdeel van het administratiesysteem zien en daar houden wij ons niet mee bezig. Dat is ook wat Niels volgens mij tijdens het feedback zei.
||Joeri Arendsen}}

{{!|Joeri Arendsen||# Nou breekt mijn klomp. Ik reageer zo omdat ik onredelijkheid waarneem. Je verwijdert geen use case om die reden.
# Ik neem aan dat je financieel administratiesysteem bedoelt: wij verwerken inderdaad de boekhouding niet in het systeem. De alarmering is echter onderdeel van het proces. Niels zegt dat ze niet wegrijden als het geld (of een deel daarvan) nog niet binnen is. In het scherm moest de betaalstatus staan van de klant, heb jij ook opgenomen in je DM. De alarmering ondersteunt het proces: kijk naar het mission-vision verhaal. Deze use case sluit daarbij aan! Het is puur een mijlpaal, net als een gereed hebben van materiaal. Dat het om geld gaat en te associëren is met boekhouding is geen reden om het dan maar door te strepen.
# Als we ons willen onderscheiden als groep van de rest, zullen we een meerwaarde moeten bieden. Dit is naast het simulatie-aspect een punt van meerwaarde.}}

{{!|Patrick Schileffski||
# Liset wilde je UC waarschijnlijk ook niet verwijderen omdat je niet reageerde maar omdat Niels deze UC tijdens het feedback kritiseerde. 
# Idd. bedoel ik financieel administratiesysteem. Je kunt mij nog niet echt overtuigen dat UC7 nodig is. Volgens mij is het de taak van de boekhouder om te kijken dat iedereen op tijd betaald en niet de taak van die die de spelers en kostuums inplant. Ik snap niet waar ik je alarmering in de MVV terug kan vinden. Ik zeg nergens dat ergens de betaalstatus van de klant moet staan. Als je DM3 bedoeld moet je bedenken, dat die samenhangt met UC3, het aanmaken van een contract. In de contract moet staan wanneer de klant hoeveel betaalt, maar het is volgens mij niet de taak van ons systeem de spelers-/kostuumplanner te waarschuwen als iemand niet betaalt. Echter is nog te overwegen of het aanmaken van een contract een onderdeel van ons systeem is.
# Ik zie er een meerwaarde in een alarmering, maar ik zie de meerwaarde niet tov. ons systeem. Wat mij betreft kunnen wij dit alarmeringssysteem in onze presentatie noemen maar wij moeten dan wel duidelijk zeggen, dat wij het niet gemodelleerd hebben omdat het niet ons taak was, maar dat het makkelijk in een boekhoudingssysteem te realiseren was, als het boekhoudingssysteem compatibel met ons systeem is. Hier zijn nog andere dingen te bedenken. Je kunt bv. uit onze gegevens afleiden hoeveel uren een artiest gewerkt heeft, maar dat is ook geen onderdeel van ons systeem. Of je kunt afleiden wanneer een van de auto's van Close Act waarschijnlijk de volgende keer naar de controlebeurt moet omdat je weet hoe veel de auto's ongeveer rijden. Maar toch gaan wij niet waarschuwen wanneer een auto naar de beurt moet. Snap je?

Het is dus niet zo, dat UC7 slecht is of geen meerwaarde heeft, maar het is volgens mij zo dat UC7 niet bij ons systeem maar bij een ander systeem behoort.
||Joeri Arendsen}}

{{!|Joeri Arendsen||We staan over dit onderwerp recht tegenover elkaar. Ik vind je tegenargumenten zelfs geen tegenargumenten omdat een auto niets te maken heeft met het basisproces van Close act, terwijl betaling een fundamentele stap is het proces. Een boekhouder spreekt niet met de klant. Dus wat denk je wat er gebeurt als een boekhouder ziet als iemand niet betaald heeft? Gaat hij zelf bellen of denk je dat hij dit laat doen door de persoon die bekend is met (de contactpersonen van) het bedrijf? Een medeweker aan de telefoon met de klant moet gelijk kunnen opmerken van "goh, waar blijft het geld." - Waarom zou je dat proces vertragen door weer een aparte persoon daarbij te halen?

Wellicht kunnen we het eens worden dat we het niet eens gaan worden.

Wat doen we nu? ||Patrick Schileffski}}

{{!|Patrick Schileffski||Wij hebben de mening van onze collega's nodig die helaas tot nu toe niet aan de discussie deelnemen...
"Een medeweker aan de telefoon met de klant moet gelijk kunnen opmerken van "goh, waar blijft het geld." impliceert voor mij een alternatieve pad binnen een gesprek waarvoor wij niet eens een UC hebben... maar geen eigen UC.
Ik ben van mening, dat de alarm bij de boekhouder moet afgaan, je hebt namelijk sowieso de boekhouder nodig voordat je de klant gaat bellen om hem te vragen of het geld er zeker nog niet is. De administratiemedewerker weet trouwens binnen de huidige domeinmodellen wel wanneer er iets moet worden betaald, maar niet of er iets betaald werd, want dat wordt in de huidige domeinmodellen nergens opgeslagen.
||Joeri Arendsen}}

{{!|Christiaan Hillen||Gezien dit onderdeel van het systeem geen samenhang heeft met de rest van het systeem. (Het is slechts een extra feature die niet van essentieel belang is) stel ik voor hem te schrappen aangezien er schijnbaar onenigheid is over de exacte invulling hiervan. Ik maak er een business rule van. (Overigens kloppen de business rules nog niet. Hier ga ik morgen mee aan de slag. 

edit: Het is tenslotte de focus itteratie, daarin wordt geschrapt...... en een discussiepunt kunnen we nu beter kwijt dan rijk zijn.}}



***********************


====07====

{|class="wikitable"
! Use Case: !! 07. Alarmering
|-
| Use case diagram
|
|-
| Description
| De administratiemedewerker inlichten over een mogelijke wanbetaler.
|-
| Source
| Voortgekomen op basis van verhaal spoedbetaling van Niels. "We rijden niet weg, als er niet betaald is."
|-
| Version
| 1.
|-
| Basic course of events
|
# Administratiemedewerker voert Act in op datum x. (Use case 01).
# Systeem berekent op basis van de actdatum de betalingsdeadline. (Deze zal bij het aanmaken van het contract, op het contract verschijnen. Use case 3.)
# Systeem meldt aan de administratiemedewerker dat er een Act is waarbij de betalingsdeadline is overschreden.
# Administratiemedewerker noteert reden van betalingsachterstand (na contact met klant).
# Administratiemedewerker stelt een nieuwe betalingsdeadline in, in het systeem. 
# Het systeem bevestigt de nieuwe betalingsdeadline.
# Administratiemedewerker van de financiële afdeling markeert act als betaald.
# Systeem bevestigt nieuwe betalingsstatus van de act.

(Sommige stappen zijn niet direct opvolgend, maar zijn onderbroken door een periode van tijd.)
|-
| Alternate paths
|
Beschrijving: er zal geen betaling binnenkomen, act wordt geannuleerd. <br>
http://linkbox.zapto.org/uni/ReqEng_Alternatepath_replacement.png
* BCoE: 1 tot en met 4. 
* --> Verder naar use case '''01b Act verwijderen''' BCoE: 4 tot en met 7.<ref name="Verwijzing">Mag je zo verwijzen naar een use case? </ref>

|-
| Preconditions
|
* Act is gepland en betalingsdeadline is daardoor bekend in het systeem.
* Aan een betalingsdeadline is niet voldaan.
|-
| Postconditions
| Betaling is alsnog voldaan.
|-
| Related business rules
| 
* 008 Indien een factuur 14 (?) dagen voorgaande aan de tijdspanne van de act waartoe de factuur behoord nog niet is voldaan geeft het systeem een waarschuwing 
|}

====[[#07|7 Alarmering]] scenario 1:====

# Het systeem geeft een waarschuwing dat de Saurusact op 15-05-2011 uur nog niet betaald is.
# Mevrouw Jansen voert de reden in dat meneer Grootjens het vergeten was.
# Mevrouw Jansen stelt als nieuwe betalingsdeadline 3 uur vanmiddag.
# Het systeem bevestigt de nieuwe betalingsdeadline.
# Meneer Finan van de financiële afdeling markeert de Saurusact op 15-05-2011 tussen 14:00 en 16:00 uur als betaald.
# Het systeem bevestigt de nieuwe betalingsstatus en markeert de act als financieel veilig.


====[[#07|7 Alarmering]] scenario 2:====

# Het systeem geeft een waarschuwing dat de Saurusact op 15-05-2011 nog niet betaald is en vraagt om reden.
# Mevrouw Jansen voert de reden in dat meneer Grootjens de act wilt annuleren omdat hij niet genoeg sponsors kon verzamelen.
# Het systeem toont annuleringskosten van 20 euro en vraagt om bevestiging van de annulering op 15-05-2011.
# Mevrouw Jansen bevestigt de annulering.
# Het systeem voert in de spelersinfo door dat Cornoelje en Piet op 15-05-2011 tussen 14:00 en 16:00 uur beschikbaar zijn en dat de rekwisieten van de saurusact op 15-05-2011 tussen 14:00 en 16:00 uur beschikbaar zijn.
# Het systeem deelt de financiële afdeling mee dat meneer Grootjens nog 20 euro moet betalen.


====[[#07|7 Alarmering]] scenario 3:====

# Het systeem geeft een waarschuwing dat de Saurusact op 15-05-2011 tussen 14:00 en 16:00 uur nog niet betaald is en vraagt om reden.
# Mevrouw Jansen voert de reden in dat meneer Grootjens de act wilt annuleren omdat hij niet genoeg sponsort kon verzamelen.
# Het systeem toont annuleringskosten en vraagt om bevestiging van de annulering op 15-05-2011 tussen 14:00 en 16:00 uur.
# Mevrouw Jansen bevestigt de annulering niet.
# Het systeem toont de berekening van de huidige annuleringskosten en maakt dit bewerkbaar.
# Mevrouw Jansen geeft aan dat de annuleringskosten van 20 euro naar 10 euro veranderd moet worden.
# Het systeem voert de verandering in en vraagt om bevestiging.
# Mevrouw Jansen bevestigt de annulering.
# Het systeem voert in de spelersinfo door dat Cornoelje en Piet op 15-05-2011 tussen 14:00 en 16:00 uur beschikbaar zijn en dat de rekwisieten van de saurusact op 15-05-2011 tussen 14:00 en 16:00 uur beschikbaar zijn.
# Het systeem meld de financiele afdeling dat meneer Grootjens 10 euro moet betalen.