Main Description |
These attributes should 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 should 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 should 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.
|
|