Requirements management as a discipline has been practiced since the first person provided the first product or service for sale or barter. At its essence, requirements are all about a definition of need or want. We’ve come a long way since the early days of hand-made products for sale in local shops or markets but our tools for managing requirements haven’t really improved all that much. After all, how different are the specs for Noah’s Ark from the list of requirements we track in requirements database tools? Sure, a computer requirements management program is a lot easier to manipulate and search than a list of measurements in ancient Hebrew (Genesis 6:14-17) but it’s still a list of items.
What’s needed is a new way of thinking about requirements and taking advantage of our connected systems to help model our connected world. To that end, tomorrow’s requirements management solutions need to be…
By connected we mean connected to everything, not just other requirements or test cases. Our complex products are systems of systems that are in turn connected to other systems and devices in the Internet of Things.
Let’s think about a straightforward product component, an electric motor. That motor is connected to the rest of the device that it is a part of (a car, a generator, etc.), which is in turn connected to a larger system (a fleet, a smart traffic system, an industrial plant) and other systems and so on. It is controlled by a combination of powertrain and battery control unit, which communicates with advanced driver assistance functions, and the infotainment system to display current power consumption, remaining range, etc. And how this product both functions and is used in practice are important pieces of information.
Up until now the way manufacturers found out how their products were used was by surveying their customers and the results were not always informative or even accurate (after all, how many people are going to admit regularly driving 25 miles over the speed limit and never changing their oil?). Today’s connected systems and IoT technology allow us to ask the products themselves how they’re being used and get real live data. This can be used by designers and engineers to not only make modifications to the current product (smart products can be updated) but also to improve the design of the next generation of products.
Search the internet for “requirements traceability” and you will find thousands of links to traceability matrixes and references to “tracing” between software requirements and either other requirements or test cases. This was one of the biggest advances in requirements management enabled by the current crop of tools: the ability to make this tracing task easier.
But today that simply isn’t good enough. We need to look at the bigger picture. How do the statements of needs of the system relate to the system architecture and structure (i.e. system models) as well as the physical implementation of the system (3D drawings and assemblies) and its embedded control software? How can I validate that the implementation satisfies all statements of need? And if I change a requirement, can I use a different system implementation that will allow me to develop the product more quickly? Safely? Inexpensively? Or will a modified component from a different supplier still allow me to achieve all specified goals for performance, stability and safety? Without the ability to have true traceability these types of questions are extremely difficult if not impossible to answer.
True traceability is more than just managing links between requirements, tests, etc. It must consider the dimensions of history (version-accurate traces), variations or branches for different product models and variants, and the decomposition of a requirement from product- or system-level to the specification of physical component or logical software module. True traceability does not depend on manual identification of related objects. Instead it uses advanced data analytics and pattern recognition algorithms to propose a set of test cases that can validate a given requirement or identify the scope of a requested change in a specification.
Machine learning and analytics are being applied to a wide variety of different problems, like when and how often should a farmer fertilize and water his crops or when should a technician replace the bearings in the motorized lift of the elevator in a skyscraper. The ability to identify patterns and synthesize new ones as well as to anticipate future behaviour has great applicability in requirements management. First applications can be seen around requirements quality checks to determine whether requirements are unambiguous, atomic and testable. More advanced scenarios include validation of requirements changes and analyzing their technical and economic impact (cost and effort). Based on formal requirements specifications even optimized architectures and structures as well as a relevant set of test cases can be identified.
We’ve already talked about linking to system models to help aid in understanding overall system design and requirements, but what about the ability to look at the requirements themselves in a visual fashion, depending on the work context of the individual user. A Quality Engineer wants to look at how requirements are traced in a table format, with linkage details available to check the completeness of test coverage. Or maybe a System Engineer wants to see a graph of these same connections to get some sense of potential impact of an architecture change.
As we’ve seen with the trend toward data visualization with infographics and other representations, the idea is to utilize visual representations to help identify patterns and enhance understanding. Modern requirements management solutions leverage these capabilities.
As software controls most functionality in any modern product, driving agility in product engineering is one imperative of modern development of complex connected products. Software engineering has adopted agile methodologies in the past two decades, but hardware development and integration, lead times for manufacturing, and time-consuming processes for homologation and compliance certification dictate different release and change cycles.
Using high-velocity incremental development methods like SCRUM works very well in prototype development. Adopting DevOps for connected products allows for a continuous information flow from test operations to refine and inform the requirements specification for series development. The immediate feedback allows to fail fast and improve immediately. Automation in the entire process ranges from code-generation, build and test management through deployment (also over-the-air) to collection and analysis of the data in connected operations of a product or its prototype.
Figure 1 - Agile methods inform specification, design and implementation work in series development
The crop of current “state of the art” requirements management tools have significantly advanced the art of innovative product development. However, connectivity and automation in the Internet of Things era demands a new set of characteristics and capabilities making requirements management connected, smart, visual and agile. PTC’s unique combination of IoT, PLM and Requirements and Validation solutions enable our customers to build the world class products of today and pave the way to deliver the products of tomorrow.
STAY UP-TO-DATE Gain access to analyst reports, buyer's guides, online webcasts, and much more.
Thank you for your interest!