The cost of getting it wrong can be astounding.
- Requirement defects account for 56% of re-work in projects
- Globally, $250 billion of annual waste is traced to poor requirements
- In the United States, about $200 billion is spent on software development (2008)
- Also in the US, $46 billion is spent on fixing software requirements errors.
- Taken together, the last two of these suggest that 25% of all spending on software.
Use the floodlight model to identify and control your project requirements
Problem: either we have some challenge that we need to address (e.g., “We are not selling as many product X than we need to do”) or we have identified an opportunity in the market (e.g., “The 30 to 45 age group is not being addressed by anyone in terms of …”).
Requirements: whichever of these is the case, we take this ‘problem’ and describe it in terms of a set of positive business requirements that describe things that we need to happen; e.g., “We need to identify more customers for product X from …”. Go to the section on stating requirements for more details.
Solutions: a single set of requirements is likely to have a myriad of potential solutions. In the floodlight model, these potential solutions are those that fall within the pool of light cast by the problem floodlight on the conceptual ‘stage’ of all possible solutions.
Constraints: luckily, we don’t need to worry about all the solutions, as limits will be placed on us by the constraints imposed. Viewing the constraints as a spotlight, the pool of light that is the intersection with the problem floodlight illuminates the candidate solutions.
Typical constraints include:
- Budget or price – the amount the sponsor is willing to spend on developing the solution
- Time – the amount of time that is available to us to provide a solution
- Resources – the number and type of resources we have available to us and, in terms of people, what skills and experience they have
- Architectures – Processes and standards the solution must comply with to integrate with preset infrastructure and policies
- Regulatory – what must be considered to remain conformant
- Physical limits – such as a fixed amount of office space for a new call centre (solution).
In simple terms, constraints may be challenged by the business analyst, but typically are less negotiable than acceptance criteria. Looked at another way, imposing unnecessary constraints restricts our solution opportunities, which may mean we will not get the ‘best’ solution that we could have.
Acceptance criteria: acceptance criteria set out the conditions that the proposed solution must satisfy. They need to be measurable and described in solution terms. The acceptance criteria come from and describe the desired changes in the business’s operating model and, therefore, should be stated and owned by the business. Analysts are critical to the process of eliciting and specifying acceptance criteria and assessing the cost-risk implications.
The acceptance criteria spotlight completes the floodlight model and further restricts what are acceptable solutions. The intersection between all three lights identifies those solutions that meet the constraints and satisfy the business criteria.
The key difference between acceptance criteria and constraints is that acceptance criteria are negotiable, and the are necessarily owned by the owner of the solution, whereas constraints may be owned by others. (This is also discussed in the ‘More on acceptance criteria’ section.
Part of the value of establishing the acceptance criteria is that they form the basis for final acceptance of the solution by the business owner. The subtext is that ‘if the solution satisfies the acceptance criteria, the business will accept the solution, and manage the impacts to deliver the value’.