29 Lecture 7: Requirements Validation and Negotiation

29.1 What is requirements validation?

During requirements validation, the decision of whether a requirement possesses the necessary level of quality is made and whether the requirement can be approved to be used for further development activities (such as design, implementation, and testing). This decision should be made on the basis of predefined acceptance criteria.

The goal of requirements validation is therefore to discover errors in the documented requirements. Typical examples of errors in requirements are ambiguity, incompleteness, and contradictions.

A contract between client and contractor is often based on requirements documents. Critical errors in requirements can lead to the fact that contractual agreements cannot be met, e.g., scope of supply and services, expected quality, or completion deadlines.

29.2 What is requirements negotiation?

The goal of negotiation is to gain a common and agreed-upon understanding of the requirements of the system to be developed among all relevant stakeholders.

Requirements validation and negotiation is an activity that must be performed (to a varying degree of intensity) throughout the entirety of requirements engineering.

29.3 The Quality Aspects of Requirements

The validation is carried out to verify three quality aspects:

Content: Have all relevant requirements been elicited and documented with the appropriate level of detail?
Documentation: Are all requirements documented with respect to the predetermined guidelines for documentation and specification?
Agreement: Do all stakeholders concur with the documented requirements and have all known conflicts been resolved?

Note

I think the following sections regarding details of each quality aspect isn’t that important.

29.3.1 Quality Aspects: Content

The quality aspect “content” refers to the validation of requirements with respect to errors in the content.

Completeness (set of all requirements): Have all relevant requirements for the system to be developed (for the next system release) been documented?
Completeness (individual requirements): Does each requirement contain all necessary information?
Traceability: Have all relevant traceability relations been defined (e.g., to relevant requirements sources)?
Correctness/adequacy: Do the requirements accurately reflect the wishes and needs of the stakeholders?
Consistency: Is it possible to implement all defined requirements for the system to be developed jointly? Are there no contradictions?
No premature design decisions: Are there any forestalled design decisions present in the requirements not induced by constraints (e.g., constraints that specifiy a specific client-server architecture to be used)?
Verifiability: Is it possible to define acceptance and test criteria based on the requirements? Have the criteria been defined?
Necessity: Does every requirement contribute to the fulfillment of the goals defined?

29.3.2 Quality Aspects: Documentation

The quality aspect “documentation” deals with checking requirements with respect to flaws in their documentation or violations of the documentation guidelines that are in effect.

Risks of ignoring documentation guidelines:

Impairment of development activities: It may be impossible to carry out development activities that are based upon a specific documentation format.
Misunderstandings: Requirements may not be understandable or may be misunderstood by the people that need to comprehend them. As a result, the requirement may be unusable.
Incompleteness: Relevant information is not documented in the requirements.
Overlooking requirements: If requirements are not documented at the position that they are supposed to in the requirements document, these requirements may be overlooked in subsequent activities.

Benefits of maintaining the “documentation” aspects of vaidation:

Conformity to documentation format and to documentation structures: Are the requirements documented in the predetermined documentation format? For instance, has a specific requirements template or a specific modeling language been used to document the requirements? Has the structure of the requirements document been maintained? For instance, have all requirements been documented at the position defined by the document structure?
Understandability: Can all documented requirements be understood in the context given? For instance, have all terms used been defined in a glossary?
Unambiguity: Does the documentation of the requirements allow for only one interpretation or are multiple different interpretations possi- ble? For instance, does a text-based requirement not possess any kind of ambiguity?
Conformity to documentation rules: Have the predetermined documentation rules and documentation guidelines been met? For instance, has the syntax of the modeling language been used properly?

29.3.3 Quality Aspects: Agreement

Agreed: Is every requirement agreed upon with all relevant stakehold- ers?
Agreed after changes: Is every requirement agreed upon with all rele- vant stakeholders after it has been changed?
Conflicts resolved: Have all known conflicts with regard to the require- ments been resolved?

29.4 Requirements Validation Principles

6 principles that increase the quality of the validation:

Involvement of the Correct Stakeholders
Separating the Identification and the Correction of Errors
Validation from Different Views
Adequate Change of Documentation Type
Construction of Development Artifacts
Repeated Validation

29.5 Requirements Validation Technique

Manual revision techniques are usually known as reviews.

Three major types of reviews are:

Commenting: The author hands his or her requirements over to another person. The goal is to receive the co-worker’s expert opinion with regard to the quality of a requirement.
Inspections:Inspections of software or any other type of product are done to systemat- ically check development artifacts for errors by applying a strict process
Walk-throughs: In requirements validation, a walk-through is a lightweight version of an inspection.

Three other techniques also proved themselves useful:

Perspective-based reading: technique for requirements validation in which requirements are checked by adopting different perspectives
Validation through prototypes: Requirements validation by means of prototypes allows auditors to experience the requirements and to try them out. The most effective method to identify errors in requirements.
Using checklists for validation: A checklist comprises a set of questions and/or statements about a certain circumstance.

29.6 Requirements Negotiation

The conflict management in requirements engineering comprises the following four tasks:

Conflict identification:
Conflict analysis
Conflict resolution
Documentation of the conflict resolution

29.6.1 Conflict Analysis

A data conflict: a deficit of information, by false information, or by different interpretations of some information.
A conflict of interest: characterized by subjectively or objectively different interests or goals of stakeholders
A conflict of value: characterized by differing underlying values stakeholders have regarding some circumstance
A relationship conflict: characterized by strong emotions, stereotypical relationship concepts, deficient communication, or negative interpersonal behavior between stakeholders
A structural conflict: characterized by unequal levels of authority or power

29.6.2 Conflict Resolution

There are multiple conflict resolution techniques, including:

Agreement: all conflict parties negotiate a solution to the conflict
Compromise: all conflict parties try to find a compromise between alternative solutions
Voting: all conflict parties vote on solution alternatives
Definition of variants: the system is developed in a way that permits the definition of variants. This way, the system can satisfy the different interests of the stakeholders.
Overruling: a conflict is resolved by means of the hierarchical organization
Consider-all-facts: all influencing factors of a conflict are being investigated so that as much information about the conflict can be collected as possible
Plus-minus-interesting: all positive and negative repercussions of a solution alternative are investigated so that positive and negative repercussions can be evaluated
Decision matrix: a table is created that contains solution alternatives in the columns and all relevant decision criteria in the rows

29.6.3 Documentation of the Conflict Resolution

If a conflict resolution is not properly documented, the following threats:

Handling conflicts repeatedly
Inappropriate conflict resolution