Requirements validation – requirements engineering

Requirements Engineering
Requirements Engineering
Mutah University
Faculty of IT, Department of Software Engineering
Dr. Ra’Fat A. AL-msie’deen
https://sites.google.com/site/ralmsideen/
[email protected]
1

validation is the process of checking that
requirements define the system that the customer really
wants.
 It overlaps with elicitation and analysis, as it is
concerned with finding problems with the requirements.
 Requirements validation is critically important because
errors in a requirements document can lead to extensive
rework costs when these problems are discovered
during development or after the system is in service.
3

cont.
 The cost of fixing a requirements problem by making a
system change is usually much greater than repairing
design or coding errors.
 A change to the requirements usually means that the
system design and implementation must also be
changed.
 Furthermore, the system must then be retested.
4

cont.
 Concerned with demonstrating that the requirements
define the system that the customer really wants.
 Requirements error costs are high so validation is very
important
 Fixing a requirements error after delivery may cost up
to 100 times the cost of fixing an implementation
error.
530/10/2014

the requirements validation process, different
types of checks should be carried out on the
requirements in the requirements document. These
checks include:
 Validity checks
 These check that the requirements reflect the real
needs of system users. Because of changing
circumstances, the user requirements may have
changed since they were originally elicited.
6

cont.
 During the requirements validation process, different
types of checks should be carried out on the
requirements in the requirements document. These
checks include:
 Consistency checks
 Requirements in the document should not conflict.
That is, there should not be contradictory constraints
or different descriptions of the same system function.
7

cont.
 During the requirements validation process, different
types of checks should be carried out on the
requirements in the requirements document. These
checks include:
 Completeness checks
 The requirements document should include
requirements that define all functions and the
constraints intended by the system user.
8

cont.
 During the requirements validation process, different
types of checks should be carried out on the
requirements in the requirements document. These
checks include:
 Realism checks
 By using knowledge of existing technologies, the
requirements should be checked to ensure that they
can be implemented within the proposed budget for
the system.
 These checks should also take account of the budget
and schedule for the system development.
9

cont.
 During the requirements validation process, different
types of checks should be carried out on the
requirements in the requirements document. These
checks include:
 Verifiability
 To reduce the potential for dispute between customer
and contractor, system requirements should always
be written so that they are verifiable.
 This means that you should be able to write a set of
tests that can demonstrate that the delivered system
meets each specified requirement.
10

cont.
 Validity.
 Does the system provide the functions which best
support the customer’s needs?
 Consistency.
 Are there any requirements conflicts?
 Completeness.
 Are all functions required by the customer included?
 Realism.
 Can the requirements be implemented given available
budget and technology
 Verifiability.
 Can the requirements be checked? 11

A number of requirements validation techniques can be
used individually or in conjunction with one another:
 Requirements reviews
 The requirements are analyzed systematically by a
team of reviewers who check for errors and
inconsistencies.
12

… cont.
 A number of requirements validation techniques can be
used individually or in conjunction with one another:
 Prototyping
 This involves developing an executable model of a
system and using this with end-users and customers
to see if it meets their needs and expectations.
 Stakeholders experiment with the system and feed
back requirements changes to the development team.
13

… cont.
 A number of requirements validation techniques can be
used individually or in conjunction with one another:
 Test-case generation
 Requirements should be testable. If the tests for the
requirements are devised as part of the validation
process, this often reveals requirements problems.
 If a test is difficult or impossible to design, this usually
means that the requirements will be difficult to
implement and should be reconsidered.
 Developing tests from the user requirements before
any code is written is an integral part of test-driven
development. 14

… cont.
 Requirements reviews
 Systematic manual analysis of the requirements.
 Prototyping
 Using an executable model of the system to check
requirements.
 Test-case generation
 Developing tests for requirements to check testability.
1530/10/2014

requirements
 You should not underestimate the problems involved in
requirements validation.
 Ultimately, it is difficult to show that a set of requirements
does in fact meet a user’s needs.
 Users need to picture the system in operation and
imagine how that system would fit into their work.
 It is hard even for skilled computer professionals to
perform this type of abstract analysis and harder still for
system users.
16

requirements problems
 As a result, you rarely find all requirements problems
during the requirements validation process.
 Inevitably, further requirements changes will be needed
to correct omissions and misunderstandings after
agreement has been reached on the requirements
document.
17

reviews should be held while the requirements
definition is being formulated.
 Both client and contractor staff should be involved in
reviews.
 Reviews may be formal (with completed documents) or
informal.
 Good communications between developers, customers
and users can resolve problems at an early stage.
1830/10/2014

Is the requirement realistically testable?
 Comprehensibility
 Is the requirement properly understood?
 Traceability
 Is the origin of the requirement clearly stated?
 Adaptability
 Can the requirement be changed without a large
impact on other requirements?
1930/10/2014

Book:
 Software Engineering (l0th Edition) – by Ian Sommerville.
Addison Wesley, 2015, ISBN-10: 0137035152.
 Chapter 4.
20

Requirements Engineering
Requirements Engineering
Mutah University
Faculty of IT, Department of Software Engineering
Dr. Ra’Fat A. AL-msie’deen
https://sites.google.com/site/ralmsideen/
[email protected]
21