Scribd Logo
Upload

Welcome to Scribd!

  • 30 views

    OOSAD Chapter 4

    Uploaded by

    HD HD
    The document discusses requirement validation techniques used during the software development process. It describes validation as checking that requirements meet stakeholder goals and do not conflict, while verification ensures each development step yields the right products. Some validation techniques discussed include simple checks, reviews and inspections, scenario testing, prototype testing, and product testing. Requirements elicitation results and analysis are documented in a Requirements Analysis Document.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    OOSAD Chapter 4

    Uploaded by

    HD HD
    30 views5 pages
    The document discusses requirement validation techniques used during the software development process. It describes validation as checking that requirements meet stakeholder goals and do not conflict, while verification ensures each development step yields the right products. Some validation techniques discussed include simple checks, reviews and inspections, scenario testing, prototype testing, and product testing. Requirements elicitation results and analysis are documented in a Requirements Analysis Document.

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document discusses requirement validation techniques used during the software development process. It describes validation as checking that requirements meet stakeholder goals and do not conflict, while verification ensures each development step yields the right products. Some validation techniques discussed include simple checks, reviews and inspections, scenario testing, prototype testing, and product testing. Requirements elicitation results and analysis are documented in a Requirements Analysis Document.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    30 views5 pages

    OOSAD Chapter 4

    Uploaded by

    HD HD
    The document discusses requirement validation techniques used during the software development process. It describes validation as checking that requirements meet stakeholder goals and do not conflict, while verification ensures each development step yields the right products. Some validation techniques discussed include simple checks, reviews and inspections, scenario testing, prototype testing, and product testing. Requirements elicitation results and analysis are documented in a Requirements Analysis Document.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    You are on page 1of 5

    Werabe University IT Department

    Chapter Four
    Requirement Validation
    4.1 Introduction
     Requirements are continuously validated with the client and the user. Validation is a
    critical step in the development process, given that both the client and the developer
    are dependent on the system specification
     Requirement validation involves checking if the specification is correct, complete,
    consistent, unambiguous, and realistic.
     A specification is correct if it represents the client’s view of the system (i.e.,
    everything in the requirements model accurately represents an aspect of the system).
     It is complete if all possible scenarios through the system are described, including
    exceptional behavior (i.e., all aspects of the system are represented in the
    requirements model).
     The system specification is consistent if it does not contradict itself.
     The system specification is unambiguous if exactly one system is defined (i.e., it is
    not possible to interpret the specification two or more different ways).
     Finally, it is realistic if the system can be implemented within constraints.
    4.2 Requirements Validation and Verification
     Validation (& Verification), is the process of checking whether the requirements,
    as identified, do not contradict the expectations about the system of various
    stakeholders and do not contradict each other.
     It is Requirements Quality Control
    Validation vs. Verification
     Validation: “Am I building the right product?” checking a work product against
    higher-level work products or authorities that frame this particular product.
    • Ensures that the software being developed (or changed) will satisfy its
    stakeholders.

    Object Oriented System Analysis & Design 1


    Werabe University IT Department

    • Checks the software requirements specification against stakeholders’


    goals and requirements.
    • Requirements validation makes sure that requirements meet
    stakeholders’ goals and don’t conflict with them.
    o Requirements are validated by stakeholders
     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.
     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.
    o Requirements are verified by the analysts mainly
    4.3 Various Requirements V&V Techniques
     Simple checks
     Reviews and inspections
     Scenario Test
     Prototype Test
     Product test
    4.3.1 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
    o Checking goals against tasks, features, requirements…
     Verify that the requirements are well written.

    Object Oriented System Analysis & Design 2


    Werabe University IT Department

    4.3.2 Reviews and Inspections


     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.
    4.3.3 Scenario Test
     During this test, one or more users are presented with a visionary scenario of
    the system. Developers identify how quickly users are able to understand the
    scenario, how accurately it represents their model of work, and how positively
    they react to the description of the new system.
     The selected scenarios should be as realistic and detailed as possible.
     A scenario test allows rapid and frequent feedback from the user.
     The advantage of scenario tests is that they are cheap to realize and to repeat.
     The disadvantages are that the user cannot interact directly with the system
    and that the data are fixed
    4.3.4 Prototype test
     During this type of test, one or more users are presented with a piece of
    software that practically implements the system.
     A vertical prototype implements a complete use case through the system, and a
    horizontal prototype presents an interface for most use cases (without providing
    much or any functionality).
     The advantages of prototype tests are that they provide a realistic view of the
    system to the user and that prototypes can be instrumented to collect detailed
    data.
     The disadvantages of prototypes are that they are expensive to build and to
    modify.
    4.3.5 Product test
     This test is similar to the prototype test except that a functional version of the
    system is used in place of the prototype.

    Object Oriented System Analysis & Design 3


    Werabe University IT Department

     A product test can only be conducted once most of the system is developed. It
    also requires that the system be easily modifiable such that the results of the
    usability test can be taken into account
    4.4 Documenting requirements elicitation
     The results of the requirements elicitation activity and the analysis activity are
    documented in the Requirements Analysis Document (RAD).
     This document completely describes the system in terms of functional and
    nonfunctional requirements and serves as a contractual basis between the client
    and the developers.
     The audience for the RAD includes the client, the users, the project
    management, the system analysts (i.e., the developers who participate in the
    requirements), and the system designers (i.e., the developers who participate in
    the system design).

    Object Oriented System Analysis & Design 4


    Werabe University IT Department

    Object Oriented System Analysis & Design 5

    You might also like