Rational RequisitePro

TM

Tutorial
Table Of Contents
1. Introduction to RequisitePro.........................................................................................................3
1.1 Working in RequisitePro.........................................................................................................3
1.2 Working with requirements documents...................................................................................5
1.3 Organizing and tracking requirements....................................................................................6
Attribute Matrix............................................................................................................................6
Traceability Matrix........................................................................................................................7
Traceability Tree...........................................................................................................................8
1.4 Creating a RequisitePro project..............................................................................................9
1.5 Working with project templates............................................................................................10
Review.........................................................................................................................................11
2. Documenting Requirements........................................................................................................12
2.1 A Requirements Management Workflow..............................................................................12
Defining the problem and understanding stakeholder needs......................................................13
Defining the system ...................................................................................................................14
2.2 Document Types....................................................................................................................14
Working with document types....................................................................................................14
Documents generated during a requirements management project............................................15
2.3 Creating documents...............................................................................................................16
Exercise: Create a use-case document........................................................................................16
2.4 Working with requirements...................................................................................................18
Exercise: Create multiple requirements......................................................................................21
Review........................................................................................................................................24
3. Organizing Requirements............................................................................................................24
3.1 Working with requirement types...........................................................................................25
Exercises: Create requirements in a view...................................................................................25
3.3 Using attributes to organize requirement information..........................................................27
Exercise: Set attribute values in a view......................................................................................28
Review........................................................................................................................................28
4. Tracking Requirements...............................................................................................................29
4.1 Managing changing requirements.........................................................................................29
4.2 Setting traceability................................................................................................................29
4.3 Managing change through traceability views.......................................................................30
Exercise: Create and clear traceability relationships from a matrix view...................................30
Exercise: Create traceability relationships from the Word document ........................................31
4.4 Using suspect links................................................................................................................32
Exercise: Create a suspect relationship.......................................................................................33
Exercise: Create suspect relationships in an Attribute Matrix view...........................................34
4.5 Establishing hierarchy...........................................................................................................35
Exercise: Create hierarchical requirements in a document.........................................................36
Exercise: Change the parent of a child requirement...................................................................37
4.6 Querying (Filtering and Sorting)...........................................................................................38
Exercise: Create a query in an Attribute Matrix.........................................................................38
Review........................................................................................................................................39
5. Advanced Features......................................................................................................................39
 Archiving....................................................................................................................................40
Creating baselines.......................................................................................................................40
Cross-project traceability............................................................................................................40
Customizing document and requirement types and attributes....................................................40
Discussion groups ......................................................................................................................42
Integrations..................................................................................................................................42
Offline authoring.........................................................................................................................42
Requirement Metrics...................................................................................................................42

1. Introduction to RequisitePro
RequisitePro is a powerful, easy-to-use requirements management tool that helps teams manage project
requirements comprehensively, promotes communication and collaboration among team members, and
reduces project risk.

Requirements management is essential for improving your software development process. The better the
communication and management of your requirements, the more likely you are to identify the correct
problem and deliver the right solution, and to do that on time and within budget. RequisitePro helps
facilitate that process.

RequisitePro offers the power of a database and Microsoft Word. Its robust architecture maintains live
requirements documents that are dynamically linked to a database for powerful sort and query capabilities.
This allows you to easily organize and prioritize your requirements, to trace relationships between them,
and track changes that affect them. Robust traceability features visually indicate how changes affect the
project, thereby giving you the ability to perform real-time impact analysis and allowing you to make
informed decisions for scope management or resource allocation. As a result, you are better able to
manage requirement change, and your project is less likely to spiral off course. RequisitePro captures the
change history for each requirement, thereby providing a paper audit of the evolution of project
requirements.

RequisitePro is integrated with other Rational Suite products. All of the products in the Rational Suite
family are team-unifying tools and include additional role-specific tools to optimize each suite for the
individual practitioner.

1.1 Working in RequisitePro

Now let's look at some of the components a bit more closely.
Toolbar buttons. The toolbar buttons are shortcuts to frequently used menu commands. When you
position your cursor over a button, a ToolTip appears, describing the button's function.

RequisitePro Shell

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. When you
select an artifact, a description of it appears in the window below the Explorer.
You can use the Explorer to access, view, and edit your project artifacts. For example, you can double-
click or right-click a view or document name in the Explorer 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.

Packages. Project information is organized in packages that contain related requirements information.
Within each package, artifacts are organized in the following order: documents (alphabetically by name),
views (by type and then alphabetically within the type), and requirements (by type and then by tag). You
can customize your packages so that they facilitate work on your project.

Views and documents are covered in separate sections.

1.2 Working with requirements documents

RequisitePro uses Microsoft Word for creating requirements documents.

A RequisitePro toolbar appears when you open Word in RequisitePro, allowing you to manage
requirements documents. You can click the RequisitePro menu to open a document, create or modify
requirements, or open a view.

RequisitePro uses most of the commands that are available in Microsoft Word. However, certain
commands do not appear; this change enhances RequisitePro's ability to control requirements documents.

You will have an opportunity to create requirements documents in Module 2.

RequisitePro Menu
1.3 Organizing and tracking requirements
RequisitePro views present requirements that are stored in the project database. Requirements, their
attributes, and their relationships with other requirements can be displayed and managed in views.
RequisitePro includes query functions for filtering and sorting the requirements and their attributes in
views. All view commands are located in the menu bar. Toolbar buttons are available for quick access to
commands.

A view presents information about requirements in a table (matrix) or in an outline tree. You can create a
view to display requirement attributes, such as status and priority, or to show the relationships between
requirements.

You can create three different kinds of views:

The Attribute Matrix view displays all requirements of a specified type. The requirements are listed in
rows, and their attributes appear in columns. This view helps you organize and prioritize requirements; for
example, you can sort the requirements on the basis of priority or risk.

Attribute Matrix
Traceability views help you manage the ripple effects caused by a requirement change. The Traceability
Matrix view displays the relationships between two types of requirements or requirements of the same
type. The Traceability Tree view displays the chain of traceability to or from requirements of a specified
type.

Traceability Matrix
Traceability Tree
1.4 Creating a RequisitePro project

In RequisitePro, a project includes a database; it can also include documents. Included in the database
are document types, requirement types and descriptors (attributes), discussions, and information about
requirement traceability and user and group security. The project and document templates you use to
create a project include the following structural information:

• Document types, such as glossary document, vision statement, and use cases (which outline
how the system behaves).

• Requirement types, which are categories of requirements such as features, use cases,
supplementary specifications, and so on.

• Requirement attributes, which describe the requirements in terms of priority, status, stability, and
other characteristics that you define.

RequisitePro provides project and document templates to help you get started.
1.5 Working with project templates
You can create a new project from an existing project structure; when you do that, the new project will
have the same document types, requirement types, attributes, and security settings as the existing project.
RequisitePro provides the following project templates:

• Use-Case Template (using a use-case methodology)

• Traditional Template (using standard software requirements)

• Composite Template (a combination of the Use Case and Traditional templates)

You can also make a new template or create a project from a blank template.

Project structure can be viewed and modified through the Project Properties dialog box. You can add and
modify document types, requirement types, and requirement attributes, and you can view general
information about the project, its documents, and its revision history. Project artifacts (such as documents
and views) are arranged in packages, which can be renamed and rearranged.

Following is the Project Properties dialog box (General tab):

Exercise: Create a new project

1. Open Rational RequisitePro.

2. Close the splash screen. In the Create Project dialog box, click the New tab.

3. Click the Use-Case Template icon. Click the Details check box; note that a description of the
template you select appears in the text box at the bottom of the dialog box.
 4. Click OK. The Rational RequisitePro Project Properties dialog box opens.

5. In the Name box, type My Exercise Project. Filling in the Description box is optional.

6. Click OK. A dialog box opens, and you are asked whether you want to create the project directory.

7. Click Yes. The Create Rational RequisitePro Project dialog box appears and informs you that
your project has been created.

8. Click Close.

Click File > Open Project, Existing tab. The projects are listed in order of recent use, so the project you
just created appears at the top of the list.

Now look at your project directory in the Explorer. It shows the project you created and several packages.
The packages contain document outlines and saved views. You can modify and customize these project
artifacts as your project evolves.

Review

The RequisitePro workplace includes a toolbar and the Explorer tree browser and package list, in which
you can see the structure of your project. Project information in the database is available to you through
requirements documents and views. Three types of views enable you to view your requirements, set
attributes (such as priority), and establish relationships between them. RequisitePro provides templates
that you can use to create projects.
2. Documenting Requirements
Topics covered in this module:

• Working with document types

• Creating documents
• Working with requirements

Objective: To demonstrate how to use RequisitePro outlines to create requirements documents and to
create requirements in those documents.

This module shows you how to use RequisitePro to document your requirements. Before you do that,
however, you typically will have spent some time and energy in defining the problem you expect your
project to solve, determining its causes, and identifying the features of a solution. These activities involve
getting input from a variety of stakeholders (people who are affected by or have an interest in the project).
You can do that by running workshops, conducting interviews, distributing questionnaires, and prototyping.

Using these techniques, you should be able to determine the project requirements as well as the attributes
of those requirements, such as importance to customer, difficulty, risk, and stability.

By the time you are ready to document your requirements, you should have a statement that (a) identifies
the problem and who is affected by it, (b) defines the impact of it, and (c) explains what would constitute a
solution.

2.1 A Requirements Management Workflow

The following diagram illustrates the requirements management workflow advocated by the Rational
Unified Process. As the diagram shows, the process is iterative and dynamic, and change management
takes place throughout the process. Phases of the process are associated with specific documents in
which team members capture the project requirements. These phases and documents will be referred to
often throughout this tutorial.
(Courtesy of Rational Unified Process, 2001)

Defining the problem and understanding stakeholder needs

Determining the real problem is an important first step toward designing a successful project. We define
the word problem as the gap between our perception of what customers say they want and what they
actually want. Determining the real problem may be trickier than it appears; what people state as a
problem may not be the actual problem. To address this, you solicit the customer's definition of the
problem and then continue to probe until you get to the problem behind the problem. When the root
causes of the problem have been identified, you can focus on the ones that contribute most to the
problem.

Effective solutions to complex problems require input from a diverse group of stakeholders (people who
are materially affected by the implementation of a solution to the problem). People who use the system
(staff and customers) are good sources of information on its shortcomings; others whose opinions must be
solicited include those who must approve the new system and those who will maintain it. These individuals
will also be able to provide important information regarding the requirements that must be provided by a
solution.
Example: A mail-order catalog company that manufactures and sells miscellaneous home items
discovered that it had not made any profit for two quarters. Company executives and key staff members
tried to determine the causes for this lack of profit; they focused on the cost of all the things that go wrong
and produce waste, scrap, and other excess costs. This cost included rework, scrap, customer
dissatisfaction, and employee turnover. When they tried to quantify the cost of nonquality, they concluded
that production waste, or scrap, was the largest contributor.

The next step was to find the root cause, or the problem behind the problem in scrap. What factors
contribute to the problem? Company staff were able to identify many contributors: customer returns,
damaged shipments, inaccurate sales orders, and manufacturing defects. Then they tried to determine the
contribution of each of these factors to the overall problem. Their records helped them determine that the
single greatest contributor to the problem of scrap was produced by customer returns related to inaccurate
sales orders; additional relevant information was obtained from sales order entry clerks, sales order
supervisors, and billing clerks, to name just a few. Company managers concluded that by addressing this
problem, they would substantially reduce waste; they defined a successful outcome as one that would
increase accuracy of sales orders at point of entry and improve reporting of sales data to management.

Defining the system

When you define the system, you translate and organize your understanding of stakeholder needs into a
description of the system to be built. Documents that define the product to be built and describe the
system's external behavior are called requirement specifications. They include Use-Case Documents,
which are designed to identify the functional behavior of the system, and Supplementary Requirements
Specification Documents, which define features of the system in specific terms.

2.2 Document Types

RequisitePro provides templates to help get you started. Module 1 described the project templates
provided with RequisitePro; this module introduces you to document types.

Working with document types

A document type is a document structure; it includes fonts, formatting, page layout information, and other
features associated with documents. You can use the document types provided with RequisitePro to
organize your requirements.

Document types are based on document outlines. Many Rational Unified Process and RequisitePro
outlines are available on which you can base the document types you need for your projects. The following
document types are commonly used in requirements management projects:

• Vision. This document gives the overall view of the system: main characteristics, major features,
key stakeholder needs, and key services provided.

• Glossary. It is important that all stakeholders use consistent terms to express requirements. The
Glossary is a tool to capture and define the terms used in the project.

• Requirements Management Plan. This document sets out guidelines for establishing the
requirements documents, types, attributes, and traceability in order to manage the project
requirements.

• Use-Case Specification. Use cases serve as a format to express functional requirements in

sequence. A use case is a sequence of actions performed by a system that yields an observable
 result (a work output) of value to a particular actor. Use cases are especially good at documenting
functional software requirements.

• Supplementary Requirement Specification. This document captures any requirements that

cannot be tied directly to any specific use case, and especially many of the nonfunctional
requirements and design constraints.

• Test Plan. This document describes the target-of-test (components, application, system) and its
goals; the stages of testing; and the types of testing that will be addressed by this plan. If you have
installed Rational TestManager, we recommend that you use it to develop your test artifacts.

By default, document outlines are available at <install drive>\Program Files\Rational\RequisitePro\outlines.

In RequisitePro, you can view the list of document types associated with the project template. You do that
by selecting the project in the Explorer, clicking File > Properties, and then clicking the Document Types
tab. Click the button to see a screen capture of that dialog box.

Some of these documents (such as the Vision and Glossary documents) are generated early in the course
of a project; others, such as supplementary specifications, are generally written after the use cases have
been developed and team members have a sense of the product functionality (the solution to the
problem).

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.

2.3 Creating documents

When you create a document, RequisitePro adds the new document to the package you selected when
you opened the Document Properties dialog box.

You select a document type, and the outline prompts you to supply information that is relevant to the type
of document you are creating. For example, the Vision Document outline will prompt you to list features
that your project should include, and the Use-Case Document outline prompts you to describe how the
system will behave. The use cases should relate to features in the Vision Document.

Exercise: Create a use-case document

In this exercise, you work in the project you created in Module 1 and create a Use-Case Document using
an existing RequisitePro outline.
A Use-Case Document helps you document functional requirements from the perspective of the user. A
use case is a sequence of actions a system performs that yields an observable result of value to a
particular actor.

1. In the Explorer, select the Use Cases package and click File > New > Document. The Document
Properties dialog box opens.

2. In the Name box, type Arrange My Shipment; in the Description box, type Basic flow for
shipment use case; and select Use Case Specification as the document type. Then click OK.

3. In the new document, delete the blue text that appears under the heading 2.1 Basic Flow and
press the Enter key.

4. Select the following text:

Upon successful completion of the Checkout use case, complete member order information will be
sent to the warehouse system.
The Web shopping application sends member information in the form of a report that can be
parsed electronically by the warehouse system. The report includes specific information.
Club member name.
Club member shipping address.
Club member phone number.
Club member ID.

5. On the browser, click Edit > Copy. In the document, click the line below 2.1 Basic Flow, and then
click Edit > Paste Special. Select the Unformatted text option and click OK.
On the Word menu bar, click RequisitePro > Document > Save, and then minimize the document.

2.4 Working with requirements

A requirement is a capability that the system must provide. It is derived directly from user needs or stated
in a contract, standard, specification, or other formally imposed document.

The bracketed text that follows is an example of what a RequisitePro requirement in a document looks
like; it appears in a document in the Learning Project - Use Cases, which you will be working with in
Module 4:

The requirement consists of the following parts:

 • Name. A requirement name is a user-defined title. It may be the same as the requirement text;
often it is a shortened form of the requirement text. The name may or may not be visible in the
requirements document; however, you can view and edit it in the Requirement Properties dialog
box on the General tab.

• Requirement text. Requirement text is the full textual content of a requirement. In the example
above, the requirement text is the double-underlined sentence.

• Requirement tag. The requirement tag is the requirement's unique identifier. It consists of a
prefix, which indicates the requirement type, and a number, which is generated by RequisitePro
and which is unique within the requirement type. In the example above, UC stands for use-case
requirement; the requirement tag is UC2.7.

• Requirement attributes. Each requirement is associated with attributes or descriptors that have
been established for that requirement type. You can view a requirement's attributes in the
Requirement Properties dialog box on the Attributes tab.

You determine the color and style in which you want the requirement to be presented (double underlined
or small caps). The requirement text appears in documents within square brackets (bookmarks).

All requirements are stored in the database. You can create requirements in a document, in a view, or in
the Explorer. When you create a requirement, you specify the requirement type and attributes. In the
Requirement Properties dialog box, click the General tab to select the requirement type and to type the
requirement name and text, and then click the Attributes tab to specify the attributes you want to
associate with that requirement. View these tabs by clicking the buttons below.

General Tab

Attributes Tab
Exercise: Create requirements in a document

All requirements are stored in the project database. You can create requirements in a document or directly
in the database.

In this exercise, you create use-case requirements in the use-case document you just created.

1. In the document Arrange My Shipment, select the first sentence you pasted into Section 2.1.

2. Click RequisitePro > Requirement > New.

The Requirement Properties dialog box opens.

3. In the Type list, you can select the requirement type to apply to the requirements. For this
exercise, select UC: Use Case. In the Name box, type Order information sent to warehouse.

4. Click OK.

Notice that the requirement you created is preceded by a [UC pending1] label. The prefix UC indicates that
the text is a use-case requirement; "Pending" indicates that the requirement has not been saved to the
database. (The new requirements are not committed to the database until the document is saved.)
Click RequisitePro > Document > Save; notice that the pending label has disappeared. Click
RequisitePro > Document > Close.

Exercise: Create multiple requirements

In the next exercise, you create multiple feature requirements in your Vision Document.

1. In the Explorer, click the Features and Vision package to show its contents. Then double-click the
Vision Document to open it.

2. Delete the blue text in Section 5 and the bracketed <aFeature> text in 5.1.

3. Select the following text:

ClassicsCD.com Web Shop

 Secure payment method.
Easy browsing for available titles.
Ability to check the status of an order.
Customer shall receive e-mail notification.
The catalog shall be highly scaleable to include many titles and effective searching through those
titles.
Customer shall be able to customize the Web site.
Customer shall be able to register as a user for future purchases without needing to re-enter
personal information.

4. On the browser, click Edit > Copy. In the Vision Document, place the cursor where
<anotherFeature> had been, and click Edit > Paste Special. Select the Unformatted text option
and click OK.

5. Select part of the text block that you just pasted (beginning with Customer shall receive and
ending with re-enter personal information).

6. Click RequisitePro > Requirement > New Wizard. The New Requirements Wizard dialog box
opens.

7. In the Requirement Type box, select Feature; you will differentiate requirements by using a
keyword, and the selection range is the sentence. In the Keyword box, type shall and click the
Add button.

8. Click Create.
The Requirement Found dialog box opens; it shows the status of the requirements as they are
created and prompts you to accept the requirement. You have the option of clicking Yes to accept
each requirement individually or Yes to All to accept all requirements without review; for this
exercise, click Yes to All.

9. Click Close.

This is what your text should look like. The [pending] label will disappear after you save the document.
Click RequisitePro > Document > Save to commit the changes. RequisitePro saves the document,
updates the database, and assigns a definitive requirement tag to the requirement (in place of the Pending
tag). In the Explorer, double-click the All Features icon (beneath the Features and Vision package) to open
it. Your project structure in the Explorer should look as follows.
Click RequisitePro > Document > Save and then RequisitePro > Document > Close.

Review

This module described some of the document types provided by RequisitePro; these document types help
you organize the information you work with in your project. You created two types of documents that you
are likely to use in any requirements project: a Vision Document, in which you listed feature requirements,
and a Use-Case Document, in which you described how the system should behave. You examined the
components of a requirement, and you learned how to create requirements individually or as a group.

3. Organizing Requirements
Topics covered in this module:

• Working with requirement types

• Managing requirements in views
• Using attributes to organize requirement information

Objective: To demonstrate how to create requirements directly in a view, set attribute values, and navigate
between the view and the document in which a requirement was created.
3.1 Working with requirement types
RequisitePro lets you organize requirements by type. A requirement type defines descriptive and
operational information associated with a requirement. Examples of types of requirements include feature
requirements, use-case requirements, and supplemental specification requirements. You can create
requirement types; for example, you might group all marketing requirements into one requirement type.
You can modify requirement types and delete them when you no longer need them.

Requirement types are useful for classifying or grouping similar requirements in a project. By grouping
them, you can manage them more effectively.

3.2 Managing requirements in views

You can create, organize, and track requirements in three kinds of views: an Attribute Matrix, a Traceability
Matrix, and a Traceability Tree. (Traceability views will be examined in Module 4.)

In an Attribute Matrix, you get a spreadsheet-like view in which requirements are displayed in rows and
their attributes are displayed in columns. Some of the attributes included in an Attribute Matrix include
Priority, Status, and Location. At a glance, you can view all requirements of a specific type and their
attribute values.

You can work with the database without opening Word or any requirements document. The Attribute Matrix
will show all of the requirements of a single requirement type no matter where they are located. You can
edit requirements and their attributes directly in the Attribute Matrix. If a requirement was created in a
document and you edit it in the database, your edit will be reflected in the document.

Exercises: Create requirements in a view

1. In the Open Project dialog box, select My Exercise Project and click OK.
 2. In the Explorer, expand the Features and Vision package and double-click All Features. The All
Features Attribute Matrix appears. Explore the menus associated with this type of view

3. The last entry in the Requirements column is entitled <Click here to create a requirement>.
Click once to activate the row, and click again to allow editing.

4. Type the following new requirement in the Name box: Item shall be shipped immediately. In the
Text box, type the following: Ship purchased item within 48 hours of receipt of order in
warehouse.

5. Click any other cell in the view, and your requirement is immediately saved and committed to the
database.

The requirement has been automatically added to the database because you are working directly in a view
rather than in a Word document. Check the attributes. Note the system-defined Location attribute tells
where that feature requirement is physically located (in this case, the "Database").

Exercise: Edit a requirement outside of a document

 1. Click Tools > Options.
The Options dialog box opens.

2. In the Views section of the dialog box, make sure the check box Double-click to go to source is
selected.

3. Click OK.

4. In the All Features Attribute Matrix that you opened in the preceding exercise, click FEAT1:
Customer shall receive e-mail notification.
(Note: This requirement was created in the Vision Document, as indicated in the Location column
of the Attribute Matrix.)

5. Edit this requirement by adding "when purchased items are shipped" after the word
"notification." Then click any other cell in the matrix to save the edits.

6. Double-click the requirement you edited.

The document in which the requirement was created is opened, and your edit is reflected in it.

7. From the Word menu bar, click RequisitePro > Document > Close.
The Document Changed dialog box opens, and you are asked whether you want to save the
modified document before closing it.

8. Click Yes.

3.3 Using attributes to organize requirement information

RequisitePro lets you qualify requirements using attributes. Attributes are data fields associated with each
requirement that contain important project information. Each new RequisitePro requirement type is
assigned default attributes by the system. You can delete, modify, or add an unlimited number of other
attributes appropriate to your project. Examples of requirement attributes include status, priority, risk,
difficulty, cost to implement, and completion date.

Attributes can be either list-type or entry-type. You can add, edit, or remove requirement attributes at any
time during your project. The following data types are supported:

• List (single value): A set of values from which a single value can be selected (up to 20 characters);
for example, high, medium, or low.

• List (multiple value): A set of values from which more than one value can be selected (up to 20
characters); for example, Sue, Bob, John.

• Text: a text string up to 255 characters; for example, John Smith.

• Integer: whole numbers; for example, 5 or 1500.

• Real: real numbers; for example, 1.347 or 6.5.

• Date: a date in the format defined by the user's Windows setting; for example, mm/dd/yy.

• Time: a time in the format defined by the user's Windows setting; for example, 10:00 A.M.
Attributes allow you to objectify the decision-making process. The values you assign to each attribute help
to organize, analyze, and prioritize the requirements in your project.

When the time comes to determine which requirements are to be implemented in the next release, you
can create rules to help you decide which requirements to implement and which to postpone for a future
release. For example, you may decide that in the first release, you will implement only those requirements
evaluated as being high risk and high difficulty. If you have assigned risk and difficulty attribute values to
each requirement, you can then easily sort all requirements by these attribute values.

One way to organize requirements is by priority. You might decide to assign high priority to certain
requirements that are important to the customer. You can then sort through your requirements and address
those with high priority early in your project.

Consider these factors when you set priorities for requirements:

• To what extent does the requirement add to the product functionality, usability, reliability, and
performance?

• Can the requirement be met within your schedule constraints?

• Is the requirement feasible given the risks associated with it?

• If the requirement is implemented, how will it affect your ability to maintain the product?

You should also examine your schedule. Do you have time to complete all of your high priorities? Setting
realistic expectations at this stage will help your team stay on schedule and close to budget.

Exercise: Set attribute values in a view

1. In the Features and Vision package, select the All Features view. Then double-click the
intersection of the FEAT4 requirement and the attribute column Status.
2. In the list, click Approved, and then set the value by clicking another requirement or attribute cell.
[Note: You can also change multiple attribute values simultaneously using Microsoft's Extended
Select (Shift > click or Ctrl > click). Go to the Difficulty column and select all cells labeled
Medium; then right click, and click again on Set Value. A dialog box appears; click on the arrow,
select High, and click OK. The Priority values in all selected cells now appear as High.]

3. Click File > Save View, and then close the view by clicking the lower X in the upper right corner.

You can close My Exercise Project. (Click File > Close Project, and click Yes in response to the dialog
box that opens.) Then click the minimize button on the upper right corner of the view window. The
exercises in Module 4 will involve the Learning Project - Use Cases, which is provided in the RequisitePro
samples directory.

Review

You can use requirement types and attributes to organize your project information. Using requirement
attributes and sorting features can help you make important decisions about implementation that may help
improve your chances of successfully completing your project; for example, you can sort requirements by
priority and address all high-priority requirements early in the project so that you can be sure to complete
the requirements that are most significant to the success of your project. You created requirements and set
requirement attributes in a view and demonstrated the link between requirements in the database and the
documents in which the requirements were created.

4. Tracking Requirements
Topics to be covered:

• Managing changing requirements

• Setting traceability
• Managing change through traceability views
• Using suspect links
• Establishing hierarchy
• Querying (filtering and sorting)

Objectives: To demonstrate how you can create traceability relationships among requirements in a Word
document, use RequisitePro's suspect link feature to help you manage change, and sort requirements that
you establish.

Note: The Learning Project - Use Cases will be used for the exercises in this module.

4.1 Managing changing requirements

Your requirements will change no matter how carefully you define them. In fact, some requirement change
is desirable; it means that your team is engaging your stakeholders. Accommodating changing
requirements is a measure of your team's sensitivity to stakeholder needs and work flexibility, team
attributes that contribute to successful projects. Change is not the enemy—unmanaged change is. (For
further discussion of managing change, click here.)

Managing requirement change includes (but is not limited to) the following activities:

• Keeping track of the history of each requirement

• Establishing traceability relationships between related requirements

• Maintaining version control

Several features in RequisitePro help you track your project requirements and manage change. Some of
these features are described below.

4.2 Setting traceability

Traceability is a directional relationship between any two requirements (of the same type or different
types). ReqA --> ReqB means that ReqA is traced to ReqB. ReqA <-- ReqB means that ReqA is traced
from ReqB.

RequisitePro's traceability feature helps assure the quality and completeness of your products. You can
link abstract requirements, such as product features, to requirements such as hardware and software
functional specifications. You can trace from your use cases to the features requested by your
stakeholders.
As you create requirements in RequisitePro, you establish traceability between feature requirements and
more detailed requirements (such as use-case requirements). You can define the dependencies among
requirements of the same type or different types. For example, you can trace use-case requirements (UC
requirement type) to the feature requirements (FEAT requirement type), because use cases depend on the
specification of the features. There may be times, however, when features do not apply to a specific use
case, they are not easily traced from a particular use case, or they are not functional requirements. In
these situations, you can trace supplementary specification (SUPP) requirements to the feature
requirements.

4.3 Managing change through traceability views

RequisitePro allows you to create two kinds of traceability views:

• Traceability Matrix, which illustrates the relationships between requirements of the same or
different types. You use this matrix to create, modify, and delete traceability relationships and to
view traceability relationships with a suspect state. You can also use the Traceability Matrix to filter
and sort the row requirements and column requirements separately.

• Traceability Tree, which displays all internal and external requirements traced to or from a
requirement (depending on the direction of the tree). The Traceability Tree displays only the first
level of traceability among requirements that reside in different projects (cross-project traceability).
For example, if a requirement in your project is traced to a requirement in another project (external
requirement), the external requirement is displayed in the Traceability Tree, but other requirements
that the external requirement is traced to are not displayed in the tree.

In a Traceability Matrix, arrows are used to denote the direction of traceability between two requirements.

When the arrow appears in a cell (the intersection between a column and a row), it means that a
requirement listed in that column can be traced to the requirement listed in that row. (The direction of the
arrow indicates whether a requirement is traced to or traced from another requirement.)

Exercise: Create and clear traceability relationships from a matrix view

In this exercise, you learn two ways to set and remove traceability relationships.

1. Click File > Open Project. In the Open Project dialog box, select Learning Project - Use Cases,
and click the Exclusive check box. Click OK.

2. In the Explorer, click the plus sign next to the Coverage Analysis package to expand it, and
double-click the view Functional Requirements Coverage.

The Traceability Matrix shows feature requirements as columns, use-case requirements as rows,
and their traceability relationships in the intersections of the rows and columns. Click any
intersection in this view and note that the full text of the row requirement (in this case UC) and
column requirement (FEAT) are displayed in the two lower panes.

3. Select one of the empty intersections between a UC and FEAT requirement.

4. Click Traceability > Trace to. You have just created a traceability relationship!
 5. Set multiple traceability relationships at one time by clicking the Ctrl or Shift key and selecting
multiple requirement traceability intersections in this view that will have the same trace.

6. Review the traceability; then select the same requirements as above and click Edit > Set Value.
Select Delete Trace and click OK; click Yes in response to the dialog box that asks you to confirm
your selection. The traceability relationships created above have been removed.

7. Click the minimize button in the top right corner of RequisitePro.

Exercise: Create traceability relationships from the Word document

1. In the Explorer, expand the Use Cases package, and then expand the Purchase CD package.

2. Double-click the document Purchase CD to open it.

3. Scroll to Section 3.1.1 and click anywhere in use-case requirement 3.2.

4. Click RequisitePro > Requirement > Properties.

The Requirement Properties dialog box opens.

5. Click the Traceability tab.

From this tab, you can add, delete, and modify the relationships between the requirement you
selected and any other requirement.

6. In the To section of the dialog box, click the Add button. (This will enable you to add a traceability
relationship from the use-case requirement to another requirement.)
The Trace To Requirement(s) dialog box opens.

7. Select FEAT1: Secure payment method.

8. Click OK to close this dialog box, and click OK again to close the Requirement Properties dialog
box.
You have now established a trace between a use-case requirement and a feature requirement.

To view the trace, expand the Traceability Matrix you created in the preceding exercise and scroll to the
intersection of the FEAT1 and UC3.2 requirements.
You can also see this relationship in a Traceability Tree view. In the Explorer, double-click the stored
Traceability Tree view and look at FEAT1.

4.4 Using suspect links

When you modify a requirement's name, text, or type or the attributes associated with requirements that
are traced to or from one another, the relationship between the requirements requires attention.
RequisitePro signals this suspect condition with a red diagonal line through the traced to or traced from
arrow in a Traceability Matrix or Traceability Tree. Note that when requirements change, only direct
traceability relationships become suspect; indirect relationships are not affected.

For example, if traceability relationships exist between Requirements A and B and between Requirements
B and C, and you modify Requirement A, the relationship between Requirements A and B becomes
suspect, but the relationship between Requirements B and C does not. Requirement B may need to be
updated to reflect the modifications made to Requirement A.

A red line through the arrow indicates that the traceability relationship is suspect. This occurs when
either of the requirements has been modified after the initial traceability relationship has been established.

In a Traceability Tree, a suspect relationship is flagged as follows:

(In an Attribute Matrix, a suspect relationship is denoted by an "(s)" in the Traced to or Traced From
columns.)

Your ability to modify traceability depends upon the security permissions that have been assigned to you
as a user. Permissions define your ability to create, modify, and remove traceability relationships and also
mark and clear suspect traceability relationships. If security has not been restricted on your project, all of
these actions are available to you by default.

Exercise: Create a suspect relationship

The traceability relationships you establish help you manage change; if you make a change to one
requirement, RequisitePro flags the traceability relationship as suspect.

1. In the Explorer, expand the Purchase CD package, and double-click the document to open it.

2. Scroll to Section 3.1.2, and place the cursor after the first bullet item (CustomerID).

3. Add a space and type and date of birth.

4. Click RequisitePro > Document > Save. The Change Description dialog box opens and asks
for a reason for the change.

5. Type for the purpose of this exercise and click OK. Then minimize the document.

Now open a Traceability Tree view and look at the two requirements. (In the Explorer, select the stored
view in the Traceability Tree Views package and double-click it.)

This is what you should see when you open the Traceability Tree.

Notice that because you have changed UC3.2, all traceability relationships that involve that requirement
are called into question and must be re-evaluated. The red diagonal line through the arrow indicator
reminds you to do that.
Suspect relationships tell you that you should check the requirements to which this requirement is linked,
to assess the impact of your UC change. Suspect links can be cleared after you have reviewed the impact
of your edit by right-clicking the suspect link and then clicking Clear Suspect. Use Microsoft's Extended-
Select (Shift > click or Ctrl > click) to select multiple suspect links to be cleared at one time.

Close the view by clicking the lower of the two Xs in the top right corner of the screen.

Exercise: Create suspect relationships in an Attribute Matrix view

1. In the Explorer, expand the Use Cases package and select the Attribute Matrix view All Use
Cases. Double-click it to open it.

2. Click View > Query Row Requirements. (You may also select the Query row requirements
icon .) This brings you into the query builder.

3. In the Select Attribute dialog box, select Traced-to as the attribute to be filtered, and click OK.
The Query Requirements dialog box opens.

4. Click the FEAT requirement type, and make sure that the Traced button and the Suspect only
check box are activated. Then click OK.

5. In the Query Row Requirements dialog box, click OK to run the query builder, which shows you
the current criteria of your query.
 In the resulting view, find UC3.2 and then scroll to the right until you reach the Traced-to column;
note the "(s)" entries after requirement FEAT1. This entry indicates that the traceability relationship
between the two requirements (UC3.2 and FEAT1) must be reexamined because a change has
been made to one of the requirements.

Close the view by clicking the lower of the two Xs in the top right corner of the screen. (Do not save the
view at the prompt.)

4.5 Establishing hierarchy

A hierarchical requirement is a requirement that is included within a parent-child relationship with other
requirements of the same type. Hierarchical relationships can be used to subdivide a general requirement
into more explicit requirements. A child requirement is any requirement that has a parent. Child
requirements provide additional detail for their parent requirement. For example, a parent requirement
might be "The system shall display customer information." Child requirements might include name,
address, date of birth (details that support the parent requirement).

If a parent requirement appears in a document, the child requirements must appear in the same
document. The parent requirement and all of its children must be of the same requirement type.

Parent-child requirements imply dependency. Each child requirement can only have one parent, but a
requirement can be both a parent and a child. If a parent requirement is changed, the relationships with its
children become suspect.
Exercise: Create hierarchical requirements in a document

First, create a requirement.

1. Open the use-case document Purchase CD.

2. Scroll to the text in section 3.2.3. At the end of the requirement bracket, press ENTER to begin a
new line, and then type the following:

QUIT TEMPORARILY, ORDER PLACED ON HOLD

The Shopper can place an order on hold for 24 hours; the Shopper then has the options of
completing the purchase or ending it altogether. The use case ends.

3. Select the text you typed and click RequisitePro > Requirement > New.
The Requirement Properties dialog box opens.

4. In the Type box, accept the default (UC: Use Case); in the Name box, type QUIT TEMPORARILY,
ORDER PLACED ON HOLD. Click OK.

5. Click RequisitePro > Document > Save to create the requirement.

Next, make the requirement you created a child of the requirement "The Web shopping application sends
information. . . ."

1. Click anywhere in the text of the requirement you just created and click RequisitePro >
Requirement > Properties.
The Requirement Properties dialog box opens.

2. Click the Hierarchy tab. In the Parent box, select Choose Parent.
The Parent Requirement Browser dialog box opens.

3. Select UC3.5 as the parent and click OK.

4. Click OK to close the Requirement Properties dialog box.

5. Click RequisitePro > Document > Save to commit the requirement.

6. The Change Description dialog box asks you to provide a reason for the requirement change.
Type "for the purpose of this exercise" and click OK.

Notice that when you created the requirement, it was given the tag UC8. After you designated it as a child
of UC3.5, it was given a number that reflects its subordinate status to that requirement.

RequisitePro generates a requirement tag for the child requirement based on the parent requirement's
number. The hierarchical relationship is reflected in the text and in the view.
Exercise: Change the parent of a child requirement

1. In the document Purchase CD, click requirement UC3.6 QUIT, SHOPPER NOT IDENTIFIED.

2. Click RequisitePro > Requirement > Properties.

The Requirement Properties dialog box opens.

3. Click the Hierarchy tab, and from the Parent box, select the choose parent option.
The Parent Requirement Browser dialog box appears.

4. Scroll to UC3.5 QUIT and click OK. Then click OK in the Requirement Properties dialog box.
The child requirement you selected has now been reassigned to a different parent requirement,
and its number has been changed to reflect that.

5. On the Word menu bar, click RequisitePro > Document > Save to commit the changes and
remove the pending tag.
The Change Description dialog box opens, and you are required to give a reason for the change;
in the window, type Assigned to a different parent for more logical clustering of child
requirements. Then click OK.
 6. Click RequisitePro > Document > Close.

4.6 Querying (Filtering and Sorting)

After you have created a view, you can query (filter and sort) its information in a variety of ways. Filtering
restricts the information being displayed, and sorting determines the order in which information is
displayed. For example, in an Attribute Matrix, you may want to order requirements information from
highest to lowest priority (sort criteria) and view only those requirements assigned to you (filter criteria).

You filter and sort requirements by applying query criteria to the attributes. These criteria limit the values of
the attributes or limit the traceability relationships. You can create a simple query involving only one
attribute, so that you can see the results of each query. Or you can create a query that filters and sorts all
at once for several attributes.

For example, you might create a query such that only requirements having a high or medium priority are
displayed. You can use this information to determine which requirement features you will implement at
various stages of the project.

Exercise: Create a query in an Attribute Matrix

In the following exercise, you isolate all feature requirements that have a high priority with the customer,
are high in stability, and low in difficulty.

1. In the Explorer, select the All Features Attribute Matrix, and double-click it to open it.
2. Click View > Query Row Requirements. (You may also select the Query row requirements icon
.) This opens the query builder.

3. In the Select Attribute dialog box, make sure the FEAT requirement is displayed in the
Requirement Types box; in the Attribute to Filter/Sort Requirements field, select Difficulty and
click OK.
The Query Requirements dialog box opens.

4. Click the None button to clear all attribute values, select the value Low, and click OK.
This criterion is now added to the Query Row Requirements window.

5. Click the Add button and follow the same procedure to add the attribute Stability with a value of
High.
Both attributes appear in the Query Row Requirements window.

6. Click OK to run this query.

The result of this query scopes and directs the development toward those requirements that are stable and
relatively easy to implement. Two requirements meet the criteria.
Close the view.

Congratulations! You have completed this introduction to some of the many features offered by
RequisitePro.

Review

This module explained how to track requirements. You can establish traceability between two
requirements; then, if you change one of them, RequisitePro flags the traceability relationship as suspect
so that you reexamine it. The module discussed hierarchical relationships, which help you organize your
requirements logically, and demonstrated how you can run queries on your requirements, filtering and
sorting information in ways that help you prioritize your tasks. The exercises showed you how to create
hierarchical requirements in documents, change the parent requirement of a child requirement, create and
clear traceability relationships in views and documents, and create queries in an Attribute Matrix.

5. Advanced Features
The preceding modules in this tutorial explained some of the features in RequisitePro that help you
document, organize, and track requirements, thereby contributing to the successful completion of your
project.

Advanced features of RequisitePro are described below. Additional information about each feature is
available from online Help.
Archiving

RequisitePro offers two ways that you can archive your projects. Archiving is the process of duplicating a
project (the database, documents, and all related files) in a directory of your choice for the purpose of
restoring at a later time.

Creating baselines

You can use RequisitePro to create a baseline, or snapshot of the project's current state. A RequisitePro
baseline is a Rational Unified Change Management object that typically represents a stable configuration
of one or more components. A baseline identifies activities and one version of every element visible in one
or more components. It should be created at project milestones.

Cross-project traceability

RequisitePro's cross-project traceability feature helps you establish traceability between requirements that
reside in different projects. It is helpful in storing requirements common to multiple projects.

Customizing document and requirement types and attributes

Modules 2 and 3 explained how you can use the defaults provided by RequisitePro to create documents
and requirements. You can also create, edit, and delete document and requirement types and attributes as
needed. To modify the existing types, you select the project in the Explorer, click File > Properties, and
then click the appropriate tab. Click the Add, Delete, or Edit buttons on the tab and follow the prompts to
add or delete information as necessary. Click the buttons below to see screen captures of the relevant
tabs.

Document Types

Requirement Types
Requirement Attributes

Deleting requirements

RequisitePro provides several ways for you to delete requirements. The Delete-Unmark command
enables you to delete a requirement from the database but to retain the requirement text as ordinary text
in the document; the Delete-Remove command allows you to delete a requirement from the database and
to delete the text of the requirement from the document. These methods cause the requirement history
and traceability relationships to be permanently removed from the project database. A third way—and this
is the way we recommend—is to keep the requirement but to modify the requirement attributes to indicate
that the requirement is invalid. You do this by adding an attribute value, such as Invalid or Deleted, to an
existing attribute, such as Status. When you sort your requirements, this value clearly indicates that the
requirement is not active. Unlike the Delete commands, this method of deleting requirements does not
delete the requirement history, which is often helpful to retain for reference purposes.

Discussion groups

Discussion groups let you comment and raise issues and questions to a group of project users
(participants). Discussions can be associated with one or many requirements, or they may refer to the
project as a whole.

Integrations

RequisitePro is included in all Rational Suite products as part of the Rational Team Unifying Platform,
which also includes the following applications:

• Rational Rose for object-oriented analysis, modeling, design, and construction

• ClearQuest for team-based change request management

• TestManager for management of software testing assessments

• ClearCase LT for configuration management

• SoDA for project reporting and documentation

• Rational Unified Process for incorporation of software development best practices.

All of the products in the Rational Suite family share a common foundation of team-unifying tools, and they
include additional role-specific tools to optimize each suite for the individual practitioner.

RequisitePro can be used with Microsoft Project, too. It can be used to create tasks from requirements and
to establish traceability from those requirements to the tasks.

Offline authoring

Offline authoring lets you edit a requirements document outside of RequisitePro (i.e., offline). A read-only
copy of the document is retained in the project for other project users to view while edits are being made
offline. You can add and delete requirements in the offline document, and when you bring the document
back online, RequisitePro replaces the read-only document with the modified document.

Requirement Metrics

Requirement Metrics enables you to report statistics on requirement text, attributes, relationships, and
revisions. You can select a subset of requirements (a requirement type or a saved view) for your report,
choose filter criteria, and add them to your report. The report results are displayed in Microsoft Excel and
can be manipulated using Excel's charting capabilities.