Joy Beatty: If you create perfectly clean blueprints for a house but forget to check that there is a back door, and you end up with a house where your kids have to go out the front door to get to the back yard, are you going to be happy? No! The same is true of requirements and systems. If we have well-written requirements, that certainly helps ensure a complete system, but it does not guarantee it. For example, the development team could overcommit, the well-written requirements might be twice as big in scope as there is budget, and, further, the requirements might not solve the actual business problems.
To address this, we start by understanding the real business problems and business objectives and derive requirements to solve those problems and meet those objectives. In fact, throughout the project, the entire team needs to keep a razor sharp focus on solving those business problems. If they do that, they can help ensure a successful project—a complete system that also delivers business value.
Heather Shanholtzer: If you had to pick one requirements model to recommend, which one would it be and why?
Joy Beatty: This is a tough question because models each serve a different purpose and projects vary so much. However, almost without fail, every project needs a Business Objectives Model, and when it is used, it is the most important model. The Business Objectives Model is what allows us to ensure that every feature developed helps solve the business problems. This model also lays the groundwork for us to be able to drastically cut scope on projects in a quantitative manner, taking the emotions out of scoping decisions.