Foundation Level - CPRE FL

In requirements modeling, the dynamic behavior of a system is modeled in the behavioral perspective. In this perspective the focus lies on the various states in which a system can be found and on the events that are responsible for a change of state. In UML state diagrams, which are based on the principles of finite state machines, the following modeling elements are used:

• State
• Start and end states
• State transition
• Concurrency

The objective of requirements validation is to validate whether requirements satisfy the defined quality criteria (see EU 4.6) in order to detect and correct any errors in the requirements as early as possible in RE. Since requirements documents are the basis for the further development activities, errors in the requirements affect all further development activities so much that the effort to correct an undetected requirements error increases significantly in the course of development. The reason for this is that not only the actual error in the requirements must be corrected, but also that all artifacts based on this must be reworked, e.g. architecture design, implementation, test cases.

Unresolved conflicts in a system’s requirements mean, for example, that one group of stakeholders’ requirements cannot be implemented or that the operational system is either not accepted or not sufficiently used. The goal of negotiating requirements is to develop, among the relevant stakeholders, a common and agreed understanding with respect to the requirements for the system to be developed.

A distinction is drawn between three quality aspects for requirements (content, documentation and agreement), whereby the quality of a requirement or set of requirements, in respect of the individual quality aspects, can each be assessed by means of a series of validation criteria.

For the quality aspect "content”, the eight validation criteria are:

• Completeness of the requirements document
• Completeness of the individual requirements
• Traceability
• Correctness and adequacy
• Consistency
• No premature design decisions
• Verifiability
• Necessity

For the quality aspect "documentation”, the four validation criteria are:

• Conformity to document format and document structures
• Understandability
• Unambiguity
• Conformity to documentation rules

For the quality aspect "agreement”, the three validation criteria are:

• Agreed
• Agreed after changes
• Conflicts resolved

The validation of requirements is based on various principles. These principles ensure that during validation as many errors as possible can be identified in the requirements. The six principles for requirements validation are:

• Involvement of the correct stakeholders
• Separating the diagnosis and the correction of errors
• Validation from different views
• Adequate change of documentation type
• Construction of development artifacts that are based on requirements
• Repeated validation

xx

There are several techniques for systematic validation of requirements, which are also partly used in addition to each other, in order to verify requirements against defined validation criteria as comprehensively as possible. Techniques for requirements validation are:

• Commenting (expert opinion)
• Inspections
• Walkthroughs

The following additional techniques are used:

• Perspective-based reading
• Validation through prototypes
• Usage of checklists

xxx

Negotiating requirements aims at establishing a common understanding of the requirements for the system to be developed among all relevant stakeholders. The tasks in the negotiation of requirements are:

• Conflict identification
• Conflict analysis
• Conflict resolution
• Documentation of conflict resolutions

During the conflict analysis various conflict types are distinguished, in respect to the requirements, which require various strategies for conflict resolution. The various conflict types are:

• Interest conflict – Stakeholders have factually different needs or divergent personal interests (note that this conflict type includes conflicts of both objective and subjective nature. Objective interest conflicts root in factually different stakeholder needs, while subjective ones are caused by divergent personal interests of involved people.)
• Data conflict– Stakeholders interpret given information differently or have information deficits.
• Value conflict – Stakeholders have divergent values and preferences
• Relationship conflicts – There are emotional problems in personal relationships between stakeholders
• Structural conflict – Conflict roots in stakeholders being on different hierarchy and decision power levels in an organization

In practice, the causes of conflict are frequently mixed. In the resolution of a conflict, all relevant stakeholders should be considered. For conflict resolution there exist a number of conflict resolution techniques, namely:

• Agreement
• Compromise
• Voting
• Definition of variants
• Overruling
• Consider-all-facts
• Plus-minus-interesting
• Decision matrix

After resolving the conflict, the conflict should be suitably documented. This should record, in particular:

• cause of the conflict
• involved stakeholders
• opinions of the various stakeholders
• the means of resolving the conflict
• potential alternatives
• the decisions and the reasons for the decisions

To manage the system’s requirements over the whole lifecycle of the system, it is necessary to collect requirements’ information as attributes in as structured a way as possible. The definition of the attribute structure for requirements is done through an attribute scheme, which can be defined either in tabular form or in the form of an information model.

Attribute schemes are frequently defined and adapted for a specific project on the basis of specific conditions. This includes:

• Specific properties of the project
• Constraints of the organization
• Domain rules
• Constraints of the development process

Typical attributes are:

• Identifier
• Name
• Description
• Source
• Stability
• Risk
• Priority

The "legal obligation" can also be saved as additional requirement’s information in the form of an attribute.

In practice, the amounts of requirements in a project and the number of dependencies among these requirements are evermore increasing. In order to keep the complexity of the requirements manageable for the project staff, it is necessary to selectively access and thereby filter the requirements depending on the current task. Two kinds of view formation are distinguished:

• Selective views: showing a subset of the attribute values from requirements selected by defined selection criteria
• Condensed views: showing condensed information about requirements selected by defined selection criteria

Requirements are prioritized, at various times and during various activities, according to various criteria. Preparing prioritization of requirements is based on a simple system:

• Determining the goals and constraints for the prioritization
• Determining the prioritization criteria
• Determining the relevant stakeholders
• Selection of the artifacts to be prioritized

Based on the results of these activities, one or more techniques for prioritization are selected and the prioritization itself carried out. Among the prioritization techniques are:

• Ranking and top-ten technique
• Single-criterion classification
• Kano classification
• Prioritization Matrix According to Wiegers

Within the management of requirements, the requirements’ traceability information is recorded, organized and maintained.
The benefits of requirements traceability involves:

• Simplification of verifiability
• Identification of unneeded properties in the system
• Identification of unneeded requirements
• Support of impact analysis
• Support of reusability
• Support of determination of accountability
• Support for maintenance and administration

With respect to the requirements’ traceability relationships, three classes of traceability relationships are distinguished:

• Pre-requirements-specification traceability
• Post-requirements-specification traceability
• Traceability between requirements

Only such information should be recorded for which there exists a clear use. The traceability of requirements can be represented in various ways. Typical representation forms are:

• Text-based references and hyperlinks
• Trace matrices
• Trace graphs

Requirements’ versioning and configuration makes it possible, over the lifecycle of a system or product, to have specific development states of requirements and requirements documents available. The version number of a requirement has at least two components:

• Version
• Increment

A requirements configuration comprises a defined set of logically related requirements, whereby at most one version of each requirement is contained in the requirements configuration. The formation of requirements configurations are defined in two dimensions:

• Product dimension: the individual requirements of the requirements foundation
• Version dimension: the various change states of a requirement

Requirements configurations have several typical properties:

• Logical connection of the requirements in a configuration
• Consistency of the requirements within a requirements configuration
• Unique identifier of the requirements configuration
• Immutability of the requirements within the requirements configuration
• Basis for rollbacks to earlier versions of the requirements base

Requirements baselines are specific requirements configurations, which comprise stable versions of requirements and often define the delivery increments of the system (system releases) as well.

Requirements change over the entire lifecycle of a system. The changes to the requirements are managed and processed in a systematic change management process. In this change management process, the Change Control Board is responsible for processing the incoming change requests.

The tasks of the Change Control Board are:

• Classification of incoming change requests
• Determination of the effort for performing the change
• Assessment of the change requests in respect to effort-benefit
• Definition of new requirements based on incoming change requests
• Deciding whether to accept or reject a change request
• Prioritization of the accepted change requests
• Assign accepted change requests to change projects

Typical member of the Change Control Board are the change manager, contractor, architect, user representative, quality manager and requirements engineer.

If changes to requirements are deemed necessary, these are documented in the form of change requests and submitted to the Change Control Board. A change request contains at least the following information:

• Identifier of the change request
• Title of the change request
• Description of the necessary change
• Justification of the need for the change
• Date filed
• Applicant
• Priority of the change as seen by the applicant.

There are three types of change requests:

• Corrective changes
• Adaptive changes
• Exceptional changes

The process of change management provides the following steps:

• Impact analysis and assessment of the change
• Prioritization of the change request
• Assignment of the change to a change project
• Communication of the acceptance/rejection of the change request

Based on the requirements validation and management information such as errors, attributes, traces or changes, the quality of the requirements documents and processes can be analyzed. This enables the identification of improvement possibilities. Typical measurements include

• Requirements change rates
• Requirements errors

Many system development tools can also support RE, e.g. test management or configuration management tools, Wikis, office software or visualization software. Also modeling tools are important for RE in order to create and analyze information as models. Requirements management tools are intended only for RE. They should feature the following characteristics:

• manage various information
• manage logical relationships between information
• identify artifacts uniquely
• make information accessible flexibly and securely, e.g. through access control
• support views over the data
• organize the information, e.g. through assignment of attributes and formation of hierarchies
• generate reports over the information
• generate documents out of the information

Standard office tools support these features only to a limited extent, specialized tools refine these, e.g. through traceability management.

Only after the introduction of RE procedures and techniques can an appropriate tool be sought. The tool introduction requires clear RE responsibilities and procedures. In the process, the following aspects are to be considered:

• Consider necessary resources
• Avoid risks by means of pilot projects
• Evaluation according to defined criteria
• Take into account costs beyond license costs
• Instruct employees

The variety of aspects to be considered when evaluating RE-tools can be structured using the following seven views:

• Project view (e.g. support for project planning)
• User view (especially usability)
• Product view (functionality)
• Process view (methodological support)
• Provider view (e.g. vendor services)
• Technical view (e.g. interoperability, scalability)
• Economic view (costs)

Clear criteria are to be defined for each view.