REQUIREMENTS

VALIDATION
AND
NEGOTIATION
OBJECTIVES
▪ The essential to validate requirements.
▪ The three quality aspects of requirements.
▪ The six principles of requirements validation.
▪ Different validation techniques.
▪ The significance of conflicts with regard to requirements.
▪ The types of requirements conflicts.
▪ The various conflict resolution techniques.
▪ The documentation of conflict resolution.
RISKS OF NON-VALIDATED
REQUIREMENTS
▪ Subsequent errors in planning, architecture, design, test, implementation
▪ Conflicts are not resolved.
▪ Late error detection at during acceptance.
▪ Client stop trusting the supplier
▪ If consistencies and mistakes turn up repeatedly.

▪ Schedule and budget overrun.

 QUALITY ASPECTS OF
REQUIREMENTS
Following aspects must be validated
I. Content
• Were all the relevant requirements elicited?
• Is the detailing degree appropriate?

II. Documentation
• Are the requirements documented as needed?

III. Agreement
• Do all stakeholder agree with the requirements?
• Are all conflicts solved?
I. VALIDATING THE
CONTENT ASPECT
Goal
▪ Avoid that the development based on false information, that is the development of something that is not
needed.
Search for shortcomings referring to
▪ Completeness
▪ Set all requirements (All requirements documented?)
▪ Individual requirements (Everything described?)

▪ Traceability (Identification?, Source?)

▪ Correctness and Adequacy (Reflects needs adequately?)

▪ Consistency (No contradictions?)

▪ No premature design decision

▪ Verifiability (Acceptance criteria possible?)

▪ Necessity (Contribution to a goal?)
II. VALIDATING THE
DOCUMENTATION ASPECT
Goal
▪ Avoid that the information gaps or the violation of agreed documentation guidelines

Search for shortcomings referring to

▪ Conformity
▪ To documentation format (Templates? Notation?)
▪ To documentation structures (Tables of contents? Filing?)
▪ To documentation rules (Rules for notation?
Text format? Layout?)
▪ Understandability (In context?, Glossary?
For all stakeholders?)
▪ Unambiguity (Interpretation possible?)
III. VALIDATING THE
AGREEMENT ASPECT
Goal
▪ Avoid that some of the stakeholders disagree with the documented requirements.

Search for shortcomings referring to

▪ Agreed (Agreed with all stakeholders?)
▪ Agreed after changes (Changes agreed with all stakeholders?)
▪ Conflicts resolved (All known conflicts solved?)
6 PRINCIPLES OF
REQUIREMENTS VALIDATION
1. Involvement of the correct stakeholders
• Independence of the auditors.
• Involve external ones, when internal lack of expertise.

2. Separating the identification and the correction of errors

• Focusing on the error identification increases detection rate.
• Avoidance of error correction decreases unproductive activity.

3. Validation from different views

• Client views, developers view, auditor view, RE view.

4. Adequate change of documentation type

• Play out the strengths, compensate weakness
• Transcribing from one into another form helps identifying errors.

5. Construction of development artifacts

• Simultaneous activities of developers and testers.

6. Repeated validation
• Re-validate constantly in a heavily changing environment.
VALIDATION OF
REQUIREMENTS
Validation by the client can be done
▪ reviewing documents.
▪ early in the development stage using prototypes.
▪ during the development stage using periodical software increments.
needs needs

requirements Review, Prototype acceptance test

engineering

system test
Requirements System

Software-
Design Integrate, Test
TYPICAL DEFECTS FOUND
DURING REQUIREMENTS CHECK;
CORRECTIVE ACTIONS
Incorrect requirements
▪ Revising the requirements.
▪ Possible only with involvement of the stakeholders.
▪ Incomplete requirements.
▪ Requirements engineer needs to gather the missing information with the stakeholder.
Contradictory requirements
▪ Requirements engineer needs to resolve the contradictions with the stakeholders and thrive for a consensus among
them.
Unrealistic requirements
▪ Requirements engineer needs to discuss and negotiate the requirements with the stakeholders.
Superfluous requirements – not needed
▪ Clarify the benefit of the requirement with the stakeholders.
Attention:
a combination of all these defects is possible
TYPICAL DEFECTS FOUND
DURING REQUIREMENTS
DOCUMENT VALIDATION
▪ System border and context are not represented.
▪ It is not evident, which actor triggers the function.
▪ A data object is not defined but used in a function.
▪ No function is defined that would effect the transition between two states.
▪ Language defects exist.
▪ Symbols with non standard notation are used with no explanation.
▪ Table has empty cells.
▪ Few or none quality requirements.
▪ The measurement methods for quality requirements are insufficient or entirely not defined.
REQUIREMENTS VALIDATION
TECHNIQUES
Static techniques
▪ Reviews (informal review, audit/commenting, walkthrough, inspection)
▪ Matching of different notations
▪ Checking of models with tools (RE-, UML-Tools,…)
▪ Checking by human beings
▪ CRC cards against storyboards.
▪ Storyboards against use cases.
▪ Use cases against data model.
▪ Use cases against state diagrams.
A combination of techniques
Dynamic techniques leads to the best results
▪ Prototypes (behaviour, design, usability)
▪ Simulation(behaviour)
REVIEW BASICS
Validation of requirement documents
▪ Validation can be performed by anyone who understands the content or needs to process it.

Review techniques are standardized in IEEE 1028-2008

Principles of reviews
▪ Four eyes see more than two An uninvolved reader will read
(especially if they were not involved in producing what is written and not what was
the checked item) intended to be written
▪ Early error detection (while they can be removed at a relatively low cost)

Already during preparation the document.

Should be discussed with the future consumer.
REVIEW TECHNIQUES
Inspection formal
▪ Complete formal technique with all roles
▪ Organizer, author, moderator, reviewer, scribe (minute-taker).
▪ and all activities
▪ Planning, distribution of materials (during kick-off), individual
preparation, inspection meeting, decision, post-processing.
▪ Use of checklists
Walkthrough
▪ Less preparation, no checklists formality of
▪ Author presents step by step the checked item the
▪ Author is also the moderator and the scribe techniques
Audit/commenting
▪ Checking by correspondence
▪ Expert opinion
Informal review
▪ No formal process, no record
▪ Spontaneous four eye principle
informal
INSPECTION GOALS AND
VALUE
▪ Focused validation using a checklist
▪ Clear allocation of roles in the team
▪ Moderation
checked
item

▪ High error detection rate

▪ Known and accepted rules of the game ?
▪ Appraisal, no problem resolution specification checklist guideline

▪ Boosts the team spirit

reference material
INSPECTION ROLES IN THE
TEAM
During inspections the team comprises of 3-10 persons
▪ Organizer (typically also the moderator)
▪ Plans and supervises the inspection process.
▪ Moderator (neutral person, not the author or inspectors)
▪ Moderates the meeting, has no opinion.
▪ Enforces rules and manners.
▪ Inspector
▪ Responsible for the finding the errors.
▪ Documents the findings.
▪ Searches for consensus regarding the findings.
▪ Reader (can be moderator)
▪ Presents the requirements to be validated.
▪ Scribe (minute-taker)
▪ Records the issues raised and results of the meeting.
▪ Author
▪ Provides requested information.
INSPECTION COMPOSITION
OF THE TEAM
Inspectors are representatives of all stakeholder groups
▪ Representative of the area of expertise
▪ Represent the knowledge in the application domain of the planned system.
▪ Necessary to check
▪ The content for validation.
▪ The agreement.
▪ Domain expert
▪ Know the specifics of the application area.
▪ Support the checking of the content, the validation.
▪ Representative of the development team
▪ Architects, designer, developer, tester
▪ Check
▪ The documentation.
▪ For feasibility, testability and the quality requirements.
▪ Representative of the Requirements Engineers
▪ Not involved, check the “handicraft”.
INSPECTION TYPICAL PHASES
planning overview

individual inspection
preparation meeting

rework and
decision
revision
REVIEWS THE RESULTING
“REVIEW REPORT”
Classification of findings Recommendation for the decision about the checked item
▪ good ▪ accept
▪ critical error ▪ with or without update.
▪ Must be fixed. ▪ reject
▪ No approval of the checked item without further ▪ update is compulsory
review. ▪ re-review is mandatory
▪ major defect
▪ should be fixed.
▪ no approval without update of the checked item.
▪ minor defect
▪ grammar, layout, …
▪ the checked item can be approved with/without
update.
▪ open issue
▪ No clarification or agreement reached in the
review meeting.
▪ No approval of the checked without
clarification.
EXAMPLE REVIEW REPORT OF
USE CASE DIAGRAM AND
SPECIFICATION
ADDITIONAL VALIDATION
TECHNIQUES - CHECKLISTS
▪ Sources for questions
▪ Quality criteria for requirements documentation.
▪ Quality criteria for individual requirements.
▪ Typical errors in formulating the requirements.
▪ Errors, that have been found in earlier reviews.

▪ Benefits of the checklist

▪ Guideline.
▪ Adequate coverage.

▪ Structure of the checklist

▪ Grouped after the aspects (properties), e.g. completeness or ambiguity of the requirement.
▪ Every reviewer checks a different mix of aspects.
EXAMPLE: CHECKLIST FOR
REVIEW OF USE CASES (1/2)
All questions need to be answered with “yes”, otherwise document a finding in
the review list
Topic Question
Use Case Title 1. Is the title an active phrase expressing the goal of the primary actor?
2. Can the goal be achieved by the system?

Short description 3. Does the description clearly describe the goal of the primary actor?
4. Does it deliver an overview of the main activities?

Primary actor 5. Is the use case triggered by at least one (primary) actor)?
6. Is the primary actor uniquely identified?

Prerequisites 7. Can the system fulfill the required prerequisites?

8. Is it true that no checking of the prerequisites is done in the use case?

Post condition 9. Can the post conditions always be met after a successful development?

Primary path 10. Is it described with 3 to 9 steps?

11. Do the steps lead from trigger to achieved post condition?
12. Are branches and loops correctly described?
13. Are exceptions described as such?
14. At conditions in the flow: Is it defined what procedure shall be taken if the condition is not fulfilled?
EXAMPLE: CHECKLIST FOR
REVIEW OF USE CASES (2/2)
All questions need to be answered with “yes”, otherwise document a finding in
the review list
Topic Question
For every step 15. Can the step be successfully executed?
16. Is it clear in all steps who is the acting actor?
17. Is it clear in all steps what the actor needs to accomplish?
18. Is none of the steps too complex?
19. Is there no design description in any step?
20. Is it unambiguous, what information is processed in each step?
21. Is each step described actively from the view of the acting actor?

Alternative paths 22. Are all alternative paths in the identical business context?
Overall view of the Use 23. Are all features and system requirements traceable to the use cases?
Case 24. No closed “include” chains of use cases exist?
25. The sponsor and user say explicitly: “ We want that”?
26. Can the stakeholder assess after the system delivery, using the use cases, whether they are
implemented?
27. Can the developer answer the question: “Can you develop this system taking the defined constraints
into account?”
ADDITIONAL VALIDATION
TECHNIQUES – PERSPECTIVE
BASED READING
The validation is checked from different views
▪ Possible perspectives from roles
▪ User client
▪ Software architect
▪ Tester
▪ Possible perspectives from quality criteria
▪ Content
▪ Documentation
▪ Agreement
▪ A perspective is assigned to the reviewer
▪ Detailed indications for each perspective.
▪ Questions, which have to be answered by the reviewer.
▪ Questions from the checklist according to the perspective.
▪ Consolidation of the replies, findings and questions.
ADDITIONAL VALIDATION
TECHNIQUES – PROTOTYPING
Advantages
▪ Concrete feedback from usage and experience

▪ Scalable (paper, wireframe, throw away, evolutionary)

▪ Improved expectation management

▪ Disadvantages

▪ Creation, validation and result analysis can be a big effort.

VALIDATION THROUGH
PROTOTYPES
After developing the prototype
▪ Manual, instructions
▪ The auditors must be able to handle the prototype.

▪ Validation scenarios
▪ Relevant data sets and user interactions.

▪ Checklist with validation criteria

▪ Criteria for the validation of the prototype, of the requirements.

▪ Performing the validation

▪ Using the prototype independently
▪ Using experimentally, beside the validation scenarios.

▪ Documentation of the validation results

▪ Protocol of the auditor.
▪ Observation protocol.

▪ Analysis of the results

▪ Change requests on the requirements.
THE CONFLICT MANAGEMENT
To negotiate the requirements you need to identify and resolve conflicts.
This happens through a systematically conflict management.
The four tasks of the conflict management are:
▪ Conflict identification
▪ Conflict analysis
▪ Conflict resolution
▪ Documentation of the conflict resolution
CONFLICT ANALYSIS
Conflict types:
▪ Data conflict
▪ Stakeholders interpret given information differently or have information deficits.

▪ Interest conflict
▪ Stakeholders have factual different needs or divergent personal interests.

▪ Value conflict
▪ Stakeholders have divergent value and preferences.

▪ Relationship conflict
▪ There are emotional problem in personal relationships between stakeholders.

▪ Structural conflict
▪ Conflict roots in stakeholders being on different hierarchy and decision power levels.

Often the conflict reasons are mixed

CONFLICT RESOLUTION
▪ Has impact on future cooperation (motivation) of the stakeholders.

▪ Important: involvement of all relevant stakeholders

Conflict resolution techniques

Agreement Negotiate the solution

Compromise Found through combinations of alternative solutions
Voting Each stakeholder gets to vote
Definition of variants Solve the conflict through system variants and/or parameters
Overruling Decision is made hierarchically
Consider-all-facts All influencing factors are considered
Plus-minus-interesting All positive and negative effects are evaluated
Decision matrix Often named as benefit value anaysis
CONFLICT DOCUMENTATION
Purpose
▪ Avoid repeated treatment of conflicts
▪ Questioning resolutions in case of later issues

Scope
▪ Cause of the conflict
▪ Involved stakeholders
▪ Opinions of the stakeholders
▪ Means of resolving the conflict
▪ Potential alternatives
▪ Decisions and reasons for the decisions
END OF CHAPTER