Inversion of Requirements

I use to inform people that when I write code I try to write code for the next guy to understand. Which is often me in 6 months. I have since realize that this is true but more importantly I am finding that I have to write code for changes in requirements.

Requirements

I often draw the analogy that building a product is like building a house. You would not start digging footers on house without architecture plans, nor would you build roof before the foundation. However in product development it is often viewed that the cost to change code is small therefore they start coding before doing any architectural design work. This often excites stake holders as progress appears to be made quickly at start of project. However most all projects stall and end up in a prolong purgatory where it is constant requirement change and then rework. This usually causes the project to be months if not years behind schedule. To get around this problem I would often tell engineers that we need to "Release early, release often, first release on paper." The idea is the first release is the architectural design done on paper.

Cost of Change

The reason for the first release on paper is that you want all the changes in requirements to occur early where the cost of the change is minimal. The cost to change requirement on paper is minimal, where the cost to make the change after 6 months into project is much higher.

This means you are really designing project plan based on the cost to change requirements. Here you are trying to make sure you get the big costly requirements into the project plan and architectural design at the start. With the house analogy it is a lot more expensive to change the foundation after the walls are up.

Coding for Change

With most projects the main development effort is firmware/software. This is usually because 95% of the features are software features. What this means is the software architecture needs to be designed for the changes in the requirements. This means the code is written to allow changes to happen easily.

Typically what we find is that the start of project code is architected well, well defined objects and separation of tasks. However the moment a requirement changes which does not met the that architecture the developer has to make a decision to tear house down and rebuild or try to hack in a fix for the new requirement. As such after 6-8 months the code has more and more hacks to get the latest requirement in.

Often the latest requirement is the "If we just had this one feature we could start shipping." This happens so much it is just a crying wolf as the proverb goes. It is never the last feature or change, even after product ships the development rarely stops.

How to design for change?

Designing for change is often more about communication than anything else. That is as stated above we try to design where we minimize the cost of change. Here engineers often complain about customer not giving them the full requirements or not even knowing their requirements.

However we invert this need for requirements and consider that the engineer should be telling the customer when the design is being done in such a way where it limits the future options. For example if you are doing a foundation for a one story house which will not allow a 2 story house then we should be communicating that based on the requirement we are limiting the future changes so it is 1 story only.

The irony is that we as engineers and designers often know more about customer needs and requirements than they do. However leading them to understand what you know is too time consuming. Rather than discussing what we need to design into product, maybe we should invert requirements discuss what we are designing out of it. Then we would have an inversion in requirements.

Example

A friend was doing a design for customer where the customer's engineering team was changed in the middle of the board layout. The new team was discussing how certain pins would not work if high voltage was applied, and wanted the design fixed. However they did not know how much voltage could be applied to the pin. This really frustrated my friend as it is hard to design to unknown requirements, even worse when the design was not yours to begin with. I suggested he invert the problem as stated above. Specifically, do the design the way he would do it. Then document the specifications for that design. At which point it is the job of the customer to verify the specifications meet their requirements.

He is now writing what limits his design will handle and be tested to. He is not saying it is fit for the customer's purpose. That is and always will be the customer's problem. If after he does that work customer needs a change it is easier as they can change the specification to create requirements for the next design.

Requirements verses Specifications

Requirements is what someone wants in a product that does not exist, where specifications is what the product actually does.
If customer has no requirements you do not know what product needs to do, often the best thing is to design a product based on what little you know, as you are now the subject matter expert. Then write specification and let customer determine if the specifications will work for them. Ideally you would write the specifications, requirements at this point, and present to customer before doing design but some customers might be fine with after.