LESSON 4: REQUIREMENT SPECIFICATIONS

Contents
4.0.Aims and Objectives
4.1.Introduction
4.2.The Software Requirement Specification
4.3.Formal Specification Techniques
4.4.Languages and Processors for requirements specification
4.5.Review Questions
4.6.Let us Sum up
4.7.Lesson End Activities
4.8.Points for Discussion
4.9.References

4.0. AIMS AND OBJECTIVES

• To understand the sate of “what” of the software product without

implying “how”.
• Define system elements like software, hardware, people data base,
documentation, and procedures.
4.1. INTRODUCTION
A complete understanding of the software requirements is essential to
the success of a software development effort. Requirements analysis task is a
process of discovery, refinement, modeling, and specification. The specification
produced becomes the foundation for all software engineering activities.

Requirements Analysis is a software engineering task that bridges the gap

between system-level software allocation and software design (See Figure 4.1).
Requirements analysis enables the system engineer to,
• Specify software function & performance,
• Indicate software’s interface with other system elements.
• Establish design constraints that the software must meet.
Requirements analysis allows the software engineer to,
• Refine the software allocation
• Build models of the process, data and domains

55
Requirements analysis provides the software engineer,
• Information of data, architectural and procedural design.
• Means to assess software quality, with the help of requirements
specification.

System
Engineering

Requirement
Analysis

Software
Design

Figure 4.1.: Requirements Analysis - a bridge between System Engg. &

Design
Software requirements analysis may be divided into the following five areas of
effort:

Problem Recognition

Evaluation & Synthesis

Modeling

Specification, and

Review
Problem Recognition: Initially the analyst studies the system specification and
the software project plan. Next communication for analysis must be established
so that problem recognition is ensured. The goal of the analyst is to identify the
basic problem elements as perceived by the user/customer.
Evaluation & Synthesis: The analyst must define all data objects, evaluate the
flow and content of information, define software functions and establish system
interface characteristics considering the context of events that affect the system
and uncover additional design constraints.
Upon evaluating current problems and desired information, the analyst begins
to synthesize one or more solutions. To begin, the data processing functions,
and behavior of the system are defined in detail. Next basic architectures for
implementation are considered. The process of evaluation and synthesis
continues till both the customer and analyst feel confident that the software
can adequately be specified for subsequent development steps.

56
Modeling: Developing a model for an industrial-strength software system prior
to its construction or renovation is as essential as having a blueprint for large
building. Good models are essential for communication among project teams
and to assure architectural soundness. As the complexity of systems increase,
so does the importance of good modeling techniques. The analyst creates
models of the system to better understand data and control flow, functional
processing, and behavioral operation. The model serves as a foundation for
software design and as the basis for the creation of a specification.
Specification: The final output of the requirements analysis is the creation of a
Software Requirements Specification (SRS) document. For simple problems the
specification activity might be the end result of the entire analysis. However in
most real life problems, the problem analysis and specification are done
concurrently. A good SRS should be understandable, complete, consistent, and
unambiguous.
Review: Requirements reviews are the most common method employed for
validating the requirements specifications. Reviews are used throughout
software development for quality assurance and data collection. Requirements
review is a review by a group of people to find out errors and point out other
matters of concern in the requirements specifications of a system.
4.1.1. Specification Principles
The list of basic specification principles given below will provide a basis for
representing software requirements.
1. Separate functionality from implementation.
2. Develop a model of the desired behavior of a system that encompasses
data and the functional responses of a system to various stimuli from the
environment.
3. Establish the context in which software operates by specifying the
manner in which other system components interact with software.
4. Define the environment in which the system operates and indicate how
“a highly twisted collection of agents react to stimuli in the environment
produced by those agents.
5. Create a cognitive (perception) model rather than design or
implementation model. The cognitive model describes a system as
perceived by its user community.
6. Recognize that “the specification must be tolerant of incompleteness and
augmentable”. A specification is always a model – an abstraction - of
some real situation that is normally quite complex. Hence it will be
incomplete and will exist at many levels of detail.
7. Establish the content and structure of a specification in a way that will
enable it to be amenable to change.
Check your progress

57
i. Requirements Analysis is a software engineering task that bridges the gap
between _______________ and ______________
ii. Requirements analysis enables the system engineer to _________, __________
and ____________
iii. Requirements analysis provides the software engineer to _________ and
____________
iv. Two types of formal specifications they are _________

Solutions

Ii

Iii

Iv

4.2. THE SOFTWARE REQUIREMENT SPECIFICATION

The Format of a requirements specification document is presented in the
following Table.

Section Requirement Specification

1. Product Overview and Summary

2. Development, Operating and Maintenance

Environments

3. External Interface and Data Flow

4. Functional Requirements

5. Performance Requirements

6. Exception Handling

7. Early subsets and Implementation

Priorities

58
 8. Foreseeable Modifications and
Enhancements

9. Acceptance Criteria

10. Design Hints and Guidelines

11. Cross-Reference Index

12. Glossary of Terms

There are number of desirable properties that a software requirement

specification should processes. They are:
 Correct
 Complete
 Consistent
 Unambiguous
 Functional
 Verifiable
 Traceable
 Easily changed
4.3. FORMAL SPECIFICATION TECHNIQUES
pecifying the functional characteristics of a software product is one of the
most important activities to be accomplished during requirements analysis.
Formal specifications have the advantage of being brief and clear-cut, they
support formal reasoning about the functional specifications, and they provide
a basis for verification of the resulting software product. Formal notations are
not appropriate in all situations or for all types of systems. However, our
experience indicates that there is usually too little formalism in software
development, rather than too much hence, our emphasis on formalism.
There are two types of formal specifications they are:
1. Relational Notations
2. State-Oriented Notations
Relational Notations
elational Notations are based on the concepts of entities and attributes.
Entities are named elements in a system; the names are chosen to denote the
nature of the elements (e.g., stack, queue). Attributed are specified by applying
functions and relations to the name entities. Attributes specify permitted
operations on entities, relationships among entities, and data flow between
entities.

59
Example:
Implicit equations, recurrence relations, algebraic axioms and regular
expressions.
State-Oriented Notations
he state of a system is the information required to summarize the status
of system entities at any particular point in time; given the current state and
the current stimuli, the next state can be determined. The execution history by
which the current state was attained does not influence the next state; it is only
dependent on the current state and current stimuli.
Example:
Decision tables, event tables, transition tables, finite-state mechanisms,
and Petri nets.

4.4. Languages & Processors for Requirements Specification

A number of special-purpose languages and processors have been
developed to permit concise statement and automated analysis of requirements
specifications for software. Some specification languages are graphical in
nature, while others are textual; all are relational in nature. Some specification
languages are manually applied and other has automated processors. Some are
the specification languages are:
a. PSL/PSA
b. RSL/REVS
c.SADT
d. SSA
e. GIST
a. PSL/PSA
The Problem Statement Language (PSL) was developed by Prof. Daniel
Teichrow at the University of Michigan. The Problem Statement Analyzer (PSA)
is the PSL processor.
The objective of PSL is to permit expression of much of the information
that commonly appears in a Software Requirements Specification. In PSL,
system descriptions can be divided into eight major aspects:
i. System input/output flow
ii. System structure
iii. Data structure
iv. Data derivation
v. System size and volume

60
 vi. System dynamics
vii. System properties
viii. Project management
PSL contains a number of types of objects and relationships to permit
description of these eight aspects. The system input/output flow aspect deals
with the iteration between a system and its environment.
The Problem Statement Analyzer (PSA) is an automated analyzer for
processing requirements stated in PSL.
b. RSL/REVS
The Requirements Statement Language (RSL) was developed by the TRW
Defense and Space Systems Group to permit brief and clear-cut specification of
requirements for real-time software systems. The Requirements Engineering
Validation Systems (REVS) processes and analyzes RSL statements; both RSL
and REVS are components of the Software Requirements Engineering
Methodology. Many of the concepts in RSL are based on PSL.
c. SADT
Structured Analysis and Design Technique (SADT) was developed by D.T.
Ross and Colleagues at Softech, Inc. SADT incorporates a graphical language
and set of methods and management guidelines for using the language. The
SADT language is called the language of Structured Analysis (SA). The SA
language and the procedures for using it are similar to the engineering
blueprint systems used in civil and mechanical engineering.
d. SSA
Structured System Analysis is used primarily in traditional data
processing environments. Like SADT, SSA uses a graphical language to build
models of systems. Unlike SADT, SSA uses graphical concepts; however, SSA
does not provide the variety of structural mechanisms available in SADT. There
are four basis features in SSA: data flow diagrams, data dictionaries, procedure
logic representation and data store structuring techniques. SSA data flow
diagrams are similar to SADT diagrams, but they do not indicate mechanism
and control, and an additional notation is used to show data stores.
e. GIST
Gist is a formal specification language developed at the USC/Information
Sciences Institute by R. Balzar and colleagues. Gist is a textual language based
on a relational model of objects and attributes. A Gist specification is a formal
description of valid behaviors of a system. A specification is composed of three
parts:
i. A specification of object types and relationships between these types.
This determines a set of possible states.
ii. A specification of actions and demons which define transitions
between possible states.

61
 iii. A specification of constraints on states and state transitions.
4.5. REVIEW QUESTIONS
1. Define requirements analysis.
2. List requirements analysis tasks.
3. Discuss the problems with requirements analysis.
4. Discuss Balzer and Goldman’s specification principles.
5. List the different analysis methods.

4.6. LET US SUM UP

Software requirements definition is concerned with preparation of the software
Requirements Specifications. The format and contents of the Software
Requirements Specification have been discussed, and relational and state
oriented notations for specifying the functional characteristics of a software
product were presented.
Several notations are automated tools for software requirements were described.
Some of the notations (SADT and SSA) do not have automated processors, but
are on the other hand useful techniques. Most of the automated tools for
requirements definition are in fact analysis and design tools; they incorporate
notations for describing structure and processing details.

4.7. LESSON END ACTIVITIES

i. In an organization of your choice, determine whether automated tools are
used for requirements analysis.
ii. If automated tools are used, what are the good and bad experiences of the
tools users?
iii. If automated tools are not used, why not? Is there any plan to experiment
with automated tools? Why or why not?

4.8. POINTS FOR DISCUSSION

i. Obtain, from an organization of your choice, a Software Requirement
Specifications. Assess the strengths ad weakness of the document in
terms of the suggested format and contents.

62
4.9. REFERENCES
1. Pressman R., Software Engineering: A practitioner's Approach, (4th ed.),
McGraw-Hill, 1997
2. Sommerville I.,Software Engineering (5th ed.), Addison-Wesley, 1996.
3. IEEE Std 830-1988, IEEE Recommended Practice for Software
Requirements Specifications. IEEE Computer Society
4. www. Imappl.org/crest/environment.html.

63
64