Feel like your requirements aren't working for you? This might be why
Dedicated requirements management tools are available to manage product, user, system requirements for new product introduction projects. These tools can be feature rich and very good, at least within the isolated context for which they were intended. For example, with a dedicated requirement management tool it’s possible to define a hierarchical set of requirements starting with a product concept, through critical-to-quality user needs and down to detailed functional requirements. Another key feature is tracking test cases and interfacing those with the tool, often it’s possible to automate the generation of traceability reports and validation protocols, whose accuracy is paramount.
But our understanding of how to make great products has evolved (in part due to technology and in part from better understanding how processes can best function to produce products optimally aligned to our business plan). Here's the idea: to release and service a new product, there are many processes that must exist and these must work in harmony with one another.
Requirements are essential feed-to and a consumer-of many of the processes that exist within the product lifecycle. A good example is in the case of “Risk Management.” The idea of "Risk Management" as a process to manage outcomes has been around a long time, with formal tools like FMEA being around since the late 1940s (developed by the US military), but surprisingly has only truly been embraced by the Medical Device industry more recently.
Risk and requirements management are tightly coupled. All risks can and should be linked back to one or more requirements. Introducing new requirements generates new risks, and as new risks are discovered new requirements are established. This kind of symbiotic relationship is true for so many pairs of processes required to manage the overall product development process. There are literally hundreds of examples of this (for one customer we counted 1500 potential connect points between all of their business processes that contribute to product development). "Requirements Management" has an unusually high inter-relationship with other processes across the product lifecycle. When considering Integware’s PLM Maturity Model , we count at least 91% or 32/35 potential relationships to other major processes across the product lifecycle (change management, regulatory submissions, product data, validation, complaints management, servicing, supplier quality, the list goes on). We rank the importance of the interfaces into three groups, nine had “critical importance”, 19 had “major importance” and only four were considered to be “light” importance (of reference only).
So, there really can only be one best solution to this problem and that is where the bulk of the product lifecycle processes integrate on top of a single, logical data model. The only systems that provide this level of capability to manage all product development processes and data models, including the actual product data, are enterprise-scale, extensible, PLM platforms.