Over a million developers have joined DZone.

Requirements Metadata Attributes – part 1

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

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 (http://www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE/14424_files/appendix_b.htm).  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 http://www.processimpact.com/articles/qualreqs.html


– 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?

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of J.d. Baker, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}