The simplistic view regarding how the software development process is that you write down all the functional requirements first (i.e. what) and then you figure out the technical implementation (i.e. how to implement the what).
This view is simplistic because in reality you should alternate between defining the functional requirements and the technical implementations.
Because the technical implementations are constrained by the current system and the budgeted implementation time. When you are defining the functional requirements you are further away from these constraints.
Sometimes you can reduce the implementation effort dramatically by tweaking the functional requirements.
Sometimes — if constraints are incorrectly assumed when defining the functional requirements — you can make features much more interesting than initially planned by marginally spending more time implementing.
here is a diagram to remember this interaction:
The conversations about how to turn the functional requirements in technical implementations (A) are expected.
However the conversations how the technical implementations change the functional requirements (B) are as important.
Some examples of these latter conversations:
- “This functional requirement is too hard! It would be simple if we changed it like this. Does that work?”
- “This technical implementation gives me an idea for a missing functional requirement!”
- “Remember that functional requirement you left out? Well it turns out we can easily do it”
Having these 2-way conversations are vital to get a quality product out the door fast.