Requisite Pro Tutorial

Rational RequisitePro Tutorial

TM

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 doubleclick 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 \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 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 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 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 ExtendedSelect (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.