Design Requirements Matrix: Turn a Diagnosed Cause Into a Change Worth Piloting

The Design Requirements Matrix translates customer and business needs into concrete design requirements for the future-state solution. That is the whole job. You arrive with a diagnosed cause and a list of things people say they want. You leave with a short table of requirements that can be built, tested and owned.

It sits in the Improve phase of RDMAICS. By the time you open it, Measure and Analyse should have told you where the process loses time, accuracy or trust. Improve is where you decide what the new process must do. The matrix is the bridge between the diagnosis and the build.

Reach for it at the moment a team starts arguing about solutions. Someone wants a new system. Someone else wants a rule change. The argument is usually unresolvable because nobody has written down what the solution must achieve. Write the requirements first. The solutions then sort themselves into those that meet the specification and those that do not.

Everything that follows uses the sample data built into the tool. The case is fictional. It describes an accounts payable process where invoices move slowly, matching is manual, approvals stall and vendors call to ask where their money is.

Five needs came out of the earlier phases. Fast invoice processing. Accurate matching. Timely approvals. Vendor transparency. Auditability. Each one is a critical to quality characteristic, or CTQ. Each one is also, on its own, useless as a brief. Nobody can build fast invoice processing. You can build automated data capture that captures at least ninety five per cent of fields automatically.

That is the shift the matrix forces. Five soft needs become five hard requirements, each with a specification that a tester can pass or fail, and each with a named owner who will answer for it.

The worksheet has five columns and one row per need. Keep the row count low. Five rows is enough for a pilot scope. Thirty rows is a programme, not an improvement.

Work left to right. Start with the need as the customer or the business states it. Then write the design requirement, which is the capability the future state must have. Then write the specification, which is the number or condition that proves the capability exists. Then set priority. Then name the owner.

In the sample data the five rows read as follows. Fast invoice processing maps to automated data capture, specified as capture of at least ninety five per cent of fields automatically, marked Critical, owned by IT. Accurate matching maps to three way match automation, specified as a match rate of at least ninety five per cent auto approve, marked Critical, owned by AP. Timely approvals maps to auto routing plus delegation, specified as approval under four hours median, marked High, owned by Finance. Vendor transparency maps to a vendor portal status view, specified as real time status visibility, marked Medium, owned by Procurement. Auditability maps to a full transaction log, specified as an immutable audit trail, marked High, owned by Compliance.

The tool rebuilds the worksheet into a single result table and checks it for traceability. The headline finding on the sample data is that every CTQ is connected to a design requirement, a measurable specification and an owner. No orphan needs. No requirement without a test. No test without a name beside it.

That is a small statement with a large effect. It means the team can no longer claim a need is covered when it is not. It also means that when the pilot runs, each result can be traced back to the need it was meant to serve.

The tool also offers an AI review that explains what the completed matrix implies. Treat that as a second reader. It will tell you how the structure reads. It will not tell you whether your specifications are the right ones for your process.

A pilot costs money and attention. The matrix lets you estimate the return before you spend either, because the specifications are the gain stated in advance.

Take the sample data. The pilot is being asked to deliver automatic capture of at least ninety five per cent of fields, an auto approve match rate of at least ninety five per cent, and a median approval time under four hours. Those three numbers are the business case. Compare each one against the baseline you measured in the Measure phase. The difference between baseline and specification is the gain you are buying.

Now check the shape of the gain. Two rows are Critical, two are High, one is Medium. If the Critical rows alone do not justify the pilot, the pilot is not justified, because the Medium row can be dropped without breaking the design. This is how priority earns its place in the matrix. It is not a mood. It is a scoping instrument.

Then check the owners. The sample data spreads ownership across IT, AP, Finance, Procurement and Compliance. Five owners means five diaries, five sets of competing work and five approval paths. A gain that depends on five functions moving together is slower to realise than a gain owned by one. Size that cost too.

Once the table is filled, several decisions become straightforward. Scope is the first. The Critical rows define the minimum viable pilot. Anything Medium can be staged into a later release.

Vendor and option selection is the second. If you are assessing build options, score each one against the specification column. An option that cannot reach ninety five per cent automatic field capture fails the first row, regardless of how well it performs elsewhere.

Acceptance testing is the third. The specification column is your test plan. You do not need a separate document. Every row is a pass or fail condition.

Governance is the fourth. The owner column tells you who attends the pilot review and who reports on which number. It removes the common failure where a requirement is everyone's responsibility and therefore nobody's.

The most frequent error is writing a solution in the requirement column. If a row says the name of a system, you have skipped a step. The requirement is the capability. The system is one way of delivering it. Keep them apart so you can still compare options.

The second error is a vague specification. Real time status visibility, as in the vendor transparency row, is acceptable because it is a binary condition that can be observed. Improved visibility would not be acceptable, because nobody could ever fail it.

The third error is priority inflation. If every row is Critical, the matrix has told you nothing and the pilot has no way to shed scope under pressure. The sample data holds the line with two Critical, two High and one Medium.

The fourth error is an owner who did not agree to be an owner. Walk the column before you publish. An owner who learns of the role at the pilot review will not deliver.

The Design Requirements Matrix checks structure, not truth. On the sample data it confirms that every CTQ has a requirement, a specification and an owner. It does not confirm that ninety five per cent is the right threshold, that four hours is achievable in your environment, or that these five needs are the five that matter most.

It will not tell you whether the cause you diagnosed is the real cause. That work belongs to Analyse. If the diagnosis is wrong, the matrix will produce a tidy, traceable set of requirements for the wrong problem.

It will not cost the work, schedule the build, assess risk or manage change. It carries no baseline figures, so it cannot calculate the gain for you. You supply the baseline from Measure and do that arithmetic yourself.

It also stops at the pilot boundary. Holding the gain is a Control and Sustain job. The matrix hands over a clean specification set and a named owner per row. What happens after the pilot depends on the controls you build next.