Requirements Attributes
While each requirement may appear simple in concept, it will naturally have a complex web of relationships with other requirements, and several measurable and enumerable attributes. The following table lists some of these attributes, including basic identification, representative measurements, elements of the surrounding political web, and (suggestive) status in the development lifecycle.
| Attribute | Description | |
|---|---|---|
| Identifier | uniquely identifies a requirement within a repository (or a document) | |
| Category | Policy, Purpose, Improvement, Activity, Feature, Dialog, Component | |
| Description | describes the result to be achieved: | |
| information to be captured or delivered, activity or quality to be improved | ||
| Verification | lists the steps needed to verify that the requirement has been fulfilled | |
| Value | answers why the requirement exists (rationale), indicating: | |
| the need(s) addressed, the benefit(s) offered by addressing the need(s), | ||
| and the ultimate value conferred (esp. if quantifiable as revenues or savings) | ||
| Risks | estimates the impact of failure to deliver: | |
| schedule consequences, financial consequences, | ||
| political consequences, lost opportunity costs, etc. | ||
| Difficulties | considers the likely technical and/or political challenges posed by the requirement, | |
| plus an overall estimate of the level of these challenges, both | ||
| technical: unknown, intractable, hard, moderate, easy, trivial, and | ||
| political: open conflict, irreconcilable differences, negotiable, | ||
| partial agreement, complete agreement | ||
| Effort | estimates of human resources: manpower (man-hour) estimates | |
| Costs | estimates of other resources, esp. if quantifiable as budgets | |
| Stability | estimates the liklihood that the requirement formulation or understanding will change | |
| Priority | often results from a weighted evaluation of the foregoing attributes as ROI | |
| Dependents | identifies which other requirements depend upon this one | |
| Dependencies | identifies the other requirements upon which this one depends | |
| Interests | lists the interested stakeholders along with their interests and concerns | |
| Source | identifies the official source of knowledge regarding this requirement (a person) | |
| Knowledge | indicates the state of knowledge: | |
| identified, formulated, understood, shared, validated | ||
| Status | indicates the lifecycle state of the requirement: | |
| proposed, deferred, cancelled, approved, incorporated, validated | ||
| Dates | discovery date, …, proposal date, …, approval date, …, | |
| incorpoation date, …, release date |
All these attributes contribute information needed to make requirements manageable, especially with a large backlog of incomplete and unfulfilled requirements. Even on relatively small projects and even with ambitions of agile development processes, having adequate information about requirements helps development activities deliver real value and maximize return on investment.
The single most important quality supported by these attributes is consistency. To consistently deliver significant business value entails that requirements be manageable, especially when the solutions must be durable, as when their anticipated product usage lifespan is many years.
Copyright 2003,2020 Nikolas S. Boyd.
Permission is granted to copy this document provided this copyright statement is retained in all copies