Requirements Analysis

Purpose

The requirements gathering process calls for a method of addressing incomplete, ambiguous, or conflicting requirements. The general term for this is Requirements Analysis. This process helps to ensure that requirements are correct, consistent, complete, and testable. This document describes the process and how it fits into the overall Software Development Life Cycle (SDLC).

Definitions

Ambiguous - A form of uncertainty by which something has more than one meaning or interpretation. Capable of being understood in two or more possible senses or ways. (ref. Merriam-Webster)

Vague - A form of uncertainty in which something is not explicit; without a clear or perceptible form. Not having a precise meaning. (ref. Merriam-Webster)

Requirements Analysis - The process verifying that requirements are correct, consistent, complete, and testable. It is primarily a defect prevention tool.

Degrees Of Uncertainty

The tolerance for uncertainty depends on where the product is in its product life cycle. Uncertainty is inherent in the early phases of product development, where we know what functions a product should perform, but not specifically how it will perform its functions. During product development, we actively work to reduce and minimize the uncertainty. Requirements Analysis is a development process that works to reduce uncertainty in requirements, and has strong ties with testing, where the uncertainty is reduced to a minimum.

Vagueness is unavoidable in the early stages of product development, and is reduced as the product specifications take form. Ambiguity, by contrast, can result in the wrong functions being developed. Therefore:

Vagueness is inevitable and is reduced as development proceeds.

Ambiguity is unacceptable.

Software development begins with a high degree of uncertainty and ends with a low degree of uncertainty. At the outset, only the general functionality will be known. By project completion, the software will be a specific set of bits, whose performance and operation is well characterized.

The following Entity-Relation diagram shows the relation between steps and uncertainty in the requirements analysis process.

Only prescriptive testing is suited to finding software defects; therefore, all further discussion in this document will relate only to prescriptive testing. The intent is that: a) test steps are derived from test objectives, and b) test steps should contain only enough descriptive detail to allow a trained operator to run the tests.

NOTE: the use of descriptive testing alone is deprecated by the FDA, ISO-9000, and the Software Engineering Institute (SEI). Some form of prescriptive testing must be used, either solely, or in conjunction with descriptive testing. It is permissible for descriptive tests to evolve from prescriptive tests.