Agile Zone is brought to you in partnership with:

J.d. is a DZone MVB and is not an employee of DZone and has posted 2 posts at DZone. View Full User Profile

Requirements Metadata Attributes – part 1

  • submit to reddit

Recently I was asked to provide a suggested list of requirements management attributes (aka metadata) for a client.  I immediately went to my relatively new laptop and searched for the list that I had built over the last few years.  I couldn’t find it, so I went to option 2 – search engines.  I used Google, Yahoo and Bing to search for “requirements attributes” “requirements metadata” and several other related phrases.  I got one relevant hit from a US Department of Transportation project (  All of the rest were either addressing the goodness of a requirement (e.g. atomic, verifiable, unique, etc.) or were too vague to be of use.  So it was off to reproduce the list from memory.  I then decided to publish these in the hopes that the next time someone searches for requirements attributes or requirements metadata or even requirements characterization that they find this list and it helps them with their requirements management problem.

I’ll break the list into three parts.  First will be the essential requirements attributes.  These are the requirements attributes that I find I need regardless of the domain or project.

Essential Attributes:

Requirement ID

– A unique Identifier for each requirement so that they can be referred to unambiguously.  I suggest that this be an identifier that is under the users control, rather than the one that is automatically assigned by a requirements management tool.  Being able to control the ID facilitates reusing and merging of requirements modules.

Source ID

– A cross-reference to the stakeholder requirements document to facilitate tracing.  This essential requirements attribute does not have to be a field in the requirements management tool.  Indeed I think it is preferable for it to be an automated link such as one can implement in a requirements management tool or a SysML modeling tool.

Requirement Text

– The text statement of the requirement should be a well-formed statement.  Karl Weigers has a good article on writing a high quality requirement at


– Not all requirements are received, decomposed, or derived at the same time in the project lifecycle.  This field allows the systems engineer to do time-based analysis.


– A program-specific designation for the release or iteration in which the satisfaction of requirement will be delivered.


– Verification methods should be defined as separate attributes.  Many requirements are verified using multiple techniques, so a boolean value for each of the verification types can capture that relationship.  The traditional verification methods are,





Start with these attributes.  Once you have them in place you should have an infrastructure for adding more requirements attributes when you are ready.

I’d like to know what you think of this initial list.  Do you have any other requirement attributes that you find essential?  How about some suggestions for the next list – the highly desirable attributes?

Published at DZone with permission of J.d. Baker, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Matthew Greenfield replied on Thu, 2011/01/13 - 1:14pm

How about "Priority"? Some "requirements", after dealing with other requirements in the system, seem to be not as "required" as originally thought. Adding a priority establishes whether or not something NEEDS to be done or COULD be done by the release.

Ellen Gottesdiener replied on Thu, 2011/01/13 - 3:08pm

and "Justification" or "Business Value" ~ ellen

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.