Requirements engineering

Requirements engineering is comprised of two  major tasks: analysis and modeling

● The requirements themselves are the  descriptions of the system services and  constraints that are generated during the  requirements engineering process.

Requirements engineering for a product line differs from requirements engineering for single systems as follows:

Requirements elicitation for a product line must capture anticipated variations explicitly over the foreseeable lifetime of the product line. This means that the community of stakeholders is probably larger than for single-system requirements elicitation and may well include domain experts, market experts, and others. Requirements elicitation focuses on the scope, explicitly capturing the anticipated variation by the application of domain analysis techniques, the incorporation of existing domain analysis models, and the incorporation of use cases that capture the variations that are expected to occur over the lifetime of the product line

·         Requirements specification now includes documentation of a product-line-wide set of requirements and product-specific requirements. The product-line-wide requirements include symbolic placeholders that the various product-specific requirements documents fill in, expand, or instantiate.

·         Requirements verification now includes a broader reviewer pool and occurs in stages. First, the common product line requirements must be verified. Later, as each product comes on the scene (or is updated), its product-specific requirements must be verified. But the product-line-wide requirements must also be verified to make sure that they make sense for this product.

·         Requirements management must now make allowances for the dual nature of the requirements engineering process and the staged (common, specific) nature of the activity. Change-management policies must provide a formal mechanism for proposing changes in the product line and supporting the systematic assessment of how the proposed changes will impact the product line. Change-management policies govern how changes in the product line requirements are proposed, analyzed, and reviewed. The coupling between the product line requirements and the core assets is leveraged by the use of traceability links between those requirements and their associated core assets. Changes in the requirements can then trigger the appropriate changes in the related core assets

Requirement validation.     

The purpose of requirements validation is to demonstrate that the software has a valid set of requirements to work on and these requirements meet the needs of the stakeholders. Validation is particularly important for requirements, which may change. Changing requirements usually means changing the corresponding part of the software design and implementation. As it is costly to amend erroneous requirements at a later stage, software engineers should validate requirements and identify the errors in the requirements as early as possible.

the requirements validation process, software engineers should conduct different types of checks, such as:

1.    Validity

2.   Consistency

3.   Completeness

4.   Realism

5.   Verifiability

6.   Traceability

7.   Comprehensibility

8.   Adaptability