1

Requirements Elicitation Techniques

Collaborative Requirements gathering. Quality Function Deployment. User Scenarios Elicitation Work Products

2

When does collaboration occur?

When people choose to collaborate. A belief that there is more to be gained

by collaborating than by competing. People choose to collaborate when they

see their personal and organization interests are acknowledged, valued and taken into account.

3

Why collaboration is so difficult?

Collaboration is about “not competing”.We spend more time learning (and being

rewarded) to compete, than collaborating.“You must have missed school the day you

were taught sharing in Kindergarten” - Diane Fisher, 2002

4

Collaborative Requirements Gathering

Meetings are conducted and attended by all interested stakeholders.

Rules for preparation and participation are established.

An agenda is suggested.A “facilitator” controls the meeting.A “definition mechanism” (work sheets,

wall stickers) is used.

5

Quality Function Deployment (QFD)

QFD defines requirements in a way that maximizes customer satisfaction.Function deployment is used to determine the

value of each function that is required for the system.

Information deployment identifies data objects and events that the system must consume and produce.

Task deployment examines the behavior of the system.

Value analysis determines the priority of requirements.

6

QFD identifies three types of requirements Normal requirements Expected requirements Exciting requirements

Quality Function Deployment (QFD)

7

Normal requirements

These requirements reflect objectives and goals stated for a product or system during meetings with the customer.

Examples of normal requirements might be requested types of graphical displays, specific system functions, and defined level of performance.

8

Expected Requirements

These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. Their absence will be a cause for significant dissatisfaction.

Examples of expected requirements are ease of human/machine interaction, overall operational correctness and reliability, and ease of software installation.

9

Exciting Requirements

These requirements reflect features that go beyond the customer’s expectations and prove to be very satisfying when present.

For example, word processing software is requested with standard features. The delivered product contains a number of page layout capabilities that are quite pleasing and unexpected.

10

Use-CasesA use-case scenario is a story about how

someone or something external to the software (known as an actor) interacts with the system. Use-Cases, identify the who, what, and how

of system behavior.Use Cases describe the interactions between

a user and a system, focusing on what the system “does” for the user.

The Use Case model describes the totality of the systems functional behavior.

11

Use-Case Diagram

12

Elements of the Analysis Model

• Scenario-based elements– Use-case: How external actors interact with the

system (use-case diagrams)– Functional: How software functions are processed

in the system (flow charts; activity diagrams)• Class-based elements

– The various system objects (obtained from scenarios) including their attributes and functions (class diagram)

• Behavioral elements– How the system behaves in response to different

events (state diagram)• Flow-oriented elements

– How information is transformed as it flows through the system (data flow diagram)

13

Class Diagram

14

State Diagram

15

Activity Diagram for RE