Have all the necessary attirbutes been defined?
Is it clear who is responsible for updating requirements attributes?
Without a clear understanding of the importance of the requirements attributes, project team members can either
neglect to update them, or update them in an incomplete way. Anyone with responsibility for managing requirements must be
given brief background information or training to be able to set the values in a meaningful way, and must agree to ensure
that the attributes are properly populated. |
Will the attribute usually be used to research, track, or manage requirements, or to select a subset of requirements?
Avoid attributes that convey information with limited or no value to the project team. If little value can be discerned
in the attribute, then do not include it.
|
Will the attribute value not be set to the default value most of the time?
Attributes that will usually be set to the default value generally can be avoided, because they increase requirements
management without providing much value. |
Is the attribute recorded in only one place?
There is also the potential to duplicate tracking that occurs elsewhere. For example, keeping the planned iteration as a
requirements attribute might duplicate information that is kept in project plans. Remove the duplication, or leverage
some higher-level traceability to ensure that someone will be aware that changes to the attribute need to be propagated to
that higher-level traceability. |
|