This Entry is dedicated to my project Use Case “Bring Emma to kindergarten”, Please read the project page first to get the general idea.
Here it is, formalized requirements outline from the previous post.
Requirements Outline
Chapter 1. Purpose and Scope
1a. What is the overall scope and goal? – Main goal is to bring Emma every working day between 08:00 and 08:30 to Kindergarten
1b. Stakeholders (Who cares?) – Chris, Reinis
1c. What is in scope, what is out of scope? – Starts with getting up and ends with leaving Kindergarten
Chapter 2. Terms Used / Glosary
Lunch – bread & fruits. Joghurt, pudding
Registration time – 08:00 – 08:30
Working day – Mo till Fr with the exception of school break, closing(?) days and comon holidays
KiGa – Kindergarten
Kindergarten – “zum St. Martin”, …. 92712 Pirk
Emma – child (daughter)
Lunchbox – pink, branded “Scouty” has picture of pony and sheep
Chapter 3. The Use Cases
3a. The primary actors and their general goals – Parents to bring Emma early and without the delay to Kindergarten; Child to meet her friends, play, masquerade; Kindergarten personell – to register child upon arrival
3b. The business use cases (operations concept) – Bring Emma to kindergarten
3c. The system use cases – Bring child to kindergarten
Chapter 4. The Technology Used
Household, municipal infrastructure
4a. What technology requirements are there for this system? – municiapal infrastructure should be maintained; household should have power, water, clothing
4b. What systems will this system interface with, with what reqruiements? – phone, baker, butcher
5. Other Requirements
5a. Development process – not applicable
5b. Business rules
Time – 08:00 – 08:30
Child is dressed
Child is not crying in process
Child has lunchbox
Acceptance of the child towards other actors
5c. Performance – use case should be completed in approx. 1 hour
5d. Operations, security, documentation – security on stairs, street, depending on weather conditions (e.g. umbrela oder gloves), health; respective clothing for operations
5e. Use and usability – possibility to parallelize some steps should be investigated
5f. Maintenance and portability – Emma should be periodically washed and fed. Dress and lunchbox should be maintained. Is this Use Case applicable for any child?
5g. Unesolved or deferred – none
Chapter 6. Human Backup, Legal, Political, Organizational Issues
Q1. What is the human backup to system opertaion? – Reinis back ups Chris; Christa back ups Reinis & Chris; Mrs Schwab backs up Christa, Reinis & Chris
Q2. What legal and what political requirements are there? – Reinis wants to participate only if he is not tired or dozy
Q3. What are the human consequences of completing this system? – not applicable
Q4. What are the training requirements? – traffic rules, dressing up Emma, lunch, brush teeth, timing!
Q5. What assumptions, dependencies are there on the human environment? – health, acceptance of Emma
End! Now, let us see what exactly is the purpose (besides obvious one of capturing requirements) of this artifact and what value does it add to our project.
Requirements Outline, what gives?
I already explained in my previous post that I was looking for a way to somehow capture all those social or, in general, human aspects I am unable to capture directlly in use case due to its behavioral nature. So does Requirements Outline serve this purpose?
Short answer – yes, but it needs to be adapted.
Long answer – we have special case of having just one use case defining scope of our project. This demands certain adaption for the requirements outline. Also the fact that the System is not computer based but rather social makes some of the chapters not really usefull or even meaningful. Let us check out some detail:
For starters, 1b. – why isn’t Emma stakeholder? Our motivation was that she does not always care. Sometimes she is willing to go to kindergarten, sometimes she really don’t care and sometimes she wants to stay in bed and is not willing to go to kingergarten no matter argumentation. The discussion on what place does Emma take in this use case we will continue again at some point. Is our assumption that Emma is no stakeholder correct? Is Emma an actor then or, maybe, she is even a domain object? I am not naging on definitions here, but rather trying to bring in clarity since without clear definition we will be probably unable to state clear requirements.
then there’s 1c. – we had a somewhat lengthy discussion about if preparations on the previous evening are within scope. Pro arguments were “well but we need to prepare that food for breakfast” or “if am not going to set alarm clock, we might oversleep…”. Contra arguments were “well but you have to buy food before you can prepare it – should buying be within the scope aswell?” or “you set alarm clock not only to get up on time to bring emma to kindergarten but also to get to work on time”. As you can see defining scope is not trivial at all, especially in cases where parts of process are taken for self-evident. I mean everyone knows that to get up early you have to set up alarm clock and how to do it or, that you have to brush your teeth or eat breakfast in the morning or dont you? I think there is no best practice that guarantees right result. Why did we left preparations on previous evening out of scope? Cause my gut feeling said so!
3a. – check out we defined an Actor for Emma (child). Is this descission right? I mean, aren’t we just driven by our social standarts that prohibit us from treating a person as (domain) object? Wouldn’t it be more appropriate to define her as a part of the system, to neglect her free will and to leave within scope only her attributes and part of behavior relevant to fullfilling given use case?
3b., 3c. – well, duh! Is it really worth writing system use case just to display that we could theoretically generalize Emma to child?…
Chapter 4 – I was about to say “duh!” as we started to write down Chapter 4, but then I realized that this chapter must be adapted before we actually can write something about “technology”. What technology are we actually using in this use case? Alarm clock, kitchen gear, phone, shower head (thats right!), shoe cabinet (technologically very advanced thing) – all very important to optimally complete use case but too general to specifically elaborate on any particular one. Those are all elements of infrastructure! Thus I come to conlusion that Chapter 4 should actually be called “The Technology and Infrastructure used” and should include also descriptions of what infrastrcutre elements are used to accomplish given use case. There is Topic 5d. “Operations, security and documentation” that kinda offers place for mentioning infrastructure still I belive that infrastructure is one of those fundamental aspects of use case and since technology chosen is very often co-related with infrastructure available those two belong together.
4b. – just one remark. See, we mention baker and butcher. It was very nice to instantlly see an added value of actually considering different aspects of requirements. We startet to discuss that we would have to interact mit Phone in those cases when Emma can not attend kindergarten. One of us suddenlly asked, but what about Mrs Häring our baker – we would have to interact with her aswell in case we would forget to prepare lunch for Emma or if our fridge would be empty. In the context – visiting Mrs Häring takes 5-15 minutes thus having serious impact on reaching performance goals of use case and thus should be part of the requirements!
5b. – “Child is not crying in process” say what?!?!? Those of you who were already confronted with bringing their children to kindergarten know what I am talking about. In first couple of weeks or every time after lengthy vacation (or visit at grandmas’) was crying and not calming down for hours on in. Kindergarten personell even called us (using phone system :)) and asked to fetch Emma early since she wouldn’t calm down. This resulted in us having phones placed close and mobiles switched on every time we leave house during kindergarten hours.
5d. – another reason to bring infrastructure to Chapter 4 is operations. We are using municipal infrastructure (pavement) which based on weather conditions or maintenance is not always really operational 🙂
5e. – I think we were unsure if we understood this topic correctlly. Any example or advice would be really appreciated. The only sentence we came up with you can see for yourself.
Chapter 6 Q2. – fact is that I am an “owl” and I must force myself to get up early. This is good to know since everytime Chris can not bring Emma to kindergarten she informs me in advance so that I can get to bed early and lessen “the pain”.
Summary
Finally, a decent best practice to structure all of the requirements. Did we really covered all of them? Again – time will tell as we advance with our project. Just reviewing initial conlusions I was able to draw from requirements outline I see solid base for further elaboration.