The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements…Therefore the most important function that software builders do for their clients is the iterative extraction and refinement of the product requirements."
- Fred Brooks in No Silver Bullet - Essence and Accident in Software Engineering

Experienced Java developers recognize that capturing and refining the requirements is one of the most important, yet difficult, parts of building a software system. An iterative software development process that incorporates the right tools can facilitate effective requirements management.

Product Background
MKS added requirements management to their software configuration management (SCM) product offerings with the recent release of MKS Integrity Suite 2005. Although the enhancements to MKS Integrity Suite encompass more than requirements management, this review focuses on the extensions to support requirements management since these extensions are the distinguishing features of the 2005 product.

Rather than developing a requirements management tool from scratch, or acquiring an existing product, MKS incorporated new features into their change management tool, MKS Integrity Manager. These features allow MKS Integrity Manager to collect and manage requirements. In addition, MKS Integrity Manager can be used with MKS Source Integrity to link requirements with source code files that are placed under version control.

Product Architecture
MKS Integrity Suite 2005 is a J2EE application comprised of MKS Integrity Server and MKS Integrity Client.

MKS Integrity Server manages the process items and source code files that reside on the server. It runs under an application server packaged and installed with the product. It uses FLEXlm as the license manager.

MKS Integrity Client consists of three logical pieces: MKS Source Integrity Enteprise, MKS Integrity Manager, and the Administration Client. MKS Source Integrity Enterprise is the version control interface, while MKS Integrity Manager facilitates process and workflow management activities. Both MKS Source Integrity and MKS Integrity Manager share the same GUI. In a separate GUI, the Administration Client allows an administrator to perform common administrative tasks on the Integrity Server.

Installation
The MKS Integrity Suite is distributed on two CDs. Installing the software is straightforward. For this evaluation, I installed both the MKS Integrity Server and the MKS Integrity Client on a 1.2GHz Wintel Notebook computer with 512MB RAM. I installed the MKS Integrity Server using the embedded PointBase database. I configured the MKS Integrity Server to use the flat file authentication scheme.

In addition to the embedded PointBase database, MKS Integrity Server is designed to work with Oracle, MS SQL Server, and DB2 databases. MKS Integrity Server stores process item data, including requirements, in the database. When using one of the supported commercial databases, files checked in to MKS Source Integrity can also be stored in the database. During the installation of MKS Integrity Server, the administrator needs to decide where version controlled files will be stored. If the database option is not selected, files placed under version control with MKS Source Integrity are stored on a file system in Revision Control System (RCS) format.

MKS Requirements 2005
After installing the MKS Integrity Suite, I proceeded to start the requirements management component. I soon realized that the requirements management component is really MKS Integrity Manager. MKS added the following enhancements to MKS Integrity Manager so that it could be used as both a requirements management repository and engine:

• Named issue relationships that link one issue to another
• A relationship view to visualize how issues are related
• Suspect links that control changes to requirements
• Integration with Microsoft Word to capture requirements defined in a Word document
• Integration with Telelogic DOORS to capture requirements defined in a DOORS module
• A process template consisting of five requirements-related processes

The process template, also called a solution, is named MKS Requirements 2005. While the process template is not required for requirements management, MKS created this template so their customers could visualize how to use the enhancements in MKS Integrity Manager to manage requirements. Although MKS describes the process template as "an illustration of MKS Integrity Suite's requirements management capabilities," I suspect that customers will want to use the template's contents to model their requirements management process. Of course, customers can modify the process items defined by the template to address their specific needs.

Using Issues to Manage Requirements
To understand how requirements are managed by MKS Requirements 2005, you need to recognize that MKS Integrity Manager uses issues to model process items. Each issue consists of fields that store data. An issue transitions through a series of states to model a process workflow. Each issue is defined by its type. When a user creates issues from a type, the user can locate these issues with a query. A user-defined query simply selects and lists issues that meet certain criteria.

An administrator defines fields, states, and types using the Administration Client. A user then creates an issue (i.e., an instance of a type) and a query using MKS Integrity Manager. Requirements, features, and tasks are examples of issues that can be managed by MKS Integrity Manager. Prior to the release of MKS Integrity Suite 2005, users of MKS Integrity Manager created issues, such as change requests, to track software development activities like fixing a defect or adding an enhancement.

After enhancing MKS Integrity Manager to support requirements management, MKS developed the MKS Requirements 2005 process template to model requirements artifacts. The template consists of seven types (Project, Requirement, Source Document, DOORS Module, Feature, Task, and Test) that take advantage of the enhancements to MKS Integrity Manager. Keep in mind that these types are administrator defined, rather than a base feature of MKS Integrity Manager. For this reason, they can be used as is or modified through the Administration Client. Figure 1 shows how to access these types using the Administration Client.

Tracking Requirements, Analyzing the Impact of Changes, and Visualizing Project Status
The strength of MKS Requirements 2005 is the way in which it allows users to track requirements, analyze the impact of the inevitable changes to requirements, and visualize the status of a project.

When using the issues in the process template, a requirement is defined by features that are implemented as tasks and then validated through tests. Figure 2 depicts a chain of relationships from requirements to features to tasks. Although not shown in this figure, change packages link tasks to the source code files that implement them. This is the premise behind task based development. Each check-in to the version control system is associated with a fine-grained development task. One benefit of task based development is that builds of the software application can be described by the features implemented, rather than just the source files modified. This makes the construction of a software application meaningful to a broader audience. Project managers, software testers, and end users can identify the features and fixes incorporated into every build of the software application. MKS Requirements 2005 extends task based development to requirements based development because it maintains relationships from requirements to features to tasks to the versions of source code files that implement the requirements. Now every build can also be described by the requirements that it implements.