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 may 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 it should probably not be included.
|
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 should generally 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 may 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. |
|