Developing an understanding of what users need from software to support their work requires a dialogue between designers and users. Neither will know for sure at the outset.
Task models represent this evolving joint understanding. They should be understandable to users, so that they can serve to clarify and coordinate communication between users and designers. They should focus on the essential aspects of the system's purpose, not incidentials, and should not make assumptions about the yet to be designed interface. Some inadequate alternatives:
Scenarios are informal narratives of the interaction between a user and a system. They are easy to understand, but mix specific details with general information.
As portrayed in the text, these provide a structured narrative of the interaction between a user and a system in terms of user actions and system responses. However, the actions and responses tend to make premature assumptions about the design of the interface.
Essential use cases are also structured narratives of the interaction between a user and the system, but they are stated in terms of the user purpose (the name of the use case) and abstract user intentions and system responsibilities (represented in aligned columns). They are written in language that users can easily understand, so they support the dialogue between designers and users. By being written in terms of intentions and responsibilities they avoid premature committment to interface details. See the definition p. 103.
As with any kind of modeling it is best to brainstorm many essential use cases first before organizing and refining them.
Develop your essential use cases by looking at your role models and asking what the users in each role are trying to accomplish, what they should be able to do to accomplish it, and what software capabilities are needed to support them. (See bulleted items page 116.)
Make sure you have at least one use case per role model, and pay special attention to the focal roles. Identify focal use cases, which typically are the most important use cases supporting focal user roles.
Some people have trouble going directly to abstractions. If you find it hard to write essential use cases directly, try writing scenarios first and then abstracting out the essential use cases.
If you can, develop use cases in collaboration with your users. At the least, show your use cases to users after you have developed them.
As with user roles and role maps, once we have some essential use cases we need to organize them. The text describes these relations and associated graphical notation:
When doing assignments (individual or project) involving essentail use cases, I want to see both the tabular representation of the use cases and a use case map. You may use standard word processing and drawing software to accomplish this.