Requirements management: a template for success

Defense AT&L, March-April, 2005 by Wayne Turk

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.