Documents generated during a requirements management project

A project may generate any number of types of documents; here we focus on the types for which RequisitePro provides document outlines.

The Vision Document provides a high-level basis for the more detailed technical requirements. It captures high-level requirements (features) as well as design constraints. The focus of the Vision Document is on user needs, goals and objectives, target markets, user environments, and product features. It serves several purposes: it helps to facilitate communication between management, marketing, and the project team; it fosters general understanding of the project; and it establishes the scope and priority of high-level features.

The Glossary Document is used to define terminology specific to the problem domain, explaining terms in the use-case descriptions or other project documents that may be unfamiliar to the reader. This document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information. It includes a section that provides a complete list of all documents referenced elsewhere in the Glossary.

The Use-Case Specification Document describes what the actor does and what the system does in response. Use cases are textual descriptions, and their main purpose is to document the behavior of a system in a clear, concise, and understandable way. The description should be phrased in the form of a dialog between the actor and the system. The use case should describe what happens inside the system, but not how or why. The document includes a basic flow and one or more alternative flows. Simple alternatives may be presented within the text of the use case.

These documents are generally produced after the project team has a clear understanding of the real problem they must address and the stakeholders who are affected by the solution they propose. They may be revised and elaborated later in the project, as additional features become necessary and new use cases are identified, but they are typically generated early in the process; they are important tools in defining the problem, listing the features to be provided by the solution, making sure that everyone concerned is using terms in the same way and has the same expectations of the system, and defining some of the behavior the system is expected to provide. Time spent in these activities improves communication between team members and increases the chances that everyone involved in the project is on the same page.

The Supplementary Requirements Specification Document captures any requirements that cannot be tied directly to any specific use case, and especially many of the nonfunctional requirements and design constraints.

The Test Plan Document identifies existing project information and the software components that should be tested, lists the recommended requirements for high-level testing, describes the testing strategies to be used, identifies the required resources, and provides an estimate of the test efforts and the deliverable elements of the test project. (If you have installed Rational TestManager, we recommend that you use it to develop your test artifacts.)

The Supplementary Requirements Specification and Test Plan documents are produced later in the process, after all required features and use cases have been identified.

Return to main tutorial