Software Requirements Third Edition

Chapter 4

Requirements elicitation

“Elicitation is a collaborative and analytical process that includes activities to collect, discover, extract and define

requirements.”

Rules

Create an environment conducive to a thorough

exploration of the product being specified

• Use vocabulary of the business

• Record significant application domain terms in a

glossary

• Customers must understand that ta discussion

about possible functionality is NOT a commitment

• Brainstorming and imagining the possibilities is a

separate matter from analyzing priorities,

functionality and constraints.

Requirements Elicitation Process

Figure 7-2 Activities for a single req’ts elicitation session

Perform

elicitation

activities

Decide on

elicitation

scope and

agenda

Prepare

resources

Prepare

questions

and straw

man models

Perform

elicitation

session

Organize

and share

notes

Document

open issues

Prepare for elicitation Follow up after elicitation

Req’ts elicitation techniques

Facilitated activities and independent activities

1. Interviews

2. Workshops

3. Focus Groups

4. Observations

5. Questionnaires

6. System interface analysis

7. User interface analysis

8. Document Analysis

Interviews

• One on one or small-group – facilitated

• User buy-in to the process

Tips (prepare):

Establish rapport

Stay in scope

Prepare questions and straw man models ahead of

time

Suggest ideas

Listen actively!!!

Workshops

“Facilitation is the art of leading people through processes toward agreed-upon objectives in a manner that encourages

participation, ownership, and productivity from all involved.”

Tips:

• Establish and enforce ground rules

• Fill all of the team roles

• Plan an agenda

• Stay in scope

• Use parking lots to capture items for later consideration

• Timebox discussion

• Keep the team small but include the right stakeholders

• Keep everyone engaged

Focus Groups

“A representative group of users who convene in a

facilitated elicitation activity to generate input and ideas

on a product’s functional and quality requirements.”

• Useful for exploring users’ attitudes, impressions,

preferences… when you do not have access to users

within your company.

• Focus groups must be facilitated.

• Keep on topic without influencing the opinions

expressed

Observations

… you can often learn a lot by observing exactly how users perform their task.

Observing a user’s workflow in the task environment allows you to:

• validate information collected from other sources,

• identify new topics for interviews,

• see problems with the current system, and

• identify ways that the new system can better support the workflow.

Silent observations are appropriate when busy users cannot be interrupted

Interactive observations allow you to interrupt the user mid-task and ask questions.

Questionnaires

Preparing well-written questions is not easy!

Suggestions:• Provide answer options that cover the full set of possible

responses

• Make answer choices both mutually exclusive (no overlaps in numerical ranges) & exhaustive

• Don’t phrase a question in a way that implies a ‘correct’ answer

• If you use scales, use them consistently throughout the questionnaire

• Use closed questions with two or more specific choices if you want to use the questionnaire results for statistical analysis. Open-ended questions allows users to respond any way they want.

• Consider consulting with an expert in questionnaire design and administration…

• Always test a questionnaire before distributing it.

• Don’t ask too many questions or people won’t respond

System interface analysis

• Independent elicitation techniques that entails

examining the systems to which your system

connects.

… reveals functional req’ts regarding the exchange of

data and services between systems.

Context diagrams… and obvious choices to begin

finding interfaces

User interface analysis

• Technique used to study existing systems to discover

user and functional req’ts.

• Best to interact with the existing systems directly…

but if necessary use screen shots

• UI analysis can help you identify a complete list of

screens to help you discover potential features.

Document analysis

• A way to get up to speed on an existing system or

new domain.

• Although… I would guess that the available

documents are not up to date … or even available.

Planning elicitation on your project

An elicitation plan includes techniques you use, when

they will be used and for what purpose.

The plan should address:

• Elicitation objectives

• Elicitation strategy and planned techniques

• Schedule and resource estimates

• Documents and systems needed for independent elicitation

• Expected products of elicitation efforts

(use cases, an SRS, an analysis of questionnaire results, or quality

attribute specs… make sure you target the right stakeholders)

• Elicitation risks

(what might get in the way of these activities, the severity, and

mitigation plan)

Fig 7-3 Suggested elicitation techniques by project

characteristic

Inte

rvie

w

Work

shops

Focu

s G

roups

Obse

rvat

ions

Ques

tionnai

res

Syst

em i

nte

rfac

e an

alysi

s

Use

r in

terf

ace

anal

ysi

s

Docu

men

t an

alysi

s

Mass-market SW x x x

Internal corporate SW x x x x x x

Replacing existing system x x x x x x

Enhancing existing system x x x x x

New application x x x

Packaged SW implementation x x x x

Embedded system x x x

Geographically distributed stakeholders x x x

Preparing for each session

Plan session scope and agenda

Prepare resources

Learn about stakeholders

Prepare questions

Imagine yourself learning the user’s job

Probe around the exceptions

Prepare straw man models

Perform

elicitation

activities

Decide on

elicitation

scope and

agenda

Prepare

resources

Prepare

questions

and straw

man models

Perform

elicitation

session

Organize

and share

notes

Document

open issues

Prepare for elicitation Follow up after elicitation

Performing elicitation activities

Educate stakeholders

Teach stakeholders about your elicitation approach

Explain exploration techniques

Take good notes

Exploit the physical space

Use walls… for diagrams, lists

Whiteboards

Perform

elicitation

activities

Decide on

elicitation

scope and

agenda

Prepare

resources

Prepare

questions

and straw

man models

Perform

elicitation

session

Organize

and share

notes

Document

open issues

Prepare for elicitation Follow up after elicitation

Following up after elicitation

• Organize and share notes

• Document open issues

• Classify newly gathered information

Perform

elicitation

activities

Decide on

elicitation

scope and

agenda

Prepare

resources

Prepare

questions

and straw

man models

Perform

elicitation

session

Organize

and share

notes

Document

open issues

Prepare for elicitation Follow up after elicitation

Classify customer input

Leftover… what doesn’t fit

• Req’t not related to the SW development (e.g. training)

• Project constraint (cost or schedule restriction)

• An assumption of dependency

• Additional info of historical, context setting, or descriptive nature

• Extraneous information that does not add value

Examples: Phrases that might indicate classification

category for requirements

• Business req’ts

• User req’ts

• Business rules

• Functional req’ts

• Quality attributes

• External interface req’ts

• Constraints

• Data req’ts

• Solution ideas

How to know when you’re done?

Perhaps if:

• The user can’t think of any more use cases or user stories.

• Users propose new scenarios, but they don’t lead to any new functional req’ts.

• Users repeat issues they already covered

• Suggested new features, user req’ts, or functional req’ts are all deemed to be out of scope

• Proposed new req’ts are all low priority

• The users are proposing capabilities that might be included “sometime in the lifetime of the product” rather than “in the specific product you are talking about

• Developers and testers who review the req’ts for an area raise few questions

Cautions

• Balance stakeholder representation

• Define scope appropriately

• Avoid the req’ts – versus - design arguments

• Research within reason

Assumed and Applied

“You will never document 100% of the req’ts… but

Req’t you don’t specify pose a risk that the project might deliver a solution different from what stakeholders expect.”

• Assumed req’ts

Those that people expect without having explicitly expressed them.

• Implied req’ts

Those that are necessary because of another req’t but aren’t explicitly stated.

Developers can’t implement functionality they don’t know about.

Finding missing req’ts

• Decompose high-level req’ts… so you know exactly

what is being requested.

• Ensure that all user classes have provided input… and

each user req’t has at least one identified user class

who will receive value.

• Trace system, user, event response lists, and business

rules to their corresponding functional req’ts.

• Check boundary values for missing req’ts.

• Represent req’ts information in more than one way…

it difficult to read a mass of text and notice if an item

is absent.

Finding missing req’ts

• Sets of req’ts with complex Boolean Logic often are

incomplete… and wrong.

• Create a checklist of common functional areas to

consider for your projects… error logging, backup

and restore, access security, reporting, printing,

preview capabilities, and configuring user interfaces.

• A data model can reveal missing functionality.

All data entities that the system will manipulate must have

corresponding CRUD functionality,