Requirements Metadata Attributes – part 1

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

Date

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

Effectivity/Release

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

Verification

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

Analysis

Inspection

Demonstration

Test

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?