Software projects are supposed to solve one or more business problems, and most software development books urge us to make sure we are building the "right" system to address the problems at hand. However, this verification can be challenging, because very few processes/frameworks provide the tools we need to do it.

Typically, what teams call requirements management is basically an effort to unambiguously document what the stakeholders want the proposed system to do. IBM Rational RequisitePro enables you to capture this information as "Stakeholder Requests." But from then on, it is the job of a requirements analyst/manager to verify that the system will solve the business problem.

In a large enterprise, although the managers who sponsor a project usually have an idea of how the proposed system will help them achieve their business goals, perhaps hundreds of other stakeholders may not have this understanding, because the project team lacks effective ways to communicate information about the system. This article briefly outlines how we used IBM Rational RequisitePro on an Infosys development project to formally capture why the project sponsors committed several million dollars and thousands of management hours to it, and how this record helped us verify that we were building a system that addressed the business needs they had in mind.

The goal graph
First, we used a goal graph to capture business/IT goals and their interrelationship in an easy-to-understand visual format. This graph complements a root cause analysis, or RCA. The RCA identifies the source of a problem, and the goal graph identifies how the project will resolve the problem. This information is not typically captured in the requirements specifications or applied in the requirements traceability.

Figure 1 shows a sample goal graph.

Figure 1: Generic goal graph
Click to enlarge

To understand why this additional information is important, suppose you were a bank that was trying to figure out why your organization is losing market share for one of its key loan products. Through root cause analysis, you might discover some basic causes:

• Customers want new products.
• Customers want the loan decision faster.
• Your current systems cannot support new business processes.

The primary goal of the new system you develop for solving the problem would be to increase market share. To achieve that goal, you would also need to fulfill one or more secondary goals, such as "enable the system to introduce new products quickly," "enable the system to reduce decision time," and so forth.

What I've been describing is a project I worked on recently. We asked the sponsors to describe, in one or two sentences, why they wanted to undertake such a large initiative. Using a goal graph, we were able to "why down" the project to two primary goals:

1. Increase market share
2. Increase profitability (per loan)

In the process, we discovered a host of secondary goals that we'd need to meet in order to facilitate the primary goal. In turn, these secondary goals required support from more narrowly defined project goals, which would be implemented through system features.

Traceability and impact analysis capabilities
Our next steps were to insert the goal graph in the IBM Rational RequisitePro Vision document and create a new requirement type in Rational RequisitePro: GOAL. Then we captured a textual description of each goal in the Vision document and assigned it the requirement type GOAL, as shown in Figure 2.

Figure 2: Capturing goals in the IBM Rational RequisitePro Vision document

As I've noted, we viewed the system features as a means to implement the goals. Therefore, we traced all features to one or more goals. As usual, we went on to establish traceability between features and use cases (features can be implemented by one or more use cases), which meant we then had traceability among goals, features, and use cases.

Essentially, designating GOAL as a requirement type enabled us to create a traceability matrix between GOAL and FEATURES, which in turn enabled us to do a thorough coverage analysis and ensure that the project was fulfilling all its goals. It also allowed us to identify and eliminate features that might not be linked to the project goals, as the query in Figure 3 indicates.

Figure 3: IBM Rational RequisitePro coverage analysis query to discover features not linked to project goals

Finally, by creating a traceability matrix between goals and features, we gained a really important predictive capability: We were able to see clearly what goals we might not be able to fulfill if we decided not to implement a certain feature. This enabled us to set priorities for functionality and understand which features we could sacrifice if we ran into a time crunch. Figure 4 shows a traceability matrix/impact analysis for thirteen system features versus primary and secondary project goals.

Figure 4: Impact analysis in IBM Rational RequisitePro: How features relate to goals

Overall: Greater visibility into project value
From this brief description, I hope you are able to understand how much value you can derive from doing a small amount of extra work to leverage the capabilities of IBM Rational RequisitePro. By creating a goal graph and integrating the data into the requirements tool, you can create the matrices you need to plan and assess the value of project features and ensure that you are building a system that truly fulfills the business goals your organization has set for it.

About the author

Comments

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• About the author
• Comments

Next steps from IBM

• Try: Rational RequisitePro
• Demo: Creating requirements with Rational RequisitePro
• Webcast: Modernization approaches to reduce the total cost for multi-platform enterprise applications
• Briefing: Jazz and Rational Team Concert
• Buy: Rational RequisitePro

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers