requirements, use cases and tasks søren lauesen, february 2011 it-university of copenhagen e-mail:...
TRANSCRIPT
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.
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.
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
Subtasks and variants:
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.
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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: . . .
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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
.
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
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
From: Soren Lauesen: Software Requirements© Pearson / Addison-Wesley 2002
The correct choice depends on the kind of supplier: - ERP supplier - SW-house without business expertice - Business consultant (KPMG, Deloitte)