This section provides an overview of RequisitePro concepts and defines some terms that will help you get started.
Requirements
RequisitePro organizes requirements and provides traceability and change management throughout the project lifecycle. A requirement describes a condition or
capability that a system must provide. Requirements contain a name and text, and they can be qualified with attributes to provide specific details. Requirements may be created in a document or in a view. All requirements information is stored in the database.

Requirement Type
A requirement type is an outline for your requirements. Requirement types are used to classify similar requirements so they can be efficiently managed. When you define a requirement type, you define a common set of attributes, display style, and tag numbering. You can create requirement types that are appropriate for your project.

Requirement Attributes
In RequisitePro, requirements are classified by their type and their attributes. An attribute provides information to manage a requirement. Attributes can provide crucial information to help a team plan, communicate, and monitor project activities from the analysis and design phases through the release phase.

Attribute information may include the following:
 The relative benefit of the requirement
 The cost of implementing the requirement
 The priority of the requirement
 The difficulty or risk associated with the requirement
 The relationship of the requirement to another requirement
RequisitePro provides several default requirement attributes, such as Priority (high,medium, low), Status (proposed, approved, incorporated, validated), Cost, and Difficulty. These attributes are suggestions. You can create and control attributes according to your needs. Whichever attributes you use, RequisitePro allows you to easily customize your project documents and databases to define, articulate, and manage the processes of your organization.
You can use attributes to determine which requirements to implement in the next release. For example, you may decide that in the first release, you will implement only those requirements evaluated as high risk, with high difficulty. If you have assigned risk and difficulty attribute values to each requirement, you can then easily query all requirements of high risk and high difficulty.

Project
A RequisitePro project includes a requirements database and its related documents. A project is usually created by a project administrator, who determines the project structure and sets up security permissions for the project’s users. Although all project users are encouraged to view and query requirements and to participate in discussions, only a limited group of users create and manage requirements within a project.

Project Database
The project database is the requirements database managed by RequisitePro. When you use RequisitePro, you can use one of three physical databases to store
requirements: Microsoft Access, Oracle, or Microsoft SQL Server. Each RequisitePro project has its own database, where all the requirements for a project are stored. (With the exception of Microsoft Access, all of these databases may contain more than one project.)
The use of client/server databases offers significantly increased scalability and power to your organization’s implementation of RequisitePro. Oracle and SQL Server databases are designed for scalable, enterprise-wide use.
In the project database, requirements can be added, modified, or deleted. When requirements are changed in a document, the changes are updated in the database. Often a project includes a variety of requirements documents, such as a product requirements document, a system requirements document, software and hardware specifications, user requirements, quality assurance procedures, and test plans. Information from all project documents is stored in the project database. The database centralizes information, so that members of the project team can update requirements, manage priorities and test plans, and report the project’s progress in one shared repository.

Project Version Control
RequisitePro’s version control lets you trace change by archiving projects. You can manage multiple versions of your projects, retrieving, modifying, and returning revisions to the archive in an organized and consistent manner. From RequisitePro, you can use RequisitePro’s Archive command or Rational ClearCase. If your team is using Unified Change Management (UCM), RequisitePro project administrators can create baselines of RequisitePro projects by performing tasks in Rational Administrator and ClearCase, implementing the UCM model. If you have a baseline of a RequisitePro project, you can use that baseline to create new projects in RequisitePro.

Project List
A RequisitePro project list is a personal library of accessible RequisitePro projects. Each user’s list is unique. For example, a project administrator who monitors the progress of all the projects scheduled for completion this quarter could have an extensive list of projects, whereas some users might have just one project in their lists at a time.
 Project administrators store new projects in their file systems—typically in the RequisitePro Project directory. In the Open Project dialog box, you can add or delete projects from your project list as you need them.


Explorer
The Explorer is RequisitePro’s primary navigation window. In this window, project artifacts (documents, requirements, views, and packages) are displayed hierarchically in a tree browser. Project information is organized in packages, which are units of related artifacts. The project’s root package is displayed as the project node, and the contents of each root package are displayed beneath it. Packages can be customized; you can create them as needed, rename and rearrange them, and delete them when you no longer need them. When you select an artifact, a description of it appears in the window below the Explorer.
You can use the Explorer to view your project structure and artifacts and to work with project information. For example, you can double-click a view or a document to open it; you can select requirements and edit them; and you can drag and drop artifacts between packages. The Explorer reflects saved changes made to an open document, view, or requirement.

Views
RequisitePro views are windows to the database. Views present information about a project, a document, and requirements graphically in a table (matrix) or in an outline tree. Requirements, their attributes, and their relationships to each other are displayed and managed in views. RequisitePro includes query functions for filtering and sorting the requirements and their attributes in views.
Three kinds of views can be created:
 The Attribute Matrix displays all requirements of a specified type. The requirements are listed in the rows, and their attributes appear in the columns.
The Traceability Matrix displays the relationships (traceability) between two types of requirements.
 The Traceability Tree displays the chain of traceability to or from requirements of a
specified type.

Three views of requirements. Top to bottom: Attribute Matrix, Traceability Matrix, Traceability Tree.

Documents
A document created in RequisitePro look like a Word document, but a few changes have been introduced that allow RequisitePro to exercise security controls over the document. For example, the File > Save as and File > Exit commands are disabled in the RequisitePro Word window in order to prevent conflicts in handling RequisitePro documents. (To close the Word document, click Window > Close Word.) The Tools > Templates and Add-in command is unavailable so as to prevent deletion of the RequisitePro template, which is required for proper functioning of RequisitePro.

A requirements document is a specification that captures requirements, describes the objectives and goals of the project, and communicates product development efforts. Each requirements document belongs to a particular document type, explained below. RequisitePro manages requirements directly in the project documents. When you build a requirements document, RequisitePro dynamically links it to a database, which allows rapid updating of information between documents and views. When you save revisions, they are available to team members and others involved with the project.
With RequisitePro’s version tracking, you can easily review the change history for a requirement, a document, or the whole project.
Not all documents are requirements documents. Documents do not have to contain requirements to be included in a project. Any Word document, no matter where it resides in the file system, can be associated with a project and is available in the document list when a project is opened.

Document Type
A document type identifies the type of document, such as a use-case or a software requirements specification, and helps ensure consistency across documents of the same type. A document type is an outline that is applied to documents. The outline can include the default font for the document, the available heading and paragraph styles, and the default type of requirements for the document, or it can encompass both formatting conventions and an outline that helps you organize your requirements information. All documents of the same document type share the same file extension (for example, .prd). You determine document types when you create or modify your project. Then, when you create a document, you can associate it with a document type already defined in your project. The new document inherits the style and functional attributes associated with the document type, making it consistent with other documents of the
same type. RequisitePro provides standard document outlines that can be used “as is” or customized according to your specifications. After you have defined the appearance of the document and the information to include, you can use the document as a standard for your organization.

There are several benefits to using standards:
 The outline can be used as an example of the type of information to include and can serve as a comprehensive “to do” list so no information is overlooked.
 Expectations and procedures are clearly presented so new authors and team members spend less time learning to build the necessary requirements documents.
 Authors familiar with the outline can create new documents quickly.
 Readers familiar with the outline can quickly locate and review information.

Hierarchical Relationships
Hierarchical requirement relationships are one-to-one or one-to-many, parent-child relationships between requirements of the same type. Use hierarchical relationships to subdivide a general requirement into more explicit requirements.
Example:
Parent requirement:
The system shall display customer information.
Child requirements provided for detail:
Name
Address
Date of Birth
When working with hierarchical relationships, keep the following in mind:
 Each child requirement can only have one parent, but a requirement can be both a parent and a child.
 The parent and child requirements must be located in the same place. If a parent requirement appears in a document, the child requirement must also appear in that document. (Note that all requirements are stored in the database.)
 You can create hierarchical relationships in a document or in a view by using the Hierarchy tab in the Requirement Properties dialog box. (You can also use
Requirement menu commands to create hierarchical relationships in a view.)
 When you delete a parent requirement, you can choose to delete its children or assign them to another parent.
 You cannot create a traceability relationship between a parent and its own child.

Hierarchical relationships are a type of change-managed relationship in RequisitePro. If a requirement is changed, the relationships with its children
become suspect. You can view and manage suspect relationships using one of two views: a Traceability Matrix or a Traceability Tree.


Traceability Relationships
Traceability links requirements to related requirements of same or different types. RequisitePro’s traceability feature makes it easy to track changes to a requirement throughout the development cycle. Without traceability, each change would require a review of your documents to determine which, if any, elements need updating. When working with traceability relationships, keep the following in mind:

 You can create a traceability relationship between requirements of the same or different types.
 You can create traceability relationships between requirements that exist in the same document, in different documents, or in the project database.
 You can create, view, and manipulate traceability relationships in a document or in a view.
 Traceability relationships are a type of change-managed relationship in RequisitePro. If either end-point of the connection is changed, the relationship
becomes suspect. If you modify the text or selected attributes of a requirement that is traced to or traced from another requirement, RequisitePro marks as suspect the relationship between the two requirements.
 Traceability relationships cannot have circular references. For instance, a traceability relationship cannot exist between a requirement and itself, nor can a relationship indirectly lead back to a previously traced from node. RequisitePro runs a check for circular references each time you establish a traceability relationship.
Note: You cannot create a traceability relationship between a parent and its own child, but you can create a traceability relationship between a parent requirement and a different parent requirement’s child.


Traced to and Traced from Relationships
The trace to or trace from state represents a bidirectional dependency relationship between two requirements. It is displayed in a Traceability Matrix or Traceability Tree when you create a relationship between two requirements.
For example, you might create a feature requirement (Requirement A) that calls for a new command to be added to a particular menu in your application. In addition, in another requirements document, you might create a use-case requirement (Requirement B) associated with that menu item. You would thus create a traceability relationship in which the use-case requirement (B) is traced from the feature requirement (A).
There can be only one traceability relationship between any two requirements. The difference between a trace to and a trace from relationship is perspective. In the example above, both of the following statements are true:
 A is traced to B
 B is traced from A

Direct and Indirect Traceability Relationships
Traceability relationships may be either direct or indirect.
In a direct traceability relationship, a requirement is physically traced to or from another requirement; in an indirect traceability relationship, a requirement traces to or from an intermediate requirement, which in turn traces to or from a third requirement. For example, if Requirement A is traced to Requirement B, and Requirement B is traced to Requirement C, then the relationships between Requirements A and B and between Requirements B and C are direct relationships. The relationship between Requirements A and C is indirect. Indirect relationships are maintained by RequisitePro; you cannot modify them directly. Direct and indirect traceability relationships are depicted with arrows in traceability views. Direct relationships are presented as solid arrows, and indirect relationships are dotted and lighter in color.

Suspect Relationships
A hierarchical relationship or a traceability relationship between requirements becomes suspect if RequisitePro detects that a requirement has been modified. If a requirement is modified, its relationships with its immediate children and all direct relationships traced to and from it are suspect.

When you make a change to a requirement, the suspect state is displayed in a Traceability Matrix or a Traceability Tree. Changes include modifications to the requirement name, requirement text, requirement type, or attributes.

Back to Main topics