Our regular blog from industry analyst expert, Cambashi
This Silos Changing series explores how manufacturers are likely to deploy new software applications that enable enterprises to implement business initiatives in the new economy. Currently we’re discussing applications that help enterprises implement business initiatives that support strategies around the product differentiation business driver.
I guess most of you have seen this cartoon on the wall of a design office somewhere! It is at least 40 years old so it would be nice to think we’ve solved this by now.
Earlier in this series we looked at how to capture the voice of the customer and plan a series of differentiated products. In this blog we are looking at requirements management once a decision is made to develop a product with differentiation. We all want to retain differentiation, and not to end up as another proof point for this cartoon.
To get requirements accurately reflected in the final product design is a multi-dimensional problem. It is more than simply ensuring that the requirements fulfilment is tracked as the product development progresses.
There are three different sets of information that have to be kept up to date and in step: the actual requirement; the functions that will implement that requirement; and the test cases that will validate that the requirement has been met.
Design is a process of refinement. As each design decision is made, more constraints are put on future decisions. For instance, a decision about the diameter of an axle will define the dimensions of the bearing carrying it. Design decisions could be as a result of a calculation or they may be made for aesthetic reasons; however, others will be arbitrary.
Historically, products were formed all from mechanical components and these were engineered in the same design office so a decision causing an avoidable constraint would be picked up, the history of design decisions that caused it recognized and prior arbitrary decisions changed. The resolution of decisions would be discussed peer-to-peer in the same office and a better design would result. I well remember the section leader coming round and saying “I wouldn’t do that if I were you.”
Design best practice today is to minimise the number of engineered parts to those that create product differentiation; other bought out parts are sourced globally. Since these parts were not designed in the context of a specific product, they too will bring constraints.
To add further complexity, today’s smart products will comprise a mixture of components designed in different disciplines, mechanical, electrical, software and semi-conductor design.
The design team needs an integrated requirements management system that can cope with implied constraints as well as change and works for all stakeholders globally.
There are already good systems that cope with requirements management in specific disciplines.
Semi-conductor design practice is the most advanced. Here, the requirements of the semi-conductor part of a product can often be specified in a computer readable language, test cases can be generated automatically, sometimes design can be synthesised. It can be simulated and verified at every stage of design refinement. Truly Computer Automated Design.
This level of support is far away for mechanical engineering and only available in very exceptional cases for electrical engineering but software engineering has made great progress. As software engineering becomes more based on model based development, software requirements management products can handle requirements and functions to be implemented in other engineering disciplines.
Manufacturers of smart products may desire a single integrated application to support requirements management. However, today they use several software tools, some developed in house, others from different suppliers.
One starting point towards the integrated application ideal is offered by IBM’s Rational DOORS, a leading requirements management application that enables requirements communication, collaboration and verification beyond one organization into the supply chain.
A number of features allow all stakeholders to collaborate. For example, it provides web browser access to the requirements database. DOORS supports the Requirements Interchange Format, which helps development partners using DOORS or other tools to be directly involved in creating, reviewing and establishing traceability for requirements. There is functionality to link requirements to design artefacts with specific functions, create test plans and test cases. In manual test environments, a test tracking toolkit links requirements to test cases.
IBM customer Diagnostic Grifols develops diagnostic medical devices for blood banking, haemostasis and immunology which must be compliant with FDA (U.S. Food and Drug Administration) regulations. Together with IBM, Diagnostic Grifols implemented a solution (including IBM Rational DOORS, IBM Rational Change and IBM Rational Synergy) to manage and connect all the stages of the development cycle. This allows different developers working on the same project to build and share all the regulated product data in a controlled environment.
Andy Gurd, IBM Rational’s requirements engineering marketing manager, says: “IBM recognizes that a smart product will implement requirements in many engineering disciplines. There is a need to rationalize the applications landscape and increase agility and lateral thinking across teams.”
An interesting community effort, initiated by IBM, is Open Services for Life Cycle Collaboration (OSLC) http://open-services.net/. The OSLC community develops open specifications for services that enable tools from different domains (i.e. requirements management, change management, test management) to provide common integration scenarios. Several large European enterprises in the automotive, aerospace and rail transport sectors are working with IBM. For example, Siemens is very actively involved in a project that integrates product lifecycle management and application lifecycle management.
We are still talking about computer aided, rather than automated, design for mechanical and electrical engineers. Meanwhile, product lifecycle management suppliers are developing significant requirements management functionality. In future blogs we will discuss those, then go on to talk about other potential deployments that support product differentiation, such as cost effective sourcing, visualization and simulation.