I posted a while ago on using DOORS Partitions for offline working. In that post, I mentioned that we had worked out a process for managing the data in a supply chain, and that is what I am going to cover here.
In an ideal world, you would have your suppliers directly accessing your data on your server through a secure hole in your firewall. In practice this seems to be a very rare occurrence. Even where I have seen access granted, it has been on a separate LAN so that you plug in to a red CAT5 cable to access the customer network. Web based tools are pointed to as a silver bullet for collaboration, but in fact there is no difference between allowing someone from outside your organization to access a secure web based tool with a browser, or allowing them access through a DOORS thick client to your database. This problem is not one of technology, but one of security and people.
You can easily send your supplier a project archive of the system requirements which they can then import into their database. The problem comes when you make an update and send them an updated archive. They import, but all their traceability is to the original work. Moving the links to the new version, or moving the updates to the old version is going to be heavy going. If there is only one supplier then the following approach might be suitable.
First some definitions:
- Customer: the organization owning the upstream requirements
- Supplier: the organization owning the downstream requirements that satisfy the upstream requirements
- System Requirements: the upstream requirements owned by the customer (I could have picked stakeholder requirements, but I didn’t; the same principles apply)
- Subsystem Requirements: the downstream requirements owned by the supplier
- Data owner: the organization responsible for creating the data
- Data custodian: the organization that holds the master copy of the data
The customer creates the initial release of the system requirements and then sends them to the supplier, possibly in the form of a DOORS Archive, or for more refined control of content, a partition. The customer then freezes the requirements in their database.
The supplier brings the requirements into their database by Restoring the Archive, or Importing the Partition. In the case of a partition this would then need to be Returned (without sending anywhere), with a copy being retained, and the copy would then need to have its access rights freed up.
Now the Owner of the system requirements is the Customer, but the Custodian is the Supplier.
The supplier then creates and Exports a Partition to send back to the customer. The Customer Imports this partition which is now their working copy.
The customer refines the system requirements.
The supplier creates the subsystem requirements and links these to the system requirements.
The customer periodically wants to update the supplier copy of the system requirements, and to do this, they must Synchronize the Partition. This sync file is sent to the supplier who will Synchronize (yes, a little confusing, but these are the correct terms). Thus copy held by the data custodian is updated. By only using Synchronize, the channel is not closed, there is no Return or Recover operation used. The supplier has no problem with linking to the system requirements because there is only one copy, the sync file just updates the existing information.
There is no reason why the same process should not be used in reverse, where the Custodian of the subsystem requirements is the customer.
This does only work with a single supplier, the data for multiple suppliers would have to be carefully fenced off in to different modules, in different projects and it would very quickly become complex. For a simple relationship this is feasible. There is an emotional difficulty of the owner of the data having the nominally subordinate copy. Any mistakes, such as a Return file being created, would cause significant issues, with the whole process needing to be started over.
This is not for the faint hearted and does require strong process to make sure that it is controlled.
Here is that image again, a little bigger. For anyone interested in the mechanics it was created on a small whiteboard and photographed with the Evernote page camera.