1

REQUIREMENTS ENGINEERINGand

SYSTEMS ANALYSIS

Elements and Definitions

2

Requirements

System Design

Detailed Design

Implementation

Installation & Testing

Maintenance

Software RequirementsSpecification - SRS

3

Who does requirements engineering?

requirements engineer

customer

system designer

4

What are the activities?

problem analysis

product description

“complete” understanding of requirements

consistent SRS

customer needs

5

• Problem Analysis:– understand the

problem (space)– expand information– specify constraints:

•find them•analyze them•resolve conflicts

– specify the solution space

• Product Description:– describe the problem– compress information– set limits:

•constraints•assumptions

– check•completeness•consistency

6

Levels of Software Requirements

Business Needs

BusinessRules

System Requirements

Constraints- e.g., standards,

architecture

Customer Satisfaction

User Satisfaction

Tester Support

DevelopersSupport

Vision & Scope Document

Business Requirements

Quality Attributes

Use Case Document

Software Requirements Specification

UserRequirements

FunctionalRequirements

Other Extra-functionalRequirements

User Expectations

7

Components of Requirements Engineering

Requirements Engineering

Requirements ManagementRequirements Development

Elicitation

Analysis

Modeling & Specification

Verification & Validation

Change Control

Version Control

Tracing

Status Tracking

8

Typical Methods & Techniques

• interviews• hands-on experience• documentation analysis• scenarios• (formal) description• completeness and consistency checking• conflict resolution techniques

9

The Product: SRS

• Standards:– IEEE / ANSI 830-1984– DoD 2167A / DI-MCCR-80025A (SRS)– NASA SFW-DID-08 (SRS)– company internal standards?

10

Elements of an SRS

• user goals• context description• behavioral/functional requirements• non-behavioral/extra-functional requirements• constraints• assumptions

===> WHAT

11

NOT included in an SRS:

• project management• design information• quality assurance plans• staffing• cost analysis

===> HOW

12

An SRS should be:

• correct• non-ambiguous• complete• verifiable• consistent

• understandable• modifiable• traceable• annotated

===> formal vs. informal requirements specification

13

IEEE Std 830-1984

1. Introduction1.1 Purpose of SRS1.2 Scope of product1.3 Definitions, acronyms, abbreviations1.4 Overview

14

IEEE Std 830-1984

2. General description2.1 Product perspective2.2 Product functions2.3 User characteristics2.4 General constraints2.5 Assumptions and dependencies

15

IEEE Std 830-1984

3. Specific requirements3.1 Functional requirements3.2 External interface requirements3.3 Performance requirements3.4 Design constraints3.5 Attributes3.6 Other requirements

Alternatives!

16

End of Section 2a

coming up:Data Flow Diagrams