1. Task Descriptions as Functional Requirements Soren Lauesen
IT University of Copenhagen
October 2005
Some of the slides are from:
Soren Lauesen: Software Requirements.
© Pearson / Addison-Wesley 2002.
With permission by the publisher

2. 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

3. 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?

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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.

12. 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

13. 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.