As products get smarter and consumer demand increases design and development have to evolve to keep pace
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.