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.
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.
Expanding scope#section4
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.
This article makes a lot of sense and is useful for “rational” clients. Other clients eat use-cases for lunch and will whittle down your nerves to scattered sawdust and reject all reason like a baby rejects whisky (they prefer milk).
I agree, in that while the majority of clients would find this a useful and approachable way to ensure both parties are clear, there are always going to be some that make it difficult.
However an approach that helps in the majority of cases is by no means a bad thing.
I guess it would always really come down to having a good well worded contract, just in case.
I really enjoyed this series of articles, I would like to see more articles, or at least some links, related to project management and planning. There seems to be so much useful information out there that you never learn in a class. Maybe just a list of suggested books. What do the best project managers do?
Yet another great article!
UML’s strongest point is allowing the devleoper to layout the way an application will function before doing any coding. Using UML as a development tool cuts down on risk and allows clients to get more of a visual representation of how the finished product will function. This allows changes to be made with much less effort, providing more flexibility in the development process.
Being a Management Information Systems major I have learned all about the importance of using UML to help understand system requirements and have a better planned web experience. On to process flows!
I think it is great that ALA is discussing these UML techniques in order to help web designers better integrate their site into the clients business practices and save themselves time during development.
Keep up the great work ALA!
This is all very well for something simple like weblogs but what about more complicated concepts. For instance lets say you have a recutment agency, thus you you have types of visitors, the recuters and recutees: you’re client may also want a recomendation system built in and already the diagram doesn’t fit on a page.
Use-cases really do help bridge the gap between the developers and the client. I’ve tried it before and it works very well.
Not just use-cases but activity diagrams and other great UML applications.
Great article, keep up the good work.
Articles like this concern me a touch. Although the Use Cases can be a powerful tool, they can be dangerous if used by inexperienced people.
Use Cases should be textual and written using a Word Processor. This article does not have a single example of a Use Case scenario written out in full, and there is no mention of Exception cases or Alternate flows. This strikes me as a little odd considering the authors recommend Alistair Cockburn’s book (which is well worth a read by the way).
The focus is on a Use Case Diagram that is only really a side issue to what Use Cases are all about. Maybe Norm Carr & Tim Meehan could be persuaded to do a part three describing both a Fully Dressed and Casual Use Case document? Other forms of Use Case control like Actor Goal lists and Levelling would also be useful.
Anyway, I hope this does not dissuade anyone from investigating Use Cases further. When done well they can save your team huge amounts of time and drastically improve the relationship with your client.
Keep up the great work! But how about maybe a little more elaborate/in-depth?
I see a few more benefits to this model:
1. It gives your site some personality – it is easier to hone in on what the site is FOR and what it ISN’T for.
2. It gives the designer direction and can provide a sense of completion when the goal is attained. This is not very possible in a situation where there are no defined goals.
3. It gives the site functional usage (the site does something tangable for someone). You can always add more functionality to it later, and you can send separate invoices for these services.
Question:
Designers are often in a situation where they are moonlighting and don’t have time to set up these types of scenarios – the client wants a site redesign YESTERDAY and don’t care to listen to our use cases. Let’s face it…a well designed site takes longer to create and could potentially cost the client more money in the short-term. How do we handle client expectations while delivering a quality product from a usability perspective without staying up until 2am every night and under-charging for our services?
Such things are the first things you learn in a project-mngt course.
At work (I’m a junior process engineer) I’ve got the luck to have a Green Belt-training.
The first lesson: The Project Charter: the most important piece of paper, with the terribly important section: project scope!
Quote: Designers are often in a situation where they are moonlighting and don’t have time to set up these types of scenarios – the client wants a site redesign YESTERDAY and don’t care to listen to our use cases. Let’s face it…a well designed site takes longer to create and could potentially cost the client more money in the short-term. How do we handle client expectations while delivering a quality product from a usability perspective without staying up until 2am every night and under-charging for our services?
Exactly. I’ve had clients put money in, pull money out, put money back in. You spend more time planning than anything but the deadlines remain. I guess this works well in the public sector because too many chiefs need bits of paper. Private sector wants results.
I agree with this in that there is an inherent problem with web development: it is too easy to go down the Rapid Application Development route. In fact it is too easy to setup a basic web site, full stop. Simply knock something together, give it a nice polished design and sell it to the client in half the time it would take to develop a proper use-case scenario.
I actually think many clients don’t have the money to pay for things to be done ‘properly’. Using UML, Use-cases and what-not takes time and money. Clients see the guy down the road offering superficially the same service but at half the cost because they ignore all the project management techniques and just ‘get on with it’.
Many clients don’t have the faintest idea of software development of any kind. They won’t see the point and therefore the long term financial benefit to getting their site developed by competent software engineers rather than someone who knows a bit of HTML and is good at design.
What would be fantabulous would be some software that could scan through bare-bones html (especially forms) and 1. Suggest accessibility/usability enhancements (like a spell check), 2. Automatically insert code where told (label tags and other annoying things we do so maticulously), 3. Proofread for validation errors. I could see this being a real time-saver. Maybe there is software that does this, but I don’t know of it. I’d program it myself, but alas…I am but an artist.
This is a good place to start if you want your HTML cleaned up so it will validate. It can also do a number of usability/accessibility tricks (such as add alt attributes to img tags), but this is to be discouraged, since accessibility especially is not something that can be solved via an automated process.
http://tidy.sourceforge.net/
What you’re really asking for is a Frontpage/Dreamweaver application which actually produces valid, usable and accessible mark up. The holy grail of web development and one which will out many people out of a job! Although I am actually very surprised this sort of tool doesn’t exist yet…
Are RAD HTML tools good or bad?
I would say that they are bad. If they did not exist, no one would be able to develop websites with just some design abilities by dragging around some images and having their tool spit out invalid HTML 3.2 People would have to learn HTML more than what is needed to operate some HTML RAD tool. hopefully that would result in them picking up some good things. Most importantly, having no RAD tools would increase the demand for advanced web developers, and there would be no way to be lazy and slap a site together in some tool.
Of course, that is not the case and will never be so as people like writing such applications…
What about the use of flow charts. Is that parctice still usefull in designing dynamic websites or it’s no longer in use or was it never in use?
Just a follow up…
I wasn’t suggesting so much that it would be neat to have a tool to wysiwyg-ify accessibility, but that it would be neat to have a tool that scans your code and suggests things that we can say yay or nay to.
For example…
Software: Scans your code…then says, “Your form fields do not have labels. This will cause a validation error. Would you like to add labels in front of each field?”
You: Click “yes”
Software: Inserts blank labels with no extra code.
You: Edit the labels as needed, save time typing.
Microsoft: Buys software and ruins it because she hates the web.
I’d be interested to hear experiences about how wireframes/storyboards fit into this process. I’ve heard different opinions about it.
Designers are often in a situation where they are moonlighting and don’t have time to set up these types of scenarios – the client wants a site redesign YESTERDAY and don’t care to listen to our use cases. Let’s face it…a well designed site takes longer to create and could potentially cost the client more money in the short-term. How do we handle client expectations while delivering a quality product from a usability perspective without staying up until 2am every night and under-charging for our services?
I think the use of UML really depends on what type of project you are working on. If it is a clean cut website with little database connectivity/complex features then I believe it is fine to skip the UML stuff if time is a factor.
But if they want a complex site with more features and a large amount of database interaction, you must make it clear to the client, the importance of the UML diagrams in a well-planned system. Explain how it will take more time, and more of their money if the system has to be reworked during the development phase.
For more information on this subject, I suggest Rapid Development by Steve McConnell. It is an easy read and I found it very interesting/helpful.
Thank you! Good article and very useful sounding approach. Another article to go into more details would be nice. Cheers, Tony
The discussion on the “extends” and “include” is very clear. However, I’ve seen even software developers misusing them. It’s good that the author stayed away from discussing the “uses” stereotype. UML2.0 actually added more stereotypes to denote relationships between usecase bubbles. See
http://www.holub.com/goodies/uml/index.html
Nice article, I’d like to say thanks for reminding me to use UML more. I’m currently making a recruitment site and I still believe there’s nothing better than really spending quality time with your client. Understand the process, work with the flow. Bring lots and lots of scratch paper and a good pencil. Draw diagrams if you must and go home to document what was discussed.
UML is clearly designed for making processes clear. That’s why we were thought Rational Rose® in college. To understand who does what and where should it all go. Large web projects can definitely benefit from this concept although tried and tested sites that does not require intensive coding/programming would, as others said, just see UML as just another fancy corporate trick that generates more $$$.
Stick with the basics… and you couldn’t possibly go wrong.
wierd, I’m taking Systems Analysis and Design right now, this is a great article for my research. Thanks!
ALA is brilliant, it has really helped me, and I have honestly found it the be the most useful resource on the net..
I wish you guys would give us an update on what is going on… ALA is by far the best resource for CSS and well… all the cool tips and tricks a developer needs to know.