In part 1 of this series I laid out the requirements metadata attributes that I believe are essential. In part two I listed the metadata attributes that I have found to be very desirable. In this final part of the series I list some metadata attributes that I have found to be useful for some projects.
• Assigned to – The name or initials of the systems engineer or organization responsible for that requirement. In small organizations where the requirements team is geographically co-located this would probably not be useful. In those cases where multiple teams, including teams composed of different companies, are responsible for requirements development it is often useful to be able to quickly identify the responsible party.
• Allocation – If you are using Model-Based Systems or Software Engineering tools and processes, your requirements traceability to design and implementation will be done using a combination of requirements management and UML/SysML/other modeling tools. Sometimes it is useful to trace allocation to elements in a development framework that may span multiple tools, and having a metadata attribute to capture that allocation is the best way to do that.
• COTS/GOTS – For a requirement that has been allocated to an off-the-shelf component you should capture the name or category of the product used to satisfy the requirement. This information should be as detailed as possible (e.g version, edition, component feature, etc.).
• Status – Especially for large requirements sets where changes are governed by regulation or contract, it may be necessary to track the requirement status. The kinds of things you might want to know are
• A – Accepted as written
• B – Accepted with minor change
• C – Accepted with major change
• D – rejected as impractical/impossible/unnecessary
• Category – It is sometimes useful to capture requirement categories. These categorizations typically depend on customer/program need. These categories are different than the quality attributes identified in the desirable set as “Type.”
• Priority – Lately I have been rethinking the allocation of priority to the sometimes useful set. Being able to prioritize a requirement is a direct reflection of the system engineers understanding of the problem and the stakeholder needs. While some customers adopt the attitude that all of their requirements are equally important, it is usually necessary to come to agreement on which requirements/features are the most important so we have a good starting point and way to identify what to work on next.
• Difficulty of Analysis – Some requirements need a significant effort to analyze. This might be because implementation involves the use of new materials or new working environments (think about the different between in and out of the atmosphere). Progress reports based on level of difficulty are appropriate for these type of requirements.
• Comments/Notes/Pointers – What does the rest of the team need to know that isn’t explicitly covered? What might be important for you to remember two years from now when you are working on version 3?
• Special Handling – You have a requirements development and management process that everyone knows and can reference. What falls outside of that normal process with respect to this one requirement? For example, do we need to double-check a second source?
You should not consider this list as gospel, but it is a good way to start. If you identify a requirements metadata attribute that you find necessary or useful and it’s not on this list, then don’t hesitate to use it. If you can, I’d appreciate if you would let me know what it is, so I can add it to my list.