Scribd
Upload
254 views22 pages

Week 12 - Lecture 1. Requirements Validation and Verification

This document discusses validation and verification of requirements documents. It describes criteria for validating requirements such as ensuring requirements are correct, consistent, unambiguous and complete. Techniques for validation include reading, walkthroughs and formal inspections. Verification techniques ensure the requirements specification corresponds to the requirements definition through traceability checks and consistency checks. Guidelines for writing requirements that are stable include ensuring traceability, avoiding ambiguity and open-endedness, and specifying usage scenarios.

Uploaded by

Ashi Sharma
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
254 views22 pages

Week 12 - Lecture 1. Requirements Validation and Verification

This document discusses validation and verification of requirements documents. It describes criteria for validating requirements such as ensuring requirements are correct, consistent, unambiguous and complete. Techniques for validation include reading, walkthroughs and formal inspections. Verification techniques ensure the requirements specification corresponds to the requirements definition through traceability checks and consistency checks. Guidelines for writing requirements that are stable include ensuring traceability, avoiding ambiguity and open-endedness, and specifying usage scenarios.

Uploaded by

Ashi Sharma
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 22

Requirements Engineering CT056-3-2

Requirements Validation & Verification


Lecture 12

Learning Outcomes
In this chapter, you will learn about: Criteria for validating requirements document Validation Techniques Verification Techniques

CT056-3-2 Requirements Engineering

Elaboration

Key Terms you must be able to use

Validation Verification Formal inspection Walkthroughs

CT056-3-2 Requirements Engineering

Elaboration

Topic & Structure of the lesson

CT056-3-2 Requirements Engineering

Elaboration

Requirements Document
Recall the Requirements document consists of two key sections:

1. Stakeholders Requirements Definitions (Business Requirements)


Describes what we are to deliver from the customers perspective

2. Requirements Specification
Provides details to the software designers/developers Specifies what needs to be built

CT056-3-2 Requirements Engineering

Elaboration

Requirements Definitions & Requirements Specifications

CT056-3-2 Requirements Engineering

Elaboration

Requirements Validation & Verification


Prior to submitting your RE document to designers, it is mandatory that
The customer understands/knows our intents (i.e., Validate requirements definitions)

Our intents are captured in the requirements document


(i.e., Verify the requirements specifications)

Requirements Validation:
Check that our requirements definitions accurately reflect all of the stakeholders needs (i.e., we build the system right) Verify that the requirements specification conforms to the requirements definition (i.e., we build the right system)

Requirements Verification

CT056-3-2 Requirements Engineering

Elaboration

Requirements Validation - Criteria


Desirable characteristics to check for include:
Are the Requirements correct?
Ensure common understanding with the customer/stakeholders of the requirements definitions

Are the requirements consistent?

Ensure there are no conflicting requirements


Multiple readers (reviewers) of the document should not walk away with different but valid interpretations of the document The requirements is considered to be complete if it specifies required behavior and output for all possible inputs in all possible states

Are the requirements unambiguous?

Are the requirements complete?

CT056-3-2 Requirements Engineering

Elaboration

Requirements Validation - Criteria(continued)


Desirable characteristics to check for

Are the requirements feasible?


Does a solution to the customer needs exists?

Is every requirement relevant?


Check if the requirements include functions that are unrelated to customers needs

the

Are the requirements testable? Are the requirements traceable?


Requirements are organized and uniquely labeled (enumerated) for reference Every entry in the requirements definition has a corresponding entry in the requirements specification, and vice versa

CT056-3-2 Requirements Engineering

Elaboration

Requirements Validation Techniques


Reading
Each stakeholder simply reads the document then reports errors and/or provides comments The team signs off on the document after the corrections/comments are incorporated in the document
Team takes responsibility for subsequent errors found in the document

Walkthroughs
One of the RE document authors presents the requirements to the stakeholders and ask for feedback
Useful for large number of varied stakeholders

CT056-3-2 Requirements Engineering

Elaboration

10

Requirements Validation
Validation Techniques (continued)

Formal Inspection
Reviewers take specific roles:
Presenter Moderator Scribe

Reviewers follow prescribed rules


How to examine the requirements When to meet When to take breaks Follow-up inspections

CT056-3-2 Requirements Engineering

Elaboration

11

Requirements Validation
Validation Techniques (continued): Review
Requires representatives from the customers and the SDLC team to examine the document individually and then meet to discuss identified problems Customers team includes:
Employees who will operate the system Employees who will prepare the systems input and those who will use the systems output respectively Key managers of the employees

SDLC team includes:

Systems architects Software Designers Test Team Process Engineer

CT056-3-2 Requirements Engineering

Elaboration

12

Requirements Validation Review (continued)


Review stated goals and objectives Compare requirements with goals and objectives Isolate irrelevant requirements
Customers rep review the flows, use-cases, MSCs to make sure they

accurately customers needs SDLC team reviews the propose functions and constraints to confirm that they realistic (i.e., resources) Assess and document any risks (development/functioning) and agree on alternative approaches Discuss about testing the system

CT056-3-2 Requirements Engineering

Elaboration

13

Requirements Validation Other Techniques


Certain Validation Techniques can be automated
Tools to check for consistency and completeness Tools to check for traceability

Interviews Checklists Models to check functions and relationships Scenarios Prototypes Simulations

CT056-3-2 Requirements Engineering

Elaboration

14

Requirements Verification Techniques


Our objective is to check that the requirement specification document corresponds to our requirements definition document Check that each requirement in the definition/stakeholders document is traceable to the requirements specifications Cross-referencing Simulation Consistency checks
Elaboration

CT056-3-2 Requirements Engineering

15

Guidelines for Writing Requirements Stable Requirements


Traceability
Is the origin of your requirements clear and well understood Can a part of the code (or change to the code) be identified with a unique set or sets of requirements Alternatively, can a requirement (or change to a requirement) be traced to a unique set of code?

Ambiguity
Can any of your requirements be interpreted in more than one way?

Open-Ended
Do the requirements contain phrases such as will support at least 20 online customers?

CT056-3-2 Requirements Engineering

Elaboration

16

Guidelines for Writing Requirements Stable Requirements


Completeness
Are all expected and unexpected responses to an input defined?
Do not assume the sunny-day scenario

Do the requirements specify how frequently a feature will be used? Do the requirements specify the peak hours of use for this feature? Do the requirements differentiate between usage by occasional users of a feature and usage by frequent users?

Consistency
How will you determine if there are any conflicting requirements? What are the decision criteria for resolving conflicting requirements?

CT056-3-2 Requirements Engineering

Elaboration

17

Guidelines for Writing Requirements Stable Requirements

Usage Scenarios
Is there a complete flow analysis from external stimulus through the system and out to external result?
If the answer is no, you may adopt the divide and conquer principle An understanding of how the system will be used is essential if the system is to architected and designed to meet the customer needs

CT056-3-2 Requirements Engineering

Elaboration

18

Guidelines for Writing Requirements


Stable Requirements

Performance Specification
To determine CPU budgets

Are response time, throughput and other performance requirements clearly stated? How were these determined? Are the number and types of users documented? Are transaction rates and/or data volumes known?
To determine CPU budgets To determine Network bandwidth

Complexity
How complex is the algorithm to implement a specific requirement? Can a simpler algorithm be substituted?
CT056-3-2 Requirements Engineering Elaboration

19

Guidelines for Writing Requirements


Stable Requirements

External Interfaces
Are external interfaces well defined and explicit?

Error Control/Recovery
What provisions have been made to recover from lost transaction? What provisions have been made to detect and recover from network failures What provisions have been made to detect and recover from disk crashes of databases (Opensong project)?
20

CT056-3-2 Requirements Engineering

Elaboration

Guidelines for Writing Requirements Stable Requirements


Operations, Administration and Maintenance (OA&M) It is necessary to understand how (and by whom) the system will be operated It is necessary to understand how (and by whom) the system will be administered It is necessary to understand how (and by whom) the system will be maintained

Availability/Reliability
Do the requirements specify system availability and reliability? Downtime requirements What are the MTBF and MTTR figures needed to meet the customer needs?
Note MTBF and MTTR preferred to 7 by 24 or 99.98%

CT056-3-2 Requirements Engineering

Elaboration

21

References
Software Engineering- A practitioners Approach 6th Ed; Roger S. Pressman

Software Requirements Practical techniques for gather and managing requirements through the product development cycle 2nd Ed; Karl E. Wiegers Software Engineering; 6th Ed; Ian Sommervillie

CT056-3-2 Requirements Engineering

Elaboration

You might also like