Using DOORS Next Gen in a Supply Chain

A common request is to maintain traceability into the supply chain. This has always proved to be problematic for a number of reasons, some technical and some political. I am offering here a potential solution.

We have, in many industries, now progressed beyond the clone-and-own approach to reuse, and some support for genuine reuse of requirements and other design data has become expected.

The underlying principle that I have used is that the organization owning the data is the only organization that will be afforded editing privileges. This applies whether the organizations in question are different legal entities, working to a contract, departments within a single business, or individuals with clear responsibility boundaries. This allows us to manage the access rights based on the owning organization.

DNG currently has the limitation that anyone who has read access to any of a Project Area (PA), has read access to the entire Project Area. This can be managed by use of smaller PAs, tied together with a Global Configuration (GC).

Another issue has historically been that of access and firewalls. It has been rare for organizations to let suppliers inside their firewall. Cloud hosting eases this to some extent, and if your immediate reaction to that is one of horror that your data could be trusted to the cloud, then please look a little deeper. It can be as secure as working with a server in the basement of one of your many sites.

A simplified Project Area structure is shown here. The system requirements and both sets of sub-system requirements are shown in blue. These are owned by the OEM or Prime Contractor. The sub-system requirements will be made accessible to the suppliers of those subsystems as read only.

For sub-system 1, I have shown two, competing, suppliers. Each of them would have read access to the OEM sub-system 1 project. Supplier B is also working on sub-system 2, so would additionally need read access to that.

The suppliers then add a level of detail and design understanding in their Response Project Areas. This would be accessible to the OEM as read only, and would not be accessible to the other suppliers, for commercial reasons. Traceability is added by the supplier, to the OEM requirements.

Interface requirements are a special case, as the need to collaborate increases in this area. It is a negotiated specification, where all parties need to be able to comment, and potentially contribute. By breaking this out into a separate PA, access can be managed through time as necessary.

It is very rare for competing suppliers to want to share information about their designs. Any shared information is at a higher level, and would be pushed back up to the OEM requirements. For example, the addition of new capability might be shared back to the OEM, and then flowed down to other suppliers of the same item. Suppliers may share, in read only, their implementation with a supplier of a different subsystem. This is likely when hardware and software are supplied separately. In most other cases, the relevant details will be handled in an interface requirements area.

How does this work in practice?

Initial delivery of requirements to supplier

The OEM works on system requirements and then breaks these down into subsystem requirements that will be delivered to the suppliers. Some effort is required to allocate the correct requirements to the correct suppliers, but this is a normal activity that has been happening for many years. The difference here, from the days of sending paper copies of documents, is that the allocation takes place in the tool. Some thought needs to be given to the partitioning of the data between PAs, to ensure that each supplier has all the data they need, and none of the data they don’t need.

Common requirements, such as Standards (International, National, Industry, and Organizational), should be placed in a separate PA that can be shared with all suppliers.

The allocated requirements and the common requirements PAs can now be shared as read only with the relevant suppliers.

Creation of implementation requirements

Each supplier now works in their own Project Area. As implementation requirements are added, they can be linked back to the allocated requirements in the OEM PA.

The supplier is working in a separate PA, and so can have a different type system, with custom attributes to support their own internal process. All of the data in this PA will also be visible to the OEM.

Enhancements and queries

Looking beyond the boundaries of DNG, the work can be managed in Rational Team Concert. With careful use of the Work Item Categories, confidentiality can be maintained between suppliers.

When a supplier finds that something is missing, or incorrect in the OEM allocated requirements, this can be raised in a WI, and changes can then be flowed down to all suppliers. The requirements in the supplier implementation will not need to be shared with other suppliers, as this is a response to the allocated requirement, and is implementation specific. Any shared requirements at this level are likely to be interface requirements which are handled separately.

Negotiating the interfaces

Interfaces are special case. This is an area where there is negotiation and collaboration between multiple suppliers and the OEM. The ownership of the interface could be supplier or OEM, and not all interfaces will necessarily be the same.

Regardless of the process for interface negotiation, the suppliers on both sides of the interface and the OEM all need visibility of the requirements. Breaking this out into a separate PA allows that visibility, and management of write access can be achieved within the PA.

A special case of interface, is that between hardware and software for a single electronic control unit (ECU). In the case where there are separate suppliers for hardware and software, it may be prudent to allow the software supplier full access to the hardware implementation requirements.

Tying in the testing and the bigger picture

Requirements are only a part of the story. Testing is another large part. As a starting point, I would recommend one Rational Quality Manager project area for each DNG project area. The OEM will need to carry out some form of acceptance on delivered work, and this would be to the requirements at the OEM allocated requirements level. Suppliers will need to carry out verification work at the level of the implementation requirements. Where the one to one RQM to DNG mapping does not fit with the process requirements, then adjustments can be made.

All of the RQM and DNG project areas, or rather the components within them, can be tied together with a Global Configuration (GC). This makes navigating between PAs straightforward.

If needed, the GC can work with components on different servers. This allows the suppliers to have their own RQM/DNG set up, and tie that to their customer’s data through GCs, thus maintaining traceability through the whole design, down to the lowest level. While there would be no single individual with visibility of concept through to fine detail, everybody would have the required visibility up and down from their own point of interest. This avoids discontinuities and the associated risks of duplicating data.