In case a brochure-like website, there is little that the website typically does from the user's (website visitor's) prospective. The visitor browses the website, perhaps he subscribes for a newsletter etc. From my prospective, there would still be Use Cases, but very few of them (e.g. "Browse the site", "Subscribe for newsletter", "Request a quote" etc.)
As websites (NOT web applications!) by their definition are rather static and do not provide much of a functionality, Use Cases cary much less information. Clients tend to think about websites in static terms also (e.g. what does the website LOOK LIKE, or what IS on the website as opposed to what the website DOES). I do see a value in making clients to think in terms of Use Cases anyway as the UCs are a good tool in setting up the scope (e.g. "Subscribe for newsletter" - does the client want the website to have this functionality? And shoud it work like this?).
In case of a website though, there will likely be very simple scenarios, the core of what the client wants will have form of a requirement (likely external one as many typical website-related requirements will affect most of the Use Cases).
Reading this after myself, I am probably not making much of a sense. So here is the bottomline:
- Yes, I think the Use Cases do provide value even for a brochure-like website (even though they will be much simpler than in case of a heavily process-oriented application)
- No, I would not try to hide Use Case from the clients as the Use Cases can help the clients to realize what do they want the website to DO
- Expect number of requirements attached to your Use Cases, such as "The website has to reflect the company colours" or "The website must have both Swahili and Yoruba language version"
Hope this helps.
Bruno
