Each supplier shall provide other suppliers with the ability to search their library of design artefacts, in order to support each supplier in their activities to ensure interoperability of their components.
On its own, the requirement seems straight forward, but when you get into the details, you realize;- One system that provides N suppliers with a capability will be easy, because the data structure and the query interface is defined by the system owner
- But there are N suppliers, and thus there are N variations in the implementation of the database and the query interface, which results in many interfaces to be implemented/tested
- Due to competition between the suppliers, supplier 2 does not want to release their design specifications to supplier 4.
- Due financial and scheduling pressures, not all suppliers can implement their querying solution at the same time.
Author | Recipient | |||
Supplier 1 | Supplier 2 | Supplier 3 | Supplier 4 | |
Supplier 1 | na | |||
Supplier 2 | na | |||
Supplier 3 | na | |||
Supplier 4 | na |
Author | Recipient | |||
Supplier 1 | Supplier 2 | Supplier 3 | Supplier 4 | |
Supplier 1 | na | Case A | Case A | Case A |
Supplier 2 | Case B | |||
Supplier 3 | Case B | |||
Supplier 4 | Case B |
A. One library to be implemented by supplier 1 and three (queries to be implemented by supplier 2, 3 and 4.
B. Three libraries to be implemented by supplier 2, 3 and 4 and three query interfaces to be validated by supplier 1 (because there could be some variation between the different implementations).
This totals six different capabilities to be designed, implemented, and verified. While stating the requirements as six different pieces takes a little more effort when writing and reviewing the requirements, it does make implementation, earned value calculations, traceability, and change management easier. Consider what happens if supplier 3 can’t provide their API in time for the release or if supplier 2 has a change in competitive allegiance and is no longer a partner. Written as a general requirement, the project team needs to show that the entire requirement is not met and draw up a waiver to explain the deficiency. If the requirement is written as six separate requirements, each requirement can be implemented and verified according to the availability of the API and the project team will be able to show that three out of six requirements are met, one requirement is deferred to a subsequent release and two requirements have been dropped. This brings me to the concept of managing requirements via a program, to be delivered by multiple, coordinated projects, but that is a discussion for another post.