You need to find out what the real users need from the system, preferably by talking to them and observing their work. These needs may not be understood by others such as managers. Needs are not the same as wants.
Users and their needs should be understood in terms of their relationships with the system to be designed. We represent users as user roles: abstract collections of needs, interests, expectations, behaviors, and responsibilities characterizing the relationship between a class of users and a system.
The box on "Model Building" p. 8 is good generic advice for the modeling process. To construct a user role model, ask the questions on page 80 of the textbook (bulleted list). You might also consider these web design questions.
Brainstorm a list of candidate roles. Chose names that capture their relationship to the software rather than job titles. But don't be picky about what you call them, and don't be critical about your list until your list of candidates seems to cover the possibilities.
Choose one to three focal roles. These are the roles that are either most common, or critical for some reason specific to the application. These roles will be prioritized in designing the software.
Once you've got a list of candidate roles, sort them into groups of related roles and consider how to simplify the list. (See "Sorting Cards" p. 83.) (Might do this in parallel with structured role models.)
If many types of user roles must be supported, it may help to construct a user role map to show the result of this work. These maps relate users by:
Then fill in the details of the roles by describing their attrributes. I suggest that you use the profiles listed below to describe your user roles, although you are certainly free to change this list and add your own. See form S3A in Appendix D, and the text's description of these profiles:
For both the individual and project assignments, turn in your structured role models and user role map, indicating which roles are focal. Also provide any explanatory narrative you feel is necessary or is requested by the assignment. You may use standard word processing software to write the structured role models (which should look like a filled in form) and standard drawing software to make the role maps. (MS Word has drawing capabilities.)
Here are a few comments from looking over the roles homework -- issues that I encountered repeatedly.
The user roles should be defined in terms of patterns of use of the software to be created. Everyone playing one role uses it a certain way. People playing one role use it in a different way than people playing another role. While it is OK to use job positions or other roles in the human organization as a guide to roles with respect to the software, don't assume that roles in the organization will be identical to usage roles. Merge any roles that seem identical in terms of use of the software.
The structured role descriptions should describe the pattern of software use that characterizes that class of users. Some of you gave roles names and checked off some of the details in the C&L forms, but did not give a narrative description of what characterizes that role.
Don't be arbitrary in your choice of focal roles. Justify (in writing) why you chose the focal roles that you did. Remember that you are writing essential use cases for the focal roles (at least, if not all of the roles), and that you will resolve design conflicts in favor of the focal users. (See also paragraph after next below.)
Be sure you understand the relations (page 85) of affinity, classification, and composition; and that you represent them with the standard notation (page 86). This requires that you change the links a bit in EuCase99.
When you have some roles specializing another, you need to choose whether the abstract role or the specializations will be focal. What are the implications of each choice? I suggest that: