127 Requirements are Never Equal

The feeling when (TFW) you are handed 127 requirements and need to establish a way to implement them as a part of a delivery. As with most requirements at the end of the day they will be put to a test (audit, verification), hence they are often non-negotiable. I have this challenge currently about once a month. Often it's contractual requirements, often around (non-functional) security and compliance requirements. But the same approach below is similar effective for classical functional requirements and for other people working with requirements.

If you are given a non-trivial amount of requirements - they are never equally important to your stakeholder and never equally possible the implement.

One way to have a dialog with your customer with regards to their understanding of the requirements would be to make a map. Examine why the customer have added them. I have recently experienced customers pulling cumbersome requirements from the list and similar experienced that they just added them in for compliance reasons, that no one would bother to check anyways.

A good framing I'm currently using is to consider their "appetite" for the topics. What is their risk appetite? What is their appetite for test cases? Appetite for automation? We should care more for figuring out what the appetite is and the serving the deal/meal.

At the end of the day, though will will need to implement some of them. But before that perform a "requirement know-how" analysis. It's a fancy word I just made up.

Perform a Requirement Know-How Analysis

In one of my projects I was facing 50+ security requirements, across a range of topics: staffing, login and MFA, segregation of duties and recurring pen tests. The lens I reviewed and discussed with the subject matter experts was the following four categories:

1. Novel. Never implemented something like this before. We need to consider this before even describing it.
2. Describe. We know this from before, but need to describe it (give it a little consideration) before implementing anything.
3. Execute. We have this already from a similar context. We can implement this right away.
4. Known-Known. We have this trivially in place already. It's a commodity in our solution already.

These four categories are inspired by the Wardley Mapping evolution axis, and I'm sure there are some great lessons in mapping the stakeholder requirements onto a map - also on the visibility axis. That could help us address how we can strategize around taking unknown requirements and making them more executable. And focusing on those that have the highest visibility. For another day perhaps.

Just based on the above analysis I could estimate the complexity of the delivery. In this specific instance 50% where Known-Knowns and 40% to be Described and the remaining to be Executed. So all in all, a straight forward exercise. (the biggest challenge in the project ended up being availability of staff - a people problem).

For two other projects since then I have been able to analyze the (security) requirements by listening to the customer appetite on one hand and analyze the requirement know-how on the other hand. With that I can tell my management the impact of implementing the requirements even before the project has started.

Not all requirements are equal - that goes for both the stakeholder and you.