The Software Requirements Balancing Act

When we first consider doing a software project, we typically have some business problem we are trying to solve or some market opportunity we are taking advantage of. Those problems and opportunities exist outside of how we choose to solve them. Requirements describe how the business wants to move forward in the market. The requirements space is the set of possible requirements that could satisfy that market need.Likewise… architecture and design describe how the requirements are going to be implemented in technology… but at the end of the day… we are really just describing in technical terms how we are going to solve the problem identified by the business. The solutions space is the set of possible solutions that could meet the requirements and satisfy that business need.

Balancing the Triple Constraints

Given unlimited time and money… the business can choose to solve the problem any way they see fit. There are no constraints on the set of requirements the business can choose from. Similarly, given unlimited amount of time and money, the technology folks can implement whatever cool stuff they want to satisfy the business requirements.  Its not often though that we have unlimited time and money to solve the problem.

Typically the opportunity has a potential market value and costs have to be minimized to reduce risk so we are confident of a return. It’s likely we have a narrow window of time to realize that return before a competitor gets there and delivers first.  Many teams operate as if there are no constraints on the time and cost. Business people go off by themselves to develop requirements that have little chance at all of being delivered within the budget constraints. Technology folks then go off and specify designs that will never be able to be done on time.

Collaborate Early and Often

Balancing the requirements space and the solutions space is my way of saying that business people and technology people need to collaborate… from the very, very beginning of the product definition… on what they are going to build. Once the product folks start thinking of what they want to implement… the technology people need to weigh in about the kinds of solutions those requirements are going to imply.We need constant communication… and frequent iteration… continuously allowing our emerging understanding of the requirements be in balance with our emerging understanding of the solution. We need to let our emerging understanding of the requirements be shaped by what it is going to take to build it. We need to let our emerging understanding of what we want to build be shaped by what the business needs, what it is willing to spend, and when it needs to be delivered.

Again… this is one of those things that is built into the very fabric of the small team agile concept. It is another one of those things that needs to be explicitly addressed when we start talking about scaling agile.

What does this look like in practice?  Simply have the business people sit down with the technology people and explain the business problem… and their vision for how to solve it… all in terms of high level requirements. The technology people have a day or so to go off and think through their palette of possible solutions. The technology folks come back and explain their high level solution… how it satisfies the product vision… and a ballpark idea of how big the project might be and how long it might take to complete.If we are not in sync… if the requirements and the solution are not in balance… iterate the process allowing what we know about the solution space influence the requirements. Come back to the table and start the process over… either until we have convergence… or we realize that there is no solution that can deliver the product vision within the time and cost constraints established by the market. By bringing the requirements vision and the solution vision into balance at the early stages of product conception… no one ever gets too far off before we have the opportunity to reset everyone’s expectations.