Example: Extended Requirements Attributes |
This is a more extensive set of attributes than that described in the core set. Many of these attributes are specific to a certain type of requirement, and best used when using a requirements management tool, rather than a manual process.
Relationships
Related Elements | Requirements Requirements Attributes
Description
Main Description | These attributes could be used in addition to the core set of attributes defined in Example: Core Requirements Attributes. Attributes for all requirement types except Stakeholder Needs:
Stability | Likelihood that this requirement will change, due to the stakeholders' or the development teams' understanding of the requirement. Use the range from 1-5, where 1 is very stable and 5 is extremely unstable.
Domain Expert | Person or group to contact if additional detail on the requirement is needed. This will usually also be the reviewer of the requirement.
Obsolete | Requirement is no longer needed. This can be captured as a TRUE or FALSE value. (In order to retain any captured information, it must not be physically deleted)
Target Release | The intended product release in which the requirement will be met (Release1, Release1.1, Release2, and so on).
Attributes for Feature requirement type:
Benefit | The importance of the requirement from the stakeholder's perspective Critical: The requirement has to do with the main tasks of the system, its basic function, or the functions for which it is being developed. If it is missing, the system fails to fulfill its primary mission. It tends to be the most frequently exercised scenarios. Important: The requirement has to do with the support of the system's functions, such as statistical data compilation, report generation, supervision, and functional testing. If it is missing, the system can still (for a while) fulfill its fundamental mission, but with degraded service quality. In modeling, less importance will be attached to these than to critical scenarios. Useful (nice to have): The requirement is a comfort item, not linked to the system's primary mission, but it helps in its use or market positioning.
Attributes for Use Cases and System-Wide requirement types:
Technology Risk | Likelihood of running into serious difficulty implementing the requirement because of lack of experience in the domain or required technologies. This can be captured as the range 1-5, where 1 is low risk and 5 is very high.
Architectural Impact | Indicates that this requirement will impact the software architecture. None: Does not affect the existing architecture. Extends: Requires extending the existing architecture. Modifies: The existing architecture must be changed to accommodate the requirement.
Effort | Estimated effort to implement the requirement. This is measured in the units that the project uses to measure effort (for instance, actual days, ideal days, relative points, and so on).
Rank | The order in which this requirement ranks compared to other requirements of the same type. This ranking is assessed based upon other attribute values. The ranking will determine the order in which it is implemented. This can be captured as a number from 1-10.
Planned Iteration | Number of the iteration within a release that this requirement needs to be implemented in, according to the project plan.
Actual Iteration | Number of the iteration within a release that this requirement was actually implemented in.
Attributes for System Wide requirement type:
Subtype | The category of the requirement, such as Performance, Security, Reliability, and so on.
More Information
Examples | Core Requirements Attributes
© Copyright IBM Corp. 1987, 2009. All Rights Reserved.