High Tech Institute trainer Cees Michielsen highlights a handful of trends in the field of system requirements engineering. He provides the 2-day training System requirements engineering improvement for High Tech Institute several times a year.
In each System requirements engineering improvement training the question arises: what it the best tool to manage our requirements? To answer this question you would need to know all the bells and whistles of requirements management tools, including the latest updates. At the same time, you need a good understanding of the operating environment where you want to insert the tool. In short: this is an impossible task.
Don’t stress, there is still a first distinction to make. It is best to do that based on the type of business you are working with. An organization like ASML is not required to conform to international safety standards, information security or FDA regulations. Even Word or Excel is then suitable to manage everything – and surprisingly this seems to be the preference.
When norms and regulations are involved, the software must support audit trails. That means providing basic functionality for configuration management, like version management, change management and status administration. It’s quite amazing, but many requirement management tools don’t provide these basic features.
Another distinction to make is the baseline. In its most basic form, a baseline is a snapshot of the requirements database, containing a subset of requirements. More advanced 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 no longer be changed.
In some industries, like the automotive industry, is the exchange of baselines between OEM and suppliers a standard procedure (better known as the Lastenheft-Pflichtenheft information exchange), but internally it is also useful. They create tranquility and stability in an environment that is known for changing requirements through multidisciplinary product development.
The decoupling of different dynamics from baselines can be very effective. This is also the base of my earlier comment about Word and Excel. They can, with their relatively slow pace of change, dictate an appropriate heartbeat for initiating change in the development organization. For example, a fast-changing agile way of working with biweekly sprints and a long lead time with quarterly updates and annual releases.
A strong argument in favor of using RM-tools, is the traceability support. Most suppliers of tools advertise that their tool is suitable to couple requirements to other requirements. As I wrote in my column on traceability, this doesn’t seem to happen in practice. It is even being discouraged.
Traceability is all about finding the source of requirements. These sources are either a requirements analysis statement or a higher level design decision. Therefore, it is essential that the tool offers the possibility to create other entities than requirements, and is able to make specific relations (trace-links) between requirements and design decisions for example.
Again, you will be amazed at the amount of tools that cannot support this.
In my previous column I presented the W-model in response to the need to assign properties (such as mass and volume) to system elements. You would expect this to be supported by tool suppliers that call their tools Product Lifecycle Management (PLM) like Siemens, IBM, Dassault, Contact Software and PTC. Unfortunately, most of these PLM-tools see their first CAD-drawings as the beginning of the lifecycle of the product. I’m just highlighting it: this is almost at the end of the development process!
Put differently: these tools completely skip the left legs of the W-model (from birth to adolescence). In the past years these PLM-tool suppliers have tried to fill the gap by acquiring model-based systems engineering tool providers or by offering interfaces to (Enterprise Architect, Capella, No Magic) and then letting the poor customer deal with the integration and interface issues, while also being left with outdated concepts such as RFLP, incompatible terminology, complete absence of the product properties concept and the lack of the ability for attributes on relationships.
A couple of popular requirements management tools are expanding their functionalities to systems engineering, like Doors, Polarion, Relatics, TopTeam and Jama. They are being confronted with the preconditions 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.
Returning to our original topic of the day: I still have to see a RM-tool that does not only support the management aspects, but also the engineering aspects. Like the quantivation of requirements with tags and qualifiers according to Gilb; the relation of functions and function-properties (also to get rid of the outdated split of the functional and non-functional requirements); how to write property-specific requirements; support for ensuring the intrinsic quality of requirements (functionality provided by tools like QVScribe); easy comparison of the system as required, the system as designed and the system as tested. A requirement is more than just a textual description.
In the column about traceability I mentioned that requirements tooling can help with answering the question: why does this requirement exist and why does it have this value? PLM-tooling can help with answering questions such as ‘If this element fails in the field, can tooling help me find the system function(s) affected by this failing element?’
