Eliciting and managing multiple levels of requirements and specifications are key activities in modern day product development.  This information is an essential part of the overall IP of today’s product, and serves as the knowledge base for tomorrow’s engineers to iterate on today’s design.  And for some, validated requirements serve as proof that engineers did what they said they would do so that no one gets hurt using the product.

In the same way a mathematical formula can be a model for physical reality, requirements can be thought of as a model for a product.  Traditionally, requirements ‘models’ have been strictly textual in nature organized into a series of documents.  Technology for elaborating and storing this information has evolved from the type-written page, to the word processor to the single-purpose requirements software repository.  Requirements management point solutions, like IBM DOORS, have survived up to today because for a long time that is all there was.  

In recent years, many technology standards have been developed to cross-the-chasms with legacy requirement management tooling.  Two prominent examples are OSLC which focuses on linking data, and ReqIF which focuses on synchronizing data. Each of these approaches are good for certain use cases and present challenges for others.  For example, OSLC which defines a set of RESTful interfaces around applications is best used where full time active IT connections can be maintained.  In typical OEM-supplier environments, this is not always the case.  ReqIF uses an XML schema to package sets of documents for transfer to a partner, but process governance must be put in place to ensure that all parties are in sync.

Modern day engineering tools in this area, commonly called Application Lifecycle Management or ALM, have evolved both in breadth of capability and depth of maturity, but this evolution has not come quickly enough for many users.  Users have been clamoring for greater value for a long time; value without incurring additional high cost.
The truth of modern day ALM software is that much of the base capabilities that these tools provide are commoditized and supported by any number of vendor solutions; create, link, edit, etc.  Ovum, in its most recent review of ALM software writes; ‘Organizations are beginning to appreciate that standardizing on a single ALM solution removes tool friction as an impediment to agility, and helps them deliver faster to market.'¹

The real value in today’s ALM solutions are:

• real-time multi-user collaboration to increase productivity
• capabilities for engineering disciplines other than requirements; i.e. planning, systems, mechanical, electronic, testing and ongoing servicing
• surfacing project information to the right people when they need it to reduce status meetings
• automating repetitive tasks when possible to allow engineers to focus on innovation
• getting the solution up and running quickly to receive value as soon as possible

In technical companies today, it is common to find a healthy pressure between IT and engineering.  IT supports engineering, but each new tool is expensive to support with license and ongoing maintenance costs as well as in time training administrators and users.  Over time, upgrading requirements tools becomes a formal IT project because new versions still have to talk to all the other systems in the tool chain.  Engineers, on the other hand, just wants ‘the best tool for the job’ which usually equates to ‘the devil we know’ because they used it on their last project or at their last job.  They may not have liked it much, but they knew how to work with its flaws.

Both Engineering and IT should ask, ‘Are we really happy with our current requirements only point solution?’  ‘Are we getting everything we need from the current tool and vendor?’  ‘Is it time that we really look at stepping up to an industrial strength ALM solution that will give us what we need?’