Good scope before requirements
The earlier you define scope, the more efficient your requirement definition process will be. Work done before scope definition is usually wasted effort. An early scope definition keeps requirements writers from diverging, reduces requirement inconsistencies, and keeps the big picture in view. It also shortens the time required for requirement writing and rewriting and reduces debates.
If you do not give everyone writing or reviewing requirements your scope definition, they are likely to create their own. Imagine listening to a movie without watching it – as I have done many times on trips in the SUV listening to a movie several times but never seeing it as it’s playing in the DVD player behind my head. I have a vision – my own vision – of what’s going on and what the characters look like and what the set looks like, but if no one describes it to me in detail or I don’t see it for myself then that’s all it is … my own vision. And it likely differs greatly from the actual film itself.
Each individual team member’s scope definition is likely to differ significantly from yours. No two team members will have the same scope definition. The result will be requirements written and reviewed from very different points of view – different goals, objectives, constraints, assumptions, operational concepts, and ultimately systems. Battles will be fought, not about requirements, but about these basic precepts. You will end up with incomplete and conflicting requirements. Your project will be undoubtedly go over budget and off schedule and you will likely not deliver the project or product your customer is seeking.
If you guide your team through scope definition before anyone writes a requirement, you will prevent divergent and inconsistent requirements. You will reduce rework and wasted effort, which translates directly into reduced time and cost.
Defining and documenting scope pays dividends throughout your product or project life cycle, not just in requirement definition. The scope definition provides a lasting big picture reference for you and your team. It prevents you from losing sight of important constraints as well as customer needs. Long after requirement definition is officially complete, the scope definition will provide vision to the customer, designers, reviewers, testers, and maintenance personnel. This vision will enable these people to correctly understand the requirements in spite of their diverse backgrounds and knowledge bases.
What is scope?
Scope is a definition of what is pertinent to your project. If includes needs, goals and objectives, missions or business cases, high-level operational concepts, major assumptions, constraints like schedules and budgets, and authority and responsibility. The relative importance of these items depends on the project and the customer, but all of these items most likely need to be covered at some point in the process. On most projects, you’ll need to go through several iterations before drilling down too far in the requirements definition and you can fill in details as requirement definition progress makes the vision clearer.
The information based somewhat on information from Hooks and Farry’s book “Customer-Centered Products.”