Requirements Specification


The process of specifying the requirements of the system is the process of capturing desired functionality of a system to be designed. In short, requirements describe the problem to be solved. Ideally, the requirements completely specify the desired behavior of the system from the end user's point-of-view. Requirements do not specify how the resulting system is achieved, which is the purpose of design, but rather what the outcome of the design should do. Thus, the end of the development process, it is the requirements that provide the measure of the success of the project. This measurement comparing the desired results (requirements) with the actual results obtained from the implementation is known as testing or verification.

The Participants

The process of specifying a new product is ideally executed by people with a broad range of expertise including the following domains of expertise.

A marketing experts understand what is needed or desired by the customers who will buy the product. Among other judgements, these experts should know what minimum feature sets are necessary to achieve the corporate goals.

Aesthetic experts are expected to focus on the appearance and usability of the product.

Both the marketing and the aesthetic experts are responsible for having their finger on the pulse of the end users.

Technical experts inject implementation feedback regarding technological risk and feasibility, rough schedule estimates, and implementation phasing suggestions, that reduce or prevent impossible or prohibitively expensive products from being specified.

Management arbitrates the process, provides input related to project funding and human resource issues, and is ultimately responsible for evaluating issues regarding various tradeoffs, and making the timely decisions that keep the process moving ahead.

The Pitfalls

There are two forces that must be balanced to achieve optimimum results in terms of the overall project development. Over-specification is the result of unrealistic expectations that confuse what is required with what is desired, and/or political feedback from the technical people that are uncomfortable with making more mundane decisions about how the product should be implemented. Both causes can result in a large product specification that is either ignored or used as a political ass-shield.

What is a Requirement?

Simply, a requirement is a statement of what the system must accomplish to be considered acceptable by the stake-holders. The most important stake-holder being the end user of the system (the customer), but other stake-holders include the parties responsible for the development, maintenance, manufacture, marketing and sales of the product.

The following is a collection of attributes for each requirement.

That a requirement must be testable is most often stated by those responsible for product testing and verification. This excellent maxim encourages those responsible for requirements capture to focus on the quantitative aspects of the system, and to unambiguously capture details, eliminating the fuzzy fluff often contained within requirements documents. However, while fluff is eliminated, adhering to this policy has the result of increasing the volume of detail, exposing the true scope and impact of each requirement from a development and testing point-of-view.

It is the responsibility of the requirements capture process to describe what the system is to do. The responsibility for describing how the requirements will be realized is the responsibility of the design team. The requirements indirectly constrain the implementation by describing the physical and logical external components and systems with which the system must interact and the required response of the system to these interactions, but the design process is responsible for realizing those requirements.

Describing a system in terms of its externally observable behavior is a means of identifying and establishing the physical and logical boundaries of a system. As an example of the difference between the physical and logical boundaries, consider a system with an external 10/100 etherenet port. The ethernet port is a physical connection to the system, but over this physical boundary may pass an almost infinite number of connections to other systems and processes, each with its own layer of protocols.

Describing Behavior

From what we have seen, requirements capture involves the unambiguous description of the systems behavior. The implication is that requirements specification at this level involves a formalism with which many of the stake holders outside of development/engineering are unfamiliar. Such behavior descriptions are the forte of Finite State Machine (FSM) diagrams.

Expressing a behavior as a FSM diagram exposes many details and interactions which otherwise go unnoticed and unresolved during requirements capture. These issues inevitably result in system implementations that are unstable, unsatisfactory or impossible. Issues such as errors handling and other exceptional conditions must be captured for such models to be accurate.

While FSM diagrams describe the logical behavior of a system, there are other behaviors and constraints which are equally important that must be captured in more traditional ways. Performance requirements are among the most widely recognized, often specified, mis-understood and mis-represented of all requirements.

Simply stating that a system must be fast is worthless. What does it mean to be fast? What are the units of fast? How important is it to be fast? What is the impact of not being fast enough? Clearly, we need to be a bit more rigorous in our specification.