Requirements Management Plan From IBM RequisitePro Sample

ClassicsCD.com

Requirements Management Plan

Version 1.1

Revision History

Date	Version	Description	Author
1.25.1998	1.0	inception	p murphy
5.22.1999	1.1		h moriyuke

Table of Contents

1. Introduction 4

1.1 Purpose 4

1.2 Scope 4

1.3 Definitions, Acronyms, and Abbreviations 4

1.4 References 4

1.5 Overview 4

2. Requirements Management 4

2.1 Organization, Responsibilities, and Interfaces 4

2.1.1 administrator 4

2.1.2 visitor 4

2.1.3 member 5

2.1.4 customer 5

2.1.5 user 5

2.1.6 back office administrator 5

2.1.7 stakeholder 5

2.1.8 project manager 5

2.1.9 quality assurance (QA) 5

2.1.10 developer 5

2.1.11 team leader 5

2.1.12 configuration manager 5

2.1.13 requirements specifier 5

2.2 Contact Table 6

2.3 Tools, Environment, and Infrastructure 6

3. Requirements Artifacts 7

3.1 Artifact Description 7

3.1.1 Document Types 7

3.1.2 Requirement Types 9

3.1.3 Attributes 10

3.1.4 List Values 13

3.2 Traceability 15

3.2.1 Traceability Criteria for Requirement Types 15

3.3 Reports and Measures 16

4. Requirements Change Management 18

4.1.1 Change Request Processing and Approval 18

4.1.2 Change Control Board (CCB) 18

4.1.3 Change Control Manager [X. Sanchez-Tobar, Change Control Manager, Classics Inc., xtobar@classicscd.com] 19

5. Milestones 19

5.1.1 Inception 19

5.1.2 Elaboration 20

5.1.3 Construction 20

5.1.4 Transition 21

6. Training and Resources 21

Requirements Management Plan

1. Introduction

1.1 Purpose

The purpose of this plan is to establish and document a systematic approach to eliciting, organizing, and documenting the requirements of the system. This plan also establishes and maintains agreement between the customer and the project team on the changing requirements of the system.

1.2 Scope

This plan provides guidelines for the management of the Classics CD online CD purchasing system project.

1.3 Definitions, Acronyms, and Abbreviations

For common vocabulary for this project, please refer to the Glossary document.

1.4 References

Kruchten, Philippe. 1999. The Rational Unified Process. Menlo Park, CA: Addison Wesley

Leffingwell, D. and Don Widrig. 2000. Managing Software Requirements. Menlo Park, CA: Addison Wesley.

Spence, I. and L. Probasco. 1998. Traceability Strategies for Managing Requirements with Use Cases. Cupertino, CA: Rational Software Corporation.

The ClassicsCD Change Management Plan. For access and information, consult with Xavier Sanchez-Tobar, Change Control Manager, at xtobar@classicscd.com

1.5 Overview

This document contains specific details and strategies for managing the requirements of the Classics CD.com project. The document details how requirements are organized and administrated within our project. It also describes how requirements will be identified, assigned attributes, traced, and modified.

The document describes the change management processs for requirements. It describes the workflows and activities associated with maintaining control of our project requirement.

It specifies milestones to be reached and standards to be adhered to so that we can ensure and evaluate fulfillment of the requirements we specify.

2. Requirements Management

2.1 Organization, Responsibilities, and Interfaces

2.1.1 administrator

This user maintains the security, queries, backups, and network topology of the system to make sure that the system keeps running efficiently.

2.1.2 visitor

Anyone who has access to a computer and Web browser can visit the ClassicsCD.com Web site.

2.1.3 member

To purchase CDs at ClassicsCD.com, visitors must become members by providing identifying and purchasing information such as name, address, and credit card number.

2.1.4 customer

Our customers are online entities who use our system to purchase CDs.

2.1.5 user

A person who will use the system that is developed. This group will include customers, administrators, and other Classics CD employees.

2.1.6 back office administrator

This user is responsible for shipping the orders, verifying payment information and providing customer service. They also update the Web site to include new selections and remove old selections.

2.1.7 stakeholder

An individual or organization who is materially affected by the outcome of the system. Our primary external stakeholder is the Unreal Venture Capital Group.

2.1.8 project manager

The role with overall responsibility for the project. The Project Manager needs to ensure tasks are scheduled, allocated and completed in accordance with project schedules, budgets and quality requirements.

2.1.9 quality assurance (QA)

The function of Quality Assurance is the responsibility of (reports to) the Project Manager and is responsible for ensuring that project standards are correctly and verifiably followed by all project staff.

2.1.10 developer

A person responsible for developing the required functionality in accordance with project-adopted standards and procedures. This can include performing activities in any of the requirements, analysis & design, implementation, and test disciplines.

2.1.11 team leader

The team leader is the interface between project management and developers. The team leader is responsible for ensuring that a task is allocated and monitored to completion. The team leader is responsible for ensuring that development staff follow project standards, and adhere to project schedules.

2.1.12 configuration manager

The configuration manager is responsible for setting up the product structure in the Change Management system, for defining and allocating workspaces for developers, and for integration. The configuration manager also extracts the appropriate status and metrics reports for the project manager.

2.1.13 requirements specifier

The requirements specifier details the specification of a part of the system's functionality by describing the requirements aspect of one or several use cases and other supporting software requirements. The requirements specifier may also be responsible for a use-case package, and maintains the integrity of that package. It is recommended that the requirements specifier responsible for a use-case package is also responsible for its contained use cases and actors.

2.1.14 Change Control Manager The change control manager role oversees the change control process. This role is usually played by a Configuration (or Change) Control Board (CCB) and consists of representatives from all interested parties, including customers, developers, and users. In a small project, a single team member, such as the project manager or software architect, may play this role.

2.2 Contact Table

Role	Name	Title	Organization	Contact
customer (for beta testing)	D. Arosh	Tech rep	Carroll Marketing	darosh@carrollmarketing.com
stakeholder	J.R. Slingsby	CFO	Unreal Venture Capital Group	(800) 555-5555 (contact only through Project Manager)
project manager	P Murphy	Software Project Manager	Classics, Inc.	pmurphy@classicscd.com
quality assurance	B.V. Tam	Senior Testing Manager	Classics, Inc.	btam@classicscd.com
team leader	H Moriyuke	Senior Developer	Classics, Inc.	hmoriyuke@classicscd.com
requirements specifier	P Murphy	Software Project Manager	Classics, Inc.	pmurphy@classicscd.com
administrator	M. Mutevelic	IT director	Classics, Inc.	mmutevelic@classicscd.com
configuration manager	K. Zahar	SeniorSoftware Engineer	Classics, Inc.	kzahar@classicscd.com
Change Control Manager	X. Sanchez-Tobar		Classics, Inc.	xtobar@classicscd.com

2.3 Tools, Environment, and Infrastructure

Tool	Description	License Info	Technical Support	Website
Rational RequisitePro	For managing requirements.		support@rational.com 800-433-5444	www.rational.com
Microsoft Word	For creating and working with documents		through our internal technical support team	www.microsoft.com
Rational ClearQuest	our tool for change management		support@rational.com 800-433-5444	www.rational.com

3. Requirements Artifacts

3.1 Artifact Description

3.1.1 Document Types

Document Type	Description	Default Requirement Type
Stakeholder Requests (STR)	Key requests from stakeholders. These requests are separate from requests for changes to the product, such as enhancement requests and defects. Change requests are managed separately in the ClearQuest change management application.	Stakeholder Request (STRQ)
Vision (VIS)	Conditions or capabilities of this release of the system. This document combines elements of our original business proposal, business plan, and specifications for features to be developed. As such it may be considered the dynamic version of our business plan.	Feature (FEAT)
Use-Case Specification (UCS)	Use case description and elaboration.	Use Case (UC)




Glossary (GLS)	Used to capture common vocabulary specific to this project.	Glossary Item (TERM)
Supplementary Requirements Specification (SUP)	This document type describes system requirements not readily captured by the use cases.	Supplementary Requirement (SUPL)
Requirements Management Plan (RMP)	This document type describes requirements and strategies specific to the management and development of the Requirements Management Plan.	Reqruirements Management Plan (RMP)

3.1.2 Requirement Types

Requirement Type	Description	Attributes
Stakeholder Request (STRQ)	A request of any type—for example, Change Request, enhancement request, request for a requirement change, defect—from a stakeholder.	Priority, Status, Cost, Difficulty, Stability, Assigned to
Feature (FEAT)	An externally observable service provided by the system which directly fulfills a stakeholder need.	Priority, Status, Planned Iteration, Actual Iteration, Difficulty, Stability, Assigned to, Origin, Rationale, Cost, EnahancementRequest, Defect
Use Case (UC)	A description of system behavior, in terms of sequences of actions. A use case should yield an observable result of value to an actor.	Property, Affects Architecture, Planned Iteration, Actual Iteration, Assigned to, Rank, Test, Priority, Status, Difficulty, Stability, Cost, EnahancementRequest, Defect
Glossary Item (TERM)	A term used in the project’s common vocabulary.
Supplementary Requirement (SUPL)	A description of a requirement not readily described by a Use Case.	Priority, Status, Difficulty, Stability, Assigned to, Cost, EnahancementRequest, Defect, Test

3.1.3 Attributes

Attribute	Description	Type	List Values	Requirement Type
Priority	A feature’s priority is set by marketing, the product manager or the business analyst. The priority attribute designates the relative importance of implementing a feature. This attribute is used in managing scope and determining development priority.	list	Must	FEAT, UC,SUPL, RMP, STRQ
			Should
			Could
			Won't
Status	This attribute is set by the quality assurance team as they evaluate stakeholder requests.	list	Proposed	FEAT, UC,SUPL, RMP, STRQ
			Approved
			Incorporated
			Validated
Planned Iteration	This attribute is set by the team leader and describes our target date to satisfy the requirement.	integer	n/a	FEAT, UC
Actual Iteration	This attribute describes when the requirement was actually satisfied and is used for tracking progress on schedule.	integer	n/a	FEAT, UC
Difficulty	The development team sets a feature’s effort level. Because some features require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations about what can and cannot be accomplished in a given amount of time. This attribute is used in managing scope and determining development priority.	list	High	FEAT,RMP,SUPL,STRQ
			Medium
			Low
Stability	A feature’s stability is set by the analyst and development team, and is based on the probability that the feature will change or that the team’s understanding of the feature will change. This attribute is used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action..	list	High	FEAT,RMP,SUPL, STRQ
			Medium
			Low
Assigned to	The team member with primary responsibility for ensuring the requirement is satisfied.	text	n/a	FEAT,RMP,SUPL,STRQ
Origin	Who came up with this requirement? This attribute should be considered along with priority.	list	Hot Line	FEAT
			Partners
			Competitors
			Large Customers
Rationale	A general attribute for elaboration on priority.	text	n/a	FEAT
Cost	Estimated financial expense.	real	n/a	FEAT,RMP, SUPL,STRQ
EnhancementRequest	Used for integrating with ClearQuest.	text	n/a	FEAT,SUPL
Defect	Used for integrating with ClearQuest.	text	n/a	FEAT, SUPL
Property	Specific to Use Cases, used to elaborate on the use case text.	list	Name	UC
			Brief Description
			Basic Flow
			Alternate Flow
			Special Requirement
			Pre-Condition
			Post-Condition
Affects Architecture	A simple yes-no question, to be set by the developer.	boolean	True/False	UC
Rank	Linked to the planned iteration attribute- describes the order in which we will satisfy the requirements in relation to other requirements of the same priority.	integer	n/a	UC
Test	To be set by Quality Assurance.	boolean	True/False	UC, SUPL

3.1.4 List Values

Value	for Attribute	Description
Must	Priority	Critical to the success/survival of the business- or a direct order from the investor or a key account.
Should	Priority	advantageous- adds competitive edge- a unique feature
Could	Priority	possible, not necessarily advantageous.
Won't	Priority	Nor worth the effort.
Proposed	Status	Proposed by a stakeholder request
Approved	Status	Approved by the project manager and/or quality assurance.
Incorporated	Status	Delivered to the executable.
Validated	Status	Tested by Quality Assurance.
High	Difficulty	So difficult, it is likely to prove too expensive in terms of resources or money. Should be attacked first or discarded.
Medium	Difficulty	Difficult, but can be done without undue risk. Should only be attacked after all high difficulty requirements have been satisfied or discarded.
Low	Difficulty	Easy. Should be satisfied last.
High	Stability	Will most likely change, or is so vague as to need further elaboration before work can begin.
Medium	Stability	May change, but is stable enough to begin work.
Low	Stability	Will almost certainly not change- should be satissfied early in our process.
Hot Line	Origin	From our sales or technical support lines- small customers only [if a large customer calls through our hotline, this attribute should be set to what kind of customer they are first.]
Partners	Origin	We have no partners at this time
Competitors	Origin	CDNow, BMG, or any other online CD merchant
Large Customers	Origin	TBA
Brief Description	Property
Basic Flow	Property	the ordinary flow of the use case
Alternate Flow	Property	alternate paths for the use case
Special Requirement	Property
Pre-Condition	Property	what conditions are necessary before this use case is valid
Post-Condition	Property	results of the use case plus any other related post-conditions

3.2 Traceability

3.2.1 Traceability Criteria for Requirement Types

Requirement Type	Guidelines	Notes
Stakeholder Request (STRQ)	Every stakeholder request with “Approved” status must trace to one or more Use Cases or to one or more Features.
Feature (FEAT)	Every feature with “Approved” status or greater must trace to one or more Use Cases or to one or more Software Requirements.
Use Case (UC)		We don’t have actor requirement types- the actor should be described within the use case. Basically, all our use cases should detail interactions with outside people or systems.
Glossary Item (TERM)	Every Glossary term must have a unique and consistent definition throughout all project documents and artifacts.	Limit glossary terms to words that have meanings specific to the project that cannot be found in the dictionary.
Supplementary Requirement (SUPL)		Non-functional, as a rule.

3.3 Reports and Measures

For reports and measures on this project, use the Requirement Metrics tool, which is available from the Tool menu. In Requirement Metrics, create reports based on requirement types or saved views and query on the following filters:

Attribute Value:

An Attribute Value filter returns the requirements whose attributes have values that matches your criteria. The choices you make depend on the data type of the attribute you select in the Attributes drop-down list.

Attribute Value Change:

An Attribute Value Change filter returns the requirements with a changed attribute value that matches your BEFORE and AFTER selections. The choices you make depend on the data type of the attribute you select in the Attributes drop-down list. If several changes have been made to the attribute value, your BEFORE selection must specify the value which immediately preceded the current (AFTER) value. To report any change in an attribute value of the selected requirement type, use the Select All buttons for the BEFORE and AFTER selections.

Base Filter:

The Base filter defines the requirement type for a query. Every query is specific to a single requirement type. When you use a saved RequisitePro view defined in the Views Workplace, the Base filter serves as the first filter for requirements. The Base filter cannot be deleted, and is only changed by selecting a new view from the Choose a Requirement View drop-down list.

Children:

A Children filter returns the requirements that have the number of direct children that matches your selection criteria. You must choose which operator to use and enter at least one numeric value. If you choose the "Between" or "Not Between" operator, you must also enter a second numeric value. The default setting (> 0) reports all requirements of the selected type that have any children.

Parent Change

A Parent Change filter returns the requirements whose parent relationship has changed from your BEFORE selection to your AFTER selection. The selections allow you to report requirements that were changed from or to any parent, no parent, or one or more selected parents which you choose. When reporting changes to selected requirements, if a requirement had several changes of parent assignments, your BEFORE selection must specify the value which immediately preceded the current (AFTER) value.

Requirement Creation:

The Requirement Creation filter returns all requirements of the specified requirement type. Typically, this filter is used with the Time Period option to determine which requirements have been created in a specified time period.

Requirement Text Change:

A Requirement Text Change filter returns the requirements whose text has changed the number of times you specify. The filter allows you to choose comparison operators, such as "equal to" (=), "greater than" (>), etc., when specifying the number of times that the text has changed.

Traceability Change:

A Traceability Change filter returns the requirements that had a trace relationship either removed or added, depending on your selection.

View Descriptions:

[use this section to describe views you have created for your project]

Query Name		Description	Requirement Type	Attributes	Attribute Value Range
Features	displays all requirements of the Feature Type		FEAT	all	all
Glossary Terms	displays all requirements of the Glossary Term Type		TERM	all	all
Supplementary Requirements	displays all requirements of the Supplementary Requirements Type		SUPL	all	all
Stakeholder Request	displays all requirements of the Stakeholder Request Type		STRQ	all	all
Use Case Survey	displays all requirements of the Use Case Type		UC	all	all
Requirements traced to Features	displays traceability between all requirements to features.		ALL to FEAT	traceability matrix
Use Cases traced to Features	displays traceability between Use Cases and Features		UC to FEAT	traceability matrix

4. Requirements Change Management

4.1.1 Change Request Processing and Approval

We do not use the Requirements Management Plan to detail Change Management procedures and strategies. For Change Management- we use Rational ClearQuest to track defects and change requests. We plan to integrate RequisitePro with ClearQuest in order to map stakeholder requests to defects and enhancement requests logged in ClearQuest, but primary responsibility for handling change requests rests with the Change Control Manager. The following is a basic description of the change management process. For more information, refer to documentation produced by the Change Control Board, specifically the Change Management Plan.

The change control manager is also responsible for defining the Change Request Management Process, which is documented in the CM Plan.

5. Milestones

5.1.1 Inception

5.1.1.1 Evaluation Criteria

Stakeholder concurrence on scope definition and cost/schedule estimates

· Agreement that the right set of requirements have been captured and that there is a shared understanding of these requirements.

· Agreement that the cost/schedule estimates, priorities, risks, and development process are appropriate.

· All risks have been identified and a mitigation strategy exists for each.

The project may be aborted or considerably re-thought if it fails to reach this milestone.

5.1.1.2 Artifacts

Tasks/Artifacts	Description	Start Date	End Date
Vision Document	This document brings together our business proposal and plan with a dynamic vision of the features we propose to deliver.	20/Oct/2001
Requirements Management Plan	This document sets forth our strategy for managing the project requirements	20/Oct/2001
Use Cases	A series of documents and requirements describing how the system will interact with external entities.	20/Oct/2001
Executable	The first iteration should deliver an executable product for testing.	20/Oct/2001
Cost estimates	Finance should deliver information for cost estimates of requirements.	20/Oct/2001
Priority/difficulty	All requirements should be assigned a priority and difficulty.	20/Oct/2001

5.1.2 Elaboration

At the end of the elaboration phase is the second important project milestone. At this point, you examine the detailed system objectives and scope, the choice of architecture, and the resolution of the major risks.

5.1.2.1 Evaluation Criteria

· The product Vision and requirements are stable.

· The architecture is stable.

· The key approaches to be used in test and evaluation are proven.

· Test and evaluation of executable prototypes have demonstrated that the major risk elements have been addressed and have been credibly resolved.

· The iteration plans for the construction phase are of sufficient detail and fidelity to allow the work to proceed.

· The iteration plans for the construction phase are supported by credible estimates.

· All stakeholders agree that the current vision can be met if the current plan is executed to develop the complete system, in the context of the current architecture.

· Actual resource expenditure versus planned expenditure are acceptable.

The project may be aborted or considerably re-thought if it fails to reach this milestone.

5.1.2.2 Artifacts

Tasks/Artifacts

TBD

Description

Start Date

End Date

5.1.3 Construction

Evaluation Criteria

The evaluation criteria for the construction phase involve the answers to these questions:

· Is this product release stable and mature enough to be deployed in the user community?

· Are all the stakeholders ready for the transition into the user community?

Are actual resource expenditures versus planned still acceptable?

Transition may have to be postponed by one release if the project fails to reach this milestone.

5.1.3.1 Artifacts

Tasks/Artifacts

TBD

Description

Start Date

End Date

5.1.4 Transition

5.1.4.1 Evaluation Criteria

The primary evaluation criteria for the transition phase involve the answers to these questions:

· Is the user satisfied?

· Are actual resources expenditures versus planned expenditures acceptable?

At the Product Release Milestone, the product is in production and the post-release maintenance cycle begins. This may involve starting a new cycle, or some additional maintenance release.

5.1.4.2 Artifacts

Tasks/Artifacts

TBD

Description

Start Date

End Date

6. Training and Resources

All staff will go through training on appropriate software applications, including RequisitePro and ClearQuest. All staff should read and be familiar with the principles of the Rational Software process, as described in the References section of this document.

posted on 2005-11-17 21:02 笨笨阅读(811) 评论(0) 编辑收藏举报