Requirements management: a template for success.

What do you do when you have a process identified as a government best practice by the Government Accountability Office (GAO)? Why, revamp it of course. At least in the DoD Health Affairs TRICARE Management Activity (TMA) Information Management Division (IMD) you do because even a good process can be made better. But I am getting ahead of myself.

The Information Management Challenge

Let's look at a little background information. DoD has to capture patient information for its 9 million beneficiaries. Data must be available for sharing 24/7 worldwide on a very mobile population that receives care in 75 hospitals, 461 medical clinics, 417 dental clinics, as well as forward-deployed medical units overseas. Information has to be timely and accurate for patient safety. And there are logistics data, pharmacy data, and insurance information that must be tracked--not to mention the myriad of other systems that must warehouse data, assist in decision making, provide back-office support, or help medical providers in other ways. This is a significant challenge.

To meet the challenge, IMD, using SRA International and other contractors, developed a world-class requirements management process in 2001--at least the GAO thought so and declared it a government best practice in 2003. The requirements management process is a critical part of the IT development process. The first step in the design and development of any IT system is requirements identification and definition. If you don't get off to the right start, you can build a fabulous system that no one will use because it doesn't do what is needed by the users. There is much more to a requirements management process than just identifying requirements. They must be refined, coordinated, validated, checked for feasibility, bundled, justified, funded, built to, tested to, and deployed in a usable system. The IMD process takes requirements up to and then overlaps the "build to" step. It only stops there because of the split between IM and IT in TMA.

[ILLUSTRATION OMITTED]

Under James Reardon, the chief information officer, TMA initiated a bold experiment. The IM function was split off from the IT or program office function of acquisition and development. IM was made responsible for everything up to the point where requirements are turned over to the program offices to build or buy software to meet those requirements. IM personnel also stay involved in the development, testing, and deployment, but to only a minor degree. SRA International provided many of the primary functional analysts for support. This model has proven to be successful for TMA. But an IM versus IT model is not the point of this article.

A Model for Success

An excellent example of the success of the requirements process is the Composite Health Care System II. CHCS II is a second-generation clinical system that serves as a complete electronic medical record. With CHCS II, DoD has a platform that supports worldwide access to centrally stored, computable data that extend medical providers' capacity to take better care of their patients. CHCS II is an enterprise-wide medical and dental clinical information system that provides secure online access to comprehensive health records. It also facilitates trend analysis activities and medical surveillance at the patient or population level. When CHCS II is demonstrated outside of DoD, those who see it--doctors, administrators, and others in the healthcare community--inevitably ask how they can get such a system for their own use. It is seen as far better than anything on the commercial market.

To end up with a system that is usable and will be used, end users have to be involved from the beginning. In CHCS II, it was healthcare providers who were involved. For the resource or back-office systems, it is hospital administrators. And so on and so on. The requirements are developed in integrated product teams. The IPTs consist of functional experts from the field and IMD, and SRA and other contractor support personnel, providing a mix of functional and technical experts who ensure that the requirements are right, comprehensive, meet the standards of good requirements, and can be translated into systems by developers. The IPTs identify what they feel are all of the requirements. Admittedly some of these don't make it into the final systems because of financial or technical constraints, but any requirements not included are maintained and may be developed later or added as enhancements as they become technically or fiscally feasible.

A Key Element: The Portfolio Process

One large and important subprocess of the overall requirements management process is the portfolio process created by SRA to support IMD. Various related requirements are bundled together in packages. These capabilities packages are the basis of modules for systems or, in some cases, complete systems. The packages contain a significant amount of information, much of which is also used in other documents, primarily the OMB 300. The package is updated annually and is used for, among other things, the basis for determining funding priorities. Package input comes from both IMD and the program office that will be in charge of development or the purchase of commercial-off-the shelf software to meet the identified requirements. The contents of each package can be seen in Figure 1.

Sections vary from a single name, to check boxes, to tables, to text, to referenced documents that are not normally included. The program office memorandum entries and schedule, for example, are tables; the functional requirements are bulleted text entries. A few sections, such as information assurance and architecture and data standards, are the same for all packages and reference documents available in other places. If new sections are identified, they are added as needed.

The Requirements Management Process

From a very simplistic viewpoint, requirements management is a four-step process Each step varies in the time and effort required, as well as who actually accomplishes the work.

Step 1: Identification and clarification

Submissions containing new requirements or change requests come from users, the Services, functional organizations, or internal sources.

Step 2: Feasibility assessment

Submissions are reviewed and validated by subject matter experts, a life cycle cost estimate is requested, and they are added to the portfolio.

Step 3: Capabilities approval

The requirements are prioritized and reviewed by the group that determines funding priorities and funding approval. After further review by a resources management group, high-level requirements are expanded into detailed requirements suitable for development/acquisition.

Step 4: Requirements definition, development, and testing.

Detailed requirements are then moved into the spiral development or acquisition process. Feedback is coordinated throughout the process to ensure that what's going to be provided to the user is what's really needed.

[FIGURE 2 OMITTED]

The real-life process is significantly more complex, as demonstrated by Figure 2, which shows the full process and who is responsible for each step.

This was the process deemed a government best practice by the GAO. It continues to be used because it works, but it is constantly being tweaked to improve it. The primary results of the process can be summed up as providing:

* Good, understandable requirements

* Buildable, usable systems

* Lower costs and shorter schedules to field systems

* User satisfaction

* A better military health system for the beneficiaries.

As seen in Figure 2, the process can became fairly complex and bureaucratic. IM has managed to keep it reasonably simple in practice. This article cannot present all of the detailed steps and procedures associated with the project, since each project would need to change the procedures to meet the organizational structure, culture, and needs. This is presented just to show how it is done successfully in one organization.

The Tracking Tool

Not to be confused with Windows[R], DOORS--Dynamic Object Oriented Requirements System--is a tool for tracking requirements from the initial identification through deployment. There are many other tools out there that can serve this function, but DOORS was selected because it met the needs of the IM and the military health system. Your organization may want to look at what tool is the best to meet your needs. While DOORS is not the most user-friendly system in the world, it has significant capabilities. It allows identification and tracking throughout the process and can provide an audit trail of all changes, who made them, and when they were made. It provides the capability to sort in a number of ways and print out what is needed. It can be integrated with Microsoft[R] Word or Excel to provide documents and reports. A tool is needed for tracking the requirements. Excel would probably work for a small project, but for a large and complex program with hundreds or thousands of requirements, a tool custom designed for requirements tracking is needed.

Some Lessons Learned

As I mentioned in the beginning, the process is constantly being changed--or rather, it is being tweaked to make it even better and to correct some minor problems. The following are a few of the lessons learned that might benefit another organization or program. I have omitted a number of lessons particular to the DoD healthcare environment that might not translate well to other organizations.

* The division of IM and IT makes communication critical. If information is not shared, especially the changes to requirements in the development stage, the process can fall apart. The final product might not meet the original requirements and no one knows why.

* There cannot be an "us/them" mentality. Everyone is in the process together; that goes for users, requirements people, developers, people who assign/monitor the funds, those deploying the system, and the senior decision makers.

* Priorities and status of requirements should be monitored and updated regularly.

* Costing must be done early and as accurately as possible. This can change the priority of a requirement. Cost/benefit analyses can be critical in determining which requirements are met when. In fact, moving the costing up in the process flow is one of the recent changes in progress.

[ILLUSTRATION OMITTED]

* Keep both current and historical records of all of the requirements. Many times "old" requirements resurface. If they are tracked, managers know what has been considered before.

* Give someone or some group the responsibility for reviewing requirements for overlap. If the same or very similar requirements are submitted for two systems or different modules of a system, determine if one can meet the requirement and share the data with the other.

* Use a requirements management tool, and try to set it up to give you the information that you need from the beginning. Keep it current.

* When requirements are presented for funding, they must be graded/prioritized objectively. That is sometimes extremely difficult. To accomplish this in TMA, standard briefing templates are used. Also, scoring criteria are determined in advance and shared with those responsible for briefing. Finally, the group doing the scoring is made up of representatives from all of the Services and organizations affected.

* Be willing to adjust the process as the environment changes. If some part of the process doesn't work, modify it, and keep trying until the process works for you.

A Starting Point

Requirements management is a critical part of the development process, not only for software, but for all products. The template presented here is constantly changing, being tweaked for improvement. However, since it would have to be adjusted for any project or program, it can, nonetheless, be considered a good starting point; and using it as the basis on which to mold your own is one proven way of achieving success.

FIGURE 1. Content of Capabilities Packages

* Information manager lead
* Process owner
* Program office lead
* Functional sponsor
* Project manager
* Objective (1)
* Functional requirements (prioritized)
* Preliminary data standards analysis
* Strategic alignment
* Regulatory drivers (1)
* President's management agenda (1)
* Benefits
* Business process reengineering efforts (1)
* Business value (1)
* Operational impacts
* Information assurance
* Architecture and data standards
* Specific referenced policies/guidance
* Infrastructure impacts
* Project Life Cycle
* Life cycle issues
* Projected schedule
* Fiscal year XX to YY program office memorandum budget profile
* Risk assessment (1)
* Federal enterprise architecture (1)
* Business process activities
* Operational architecture summary

(1) Denotes sections also used in the OMB 3000

Turk is a retired Air Force lieutenant colonel and a project manager with SRA International, supporting a National Guard Bureau information technology project. He has supported projects for DoD, the military services, other federal agencies, and non-profit organizations.

The author welcomes questions and comments. He can be contacted at [e-mail].