Read an Excerpt

Software Requirements Engineering

John Wiley & Sons

Chapter One

1. Introduction to Chapter

It is a well-documented belief that the failure to develop and document good requirements specifications is the major cause of software development failures. The purpose of Chapter 1 is to identify some of the major issues in software requirements development and to define terms used both in and around system and software engineering.

The problems with writing good, correct, complete, and measurable system and software requirements specifications are a major issue in software development today. Some of the major issues of concern in the requirements area are:

The inability of engineers to write a correct software requirements specification

The desire of managers to truncate requirements activity because they believe that the major effort in any software development is programming and testing

The lack of cooperation by customers when it comes to verifying that the software requirements are correct, and the lack of understanding of the structure and purpose of the software requirements specifications

The problems associated with identifying which tool and/or methodology to use in developing and representing a software requirements specification

The lack of knowledge that system requirements are essential to the development of good software requirements, or the unwillingness to act in accordance with that knowledge

The lack of training of system engineers on how to partition and allocate system functions to software

The desire of senior management in many large corporations to place personnel with little software knowledge or experience in positions of responsibility over what is essentially a major software project

Terminology causes many problems because of the newness of the computer science and software engineering fields. Many terms do not have universally accepted definitions. System engineers, computer scientists, and software development groups define things in different ways. One of the purposes of this tutorial is to provide a common set of definitions that can be used in the area of system and software requirements engineering.

The four articles in this chapter were selected to introduce the tutorial, provide definitions, and establish the requirements engineering issues and problems. The first article, by the co-editor of the tutorial, Dr. Merlin Dorfman, sets the tone for the entire tutorial and establishes the definition of system and software requirements engineering. The article by Harwell et al. defines software requirements and provides a taxonomy of software requirements definitions. An article by Scharer looks at requirements from both the user's and developer's point of view. The last article, by Siddiqi and Shekaran, Program Co-Chairs of the 1996 International Conference on Requirements Engineering, summarizes the current state of research and practice.

2. Description of Articles

The first article, "Requirements Engineering" by Merlin Dorfman, is an overview of this tutorial. In this article, Dorfman discusses the value of good requirements and specifications, the place of requirements analysis in the life cycle, and the framework for developing system requirements. The article introduces the concepts of architectural design, allocation, flowdown, and traceability. It also explains the application of configuration management, interface definition, and verification and validation to the requirements activity. A brief introduction is given to some of the tools and methods to be discussed in detail later in the tutorial.

The second article in the chapter, "What Is a Requirement?" by Richard Harwell, Erik Aslaksen, Ivy Hooks, Roy Mengot, and Ken Ptack, does an excellent job in defining many of the terms associated with requirements engineering. While there may be some differences of opinion in discussing some of these definitions, for the most part they appear to be those definitions in common use today. The article defines differences between:

Derived and primary (also called "allocated") requirements

Qualitative and quantitative requirements. The authors define qualitative requirements as being unmeasurable requirements and quantitative requirements as being measurable requirements. One of the major research areas in software engineering is in determining how to measure qualitative requirements

Project and product requirements. Product requirements would be part of a requirements specification and project requirements would be part of a statement of work (SOW) or management plan

Mandatory requirements, guidance (also called "desirable requirements"), and information (also called "notes")

The article also attempts to separate requirements from "design;" however, it does recognize that a "design" (sometimes called a design constraint) can be a requirement. The article concludes with a discussion about three attributes of a requirements specification: (1) completeness, (2) lack of ambiguity, and (3) scope (also called "measurable"). A discussion in Chapter 3 will indicate that there are a number of other attributes that can also be applied to a specification document.

"Pinpointing Requirements" by Laura Scharer does a very fine job of defining the major issues involved in writing a software requirements specification. She points out that analysts and users harbor grave doubts about each other. The origins of these attitudes are obvious-failure encourages blame. Users are disenchanted, because developers constantly bungle new system developments; and developers are disenchanted because they alone are blamed for the failures.

This article is about software development for an in-house user; in other words, the user belongs to the same parent company as the software development team. Because of this situation, the relationship between the developer and user is much closer than in a contract situation.

Scharer points out the problems that exist between experienced and inexperienced users and between experienced and inexperienced software developers. She goes on to discuss some realistic goals and how to improve the relationship between the developer and the user. For instance, a thorough evaluation is needed as to whether or not the system can be defined. The article also points out 12 different environmental factors that influence the software development process.

The article goes on to define methods for controlling the system, for selecting a user for the project team, and for training the user, and presents a well-defined approach to developing a software system.

The last article, by Jawed Siddiqi and M. Chandra Shekaran, "Requirements Engineering: The Emerging Wisdom," reports on some of the work being done to improve software requirements. The article examines a number of different ways to answer the question, "What constitutes a requirement?" Other issues discussed in the article are as follows:

Prioritizing requirements

Coping with incompleteness

Making requirements methods and tools more accessible

The article concludes with a statement that the authors believe there is a greater need to narrow the gap between research and practice.

Requirements Engineering

Merlin Dorfman Lockheed Martin Missiles & Space Company Sunnyvale CA 94088-3504

Abstract

Requirements engineering is presented and discussed as a part of systems engineering and software systems engineering. The need for good requirements engineering, and the consequences of a lack of it, are most apparent in systems that are all or mostly software. Requirements engineering approaches are closely tied to the life cycle or process model used. A distinction is made between requirements engineering at the system level and at lower levels, such as software elements. The fundamentals of requirements engineering are defined and presented: elicitation; decomposition and abstraction; allocation, flowdown, and traceability; interfaces; validation and verification. Requirements development approaches, tools, and methods, and their capabilities and limitations, are briefly discussed.

I. Introduction

When the "Software Crisis" was discovered and named in the 1960s, much effort was directed at finding the causes of the now-familiar syndrome of problems. The investigations determined that requirements deficiencies are among the most important contributors to the problem: "In nearly every software project which fails to meet performance and cost goals, requirements inadequacies play a major and expensive role in project failure." Development of the requirements specification "in many cases seems trivial, but it is probably the part of the process which leads to more failures than any other."

It was determined that the benefits of good requirements include:

Agreement among developers, customers, and users on the job to be done and the acceptance criteria for the delivered system

A sound basis for resource estimation (cost, personnel quantity and skills, equipment, and time)

Improved system usability, maintainability, and other quality attributes

The achievement of goals with minimum resources (less rework, fewer omissions and misunderstandings)

It was also observed that the value of good requirements, and the criticality of doing them well, increased dramatically with the size and complexity of the system being developed. Additionally, software-intensive systems seemed to have more inherent complexity, that is, were more difficult to understand, than systems that did not contain a great deal of software; thus these systems were more sensitive to the quality of their requirements.

The products of a good requirements analysis include not only definition, but proper documentation, of the functions, performance, internal and external interfaces, and quality attributes of the system under development, as well as any valid constraints on the system design or the development process.

As the value of good requirements became clear, the focus of investigation shifted to the requirements themselves: how should they be developed? How can developers know when a set of requirements is good? What standards, tools, and methods can help; do they exist, or must they be developed? These investigations are by no means complete: not only are new tools and methods appearing almost daily, but overall approaches to requirements, and how they fit into the system life cycle, are evolving rapidly. As a result, requirements engineering has been well established as a part of systems engineering. Requirements engineers perform requirements analysis and definition on specific projects as well as investigate in the abstract how requirements should be developed.

II. Requirements Engineering and the Development Life Cycle

Many models exist for the system and/or software life cycle, the series of steps that a system goes through from first realization of need through construction, operation, and retirement. (Boehm provides a good overview of many existing models, and presents as well a risk-driven approach that includes many other models as subsets; Davis et al. describe conditions under which various models might be used.) Almost all models include one or more phases with a name like "requirements analysis" or "user needs development." Many models require generation of a document called, or serving the function of, a requirements specification. Even those that do not call for such a document, for example Jackson System Development, have a product such as a diagram or diagrams that incorporate or express the user's needs and the development objectives.

A few of the better-known life cycle models are briefly discussed in the following sections, and the way requirements engineering fits into them is presented.

A. Baseline Management

Among the most extensively used models are Baseline Management and the Waterfall, on which Baseline Management is based. (Baseline Management differs from the Waterfall in that it specifically requires each life cycle phase to generate defined products, which must pass a review and be placed under configuration control before the next phase begins.) In these models, as shown in Figure 1, determination of requirements should be complete, or nearly so, before any implementation begins. Baseline Management provides a high degree of management visibility and control, has been found suitable for developments of very large size in which less complex methods often fail, and is required under many military standards and commercial contracts. This model, however, has been somewhat discredited, because when large complex systems are developed in practice it is usually impossible to develop an accurate set of requirements that will remain stable throughout the months or years of development that follow completion of the requirements. This essential and almost unavoidable difficulty of the Waterfall and Baseline Management models had been noted for many years but was brought to the attention of the U.S. defense software community by a Defense Science Board report authored by F. Brooks. Brooks pointed out that the user often did not know what the requirements actually were, and even if they could be determined at some point in time they were almost certain to change. To resolve this problem Brooks recommended an Evolutionary model, as is discussed below. The approach advocated by Brooks provides the following advantages:

The user is given some form of operational system to review (a prototype or early evolution), which provides better definition of the true needs than can be achieved by reading a draft specification. This approach avoids what Brooks identified as the unacceptable risk of building a system to the a priori requirements.

Delivery of some operational capabilities early in the development process-as opposed to the delivery of everything after many months or years-permits incorporation of new requirements and of capabilities that did not exist or were not feasible at the start of development.

B. Prototyping

The Prototyping life cycle (Figure 2) is one approach to the use of an operational system to help determine requirements. In this model, some system capability is built with minimum formality and control to be run for or by the user, so that requirements can be determined accurately. Several successive prototypes will usually be built. The amount of requirements analysis that precedes prototyping depends on the specifics of the problem. It is normally recommended that the prototype should be used only to help generate a valid set of requirements; after the requirements are available, they should be documented, and development should proceed as in the Baseline Management model. If this recommendation is followed, the prototyping portion of the life cycle may be considered as a tool or method supporting requirements analysis within the Baseline Management model.

(Continues...)

---

Excerpted from Software Requirements Engineering Excerpted by permission.
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---