One of the biggest gaps in the requirements discovery and specification, and solution design is formed because the whys are not communicated to the solution developers. The requirements specification usually talks only about what the solution should do. There is nothing that tells them why it is so. When their decisions are not aware of the underlying reasons, they can work against the overall benefit and at times make the solution a failure. Here are some things that I think should be communicated to the solution developers:
- problems and pain points in the current system
- priorities of requirements
- business constraints
- other non-software components, like processes and skills
- rationale behind important decisions
A lot of businesses do feasibility studies but they are not shared with the developers. Or sometimes businesses have already identified a solution that they are using to build their requirements. Or sometimes businesses just do not invest enough in identifying their problems and pain points.
Unless the solution developers know the ROI behind the code they are writing of tools they are integrating, they are not going to be able to effect it. It is always better to define the problem in its own space, keep it solution agnostic and share it with people who are developing your systems. Or this gap can lead you to the wrong solution or a solution for the wrong problem.