Software Engineering I

(Analysis, Design, Creation) Spring 1998

Today's class:

1. Exam 1: February 24, 1998

1. Review from last time

Last:

System Engineering

System Engineering "Hierarchy"

Systems Modeling

ISP and Modeling

System Architecture

ACD, AFD

System Specification

Re-engineering:

A Business Process ("BP") - like other processes

is a set of related tasks to achieve a defined outcome

BPR (Reengineering) is implementing change for

"breakthroughs"

Hammer suggests…

BPR is:

Define Business Goals

Identify process, prioritize

etc.

Software Re-engineering:

Maintenance is:

Corrective, Adaptive, Perfective, Preventive

Process Model

Inventory Analysis, Document restructuring,

Reverse Engineer, Restructure Code,

Restructure Data, Forward Engineering

TODAY: Requirements:

Remember you did:

"Add two numbers together, display result.

Questions:

What if last line not terminated?

Lots of error "conditions":

The test input:

1. 2.0

Requirements:

What to do.

Done between System Engineering and Design.

What, NOT how.

1. Recognize problem
2. Evaluate and synthesize
3. Model
4. Specify
5. Review

What is Requirements Engineering?Requirements engineering is a systematic process used to derive a definition of a software system that is to be developed.

FOCUS / OBJECTIVES

Develop understanding of application domain. Focus is to determine WHAT is needed from the system,

not HOW the system will achieve its goals.

System requirements - List of WHATs.

What functionality must a system provide?

Focus on the user's needs only:

To define externally observable behavior of system.

Treat system as black box

(can see WHAT, but not HOW).

Requirements analysis activities try to identify:

Software functionality/behavior.

Performance criteria.

Software interfaces with other systems.

Design constraints.

Identifying requirements requires interaction

between the analyst and the client / users.

Why is Requirements Engineering Important?

Establish the basis for agreement between client and

developer on what the software product will do.

- Helps clients better understand their own needs.

- Help developers better understand the problem.

Reduces the cost of development.

• Forces careful consideration of requirements

before design begins.

- Can reveal omissions, inconsistencies, and

misunderstandings.

- Reduces the amount of rework.

Provides a reference for validation (testing)

of the final product.

- Used to determine if software meets the requirements.

Requirements Engineering Process

Feasibility Study

Can be project be done with current technology?

Is it cost-effective to build the system?

Decide whether to continue analysis.

Requirements Analysis

Process of deriving the system requirements.

Develop understanding of the application domain.

Communicate with client and users to understand

their needs.

Requirements Definition

Record requirements into a document

Written so that customer can understand

Requirements Specification

A detailed and precise description of the system

requirements is stated.

Act as basis for contract between client and developer.

Serves as input to the design phase.

Typical Errors in Requirements

What types of mistakes are commonly made while defining requirements?

Incorrect facts

Omissions

Inconsistencies

Ambiguities

There is no such thing as perfect requirements that satisfy all

characteristics of good requirements.

Cost of Errors

The greater the distance between the phase when

an error is introduced and the phase it is found

the more it costs to fix the error.

Why?

Trickle down effect.

Implementation is based on design based on

requirements.

Arbitrarily assume it costs 1 unit to detect and

repair an error during the coding phase,

then (data from 1970's).

STAGE RELATIVE COST OF REPAIR

Requirements 0.1 to 0.2

Design 0.5

Coding 1

Unit Test 2

Acceptance Test 5

Maintenance 20

What are Good Requirements?

(Specification Principles)

Separate functionality from implementation.

A process-oriented systems specification language

is required.

A specification must encompass the system of which

the software is a component.

A specification must encompass the environment in

which the system operates.

A system specification must be a cognitive model.

A specification must be operational.

The system specification must be tolerant of

incompleteness and be augmentable.

A specification must be localized and loosely

coupled.

Requirements Analysis Process

Domain Understanding

Understand the problem to be solved

Identify and research the problem domain

Requirements Collection

Elicit the requirements.

Record the requirements.

Organize the requirements into related groupings.

Conflict Resolution

Examine requirements to find and remove conflicts.

Prioritization

Prioritize the requirements.

Requirements Validation

Check requirements.

Are they complete and consistent?

These steps interact and are not necessarily sequential!