advertisement

Managing Requirement With A Rmp

50 %
50 %
advertisement
Information about Managing Requirement With A Rmp

Published on January 3, 2009

Author: baldrick98007

Source: slideshare.net

advertisement

Managing Requirements With A Requirements Management Plan Requirements Discipline June 7, 2009

Precursor In order to understand the material in this course, you should have equivalent knowledge of the following courses: Introduction to RequisitePro, Working with application use cases.

In order to understand the material in this course, you should have equivalent knowledge of the following courses:

Introduction to RequisitePro,

Working with application use cases.

Overview The purpose of this presentation is to: demonstrate how a Requirements Management Plan(RMP) is used to control project requirements. demonstrate how the RMP is realized by managing requirements with RequisitePro. This presentation introduces the reader to the contents of a RMP and then details the contents of each section of the RMP.

The purpose of this presentation is to:

demonstrate how a Requirements Management Plan(RMP) is used to control project requirements.

demonstrate how the RMP is realized by managing requirements with RequisitePro.

This presentation introduces the reader to the contents of a RMP and then details the contents of each section of the RMP.

What Is A Requirement? According to RUP: A specification of an externally observable behavior of the system; for example, inputs to the system, outputs from the system, functions of the system, attributes of the system, or attributes of the system environment.

According to RUP:

A specification of an externally observable behavior of the system; for example, inputs to the system, outputs from the system, functions of the system, attributes of the system, or attributes of the system environment.

What Is The RMP The Requirements Management Plan describes: requirements artifacts, requirement types, requirements attributes, requirements lifecycle, the information to be collected and control mechanisms to be used for measuring, reporting, and controlling changes to the application requirements.

The Requirements Management Plan describes:

requirements artifacts,

requirement types,

requirements attributes,

requirements lifecycle,

the information to be collected and control mechanisms to be used for measuring, reporting, and controlling changes to the application requirements.

The sections Of The RMP Requirements Management Approach Requirement Identifiers Project Lifecycle Requirements Documentation Requirement Types Requirements Attributes Traceability Strategy Requirement Lifecycle Change Control Approach Requirements Management Team Environment And Structure Training Needs

Requirements Management Approach

Requirement Identifiers

Project Lifecycle

Requirements Documentation

Requirement Types

Requirements Attributes

Traceability Strategy

Requirement Lifecycle

Change Control Approach

Requirements Management Team

Environment And Structure

Training Needs

Requirements Management Approach The RMP is designed to allow a systems analyst to customize the requirements elicitation, analysis, documentation, and approval process according to the needs of the project. As the business requirements of the project are approved, they are controlled by a change management process. Application use cases (AUCs) are traced to controlled business requirements. Application requirements are derived from the BUC steps. These are classed as use case requirements or supplementary requirements. Supplemental requirements are constraints upon use case requirements and are traced from all use case requirements that they affect. Other types of requirements include Risks, Change Requests and Issues (these are not requirements as such, but impacts to the use cases that trace from the requirements).

The RMP is designed to allow a systems analyst to customize the requirements elicitation, analysis, documentation, and approval process according to the needs of the project.

As the business requirements of the project are approved, they are controlled by a change management process.

Application use cases (AUCs) are traced to controlled business requirements.

Application requirements are derived from the BUC steps.

These are classed as use case requirements or supplementary requirements.

Supplemental requirements are constraints upon use case requirements and are traced from all use case requirements that they affect.

Other types of requirements include Risks, Change Requests and Issues (these are not requirements as such, but impacts to the use cases that trace from the requirements).

Requirement Identifiers In order to maintain a unique set of requirement identifiers across the project, each requirement type is given a unique 3 letter tag prefix. All requirement identifiers begin with its tag prefix, and then have a unique number assigned. For example, AUC100.

In order to maintain a unique set of requirement identifiers across the project, each requirement type is given a unique 3 letter tag prefix.

All requirement identifiers begin with its tag prefix, and then have a unique number assigned. For example, AUC100.

Project Lifecycle Step 1: The business model is approved and candidate use cases are derived from the BUC steps and tagged as requirements. Step 2: Impacted existing application use cases (AUC) are imported to the project. Step 3: AUCs are baselined and traced to the BUC steps. Step 4: The project is deployed into production, the AUCs are moved to a central repository and the project is made read-only.

Step 1: The business model is approved and candidate use cases are derived from the BUC steps and tagged as requirements.

Step 2: Impacted existing application use cases (AUC) are imported to the project.

Step 3: AUCs are baselined and traced to the BUC steps.

Step 4: The project is deployed into production, the AUCs are moved to a central repository and the project is made read-only.

Requirements Documentation The following documents are used to manage requirements: The RMP - Although it contains no requirements the RMP is made available for viewing from within the Requirements Management Tool(RMT). The Vision document - Although it contains no requirements a project vision document is made available from within the RMT. Application use cases – The AUC is located within a AUC document and may be imported from a a central repository or it may be created within the RMT. Supplementary Specification - A document containing all supplementary requirements, this document is generated as needed.

The following documents are used to manage requirements:

The RMP - Although it contains no requirements the RMP is made available for viewing from within the Requirements Management Tool(RMT).

The Vision document - Although it contains no requirements a project vision document is made available from within the RMT.

Application use cases – The AUC is located within a AUC document and may be imported from a a central repository or it may be created within the RMT.

Supplementary Specification - A document containing all supplementary requirements, this document is generated as needed.

Requirement Types AUC - used to track and manage Application Use Cases. BUC – Contains the steps that the business performs in order to do their job. CRQ – Change request that impacts one or more requirements. CUC – Candidate use case that is a temporary requirement used to track BUC steps that are to be automated. ISS – Issues with requirements that are tracked within the RMT. LNK requirement - allows external documents to be referenced within the RMT via a hyperlink. RSK – Risks with the project; these are not traced to any requirements. SUP - used to track and manage supplementary requirements.

AUC - used to track and manage Application Use Cases.

BUC – Contains the steps that the business performs in order to do their job.

CRQ – Change request that impacts one or more requirements.

CUC – Candidate use case that is a temporary requirement used to track BUC steps that are to be automated.

ISS – Issues with requirements that are tracked within the RMT.

LNK requirement - allows external documents to be referenced within the RMT via a hyperlink.

RSK – Risks with the project; these are not traced to any requirements.

SUP - used to track and manage supplementary requirements.

Requirements Attributes Each requirement type has its own set of attributes. The AUC requirement type comes in 2 parts: The AUC description, is the parent requirement, The AUC step is a child of the AUC.

Each requirement type has its own set of attributes.

The AUC requirement type comes in 2 parts:

The AUC description, is the parent requirement,

The AUC step is a child of the AUC.

Requirement Attributes AUC 1 Assigned To - The analyst responsible for this AUC. Name - The title of the AUC. Text - An overview description of the AUC, or the text of the step. Application - The application impacted by this AUC. Priority – How important is this requirement: None* - Has not been prioritized. High – must have for the project to succeed. Medium – extremely desirable, but the project can be released without it, and the use case added at a later release. Low – Nice to have, can be implemented when all high and medium use cases have been implemented. *The asterisk denotes the default value.

Assigned To - The analyst responsible for this AUC.

Name - The title of the AUC.

Text - An overview description of the AUC, or the text of the step.

Application - The application impacted by this AUC.

Priority – How important is this requirement:

None* - Has not been prioritized.

High – must have for the project to succeed.

Medium – extremely desirable, but the project can be released without it, and the use case added at a later release.

Low – Nice to have, can be implemented when all high and medium use cases have been implemented.

*The asterisk denotes the default value.

Requirement Attributes AUC 2 Status – At what stage of production is this AUC: Defined* – The AUC has been identified as a use case for this project and it has been scoped in the description. Detailed – The AUC has had its steps defined. Implemented – The AUC has been baselined and is in the process of being deployed. Deployed – The AUC has been deployed into production. Deleted – The AUC has been taken out of scope for this project. Difficulty – How hard is it anticipated to implement this AUC: High – This use case contains a lot of new technology. Medium – There is some new technology. Low – We’ve done something similar to this before, almost no new technology. None* - Has not been assigned a difficulty rating.

Status – At what stage of production is this AUC:

Defined* – The AUC has been identified as a use case for this project and it has been scoped in the description.

Detailed – The AUC has had its steps defined.

Implemented – The AUC has been baselined and is in the process of being deployed.

Deployed – The AUC has been deployed into production.

Deleted – The AUC has been taken out of scope for this project.

Difficulty – How hard is it anticipated to implement this AUC:

High – This use case contains a lot of new technology.

Medium – There is some new technology.

Low – We’ve done something similar to this before, almost no new technology.

None* - Has not been assigned a difficulty rating.

Requirement Attributes AUC 3 Risk – The anticipated risk that this requirement cannot be implemented within its allocated time and cost? High – There is a >50% chance that this requirement will adversely affect the project schedule. Medium – There is a 10 to 50 percent chance that this use case will adversely affect the project schedule. Low – There is <10% chance that this requirement will adversely affect the project schedule. None* - Has not been assigned a risk. Significance – How much impact does this requirement have on the system architecture: High – This use case will make significant changes to the original architecture. Medium – There is some change to the existing architecture is anticipated. Low – No significant architectural changes anticipated. None* - Has not been assigned a significance rating.

Risk – The anticipated risk that this requirement cannot be implemented within its allocated time and cost?

High – There is a >50% chance that this requirement will adversely affect the project schedule.

Medium – There is a 10 to 50 percent chance that this use case will adversely affect the project schedule.

Low – There is <10% chance that this requirement will adversely affect the project schedule.

None* - Has not been assigned a risk.

Significance – How much impact does this requirement have on the system architecture:

High – This use case will make significant changes to the original architecture.

Medium – There is some change to the existing architecture is anticipated.

Low – No significant architectural changes anticipated.

None* - Has not been assigned a significance rating.

BUC Step Attributes 1 The business requirements are the steps of the BUC. Priority – How important is this requirement: None* - Has not been prioritized. High – Must have for the project to succeed. Medium – Extremely desirable, but the project can be released without it, and the use case added at a later release. Low – Nice to have, can be implemented when all high and medium use cases have been implemented. Origin – Where the business requirement originated: Product Management, Customers, Partners, Technical, Support, Sales, Marketing, Development, Technical Writers, Test, Unknown. SME contact – Who in the business to see with questions about this step of the BUC.

The business requirements are the steps of the BUC.

Priority – How important is this requirement:

None* - Has not been prioritized.

High – Must have for the project to succeed.

Medium – Extremely desirable, but the project can be released without it, and the use case added at a later release.

Low – Nice to have, can be implemented when all high and medium use cases have been implemented.

Origin – Where the business requirement originated:

Product Management, Customers, Partners, Technical, Support, Sales, Marketing, Development, Technical Writers, Test, Unknown.

SME contact – Who in the business to see with questions about this step of the BUC.

BUC Step Attributes 2 Stability – How sure are we that this step will not change prior to being implemented. None* - Has not been assessed for stability. High – Expect it to change > 50%. Medium – Less than 50%, but more 10% chance of change. Low – Unlikely to change <10%. Status- Indicates the state of defining the BUC step: Defined* – The step has been identified. Approved – The BUC has been approved. Deleted – The step is no longer part of the BUC. Implemented – The step has been automated. Assigned To – Who is the responsible business process analyst for this BUC. Automated – Whether this step is going to be implemented by a system: True – Yes, it is being implemented by this project. False* – Not in this project.

Stability – How sure are we that this step will not change prior to being implemented.

None* - Has not been assessed for stability.

High – Expect it to change > 50%.

Medium – Less than 50%, but more 10% chance of change.

Low – Unlikely to change <10%.

Status- Indicates the state of defining the BUC step:

Defined* – The step has been identified.

Approved – The BUC has been approved.

Deleted – The step is no longer part of the BUC.

Implemented – The step has been automated.

Assigned To – Who is the responsible business process analyst for this BUC.

Automated – Whether this step is going to be implemented by a system:

True – Yes, it is being implemented by this project.

False* – Not in this project.

Requirement Attributes CUC Status – The state of the candidate use case. Working* – Being incorporated into an AUC, Incorporated – Has been mapped to a use case. Assigned To – The person responsible for incorporating this CUC.

Status – The state of the candidate use case.

Working* – Being incorporated into an AUC,

Incorporated – Has been mapped to a use case.

Assigned To – The person responsible for incorporating this CUC.

Requirement Attributes SUP 1 Name - A brief description of the SUP requirement. Text - The requirement text. Difficulty – how much risk there is that the requirement will impact the project schedule: High – this is new technology, Medium – there is some new technology and some existing, Low – nothing new here. None* - Has not been assigned a difficulty rating. Cost – total number of hours required to implement this requirement.

Name - A brief description of the SUP requirement.

Text - The requirement text.

Difficulty – how much risk there is that the requirement will impact the project schedule:

High – this is new technology,

Medium – there is some new technology and some existing,

Low – nothing new here.

None* - Has not been assigned a difficulty rating.

Cost – total number of hours required to implement this requirement.

Requirement Attributes SUP 2 Status – The state of the requirement : Defined* – The supplementary requirement has been identified as a for this project. Implemented – The SUP requirement has been baselined and is in the process of being deployed. Deployed – The supplementary requirement has been deployed into production. Deleted – The AUC has been taken out of scope for this project. Category – The type of supplementary requirement. Types are; Usability, Reliability, Performance, Supportability, Design Constraint, Accessibility, Globalization, Availability, Installability, Servicability (Maintainability), Security, (Vulnerability), User Documentation, Consumability (Migration), Integration, Software Reuse/Componentization, Purchased Components, Interfaces, Licensing Requirements, Legal/Copyright/Other Notices, Applicable Standards, To be determined*.

Status – The state of the requirement :

Defined* – The supplementary requirement has been identified as a for this project.

Implemented – The SUP requirement has been baselined and is in the process of being deployed.

Deployed – The supplementary requirement has been deployed into production.

Deleted – The AUC has been taken out of scope for this project.

Category – The type of supplementary requirement. Types are;

Usability, Reliability, Performance, Supportability, Design Constraint, Accessibility, Globalization, Availability, Installability, Servicability (Maintainability), Security, (Vulnerability), User Documentation, Consumability (Migration), Integration, Software Reuse/Componentization, Purchased Components, Interfaces, Licensing Requirements, Legal/Copyright/Other Notices, Applicable Standards, To be determined*.

Requirement Attributes Other Change Request, Risk and Issue, take the following attributes: Name – A brief description of the item. Text – A detailed description of the item. Status – Whether the item is open or closed (or realized in the case of a Risk). Assigned To – Who is responsible for this item. Responsible – Who raised this item. Cost – How much project time is impacted by this item. Priority – A n integer value that allows these items to be ranked in order of importance. (The following are Risk attributes only.) Probability – The probability that the risk will be realized, is a % value between 1 and 100. Impact – Indicates how much of the project will be affected as a result of the risk being realized, and is a % between 1 and 100

Change Request, Risk and Issue, take the following attributes:

Name – A brief description of the item.

Text – A detailed description of the item.

Status – Whether the item is open or closed (or realized in the case of a Risk).

Assigned To – Who is responsible for this item.

Responsible – Who raised this item.

Cost – How much project time is impacted by this item.

Priority – A n integer value that allows these items to be ranked in order of importance.

(The following are Risk attributes only.)

Probability – The probability that the risk will be realized, is a % value between 1 and 100.

Impact – Indicates how much of the project will be affected as a result of the risk being realized, and is a % between 1 and 100

Link Attributes This requirement type allows you to link external documents, or other types of file, to requirements. It’s attributes are: Name - The name of the external document. Text – A descriptive overview of the document. Document - Hyperlink to the file.

This requirement type allows you to link external documents, or other types of file, to requirements. It’s attributes are:

Name - The name of the external document.

Text – A descriptive overview of the document.

Document - Hyperlink to the file.

Traceability Strategy Diagram 1 .. * - one to many, * - 0 to many, 1 – exactly one,

Traceability Strategy An application use cases traces from 1 or more BUC steps. A BUC step traces to 0 or more AUCs. A CUC is derived from 1 or more BUC steps. A BUC step may derive several CUCs. An AUC comes from 0 or more CUCs. CUCs make up part of 1 AUC. An AUC contains 1 or more AUCSteps. An AUCStep must be contained within a AUC. A supplementary requirement impacts 1 or more AUCs. An AUC may be impacted by several supplementary requirements. The CRQ, ISS and RSK are all forms of Item that concern 1 or more AUCs. AUCs may be impacted by several of these Items. A test case traces from at least 1 AUCStep. AUCSteps may trace to several test cases.

An application use cases traces from 1 or more BUC steps. A BUC step traces to 0 or more AUCs.

A CUC is derived from 1 or more BUC steps. A BUC step may derive several CUCs.

An AUC comes from 0 or more CUCs. CUCs make up part of 1 AUC.

An AUC contains 1 or more AUCSteps. An AUCStep must be contained within a AUC.

A supplementary requirement impacts 1 or more AUCs. An AUC may be impacted by several supplementary requirements.

The CRQ, ISS and RSK are all forms of Item that concern 1 or more AUCs. AUCs may be impacted by several of these Items.

A test case traces from at least 1 AUCStep. AUCSteps may trace to several test cases.

Requirement Lifecycle AUC

Requirement Lifecycle States AUC AUCs lifecycle comprises the following states: Initially the AUC does not exist within the scope of the project. A potential AUC is identified from the list of CUCs and its status is set to ‘Defined’. The AUC is verified as a real use case for the project and has detail added, and its status is set to ‘Detailed’. The AUC is baselined and its status set to ‘Implemented’. The AUC is deployed into production and its status is set to ‘Deployed’. The AUC is now moved into the central repository for its application. At steps 1, 2 or 3 the AUC may be taken out of scope of the project and its status is set to ‘Deleted’. At step 3, if the AUC changes any of its attributes its status is set to ‘Detailed’ and must be baselined again.

AUCs lifecycle comprises the following states:

Initially the AUC does not exist within the scope of the project.

A potential AUC is identified from the list of CUCs and its status is set to ‘Defined’.

The AUC is verified as a real use case for the project and has detail added, and its status is set to ‘Detailed’.

The AUC is baselined and its status set to ‘Implemented’.

The AUC is deployed into production and its status is set to ‘Deployed’. The AUC is now moved into the central repository for its application.

At steps 1, 2 or 3 the AUC may be taken out of scope of the project and its status is set to ‘Deleted’.

At step 3, if the AUC changes any of its attributes its status is set to ‘Detailed’ and must be baselined again.

Requirement Lifecycle SUP

Requirement Lifecycle States SUP The SUP lifecycle is a little simpler than that of the AUC. It’s lifecycle comprises the following states: Initially the SUP does not exist within the scope of the project. A SUP is proposed its status is set to ‘Proposed’. If any AUC that the SUP traces from becomes baselined, the SUP must have its status set to and its status set to ‘Baselined’. When all AUCs that the SUP traces from are deployed into production its status is set to ‘Deployed’. The SUP is now moved into the central repository for its application. At steps 1 or 2 the SUP may be taken out of scope of the project and its status is set to ‘Deleted’. At step 2, if the SUP changes any of its attributes its status is set to ‘Proposed’ and all AUCs that it traces from must be investigated for impacts and baselined again.

The SUP lifecycle is a little simpler than that of the AUC. It’s lifecycle comprises the following states:

Initially the SUP does not exist within the scope of the project.

A SUP is proposed its status is set to ‘Proposed’.

If any AUC that the SUP traces from becomes baselined, the SUP must have its status set to and its status set to ‘Baselined’.

When all AUCs that the SUP traces from are deployed into production its status is set to ‘Deployed’. The SUP is now moved into the central repository for its application.

At steps 1 or 2 the SUP may be taken out of scope of the project and its status is set to ‘Deleted’.

At step 2, if the SUP changes any of its attributes its status is set to ‘Proposed’ and all AUCs that it traces from must be investigated for impacts and baselined again.

Requirement Lifecycle BUC Step The BUC step state transitions are: Initially the step has not been identified as part of the BUC. Once the BA identifies that the step exists, it is added to the BUC. After the BUC has been successfully reviewed the step becomes approved. Finally, the step may be implemented into a production system and the step ends its lifecycle. At any time the step may be removed from the BUC and its stat6us is set to deleted.

The BUC step state transitions are:

Initially the step has not been identified as part of the BUC.

Once the BA identifies that the step exists, it is added to the BUC.

After the BUC has been successfully reviewed the step becomes approved.

Finally, the step may be implemented into a production system and the step ends its lifecycle.

At any time the step may be removed from the BUC and its stat6us is set to deleted.

Requirement Lifecycle CUC The CUC simply exists to link the BUC step to the AUC. When a BUC Step has been identified as to be automated a CUC is created in a working state. Once the CUC has been incorporated into an AUC it is finalized.

The CUC simply exists to link the BUC step to the AUC.

When a BUC Step has been identified as to be automated a CUC is created in a working state.

Once the CUC has been incorporated into an AUC it is finalized.

Change Control Approach Once a requirement has been baselined the requirement must not be edited. (If it is edited any traceability links will become broken.) In order to edit a baselined requirement, its status is set back to the previous state. A requirement may be taken out of scope for the project anytime prior to it being deployed by setting its status to ‘Deleted’. A deployed requirement may not be edited. To change a deployed requirement a copy must be made and worked on in a new project.

Once a requirement has been baselined the requirement must not be edited. (If it is edited any traceability links will become broken.)

In order to edit a baselined requirement, its status is set back to the previous state.

A requirement may be taken out of scope for the project anytime prior to it being deployed by setting its status to ‘Deleted’.

A deployed requirement may not be edited. To change a deployed requirement a copy must be made and worked on in a new project.

Requirements Management Team This section lists roles of the people involved with managing requirements: Lead systems and process analyst – this is a one person team.

This section lists roles of the people involved with managing requirements:

Lead systems and process analyst – this is a one person team.

Environment And Structure Windows XP Professional on my home PC.

Windows XP Professional on my home PC.

Training Needs None. I already know it all ;-)

None. I already know it all ;-)

Test Your Knowledge Name 3 attributes of the AUC requirement type. Name 3 types of supplementary requirement. What is the state of an AUC requirement between Proposed and Implemented? When is the SUP requirement baselined. How do you take a requirement out of scope? What attributes are populated in the AUC step requirement?

Name 3 attributes of the AUC requirement type.

Name 3 types of supplementary requirement.

What is the state of an AUC requirement between Proposed and Implemented?

When is the SUP requirement baselined.

How do you take a requirement out of scope?

What attributes are populated in the AUC step requirement?

End of Part 1 Example Requirements Management Plan The Managing Requirements With ReqPro demonstrates how the RMP is realized by a RMT.

Example Requirements Management Plan

The Managing Requirements With ReqPro demonstrates how the RMP is realized by a RMT.

Add a comment

Related pages

Managing Requirements and improving quality - TraceCloud

[MANAGING REQUIREMENTS AND IMPROVING QUALITY] March 1, ... Requirement Types ... (RMP) can help in getting ...
Read more

European Medicines Agency - - Risk-management plans

whenever the risk-management system is modified, ... Draft guidance on format of the risk management plan (RMP) in the EU – in integrated format
Read more

Cybersecurity Risk Management Process (RMP) | Department ...

The electricity subsector cybersecurity Risk Management Process (RMP) ... The RMP is built on the premise that managing cybersecurity risk is critical to ...
Read more

Business Analyst | Requirements Management 101

The requirements management plan (RMP) describes how the business analysis work will be completed. ... In order for a requirement to be worth managing, ...
Read more

Requirements Management, Requirements - Business Analysts

What is Requirements Management? Requirements Management is an iterative set of activities that help ... (RMP) RMP Contents. The ... Managing requirement ...
Read more

Project Management | Requirements Management 101

The requirements management plan (RMP) describes how the business analysis work will be completed. ... In order for a requirement to be worth managing, ...
Read more

Requirements Management Plan Template - jiludwig.com

Visit the requirements management website at: ... Requirement Report Examples. 6. E. ... maintaining, and managing requirements. Discuss inputs, processes, ...
Read more

Project Management Professional Certification | PMP

PMI Risk Management Professional (PMI-RMP) ...
Read more

Guidelines: Requirements Management Plan - UHCL

Guidelines: Requirements Management Plan ... the white paper Traceability Strategies for Managing Requirements ... requirement attributes which have ...
Read more