Requirements Analysis

Overview

To frame our discussion, consider:

What is the nature of software requirements?

How are requirements determined?

What techniques are useful for understanding system models?

OUTLINE

Objectives
Qualities of the SRD
Analysis Principles
Information Capture
Requirements Management
References

The Objectives of Requirements Analysis

To Obtain a clear, complete, agreed-upon requirements specification.

Requirements describe:

User-level behaviors or functionality (features)
General system properties
Definitions of other systems which must be integrated
Specific operational constraints
Domain rules (e.g., computation)
Development constraints

For Clarity

Define all special terms used
Work toward Successive Elaboration
Use Pictorial Representations of the System
Key all requirements to the representations
Keep the requirements at the level of external behavior
Keep requirements consistent with one another

For Completeness

Tell what users need and how well this must be done
Functional Requirements -- what will be accomplished
Data Base Requirements -- data items and groups of data items to be stored
Performance Requirements --
Hardware and software systems involved

For agreed-upon -- validation

Qualities of the SRD

correct	Every requirement is something required of the system.
nonambiguous	Every statement has one interpretation.
complete	Everything that matters is covered in the document.
verifiable	The built system can be checked to see if requirement is met.
consistent	There are no conflicts between requirements.
understandable	The form the document takes should allow the different audiences to gather the information they need.
modifiable	Changes to the requirements can be accommodated.
traceable	Each requirement exists because there was a need in the problem domain. Activity in the solution domain should be able to relate back to the requirements.

Analysis Principles

Examine and Understand the Information Domain

Information Content
The individual data and control objects that make up the available inputs to the system.

Information Flow
The way data and control are changed as each moves through the system.

Information Structure
Defines the internal representation of the items and how information items relate to one another.
Define the functions the software must perform (requirements).
Construct a model that provides an increasing level of detail regarding the functions the software must provide.
Represent the behavior of the software.
A behavioral model represents the states of the software and the events that cause software to change state.

Information Capture

Data/Data Flow
Process/Function
Control/Control Flow
Communication
Behavior
Concurrency
Timing/Synchronization
Relationships
- Temporal
- Dependency
- Constraints
- Aggregation
- Decomposition
- Hierarchy
Rationale
History
??

The software requirements provide a basis for creating the Software Requirements Specifications (SRS). The SRS will aid in estimating cost, planning team activities, performing tasks, and tracking the team's progress throughout the development activity. Requirements management is the process of managing these project resources that are called requirements. The process will help to establish a common understanding between the customer and the project team of stakeholder's requirements.

Traceability

A critical part of the requirements change management is assessment of the impact of a requested change. Impact assessment depends on traceability.

Traceability information

defines requirements dependencies
provides requirements rationale
connects requirements to implementation

Types of Traceability

Backward-from: Links requirements to their source
Forward-from: Links requirements to design and implementation
Backward-to: Links design and implementation to requirements
Forward-to: Links prior documents to requirements

Go To Lecture [Outline] [Overview]

Go To [311 Course Outline] [CIS Department Page]

References

Davis, A. (1995) Software Requirements. Englewood Cliffs, NJ: Prentice Hall.

Martin, C. (1988) User Centered Requirements Analysis. Englewood Cliffs, NJ: Prentice Hall.

Pfleeger, S. (1987) Software Engineering. New York: Macmillan.

Zave, P. & M. Jackson (1997) Four Dark Corners of Requirements Engineering. ACM Trans. on Software Engineering and Methodology, 6(1), p. 1-30.