设为首页 收藏本站
查看: 1058|回复: 0

[经验分享] Requirements Management Plan From IBM RequisitePro Sample

[复制链接]

尚未签到

发表于 2015-10-6 03:50:27 | 显示全部楼层 |阅读模式
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.
Rational Unified Process®, Version 2002.05.00. Copyright © 1987 – 2001. 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

[tr][td=1,1,0][tr][td=1,1,0][tr][td=1,1,0][tr][td=1,1,0]
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.

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-123084-1-1.html 上篇帖子: Java Web 服务: Axis2 WS-Security 签名和加密(转IBM) 下篇帖子: IBM发布AppScan Source 8.7:减少iOS企业级应用安全风险
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表