5 requirementselicitation

8/2/2019 5 RequirementsElicitation

1/30

Page 1

ENGR2720U

ENGR2720

Software Design II

Notes taken from Requirements Engineering for SoftwareSystems, P.A. Laplante

Requirements Elicitation

Techniques


2/30

Page 2

ENGR2720U

Background

In this lecture I will present several different techniques for solicitingrequirements. Which include:

BrainstormingCard SortingDesigner as Apprentice

Domain AnalysisEthnographic ObservationGoal-based ApproachesGroup WorkInterviewsIntrospection

Joint Application Development(JAD)

LadderingProtocol AnalysisPrototyping

Quality Function Deployment(QFD)QuestionnairesRepertory GridsScenariosTask Analysis

User StoriesViewpoints


3/30

Page 3

ENGR2720U

Brainstorming

Informal sessions with Stakeholders togenerating overarching goals for the system.

Meetings can be formal but formality is inversely

related to creativity level exhibited at themeeting.

Prefer informal over formal but use a recorder.

The outcome may be some preliminaryrequirements but it is primarily a way to get newideas into the process.

Good for general objectives such as mission or vision

statements.


4/30

Page 4

ENGR2720U

Card Sorting

Stakeholders complete a set of cards that includes keyinformation about functionality for the system/softwareproduct.

Include ranking and rationale for each of the functionalities.

It is recommended that a minimum of 1 week and nomore that 2 be given to complete the cards.

Requirements engineer sorts the cards based on groupsof requirements types.

These cards can also be used to as an input to the process CRC(capability, responsibility, class) that is used to develop classesfrom the requirements.

Customer can be shown the sorted cards forcorrection or missing features.


5/30

Page 5

ENGR2720U

Designer as Apprentice

Designer Engineer looks over the shoulder of thecustomer to basically learn what the software might do.

Customers do not have to have any form of teachingability since many persons can easily talk about what

they are doing as it unfolds.Seeing the work reveals what matters.

Some actions occur because of years of experience and thecustomer cannot recollect easily when interviewed.

In order for this to work the SE must understand thestructure and implication of the work.

The designer must demonstrate an understanding of thework to the customers so that any misunderstandingscan be corrected.


6/30

Page 6

ENGR2720U

Domain Analysis

Basically this point emphasizes that domainanalysis is key for the developer.


7/30Page 7

ENGR2720U

Ethnographic Observation

Any technique in which observation of indirect and directfactors inform the work of the requirements engineer.

Comes from the Social Science domain in whichobservations of human activity and the environment inwhich the occurs are used to inform the scientist in thestudy of some phenomenon.

This can be done in an active way like Designer asApprentice or passive where the SE simply observes.

It is time-consuming and takes some training to do.

It is subject to the Heisenberg uncertainty principle. When you observe something you cause a change in the environment.


8/30Page 8

ENGR2720U

Goal-Based Approaches

Requirements are recognized to emanate from themission statement, through a set of goals that lead torequirements.

Look at the mission statement and extract goals, and

finally lower-level goals that lead to specific high-levelrequirements.

Take a goal and

Derive from it what questions must be answered to determine if

they are being met. Decide what must be measured in order to be able to answer the

question.

Sometimes it is not easy to determine the appropriatequestion for some goal.


9/30Page 9

ENGR2720U

Group Work

The most celebrated group-oriented work for requirements discoveryis Joint Application Design (JAD).

Important group meeting guidelines:

Research all aspects of the organization, problems, politics,environment, and so on.

Publish an agenda.

Stay on the agenda.

Have a dedicated note taker.

Do not allow personal issues to creep in.

Allow all to have their voices heard.

Look for a consensus at the earliest opportunity

Do not leave until all items on the agenda have received sufficientdiscussion.

Publish the minutes of the meeting within a couple of days and allow forchanges.


10/30Page 10

ENGR2720U

Interviews

Opposite of group activities, a one to oneinterview.

There are 3 kinds of interviews:

Unstructured Conversational in nature, but can be hit or miss.

Structured

More formal, pre-defined questions and templates used.

Problems are that some customers might withholdinformation because format is too stodgy

Semi-structured

Preferred approach. Carefully thought out questions areprepared but the choice of which one to use is opportunistic.


11/30Page 11

ENGR2720U

Interviews Examples of Questions

Name an essential feature of the system? Whyis this feature important?

On a scale of 1 to 5, how would you rate this

feature?How important is this feature with respect toother features?

What other features are dependant on thisfeature?

What other observations can you make aboutthis feature?


12/30Page 12

ENGR2720U

Introspection

This is an important process that is even usedfor software development.

When a SE develops requirements based on he

thinks this is called introspection.Used when the SEs domain knowledge far

exceeds the customers.

Customer might ask the engineer If you were me

what would you want?

Dont tell a customer what they want!!


13/30Page 13

ENGR2720U

Joint Application Design (JAD)

Involves highly structured group meetings with system users,system owners, and analysts at the same time for extended periodsof time.

4-8 hours a day over a couple of weeks.

Code for group consensus because all the stakeholders are at the

table.Steps:

Select participants

Preparing the agenda

Selecting the location

Stakeholder groups elect a leader to attend the meeting

Before planning a session the SE must determine the scope of theproject and set the high-level requirements.

Agenda code and documentation must be sent to participants in

plenty of time to review before the meeting.


14/30Page 14

ENGR2720U

Joint Application Design (JAD) - Rules

Stick to the agenda

Stay on Schedule

Ensure the scribe can take notes

Avoid technical jargon

Resolve conflicts

Encourage group consensus

Encourage participation

Keep the meeting impersonal

Allow meetings to take as long as necessary.


15/30Page 15

ENGR2720U

Laddering

The SE asks the customer short prompting questions(probes) to elicit requirements.

Follow questions are then used to dig deeper into therequirement.

Example: SE: Name a key feature of the system?

Customer: Customer identification.

SE: How do you identify a customer?

Customer: They can swipe their loyalty card

SE: What if a customer forgets their card?

Customer: They can be looked up by phone number

SE: When do you get the customers phone number?

Customer: ..


16/30Page 16

ENGR2720U

Protocol Analysis

SE and customers walk through the proceduresthat they are going to automate.

Customer explicitly state the rationale for each

step that is being taken.Very similar to Design as Apprentice except thatSE is more passive.


17/30Page 17

ENGR2720U

Prototyping

This involves constructing a model of the system that are eitherworking or non-working.

Working models have executable code while non-working models arelike story boards and mock-ups of user interfaces.

In general user interface prototypes can be re-used in the designand most agile developers use this technique.

This is also the technique used for the spiral development processwhere incremental parts of the system are designed, tested, anddelivered

Neil and Laplante 2003 Survey

60% of respondents used prototyping for requirements gathering. 40% Interfacing

27% Evolutionary

14% Throw away


18/30Page 18

ENGR2720U

Quality Function Deployment

Technique that helps determine quality assurance pointsto be used throughout the production phase. Also knownas house of quality that is taught here to Mechanical

Engineers.

Construct relationship matrices between customerneeds, technical requirements, priorities, and competitorassessment.

Incorporates card sorting, laddering, and domain analysis.

Quality function deployment is a process of listening tothe voice of the customer, identifying the customers

needs, and incorporating those needs in the design andproduction of goods and services [Madu, 1999].


19/30

Page 19

ENGR2720U

House of Quality (Akao 1990)

The HOQ is broken into 6steps shown at right.

Customer Requirements

Planning Rankingrequirements

Technical RequirementsQuantifying requirements

Interrelationships used togenerate consensus betweendevelopment team and

customers

Roof - Considers impact oftechnical requirements on eachother.

Targets Draw conclusions.

6. Targets6. Targets

4. Inter-

relationships

4. Inter-

relationships

2.

PlanningMatrix

1.

Customer

Requirements

3. Technical

Requirements

3. Technical

Requirements

5. Roof5. Roof


20/30

Page 20

ENGR2720U

House of Quality Pros and Cons

Pros Involves the involvement of users and managers.

Shortens development lifecycle and improves overall projectdevelopment.

Supports team involvement.

Provides a preventative tool that avoids the loss of information.

Cons

Difficult to express temporal requirements.

Difficult to use with an entirely new project type.

Hard to find measurements for certain functions and keep thelevel of abstraction uniform.

The less we know the less we document

As the features grow the house of quality becomes a mansion.


21/30

Page 21

ENGR2720U

Questionnaires

Good for large group of Stakeholders.

Used in the early stages of the elicitationprocess to quickly define the scope boundaries.

Questions can be closed (only certain choices)or open (text).

There is the danger of under or over scoping

based on the questions. Better when the domain is very well understood.


22/30

Page 22

ENGR2720U

Repertory Grids

These are grids that incorporate a structured ranking system for variousfeatures of the different entities in the system.

Used when the customers are domain experts.

Rows System entities

Cols Rankings

Very much like a quality matrix that we will see later.

Baggage handling speed 1 1 5

Fault tolerance 4 5 5

Safety 5 4 4

Reliability 3 5 5

Ease of maintenance 3 5 5

Airline workers union repMaintenance engineer

Airport operations manager


23/30

Page 23

ENGR2720U

Scenarios

Informal descriptions of the system that providea high-level description of system operations,classes of users, and exceptional situations.

We will see later that scenarios can be definedfrom Use Cases.

Useful when the domain is novel. User storiesare a form of scenario.


24/30

Page 24

ENGR2720U

Task Analysis

A hierarchical oriented technique that involves afunctional decomposition of tasks to beperformed by the system.

This is very typical way of detailingrequirements.

The detailing continues until a single task is achieved.


25/30

Page 25

ENGR2720U

User Stories

User stories are similar to scenarios except thatthey are written by the customers in terms ofwhat the system needs to do for them.

Consist of 2-4 sentences written on a 3x5 card.

About 80 user stories is said to be appropriatefor one system evolution.

They should only provide enough detail to make

a reasonably low-risk estimate of how long thestory will take to implement.

Later the developers will meet with the story tellers toflesh out the details.

ENGR U


26/30

Page 26

ENGR2720U

Viewpoints

Used to organize information from the point of view of differentStakeholders.

Typically you will quickly see contradictions between theStakeholders.

Components in a viewpoint:

A representation style, which defines the notation used in thespecification.

A domain, which is defined as the area of concern addressed by the

viewpoint

A specification, which is a model of a system expressed in the define

style A work plan with a process model which defines how to build and check

the specification.

A work record, which is a trace of the actions taken in building,checking, and modifying the requirements.

ENGR2720U


27/30

Page 27

ENGR2720U

Combining Elicitation TechniquesTechnique Type Techniques

Domain-oriented Card sortingDesigner in apprenticeDomain analysisLadderingProtocol AnalysisTask Analysis

Ethnography Ethnographic observation

Goals Goal-based approaches

Group work BrainstormingGroup WorkJAD

Interviews InterviewsIntrospectionQuestionnaires

Prototyping Prototyping

Scenarios ScenariosUser stories

Viewpoints ViewpointsRepertory grids

ENGR2720U


28/30

Page 28

ENGR2720U

Techniques for Elicitation Activities

Interviews

D

omain

G

roupwork

E

thnography

P

rototyping

G

oals

S

cenarios

V

iewpoints

Understanding the domain

Identifying sources of requirements

Analyzing the stakeholders

Selecting techniques and approaches

Eliciting the requirements

ENGR2720U


29/30

Page 29

ENGR2720U

Complementary and Alternative Techniques

Interviews

Domain

Groupwork

Ethnograp

hy

Prototypin

g

Goals

Scenarios

Viewpoints

Interviews C A A A C C C

Domain C C A A A A A

Groupwork A C C C C C

Ethnography A A A C C A A

Prototyping A A C C C C C

Goals C A C C C C C

Scenarios C A C A C C A

Viewpoints C A C A C C A

ENGR2720U


30/30

ENGR2720U

Which Techniques are Used

Scenarios / User cases 51%

Focus Groups 38%

Informal modeling 33%

Semi-formal modeling 22%

JAD 20%

User centered diagrams 20%

Interviews 12%Designer as Apprentice 10%

QFD 5%

5 requirementselicitation

Documents