1

User Requirements Phase

Drawn from Sommerville and S. Lauesen, Software Requirements, Styles and

Techniques, Addisson Wesley, 2002

2

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

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

Product

Platform

Other systems

Product I/O

Domain I/O

Inner Domain

Outer orBusiness Domain Actors

Stakeholders

5

Scale of Requirements(responsibility)

Precalculations shall be accurate to within 5%

Goal-level requirement

Product shall support cost recording and quotation with experience data

Domain-level requirement

Product shall have recording and retrieval functions for experience 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?

6

The Typical URD

1. Introduction: including business goals2. Limits of the system: scope and interfaces3. Data requirements: data model + dictionary4. Product functional requirements: function

lists, feature reqs, process descriptions5. Quality requirements: non-functionalDocumentation standards: PSS-05, IEEE 830

7

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

8

Types of RequirementsNon-Functional (AKA Quality) Requirements:• “everything else”• The product• The development process• The system environment

• We can place these in a taxonomy (Sommerville) with a checklist function

• See also:– McCall and Matsumoto (1980)– ISO 9126– IEEE 830 (software requirements specifications)

9

Non-functional

Product Organizational External

Usability

Efficiency

Reliability Portability

speed

throughput

memory

delivery

implementation

standards

legislative

interoperability

ethical

privacy/security

safety commercial

10

Requirements Capture

• An iterative dialog between

• End-usersRequirements

Analysts

Using a variety of tools and techniques

11

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

12

Capture techniques

A good analyst:1. knows many techniques,2. knows when to use them and when not,3. Combines and modifies techniques according

tospecific needs.

13

Techniques1. Stakeholder analysis (small scale, who, what, why, risks, costs, solutions?)2. (Group) interview (recorded, taped, filmed)3. Observation (see also ethnography / immersive studies)4. Task demo (“here’s how I usually …”)5. Document studies (company info)6. Questionnaires (large scale, capture statistics & opinions, open/closed questions)7. Brainstorm (unstructured – anything goes)8. Focus groups (structured)9. Domain workshops (business process)10. Design workshops (interface ideas)11. Prototyping (product-level reqs., design-level reqs.)12. Pilot experiments (COTS?)13. Similar companies/ Related products14. Ask suppliers (they know their customers)

14

Example: Organizing a Focus Group

1. Invite participants: 6-18 people, all stakeholders represented, max 30% are suppliers

2. Open the meeting: present the topic, let people get to know each other and relax

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

15

Focus Group (continued)

4. Imagine the Future: Invite ideas, invite speculation. Ask: why/when do you want this? Record ideas.

5. List the issues: edit on the fly, regroup and organise, combine similar. Record issues.

6. Prioritize issues: Each stakeholder group picks top ten – but don’t prioritize within these to avoid conflict.

7. Review the lists: rountable comment, and close the meeting

16

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!

17

Requirements Analysis

• Analysis involves several types of checks and tests that can be carried out:

• Validity• Consistency• Completeness• Realism• Verifiability

18

Validity• Problem: User may have incorrectly defined a functional

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

19

Consistency

• Problem: User may state requirements that contradict each other (Common with many end-users!)

• E.g. year + 1 > yearyear is a 2-digit number99 + 1 = 00 > 99

contradiction!

Simplified model of the Year 2000 Problem

20

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

21

Completeness

• Problem: user may have forgotten some requirements, leaving holes in the requirements document. These may possibly be solved arbitrarily … but possibly not!

• Methods: – Rapid prototyping– URD reviews– Test case generation– Use cases analysis– Tables– Fault/ decision trees

22

Realism (Feasibility)

• Problem: User may express requirements that or not technically feasible (e.g. performance) or violate some non-functional requirement (e.g. legislative)

• Methods: – Prototyping– Mathematical model/simulation (e.g queueing theory)– URD reviews– External advice (e.g. lawyers)

23

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

24

Numerical Quality RequirementsRequirement 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

25

Usability = fit for use + ease of use

The five (ease of) usability factors (Schneiderman 1998):1. Ease of learning2. Task efficiency3. Ease of remembering4. Subjective satisfaction5. Understandability

Some developers claim we cannot optimize all 5, if so … which to prioritize?

26

Usability MetricsMeasure 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

27

Score for understanding: Show 5 users 10 common error messages. Ask for explanation of cause. 80% of the answers shall be correct

medium low

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 low

Development process requirements: Three prototype versions shall be made and usability tested during project.

medium

28

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 …

29

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

30

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?)

31

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

32

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 end-users

33

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

34

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

Options1. Class Diagram (OO analysis) 2. Entity-Relationship diagram (Database theory)3. Data dictionary: terms and meanings4. Data expression: format and legal values. Use regular expressions or DTDs.

35

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

36

1. Double room used as single 25%

2. Family with more than one room, discount for additional rooms

10%

3. Discount at immediate checkin

a. Before 6pm and hotel less than 50% occupied, fair weatherb. Before 6pm and hotel less than 50% occupied, bad weather

a. 25%b. 0%

Requirement x. The product shall suggest the following discount rates if a customer asks for a discount.