Requirements, use cases and tasks Søren Lauesen, February 2011 IT-University of Copenhagen E-mail: [email protected]

Requirements, use cases and tasks

Søren Lauesen, February 2011 IT-University of Copenhagen

E-mail: [email protected] http://www.itu.dk/people/slauesen

Select supplier

Customize

Contract

Analysis

Reqspec

Op & maint

Design

Program

Test

2. The role of requirements

Demands Elicitation

Stakeholders

Verification

Validation

Tacitdemands

& reqs

Tracing:Forwards . . .Backwards . . .

Req. management:Changing reqs

From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002

3. Traditional requirements - hospital roster planning

R47. It must be possible to attach a duty type code (first duty, end duty, etc.) to the individual employee.

R144. The supplier must update the system according to new union agreements no later than a month after their release.

R475. The system must be able to calculate the financial consequences of a given duty roster - in hours and in $.

R479. The system must give notice if a duty roster implies use of a temporary worker for more than three months.

R669. The system must give understandable messages in text form in the event of errors, and instruct the user on what to do.

ExperiencesRequirements are met, but the user tasks are supported badly.The business goals are not met.Too expensive - no freedom for the developer.

IEEE 830

4. Write it as use cases?

Use case 475: Calculate the financial consequences of a roster. Trigger: The user wants to calculate the consequences.Precondition: The user is logged on.

1. The system shows a list of rosters.2. The user selects a roster3. The user selects "Calculate consequences"4. The system calculates the consequences.5. The system shows the consequences.Exception: No rosters in the list.

When is it used and for what?

Trivial details - seduced by the template.No real value added.

Invented dialog. Would be harmful here.

Subtasks and variants:

1. Create new roster.

2. Record leave. Two kinds . . .

3. Allocate staff. Ensure competence level, leave, union agreements. Avoid extra pay.

3a. Substitute not yet in the system.3b. Get staff from other department.

4. Distribute plan for comments.

5. Park the plan or release it.

5. Better requirements: Support tasks C1, C2 . . .

C2: Make rosterFrequency: Every 14 day. In some departments . . .Difficult: Vacation periods.

Example solutions:

Automatically from last plan . . .

System checks the vacation rules.System can record several years ahead.

System suggests staffing of unstaffed duties. Warns in case violated rules and excess pay. Supports the "jigsaw puzzle" with Undo and several trial versions.

Shows free staff from other depts.

A print of the roster suffices.

Done by humanplus computer

Example of computer's part - not requirements

Customer: Help - we bought the wrong

system

Present problem: Recorded on stickers many months ahead.

Pres. problem: Difficult manually. Errors and too much extra pay.


1. Create new roster.

2. Record leave. Two kinds . . .

3. Allocate staff. Ensure competence level, leave, union agreements. Avoid extra pay.

3a. Substitute not yet in the system.3b. Get staff from other department.

4. Distribute plan for comments.

5. Park the plan or release it.

6. Requirements verification - assessing solutions

C2: Make rosterFrequency: Every 14 day. In some departments . . .Difficult: Vacation periods.

Example solutions:

Automatically from last plan . . .

System checks the vacation rules.Only one year ahead.

System suggests staffing of unstaffed duties. Separate batch calculation, 24 hours. Several versions cumbersome.

Can show free staff from neighbor hospitals.

A print of the roster suffices.

Present problem: Recorded on stickers many months ahead.

Pres. problem: Difficult manually. Errors and too much extra pay.

Total points: 2(as today)

7. Business goals and how to meet them

Personnel department:Automate some tasks Remove error sourcesObserve the 120 day ruleLess trivial work and stress

Hospital department:Reduce over-time pay etc.Faster roster planningImprove roster quality

Use

r: P

lann

er in

dep

artm

ent

C1.

Mon

thly

repo

rt to

per

sonn

el d

ept.

C2.

Mak

e ro

ster

Use

r: S

taff

in d

epar

tmen

tC1

0.Re

cord

act

ual w

ork

hour

s C1

1.Sw

op d

utie

s C1

2.St

aff i

llnes

s

Use

r: P

erso

nnel

dep

artm

ent

C20.

Chec

k ro

ster

s C2

1.Pa

yrol

l am

endm

ents

C22.

Reco

rd n

ew e

mpl

oyee

s

Businessgoals

Usertasks

System

Platform:HW, OS, DB

Ext. systems:Present and new

8. What to include?

Usergroups

Quality requirements:How fast?

How easy to use?. . .Interfaces

Data requirements: What to record?

Functional reqs, external systems:System must transfer data ...

Third party must be able integrate with ...

30%

30%

15%

15%

Help the reader:Business goalsContext ...

Functional reqs, user interface: Some alternatives:Design level: Search screen (Fig. 1) shows ...

"Find" button queries ...

Product level: System must show ...System allows searching for ...

Domain level: System must support user tasks C1, C2 ...

IEEE 830

9. Requirements template SL-07 (EHR example)

A. Background, vision, guide . . .

B. High-level demandsB1. Business goalsB2. Early proof of concept

C. Tasks to supportC1. Admit patientC2. Clinical session . . .

D. Data to recordD1. DiagnosesD2. Diagnosis types . . .D10. Data in existing systems

E. Other functional requirementsE1. Complex calculations and rulesE2. ReportsE3. Expansion of the system

F. Integration with external systems

G. Technical IT architectureG1. Use of existing HW and SWG2. New hardware and software

H. SecurityH1. Access rights for usersH2. Security managementH3. Protection against data lossH4. Protection against unintended . . .H5. Protection against threats

I. Usability and designI1. Ease-of-learning and task efficiencyI2. Accessibility and Look-and-Feel

J. Other requirements and deliverablesJ1. Other standards to followJ2. User trainingJ3. DocumentationJ4. Data conversionJ5. Installation

K. The customer's deliverables

L. Operation, support, and maintenanceL1. Response timesL2. AvailabilityL3. Data storageL4. SupportL5. Maintenance

20% reuse

1% reuse

1% reuse

50% reuse

80%

80% reuse

90% reuse

30% reuse

10. SL-07 example: Demand at left, solution at right

H3. Protection against data loss Data may unintentionally be lost or misinterpreted.

The system must protect against: Example solutions: Code: 1. Loss or replication of data transferred between

two systems, e.g. because one or both systems close down.

2. Concurrency problems, e.g. that user A makes a decision about medication, but before the system has recorded the decision, user B has prescribed a drug that interacts. Neither A nor B will notice the conflict.

3. Disk crash Periodic backup or RAID disks.

4. Fire Remote backup . . .

Visions and task descriptions

12. Business goals and reqs for a hotel system

Tasks to supportT1. Book roomT2. Check in - May have booked - Neighbor roomsT3. Check outT4. Change roomT5. Record services

T10. Staff scheduling

Data modelD1. GuestsD2. RoomsD3. Services

Business goals: - Catch small-hotel market. - Much easier to use and install than

existing hotel systems. - Interface to existing Web-booking

systems.

Requirements:R1: Support tasks T1 to T34.R2: Store data according to data model.. . .R7: Usable with 10 min of instruction.

Verifiable?

13. Annotated task list for the hotel system

Task list1. Reception

T1.1 Book room. May involve many rooms.

T1.2 Check in. Some guests have booked in advance, some not.

T1.3 Check out. Review account, then invoice.Problem: Checkout queue in the morning.Solution? Self-service checkout.

T1.4 Change room. Possible any time during the stay.

T1.5 Record services and breakfast list. Breakfast list daily, service notes at any time.Clever: Special screen for breakfast list.

2. Staff scheduling

T2.1 Record leaveT2.2 . . .

Work area

Work area

Possible future

Present way

Present way

Task:Domain-level,now and future

Imperative language


1. Find free room.

1a. Guest has booked in advance.

1b. No suitable rooms.

2. Record guest data.

3. Record guest as checked in.

4. Deliver the key.

Example solutions:

System shows free rooms on floor map. System shows bargain prices, time and capacity dependent.

Soundex and closest match.

System prints electronic keys. New key for each customer

14. Task description - Hotel systemC2: Check inStart: A guest arrives.End: The guest has got rooms. Accounting started.Frequency: Total: Around 0.5 check-ins per room per night. Per user: 60 ... Difficult: A bus with 60 guests arrive.Users: Novices with little domain knowledge. Expert receptionists.

Future:What computer does

Past: Problems

Domain level: Hide who does what

Validation: Something missing !

Not requirements but assump-tions behind the requirements

Problem: Guest wants neighbourrooms. Wants to bargain.

Problem: Find guest in the records.

Problem: Guest forgets to return key.Wants two keys.

15. Exercise: Reqs for email system (client side only)

Which tasks to support?

16. Good or bad tasks?

Good tasks:• Closed: From trigger to "coffee break"• Session task: Small, related tasks bundled into one task• Imperative: Hide who does what• Don’t program - "if the customer has booked then ... "• No precondition: Part of the task is to check the condition

Examples:1 Manage rooms?2 Enter guest name?3 Check in a guest?4 Check in a bus of tourists?

5 Change the guest’s address etc?6 Change the booking dates?7 Cancel entire booking?

Optional subtasks in "Change booking"

8 A stay at the hotel from booking to check out?

Many coffee breaks.A task flow.


17. Task flow or high-level task

High-level steps:

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 outProblem: Long queue in the morning

6. Reimburse expensesProblem: 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.

Flow 1: A stay at the hotelUser: The guestStart: . . .


Hierarchical decomposition? Only in simple cases

High-level step: Tasks:1. Admit the patient

2. Make a diagnosis3. Plan the treatment4. Carry out the treatment5. Assess the result6. Discharge the patient7. Follow-up at home

18. Complex tasks - not hierarchical

Flow 2: Patient treatmentStart: The patient is referred to the hospital from a

practitioner or arrives in emergency.End: The patient is cured or . . .

C1: Admit before arrivalC2: Immediate admissionC10: Clinical sessionC10: Clinical sessionC10: Clinical sessionC10: Clinical sessionC3: Discharge patient . . .

?

Subtasks and variants: Example solution:1. Review the state of the patient

Problem: Overview of data Overview of diagnoses and results2. Provide services on the spot Record results on the spot3. Follow up on planned services Overview of requested services4. Adjust diagnoses Record on the spot5. Plan new services Check with everybody's calendar ...6. Maybe discharge the patient Request transport, message to ...

C10: Perform a clinical sessionStart: Contact with the patient, e.g. ward round or emergency ward.

Or conference about the patient.End: When we cannot do more for the patient now.Data needs: See the data description in . . .

(All subtasks are optional and repeatable. The sequence is arbitrary)

19. The true work task

12 pages. Cover all tasks.

20. Use cases versus tasks

Hotel system

Booking

Checkin

CheckoutReceptionist

Accountsystem

UML use casediagram:

Transferactor

actor

Human and computer separated:

Hotel system

. . .

Booking

Hotel system

Booking

. . .

Task descriptions. Split postponed:

Accountsystem

Transfer

Problems allowed as "requirements"

21. Eight use case solution vs. seven task solutions

Use case approach

Ignores problems without an easy solution. Hides very important business needs.

Task approach

Records a "problem requirement". Makes it visible whether the supplier has a solution.

Invents a dialog and restricts the solution space. Often bad dialogs.

Describes what user and system do together. Supplier defines dialog.

Not suited for comparing solutions. For each solution, customer tries out the tasks. Assesses goodness of support and problem resolution.

Template causes wrong requirements: preconditions, business rules, exceptions.

Dealt with in other requirements sections: Security, data requirements, special functional requirements.

Reference: Lauesen, S., Kuhail, M.: Use cases versus task descriptions. Proceedings of REFSQ 2011, Springer Verlag

Architecture and integration

23. Restraining, detailed requirements, H:S

R 512: Must be module-based with SOA interfaces. No local data copies.

Integration platform

Medicine module

Supplier: It will be expensive. Our system must be reengineered.

Note module Booking module

Interface 3: Create medicine orderRetrieve order . . . XML

Why this requirement? The customer wanted supplier independence - no monopoly.

Better way to avoid monopoly (SL-07): F10-9: Third party must have the means and rights to retrieve all data.F10-7: Data and interfaces must be documented in such a way that a qualified

third-party can understand them and use them for the purpose.

Adding a new service between two suppliers: around 2 * 80,000 DKKResult: Nothing was ever integrated on

the platform. 100 mio DKK wasted.

e-TL

DanID

24. Architecture reqs, e-LandRegistration (e-TL)

CVR

Tax

R1. SOA-XML-services internally as well as externally.

R2. Data stored only in one place - no data replication.

R3. Expects that system is based on existing modules.

Note: All external systems have well-defined XML-interfaces.

Why SOA? Supplier independence? Doesn't help.

XM

L

Checks

Requires 10-50 times more computer power.

The supplier cannot guarantee response time and availability.

Inconsistency or questionable limitation of potential suppliers.

All except CPR was under major change.

The IT priesthood's vision? (Want it to be a law. Then they don't have to argue for it any more).

Final solution:No internal SOA.Data replicationin most places.

9 more

Response time

26. Response time requirements

Unrealistic

R10: When moving from one field to the next, it must be possible to type within 0.2 s.

R11: When moving from one screen to the next, it must be possible to type within 1.3 s.

R13: Simple reports used occasionally must be visible within 20 s.

R20: Simple reports used occasionally must be visible within 20 s in 95% of the cases. It may never take more than 80 s.

The specified times must apply in 95% of the cases in peak load:

20 users work with claims management (Task C10) and

100 users with customer support (task C12)

Mental switch Or user will change task

Or the typing speed will decrease

R2: Product shall compute a room occupation forecast within 20 s.

R3: Product shall compute a room occupation forecast within 40 s.

R4: Product shall compute a room occupation forecast within ___ seconds.

R5: Product shall compute a room occupation forecast within ___ seconds. (Customer expects 20 s.)

Best availableis 40 s?

Nobody strives for 20 s.

Open target buthow important?

Open target +expectations

27. Balancing needs against possibilities: Open target

Why 20 seconds?

Response time requirements

Simple reports used occasionally must be visible before the user loses patience.

Moving from one field to the next may not slow down the user's typing.

Example solution

The report is visible within ___s.(Customer expects 20 s.)

Typing is possible within ___s.(Customer expects 0.2 s.)

Example from Requirements SL-07

Elicitation

29. Elicitation techniques

Pres

ent w

ork

Pres

ent p

robl

ems

Goa

ls &

key

issu

esFu

ture

sys

tem

idea

sR

ealis

tic p

ossi

bilit

ies

Con

sequ

ence

s &

C

omm

itmen

tC

onfli

ct re

solu

tion

Req

uire

men

tsPr

iorit

ies

Com

plet

enes

s

Stakeholder analysis(Group) interviewObservationTask demoDocument studiesQuestionnairesBrainstormFocus groupsDomain workshopsDesign workshopsPrototypingPilot experimentsSimilar companiesAsk suppliersNegotiationRisk analysisCost / benefitGoal-domain analysisDomain-reqs analysis

From: Soren Lauesen:Software Requirements© Pearson / Addison-Wesley 2002

How much do we know about:

(scale 0-5)27/10 . . .

Present work

Present problems

Goals & key issues

Future system ideas

Realistic possibilities

Effect and risk

Commitment

Conflict resolution

Requirements

Priorities

Completeness

Status indicators - scale 1-5

30. Experiences from West Zealand County

Traditional

Write requirements

Ask everybody.All come up with wishes.

Merge to one document.Few understand the spec.

Time: 25 weeks.

Assess proposals

Everybody has an opinion.

Political choice.

Time: 10 man-months.

Fast version

Write requirements

Team of three write spec,particularly tasks.

Everyone can correct tasksand add potential solutions.

Time: 3 weeks (first time)

Assess proposals

Carry out the tasks and ratethe system.Ask selected stakeholders.No doubt.

Time: 1 man-month.

31. Early proof of concept, from SL-07

High-risk requirement areas:- Efficient support of basic user tasks- Adequate usability- Response time with the planned number of users- Possibility for third-party integration with other

systems

The customer considers these areas crucial for long-term success. Substantial deficiencies in these areas can hardly be corrected late in the project.

Risk reduction:Set up a test system with simulated load.

Usability test of mockup.

Have third party make an integration.

To reduce the risk, the supplier must within __ working days after signing the contract prove that he can handle these areas. (The customer expects 40 days.)

If the customer is not satisfied with the proof, he can terminate the contract.

Usability requirements

Examples:The system works as intended by theprogrammer, but the user:

P1. Cannot figure out how to start the search. Finally finds out to use F10.

P2. Believes he has completed the task, but forgot to click Update.

P3. Sees the discount code field, but cannot figure out which code to use.

P4. Says it is crazy to use six screens to fill in ten fields.

P5. Wants to print a list of discount codes, but the system cannot do it.

33. Usability problems

Severity classes:

1 Missing functionality(not really usability)

2 Task failure

3 Annoying, cumbersome

4 Medium problem (succeeds after a long time)

5 Minor problem (succeeds after a short time)

Critical problem =Missing functionality, task failure, or annoying

+ For many users

Purpose:Find usability problems

34. Usability test - think aloud

UserPerforms tasksThinks aloud

Log keeperListensRecords problems

FacilitatorListensAsks as needed

I try this because ...

User doesn’tnotice ...

Must be done before programming - Use mockups

35. Usability requirements

Problem countsR1: At most 1 of 5 novices shall encounter critical problems during

tasks Q and R. At most 5 medium problems on list.

Risk

Cus

t.S

uppl

.


Keystroke countsR3: Recording breakfast shall be possible with 5 keystrokes

per guest. No mouse.

Task timeR2: Novice users shall perform tasks Q and R in 15 minutes.

Experienced users tasks Q, R, S in 2 minutes.

Opinion pollR4: 80% of users shall find system easy to learn. 60% shall

recommend system to others.

Score for understandingR5: Show 5 users 10 common error mesages, e.g. Amount too

large. Ask for the cause. 80% of the answers shall be correct.

Details: A novice has got 5 min instruction ...Task Q: John Simpson calls to reserve a room ...

Testing

Analysis

Design

Program

37. Sources of test cases

Users

Design spec

Code

Domain reqs

Tester'stricks

Test cases:

User test . . .Beta test

Support tasks T1-T34.At most 5 critical problems.

Screens: . . .Buttons: . . .

Branch test, empty loop

Date blank, name okDate ok, name blank

Limit test, illegal valuesRoom 1000Room a7%

Carry

out

task

Usabi

lity te

st

Check in from streetCheck in booked guest Inspect screens

Try buttons

Find guest, many matchesFind guest, no match

38. Fredericia Shipyard - specializing in repairs

Many local subcontractors, plummers, painters, . . .

Loses orders when quotation price too high. Loses money when price too low.Stress at invoicing - shipowner loses 500.000 DKK for each day the ship stays.Outdated IT system - not maintainable. Cannot handle drawings, etc.

40. Shipyard ERP - which requirement?

R1. Our pre-calculations shall hit within 5%

R2. The system must record and use experience data in these tasks- Cost recording- Quotation calculation

R3. The system must have functions for recording and retrieving experience data

R4. The system must have the screens shown in App. D.

Goal-levelrequirement

Domain-levelrequirement

Product-levelrequirement

Design-levelrequirement


The correct choice depends on the kind of supplier: - ERP supplier - SW-house without business expertice - Business consultant (KPMG, Deloitte)

Documents

Requirements, use cases and tasks Søren Lauesen, February 2011 IT-University of Copenhagen E-mail: [email protected]