Every software team talks about scope, and project team members often complain about unending scope creep. Unfortunately, the software industry lacks a uniform definition of these terms, and the requirements engineering literature lacks clear guidance on how to represent scope. This article presents some definitions and describes three techniques for defining the scope boundary: the context diagram, the use case diagram, and feature levels.
Vision and Scope
The vision and scope document is a key software project deliverable. Other terms for such a high-level guiding document are project charter, marketing requirements document, and business case. Vision and scope are two related concepts. I think in terms of the product vision and the project scope. The product vision is:
A long-term strategic concept of the ultimate purpose and form of a new system.
Chapter 5 of my book Software Requirements, 3rd Edition describes how to write a concise and focused vision statement using a keyword template. We can then define the project scope as:
The portion of the ultimate product vision that the current project will address. The scope draws the boundary between what’s in and what’s out for the project.
The latter part of the project scope definition is the most important. The scope defines what the product is and what it is not, what it will and won’t do, what it will and won’t contain. A well-defined scope boundary sets expectations among the project stakeholders. It defines the external interfaces between the rest of the world and the system, which could be just a software application or could be a combination of automation elements and manual processes. The scope definition helps the project manager assess the resources needed to implement the project and it helps him make realistic commitments. In essence, the scope statement defines the boundary of what the project manager is responsible for.
Your scope definition should also include a list of specific limitations or exclusions — what’s out. Obviously, you can’t list everything that’s out of scope, as that would be the entire known universe except for the tiny sliver that is in scope for this project. Instead, the limitations should identify capabilities that a reader might expect to be included in the project but which are not. One project that was building a website for a national rugby team included the following scope exclusions for the initial release:
- There will be no virtual or fantasy rugby games via the web.
- There will be no ticketing facilities on the site.
- There will be no betting facilities available.
- The demographic details for newsletters will not be collected.
- Message boards are out of scope for Phase 1.
Some stakeholders in this website project might have expected these capabilities to be included with the first release. Itemizing them as exclusions makes it clear that they will not be. This is a form of expectation management.
The context diagram is a venerable analysis model dating from the structured analysis revolution of the 1970s. Despite its age, the context diagram remains a useful way to depict the environment in which a software system exists. Figure 1 illustrates a partial context diagram for a hypothetical corporate cafeteria ordering system.
The context diagram shows the name of the system or product of interest in a circle. The circle represents the system boundary. The rectangles outside the circle represent external entities, also called terminators. External entities could be different user classes, actors, organizations, other systems to which this one connects, or hardware devices that interface to the system.
The interfaces between the system and these external entities are shown with the labeled arrows, called flows. Flows represent the movement of data, control signals, or physical objects between the system and the external entities. If a “system” is considered to include both a software application and manual operations, then flows could represent the movement of physical objects. However, if the “system” is strictly an automated system, flows should represent data or control signals.
The context diagram shows the project scope at a high level of abstraction. This diagram deliberately reveals nothing about the system internals and it doesn’t identify exactly what features or functionality are in scope. The functional behavior of the system is merely implied by the labeled flows that connect the system to the external entities.
Even the flows are labeled at a high level of abstraction, just to keep the diagram’s complexity manageable. Data flows can be decomposed into individual data elements in the project’s data dictionary or data model. Input/output pairs of data flows suggest the types of transactions or use cases that the system will perform, but these are not shown explicitly in the context diagram.
Despite the limitations that the high level of abstraction imposes, the context diagram is a helpful representation of scope. A business analyst in a requirements course I once taught showed me a context diagram for her current project. She had just shown this to the project manager. The manager had pointed out that a decision had been made to make one of the external entities — another information system — a part of the new system being developed. If the diagram was that shown in Figure 1, this would be comparable to moving the Payroll System inside the circle. That is, the scope of the project just got larger. This BA had expected that external system to be someone else’s responsibility but now it was her problem. The context diagram provides a tool to help the project stakeholders communicate a common understanding of what lies outside the system boundary.
Use cases have are a powerful technique for exploring user requirements. The Unified Modeling Language includes a use-case diagram notation. Figure 2 shows for a partial use-case diagram for our cafeteria ordering system.The rectangular box represents the system boundary, analogous to the circle in a context diagram. The stick figures outside the box represent actors, entities that reside outside the system’s context but interact with the system in some way. The actors correspond approximately to the external entities shown in rectangles on the context diagram.
Unlike the context diagram, the use case diagram does provide limited visibility into the system internals. Each oval inside the system boundary represents an individual use case — literally, a case of usage — in which actors interact with the system to achieve a specific goal.
The arrows on the use-case diagram indicate which actors participate in each use case. Arrows do not indicate flows, as they do on the context diagram. An arrow from an actor to a use case indicates that that primary actor can initiate the use case. An arrow pointing from a use case to an actor means that that secondary actor participates in the successful completion of the use case. In addition to showing these connections to external actors, a use-case diagram could depict logical relationships and dependencies between use cases.
The use case diagram provides a richer scope representation than the context diagram because it provides a high-level look at the system’s internals, not just its external interfaces. There is a practical limitation, though. Any sizeable software system will have dozens of use cases with many connections between actors and each other. It quickly becomes unwieldy to show all those objects inside a single system boundary box. Therefore, the analyst needs to model groups of related use cases or create multiple use-case diagrams at various levels of detail. This gets away from the simplicity of having a single diagram that shows the objects on both sides of the system boundary.
Customers, marketers, and developers often talk about product features but the software industry doesn’t have a standard definition of this term. I consider a feature to be:
A set of logically related functionality that provides a capability to the user and enables the satisfaction of a business objective.
We can think of each product feature as having a series of levels that represent increasing degrees of capability or feature enrichment. Each release of the product implements a certain set of new features and perhaps enhances features that were partially implemented in earlier releases, beginning with the top-priority levels of the top-priority features. One way to describe the scope of a particular product release, then, is to identify the specific level of each feature that the team will implement in that release. A sequence of releases represents increasing levels of capability — and hence user value — delivered over a period of time.
To illustrate this approach to scope definition, consider the following set of features from our cafeteria ordering system:
FE-1: Create and modify cafeteria menus
FE-2: Order meals from the cafeteria menu to be picked up or delivered
FE-3: Order meals from local restaurants to be delivered
FE-4: Register for meal payment options
FE-5: Request meal delivery
FE-6: Establish, modify, and cancel meal service subscriptions
FE-7: Produce recipes and ingredient lists for custom meals from the cafeteria
Figure 3 illustrates a feature roadmap, the various levels for these features that are planned for implementation in forthcoming releases. FE-2 and FE-5 in Figure 3 represent features having three enrichment levels each. The full functionality for each of these features is delivered incrementally across the three planned releases.
The feature level approach is the most descriptive of these three techniques for defining the project scope. The analyst can also indicate dependencies between features or feature levels. For example, the level of FE-2 scheduled for Release 1 is expected to let users pay for meals by payroll deduction. Therefore, the capability of FE-4 that lets users register for payroll deduction payments cannot be deferred to a later release.
A visual way to depict this same information is with a feature tree. In a feature tree, features and subfeatures are shown in a branching tree diagram similar to a fishbone diagram, as illustrated in Figure 4. You can use different colors to distinguish those features that are allocated to specific releases or development iterations. See my article “Using Feature Trees to Depict Project Scope” for more detailed information on this useful technique.
The farther into the future you look, the fuzzier the scope plans become and the more you can expect to adjust the scope as project and business realities change. Nonetheless, defining the product vision and project scope lays a solid foundation for the rest of the project work. This helps keep the team on track toward maximizing stakeholder satisfaction.
This article is adapted from Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty. If you’re interested in software requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources. Karl’s latest book is The Thoughtless Design of Everyday Things.