User Requirements Phase
Drawn from Sommerville (9th edition) Chapter 4 and
S. Lauesen, (various sections) Software Requirements,
Styles and Techniques, Addison Wesley, 2002
1
Overview
• User requirements capture and analysis is an
early phase of every lifecycle model.
• Capture means finding out what the user
wants … using different dialog techniques …
and documenting this.
• Analysis means studying the documented
requirements for errors and technical
consequences
2
Definition
(IEEE) A requirement is:
1. A condition or capability needed by a user to solve a
problem or achieve an objective
2. A condition or capability that must be met or
possessed by a system or component to satisfy a
contract, standard, specification, or other formally
imposed document
3. A documented representation of 1 or 2.
3
Terminology
• Product: the system to be delivered
• Inner domain: product + surrounding work area, immediate
users, their activities, other systems
• Outer domain: customers, “second-level users”, AKA business
domain
• Product I/O
• Domain I/O
• Product-level requirements
• Domain-level requirements
• Actor: human or external system that communicates with the
product
• Stakeholder: people who ensure the success of the project.
(Not the same as actors, why?)
4
Terminology
Outer or
Business Domain
=? Business environment
Actors
Domain I/O
Platform
Product I/O
Product
Other
systems
Inner Domain
=? company
Stakeholders
5
Why do IT projects fail?
• Annual CHAOS report (Standish Group)
• Survey of over 10,000 IT projects since 1994
– Challenged: >190% of cost estimate
– Failed: cancelled or never implemented
– Succeeded: on time, to budget
6
CHAOS = chaos!
• 31% of projects are challenged
• 53% are failed
• 16% succeed
EU ESPITI survey (1996) identified 2 major issues
1. Poor requirements specification
2. Poor requirements management
Let’s look more closely at underlying factors …
7
Success and Failure Factors (CHAOS)
• Failure factors
– Incomplete requirements
– Lack of user involvement
– Lack of resources
• Challenged factors
– Lack of user input
– Incomplete requirements and specifications
– Changing requirements and specifications
• Success factors
– User involvement
– Executive management support
– Clear statement of requirements
8
Cost Perspective
• Davis 1994, summarised cost studies by IBM,
HP etc.
Phase
Cost
Requirements Definition
1-2
Design
5
Coding
10
Unit Testing
20
Acceptance Testing
50
Relative cost of changing requirements at
different phases in an IT project
9
Some Conclusions
1. Avoid requirements
capture/analysis/management and we
probably crash the project.
2. Requirements need to be debugged as soon
as possible.
10
Requirements Types
according to RUP
• Rational Unified Process (RUP)
• A methodology to support UML users
• Three types of requirements:
1. Stakeholder requests
2. Features
3. Use cases
11
1. Stakeholders Requests (STRQ)
General requirements which describe the
stakeholders needs on a high level. Normally
elicited in the beginning of a development cycle
by listening to stakeholders needs
12
2. Features (FEAT)
High level functionality that the system shall
fulfill. Each feature should be derived from
stakeholder requests and traceable back to
them.
13
3. Use Cases (UC)
Express in a detailed way how users interact
with the system. Use cases describe how to put
and get information into and from the system. A
use case should be derived from on or more
features. Sufficient detail is needed to support
later architectural and detailed design work.
14
Example
• STRQ BUYPROD: The system shall offer
functionality for buying products.
• FEAT SEARCHNN: The user shall be able to
search for a product via article name or
number
• UC SEARCHNN:
– Step 1: User enters an article name or number
– Step 2: User asks system to find product
– Step 3: System presents product for user
15
Scale of Requirements
(responsibility)
Contract tenders shall always be
accurate to within 5%
Goal-level requirement
(Organisational)
Product shall support cost recording
and quotation with historical data
Domain-level requirement
Product shall have recording and
retrieval functions for historical data
Product-level requirement
System shall have screen pictures as
shown in App. xx
Design-level requirements
Questions:
1: what can we actually take responsibility for?
2: what is the right level of requirement?
16
Typical URD Structure
1.
2.
3.
4.
Introduction: including business goals
Limits of the system: scope and interfaces
Data requirements: data model + dictionary
Product functional requirements: function
lists, feature reqs, process descriptions
5. Quality requirements: non-functional
Documentation standards: PSS-05, IEEE 830
17
Types of Requirements
• Functional requirements: describe what the
system does, in terms of input data, output
date, error messages, etc.
• E.g. a spreadsheet, a database, a word
processor, 3D game, etc
18
Types of Requirements
Non-Functional (AKA Quality) Requirements:
• “everything else”
• The product
• The development process
• The system environment
• We can place these in a taxonomy (Sommerville) or
checklist
• See also:
– McCall and Matsumoto (1980)
– ISO 9126
– IEEE 830 (software requirements specifications)
19
Non-functional
Product
Usability
Organizational
External
Reliability Portability
Efficiency
delivery
legislative
standards
interoperability
implementation
speed
memory
ethical
throughput
privacy/
security
safety
commercial
20
Requirements Capture
• An iterative dialog between
• End-users
Requirements
Analysts
using a variety of tools and techniques
21
Why don’t we just ask the Customer?
• Stakeholders may have difficulty expressing their
needs, or may ask for a solution that doesn’t meet
their needs.
• Stakeholders can have conflicting demands
• Users find it difficult to imagine new ways of doing
things, or to imagine the consequences of what they
ask for
• A system that fulfills the requirements may not fulfill
user expectations
• Sometimes there are no users because a product is
completely new
• Demands and the environment change over time
22
Capture Techniques
A good analyst:
1. knows many techniques,
2. knows when to use them and when not,
3. Combines and modifies techniques according
to specific needs.
23
Techniques
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Focus groups (structured)
Stakeholder analysis (small scale, who, what, why, risks, costs, solutions?)
(Group) interview (recorded, taped, filmed)
Observation (see also ethnography / immersive studies)
Task demo (“here’s how I usually …”)
Document studies (company info)
Questionnaires (large scale, capture statistics & opinions, open/closed questions)
Brainstorm (unstructured – anything goes)
Domain workshops (business process)
Design workshops (interface ideas)
Prototyping (product-level reqs., design-level reqs.)
Pilot experiments (COTS?)
Similar companies/ Related products
Ask suppliers (they know their customers)
24
Example: Organizing a Focus Group
1. Set the area of focus
2.
Invite participants: 6-18 people, all
stakeholders represented, max 30% are
suppliers
3. Open the meeting: present the topic, let people
get to know each other and relax
4. Bad experiences: roundtable discussion of past
experiences with similar products or work
domains. Record issues on whiteboard. Record
ideas on whiteboard. Facilitator makes sure no
one dominates. Supplier staff are low key
25
Focus Group (continued)
5. Imagine the Future: Invite ideas, invite
speculation. Ask: why/when do you want this?
Record ideas.
6. List the issues: edit on the fly, regroup and
organize, combine similar. Record issues.
7. Prioritize issues: Each stakeholder group picks
top ten – but don’t prioritize within these to
avoid conflict.
8. Review the lists: roundtable comment, and close
the meeting
26
Requirements Analysis and Validation
• “Are we building the right product”?
• i.e. will we build the product the customer
truly wants to have? (at least at some point in
time!)
• Paradox: only the customer can determine
this … but the customer is non-technical!
27
Requirements Analysis
• Analysis involves several types of checks and
tests that can be carried out:
• Validity
• Consistency
• Completeness
• Realism
• Verifiability
28
Validity
• Problem: User may have incorrectly defined a
functional requirement. All requirements must be
checked for functional correctness
• Methods:
–
–
–
–
–
–
–
Rapid prototype
Paper model
Animation/simulation
Check existing/historic data
Test case generation
URD reviews
System User Manual
29
Consistency
• Problem: User may state requirements that
contradict each other (Common with many
end-users!)
• E.g. year + 1 > year
year is a 2-digit number
99 + 1 = 00 > 99 contradiction!
Simplified model of the “Year 2000 Problem”
30
Consistency
• Methods:
• If requirements are formal use constraint
solvers and/or CASE tools for automatic check
• Manual check, unclear, error prone,
combinatorial explosion!
• Note: problem may not be solved by
prototyping
31
Completeness
• Problem: user may have forgotten some requirements,
leaving holes in the requirements document. These
may possibly be solved arbitrarily … but possibly with
conflicts (see inconsistency!)
• Methods:
–
–
–
–
–
–
Rapid prototyping
URD reviews
Test case generation
Use cases analysis
Tables
Fault/ decision trees
32
Realism (Feasibility)
• Problem: User may express requirements that
are not technically feasible (e.g. performance) or
violate some non-functional requirement (e.g.
legislative)
• Methods:
– Prototyping
– Mathematical model/simulation
• (e.g Markov chain, queuing theory)
– URD reviews
– External advice (e.g. lawyers)
33
Verifiability
• Problem: Users may state requirements which
can never be checked/verified,
• E.g. “user interface must be user friendly and
easy to use”
• Contractual disputes may emerge
• Methods:
– Test case generation esp. acceptance tests
– Usability metrics
34
Numerical Quality Requirements
Requirement
Comment
1. Product shall detect license plate and
take photo in 0.5 seconds
Physical limits AKA hard-real time req.
2. Product shall compute a room
occupation forecast within 2 minutes
Too fast? AKA soft-real time req.
3. Product shall compute a room
occupation forecast within 4 minutes
Too slow, supplier makes no effort
4. Product shall compute a room
occupation forecast within X minutes.
Open target, but how important?
5. Product shall compute a room
occupation forecast within X minutes
(customer expects 1 minute)
Open target + expectations
6. Forecast shall be measured 10 times by
stopwatch during busy period
Customer might user other approach?
7. Forecast shall be measured by some
means specified by customer
Open metric
35
Usability = fit for use + ease of use
The five (ease of) usability factors (Schneiderman
1998):
1. Ease of learning
2. Task efficiency
3. Ease of remembering
4. Subjective satisfaction
5. Understandability
Some developers claim we cannot optimize all 5,
if so … which to prioritize?
36
Usability Metrics
Measure
Customer Risk
Supplier Risk
Problem Count: At most 1 of 5 novices shall
encounter problems during tasks Q and R
low
high
Task Time: Novice shall perform tasks Q and R in 15
minutes, experienced user shall complete Q,R,S in 2.
high
Keystroke counts: Recording breakfast shall be
possible with 5 keystrokes per guest, no mouse.
medium
Opinion Poll: 80% of users shall find system easy to
learn. 60% shall recommend system to other users
medium
high
37
Score for understanding: Show 5 users 10 common error
messages. Ask for explanation of cause. 80% of the
answers shall be correct
medium
Design-Level Requirements: System shall use screen
pictures in app. Xx, buttons work as in app. Yy
high
Product level requirements: For all code fields, user shall
be able to select value from drop-down list
medium
Guideline adherence: System shall follow style guide Zz.
Menus shall have at most 3 levels.
high
Development process requirements: Three prototype
versions shall be made and usability tested during project.
medium
low
low
38
Security Requirements
While other requirements support use-cases ...
safety requirements prevent abuse-cases.
Customer has certain assets to be protected
against threats.
We will examine security under risk
management later …
39
Requirements Capture Languages
• Requirements need to be recorded as
precisely as possible,
• Therefore technical requirements languages
are useful
• Large variety of these in many styles
• We first consider styles: merits and demerits
40
Style: Natural Language
+ easily understood (esp. by end-user)
+ no technical training needed
+ very high-level/compact requirements
- unclear/ ambiguous
- debugging is difficult
- no inherent structure
- no tool support for validation (spell checker?)
41
Style: Structured Natural Language
E.g. tables, decision trees, fault trees, data
dictionaries
+ understood by end-user (sometimes)
+ small technical training
+ some structure (e.g. nouns, verbs, relations etc)
+ improve completeness issues
- unclear/ ambiguous
- lack of standards
- little tool support
42
Tables: a structured style
•
•
•
•
•
•
Advocated by David Parnas
Informal but structured style
Easily understood by end-users
Many formats, e.g. nested tables
Good for completeness and consistency check
Good for business rules
43
Requirement x. The product shall suggest the following discount
rates if a customer asks for a discount.
1. Double room used as single
25%
2. Family with more than one room,
discount for additional rooms
10%
3. Discount at immediate check-in
a. Before 6pm and hotel less
than 50% occupied, fair weather
a. 25%
b. 0%
b. Before 6pm and hotel less
than 50% occupied, bad weather
44
Style: Graphical Requirements
Language
e.g. UML, SDL, Petri Nets, etc
+ high-level/compact
+ quite or very precise
+ increasing tool support
+ often standardized / multiple vendors, courses,
books, consultants
- needs technical training
- rarely understood by non-IT people and endusers
45
Style: Formal Specification
Logic: e.g. OCL, JML, VDM, Z, B, temporal logic
Ad-hoc: e.g. queuing theory, Markov chain
+ good tool support for validation problems
+ can be used to generate test cases, prove code
correctness
+ extremely precise and accurate
- Needs technical training
- Poorly understood by end-users
- Notation hard to read, overly detailed or low level
46
Data Modeling
• Data models describe data inside and outside the
product
• Good for experts, maybe difficult for end-users
• Early models can survive all the way to coding
• Good for completeness/consistency checking
Options
1.
2.
3.
4.
Class Diagram (OO analysis)
Entity-Relationship diagram (Database theory)
Data dictionary: terms and meanings
Data expression: format and legal values. Use regular expressions or DTDs.
47
Data Dictionary (aka Glossary)
• A simple dictionary that defines nouns (data
classes, data objects and actors). Usually
alphabetical ordering for ease of use.
• E.g.
– Customer account : every user has a customer
account containing name, address, history …
– Address : an address has a name or number
(obligatory), a street name (obligatory), an district
name (optional) , a country name (obligatory),
and a postcode (obligatory).
48
Regular Expressions
• Regular expressions such as
ab (cd)*(e I f )+
• Can be useful to define data and file formats.
• Can define data filters to prevent file corruption
• Can write exception handlers for bad data.
• There are many “commercial” ways to define
such expressions such as
– BNF : Backus-Naur Format
– DTD : XML Data Technical Definition
– Finite automata
49