Product development is a journey of collaborative learning. We learn, through iteratively growing a solution, how to solve effectively an initially unknown set of problems. This is not a linear process. It includes rework and removal of work. Misunderstanding and the limits in software visualization matter here. Failures, in the development effort, help the team find its way through uncertainty toward a good product. And so, identifying invalid assumptions about how to create value deserves deep thought in each activity of the development process.
Users use a product because it solves their problems in a way that fits well within their contexts. They see solutions, not features, and they learn more about the product as their interaction with it increases. In an environment where feedback is highly valued, stakeholders try the software frequently during its development. That changes their view as well as their expectations. Using the existing system as a basis for conversations, they express their problems to the team clearly.
Validated requirements constitute the way to a good product. The specification of the requirements early is rarely useful in the long run. Unless for providing a rich framework for conversations, the cost of these decisions outweighs their value. We work toward requirements and we get them when we are done. That makes more sense when we see the requirements as a view of the software solution.
We start with assumptions. We assume that listing the events will help the manager find and update his target. But, does that meet the need of the manager? She might also need to change the date of the next event frequently. That depends on where she finds the events, what is she using the system for, when she does that, and how the software fits in her life. This requires continuous investigation, deep reflection, and a lot of trial and error.
We work on problems, and solving each problem changes the setting of the next one. We approach our problems one by one. We identify the problem, we assume a solution, we test it, we get feedback, we learn, and then we reflect on our understanding of the problem as well as the adequacy of the solution. We repeat this until we come up with a good solution to the right problem. Only when we end up with proof of viability of a solution that we take it as a requirement.
Another problem with up-front requirements gathering is that identifying the scope of the software early hinders our ability to learn and inquire deliberately. The stakeholders’ views change continuously. They learn more about the solution. Their interaction with the software gives birth to a set of patterns. That is because users establish rules and habits of use. This invalidates most of the early decisions.