The first step in the development of any new product is defining the requirements for the product. The initial definition typically comes from product management, marketing or the company’s designated visionary. Initial requirements often consist of a list of specific new features, functions, performance, and cost. The list may include new and revolutionary ideas but, more often than not, simply consists of comparative references, e.g. faster than X, better than Y, less expensive than Z, etc. Also common are ‘inverse’ requirements, “none of the problems or issues of product X, Y or Z”. Naturally, everyone ‘knows’ that the list is not comprehensive and does not include ‘all’ of the requirements. The tacit assumption is that the new product will automatically inherit all of the ‘good’ characteristics of its predecessor/competitor and none of the ‘bad’ ones.
While the list is not a bad place to start, it is all too common for this list to be the ending place as well. After the development team marks up the list, the requirements exercise often concludes with relatively little discussion or incremental substance or clarity. When described in this manner, it is obvious that the subsequent product development effort is destined to fail, or at best, produce another small evolutionary step after experiencing numerous changes, delays, and budget overruns. Despite the knowledge and experience of the development team, new product success is based on a common, shared product vision. The only way to establish and share that vision is to clearly articulate and document the new product before actual design work begins. This is the primary reason for generating and maintaining a comprehensive Requirements Document.
This requirements document template provides a framework that the product development team can use to achieve a single shared vision of what the product should be.