Software Requirements:Overview and MotivationSoftware Requirements:

Overview and Motivation

Gruia-Catalin Roman and Christopher Gill

CSE 436 January 2007Department of Computer Science and Engineering

[ §1 : 2 ]

Overview of Requirements Topics

[1] Software Crisis (the motivation)

[2] Life-Cycle Perspective (the context)

[3] Software Requirements (the ideas)

[4] Processes (applying the approach)

[5] Products (results and artifacts)

[6] Basic Methods (foundational techniques)

[7] Complex Models (advanced techniques)

[8] Reviews (evaluation and feedback)

[ §1 : 3 ]

1. Software Crisis (the motivation)

Overview

1.1 Symptoms 1.2 Causes 1.3 Costs 1.4 Response

[ §1 : 4 ]

1.1 Symptoms Systems are being delivered late and over budget

Denver Airport (losses of $1.1 million/day) FAA ($1 billion over budget, five years late)

Systems under development are canceled due to emerging gaps between projected capabilities and

understood needs two out of six major projects suffer this fate

[ §1 : 5 ]

1.1 Symptoms, Continued

Completed systems meet the needs of the user only in part

Some needs may never have been captured Capture may not have been rigorous / detailed Needs may have been out of scope for $ or time budgets

Completed systems are never installed These problems are not limited to large and complex

systems

[ §1 : 6 ]

1.2 Causes

Complexity System requirements Weak management controls Lack of technical maturity

[ §1 : 7 ]

1.3 Costs The cost of correcting an

error grows very rapidly as the project moves along its life-cycle

This observation argues for early error detection and provides the motivation for technical reviews

The highest cost errors are those involving the systems requirements formulation

error correction cost

point of

detection

[ §1 : 8 ]

Implications

Problems relating to the identification and documentation of system requirements present the highest risk for a project

Investments in other areas of the software development process can be easily undercut Costs incurred by problems with the requirements … take away time and $ from design,

implementation, testing, upgrades, etc.

[ §1 : 9 ]

Implications, Continued

Meaningful measurement and evaluation must consider the key relation between error introduction points error detection points

Otherwise errors can persist, even propagate Limits effectiveness of the quality assurance Introduces weaknesses in development process

[ §1 : 10 ]

1.4 Response

There is no silver bullet for the very difficult task of requirements definition and management

The state of the art, however, is very much ahead of the state of the practice

What you learn in this course, you can apply with impact A standardized framework can be the conduit for

bridging the gap increased awareness common terminology assimilation of very basic practices

[ §1 : 11 ]

Capability Maturity Model Capability Maturity

Model (CMM) A framework designed to

facilitate the introduction of basic sound practices across the industry

CMM does not solve the technical problem

CMM facilitates the adoption of sound technical and managerial practices

Optimizing (5)

Managed (4)

Defined (3)

Repeatable (2)

Initial (1)

... Software project planning

Requirements management

[ §1 : 12 ]

Repeatable Level

Key process areas

Requirements management Software project management Software project tracking and oversight Software subcontract management Software quality assurance Software configuration management

[ §1 : 13 ]

Requirements Management

Goals Requirements are controlled

to establish a baseline for technical and managerial use

Plans, products, and activities are kept consistent with the requirements

Commitment to perform The project follows a written

organizational policy for managing system requirements

Ability to perform Responsibility is established

for analyzing and allocating the requirements

Requirements are documented

Resources are provided for managing the requirements

Training is provided

[ §1 : 14 ]

Performance

Activities performed Requirements are reviewed prior to use Requirements are used as a basis for plans,

products, and activities Changes to allocated requirements are

reviewed

[ §1 : 15 ]

Controls

Measurement and analysis Measurements are made and used to determine the

status of the activities for managing the requirementsVerifying implementation Activities for managing requirements are reviewed

with senior management Activities for managing requirements are reviewed

with the project manager The software quality assurance group reviews

activities and products