01604 491 661

Managing Requirements Traceability: Increasingly Complex Systems

As products get smarter and consumer demand increases design and development have to evolve to keep pace

The automotive industry gives us a great example of the accelerating complexity of electrical and electronic (EE) systems. A recent article by Forbes indicated that “The Connected Car Isn’t The Only Thing Getting More Complex. So Is Its Test Environment”. Manufacturers are having to adapt and focus their design and development approaches to balance computer and network resources with software and electronics across their platforms. On top of that, they’re having to meet exacting safety, environmental, user experience, non-functional and functional requirements too. This increase in complexity has not only changed how vehicles are developed and manufactured, but also how they are marketed, serviced and eventually disposed.

These changes aren’t just happening in the automotive industry, they’re happening universally in pretty much every industry sector you can think of. And as the products we make get smarter and consumer demand increases, then you won’t be alone in thinking that design and development are going to have to evolve to keep pace.

Evidently, it’s not uncommon for organisations to struggle with requirements management and traceability with the increasing complexity of EE systems – engineers are having to manage a vast number of requirements linked to numerous items across software, electronic and electrical domains. As the product changes during its development lifecycle, to better fulfil new, existing, or changing requirements, organisations find it difficult to manage and keep track of them. This is partly down to the way that today’s requirements are intricately connected to one another.

When developing a new system, everything has to work together. If we take an EE system as an example again, you’ve got to be sure that the communication protocols that the sub-systems are using are fully compatible with one another. Then, you’ve got to make sure you’ve got sufficient capacity on the network to cope with the intended traffic. On top of this, taking thermal considerations into account, you need to provide prevent unwanted heat transfer between elements. You can’t develop the sub-systems in isolation from one another because of their connected nature.

Even in this simple example, you can see straight away that EE design affects every aspect of a product. So, a robust requirements management strategy is critical to keeping the rising complexity of systems of any sort under tight control.

There’s inherent risk with document-based requirements traceability

To appreciate the direction of travel, you first need to gauge where you’re coming from. Historically, one of the most omnipresent tools to grace any manufacturers door is being perilously leveraged to manage product requirements – if you haven’t guessed already, we’re talking spreadsheets. Let’s have a look at why taking this approach for requirements management is fraught with risk.

1. Lack of coherent version control – Engineers universally manage documents and spreadsheets at a file level using their desktops. With that in mind, picture this: an engineer creates a single spreadsheet detailing thirty requirements, and the version number goes from A.1 to A.2. How easy would it then be to determine what change, or changes have been made to each individual requirement? If you find yourself in this scenario, you’ll find it’s particularly tricky to track changes to the product, and even more so if you ever decide to revert any changes back.

2. Stifled collaboration – With documents and spreadsheets, there’s no single source of truth. Actually, what we mean by “single source of truth” is that there’s only one place to look, and only one version of everything. If I write a word document and you write a word document, which one does the next person read to find out about our system? Answer – they won’t know until they have read both (multiple sources), next what if the two contradict each other? Answer – we can’t determine which is correct (multiple truths).

3. Unclear context – Not being able to link requirements directly to specific design elements in the system is perhaps the biggest issue with document-based requirements traceability. You can’t link text in a spreadsheet to software, an electrical network or electronic unit and that’s where the problem lies. It means you can’t clearly communicate to engineers which bit of the design satisfies which requirement, so instead you’ll likely end up with costly errors at a late stage in the design development process.

Managing requirements this way’s ok for small and less complex sets of requirements but it doesn’t scale. Unfortunately, it’s not obvious where the tipping point is, so just because it worked on your last project doesn’t mean it will work on the next. As with all issues though, there is a solution afoot…

Introducing Model-Based Systems Engineering (MBSE)

Many of the issues associated with document-based requirements traceability can be resolved with a Model-Based Systems Engineering (MBSE) approach by managing requirements in a more progressive way to combat the increasing complexity of systems.
The premise itself is relatively straight forward: having a single model comprising of Requirements, Behaviour, Structure and Constraints in the Problem Space, Solution Space and finally Implementation, allows you to trace the various engineering elements throughout the lifecycle. One approach may be:

Requirements are traced to functions.
Functions are allocated to elements in the logical architecture.
Elements in the logical architecture are allocated to elements in the physical architecture.

With everything connected, a network of relationships is created which provides you with clear traceability starting at top-level requirements all the way through to the physical implementation of the design. By taking away any ambiguity, engineers can quickly grasp each design elements function and purpose which means collaboration’s enabled and the development process is expedited.

With MBSE, collaboration is enhanced even further as the model becomes a single source of truth, with the ability for engineers to concurrently access and edit the model in real-time.

Hopefully, this article has started to paint the picture of how an MBSE approach hugely simplifies how you could track and manage your product requirements. Unlike with document-based requirements traceability, MBSE can handle the challenges thrown at it the ever-increasing complexity of today’s systems.

Contact Us

Have some questions about your choices?

Get a Price

Found your solultion? We'd love to talk about how we can work together

Need Help?

Do you have a question about our solutions, or do you need support in identifying the right solution for your business? Get in touch with our team today for free, no strings attached consultation


We use Feefo (the global feedback engine) to gather anonymous but certified genuine reviews from our customers