This chapter discusses key requirements management and RequisitePro concepts.
RequisitePro is a comprehensive tool that supports any of today's requirements management processes. The predominant requirements management processes in use today are traditional (e.g. IEEE, CMM) and use case driven (e.g. Objectory). Whether you document your requirements with use cases or a software requirements specification, RequisitePro is the only tool that organizes, documents and manages change for any and all of these processes.
Included with RequisitePro 3.0 are features to help you effectively manage requirements, regardless of which process you use. The Learning Projects are online tutorials designed to accelerate learning RequisitePro. One Learning Project teaches traditional requirements management techniques and includes such traditional materials as a Product Requirements Document (PRD), a Software Requirements Specification (SRS) and a Test Plan (TST). The other Learning Project teaches the use case based approach to requirements management.
A discussion of requirements management
Requirements management is a systematic approach to finding, organizing, documenting and tracking the changing requirements of a software application or system. Requirements are capabilities and objectives to which the software or system being built must conform. Requirements are found in vision documents, problem reports, feature requests, other products, business practices, designs, specifications, quality assurance plans, test cases and prototypes.
The Standish Group reported forty percent of software projects fail. This failure is attributed to poor requirements management; incorrect definition of requirements from the start of the project and poor requirements management throughout the development lifecycle. One way to help ensure the success of a project is to implement an effective requirements management process. RequisitePro can help you effectively organize and manage requirements as well as trace the impact of changes on schedules, costs and resources.
Requirements management offers numerous benefits. These include improved predictability of a project's schedules and deliverables, reduced project costs and delays, improved software quality, improve team communication, improved compliance with standards and regulations (the Capability Maturity Model, the Department of Defense, ISO 9000, FDA).
Implementing an effective requirements management process
Here are six essential steps to help you manage your requirements and achieve your project goals.
Identify your requirements.It is very important to identify and manage requirements from the beginning of a project. Here are some factors to consider when setting priorities at the beginning of the requirements management process.
- How does the requirement add to product functionality, usability, reliability and performance?
- Will the requirement being considered be worth the effort, given your schedule constraints?
- Is the requirement feasible given risks associated with it?
- If the requirement is implemented, how will it impact your ability to maintain the product?
Organize your requirements. Look at your schedule. Do you have time to complete all of your high priorities? Setting expectations at this stage will help team stay on schedule and close to budget. Ask yourself these questions:
- What are the needs of my users?
- What are primary goals of this project?
- What key features are part of my requirements list?
- What kinds of documents are needed to record and trace requirements from wish lists to test scripts?
- Determine which tasks are necessary to accomplish requirements, who is responsible for completing them and which requirements are part of the project's critical path.
Understand and analyze the factors associated with your requirements. If you have a long list of requirements, classify them in categories that make sense to your team. Asking the following questions will help you analyze these factors more efficiently.
- How will each requirement benefit your customers?
- How much effort is necessary to accomplish the requirement?
- How will each requirement affect your budget and schedule?
- What are the risks associated with each requirement?
Refine and expand your requirements. Refining requirements early on in the process will help prevent requirement errors later. The time, money and effort required to fix errors at the end of the process could cost one hundred times more than the time spent planning now.
Manage changes to your requirements. Track the progress of your requirements and trace changes to them. Monitor changes, analyze the impact of change and communicate this to your team.
RequisitePro provides a document-centric approach to managing requirements. This approach itemizes requirements from within project documents, then manages them with an integrated database. This approach lets teams easily collaborate, communicate and provide updates on the same project.
RequisitePro is comprised of workplaces where distinct, but interrelated work is done. When RequisitePro is started, the Tool Palette Workplace and the Views Workplace display. The Views Workplace is a window to the database. The Word Workplace is not started until a document is created or opened and is a window to Word. The Workplace currently in use displays in front.
RequisitePro automates change management and traceability. Requirements, requirement relationships and changes to requirements and their relationships can be queried, traced and tracked throughout the development lifecycle.
One way to better acquaint yourself with how RequisitePro works is to run the two Learning Projects. The Learning Projects are online tutorials designed to accelerate learning RequisitePro. One Learning Project covers the essentials of RequisitePro, including key features and operations as well as new features for each release. Included in this Learning Projects are samples of a Product Requirements Document (PRD), a Software Requirements Specification (SRS) and a Test Plan (TST). The other Learning Project provides a use case based approach to requirements management.
Using RequisitePro to manage requirements
Because each project changes as it progresses, your project's success may depend on your ability to track and trace requirements as they evolve. RequisitePro includes powerful management tools that help you track the progress of your requirements, trace changes to them and enhance your ability to perform impact analysis when changes occur.
Traceability is a methodical approach to managing change by linking high-level requirements to their more specific descendents. RequisitePro's Traceability feature makes it easy to track changes to a requirement throughout the development cycle. Without traceability, each change would require a review of your documents to determine which, if any elements need updating.
It is important to use traceability to maintain links between requirements and the business and technology solutions that resulted from them. These links help a team determine the impact of changes, as well as development status (which should be an attribute of the business and technology solutions).
Version control provides the ability to trace changes by archiving projects. RequisitePro's version control lets you trace change by archiving projects. Version control helps you keep a record of changes to project files during the development cycle. With version control you can manage multiple reviews of your projects, retrieving, modifying and returning revisions to the archive in an organized and consistent manner. This is accomplished in RequisitePro with RequisitePro's Archive command, PVCS Version Manager, Visual SourceSafe and ClearCase.
Using hierarchical requirements and traceability to manage change
Hierarchical requirements and traceability are two distinct elements of change managed relationships. A change managed relationship is a connection between two requirements. This connection can be changed and can be suspect. Hierarchical requirements and traceability are two distinct change managed relationships. Hierarchical requirements are tree-like change management and traceability is networked change management.
Traceability does not have a hierarchy, it is just a connection. Hierarchical requirements have a hierarchy and this hierarchy is parent-child. Traceability is a directed, networked relationship of many requirements to many requirements that participates in change management. Hierarchical requirements is a one parent to one or more child(ren) relationship that participates in change management. Hierarchical requirements exist within one requirement in one document in one project.
What causes a requirement relationship to become suspect? A change to text or an attribute. Only relationships are suspect. Neither parents nor children are suspect, just their relationships.
With both hierarchical and traceability relationships, the relationship cannot trace to itself or be circular.
Understanding change managed hierarchical relationships
If a parent requirement is deleted, one of the following results occurs.
Understanding how change affects suspect relationships
Displaying hierarchical requirements in Views and queries
The behavior of hierarchical requirement relationships is similar to other change managed relationships. One major difference is the addition of more variables, such as attributes and child requirements. So, you need to plan much more carefully and factor in these additional variables when you create a view or a query. Because hierarchical relationships are tree relationships, determine which piece of the tree displays in the query.
How RequisitePro works with requirements
Requirements in RequisitePro are classified by their type and their attributes. In RequisitePro, an attribute provides information to manage a requirement. Most attribute information is project-related and may include:
Attributes can provide crucial information to help a team plan, communicate and monitor project activities from the analysis and design phases through the test and release phases. Determine who an attribute is relevant to. For example, if you sort by high priority, determine whose high or low priority to sort by, the parent or the child?
Following is a list of suggested attributes that can be helpful for defining your requirements in RequisitePro. These attributes are suggestions, not rules. You can use these suggested attributes provided with RequisitePro or define and use any attributes that are appropriate for your project and business.
Priority
- Identifies requirements by their importance to the project. Helps team members prioritize their efforts and use their time more effectively.
Status
- Communicates the progress of a requirement.
- If a requirement's status is Proposed, the requirement is currently being discussed by the project team.
- If a requirement's status is Approved, the requirement has been discussed and agreed on.
- If a requirement's status is Incorporated, the requirement has been added to the appropriate specification.
Authors -
Documents information about the individual or team that created or changed the requirement's text or attributes.
Responsible Party
- Documents the individual (or team) responsible for ensuring the requirement is satisfied.
Rationale
- Documents the text of or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification, or to a minute marker on a video tape of an important customer interview.
Cost
- This is the cost value of the requirement to implement. The value of cost can be logical (high, medium, low) or numerical.
Date -
Documents the date a requirement was created or the date the most recent change was made to a requirement.
Version of Requirement
- Identifies the version number and history of requirements changes.
Relationships To Other Requirements
- Documents the relationships that exist among requirements. For example, attribute fields can record:
- The less developed, high level requirement(s) the requirement was based on.
- The more well-defined requirement that resulted from this requirement.
- Requirements that are dependent on this requirement.
The list of requirement attributes in the preceding section is not definitive. Other common attributes include Difficulty, Stability, Risk, Security, Safety, Release Implemented and Functional Area. You can create and control attributes according to your needs. Whichever attributes you use, RequisitePro offers the flexibility to easily customize your project documents and databases to define, articulate and manage the processes and culture of your organization.
A document type identifies the type of document, such as a use case, or a software requirements specification and helps ensure consistency across documents of the same type. A document type is a template that is applied to your documents. The template can include the default font for your document, the available heading and paragraph styles, and the default type of requirements for the document. Or it could encompass both formatting conventions and an outline that helps you organize your requirements information.
You determine the document type when you create or modify your project. Each document in your project must be associated with a document type, but more than one document can be associated with the same document type.
When you create a document, you can associate it with a document type already defined in your project. The new document inherits the style and functional attributes associated with the document type and, at the same time, is consistent with other documents of the same type.
RequisitePro recognizes different project documents are important to the success of a project. RequisitePro provides standard document templates that can be used as is, or can be customized according to your specifications. With RequisitePro document types, you can define a template that includes an outline, formatting, attributes, attribute definitions and system defaults. Once you define the document type, an author can create a new document based on that type
After the appearance of the document and the information to include is defined, you can use the document as a standard for your organization. The benefits to using standards, either those provided with our IEEE Standards Pack or those you define are:
A requirement type is a template for your requirements. Requirement types are used to classify similar requirements so they can be efficiently managed. When you define a requirement type, you define a common set of attributes, display style, and tag numbering. A requirement type is a set of descriptive and operational information associated with the requirement when the requirement is created. A requirement type serves as a template for subsequent requirements and is useful for classifying and grouping similar requirements in a project. RequisitePro uses three requirement types for RequisitePro projects. They are a product requirement type (PRD), a software requirement type (SRS), testing requirement type (TST) and use cases.
Although RequisitePro provides these three requirement types, you are not limited to using just these three. You can create your own requirement types or add any new ones you deem appropriate.
A PRD is a high-level document that is often used to describe the whys and whats of a product or application. Use the PRD to:
The SRS defines the complete external behavior of the system to be built. The SRS captures software requirements that provide:
The SRS should be as complete, correct and clear as possible. Use the SRS to:
The TST captures the test plan, test design specifications, test case specification and test procedure specifications. The TST is useful for the verification and validation phase, also called V&V, of a project's lifecycle. Verification is the process of assuring the products of a given phase of the software development lifecycle fulfill the requirements established during the previous phase. Validation is the process of evaluating software at the end of the development process to ensure compliance with software requirements. Use the V&V process to ensure:
Document Types Versus Requirements Types
Document types and requirement types are two similar requirements management concepts and tools. They are often confused with one another because they perform such similar functions. Both serve as templates and define the appearance of two essential requirements management components, a document and a requirement. Where they differ is in their application.
One way to avoid confusing the two is to think of them as macro and micro requirements management tools. The document type is the macro tool and defines the look and feel of a requirements document, and the requirement type is the micro tool and defines the look and feel of requirements in a requirements document.
About the RequisitePro/Rational Rose synchronization
The Rose synchronization wizard exchanges information between a RequisitePro project and a Rational Rose model. With the wizard, requirement types in RequisitePro are synchronized with Rose actors, use cases, classes and/or packages. The information exchange ensures the data being used is the same in both applications. This also eliminates the need to recreate information created in one application for use with another.
The terms that follow are used throughout the learning paths and are specific to RequisitePro.
Actor
- Someone or something outside the system or business that interacts with the system or business.
Attribute
- Information attached to a requirement that provides important details about the requirement, such as its priority, cost or author.
Attribute label
- The name of the attribute, such as risk, priority or author.
Attribute matrix
- An attribute matrix displays a requirement type's attributes in columns from left to right.
Attribute value
- Information assigned to the attribute such as text or numbers. For example, the value of priority could be Low, Medium or High.
Catalog
- The RequisitePro catalog stores reference information that maps logical names of documents and projects to their physical DOS/Windows file names. Catalog is also a button on the Tool Palette that adds projects to the RequisitePro catalog.
Child requirement
- A requirement that participates in a hierarchical relationship with a parent requirement. Child requirements reside below the parent in the hierarchy.
Class
- A Rational Rose concept used to describe data and methods.
Cross project traceability
- A RequisitePro feature that lets you establish traceability relationships between requirements that reside in different projects.
Database
- A collection of data stored in a repository. By using specific commands, a database can be searched and sorted for the retrieval of specific information. See Repository.
Document
- A Word document that is part of the project.
Document type
- A set of descriptive and operational information associated with a document when the document is created. The document type defines the document's default template or outline, default requirement type attributes and requirement styling. All documents in a document type share the same three character extension (ex. .doc).
External project
- A project containing requirements used to establish traceability relationships with requirements in a currently open project.
External requirement
- Requirements residing in an external project. Traceability relationships can be created between requirements in different projects.
External traceability
- An established traceability relationship between requirements in different projects.
Feature
- An externally observable service provided by the system which directly fulfills a need.
Group
- A list of users organized by the operations they have privileges to perform. For example, members of the Administrators group can create group accounts and add users to groups.
Hierarchical levels
- The level of a requirement in a hierarchical relationship. The parent requirement is the top or the root level.
Hierarchical relationship
- A relationship between two requirements of the same requirement type. The requirements follow rules regarding to numbering, deleting parent/child requirements and change management.
Hierarchical requirement
- A requirement that participates in a hierarchical relationship with other requirements. A requirement is either a parent, a child or a parent and a child.
Outline
- A reference document used to create new Word documents. Also referred to as a template. An outline can include formats, page layout information, attributes, attribute definitions and system defaults. An outline is useful for maintaining consistency across documents of the same type.
Package
- A Rational Rose concept used to describe a collection of information. Also referred to as a category.
Parent requirement
- A requirement that participates in a hierarchical relationship with a child requirement. Parents reside at the root level, above child requirements, in the hierarchical relationship.
Project
- A project encompasses a database, documents, document types, requirements and requirement types.
RxR matrix
- This View displays two different requirement types and the interrelationships between them. Also referred to as a traceability matrix. See also View.
Reparent
- The act of assigning a new parent to a child requirement participating in a hierarchical relationship.
Repository
- A collection of data. See Database.
Requirement
- A specification for the externally observable behavior of the system (i.e., inputs to the system, outputs from the system, functions of the system, attributes of the system or attributes of the system environment). In RequisitePro, requirements can be articulated as textual, graphical or OLE objects.
Requirement type
- A set of descriptive and operational information associated with the requirement when the requirement is created. A requirement type serves as a template for subsequent requirements.
Requirements document
- A document created in Word or RequisitePro that captures requirements and is used to communicate product development efforts.
Requirements management
- A systematic approach to eliciting, organizing, documenting and managing the changing requirements of a software application.
Root requirement
- A requirement that resides at the top level of a requirements hierarchy.
Rose item
- A RequisitePro concept used to describe any of the three Rational Rose concepts (use case, class and package).
SPC templates
- The EssentialSETLite templates created by the Software Productivity Centre, Inc. These templates provide information on IEEE standards, ISO 9001, SEI's CMM and recommendations on how to use and customize the files. SPC's templates provide procedures, standards and template files.
Security
- Prevention of system use, potential harm and data loss by unauthorized individuals. In RequisitePro, users are given specific privileges or rights that determine the amount or kind of access they have to projects.
Suspect traceability relationship
- This state displays when a change occurs to a link established between two or more requirements in the same project.
Tool Palette
- A collection of commands displayed as buttons in RequisitePro. When clicked, these buttons provide access to requirements information and perform requirements management operations in a RequisitePro project.
Traceability
- A link or definable relationship between two requirements.
Traceability matrix
- This View displays two different requirement types and the interrelationships between them. See View.
Traceability tree
- This View displays all or selected requirement types in a project and the relationships between them. Also referred to as a Tree View. See View.
Use case
- A sequence of transactions a system performs which yield an observable result of value (a work output) to someone or something outside the system that interacts with the system.
User
- An individual or entity that directly uses the system or the output of a system to accomplish a work product.
View
- In RequisitePro, a View displays information about a project, document or requirement. Views display requirements in documents, in tables and in outline trees. Views display the attributes assigned to requirements or the relationships between requirements.
Views Workplace
- A window that manages different Views of the requirements management information in a project.
Word document
- A document created in Microsoft Word or RequisitePro that is saved in Word format.
Word Template
- A reference document (.dot) used to create new Word documents. Also referred to as an outline. A template can include formats, page layout information, attributes, attribute definitions and system defaults.
Word Workplace
- The Word Workplace contains requirements specifications in the form of RequisitePro documents. The Word Workplace can also contain normal Word documents.
General Conventions
|
Save As |
Selects an item from a menu or Tool Palette. For example, Save As means click the File menu and point to Save As. |
|
Italics |
Used to emphasize a word, term or file name (ex., reqpro.ini). |
|
Boldface |
Signifies buttons in dialog boxes that launch subsequent dialogs (ex., Add to PVCS Version Manager button in the PVCS Version Manager dialog box) or commands. |
Keyboard Conventions
The keys on your keyboard may be labeled differently than those described in this manual.
|
Shortcut keys |
Use shortcut keys in combination or in sequence. For example, SHIFT + F3 means hold the SHIFT key while pressing the F3 key. |
|
UP ARROW, DOWN ARROW, RIGHT ARROW, LEFT ARROW, HOME, END, PAGE UP, PAGE DOWN |
Use these keys to navigate in a document, view or in a menu. |
|
Numeric keypad keys |
If your keyboard has a numeric keypad, press the NUM LOCK key to type numbers. |
Mouse Conventions
Use a single-button or a multiple-button mouse with RequisitePro. With a multiple-button mouse, the left mouse button is the primary mouse button, unless you have configured it otherwise. Use the secondary mouse button in the Word and Views Workplaces.
|
Point to |
Position the pointer so it rests on the desired item on the screen. |
|
click |
Point to an item, press the left mouse button, then immediately release the button without moving the mouse. |
|
Double-click |
Point to an item, then quickly press and release the left mouse button two times. |
|
Right-click |
Point to an item, press the right mouse button, then immediately release the button without moving the mouse. |
|
Click and drag |
Point to an item and press and hold the left mouse button while dragging the item around the screen. |
File Extensions
|
File extension |
Definition |
|
.def |
An outline's definition file. |
|
.doc |
A Word document. |
|
.dot |
A Word template. |
|
.hlp |
A Windows application help file. |
|
.txt |
A text file used to maintain information about projects and their documents. |
|
.rqs |
A RequisitePro project database. |
201 Principles of Software Development. Dr. Alan Davis.
McGraw-Hill, Inc. New York, NY. 1995.
Exploring Requirements Quality Before Design. Donald C. Gause and Gerald M. Weinberg. Dorset House Publishing Co., Inc. 1989.
Object-Oriented Software Engineering. Ivar Jacobson. The ACM Press.
Addison-Wesley Longman Limited. Essex, England. 1992.
Standards, Guidelines and Examples of System and Software Requirements Engineering. M. Dorfman and R. Thayer.
IEEE Computer Society. Los Alamitos, CA 1991.
Order from IEEE Customer Service
445 Hoes Ln.
P.O. Box 1331
Piscataway, NJ 08855-1331.
(800) 678-4333.
UML Distilled. Martin Fowler with Kendall Scott.
Addison-Wesley Longman, Inc. Reading, MA. 1997.