Trend 5: Tooling

What’s the best tool to manage requirements? In every training, this question pops up. To answer it, you would have to know the bells and whistles of all requirements management tools, including the latest updates. At the same time, you need a good understanding of the business environment where you want to deploy the tool. I can be brief: this is a well-nigh impossible task.

But not to worry, it is quite possible to give it a try. It’s useful to do so based on the type of business. For example, an organization like ASML isn’t required to adhere to international safety standards, information security or FDA regulations. In such cases, even Word or Excel can suffice to manage things – surprisingly, this is often preferred.

Once standards and regulations apply, the software has to support audit trails. That means providing configuration management functionality such as version control, change control and status accounting. It may sound odd, but many RM tools don’t offer these basic functions.

Another distinguishing feature is the baseline. In its most elementary form, this is a snapshot of the requirements database, which contains a subset of requirements. More sophisticated tools provide workflows to select specific requirements with specific characteristics from the database. Such a baseline can be reviewed, modified, approved and released as a separate entity in the tool. Once released, the content of the baseline can’t be changed.

In some industries, such as automotive, exchanging baselines between OEMs and suppliers has been standard operating procedure for several decades (better known as the Lastenheft-Pflichtenheft information exchange). However, baselines are also very useful internally. They bring rest and stability to an environment characterized by frequently changing requirements in multidisciplinary product development.

Decoupling different dynamics with baselines can be very effective. This is also the basis of my earlier comment about Word and Excel. These tools, with their relatively slow pace of change, can dictate an appropriate heartbeat for deploying change in the development organization. Think of a rapidly changing agile way of working with bi-weekly sprints and a long lead time with quarterly updates and annual releases.

A strong argument for using RM tools is support for traceability. Most tool vendors advertise their products as being capable of linking requirements to other requirements. As I wrote in my earlier column on traceability, this doesn’t happen in practice. In fact, it’s discouraged.

Traceability is all about finding the source of requirements. This source is either a requirement analysis statement or a higher-level design decision. It’s therefore essential that the tool provides the ability to create entities other than requirements and also to establish specific relationships (trace links) between requirements and, for example, design decisions. Again, you’ll be amazed about the number of tools that fail to support this.

In my previous column, I presented the W model as an answer to the need to assign properties (such as mass and volume) to system elements. You’d expect this to be supported by vendors of so-called “product lifecycle management” tools, such as Siemens, IBM, Dassault, Contact Software and PTC. Unfortunately, most PLM tools view the initial CAD drawings as the beginning of the product life cycle. Note that this is almost at the end of the design process! Those tools thus completely skip the left leg of the W model (from product birth to adolescence).

In recent years, vendors have tried to fill the gap by acquiring providers of model-based systems engineering tools or offering interfaces with Enterprise Architect, Capella or No Magic and then letting the poor customer solve the integration and interface problems, while at the same time leaving them with outdated concepts such as RFLP, incompatible terminology, a complete absence of the concept of product properties and the lack of ability for attributes on relationships. Several popular requirements management tools, including Doors, Polarion, Relatics, Topteam and Jama, are now extending their functionality to systems engineering. They face the prerequisites that must be met from an SE perspective: proper configuration, change and release management, cross-context traceability, life cycle support for system elements, baselining and more.

I have yet to see a tool that supports not only the management side but also the engineering side of RM. I’m referring to aspects such as quantification of requirements with tags and qualifiers according to Gilb, the relationship between functions and function properties (also to get rid of the outdated split of functional and non-functional requirements), how to write property-specific requirements, support for ensuring the intrinsic quality of requirements (as offered by tools like QVScribe) and easy comparison between the system as required, the system as designed and the system as tested. After all, a requirement is more than a textual description.