• Skip to main content
  • Skip to primary sidebar
  • Skip to secondary sidebar
  • Skip to footer

Computer Notes

Library
    • Computer Fundamental
    • Computer Memory
    • DBMS Tutorial
    • Operating System
    • Computer Networking
    • C Programming
    • C++ Programming
    • Java Programming
    • C# Programming
    • SQL Tutorial
    • Management Tutorial
    • Computer Graphics
    • Compiler Design
    • Style Sheet
    • JavaScript Tutorial
    • Html Tutorial
    • Wordpress Tutorial
    • Python Tutorial
    • PHP Tutorial
    • JSP Tutorial
    • AngularJS Tutorial
    • Data Structures
    • E Commerce Tutorial
    • Visual Basic
    • Structs2 Tutorial
    • Digital Electronics
    • Internet Terms
    • Servlet Tutorial
    • Software Engineering
    • Interviews Questions
    • Basic Terms
    • Troubleshooting
Menu

Header Right

Home » Software Engineering » Requirements Validation in Software Engineering
Next →
← Prev

Requirements Validation in Software Engineering

By Dinesh Thakur

The development of software begins once the requirements document is ‘ready’. One of the objectives of this document is to check whether the delivered software system is acceptable. For this, it is necessary to ensure that the requirements specification contains no errors and that it specifies the user’s requirements correctly. Also, errors present in the SRS will adversely affect the cost if they are detected later in the development process or when the software is delivered to the user. Hence, it is desirable to detect errors in the requirements before the design and development of the software begins. To check all the issues related to requirements, requirements validation is performed.

In the validation phase, the work products produced as a consequence of requirements engineering are examined for consistency, omissions, and ambiguity. The basic objective is to ensure that the SRS reflects the actual requirements accurately and clearly. Other objectives of the requirements document are listed below.

  1. To certify that the SRS contains an acceptable description of the system to be implemented
  2. To ensure that the actual requirements of the system are reflected in the SRS
  3. To check the requirements document for completeness, accuracy, consistency, requirement conflict‘, conformance to standards and technical errors.

Requirements validation is similar to requirements analysis as both processes review the gathered requirements. Requirements validation studies the ‘final draft’ of the requirements document while requirements analysis studies the ‘raw requirements’ from the system stakeholders (users). Requirements validation and requirements analysis can be summarized as follows:

  1. Requirements validation: Have we got the requirements right?
  2. Requirements analysis: Have we got the right requirements?

Various inputs such as requirements document, organizational knowledge, and organizational standards are shown. The requirements document should be formulated and organized according to the standards of the organization. The organizational knowledge is used to estimate the realism of the requirements of the system. The organizational standards are specified standards followed by the organization according to which the system is to be developed.      

                                 Requirements Validation

The output of requirements validation is a list of problems and agreed actions of the problems. The lists of problems indicate the problems encountered in the” requirements document of the requirements validation process. The agreed actions is a list that displays the actions to be performed to resolve the problems depicted in the problem list.

We’ll be covering the following topics in this tutorial:

  • Requirements Review
  • Other Requirements Validation Techniques

Requirements Review

Requirements validation determines whether the requirements are substantial to design the system. The problems encountered during requirements validation are listed below.

  1. Unclear stated requirements
  2. Conflicting requirements are not detected during requirements analysis
  3. Errors in the requirements elicitation and analysis
  4. Lack of conformance to quality standards.

To avoid the problems stated above, a requirements review is conducted, which consists of a review team that performs a systematic analysis of the requirements. The review team consists of software engineers, users, and other stakeholders who examine the specification to ensure that the problems associated with consistency, omissions, and errors are detected and corrected. In addition, the review team checks whether the work products produced during the requirements phase conform to the standards specified for the process, project, and the product.

At the review meeting, each participant goes over the requirements before the meeting starts and marks the items which are dubious or need clarification. Checklists are often used for identifying such items. Checklists ensure that no source of errors, whether major or minor, is overlooked by the reviewers. A ‘good’ checklist consists of the following.

  1. Is the initial state of the system defined?
  2. Is there a conflict between one requirement and the other?
  3. Are all requirements specified at the appropriate level of abstraction?
  4. Is the requirement necessary or does it represent an add-on feature that may not be essentially implemented?
  5. Is the requirement bounded and has a clear defined meaning?
  6. Is each requirement feasible in the technical environment where the product or system is to be used?
  7. Is testing possible once the requirement is implemented?
  8. Are requirements associated with performance, behavior, and operational characteristics clearly stated?
  9. Are requirements patterns used to simplify the requirements model?
  10. Are the requirements consistent with the overall objective specified for the system/product?
  11. Have all hardware resources been defined?
  12. Is the provision for possible future modifications specified?
  13. Are functions included as desired by the user (and stakeholder)?
  14. Can the requirements be implemented in the available budget and technology?
  15. Are the resources of requirements or any system model (created) stated clearly?

The checklists ensure that the requirements reflect users’ needs and provide groundwork for design. Using the checklists, the participants specify the list of potential errors they have uncovered. Lastly, the requirements analyst either agrees to the presence of errors or states that no errors exist.

Other Requirements Validation Techniques

A number of other requirements validation techniques are used either individually or in conjunction with other techniques to check the entire system or parts of the system. The selection of the validation technique depends on the appropriateness and the size of the system to be developed. Some of these techniques are listed below.

  1. Test case generation: The requirements specified in the SRS document should be testable. The test in the validation process can reveal problems in the requirement. In some cases test becomes difficult to design, which implies that the requirement is difficult to implement and requires improvement.
  2. Automated consistency analysis: If the requirements are expressed in the form of structured or formal notations, then CASE tools can be used to check the consistency of the system. A requirements database is created using a CASE tool that checks the entire requirements in the database using rules of method or notation. The report of all inconsistencies is identified and managed.
  3. Prototyping: Prototyping is normally used for validating and eliciting new requirements of the system. This helps to interpret assumptions and provide an appropriate feedback about the requirements to the user. For example, if users have approved a prototype, which consists of graphical user interface, then the user interface can be considered validated.

You’ll also like:

  1. Requirements Analysis in Software Engineering
  2. Software Requirements Engineering Tools
  3. Requirements Management Process in Software Engineering
  4. Software Engineering – What is Software Engineering? Write Basic Objective and Need for Software Engineering
  5. Definition of Software Engineering and Software Engineering Layers
Next →
← Prev
Like/Subscribe us for latest updates     

About Dinesh Thakur
Dinesh ThakurDinesh Thakur holds an B.C.A, MCDBA, MCSD certifications. Dinesh authors the hugely popular Computer Notes blog. Where he writes how-to guides around Computer fundamental , computer software, Computer programming, and web apps.

Dinesh Thakur is a Freelance Writer who helps different clients from all over the globe. Dinesh has written over 500+ blogs, 30+ eBooks, and 10000+ Posts for all types of clients.


For any type of query or something that you think is missing, please feel free to Contact us.


Primary Sidebar

Software Engineering

Software Engineering

  • SE - Home
  • SE - Feasibility Study
  • SE - Software
  • SE - Software Maintenance Types
  • SE - Software Design Principles
  • SE - Prototyping Model
  • SE - SRS Characteristics
  • SE - Project Planning
  • SE - SRS Structure
  • SE - Software Myths
  • SE - Software Requirement
  • SE - Architectural Design
  • SE - Software Metrics
  • SE - Object-Oriented Testing
  • SE - Software Crisis
  • SE - SRS Components
  • SE - Layers
  • SE - Problems
  • SE - Requirements Analysis
  • SE - Software Process
  • SE - Software Metrics
  • SE - Debugging
  • SE - Formal Methods Model
  • SE - Management Process
  • SE - Data Design
  • SE - Testing Strategies
  • SE - Coupling and Cohesion
  • SE - hoc Model
  • SE - Challenges
  • SE - Process Vs Project
  • SE - Requirements Validation
  • SE - Component-Level Design
  • SE - Spiral Model
  • SE - RAD Model
  • SE - Coding Guidelines
  • SE - Techniques
  • SE - Software Testing
  • SE - Incremental Model
  • SE - Programming Practices
  • SE - Software Measurement
  • SE - Software Process Models
  • SE - Software Design Documentation
  • SE - Software Process Assessment
  • SE - Process Model
  • SE - Requirements Management Process
  • SE - Time Boxing Model
  • SE - Measuring Software Quality
  • SE - Top Down Vs Bottom UP Approaches
  • SE - Components Applications
  • SE - Error Vs Fault
  • SE - Monitoring a Project
  • SE - Software Quality Factors
  • SE - Phases
  • SE - Structural Testing
  • SE - COCOMO Model
  • SE - Code Verification Techniques
  • SE - Classical Life Cycle Model
  • SE - Design Techniques
  • SE - Software Maintenance Life Cycle
  • SE - Function Points
  • SE - Design Phase Objectives
  • SE - Software Maintenance
  • SE - V-Model
  • SE - Software Maintenance Models
  • SE - Object Oriented Metrics
  • SE - Software Design Reviews
  • SE - Structured Analysis
  • SE - Top-Down & Bottom up Techniques
  • SE - Software Development Phases
  • SE - Coding Methodology
  • SE - Emergence
  • SE - Test Case Design
  • SE - Coding Documentation
  • SE - Test Oracles
  • SE - Testing Levels
  • SE - Test Plan
  • SE - Staffing
  • SE - Functional Testing
  • SE - Bottom-Up Design
  • SE - Software Maintenance
  • SE - Software Design Phases
  • SE - Risk Management
  • SE - SRS Validation
  • SE - Test Case Specifications
  • SE - Software Testing Levels
  • SE - Maintenance Techniques
  • SE - Software Testing Tools
  • SE - Requirement Reviews
  • SE - Test Criteria
  • SE - Major Problems
  • SE - Quality Assurance Plans
  • SE - Different Verification Methods
  • SE - Exhaustive Testing
  • SE - Project Management Process
  • SE - Designing Software Metrics
  • SE - Static Analysis
  • SE - Software Project Manager
  • SE - Black Box Testing
  • SE - Errors Types
  • SE - Object Oriented Analysis

Other Links

  • Software Engineering - PDF Version

Footer

Basic Course

  • Computer Fundamental
  • Computer Networking
  • Operating System
  • Database System
  • Computer Graphics
  • Management System
  • Software Engineering
  • Digital Electronics
  • Electronic Commerce
  • Compiler Design
  • Troubleshooting

Programming

  • Java Programming
  • Structured Query (SQL)
  • C Programming
  • C++ Programming
  • Visual Basic
  • Data Structures
  • Struts 2
  • Java Servlet
  • C# Programming
  • Basic Terms
  • Interviews

World Wide Web

  • Internet
  • Java Script
  • HTML Language
  • Cascading Style Sheet
  • Java Server Pages
  • Wordpress
  • PHP
  • Python Tutorial
  • AngularJS
  • Troubleshooting

 About Us |  Contact Us |  FAQ

Dinesh Thakur is a Technology Columinist and founder of Computer Notes.

Copyright © 2025. All Rights Reserved.

APPLY FOR ONLINE JOB IN BIGGEST CRYPTO COMPANIES
APPLY NOW