Software Engineering-Requirements Engineering

The outcome of the system engineering process is the specification of a computerbased system or product at the different levels . But the c...

The outcome of the system engineering process is the specification of a computerbased system or product at the different levels . But the challenge facing system engineers (and software engineers) is profound: How can we ensure that we have specified a system that properly meets the customer’s needs and satisfies the customer’s expectations? There is no foolproof answer to this difficult question, but a solid requirements engineering process is the best solution we currently have.

Requirements engineering provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification, and managing the requirements as they are transformed into an operational system . The requirements engineering process can be described in five distinct steps:

• requirements elicitation
• requirements analysis and negotiation
• requirements specification
• system modeling
• requirements validation
• requirements management

Requirements Elicitation

It certainly seems simple enough—ask the customer, the users, and others what the objectives for the system or product are, what is to be accomplished, how the system or product fits into the needs of the business, and finally, how the system or product is to be used on a day-to-day basis. But it isn’t simple—it’s very hard.

Christel and Kang   identify a number of problems that help us understand why requirements elicitation is difficult:

• Problems of scope. The boundary of the system is ill-defined or the customers/ users specify unnecessary technical detail that may confuse, rather than clarify, overall system objectives.

• Problems of understanding. The customers/users are not completely sure of what is needed, have a poor understanding of the capabilities and limitations of their computing environment, don’t have a full understanding of the problem domain, have trouble communicating needs to the system engineer, omit
information that is believed to be “obvious,” specify requirements that conflict with the needs of other customers/users, or specify requirements that are ambiguous or untestable.

• Problems of volatility. The requirements change over time. 

To help overcome these problems, system engineers must approach the requirements gathering activity in an organized manner. Sommerville and Sawyer [SOM97] suggest a set of detailed guidelines for requirements elicitation, which are summarized in the following steps:
• Assess the business and technical feasibility for the proposed system.
• Identify the people who will help specify requirements and understand their organizational bias.
• Define the technical environment (e.g., computing architecture, operating system, telecommunications needs) into which the system or product will be placed.
• Identify “domain constraints” (i.e., characteristics of the business environment specific to the application domain) that limit the functionality or performance of the system or product to be built.
• Define one or more requirements elicitation methods (e.g., interviews, focus groups, team meetings).
• Solicit participation from many people so that requirements are defined from different points of view; be sure to identify the rationale for each requirement that is recorded.
• Identify ambiguous requirements as candidates for prototyping.
• Create usage scenarios to help customers/users better identify key requirements.

The work products produced as a consequence of the requirements elicitation activity will vary depending on the size of the system or product to be built. For most systems, the work products include
• A statement of need and feasibility.
• A bounded statement of scope for the system or product.

• A list of customers, users, and other stakeholders who participated in the requirements elicitation activity.
• A description of the system’s technical environment.
• A list of requirements (preferably organized by function) and the domain constraints that apply to each.
• A set of usage scenarios that provide insight into the use of the system or product under different operating conditions.
• Any prototypes developed to better define requirements.

Each of these work products is reviewed by all people who have participated in the requirements elicitation.

Requirements Analysis and Negotiation

Once requirements have been gathered, the work products noted earlier form the basis for requirements analysis. Analysis categorizes requirements and organizes them into related subsets; explores each requirement in relationship to others; examines requirements for consistency, omissions, and ambiguity; and ranks requirements based on the needs of customers/users.

As the requirements analysis activity commences, the following questions are asked and answered:
• Is each requirement consistent with the overall objective for the system/product?
• Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage?
• Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house the system or product?
• Is each requirement testable, once implemented?

It isn’t unusual for customers and users to ask for more than can be achieved, given limited business resources. It also is relatively common for different customers or users to propose conflicting requirements, arguing that their version is “essential for our special needs.”

Requirements Specification

In the context of computer-based systems (and software), the term specification means different things to different people. A specification can be a written document, a graphical model, a formal mathematical model, a collection of usage scenarios, a prototype, or any combination of these.

Some suggest that a “standard template”  should be developed and used for a system specification, arguing that this leads to requirements that are presented in a consistent and therefore more understandable manner. However, it is sometimes necessary to remain flexible when a specification is to be developed. For large systems, a written document, combining natural language descriptions and graphical models may be the best approach. However, usage scenarios may be all that are required for smaller products or systems that reside within well-understood technical environments.

The System Specification is the final work product produced by the system and requirements engineer. It serves as the foundation for hardware engineering, software engineering, database engineering, and human engineering. It describes the function and performance of a computer-based system and the constraints that will govern its development. The specification bounds each allocated system element. The System Specification also describes the information (data and control) that is input to and output from the system.

System Modeling

Assume for a moment that you have been asked to specify all requirements for the construction of a gourmet kitchen. You know the dimensions of the room, the location of doors and windows, and the available wall space. You could specify all cabinets and appliances and even indicate where they are to reside in the kitchen. Would this be a useful specification?

The answer is obvious. In order to fully specify what is to be built, you would need a meaningful model of the kitchen, that is, a blueprint or three-dimensional rendering that shows the position of the cabinets and appliances and their relationship to one another. From the model, it would be relatively easy to assess the efficiency of work flow (a requirement for all kitchens), the aesthetic “look” of the room (a personal, but very important requirement).

We build system models for much the same reason that we would develop a blueprint or 3D rendering for the kitchen. It is important to evaluate the system’s components in relationship to one another, to determine how requirements fit into this picture, and to assess the “aesthetics” of the system as it has been conceived. 

Requirements Validation

The work products produced as a consequence of requirements engineering (a system specification and related information) are assessed for quality during a validation step. Requirements validation examines the specification to ensure that all system requirements have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected; and that the work products conform to the standards established for the process, the project, and the product.

The primary requirements validation mechanism is the formal technical review . The review team includes system engineers, customers, users, and other stakeholders who examine the system specification looking for errors in content or interpretation, areas where clarification may be required, missing information, inconsistencies (a major problem when large products or systems are engineered), conflicting requirements, or unrealistic (unachievable) requirements.

Although the requirements validation review can be conducted in any manner that results in the discovery of requirements errors, it is useful to examine each requirement against a set of checklist questions. The following questions represent a small subset of those that might be asked:

• Are requirements stated clearly? Can they be misinterpreted?
• Is the source (e.g., a person, a regulation, a document) of the requirement identified? Has the final statement of the requirement been examined by or against the original source?
• Is the requirement bounded in quantitative terms?
• What other requirements relate to this requirement? Are they clearly noted via a cross-reference matrix or other mechanism?
• Does the requirement violate any domain constraints?
• Is the requirement testable? If so, can we specify tests (sometimes called validation criteria) to exercise the requirement?
• Is the requirement traceable to any system model that has been created?
• Is the requirement traceable to overall system/product objectives?

• Is the system specification structured in a way that leads to easy understanding, easy reference, and easy translation into more technical work products?
• Has an index for the specification been created?
• Have requirements associated with system performance, behavior, and operational characteristics been clearly stated? What requirements appear to be implicit?

Checklist questions like these help ensure that the validation team has done everything possible to conduct a thorough review of each requirement.

Requirements Management

Requirements management is a set of activities that help the project team to identify, control, and track requirements and changes to requirements at any time as the project proceeds. Many of these activities are identical to the software configuration management techniques.

Like SCM, requirements management begins with identification. Each requirement is assigned a unique identifier that might take the form

               <requirement type><requirement #>

where requirement type takes on values such as F = functional requirement, D = data requirement, B = behavioral requirement, I = interface requirement, and P = output requirement. Hence, a requirement identified as F09 indicates a functional requirement assigned requirement number 9.

Once requirements have been identified, traceability tables are developed.Each traceability table relates identified requirements to one or more aspects of the system or its environment. Among many possible traceability tables are the following:

Features traceability table. Shows how requirements relate to important customer observable system/product features. Source traceability table. Identifies the source of each requirement.

Dependency traceability table. Indicates how requirements are related to one another.

Subsystem traceability table. Categorizes requirements by the subsystem(s) that they govern.

Interface traceability table. Shows how requirements relate to both internal and external system interfaces.

In many cases, these traceability tables are maintained as part of a requirements database so that they may be quickly searched to understand how a change in one requirement will affect different aspects of the system to be built.