CPSC 333: Introduction to Requirements Analysis

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Introduction to Requirements Analysis and Specification


This material was covered during lectures on January 13, 1997.


Reference

The following material is presented in more detail (and additional useful material can be found) in

R. S. Pressman, Software Engineering: A Practitioner's Approach
Depending on which edition of this book you have, you might find this material in a chapter whose title is either ``Requirements Analysis Fundamentals'' or ``Analysis Concepts and Principles.''

Purpose of Requirements Specifications

A requirements specification states what software will be expected to do, and not how it needs to do it. It is started before software design and implementation can begin; indeed, it should be (nearly) completed, and should be reviewed and ``accepted'' before software design and implementation. However, if the software to be developed is large or complex, or is to be used or maintained for a long period of time, then the requirements specification probably will be changed at some point.

A requirements specification

Analysis and Specification Principles

  1. The Information Domain must be represented.

    Pressman identifies three different aspects or components of the information that should be included and that can be modeled (almost) independently:

  2. Models will be Used to Represent Aspects of the information Domain.

    Models are abstractions that highlight important system requirements. Typically, several models are developed during requirements analysis and included in a requirements specification.

    Many models use a graphical notation that depicts information to be maintained, required system behaviour, and other characteristics using distinct and recognizable symbols.

    These (and other) models generally often include textual information, sometimes to ``annotate'' the graphical component of the model. This textual information might used a structured language (such as a kind of ``pseudocode'') or it might be written using a Natural language (such as English).

    Types of Models

  3. Requirements Should Be Partitioned.

    Problems are often too large and complex to be understood all at once. Therefore will will try to partition (or ``divide up'') problems into pieces that can be understood easily, and establish any necessary interfaces between these subsystems that correspond to these pieces, and then specify requirements for (and develop) these pieces, largely independently.

    We will ``partition'' requirements by using different models to represent each of the different aspects of the information domain.

    For example, if structured development is being used, then we will use

    Furthermore, it will often be possible to ``partition'' requirements further, by organizing components of each model.

    Some models are hierarchical - organized in a ``tree'' structure, with a top view giving an overall picture of (some aspect of) the entire system, without much detail, and with views corresponding to lower levels of the tree giving more detailed pictures of smaller subsystems. For example, data flow diagrams are often organized this way when used in structured development.

    Other models can be viewed in a layered fashion, with different kinds of information separated into different layers of the model. Some CASE tools allow users to choose which layers of the model will be shown when the model is displayed. For example, entity-relationship diagrams can be viewed in this way.

  4. The Analysis and Specification Progress Should Progress from Essential Requirements to Implementation Details (and Should Separate Them)

Final Remarks

The above principles are motivated by the fact that requirements are generally too complex to be specified by a single person in a small amount of time, or to be understood as a whole, and that a requirements specification must be easy to create, read, and change.

The next lectures will introduce a number of models for specification, and will describe how to develop and use them for both structured and object-oriented development. It might be worthwhile to read this introduction again (and to try to see how the principles apply) after the models have been introduced and their use has been described.

Location: [CPSC 333] [Listing by Topic] [Listing by Date] [Previous Topic] [Next Topic] Introduction to Requirements Analysis and Specification


Department of Computer Science
University of Calgary

Office: (403) 220-5073
Fax: (403) 284-4707

eberly@cpsc.ucalgary.ca