When web projects go wrong, the cause can often be traced to misunderstanding and miscommunication about scope: what you thought your client wanted and what they thought they were getting doesn’t match. The later in a project this is discovered, the costlier for someone it can become.
Article Continues Below
To manage scope effectively, we have to define what the site must contain, what optional features would be good to have, and what features are irrelevant – and then we have to deal with newly requested or discovered needs and enhancements.
The use-case model can be a powerful tool for controlling scope throughout a project’s lifecycle. Because a simplified use-case model can be understood by all project participants, it can also serve as a framework for ongoing collaboration as well as a visual map of all agreed-upon functionality. It can, therefore, be a precious reference during later negotiations that might affect the project’s scope.
We habitually storyboard new functionality for customers so that they can see the consequent increase in complexity. By doing so, we define options for the customer and then decide which bits of proposed functionality are the most important. We also use use-case diagrams to establish boundaries for the project; any use cases devised for the site later on are obviously change requests that add extra effort and therefore increase the project’s cost.
Let’s return to our previous example of a hypothetical weblog’s use cases and elaborate a little to see how simplified use cases can help us understand and manage project scope.
The following sections assume that you’ve read our previous article, which introduced the ways in which simple use cases can help us describe a website’s purpose and goals. If you haven’t read it yet, you should probably do so now.
Mapping scope boundaries#section2
Even very early in a project’s evolution, the use-case model can provide a useful visualization of the project’s scope. The “Search Content” use case, for example, clearly identifies a goal that will need to be satisfied by specific functionality.
The use-case model also shows that no other project elements depend on “Search Content,” so we can discuss implementing this feature independently of “Publish Weblog.” We might use our own database, or we might delegate functionality to a third-party, such as Google. [A List Apart uses Atomz Search. – Ed.]
The use-case model allows us to see that this decision shouldn’t have any impact on decisions concerning the rest of the project’s scope. In this way, use cases enable the identification of scope boundaries.
Exploring scope options#section3
We recognize that the use-case goal of “Publish Weblog” represents only the most fundamental functionality of our application. Scenarios inside “Publish Weblog” will only include essential tasks like creating new content, editing, and deleting.
As our ideas evolve, we need a way to describe use cases that are enhancements to the project’s core idea. The ability for visitors and authors to leave comments is one obvious such enhancement, so let’s create a new use case: “Leave Comment.”
The <
We might devise other use cases that could extend “Publish Weblog”: “Categorize Content,” perhaps, or maybe “Skin Content” for the ability to change look and feel. Each extension use case can be considered as a self-contained portion of the entire project scope.
As we identify more enhancements, the scope of our project expands – but because our model provides a clear picture of the relationships between use cases, we can make intelligent decisions on how to prioritize the implementation of each use case.
Say we’ve now decided that we must to require visitors to register before commenting so that we can monitor and control comment abuse.
Since this is now a required feature and not an option, we’ve added a whole new level of development effort. The “Publish Weblog” use case has now become dependent on the “Control Access” use case. We can indicate that the dependence of “Publish Weblog” on “Control Access” is an essential requirement by the <
Notice, however, that the new scope is an addition to, not a replacement for, the earlier model. Just as in the model’s previous state, we’re able to consider scope in for the discrete parts identified by the use cases. The implementation plan for “Control Access” can be devised without requiring the re-evaluation of the implementation of existing scope. Complexity is under control.
Controlling complexity#section5
Our bare-bones example is now ballooning into something that begins to resemble a real-world web project. As more use cases are identified, the level of effort they represent – the project scope – expands.
The use-case driven approach to establishing project scope and requirements has demonstrated several advantages over more ad hoc practices:
- The diagrammed model quickly communicates the scope “story” in an accessible way. Everyone involved has a common foundation for the discussion of architectural and design options.
- When resources are limited (when aren’t they?) the use-case model helps us make intelligent decisions about implementation priorities.
- The effects of requested changes and enhancements on the overall level of effort can be assessed objectively.
- A modular design framework has been established up-front.
Cost and time overruns are where projects become vulnerable, and up-front estimation is always a difficult task. A solid understanding of scope early a project (combined with previous development experience) can help control the risks inherent in cost and time estimates.
The use-case approach to scope helps to clarify and document early discussions of a project’s reach, improving communication and facilitating collaboration. Since a client-approved scope story can provide a framework for discussions about options, complexity, and pricing, it can even be considered a part of the contract between creator and customer.
