Chapter 7

Purpose of requirements validation :

- Approving requirements : can be approved for further development activities
- Design, implementation, test, …
- Goal of validation: reviewing requirements in order to discover errors or quality
problems
- Error proliferation : have the necessary level of quality
- Legal risks : especially important in client-contractor relationships

Purpose of requirements negotiation :

- Contradictory requirements cause conflicts
- Risks and opportunities of conflicts
- Unsolved conflicts reduce system acceptance
- Goal of requirements negotiation
- Gain a common and agreed-upon understanding of the requirements among all
stakeholders
- Reducing costs and risks in late phases
- Negotiation needs to be done throughout the entire requirements engineering
process ( not as a single step at end! )

Done by Mariah Brashi

Relevant quality aspects for validation :
1- Content
2- Documentation
3- Agreement
A requirement should only be approved for further development activities if all three quality
aspects are being fulfilled

1- Content :
- Content errors are present when the quality criteria for requirements are
violated
- Fulfilled if no shortcoming have been detected with regard to :
➢ Completeness (set of all requirements)
➢ Completeness (individual requirements)
➢ Traceability
➢ Correctness / adequacy
➢ Consistency
➢ No premature design decisions
➢ Verifiability
➢ Necessity

Done by Mariah Brashi

2- Documentation:
- Documentation errors are present when specification guidelines have been
violated
- Risks of documentation errors
➢ Impairments of development activities
- Format not usable for processing
➢ Misunderstanding
- Requirements consumers do not understand the notation properly
➢ Incompleteness
- Used format does not allow representing all information
➢ Overlooking requirements
- Requirements consumers do not find information where expected
- Fulfilled if no shortcoming have been detected with regard to :
➢ Conformity to documentation format ( e.g. template, notation ) and structure (
e.g. correct section )
➢ Understandability ( e.g. defined terminology )
➢ Unambiguity ( only one possible interpretation )
➢ Conformity to documentation rules ( e.g. correct use of notation syntax )

3- Agreement :
- Agreement errors are present when the set of requirements does not or no
longer represent the stakeholders’ actual needs and expectations
- Fulfilled if no shortcoming have been detected with regard to :
➢ Agreement ( all requirements agreed upon by the stakeholders )
➢ Agreement after changes
➢ Conflict resolution

Done by Mariah Brashi

Essential validation principles :
1- Involvement of correct stakeholders
2- Separation of the identification and correction of errors
3- Validation from different views
4- Adequate change of document type
5- Construction of development artifacts
6- Repeated validation
* These principles are independent of how the validation is performed

Techniques overview :
- Core techniques ( review techniques )
➢ Commenting
➢ Inspections
➢ Walkthrough
- Supporting techniques ( used in conjunction with the core techniques )
➢ Validation checklist
➢ Perspective-based reading
➢ Validation through prototyping
* each technique requires upfront preparation ( e.g. identification and involvement
or correct stakeholders )

Done by Mariah Brashi

Core techniques ( Commenting ):
- Receiving opinions on the quality of the requirements
- Process
1- The author hands out the document to an expert
2- The expert checks for errors and ambiguities
3- The flaws are marked and briefly explained
- Advantages
- Easy to apply
- Low costs
- Disadvantages
- Unsystematic; results depend on expert’s knowledge
- No group effects

Core techniques ( Inspection Process ) :

1- Planning 2- Overview 3- Error detection
4- Error collection and consolidation ( technical review ) 5- Correction
Core techniques ( Inspection ) :
- Systematic error detection
- Advantages
- Very effective and efficient
- Structured process
- Systematic support through reading techniques
- Disadvantages
- costly
- learning effort

Done by Mariah Brashi

Core techniques ( Walkthrough ) :
- Gaining a shared understanding and identifying quality flaws
- Process
1- The author hands out requirements to validators
2- Validators discuss the requirements to be validated one by one
- Advantages
- Stakeholders gain a better understanding
- Active discussions among stakeholders
- Disadvantages
- No formal process
- Risk of the author presenting the requirements too positively

Supporting techniques ( Validation checklists ) :

- Ideal for complex environments in which no aspect may be omitted
- A checklist for requirements validation contains Precise questions that ease the
detection of errors, according to the:
➢ three quality aspects (content, documentation, agreement)
➢ six principles of validation
➢ quality criteria for requirements documents
➢ quality criteria for (single) requirements
➢ experiences from prior projects
➢ error statistics from prior projects
- The checklist should not be longer than one page
- The checklist can range from generic to perspective-specific

Done by Mariah Brashi

Supporting techniques ( Perspective -Based Reading ) :
- Supporting technique, to be applied in conjunction with review techniques
(especially inspections)
- Reviewing the document based on perspective-specific checklists from just one
perspective, e.g.:
➢ user perspective
➢ architect perspective
➢ tester perspective

Supporting techniques ( Validation through prototyping ) :

- Enables stakeholders to experience what they will get
- Considered the most effective means for validation
➢ Prototypes support communication and can be used to test qualities

Situations in which prototyping are useful :

- When stakeholders do not have any experience regarding the system to be built or
do not know in detail what they really need
- When a risk for misunderstandings exists, because:
➢ stakeholders are not able to describe their requirements properly
➢ requirements engineers do not understand the stakeholders correctly
- When a similar product did not exist so far (feasibility unclear)
- When the system is interactive

Done by Mariah Brashi

Disadvantages of prototyping :
- Abstract representation of the system under development can cause
misunderstandings
➢ Wrong expectations (e.g.: system can be developed just as quickly,
feasibility of an innovative new system not proven)
➢ If stakeholders cannot abstract or have too little expertise:
• discussion can easily get lost in the details
• sketches without visual design may not be understood
- Limited functionality
- Design solutions may be taken for granted

Low-Fidelity prototyping:
- Usually first sketches on paper
➢ Intentionally not similar to the final product
- Advantages
➢ Easy to create
➢ Supports communication
➢ Change requests can be “implemented” directly
- Disadvantages
➢ No prototyping of functionality
➢ Throw-away prototype
➢ No assurance that every concept is technically feasible

Done by Mariah Brashi

High-Fidelity prototyping:
- Usually realistic screens developed using software
➢ High similarity to the final system
- Advantages
➢ Functionality can be validated as well
➢ Users can get a feel what the final system is like
- Disadvantages
➢ Costly development
➢ Change requests cannot be incorporated directly
➢ Stakeholders may get the impression that the system is already there

Validation process with prototyping :

1. Selection of requirements that should be validated through the prototype
2. Selection of a suitable class of prototypes
3. Development of the prototype
4. Preparation of a manual or set of instructions for the users, a prototyping
scenario, and a checklist of validation criteria
5. Performing the validation with stakeholders
6. Documentation of the validation results (i.e., own observations and
statements of the stakeholders)
7. Analysis of the results and decision about adaptation
8. (Repeat process)

Done by Mariah Brashi

Performing requirements negotiation :
- Negotiation requires systematic conflict management, which includes:
➢ conflict identification
➢ conflict analysis
➢ conflict resolution
➢ documentation of the resolution

Conflict Identification :
- Conflicts between requirements are often not obvious at first glance
- Conflicts need to identified systematically by:
➢ directly analyzing elicited requirements
➢ analyzing the requirements while documenting them
➢ reviewing the requirements explicitly during validation

Conflict Analysis :
- To resolve contradicting requirements, the underlying reason for the conflict must
be understood
- Main conflict types
1. Subject conflict
2. Conflict of interest
3. Conflict of value
4. Relationship conflict
5. Structural conflict
*Note: In practice, most contradictions have multiple underlying reasons (hybrid conflicts).
The above classification helps to analyze these reasons.

Done by Mariah Brashi

- Subject conflict
➢ Stakeholders have different interpretation of the consequences
• E.g., “Is a response time of 1 second fast enough?”
- Conflict of interest
➢ Stakeholders have different interests or goals
➢ Personal interests are subjective, goals/needs are objective
• E.g., “Should the requirements on integrating the system with the
central human resources system be rejected due to its
implementation costs?”
- Conflict of value
➢ Stakeholders have different cultural and personal preferences
• E.g., “Should the BTB system be developed using open source or
commercial components?”
- Relationship conflict
➢ Negative interpersonal behavior between stakeholders of the same
organizational rank (à “power & politics”)
• E.g., “Should the requirement of the Payroll Director be replaced
by the requirement the Human Resources Director?”
- Structural conflict
➢ Similar to relationship conflict, but between stakeholders on different
levels of the hierarchy
• E.g., “Does the Human Resources Director agrees with the
requirements of Tina Travelmanager?”

Done by Mariah Brashi

Conflict Resolution and documentation :
- Conflict resolution is a success factor for a project
➢ It can motivate or demotivate stakeholders to cooperate further
- It is essential to involve all relevant stakeholders in conflict resolution
➢ Otherwise: some opinions and viewpoints will be neglected
- Conflicts and their resolution must be documented, otherwise:
➢ the same conflicts may arise again and need to be handled anew
➢ the rationale for the requirement is lost and one group of stakeholders will
complain when the system is in place

Conflict Resolution techniques :

- Agreement : one party convinces the other party and both parties agree on a
solution
- Compromise : The parties find a compromise between the contradicting,
alternative requirements or create a new requirement to which all parties agree
- Voting : all stakeholder vote for one of the contradicting requirement, and the
requirement with most votes is selected
- Variants : the conflicting requirements are not resolved, but the system is
developed in different variants (or configurations)
- Overruling : a party with a higher organizational rank selects one of the
conflicting requirements (only if all other techniques have failed)
- …and some more, e.g., decision matrix, plus-minus-interesting, and consider-all-
facts

Done by Mariah Brashi