Requirement engineering

CHAP:2 - Requirement engineering

REQUIREMENTS ENGINEERING

     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 [THA97].

The requirements engineering process can be described in five distinct steps [SOM97]:

·       requirements elicitation

·       requirements analysis and negotiation

·       requirements specification

·       system modeling

·       requirements validation

·       requirements management

1.    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.

v 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.

v 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.

v Problems of volatility The requirements change over time.

Sommerville and Sawyer [SOM97] suggest a set of detailed guidelines for requirements elicitation, which are summarized in the following steps:

v Assess the business and technical feasibility for the proposed system.

v Identify the people who will help specify requirements and understand their organizational bias.

v Define the technical environment (e.g., computing architecture, operating system, telecommunications needs) into which the system or product will be placed.

v 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.

v Define one or more requirements elicitation methods (e.g., interviews, focus groups, team meetings).

v 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.

v Identify ambiguous requirements as candidates for prototyping.

v Create usage scenarios (see Chapter 11) 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

v A statement of need and feasibility.

v A bounded statement of scope for the system or product.

v A list of customers, users, and other stakeholders who participated in the requirements elicitation activity.

v A description of the system’s technical environment.

v A list of requirements (preferably organized by function) and the domain constraints that apply to each.

v  A set of usage scenarios that provide insight into the use of the system or product under different operating conditions.

v Any prototypes developed to better define requirements.

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

2.    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:

v Is each requirement consistent with the overall objective for the

           system/product?

v 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?

v Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system?

v Is each requirement bounded and unambiguous?

v Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement?

v Do any requirements conflict with other requirements?

v Is each requirement achievable in the technical environment that will house the system or product?

v 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.”

3.    Requirements Specification:

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” [SOM97] 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.

4.    Requirements Validation:

The work products produced as a consequence of requirements engineering 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 specification5 looking for errors in content or interpretation, areas where clarification may be required, missing information, inconsistencies, 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:

v Are requirements stated clearly? Can they be misinterpreted?

v 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?

v Is the requirement bounded in quantitative terms?

v What other requirements relate to this requirement? Are they clearly noted via a cross-reference matrix or other mechanism?

v Does the requirement violate any domain constraints?

v Is the requirement testable? If so, can we specify tests (sometimes called validation criteria) to exercise the requirement?

v Is the requirement traceable to any system model that has been created?

v Is the requirement traceable to overall system/product objectives?

v Is the system specification structured in a way that leads to easy understanding, easy reference, and easy translation into more technical work products?

v Has an index for the specification been created?

v Have requirements associated with system performance, behavior, and operational characteristics been clearly stated?

v What requirements appear to be implicit?

5.    Requirements Management:

we noted that requirements for computer-based systems change and that the desire to change requirements persists throughout the life of the system.

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.

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. Shown schematically in Figure , 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.

                            FIG: TRACEABILITY TABLE