1

REQUIREMENT VALIDATION

CHAPTER-5

Prepared by: Berhanu S.

 Objectives
 To introduce software verification and validation
and to discuss the distinction between them
 To explain static analysis as a verification
technique
 To describe techniques for inspection, verification
and validation
 To discuss how to evaluate requirement

2
 Requirements Validation

 Requirements Validation
 Check that the right product is
being built
 Ensures that the software being
developed (or changed) will
satisfy its stakeholders
 Checks the software requirements
specification against stakeholders
goals and requirements
3
 Requirements Verification
4

 Check that product is being built right

 Ensures that each step followed in the
process of building the software yields the
right products
 Checks consistency of the software
requirements specification artefacts and
other software development products(design,
implementation) against the specification
 Requirements Checking
 There are different types of checks should be carried out on the
requirements. These checks include:
 Validity checks: The functions proposed by stakeholders should be
aligned with what the system needs to perform.
 Consistency checks: Requirements in the document shouldn’t conflict
or different descriptions of the same function
 Completeness checks: The document should include all the
requirements and constraints.
 Realism checks: Ensure the requirements can actually be
implemented using the knowledge of existing technology, the
budget, schedule, etc.
 Verifiability: Requirements should be written so that they can be
tested.
5
 Requirements Verification and
Validation
 Help ensure delivery of what the client wants
 Need to be performed at every stage during the (requirements)
process
 Elicitation

• Checking back with the elicitation sources

• “So, are you saying that . . . . . ?”
 Analysis

• Checking that the domain description and requirements are correct

 Specification

• Checking that the defined system requirement will meet the user
requirements under the assumptions of the domain/environment
6 • Checking conformity to well-formedness rules, standards
 The V & V process
7

 Is a whole life-cycle process - V & V must be

applied at each stage in the software process.
 Has two principal objectives
 The discovery of defects in a system;
 The assessment of whether or not the system is useful and useable
in an operational situation.
V & V goals
 Verification and validation should establish confidence that the
software is fit for purpose.
 This does NOT mean completely free of defects/imperfections.
 Rather, it must be good enough for its intended use and the type
of use will determine the degree of confidence that is needed.
Wednesday, May 3, 2023
 V & V confidence
8

 Depends on system’s purpose, user expectations and

marketing environment
 Software function
 Thelevel of confidence depends on how critical the software is
to an organisation.
 User expectations
 Users may have low expectations of certain kinds of software.
 Marketing environment
 Gettinga product to market early may be more important than
finding defects in the program.

Wednesday, May 3, 2023

 Independent Validation and
9
Verification
 Can be done by another internal team or external
(other company)

developer independent tester

Understands the system Must learn about the system,

but, will test "gently" but, will attempt to break it
and, is driven by "delivery" and, is driven by quality
Wednesday, May 3, 2023
 Requirements Validation Techniques
 Requirements validation techniques
are used to ensure that the software  Model-based verification
requirements are complete,  Black-box testing
consistent, and correct. Some common  Acceptance testing
techniques used are include:  Test case generation
 Simple checks  Reviews and inspections
 Traceability, well-written
– Walkthroughs
requirements
– Formal inspections
 Prototyping
– Checklists
 Functional test design
 User manual development

10
 Simple Checks
 Various checks can be done using traceability techniques
– Given the requirements document, verify that all
elicitation notes are covered
– Tracing between different levels of requirements
• Checking goals against tasks, features,
requirements…
 Involves developing a traceability matrix
– Ensures that requirements have been taken into
consideration (if not there should be a reason)
– Ensures that everything in the specification is justified
 Verify that the requirements are well written (according
to the criteria already discussed)
11
 Prototyping
 Prototyping an executable model of the system is demonstrated to the
customer and end-users to validate and ensure if it meets their needs.
 Prototyping is usually used when the requirements aren’t clear. So, we
make a quick design of the system to validate the requirements. If it
fails, we then refine it, and check again, until it meets the customer's
needs.
 Excellent for validation by users and customers
– More accessible than specification

– Demonstrate the requirements and help stakeholders discover

problems
 Come in all different shapes and sizes
– From paper prototype of a computerized system to formal
12
executable models/specifications
 Continued…
 Prototyping-based validation steps
 Choose prototype testers

 Develop test scenarios

• Careful planning is required to draw up a set of test
scenarios which provide broad coverage of the
requirements
• Users should not just play around with the system as this
may never exercise critical system features
 Execute test scenarios

 Document problems using a problem reporting tool

13
 Functional Test Design and User Manual
Development
 The two V&V techniques, namely Functional Test
Design and User Manual Development, are not really
V&V techniques.
 They are activities that must be performed anyway,
and they are based on the specification document.
– Through these activities, as for any other activities
based on the specification document, errors and
other problems with this document may be
detected.

14
 Functional Test Design
 Functional tests at the system level must be developed sooner or later...
 Can (and should) be derived from the requirements specification
 Each (functional) requirement should have an associated test
 Non-functional (e.g., reliability) or exclusive (e.g., define what should
not happen) requirements are harder to validate with testing
 Each requirements test case must be traced to its requirements
 Inventing requirements tests is an effective validation technique
 Designing these tests may reveal errors in the specification (even
before designing and building the system)!
– Missing or ambiguous information in the requirements description
may make it difficult to formulate tests
 Some software development processes (e.g., agile methods) begin with
tests before programming  Test-Driven Development (TDD)
15
 User Manual Development
 The Same reasoning as for functional test design
– Has to be done at some point

– Reveals problems earlier

 It forces a detailed look at requirements

 Particularly useful if the application is rich in user
interfaces / for usability requirements
 Typical information in a user manual
– Description of the functionality

– How to get out of trouble

– How to install and get started with the system

16
 Continued…
 Model-based verification: This technique involves creating a model
of the system and simulating it to see if it meets the requirements.
 Black-box testing: This technique involves testing the system without
any knowledge of its internal structure or implementation, to see if
it meets the requirements.
 Acceptance testing: This technique involves testing the system with
real users to see if it meets their needs and requirements.
 Test case generation: Requirement mentioned in SRS document
should be testable, the conducted tests reveal the error present in
the requirement. It is generally believed that if the test is difficult or
impossible to design than, this usually means that requirement will
be difficult to implement and it should be reconsidered.
17
 Requirements review
 A group of people read and analyze requirements,
look for potential problems, meet to discuss the
problems, and agree on a list of action items needed
to address these problems.
 Systematic manual analysis of the requirements.
 Reviews can be expensive because they involve many
people over several hours reading and checking the
requirements document.
 A widely used requirements validation technique
– Lots of evidence of effectiveness of the technique

18
 Continued…
19

 Can be expensive
– Careful planning and preparation

– Pre-review checking

– Need appropriate checklists (must be developed if

necessary and maintained)
 Check the document and look for straightforward
problems such as missing requirements (sections), lack
of conformance to standards, typographical errors,
etc.
 Types of reviews
 Different types of reviews with varying degrees of
formality exist (similar to JAD vs. brainstorming
sessions)
 Reading the document
• A person other than the author of the document
 Reading and approval (sign-off)
• Encourages the reader to be more careful (and
responsible)
 Walkthroughs
 Technical reviews
 Inspection etc.
20
 Typical Review / Inspection Steps
 Plan review
 The review team is selected and a time and place for the review meeting is
chosen
 Distribute documents
 The requirements document is distributed to the review team members

21
 Continued…
 Prepare for review
 Individual reviewers read the requirements to find conflicts, omissions,
inconsistencies, deviations from standards, and other problems
 Hold review meeting
 Individual comments and problems are discussed and a set of action items to
address the problems is established

22
 Continued…
 Follow-up actions
 The chair of the review checks that the agreed action items have been carried
out
 Revise document
 Requirements document is revised to reflect the agreed action items
 At this stage, it may be accepted or it may be re-reviewed

23
 Active Review

• Reviewer is asked to use the specification

• Author asks reviewer questions which can
only be answered with the help of the
document to be reviewed
• Author poses questions for the reviewer to
answer that can be answered only by
reading the document
• Author may also ask reviewer to simulate a
set of scenarios
24
 Review Team
 Reviews should involve a number of stakeholders
drawn from different backgrounds
 People from different backgrounds bring different skills
and knowledge to the review
 Stakeholders feel involved in the RE process and
develop an understanding of the needs of other
stakeholders
 Review team should always involve at least a domain
expert and a user

25
 Review Checks
26

The checklist for a requirements review

 Completeness (have all functional and quality requirements
described in the problem statement been included?);
 Correctness (do the requirements reflect the user’s needs? are
they stated without error?);
 Comprehensibility – can readers of the document understand
what the requirements mean?
 Clarity (it is very important to identify and clarify any
ambiguous requirements);
 Ambiguity – are the requirements expressed using terms which
are clearly defined? Could readers from different backgrounds
make different interpretations of the requirements?
 Continued…
 Relevance (is the requirement pertinent to the problem area?
Requirements should not be superfluous);
 Redundancy (a requirement may be repeated; if it is a duplicate
it should be combined with an Equivalent one);
 Testability (can each requirement be covered successfully with one
or more test cases? can tests determine if the requirement has
been satisfied?);
 Feasibility (are requirements implementable given the conditions
under which the project will progress?).
 Traceability – are requirements unambiguously identified? Do
they include links to related requirements and to the reasons why
these requirements have been included?
27
 Continued…

 Organisation – is the document structured in a sensible way?

Are the descriptions of requirements organised so that related
requirements are grouped?
 Conformance to standards – does the requirements document
and individual requirements conform to defined standards?
Are departures from the standards justified?
 Consistency – do the descriptions of different requirements
include contradictions? Are there contradictions between
individual requirements and overall system requirements?

28
 Inconsistency management
29

 Inconsistency is the violation of consistency rule among

items
 Inconsistencies are highly frequent in RE
 Inter-viewpoints:-each stakeholder has its own focus and
concern
 Intra-viewpoint:- conflicting quality requirement
 Inconsistencies must be detected and resolved…
 Not too soon: - to allow further elicitation within
viewpoint.
 Not too late:- to allow software development
 Type of Inconsistency
30

 Terminology clash:- the same concept named differently in

different statements. E.g “borrower vs Patron
 Designation clash:- The same name for different concepts in
different statements. E.g Library user vs Library software user
 Structure clash: The same concept structured differently in
different statements. E.g “latest return date” as time point vs
time interval
Handling clash
 Create glossary of terms
 Precise, intelligible definition of all terms used
 Accepted synonyms
 Detection of conflicts
31

Conflict detection
 Informally or formally (theorem proving techniques

?)
 Using heuristics on conflicting requirement
categories
 Using conflict patterns
 Managing conflicts-> systematic approach
32
 Documenting conflict
33

 Record for later resolution , find statements involved in

multiple conflicts
 Most conflicting, non-conflicting statement , overlapping
statements
 Interaction matrix (kotonya& Sommerville, 1997)
 Row and column -> single statement
 Si,j=1 if Si conflicts with Sj
 Si,j=0 if Si andSj are distinct , don’t overlap
 Si,j=n, n Element of N, n>1 if Si and Sj overlap without
conflicting
 Interaction matrix Example
34
 Generating Conflict Resolution
35

 For optimal resolution:

 Explore multiple candidate resolution first,
 Compare, select/agree on most preferred next
 To generate candidate resolutions
 Elicitation techniques (interviews, group sessions)
 Resolution tactics
 Resolution Tactics
36

 Avoid boundary condition : “keep copies of highly

needed books unborrowable
 Restore conflicting statements :”copy returned within X
weeks and then borrowed again
 Weaken conflicting statements: ”copy returned within
X weeks unless explicit permission “
 Drop lower –priority statements
 Specialize conflict source or target:” Book loan status
known by staff users only “
 Transform conflicting statements or involved objects ,
or introduce new requirements
 Selecting alternative
37

Evaluation criteria for preferred resolution:

 Contribution to critical non-functional requirements

 Contribution to resolution of other conflicts and risks

 Advantages of Using Requirements Validation
Techniques

 Improved quality of the final product

 Reduced development time and cost
 Increased user involvement
 Improved communication
 Easy testing and validation
 Increased alignment with business goals
 Traceability
 Agile methodologies

38
 Disadvantages of Using Requirements Validation
Techniques
39

 Increased time and cost

 Risk of conflicting requirements
 Risk of changing requirements
 Misinterpretation and miscommunication
 Dependence on the tool
 Limited validation
 Limited to functional requirements
 Validation vs. Analysis
• Both have several activities in common
– Reading requirements, problem analysis, meetings and
discussions...
• Analysis works with raw, incomplete requirements as
elicited from the system stakeholders
– Develop a software requirements specification document
– Emphasis on "we have the right requirements“
• Requirements Validation works with a software
requirements specification and with negotiated and
agreed (and presumably complete) domain requirements
– Check that this these specifications are accurate
40
– Emphasis on "we have the right requirements well done"
 Test planning
41

 Careful planning is required to get the most out of

testing and inspection processes.
 Planning should start early in the development process.
 The plan should identify the balance between static
verification and testing.
 Test planning is about defining standards for the testing
process rather than describing product tests.

Wednesday, May 3, 2023

 The structure of a software test plan
42

 The testing process.

 Requirements traceability.
 Tested items.
 Testing schedule.
 Test recording procedures.
 Hardware and software requirements.
 Constraints.

Wednesday, May 3, 2023

Thank You!