So you have created a top notch requirements traceability matrix (RTM) and the business/stakeholder/solution hierarchy is a thing of beauty. When you do your structured walkthroughs with key stakeholders, they praise your efforts and discuss how you should be nominated for employee of the month. It passes through the approval processes without a hitch and is formally passed to the design/development teams.
Later that same day you get an email from the lead of the design/development team and it is titled "About XYZ RTM". You expect it to include additional praise regarding your brilliance but it contains something completely different.
I've received this RTM document today regarding the ABC Project. I'm not sure what it is or what I'm supposed to do with it. It has a few things we can use but most of it is too vague to be helpful to the design teams. Is this all you have in regards to requirements documentation?"
Even to this day, many developers get software projects thrown over the wall to them without any real requirements or the requirements are in a format they cannot really use. Requirements by nature should focus on the "what" and not the "how". But there is a middle ground between the "what" and "how" called the specification. In its most basic form, the specification should contain vital characteristic and constraint information that influence the ”how" decisions.
This document is often called a Software Requirements Specification (SRS) and is a companion document to a Business Requirement Document (BRD) and/or Requirements Traceability Matrix (RTM). As with most project documentation, this document can be called many other things. I've also seen cases where the document doesn't actually exist but the specifications it normally would communicate are found within design documentation. The lines can get a little blurry in regards to if a specification is part of the requirements process or the design process. As trivial as that might sound, some organizations care about the difference quite a bit. The most classic case is when one vendor has a contract for the requirements and another vendor has a contract for designs.
However, (IMHO) specifications related to specific functional requirements should be handled by the requirement professionals. So in the example above, the development teams tend to focus on solution requirements and most of that attention goes to the functional requirements. So a very basic SRS should list the functional requirements that need specification elaboration and then provide that elaboration. I would recommend working with the consumers of that documentation as you craft it. Yes, that means working with the developers and designers before you hand the ball over to them.
©2015 Dwayne Wright