Ejemplo de Plan de Requerimientos

A
P P E N D I X
Sample
Requirements
Management Plan
1
1.1
Introduction
Purpose
This document describes the guidelines used by the project to establish the requirement
documents, requirement types, and requirement attributes. It also describes traceability
between various requirement types that will be maintained during the project lifecycle. It
serves as the conguration document for the RequisitePro tool. The objective of requirements traceability is to reduce the number of defects found late in the development cycle.
Ensuring that all product requirements are captured in the software requirements, design,
and test cases improves the products quality.
1.2
Scope
This plan pertains to all phases of the project.
1.3
Overview
Paragraph 2 describes tools that will be used for requirements management.
Paragraph 3.1 describes traceability items and denes how they are to be named, marked,
and numbered.
Paragraph 3.2 describes requirement types used as traceability items.
Paragraph 3.3 describes traceabilitywhich requirement elements trace to another type of
requirement.
Paragraph 3.4 describes suggested attributes for each type of requirement.
319
320
Appendix
Sample Requirements Management Plan
Tools, Environment, and Infrastructure

RequisitePro will be used to manage requirements. Requirement attributes and traceability
will be stored in a RequisitePro database. Team members who do not have access to
RequisitePro will use Microsoft Word. Some diagrams will be created in Rational Rose and
incorporated into RequisitePro documents.
3
3.1
Documents and Requirement Types

Documents
The following documents will be created in the project.
Document Type
Description
Default Requirement Type
Stakeholder Requests (STR)
Key requests from

stakeholders.
Stakeholder Request (STRQ)
Vision (VIS)
Overall system description

and specic requirements.
Feature (FEAT)
Use Case Specication (UCS)
Use case description.
Use Case (UC)
Glossary (GLS)
Use to capture common

vocabulary.
Glossary Item (TERM)
Supplementary
Specication (SS)
Nonfunctional
specications.
Supplementary Requirements (SUPL)
Requirements Management
Plan (RMP)
This document.
No requirements
3.2
Requirement Types
This paragraph describes traceability items and denes how they are to be named, marked,
and numbered. A traceability item is any project element that needs to be explicitly traced
from another textual or model item to keep track of the dependencies between them. In
RequisitePro, traceability items are represented by an instance of a RequisitePro requirement type. The following table describes all the requirement types used in the project.
321
Traceability Item
(Requirement Type)
Artifact
(Document Type)
Stakeholder Request (STRQ)
Vision (STR)
Key stakeholder and user needs. They

describe high-level requirements.
Feature (FEAT)
Vision (VIS)
The systems conditions and capabilities.
Use Case (UC)
Use Case (UC)

documents
Use cases capturing all the systems

functional requirements.
Supplementary Requirement
(SUPL)
Supplementary
Specication (SS)
Nonfunctional requirements that are not

captured in the use case model.
3.3
Description
Traceability
Figure A.1 shows the traceability structure used in the project.
STRQ
FEAT
UC
Figure A.1
SUPL
Traceability diagram.
Stakeholder Requests (STRQ) will be traced to Features (FEAT) dened in the Vision
document and Supplementary Requirements dened in the Supplementary Specication.
There may be a many-to-many relationship between STRQ and FEAT, but usually it is
one Stakeholder Request to many Features. Every approved Request must trace to at
least one Feature or Supplementary Requirement.
Feature Requirements (FEAT) (dened in the Vision document) will be traced to either a
Use Case or Supplementary Requirement. Every approved feature must trace to at least
one Use Case or Supplementary Requirement. There may be many-to-many relationships between Features and Use Cases and Supplementary Requirements.
322
Appendix
Use Case Requirements (UC) dened in the Use Case Specications will be traced back
to Features.
Supplementary Requirements (SUPL) will be traced back to Features.
3.4
3.4.1
Requirements Attributes
Attributes for FEAT
Status
Tracks the progress of the requirement development from initial drafting through nal
validation.
Attribute Value
Description
Proposed
Describes features that are under discussion, but have not yet been reviewed and
accepted.
Approved
Features approved for further design and implementation.
Realized
The feature is incorporated into the design. Rational Rose diagrams reect this
feature.
Incorporated
The feature is incorporated into the product.
Validated
The feature is tested and checked to see that it works correctly.
Priority
Determines the requirements priority to assign appropriate development resources.
Attribute Value
Description
High
High priority.
Medium
Medium priority.
Low
Low priority. Implementation of this feature is less critical and may be

rescheduled for subsequent iterations or releases.
323
Benet
Benet and importance of the requirement to the end users and customers.
Attribute Value
Description
Critical
Essential features. Failure to implement them means that the system will not meet
customer needs. All critical features must be implemented in the release, or the
schedule will slip.
Important
Features important to the systems effectiveness and efciency for most applications. The functionality cannot easily be provided in some other way.
Useful
Features that will be used less frequently, or for reasonably efcient workarounds
that can be achieved. No signicant revenue or customer satisfaction impact can
be expected if such an item is not included in a release.
Effort
Set by the development team. Should be expressed in the total number of persons working
times the amount of days it will take.
Risk
The probability that implementing the requirement will cause undesirable events, such as
effort overruns, design aws, a high number of defects, poor quality, and poor performance.
It is enough to categorize the technical risks of each use case as high, medium, or low.
Attribute Value
Description
High
The impact of the risk combined with the probability of the risk occurring is high.
Medium
The impact of the risk is less severe, and the probability of the risk occurring is
smaller.
Low
The impact of the risk is minimal, and the probability of the risk occurring is low.
Stability
Probability that the feature will change or that the teams understanding of the feature will
change. Used to help establish development priorities and determine items for which additional elicitation is required.
Target Release
A target release may be expressed as the name of an iteration, in which the feature will be
incorporated into the product.
324
Appendix
Assigned To
Features may be assigned to the people responsible for further elicitation, writing the software requirements and implementation.
Reason
This text eld is used to track the source of the requested feature. Requirements exist for
specic reasons. This eld records an explanation or a reference to an explanation.
3.4.2
Attributes for STRQ

The same as for FEAT, except for Target Release:
Status
Priority
Benet
Effort
Risk
Stability
Reason
3.4.3
Attributes for UC
The same as for FEAT. In addition, there is an Actor attribute.
Actor
Describes which actor initiates this use case.
Other attributes are the same as for FEAT:
Status
Priority
Benet
Effort
Risk
Stability
Target Release
Reason
3.4.4
Attributes for SUPL

The same as for FEAT:
Status
Priority
Benet
Effort
Risk
Stability
Target Release
Reason
3.5
Reports and Measures

The views will be created to provide the following reports:
Attribute Matrices showing all requirements of the specic type:
All Stakeholder Requests
All Features
All Supplementary Requirements
All Use Cases
Traceability Matrices:
Traceability of STRQ to FEAT
Traceability of FEAT to US
Traceability of FEAT to SUPL
All STRQ not traced to FEAT
All FEAT not traced to US or SUPL
All FEAT not traced from STRQ
All UC not traced from FEAT
All SUPL not traced from FEAT
Traceability Trees:
Traceability Tree traced from STRQ
Traceability Tree traced to UC
Traceability Tree traced to SUPL
325

Ejemplo de Plan de Requerimientos

Uploaded by

Copyright:

Available Formats

Ejemplo de Plan de Requerimientos

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ejemplo de Plan de Requerimientos

Uploaded by

Copyright:

Available Formats

A

Sample Requirements Management Plan

Tools, Environment, and Infrastructure

Documents and Requirement Types

Default Requirement Type

Stakeholder Requests (STR)

Key requests from

Stakeholder Request (STRQ)

Overall system description

Use Case Specication (UCS)

Use case description.

Use Case (UC)

Use to capture common

Glossary Item (TERM)

Supplementary Requirements (SUPL)

Documents and Requirement Types

Stakeholder Request (STRQ)

Key stakeholder and user needs. They

The systems conditions and capabilities.

Use Case (UC)

Use Case (UC)

Use cases capturing all the systems

Nonfunctional requirements that are not

Sample Requirements Management Plan

Features approved for further design and implementation.

The feature is incorporated into the product.

The feature is tested and checked to see that it works correctly.

Low priority. Implementation of this feature is less critical and may be

Documents and Requirement Types

Sample Requirements Management Plan

Attributes for STRQ

Documents and Requirement Types

Attributes for SUPL

Reports and Measures

You might also like