Open Main Menu

Requirements via Tables

This is post four of five that shares learning and insight gained during a recent consulting experience.

If you read post two of this set, you will recall I mentioned that I like to use tables to clarify scope.  I also like using tables because they visually present all the options and combinations that are possible and ensure that stakeholders consider all possible outcomes.

While business requirements can be high level, it is important that functional requirements, be unambiguous, testable, concise, precise, consistent and relate to one thing and only one thing.

The corollary to this is that, if a requirement is related to multiple stakeholders or multiple capabilities, it should be broken down into parts. One of my favourite tools to break down requirements and scope is a matrix or table.

Consider the following business requirement for a team of suppliers working on a large project:

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

This problem could be simplified if one of the N suppliers would take ownership of all the design artefacts and host the library for all to share, however the simple technical solution does not consider the complex political, financial, and competitive pressures that exist in the market.

Consider a scenario where the following factors are present:

  • 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.

All of a sudden a simple requirement, ends up being very difficult to design and implement. As a BA, the approach for implementing the solution is not our concern, but we are interested in documenting the requirements in a logical and flexible manner that makes it easy to provide traceability and support change management?  So how can one document a requirement that is so complex?  Use an NxN Table.

Consider a situation where there are four suppliers.

 

Author Recipient
Supplier 1 Supplier 2 Supplier 3 Supplier 4
Supplier 1 na
Supplier 2 na
Supplier 3 na
Supplier 4 na

If I am an Analyst for supplier 1, the relationship between the other suppliers is out of scope, thus the NxN matrix is reduced to 2(N-1) requirements.

 

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

This leaves the cases in which supplier 1 needs to provide information to other suppliers (Case A) and several cases in which supplier 1 needs to receive information from other suppliers (Case B).  Thus, the single business requirement is actually:

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.