Validating the Validating the RequirementsRequirements

Chapter 15Chapter 15

Prepared by :Prepared by :

AHMED ABU SA'DA AHMED ABU SA'DA

Moataz Moataz WassimWassim

- -May – 2010 May – 2010 1818

2009/20102009/2010

IntroductionIntroduction: :

Most software developers have experienced the Most software developers have experienced the frustration of being asked to implement frustration of being asked to implement requirements that were ambiguous or requirements that were ambiguous or incomplete. If they can't get the information incomplete. If they can't get the information they need, the developers have to make their they need, the developers have to make their own interpretations, which aren't always own interpretations, which aren't always correct. Substantial effort is needed to fix correct. Substantial effort is needed to fix requirement errors after work based on those requirement errors after work based on those requirements has already been completed.requirements has already been completed.

Requirements validation is the Requirements validation is the fourth component—with fourth component—with elicitation, analysis, and elicitation, analysis, and

specification specification of requirements of requirements developmentdevelopment

Requirements validation Requirements validation activities attempt to ensure activities attempt to ensure

thatthat The SRS correctly describes the intended system The SRS correctly describes the intended system

capabilities and characteristics that will satisfy capabilities and characteristics that will satisfy the various stakeholders' needsthe various stakeholders' needs..

The software requirements were correctly derived The software requirements were correctly derived from the system requirements, business rules, or from the system requirements, business rules, or other sources.other sources.

The requirements are complete and of high The requirements are complete and of high quality.quality.

All requirements representations are consistent All requirements representations are consistent with each other.with each other.

The requirements provide an adequate basis to The requirements provide an adequate basis to proceed with design and construction.proceed with design and construction.

Validation ensures that the requirements Validation ensures that the requirements exhibit the desirable characteristics of exhibit the desirable characteristics of excellent requirement statements excellent requirement statements ((complete, correct, feasible, necessary, complete, correct, feasible, necessary, prioritized, unambiguous, and verifiableprioritized, unambiguous, and verifiable) ) and of excellent requirements and of excellent requirements specifications specifications ((complete, consistent, complete, consistent, modifiable, and traceablemodifiable, and traceable). ). Of course, Of course, you can validate only requirements that you can validate only requirements that have been documented, not implicit have been documented, not implicit requirements that exist only in requirements that exist only in someone's mindsomeone's mind..

Validation isn't a single discrete phase Validation isn't a single discrete phase that you perform after gathering and that you perform after gathering and documenting all the requirementsdocumenting all the requirements. . Some Some validation activities, such as incremental validation activities, such as incremental reviews of the growing SRS, are threaded reviews of the growing SRS, are threaded throughout the iterative elicitation, throughout the iterative elicitation, analysis, and specification processesanalysis, and specification processes. . Other activities, such as formal SRS Other activities, such as formal SRS inspection, provide a final quality gate inspection, provide a final quality gate prior to baselining the SRSprior to baselining the SRS. . Include Include requirements validation activities as requirements validation activities as discrete tasks in your project plandiscrete tasks in your project plan..

Reviewing RequirementsReviewing Requirements

Informal reviews are useful for Informal reviews are useful for educating other people about the educating other people about the product and collecting unstructured product and collecting unstructured feedback. However, they are not feedback. However, they are not systematic, thorough, or performed in systematic, thorough, or performed in a consistent way. a consistent way.

Informal review approaches Informal review approaches includeinclude::

AA peer deskcheckpeer deskcheck, , in which you ask in which you ask one colleague to look over your work one colleague to look over your work productproduct

AA passaroundpassaround, , in which you invite in which you invite several colleagues to examine a several colleagues to examine a deliverable concurrentlydeliverable concurrently

AA walkthroughwalkthrough, , during which the during which the author describes a deliverable and author describes a deliverable and solicits comments on itsolicits comments on it

The Inspection ProcessThe Inspection Process

Inspection is a well-defined Inspection is a well-defined multistage process. It involves a multistage process. It involves a small team of trained participants small team of trained participants who carefully examine a work who carefully examine a work product for defects and improvement product for defects and improvement opportunities. Inspections provide a opportunities. Inspections provide a quality gate through which quality gate through which documents must pass before they documents must pass before they are baselined. are baselined.

Inspection RolesInspection Roles

All participants in an inspection, All participants in an inspection, including the author, look for defects including the author, look for defects and improvement opportunities. and improvement opportunities. Some of the inspection team Some of the inspection team members perform the following members perform the following specific roles during the inspection.specific roles during the inspection.

Inspection Roles contInspection Roles cont....

AuthorAuthor ModeratorModerator ReaderReader RecorderRecorder

Entry CriteriaEntry Criteria

You're ready to inspect a requirements document You're ready to inspect a requirements document when it satisfies specific prerequisiteswhen it satisfies specific prerequisites. . TheseThese entry criteriaentry criteria set some clear expectations for set some clear expectations for authors to follow while preparing for an authors to follow while preparing for an inspectioninspection. . They also keep the inspection team They also keep the inspection team from spending time on issues that should be from spending time on issues that should be resolved prior to the inspectionresolved prior to the inspection. . The moderator The moderator uses the entry criteria as a checklist before uses the entry criteria as a checklist before deciding to proceed with the inspectiondeciding to proceed with the inspection. .

Inspection StagesInspection Stages An inspection is a multistep process, as An inspection is a multistep process, as

illustrated inillustrated in Figure 15-2Figure 15-2. . The purpose The purpose of each inspection process stage is of each inspection process stage is summarized briefly in the rest of this summarized briefly in the rest of this sectionsection..

PlanningPlanning

  The author and moderator plan the The author and moderator plan the inspection togetherinspection together. . They determine who They determine who should participate, what materials the should participate, what materials the inspectors should receive prior to the inspectors should receive prior to the inspection meeting, and how many inspection meeting, and how many inspection meetings will be needed to inspection meetings will be needed to cover the materialcover the material. . The inspection rate has The inspection rate has a large impact on how many defects are a large impact on how many defects are foundfound

The number of defects found The number of defects found depends on the inspection depends on the inspection

raterate. . AsAs Figure 15-3Figure 15-3 shows, proceeding through the shows, proceeding through the

SRS slowly reveals the most defectsSRS slowly reveals the most defects. (. (An An alternative interpretation of this frequently alternative interpretation of this frequently reported relationship is that the inspection slows reported relationship is that the inspection slows down if you encounter a lot of defectsdown if you encounter a lot of defects.) .) Because Because no team has infinite time available for no team has infinite time available for requirements inspections, select an appropriate requirements inspections, select an appropriate rate based on the risk of overlooking major rate based on the risk of overlooking major defectsdefects. . Two to four pages per hour is a practical Two to four pages per hour is a practical guideline, although the optimum inspection rate guideline, although the optimum inspection rate for maximum defectfor maximum defect--detection effectiveness is detection effectiveness is about half that rate about half that rate ((Gilb and Graham 1993Gilb and Graham 1993). ). Adjust this rate based on the following factorsAdjust this rate based on the following factors::

The number of defects found The number of defects found depends on the inspection depends on the inspection

raterate. .

Overview meetingOverview meeting    

During the overview meeting, the During the overview meeting, the author describes the background of author describes the background of the material the team will be the material the team will be inspecting, any assumptions he inspecting, any assumptions he made, and his specific inspection made, and his specific inspection objectivesobjectives. . You can omit this stage if You can omit this stage if all inspectors are already familiar all inspectors are already familiar with the items being inspectedwith the items being inspected. .

Defect checklist for software Defect checklist for software requirements specificationsrequirements specifications. .

Organization and CompletenessOrganization and Completeness CorrectnessCorrectness Quality AttributesQuality Attributes TraceabilityTraceability Special IssuesSpecial Issues

Requirements Review Requirements Review ChallengesChallenges

Large requirements documentsLarge requirements documents    The The prospect of thoroughly inspecting a severalprospect of thoroughly inspecting a several--hundredhundred--page SRS is dauntingpage SRS is daunting. . You might You might be tempted to skip the inspection entirely be tempted to skip the inspection entirely and just proceed with construction—not a and just proceed with construction—not a wise choicewise choice. . Even given an SRS of moderate Even given an SRS of moderate size, all inspectors might carefully examine size, all inspectors might carefully examine the first part and a few stalwarts will study the first part and a few stalwarts will study the middle, but it's unlikely that anyone will the middle, but it's unlikely that anyone will look at the last partlook at the last part. .

Requirements Review Requirements Review ChallengesChallenges

Large inspection teamsLarge inspection teams    Many project Many project participants and customers hold a stake in participants and customers hold a stake in the requirements, so you might have a the requirements, so you might have a long list of potential participants for long list of potential participants for requirements inspectionsrequirements inspections. . However, large However, large inspection teams make it hard to schedule inspection teams make it hard to schedule meetings, tend to hold side conversations meetings, tend to hold side conversations during inspection meetings, and have during inspection meetings, and have difficulty reaching agreement on issuesdifficulty reaching agreement on issues..

Testing the RequirementsTesting the Requirements

It's hard to visualize how a system It's hard to visualize how a system will function under specific will function under specific circumstances just by reading the circumstances just by reading the SRSSRS. . Test cases that are based on Test cases that are based on the functional requirements or the functional requirements or derived from user requirements help derived from user requirements help make the expected system behaviors make the expected system behaviors tangible to the project participantstangible to the project participants. .

Testing the RequirementsTesting the Requirements

You can begin deriving conceptual You can begin deriving conceptual test cases from use cases or other test cases from use cases or other user requirements representations user requirements representations very early in the development very early in the development processprocess . .

Some conceptual test cases Some conceptual test cases would be the followingwould be the following: : User enters order number to view, order User enters order number to view, order

exists, user placed the orderexists, user placed the order. . Expected Expected resultresult: : show order detailsshow order details..

User enters order number to view, order User enters order number to view, order doesn't existdoesn't exist. . Expected resultExpected result: : Display Display message message ""Sorry, I can't find that orderSorry, I can't find that order."."

User enters order number to view, order User enters order number to view, order exists, user didn't place the orderexists, user didn't place the order. . Expected resultExpected result: : Display message Display message ""Sorry, Sorry, that's not your orderthat's not your order."."

Ideally, an analyst will write the Ideally, an analyst will write the functional requirements and a tester functional requirements and a tester will write the test cases from a will write the test cases from a common starting point, the user common starting point, the user requirements, as shown inrequirements, as shown in Figure 15-6Figure 15-6

Figure 15-6: Development and testing work products are derived from a common source.

The notion of testing requirements The notion of testing requirements might seem abstract to you at firstmight seem abstract to you at first. . Let's see how the Chemical Tracking Let's see how the Chemical Tracking System team tied together System team tied together requirements specification, analysis requirements specification, analysis modeling, and early testmodeling, and early test--case case generationgeneration.. Following are Following are a business a business requirement, a use case, some requirement, a use case, some functional requirements, functional requirements, part of a dialog part of a dialog map, and a test casemap, and a test case, all of which relate , all of which relate to the task of requesting a chemicalto the task of requesting a chemical. .

Business requirementBusiness requirement    

business requirement is from the business requirement is from the vision and scope documentvision and scope document ..

""Establishing the Product Vision and Establishing the Product Vision and Project ScopeProject Scope."."

Use caseUse case    

A use case that supports this A use case that supports this business requirement is business requirement is ""Request a Request a ChemicalChemical." ." This use case includes a This use case includes a path that permits the user to request path that permits the user to request a chemical container that's already a chemical container that's already available in the chemical stockroomavailable in the chemical stockroom. .

Functional requirementFunctional requirement    

  Here's a bit of functionality Here's a bit of functionality associated with this use caseassociated with this use case::

1.1. If the stockroom has containers of If the stockroom has containers of the chemical being requested, the the chemical being requested, the system shall display a list of the system shall display a list of the available containersavailable containers..

2.2. The user shall either select one of The user shall either select one of the displayed containers or ask to the displayed containers or ask to place an order for a new container place an order for a new container from a vendorfrom a vendor..

Test caseTest case

The use case has several possible The use case has several possible execution paths, you can envision execution paths, you can envision several test cases to address the several test cases to address the normal course, alternative courses, normal course, alternative courses, and exceptionsand exceptions. .

Use cases and test cases work well Use cases and test cases work well together in two waystogether in two ways: : If the use If the use cases for a system are complete, cases for a system are complete, accurate, and clear, the process of accurate, and clear, the process of deriving the test cases is deriving the test cases is straightforwardstraightforward. . And if the use cases And if the use cases are not in good shape, the attempt to are not in good shape, the attempt to derive test cases will help to debug derive test cases will help to debug the use casesthe use cases..

Defining Acceptance CriteriaDefining Acceptance Criteria

Software developers might believe Software developers might believe that they've built the perfect that they've built the perfect product, but the customer is the final product, but the customer is the final arbiterarbiter. . Customers perform Customers perform acceptance testing to determine acceptance testing to determine whether a system satisfies itswhether a system satisfies its acceptance criteriaacceptance criteria

Acceptance testingAcceptance testing

Acceptance testing should focus on Acceptance testing should focus on anticipated usage scenariosanticipated usage scenarios..

Acceptance tests focus on the Acceptance tests focus on the normal courses of the use cases, not normal courses of the use cases, not on the less common alternative on the less common alternative courses or whether the system courses or whether the system handles every exception condition handles every exception condition properlyproperly. .

Acceptance CriteriaAcceptance Criteria

Having customers develop acceptance Having customers develop acceptance criteria thus provides another opportunity to criteria thus provides another opportunity to validate the most important requirementsvalidate the most important requirements. . It's a shift in perspective from the It's a shift in perspective from the requirementsrequirements--elicitation question of elicitation question of ""What do What do you need to do with the system?you need to do with the system?" " to to ""How How would you judge whether the system satisfies would you judge whether the system satisfies your needs?your needs?" " If the customer can't express If the customer can't express how she would evaluate the system's how she would evaluate the system's satisfaction of a particular requirement, that satisfaction of a particular requirement, that requirement is not stated sufficiently clearlyrequirement is not stated sufficiently clearly. .

Acceptance CriteriaAcceptance Criteria

Writing requirements Writing requirements isn't enoughisn't enough.. You You need to make sure that they're the right need to make sure that they're the right requirements and that they're good enough requirements and that they're good enough to serve as a foundation for to serve as a foundation for design, design, construction, testing, and project construction, testing, and project managementmanagement.. Acceptance test planning, Acceptance test planning, informal reviews, SRS inspections, and informal reviews, SRS inspections, and requirements testing techniques will help requirements testing techniques will help you to build higheryou to build higher--quality systems faster quality systems faster and more inexpensively than you ever have and more inexpensively than you ever have beforebefore. .

Thank you for you attentionThank you for you attention