Every product development team talks about project scope and team members often complain about unending scope creep. The vision and scope document, otherwise known as the MRD (marketing requirements document) or business case, is a key deliverable in defending against scope creep. You don’t necessarily need a standalone vision and scope document for a small project. Any project of any size, though, will benefit from such strategic guidance, even if it’s just a paragraph or two at the beginning of the requirements specification.
Vision and Scope
Both the vision and the scope are components of the project’s business requirements. I think in terms of the product vision and the project scope. I define the product vision as: “A long-term strategic concept of the ultimate purpose and form of a new system.” The product vision could also describe the product’s positioning among its competition and in its market or operating environment.
A well-defined scope sets expectations among the project stakeholders. It identifies the external interfaces between the system and the rest of the world. The scope definition helps the project manager assess the resources needed to implement the project and make realistic commitments. In essence, the scope statement defines the boundary of the project manager’s responsibilities.
Your scope definition also should include a list of specific limitations or exclusions—what’s out. Obviously, you can’t list everything that’s out of scope because that would include every detail in the universe except for the tiny sliver that is in scope for your project. Instead, the limitations should identify capabilities that a reader might expect to be included in the project but which are not included. I know of a project to build a Web site for a national sports team that included the following exclusions for the initial release:
- There will be no virtual or fantasy 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 involved with this project might have expected these capabilities to be included. Itemizing them as exclusions makes it clear that they won’t be. This is a form of expectation management, an important contributor to project success.
Context Diagram
The venerable context diagram dates from the structured analysis revolution of the 1970s. Despite its antiquity, 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 circumference of the circle represents the system boundary. Rectangles outside the circle represent external entities, also called terminators. External entities could be user classes, actors, organizations, other software 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 labeled arrows, called flows. If the “system” is strictly an electronic system involving software and perhaps hardware components, flows will represent data or control signals. However, if the “system” includes both a software application and manual operations, flows could also represent the movement of physical objects. Two-headed flows indicate update operations involving the data object on the flow.
The context diagram depicts the project scope at a high level of abstraction. This diagram deliberately reveals nothing about the system internals: no information about functionality, architecture, or look-and-feel. Nor does it explicitly identify which features or functionality are in scope and which are not. 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.
Despite the limited view that the high level of abstraction imposes, the context diagram is a helpful representation of scope. It serves as a tool to help the project stakeholders communicate about what lies outside the system boundary.
Use Case Diagram
Use cases are a powerful technique for exploring user requirements. The Unified Modeling Language (UML) includes a use case diagram notation. Figure 2 shows 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 (exactly, in this example) to the external entities shown in rectangles on the context diagram.
Unlike the context diagram, the use case diagram does provide some visibility into the system. Each oval inside the system boundary box represents a use case. The use case diagram shows the interactions of the system with its users and some connections between internal system operations, albeit at a high level of abstraction.
The arrows on the use case diagram indicate which actors participate in each use case. In Figure 2, the arrow from the Patron to the oval labeled “Submit Feedback” means that the patron actor can initiate the Submit Feedback use case. The arrow from Submit Feedback to the Menu Manager actor indicates that the Menu Manager participates somehow in the execution of Submit Feedback. Arrows on the use case diagram do not indicate data flows as they do on the context diagram. 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 capabilities, not just at its external interfaces. There is a practical limitation, though. Any sizeable software system will have dozens of use cases, with many connections among them and between use cases and actors. Attempting to show all those objects inside a single system boundary box quickly becomes unwieldy. Therefore, the analyst needs to model groups of related use cases as packages or to create multiple use case diagrams.
Many analysts have found the context diagram and use case diagram to be helpful ways to represent and communicate a shared understanding of a project’s scope. In Part 2 of this series, I’ll describe two other techniques for defining scope, feature levels and system events.
Check out Part 2, Defining Project Scope: Feature Levels and System Events
Check out Part 3, Defining Project Scope: Managing Scope Creep
Learn how product development teams can leverage analytics to improve efficiency and quality in “The Essential Guide to Software Development Team Metrics.”