In every article or book* about how to write use cases, you’ll read that you must not include UI details in use cases. Use cases should describe the functional requirements of the system, what the user is trying to accomplish, rather than how to do it. If you’ve identified them correctly, the user’s goals are not going to change much throughout the development process. Details about fields, screen layouts and screen flow are, and should, change more regularly as you refine your design.

After you’ve written a number of use cases, and have started drafting the screen flow and some screen elements, it’s harder to keep all UI references out of the use case. Referring to a particular screen by name, if you’re fairly certain that it’s not going to change, is usually OK. After working on a number of systems, the general pattern becomes familiar. I’ve used this approach many times, and it has saved time and hasn’t caused too much rework as things change. The key is knowing when the design is relatively stable.

But lately I’m finding that this practice is more dangerous because the applications that I’m working on use some sort of Ajax or Web 2.0 (or whatever you want to call it) features. I can no longer count on a number of individual screens, or having to wait until an input form is complete and submitted in order to validate the contents. Any screen element can be modified without a page refresh, and sometimes the entire application consists of a single page and a whole lot of Javascript.

In this type of environment, it becomes more important to focus on the user’s goals and functional requirements. And I’ve found that without a predictable set of screens and UI actions, writing the use case becomes easier. I’m forced to include only they key elements of what the user is trying to do. This makes the use cases simpler and more focused–like they should be.

* If you’re looking for a book on use cases, the one to get is Writing Effective Use Cases by Alistair Cockburn.

Recent posts by Kevin

• Lightweight Requirements Management with Confluence - March 12th, 2010
• Shorter Requirements are Better - July 7th, 2009
• Reports are requirements too - April 3rd, 2009

Related posts

• Shorter Requirements are Better When writing requirements documents, it’s tempting to add more &...
• Reports are requirements too Reporting requirements are often put off until the end of...
• Lightweight Requirements Management with Confluence It’s common for project teams to document and manage their...