Identifying Your Audience
A use case is a particular purpose that a user can actually use the system to accomplish. Use cases achieve their great power primarily by simplicity and organization: When you identify and organize use cases, you can paint a clear picture of what the system has to do. You can show this clear picture to your customers, users, management, and peers—which can help you get invaluable, focused feedback on your ideas for the system early in its process of development.
 |
Considering the needs of the clients and their customers and workers is a good start, and although the use case’s focus on actors does help you consider their needs, it’s not enough. We recommend that you also acknowledge the existence of stakeholders (the many individuals and organizations that have a vested interest in the success of your project). Every system has a set of these potential stakeholders—individuals or organizations affected by the operation of your system (or who may affect the operation of your system). The stakeholders are the sources of your funding, your requirements, and your opposition. They are your fans and opponents. Even within these groups, subgroups whose opinions matter must be identified.
As an example, if you examine the workers, the stakeholders include those who will use your system and those who have used the previous system. Also, consider those workers whose jobs you automate, change, or eliminate. If you examine your own organization, the different types of developers have their own stakes in the project.
Anyone who cares about the success of your system or who can derail it is a stakeholder. The authorities (legal, regulatory, industry, political, trade, and so on), lobbies, and special-interest groups are also stakeholders.
Are hackers and terrorists also stakeholders, then? After all, they can certainly derail your system. Well, not normally. Some companies do explicitly treat the bad guys as stakeholders—and sometimes even model them as actors—but that’s a part of threat analysis. For a normal assessment of stakeholders and their needs, concentrate on identifying individuals, teams, and groups who represent political and economic forces that have legitimate vested interests (stakes) in your system.
During the process of gathering the requirements for your system, you’ll be spending most of your time with the actors—but you must consider all the stakeholders. Diagram the actors with their use cases, but examine the stakeholders also. Prioritize them by their potential impact on the system as you evaluate their needs. The more you satisfy your stakeholders’ needs, the smoother sailing your system will have, and acceptance and follow-on will be high.
|
To get an accurate picture of your system’s purpose, you must identify whom the system is for (your customer) and who uses the system (the users).
Remember The users and the customers are generally not the same group of people. Even when they are the same people, it’s beneficial to think of user and customer as different roles.
-
Your customers: Your customers—sometimes called the clients—are the people or organizations that ultimately fund and task your team. They must be satisfied for you to get paid. Your team may have a contractual relationship with them (external customers), or they may be part of your own management structure (internal customers). When you’re in an in-house development organization, consider your parent organization as your client.
-
The client’s customers: When you talk about the customers (as opposed to your customers), you typically are referring to the customers of your client. These are the people or organizations that buy things from your client. If your system doesn’t make them happy, your client is unhappy, and that means you’re unhappy.
-
Users: When you refer to users of a system, they may be your clients’ customers, or they may be the workers in your client’s organization who have a hands-on relationship with the system. Many systems have users of all types—clients, their customers, and their workers. Users get the closest feel for the system—and get the strongest impressions. The tasks of the users are what the system must automate; the needs of the users are what the system has to meet.
UML has a special term for the users, whether they’re clients, customers, or workers: actors. The actors initiate behaviors in the systems and receive information from the system.
Imagine you’re building a hotel registration system to be used by both potential guests from home (via the Internet) and by registration clerks at the hotel when the potential guests phone them. Table 8-1 lists the main stakeholders on this project. (The nearby sidebar “Consider the stakeholders” provides more information on stakeholders.) In the table, Potential Guest appears as twice as a stakeholder—once in the role of customer (when the actor is Registration Clerk), and once as an actor who uses the system directly via the Internet. Such duplication happens often when there are optional intermediary workers (such as Registration Clerk).
| Stakeholder Group | Example |
|---|---|
| Client | Hotel Chain |
| Customer | Potential Guest |
| Actor (Worker) | Registration Clerk |
| Actor (Customer) | Potential Guest |
EAN: 2147483647
Pages: 193