Requirements GatheringRequirements Gathering

How do we find out what we are supposed How do we find out what we are supposed

to be building?to be building?

Why good Specs are Essential:

$$ It is VERY expensive to fix problems late in the process.

It is very cheap to rewrite or clarify a written spec.

What costs $1 to fix at ReqGathering $5 in the design stage $10 in the coding stage $20 in the unit testing phase $200 after delivery

Types of RequirementsTypes of Requirements Functional

ex - it must email the sales manager when an inventory item is "low"

Non-Functional ex - it must require less than one hour to run

Explicit ex – required features

Implied ex – software quality

Forgotten ex – exists in current process

Unimagined

Requirements of RequirementsRequirements of Requirements

Clear

Measurable

Feasible

Necessary

Prioritized

Concise

Req Gathering Problems

Accommodating changing reqs Being complete, without being constraining Conflicting views Ease of omitting obvious info Identifying the experts and getting

authority to talk to people Incomplete understanding of the problem

on the part of the user/customer Sticking with “what” and not “how” Determining what is critical Avoiding mission creep

Requirements WILL Change

Requirements Engineering Tasks

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

7. Management

Software Engineering: A Practitioner’s Approach by Roger Pressman

Inception

Project starts due to a business decision

Software Engineer Asks: What is the basic problem Who wants a solution Nature of solution

Inception

Project starts due to a business decision

Software Engineer Asks: What is the basic problem Who wants a solution Nature of solution

First Questions:1. Who is behind the request for work?2. Who will use the solution?3. What will be the economic benefit of success?4. Is there another source for the solution?

Elicitation via Interviews

Elicitation via Interviews

Difficulties: Ill-defined project scope

Unnecessary details that confuse

Not sure what they need

Poor understanding of capabilities

Omitting the “obvious”

Requirements that conflict with other people’s requirements

Requirements Change!!!

Elicitation via Interviews The list of involved stakeholders must be

broad!!!! Use real users.

Meetings include the SwEngs and the stakeholders

Use agendas that cover the important points yet encourage flow of ideas

Use wall-stickers, flip-charts, … Ahead of time, the participants should build

a partial list of the functions, performance criteria, environment factors, …

Start with scope and context, move to functions

Elicitation via Use Cases Diagrams composed of Actors and Actions

AnonymousUser

RegisteredUser

Credit CardSystem

Create Account

Manage Account

Logout

Elicitation via JAD

Joint Application Design JAD Sessions Participants:

Executive Sponsor Project Leader Facilitator – trained and experienced Recorder Participants Observers – developers who sit on sideline and don’t talk

Outputs of sessions: Data flow diagrams Data requirements List of assumptions etc

Elicitation via QFDSince 1966, Quality Function Deployment (QFD) has been used world wide

in nearly every industry and sector to: 1. Prioritize spoken and unspoken customer wows, wants, and needs; 2. Translate these needs into actions and designs such as technical

characteristics and specifications; and 3. Build and deliver a quality product or service by focusing various

business functions toward achieving a common goal and customer satisfaction.

www.qfdi.org

QFD uses interviews, surveys, and data (problem reports) to build a table of requirements called the Customer Voice Table.

Functional Deployment – value of each function Information Deployment – identify the input and output Task Deployment – examine system behavior Value Analysis – prioritize the requirements

Elaboration

Goal is to create an “analysis model”

Model Defines information functions

What such a model looks like is the next lecture

Negotiation

Goal is to resolve requirements that are Conflicting Costly Unrealistic

1. Identify the subsystem’s stakeholders

2. Determine their win conditions

3. Negotiate their win conditions into win-win conditions for everyone

Specification and Validation

Specification yields the SRS Format of SRS is the next lecture

Validation reviews the SRS