Requirements EngineeringRequirements Engineering

How do we keep straight what we are How do we keep straight what we are

supposed to be building?supposed to be building?

Starter QuestionsStarter Questions

What is a "requirement"?

How do we determine the requirements?

Why is requirements engineering difficult?

2

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

3

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 report #5

Explicit ex – required features

Implied ex – software quality

Forgotten ex – exists in current process

Unimagined 4

Requirements of RequirementsRequirements of Requirements

Clear

Measurable

Feasible

Necessary

Prioritized

Concise

5

Ambiguousness – example one

The control total is taken from the last record.

1. The total is taken from the record at the end of the file.

2. The total is taken from the latest record.

3. The total is taken from the previous record.

IEEE 830-1984

Ambiguousness – example two

All customers have the same control field.

1. All customers have the same value in their control field.

2. All control fields have the same format.

3. One control field is issued for all customers.

IEEE 830-1984

Why Req Eng is Difficult

8

Requirements Engineering TasksRequirements Engineering Tasks

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

7. Management

Software Engineering: A Practitioner’s Approach by Roger Pressman9

Inception

Project starts due to a business decision

Software Engineer Asks: Why do you want this What is the basic problem Who wants a solution

who wants this who will use this

Nature of solution economic benefit of success?

10

Requirements Engineering TasksRequirements Engineering Tasks

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

7. Management

11/32

Elicitation via InterviewsDifficulties

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!!!12

Elicitation via InterviewsRecommendations

1. The list of involved stakeholders must be broad include end-users, managers, etc include the software developers

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

3. Ahead of time, the participants should build a partial list of the functions, performance criteria, environment factors, …

4. Start with scope and context, move to functions

5. Use visuals such as wall-stickers, flip-charts, …

13

Elicitation via Use Cases

http://www.evanetics.com/Articles/ar_usecases/uc_valueofucd.htm

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

15

Requirements Engineering TasksRequirements Engineering Tasks

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

7. Management

16/32

Elaboration

Goal is to create a modelmodel that defines:1. information2. functions

Models could be ER Diagrams Use Cases Data Flow Diagrams all of the above

htt

p:/

/ww

w.c

am

sp.c

om

/corn

ers

tone/a

ssets

/im

ag

es/

reso

urc

es/

when_u

se_m

ap

s_sm

.png

17

System ModelingSystem Modeling

Function & Information Flow Model what we will do with the data

Data Model structure of the information

Behavior Model how we interact with the

system

Data Modeling

Data Objects, Attributes, Relationships Formatted as Lists or Tables

Entity Relationship Diagrams

securitysystem

sensor

monitors

enables/disables

tests

programsis programmed by

Behavior Modeling

State Transition Diagram

1 32

4

start

read msg save msg

file namedone

composesend

Requirements Engineering TasksRequirements Engineering Tasks

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

7. Management

21/32

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

22

Requirements Engineering TasksRequirements Engineering Tasks

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

7. Management

23/32

Technically Speaking,"requirement" ≠ "specification"

Requirement – understanding between customer and supplier

Specification – what the software must do

Requirements that are not in the SRS Costs Delivery dates Acceptance procedures etc

24

IEEE 830

Characteristics of a Good SRS

1. Unambiguous

2. Complete

3. Verifiable

4. Consistent

5. Modifiable

6. Traceable

7. Usable during the Operation and Maintenance Phase

25

IEEE 830

Role of SRS1. “The SRS must correctly define all

of the software requirements, but no more.”

2. “The SRS should not describe design, verification, or project management details, except for required design constraints.”

26

SRS Table of Contents

1. Introduction1. Purpose2. Scope3. Definitions4. References5. Overview

2. General Description1. Product Perspective2. Product Functions3. User Characteristics4. General Constraints5. Assumptions and Dependencies

3. Specific RequirementsIEEE 830-1984

3. Specific Requirements 3.1 Functional Requirements 3.1.1 Func Req 1 3.1.1.1 Introduction 3.1.1.2 Inputs 3.1.1.3 Processing 3.1.1.4 Outputs 3.1.2 Func Req 2 … 3.2 External Interface Requirements 3.2.1 User Interface 3.2.2 Hardware Interfaces 3.2.3 Software Interfaces 3.2.4 Communication Interfaces 3.3 Performance Requirements 3.4 Design Constraints 3.4.1 Standards Compliance 3.4.2 Hardware Limitations 3.5 Attributes 3.5.1 Security 3.5.2 Maintainability 3.6 Other Requirements 3.6.1 Database IEEE 830-1984

Non-830-Style Requirements

User stories encourage the team to defer collecting details. An initial place-holding goal-level story ("A Recruiter can post a new job opening") can be written and then replaced with more detailed stories once it becomes important to have the details. This technique makes user stories perfect for time-constrained projects. A team can very quickly write a few dozen stories to give them an overall feel for the system. They can then plunge into the details on a few of the stories and can be coding much sooner than a team that feels compelled to complete an IEEE 830–style software requirements specification.

Quote from "Advantages of User Stories for Requirements"By Mike Cohn

http://www.awprofessional.com/articles/article.asp?p=342885&seqNum=3

Other Specification Techniques

Use Cases

Formal Specification Languages e.g. Petri Nets

http://www.cs.indiana.edu/classes/p465/Lect/Images/petri-img-10.jpg

Requirements Engineering TasksRequirements Engineering Tasks

1. Inception

2. Elicitation

3. Elaboration

4. Negotiation

5. Specification

6. Validation

7. Management

31

Next ClassesNext Classes

Risk Analysis and Management Metrics Managing the Testing Process