ContentsMeeting the contract . . . . . . . . . . . . . . . . . . . . . .2The requirements management problem . . . . . . . . .2A better approach . . . . . . . . . . . . . . . . . . . . . . . .4

Complete and verifiable requirements . . . . . . . . . .4Traceability between requirements . . . . . . . . . . . .5Traceability across the application lifecycle . . . . . .5Applying risk factors . . . . . . . . . . . . . . . . . . . . .9A lifecycle quality management platform . . . . . . .9

The HP difference . . . . . . . . . . . . . . . . . . . . . . . .10The right solution . . . . . . . . . . . . . . . . . . . . . . .10The right services . . . . . . . . . . . . . . . . . . . . . . .10A complete solution . . . . . . . . . . . . . . . . . . . . .10

Learn more . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Reducing risk through requirements-driven quality management:An end-to-end approachWhite paper

Meeting the contractWhen IT undertakes a development project, it signs—figuratively or literally—a contract with the business.The contract spells out what requirements will befulfilled and when they will be delivered. Further, ITcommits to a level of quality in the product that assuresits success when deployed. No attorney would permita client to sign a legal contract unless all the risks wereknown, yet IT departments often lack the ability toquantify and respond to the risks that arise duringdevelopment and test. Requirements management—aspart of a comprehensive software quality managementsystem—helps IT quantify the risks associated witheach requirement and make informed decisions aboutresource allocation and release.

More than 60 percent of IT organizations that use an automated software quality system use HP QualityCenter software. HP Quality Center software goesbeyond traditional approaches to requirements man-agement by allowing quality managers to reduce riskand optimize the business outcome of the project. Thispaper shows how it does this by tracing requirementsfrom definition to release and by giving IT and bus-iness managers real data to support decisions aboutcontract fulfillment.

The requirements managementproblemThe dynamics of software quality management arewell understood. For example, most people know thatthe majority of software defects are introduced early in the application lifecycle but found much later. Asshown in Figure 1, the National Institute of Standardsand Technology (NIST) estimates about 70 percent ofsoftware defects are introduced in the requirementsphase.2 And the later they are found, the more expensivethey are to fix. According to one study, the cost to fix adefect after delivery is more than100 times the cost tofix it in the requirements and design phase. Thesefacts highlight the need for close collaboration withbusiness users, careful, unambiguous requirementsdefinition and management of requirements throughoutthe application lifecycle.

2

More than 60 percent of ITorganizations that use an automatedsoftware quality system use HPQuality Center software.1

Risk

Qualitycontract

ITresources

Businessrequirements

Commitment

Managing requirements through definition, development,test and release is a joint effort between businessanalysts—who represent the customer’s needs—andsoftware quality managers who shepherd them throughthe testing and release process. When their name ison the contract, business analysts must:

• Define concise and unambiguous requirements.

• Establish the business value of each requirement.

• Quantify the risk associated with each requirement.

• Understand the dependencies of each requirement.

Software quality managers have critical questions toanswer:

• Are the requirements verifiable when implemented?

• Are the requirements realistic, and how will they beimplemented and tested?

• Where do I assign testing resources for increasedefficiency and reduced risk?

• Is the planned testing for the requirement a goodtrade-off between the requirement’s business valueand its risk?

Even with careful planning, requirements change, andchanges ripple through development, test and release.Changes pose additional questions:

• How does the change affect other requirements?

• What tests are affected by the change?

• What new risks are introduced by the change?

• What is the effect on release?

Without answers to the questions above, trade-offdecisions become a crapshoot. Analysts may believeone requirement is more important than another, butthey cannot show why. Test planners may decide toreduce the test effort on some requirements, but theycannot quantify the risk of doing so, and they cannotdemonstrate that the risk is justified given the businessvalue of the requirement. When functionality must bedropped from a release, no one can demonstrate tothe business that the proposed change offers the bestbusiness value at the appropriate risk point comparedto other alternatives.

3

Figure 1: NIST software qualitystudy results

Introduction of defects80%

60%

40%

20%

0%Requirementand design

Codingand

unit test

Useracceptance

test

Production

Detection of defects80%

4%

17%

60%

21%

60%

40%

20%

0%Requirementand design

Codingand

unit test

Useracceptance

test

Production

Testrequirements

Business processes

Tests

Effects

Businessrequirements

Release

An effective requirements management system musthelp both business analysts and quality managersmeet their commitments with limited resources and inthe face of inevitable change. They need a structuredway to manage requirements, and they need real datato evaluate alternatives. Just as important, they need away to engage business users in a meaningful conver-sation about business value and risk. HP QualityCenter software helps them do that.

A better approachMany software vendors offer requirements manage-ment as a silo in a quality management system, butrisk-based requirements and quality management areinseparable from the larger process of managing theplanning, test and release of a software system. Thereare three factors that enable requirements and qualitymanagement:

• Complete and verifiable requirements

• Traceability of requirements across the applicationlifecycle

• Evaluation of a requirement’s business value and risk factors

We will look at how HP Quality Center uses thesefactors to manage requirements and how that fits intothe larger quality management process.

Complete and verifiable requirements The first challenge for business analysts and qualitymanagers is to create requirements that are complete,clear and verifiable. HP Quality Center software lets ITdetermine what information must be included in anyrequirement. Custom workflows—triggered by requirementtype or even the attributes of an individual requirement—facilitate the collection and inclusion of the neededdata and invoke other actions needed to promoteconsistent and complete requirements definition. Sinceusers interact with the software through everydayinterfaces like web browsers and Microsoft® OfficeWord, requirements can be routed to other analystsand even business users for review, verification or even updating.

4

HP Quality Center softwaremaintains traceability betweenrequirements and provides otherfeatures to make traceability auseful tool for the analyst or quality manager.

Traceability between requirementsIf John Donne had been a business analyst rather than a 17th century poet, he might have said, “Norequirement is an island.” Requirements have a naturalparent-child relationship because high-level businessrequirements can be decomposed into lower levelfunctional requirements that, in turn, generate specifictest requirements. For example, the business require-ment “Generate e-mail confirmation to customer onlineorder” would produce a number of distinct functionalrequirements (“Verify e-mail address,” “Transmitmessage,” “Receive returned e-mail message,” etc.),each of which needs to be implemented in a codemodule and requires testing.

Understanding these relationships is essential toplanning and executing adequate test coverage. Andwhen analyzing a proposed change to a requirement—or test procedure—you must know what other require-ments may be affected by the change. HP QualityCenter software maintains traceability betweenrequirements and provides other features to maketraceability a useful tool for the analyst or qualitymanager. For example:

• Users can define multiple types of requirements and maintain relationships between them.

• Requirement types can be customized for eachproject.

• Trace-to and trace-from views display the parent/child relationship between requirements.

• Requirements can be organized into folders foreasier navigation.

• Requirements can be imported from Microsoft®

Word, or users can work directly in Microsoft Wordwithin HP Quality Center software.

• Stakeholders are automatically informed via e-mail orrequirements traceability alerts when a requirementchanges.

• Audit trail tracks which values are changed and when.

Traceability across the application lifecycleTraceability between requirements only solves part ofthe problem. It is also essential to follow individualrequirements through the application lifecycle to test,defects and release. That means testers and qualitymanagers can see what and how much testing isplanned for each requirement. They can analyze thestatus of the testing to see how much has been com-pleted and how many defects have been found (Figure2). And when defects are found, it lets them see whichrequirements are affected.

5

Figure 2: Tracing requirements totest and defects

Test status by requirement

Applying defect history—Boehm and Basili find thathistorically 80 percent of the defects occur in 20percent of the modules, and approximately 50 percentof the modules have no defects at all.3 The challengefor quality managers is to assign testing effort where it is most needed and to reduce effort where it is not.Tracing requirements to module defect history showswhich requirements are most likely to experience prob-lems and exactly which tests must be run to cover thatcritical 20 percent. When quality managers know wheretest effort is best applied to mitigate deployment risk,they can finally begin to plan for defects rather thanjust react to them.

Planning for release—No change draws moreattention than a change in release date or in therequirements served by a release. HP Quality Centersoftware allows quality managers to allocate entirerequirements trees to a release and then to assignindividual requirements to cycles within the plannedrelease. Aligning all testing assets—requirements, tests,defects—to releases, cycles and builds enables thequality assurance organization to monitor and reporton progress. Quality managers can see at a glancehow much test coverage has been planned for individualrequirements, how much has been completed and howmany tests have passed. This is shown in Figure 3.

Associating requirements and other test assets to tests,defects and release also lets IT examine the quality ofrelease cycles over time. Have all critical requirementsbeen validated by testing? Is the defect-fix rate up?Has the defect-found rate shown that marked downturnwe want? Release cycles can be compared to eachother to see how much test coverage has been completedbetween cycles or to compare the efficiency of the testeffort to internal goals. HP Quality Center softwareprovides the data that IT executives look for in projectupdates and that quality assurance needs to makesmart release decisions.

6

Figure 3: Planning for release

Test coverage by release cycle

7

Managing change—In addition to smart planning,analysts and quality managers must make rightdecisions about change. HP Quality Center softwarehelps quality managers see how requirements areaffected by planned changes to testing and release.They make better decisions, and they can better justifydecisions to business users and executive management.

Risk-based requirements and quality managementWe have seen how HP Quality Center software’s end-to-end approach to managing requirements providesthe planning data that IT needs. But even more criticalis the need to apply that data to reduce risk at deploy-ment. That’s what the contract demands.

The need to evaluate and mitigate risk goes beyondtraditional requirements management solutions, and itposes additional questions for business analysts andquality assurance managers:

• Is the planned test coverage adequate given thebusiness criticality of the requirement?

• Where can we reduce effort with the least risk?

• What time/resource/risk trade-offs enable the bestbusiness outcome?

• How do we communicate risk to business users andset proper expectations?

In quality management terms:

Risk = business impact of failure * probability failurewill occur.

When requirements traceability is combined with theability to assess and quantify a requirement’s businesscriticality and failure probability, we have the basis fortrue risk-based requirements and quality management.And it is this ability to evaluate and mitigate risk thatincreases our chance for a successful business outcometo a development project.

Assessing business criticalityUsers and business analysts usually have a sense ofhow important individual requirements are, but thesejudgments are subjective. They often lack the tools toquantify business criticality, to apply business criticalityin trade-off decisions and to justify criticality trade-offsto their management. HP Quality Center softwareprovides analysts a structured and objective approachto assess the business impact of requirements.

HP Quality Center software providesthe data that IT executives look for in project updates and that qualityassurance needs to make smartrelease decisions.

A requirement’s business impact usually depends uponseveral factors. For example:

• How many customers might be affected by a defect?

• Does the module change data or only display it?

• Could a resulting error mean legal liability for thecompany?

• How often is the feature used?

And there may be other criteria that analysts establishfor a particular enterprise or application.

Characterizing each criterion according to its impact,HP Quality Center software calculates a businesscriticality assessment value which can be used tocompare one requirement to another (Figure 4).

Assessing business criticality is a joint effort between IT and the business. The process of evaluating howfailure might impact the business establishes a commonvocabulary with business users and creates sharedunderstanding. When business managers ask “Why?”IT and business users stand shoulder-to-shoulder to answer.

Failure probabilityWhen the question is, “What’s the chance it will fail?”however, all eyes are on IT. Probability of failuredepends upon the overall maturity of the softwaresystem, the extent to which the software is beingchanged and the defect rate experience with thespecific software module. HP Quality Center softwareprovides quality assurance managers a similar quanti-tative way to evaluate failure probability (Figure 5).And remember, because requirements are traceable toother requirements, tests and defects, we have realdata to apply to failure probability.

8

Figure 4: Evaluating arequirement’s business criticality

Calculated business criticality

Applying risk factorsWe have seen that each requirement is assigned abusiness criticality factor—A, B or C—and a probabilityof failure—1, 2 or 3. Thus, each requirement maps intoa risk category such as A1, A3 or B2. This helps intwo ways:

Risk comparison—Requirements can be comparedbased on risk. This is crucial when trade-off decisionsmust be made—and when they must be explained.When business users are engaged with IT businessanalysts in calculating business criticality and when IT has a structured, understandable way to analyzeprobability of failure, then recommendations are based on real data, and trade-off decisions become a team effort.

Test effort optimization—Test plans should allocate the most effort where there is the most risk. Since HPQuality Center software traces requirements to testplans, it can easily analyze the test effort by riskcategory.

Figure 6 shows this. This data shows quality managersif they are applying test effort in the right places. And it indicates at a glance how possible changesin the test plan impact risk.

A lifecycle quality management platformRisk-based quality management is possible only whenrequirements management is an integral part of alifecycle quality management platform. The ability toanalyze the risk and business benefit of each require-ment and then trace that requirement right through test,defects and release gives quality managers the dataneeded to make smart decisions. HP Quality Centersoftware does just that, and it does it right out of thebox. No special integration is required, and becausethere is a single repository, no data synchronization isever needed. The results are quicker time to value andlower total cost of ownership.

9

Figure 5: Assessing arequirement’s failure probability

Calculated failure probability

The HP differenceYou have choices when it comes to automated softwarequality management solutions. When you must meetthe contract, why choose HP?

The right solution• HP Quality Center software offers a lifecycle approach

to quality management. You have seen how ourlifecycle approach helps optimize the business outcomeof development projects. Piecemeal approaches don’tprovide the data needed when you are asked thehard questions.

• HP Quality Center software provides the platformand application coverage you need.

• HP Quality Center software supports a qualitymethodology model in your organization. Using it,you can implement best practices and repeatableprocesses designed to save time and cost compared to traditional approaches.

• HP Quality Center software is the industry leader.IDC says 61 percent of IT shops using an automatedsoftware quality solution use HP Quality Centersoftware. And some of the biggest developmentshops in the world—including SAP—use it.

• HP Quality Center software accelerates time tovalue. When a solution provides the functionality wehave described—and does it right out of the box—you get going quicker and with less implementation cost.

The right servicesHP provides quality software services that address yourneeds across the application lifecycle. Global serviceand support—from online self-solve support to proactivemission-critical services—enable you to choose theservices that best match your business needs.

A complete solutionTraining—HP provides a comprehensive curriculum of HP Software and IT Service Management trainingcourses. These offerings provide the training you needto realize the full potential of your HP solutions.

Managed services—If you want help operating yourHP solutions, HP offers managed services to bring thevalue you want quickly.

Finance services—HP Financial Services providesinnovative financing and financial asset managementprograms to help you cost-effectively acquire, manageand ultimately retire your HP solutions.

10

Figure 6: Planning test effort by requirement risk category

Requirements per risk category

Test hours per risk category

Learn moreIf your business wants your signature on a qualitycontract, find out more about HP Quality Centersoftware today.

To learn more about software quality management,order our book.

Optimize Quality for Business Outcomes by AndreasGolze, Charlie Li and Shel Prince, paperback: 210pages, language: EnglishOrder: www.merc-training.com/main/us

For an overview of HP software services, visit www.managementsoftware.hp.com/service

To access technical interactive support, visit SoftwareSupport Online at www.hp.com/managementsoftware/services

To learn more about HP Software CustomerConnection, a one-stop information and learningportal for software products and services, visitwww.hp.com/go/swcustomerconnection

To find an HP Software sales office or reseller nearyou, visit www.managementsoftware.hp.com/buy

1IDC, Worldwide Distributed Automated Software Quality Tools 2006–2010 Forecast2NIST 2002 RTI Project 7007.0113B. Boehm and V. Basili, “Software Defect Reduction Top 10 List,” IEEEComputer, IEEE Computer Society, Vol. 34, No. 1, January 2001, pp. 135–137.

11

To learn more, visit www.hp.com/go/software© Copyright 2007 Hewlett-Packard Development Company, L.P. The information contained herein is subject tochange without notice. The only warranties for HP products and services are set forth in the express warrantystatements accompanying such products and services. Nothing herein should be construed as constituting anadditional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation.

4AA1-2112ENW, May 2007