To recap from part one, the essential attributes (aka metadata) to be associated with a requirement include Requirement ID, Source ID, Requirement Text, Date, Effectivity and Verification Method.
Beyond these essential attributes there are some that I have found to be very desirable, at least in some situations. These highly desirable attributes include:
- Requirement Short Text – An abbreviated text of the requirement can be useful when tracing the requirement, either within the requirement set, or into the design and implementation.
- Type – A code identifying the type of requirement. A common type set is that identified by the acronym FURPS+.
- Functional – includes things like feature set, capabilities and security
- Usability – includes things like human factors, aesthetics, consistency and documentation
- Reliability – includes things like mean time to failure, recoverability from failure, predictability, accuracy and availability
- Performance – includes things like speed, efficiency, through-put, response time
- Supportability – includes things like testability, extensibility, adaptability, maintainability, configurability, installability and localizability
- The plus includes constraints, physical, interface, and implementation requirements
- Risk – this attribute allows you to identify the relative risk level of each requirement. Requirements identified as high-risk should be evaluated for inclusion in the technical performance measures.
- Verification Level – The level at which the requirement will be verified. Some requirements may be evaluated at the component or sub-system level in order to reduce the amount of time and effort in full system evaluation.
There are an additional set of attributes or metadata that might be employed to support metrics collection and analysis.
- Funded – An indication that the requirement was a funded change. It may also be advisable to track the reason for an unfunded change.
- Deleted – Requirements that are deleted are one indication of volatility. While some volatility is expected and may mean increased understanding of the problem, too much volatility may indicate the project is in trouble.
- Modified – a Boolean value that is another indication of volatility.
- Verification Issue – a general category used to track verification problems and concerns.
All of these requirements metadata elements may not apply to your particular system development situation. On the other hand, each of them should be considered for inclusion as you work through the requirements development process. Part three of this series will conclude with some occasionally useful attributes that you may wish to consider.