Task Descriptions as Functional Requirements Soren Lauesen IT University of Copenhagen E-mail: slauesen@itu.dk http://www.itu.dk/people/slauesen/ October 2005 Some of the slides are from: Soren Lauesen: Software Requirements. © Pearson / Addison-Wesley 2002. With permission by the publisher

1. The role of requirements Tacit demands & reqs Stakeholders Demands Elicitation Analysis Contract Reqspec Validation Design Tracing: Forwards . . . Backwards . . . Req. management: Changing reqs Program Verification Test Op & maint

2. Shipyard application. Which requirement is best? R1. Our pre-calculations shall hit within 5% R2. Product shall support the cost recording and the quotation task by means of experience data R3. Product shall have recording and retrieval functions for experience data R4. System shall have user screens as shown in app. xx Goal-level requirement Domain-level Product-level (traditional) Design-level Proper choice depends on supplier If the supplier is A vendor of business applications? A software house - programmers? PriceWaterhouseCoopers?

3. A hotel system Task list Data about Book guest Checkin Checkout Change room Breakfast list & other services Data about Guests Rooms Services From: Soren Lauesen: Software Requirements © Pearson / Addison-Wesley 2002

4. The hotel system shall support tasks 1 to 5 Task 1: Checkin Start: A guest arrives. End: The guest has got room(s). Accounting started. Frequency: Around 0.5 check ins per room per night. Critical: A bus with 50 guests arrive Sub-tasks: 1. Find room. 2. Record guest as checked in. 3. Deliver key. Variants: 1a. Guest has booked in advance. Problem: Guest wants neighbor rooms; price bargain. Problem: Guest forgets to return the key; guest wants two keys. Problem: Guest identification fuzzy. Example solution: [later: Proposal] System shows free rooms on floor maps. System shows bargain prices, time and day dependent. (Standard data entry) System prints electronic keys. New key for each customer. System uses closest match algorithm. Future: Computer part Missing subtask? Past: Problems Domain level

5. Typical UML use-case For what reason? Use case 21: Find a free room Start: The receptionist wants to find a free room End: The receptionist has found a free room Subtasks: 1. Select room type. 2. Select desired period. 3. Click Search. 4. System shows the first free room. Variant: No free rooms Premature dialog Used for what

6. High-level task. Sub-tasks are good user tasks Task ?: A stay at the hotel Actor: The guest Start: . . . Sub-tasks: 1. Select a hotel. Problem: We aren’t visible enough. 2. Booking. Problem: Language and time zones. Guest wants two neighbor rooms 3. Check in. Problem: Guests want two keys 4. Receive service 5. Check out Problem: Long queue in the morning 6. Reimburse expenses Problem: Private services on the bill Example solution: ? Web-booking. Choose rooms on web at a fee. Electronic keys. Use electronic key for self- checkout. Split into two invoices, e.g. through room TV. Is this a workflow? Preconditions? True tasks have no preconditions

7. Use cases vs. tasks UML use case diagram: Hotel system Booking actor Checkin Receptionist Checkout Account system Transfer actor Human and computer separated: Hotel system . . . Booking Hotel system Booking . . . Task descriptions. Split postponed: Account system Transfer

8. Trap: Often sub-tasks are not good user tasks High-level task: A hospital stay (EPR = Electronic Patient Record) 1. Patient admission 2.1 Show diagnoses (3 pages description) 2.2 Create diagnosis (4 pages) 2.3 Change diagnosis (3 pages) 3.1 Create plan 3.2 Change plan 3.2.1 Book services 3.2.2 Request service 3.2.3 Medication 2. Diagnostic process (what is the matter) Data descrip- tions all over 3. Planning 4. Execution 5. Evaluation Supplier’s solution: Main menu: Choose admission, diagnoses ... Log in and see/enter data ... Log out and choose something else Awfully cumbersome ! 6. Patient discharge

9. Use case with premature design Three pages in total Use case 2.1: Show diagnoses Start: The user wants to inform himself about the health state of the patient. Example: nurse starting on duty. Critical: Must be available at all times and provide overview through brief summaries and conclusions Precondition: At least one admission cause note must be attached. Postcondition: The user has got an overview ... Subtasks and variants: 1. Show the hierarchy of diagnoses. 2. Select view (e.g. hierarchy or Gantt diagram) 3. Select level of detail (collapse or expand levels) 4. Select parts of the hierarchy ... current/all, time interval ... 5. Show diagnose history. 6. Show detail data for a selected diagnose - Basis for diagnosis is shown on an overview with ... - Notes about the diagnosis are shown in an overview with ... - External causes are shown in an overview with ... 7. Show related services. The status of the service must be shown ... Lots of data are introduced here

10. Better: Reflect the true work task Use case = one page Task 2: Clinical session Start: Contact with the patient, e.g. ward round or emergency ward. Or conference about the patient. End: When what can be done now is done. Data needs: See the data description in . . . (All subtasks are optional and repeatable. The sequence is arbitrary) Data description: 12 pages + 1 per service type. Covers all use cases Subtasks and variants: Example solution: 1. Review the state of the patient Problem: Overview of data Overview of diagnoses and results 2. Provide services on the spot Record results on the spot 3. Follow up on planned services Overview of requested services 4. Adjust diagnoses Record on the spot 5. Plan new services Check with everybody's calendar ... 6. Maybe discharge the patient Request transport, message to ... Requirement: Support this well Write your solution here - or refer to appendix. We choose the supplier with the best solution.

11. Roster planning and payroll 1.1 Monthly report to personnel dept. 2.1 Record actual work hours User: Planner in department User: Personnel department 3.3 Record new employees User: Staff in department 3.2 Payroll amendments 3.1 Check rosters 2.2 Swab duties 1.2 Make roster 2.3 Staff illness User tasks Business goals Personnel department: Automate some tasks Remove error sources Observe the 120 day rule Less trivial work and stress Hospital department: Reduce over-time pay etc. Faster roster planning Improve roster quality

12. Conclusion Choose the right requirement level: Task descriptions: Workflow: Domain level: Tasks and data to support. Supplier ensures task support and ease of use. Design level: Details of user interface. Analyst ensures task support and ease of use. What user and system do together. True, closed tasks. Solution in right-hand column. Sequence of tasks, but true tasks have no preconditions. Flow embedded in data (states) and helpful task support.