 | Level: Intermediate Brian Wallenfelt (bwallen@us.ibm.com), Software Engineer, IBM
Wayne Carrigan (carrigan@us.ibm.com), Software Engineer, IBM
07 Oct 2005
Updated 28 Nov 2005 IBM Rational RequisitePro is a "team-based requirements management tool". This seems to be a simple enough concept, but in reality RequisitePro's flexibility and configurability leads to multiple "How do I deploy?" questions. This article will briefly describe a "disruptive" deployment, and then compare it to one development team's use of RequisitePro in a "non-disruptive" deployment.
Introduction IBM Rational RequisitePro is a tool for finding, documenting, organizing, and tracking requirements. It also includes features that aid in establishing and maintaining agreement between the customer and the development team regarding project requirements. The Microsoft® Word document association with requirements in the RequisitePro database, for instance, is quite useful. However, one of the most intriguing features -- on which this article will focus -- is the linking capability. Traceability links can be established and then monitored for change. If change occurs the link becomes "suspect". This feature makes deploying RequisitePro into an already existing and mature requirements tracking process, such as IBM's Integrated Product Development (IPD), very attractive.
While RequisitePro has many features worth exploring, this article will focus on utilizing the traceability linking capability. At the core, there are three basic scenarios for deploying RequisitePro:
- New project: you need new tools and processes for requirements tracking
- Existing project, change process: you are looking to replace the entire requirements tracking process
- Existing project, augment process: you utilize RequisitePro to build on top of the existing requirements tracking process (such as the early stages of the IPD process) and slowly merge out the old or inefficient tools and processes
There are already many articles about the benefits of utilizing RequisitePro out of the box on a new project, so this article will not discuss that process. Instead, it will focus on the other two scenarios -- and make a case for implementing change right now.
Figure 1, following, illustrates the IPD process. This article will use the IPD terminology as a basis for discussing implementing RequisitePro into your process development methodology.
Figure 1. IPD process phases
For a consistent means of talking about the product development process we will focus on three of the six phases of the IPD process: Develop Product Concept (requirements), Develop Product Definition and Plan (planning), and Develop and Verify (development):
- The requirements phase consists of analyzing the marketplace, interacting with customers, and looking for new ideas to put forward as candidates for the next iteration of a product.
- The planning phase involves determining what will be in the next iteration of the product.
- The development phase is the execution function of the Product Concept phase, including design, reviews, status tracking, and plan change management.
Starting fresh with RequisitePro In the disruptive scenario, the process team makes a decision to swap out part or all of the existing requirements tracking process. Reasons for this could be that one or more of the first three IPD phase processes is not working well. It does not necessarily mean that the entire process is broken, but that execution of one or more of the individual phases is viewed as broken. We will not go into details on why an IPD phase might be viewed as broken, but will focus on how RequisitePro could be deployed, and the potential effects of that deployment on the users of the IPD process.
Even if the existing process is either non-productive or counter-productive, replacing an existing process is still generally viewed as disruptive. Either a major process is changed, or new tools are imposed on the project managers and developers. When following the disruptive model several things need to be considered:
- Timing: If the change is introduced during the release cycle, it can be viewed as very disruptive, causing delays in the release of a new iteration of the product. To reduce the disruption, the change needs to occur at the beginning of a release cycle. Timing the deployment of a new tool on a release boundary is almost an impossible task. If not implemented correctly, the release can be delayed until the tools and processes are in place.
- Migration: Your move from the existing tools and processes, including data, and possible states. Migration not only includes the actual movement of the data, but also the verification that critical data and states are not lost. This risk can be somewhat mitigated by developing a parallel migration and development architecture, where data exists in both the old and new tools, but once again timing is critical.
- Deployment: Successfully executing the change is tied to both timing and migration. In parallel to timing and migration, you need to consider education and client rollout. In the disruptive example, users WILL be impacted, since existing tools and processes will be replaced.
As you will see in the following, you can mitigate and in some cases eliminate the three major concerns of the disruptive deployment model: timing, migration, and deployment.
Utilizing RequisitePro in a mature requirements tracking environment As Figure 2 shows, we will focus on the first three phases of the IPD process: requirements, planning, and development.
Figure 2. Using RequisitePro in the IPD process
We have a number of tools, databases, and processes for collecting requirements during the requirements phase. Our teams at IBM are familiar with -- and very good at -- using these tools. Our strategy and marketing teams put together requirements documents by analyzing our customer's demands and our competitor's products. This document format integrates well with a RequisitePro environment.
Our customer support teams work directly with customers and gather requirements through that interaction. The requirements they collect are stored in a database that is accessible to them and to the development lab. They host a meeting for a subset of our customers on a regular basis. The participants in this meeting discuss and submit product requirements to our teams through another, separate database. There are many other groups that have their own databases for submitting requirements to us as well. Converging on a single tool, database, and process would have many benefits, but it could also prove disruptive to our teams and customers. At any rate, it would be a much larger task than what this article will describe.
In the next phase, the planning team has one of the most difficult jobs. They look at all of the requirements and decide which ones the development team has the resources to complete. It is their job to decide what will (and won't) be included in the next product release. This means analyzing, prioritizing, and balancing all of the requirements they have received from all of the previously discussed sources. Since these requirements exist in different databases and formats, it can take a long time for the planning team to locate the various requirements and get an understanding of what everyone wants.
When they do finally get it all figured out, they create line items and assign these to departments. As soon as all the line items are created, of course, something changes. Then new line items need to be added to the plan, while others need to be deferred or cancelled. Eventually, the plan settles down. By then the requirements and plan have changed so frequently that it can seem as if that no one knows exactly why they are working on any of the specific line items.
Finally the development phase starts. The team creates development items for each change to the system architecture. A development item is used to keep track of design, review, status, and change management information associated with enhancing or modifying the system architecture. Development items reference the line item with which they are associated in the plan.
At this point, our development teams begin building solutions for the line items. This starts with analysis and design, in which an architect tries to understand the exact nature of the line item to determine what needs to be built. The architect can only see the information in the line item, because they are not able to look back at the original requirements. During this process, the high level description in a line item is broken down into smaller, more concrete requirements. After that the development team begins to write code to implement the required changes. From here on out, as long as the requirements and the plan don't change, our IPD cycle will run smoothly.
As the team members work through the development process, they will want to report back the status of certain requirements to our various requirement sources. Without RequisitePro, this is not a very simple process. It requires looking at all of the requirements submitted by a particular group, and then either remembering which line items they are associated with or tracking down someone who does remember. This method usually takes slightly less time than it did to put the plan together in the first place.
Utilizing RequisitePro to maximum benefit There are three benefits you will see from using RequisitePro to align the IPD process more closely with your customer's requirements. The first benefit is creating a single, centralized requirement collection point for all of your requirements. This gives your plan team a unified interface with which to analyze and compare all of the requirements (from both customers and internal sources).
Secondly, RequisitePro enables you to trace requirements to line items. This allows you to keep your plan extremely close to your customer's requirements. Of course, line items are based on requirements (you hope), but this relationship is rarely documented or stored in a consistent manner. Often this information is only recorded in the memories of the plan team. Traceability, on the other hand, provides you with an easy method to feed back information about a requirement to the customer who submitted it. Additionally, if a requirement changes the link will be marked as suspect, and you will know that you must check to see if the line item also needs to be updated.
The third benefit of using RequisitePro is that it shares more information with your development teams about the requirements that are the basis for the work they are doing. The team can gain many insights by looking back at what it was that the customer, marketing, or the strategy team originally asked for. To realize these benefits, you need to use RequisitePro both as a central repository for requirements from all of the other sources we have described, and as a middle-man between these requirements and line items. One way to accomplish this is through the RequisitePro Extensibility Interface (RPX). Through the RPX you can programmatically do almost anything that can be done with the RequisitePro client. This interface can be used to create requirements, create documents, add users, or even query requirements in a language -- called the RequisitePro Query Language (RQL) -- similar to SQL.
At IBM, we have built a script to connect to our current requirement databases and extract all the requirements in them. Next, the script iterates through those requirements and inserts them into our RequisitePro project (or updates the requirement in the project if it already exists and has changed). These scripts run daily and keep the RequisitePro database in sync with all of the other separate requirements databases. Furthermore, another script extracts line items stored in a database and inserts or updates them in RequisitePro as well. Figure 3 shows traceability between requirements and line items.
Figure 3. Traceability in RequisitePro
Storing all of this information in a central location also simplifies and enhances the planning phase. It is now much easier for your planners to get a broad view of the most up-to-date requirements from all sources. Using this information, they can better prioritize requirements from all sources, as well as look for similar requirements from multiple groups. To make this truly valuable, you will need your planners to establish traceability links from line items to requirements.
This is an extra -- but hopefully painless -- step for your planners. The relationship between requirements and line items already exists conceptually; it just isn't being consistently documented. You are simply asking them to formalize this information in a tool. The interfaces for doing this are simple and the benefits are many. These benefits are such that:
- You can quickly determine the status of a requirement because you know which line item it traces to in the plan. This allows you to provide accurate feedback to your customers on the status of the requirements they have submitted.
- You can easily identify the line items that need to be reviewed when requirements change by looking for suspect links in a traceability matrix.
- The plan team can quickly see which requirements and which requirement sources will be affected by adding, dropping, or deferring a line item.
- The development teams are able to see more information about the initial requirements that they are writing code to solve.
Conclusion This article discussed both disruptive and non-disruptive methods of deploying RequisitePro. While RequisitePro works well in both cases, it is the impact to the users that you need to consider. RequisitePro can help strengthen the IPD process. We would highly encourage teams to consider an initial roll-out of RequisitePro using the non-disruptive method. It is a great way to get many of the benefits of RequisitePro -- along with some initial user buy-in -- without significantly changing the way everyone works.
Resources - Get the evaluation version of IBM Rational RequisitePro from the Trials and betas page.
- Rational's software development process, Rational Unified Process version 2003.06.13, is also available from the Trials and betas page.
- The IBM Software Developer Platform homepage provides detailed information on the overall IBM Software Development platform, of which requirements management is a part.
- For technical resources about Rational's products, visit the developerWorks Rational content area. You'll find technical documentation, how-to articles, education, downloads, product information, and more. For specific information about RequisitePro, visit the RequisitePro technical resources page.
- Get involved in the developerWorks community by participating in developerWorks blogs.
- Ask questions about RequisitePro in the Requirements Management and RequisitePro forum.
- Purchase Rational books at discounted prices in the Rational section of the Developer Bookstore.
- Be sure to peruse the Help pages within RequisitePro. This is the documentation that ships with the product and it provides a wealth of information.
About the authors | | | Brian is a software engineer working in the Application Development Solutions team, and has expertise in RequisitePro and the RequisitePro Extensibility Interface. |
| | | Wayne is a software engineer working in the Application Development Solutions team. |
Rate this page
| |
