Alliance Collage

Object Oriented System Analysis & Design

Chapter 4
 Ensuring Your Requirements Are correct
Requirement validation Techniques
• Requirements validation is concerned to check the
requirements document for consistency, completeness, and
accuracy.
• It is the system conforming to its requirements.
• Requirements validation is a critical step in the development
process, usually after requirements analysis.
• Validation works with a final draft of the requirements
document i.e. with negotiated and agreed requirements.
• All known incompleteness and inconsistency of requirements
are removed during validation.
• Validation process is more concerned with the way in which
the requirements are described.
• Requirements are validated by stakeholders.
 Cont…
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
Validation: checks you are solving the right problem
• “Are we building the right system?”
• “Have we got the requirements right?”
• Does our problem statement accurately capture the real problem?
• Did we account for the needs of all the stakeholders?
 Validation objectives

• Certifies that the requirements document is an

acceptable description of the system to be
implemented
• Checks a requirements document for
– Completeness and consistency
– Conformance to standards
– Requirements conflicts
– Technical errors
– Ambiguous requirements
 Cont….
Two validation criteria:
• Did we discover (and understand) all the important
Requirements?
• Did we discover (and understand) all the relevant
Domain properties?
Validation Techniques
• Prototyping - gets customer feedback early
• Inspection - domain experts read the specification
carefully
• Model Analysis (e.g. Model Checking) - mathematical
analysis of your models
 Validation inputs

• Requirements document
– Should be a complete version of the document, not an
unfinished draft. Formatted and organized according to
organizational standards
• Organizational knowledge
– Knowledge, often implicit, of the organization which
may be used to judge the realism of the requirements
• Organizational standards
– Local standards e.g. for the organization of the
requirements document
 Validation outputs

• Problem list
– List of discovered problems in the requirements
document
• Agreed actions
– List of agreed actions in response to requirements
problems. Some problems may have several
corrective actions; some problems may have no
associated actions
 Cont…
• Validation inputs and outputs
Requirements
document List of problems

Organisational Requirements
knowledge validation Agreed actions

Organisational
standards
 Verification
• “Am I building the product right?” Checking a work product against
some standards and conditions imposed on this type of product
and the process of its development. Requirements are verified by
the analysts mainly.
Requirements Verification
• 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
artifacts and other software development products (design,
implementation ...) against the specification
Verification Techniques
• Making Specifications Traceable
• Testing
• Code checking
 Requirements testing

• Each requirement should be testable i.e. it

should be possible to define tests to check
whether or not that requirement has been met.
• Inventing requirements tests is an effective
validation technique as missing or ambiguous
information in the requirements description
may make it difficult to formulate tests
• Each functional requirement should have an
associated test
 Test case definition

• What usage scenario might be used to check

the requirement?
• Does the requirement, on its own, include
enough information to allow a test to be
defined?
• Is it possible to test the requirement using a
single test or are multiple test cases required?
• Could the requirement be re-stated to make
the test cases more obvious?
 Test record form

• The requirement’s identifier

– There should be at least one for each requirement.
• Related requirements
– These should be referenced as the test may also be relevant to these
requirements.
• Test description
– A brief description of the test and why this is an objective requirements
test. This should include system inputs and corresponding outputs.
• Requirements problems
– A description of problems which made test definition difficult or
impossible.
• Comments and recommendations
– These are advice on how to solve requirements problems which have
been discovered.
 Hard-to-test requirements
• System requirements
– Requirements which apply to the system as a whole. In general,
these are the most difficult requirements to validate irrespective
of the method used as they may be influenced by any of the
functional requirements. Tests, which are not executed, cannot
test for non-functional system-wide characteristics such as
usability.
• Exclusive requirements
– These are requirements which exclude specific behavior. For
example, a requirement may state that system failures must
never corrupt the system database. It is not possible to test such
a requirement exhaustively.
• Some non-functional requirements
– Some non-functional requirements, such as reliability
requirements, can only be tested with a large test set. Designing
this test set does not help with requirements validation.
 Key points
• Requirements validation should focus on checking the final draft
of the requirements document for conflicts, omissions and
deviations from standards.
• Inputs to the validation process are the requirements document,
organizational standards and implicit organizational knowledge.
The outputs are a list of requirements problems and agreed
actions to address these problems.
• Prototyping is effective for requirements validation if a prototype
has been developed during the requirements elicitation stage.
• Systems models may be validated by paraphrasing them. This
means that they are systematically translated into a natural
language description.
• Designing tests for requirements can reveal problems with the
requirements. If the requirement is unclear, it may be
impossible to define a test for it.
 Use case Scenario Testing
• Scenario is a textual description of how a system behaves
under a specific set of circumstances.
• Scenarios also provide a basis for developing test cases and
acceptance-level test plans. Behavior described in use cases
is the basis for scenarios.
• A realization of a use case.
• Flow of event
• Instance of an use case that effectively tests one path
through a use case
• To demonstrate whether a use case accurately reflects user
needs
• useful during testing
 Cont….
• There are two types of scenario testing.
• Type 1 – scenarios used as to define input/output
sequences. They have quite a lot in common with
requirements elicitation.
• When we do scenario testing type 1, we use the
scenarios to write transactions as sequences of
• Input
• Expected output
• E.g. be an extremely detailed textual use case.
 Cont…
• Type 2 – scenarios used as a script for a sequence
of real actions in a real or simulated environment.
• When it comes to realism, scenario testing type 2
is the ultimate testing method. The goal of
scenario testing is to test how the system will
behave
• In real word situations – described by scenarios
• With real users, supplied by the system owner
• With real customers – if necessary
 Cont…
• A scenario tests is done as follows:
• The environment is arranged according to the scenario description.
Customers are instructed as needed.
• A person – the game master – reads out each step of the scenario.
• Users and customers react to the situations created by the game
master.
• The events resulting from each scenario is documented – e.g. by a
video camera or by one or more observers – for later assessment.
• The number of possible scenarios is large. Which scenarios we select
depends on the customer’s priorities. In addition, since scenario tests
are expensive, we can usually just afford to run a few.
• Scenarios are most efficient when we want to test requirements
involving a strong interaction with the systems environment – users,
customers, networks, file servers, a stressful work situation etc.
 Cont…
Example:
• Consider the use case “Track License Application”
• There are at least two possible scenarios:
• the applicant enters the license application number; the system
retrieves the information related to it; the system displays this
information
• the applicant enters the license application number; the
number does not exist in the agency’s database; the system
displays an error message
• Scenario: the applicant enters the license application number;
the system retrieves the information related to it; the system
displays this information.
 Cont…
• Steps:
• Applicant requests to track status of a license application
• System displays the logon form
• Applicant enters the logon information
• Applicant submits the logon information
• System validates the applicant
• System displays the form to enter the tracking number
• Applicant enters the tracking number
• Applicant submits the license number
• System retrieves the license information
• System displays the license information