Establishing the Vision for Use Case Modeling

This chapter is from the book

Use Case Modeling

Learn More Buy

This chapter is from the book

This chapter is from the book 

Use Case Modeling

Learn More Buy

Too many project teams dive into the details of the use-case model before they have established a stakeholder community, a shared vision, the real need for the product, or the constraints under which it is to be built. Proceeding with use-case modeling without this kind of foundation often causes immense problems. Some projects are completed before the team realizes that the system produced doesn't meet any of the stakeholders' real needs. Other project teams find it impossible to produce a stable use-case model or even to agree on one at all.

To avoid these kinds of problems, it is essential that the team:

• Establish a good understanding of the stakeholder community

• Demonstrate an understanding of the problem to be solved

• Capture the real needs of the stakeholders and the system features required to fulfill them

• Ensure that the views of the stakeholder community are actively and appropriately represented throughout the project

In this chapter we look at strategies that will help you in these activities and the positive effect that this will have on the quality of the use-case model you produce.

In Chapter 1, we briefly introduced the concept of the requirements pyramid, as shown in Figure 3-1, to clarify the role, purpose, and context of use cases. In this chapter we look more closely at the other elements of the requirements pyramid, discuss how they can be captured, and describe how they affect the construction and detailing of use-case models.

Figure 3-1. The requirements pyramid: Our map of the territory

Introducing stakeholders and users

Before you start any use-case modeling or other requirements-management activity, you must understand the project's stakeholder community and how it will be involved in the project. You must understand the stakeholder community in order to tackle the following tasks:

• Establishing an understanding of the problems the project should be addressing. This is very hard to do without first identifying who is affected.

• Preparing for a requirements workshop. If a workshop is to be run to identify the system's actors and use cases, then the coordinator needs to know who to invite and which aspects of the business the invitees represent.

• Identifying the sources of the system's requirements. Requirements come from many sources, including, but not limited to, customers, partners, users, and domain experts. Understanding these sources of requirements will allow the project team to decide how best to elicit information from them.

To deliver an effective solution, one that will be wholeheartedly accepted by the stakeholder community, you must have a clear understanding of the stakeholders and their particular needs. It is also important that the people asked to become involved in the project understand the role that they are expected to play and the responsibilities that they are expected to fulfill.

In this section we will look at:

• The definition of a stakeholder

• Why stakeholders are important

• The role of stakeholders in the project

• Why it is necessary to explicitly identify users, stakeholders, and actors.

• How to identify and involve the stakeholders in the project

• The relationships among stakeholders, users, actors, and use cases

What Are Stakeholders?

A stakeholder is

An individual who is materially affected by the outcome of the system or the project(s) producing the system.¹

Using this definition, some obvious stakeholders spring to mind:

• The users of the system. If the users are not materially affected by the outcome of the system, they won't use it and the system itself will be a failure.

• The development team. If these people are not materially affected by the outcome of their project and the system that it produces, there is probably something amiss with the commissioning organization's reward structure.

The full set of stakeholders will actually be larger than this. For example, the people who suffer from the problem being addressed are also stakeholders, regardless of the kind of solution chosen.

The decision to develop a system will often affect a great many other people. For example, the decision to invest in a new system involves the investors themselves in the success of the system; the decision by the development team to use third-party software in their solution will involve the suppliers as additional stakeholders. Although these people may not be directly affected by the original problem, they are affected by the outcome of the project. Figure 3-2 sums up the relationship between the stakeholders and the problem and its solution.

Figure 3-2. The stakeholder community is made up of those people that suffer from the problem and/or are materially affected by the outcome of the solution.

There can be millions of stakeholders for even the smallest project. Consider for a moment the simple telephone system discussed in the first two chapters. Everyone who uses, or potentially could use, the system is a stakeholder. If you take into account all those who could be materially affected by the outcome of the system, the stakeholder community must also include

• The company's customers: the people who will be paying the bills

• Other telephone companies: the suppliers of the other telephone systems involved in making long-distance calls

• The other companies' customers and users

And so on.... It is obviously impossible to identify all of these people as individuals and involve them all in a project. However, it is entirely possible (not to mention good practice) to put in place a mechanism to allow us to understand the views of all the different types of stakeholder and to ensure that they are all represented in the project's requirements and decision-making process.

Identifying Stakeholder Types

The first step to understanding the stakeholder community is to identify the types of stakeholder affected by the system.

Stakeholder Type: The classification of a set of stakeholders sharing the same characteristics and relationships with the system and/or the project that produces the system.

In the phone system example, users, customers, customer support representatives, technical support staff, developers, marketers, other telephone companies, and the customers of other companies are all candidate stakeholder types for the project producing the simple telephone system.

Stakeholders typically fall into the following categories:

• Users: The most obvious types of stakeholder are the actual users of the system. These are the people who will be taking on the roles defined by the actors in the use-case model.

• Sponsors: The business managers, financiers, shareholders, champions, department heads, sellers, marketers, steering committee members, and other people who are investing in the production of the system. These stakeholders are only indirect users of the system or are affected only by the business outcomes that the system influences. Many are economic buyers for or internal champions of the system.

• Developers: Project managers, system maintainers, testers, support staff, designers, coders, technical writers, production staff, and any other types of developer involved in the production and support of the system.

• Authorities: Experts in a particular aspect of the problem or solution domain. These include legislative authorities, standards organizations, organizational governance departments, external and internal regulatory bodies, domain experts, and technology experts.

• Customers: The people and/or organizations who will actually be purchasing the final system. These can include the buyers, evaluators, accountants, and agents acting on behalf of the purchasing organizations.

The actual list of stakeholder types for a project will be more concrete than this; it will identify specific user types, agencies, and organizational units. The key thing is to ensure that all those affected by the outcome of the system are considered. When identifying the stakeholder types, focus on understanding how they are affected by the project and the system it will produce.

Identifying Stakeholder Representatives and Stakeholder Roles

The next step is to define a set of stakeholder roles within the project that enable the views of all the stakeholder types to be represented. Appropriate people can then be recruited to fulfill these roles. The objective is to recruit a set of stakeholder representatives to be directly involved in the project.

Stakeholder Representative: A member of the stakeholder community directly involved in the steering, shaping, and scoping of the project. A stakeholder representative represents one or more stakeholder types.

Before you can recruit an appropriate set of stakeholder representatives, you must define how these representatives will participate in your project.

Stakeholder Role: The classification of a set of stakeholder representatives who share the same roles and responsibilities with respect to the project.

The definition of the stakeholder roles allows the stakeholder representatives to understand the commitment they are making to the project, the responsibilities that they are taking on, the level of involvement they will be required to provide, and who they are representing. When identifying the stakeholder roles, you are interested in understanding how they will interact with the project as well as which subset of the stakeholder types they represent. It is important to ensure that each type of stakeholder is represented and that their representation is at a level that reflects both the importance of the stakeholders to the project and the capabilities, and availability, of the representatives.

Some methodologies go so far as to explicitly define a set of stakeholder roles to complement the more commonly defined developer roles. For example, the Dynamic System Development Method (DSDM)² explicitly defines the following stakeholder roles as essential to any user interface-intensive project:

• Ambassador User: Responsible for bringing knowledge of the user community into the project team and disseminating information from the team back to the rest of the users. The ambassador users act as the major source of requirements to the project.

• Advisor User: Responsible for representing users not covered by the ambassador users. Typically part of a panel of staff that attends workshop-style demonstrations of prototypes. Outside prearranged events, the Advisor Users channel their information and feedback through the Ambassador Users.

• Visionary: Responsible for ensuring that the right decisions are made with respect to system scope and that the original business objectives of the project are met.

• Executive Sponsor: Responsible for project funding. Executive spon-sors are the ultimate decisionmakers in the business area.

That stakeholders play four critical roles further underscores the importance of achieving the correct level of stakeholder involvement in modern software development practices. (By way of contrast, only two developer roles have been defined: Senior Developer and Developer.³)

It is impossible to define a useful, universally applicable set of stakeholder roles. These generic roles will inevitably be too abstract to be useful as anything more than a checklist (that is, how many user types does each ambassador user represent and how exactly do you involve them in the project?). We recommend that you instead perform a formal analysis of the stakeholder types and define a specific set of concrete stakeholder roles. This significantly increases the chances that you will secure a sufficient and appropriate level of stakeholder representation and involvement in the project. (Remember that for a large-scale project there could be many millions of stakeholders, far too many to directly involve in the development project.)

In most projects, the term stakeholder is used to indicate the set of stakeholder representatives directly involved in the project. Little thought is given to the broader stakeholder community and to the fair representation of their views. Because stakeholder representatives can play a much more significant role than they are sometimes given credit for, it is well worth your effort to ensure that they understand both their responsibilities to the project and to the people they represent.

The practicalities of defining stakeholder types and stakeholder roles are covered in the section Involving Stakeholders and Users in Your Project later in this chapter. This section also explains how to recruit stakeholder representatives and suggests ways to involve them throughout the project.

The Role of Stakeholders and Stakeholder Representatives

Stakeholders and stakeholder representatives own the problem and are affected by the proposed solution. They are also the primary source of requirements. Figure 3-3 illustrates this relationship. The problem itself being fairly intangible, it is the stakeholder representatives that bridge the gap between the problem and the specification of the proposed solution. The requirements documentation itself is a formal articulation of the stakeholders' goals and acts as their sur-rogate on the project when the stakeholder representatives themselves are not available. Figure 3-4 sums up the relationships between the stakeholders, the system, and the requirements documentation.

Figure 3-3. The stakeholders are the primary source of requirements.

Figure 3-4. The requirements act as the representation of the stakeholders' goals.

Consider which stakeholder types will be the sources of the requirements when defining stakeholder roles and appointing stakeholder representatives. All stakeholder types must be represented, but it is important to focus attention where it will receive the best return. For example, shareholders are a type of stakeholder, but they will not provide many, or any, requirements to the project. Although their interests should certainly be considered and represented, the project team should focus on addressing the requirements of the more direct stakeholders, such as users and developers. The makeup of the set of stakeholder representatives should reflect the relative importance of the stakeholder types as requirements sources.

The stakeholder representatives who will act as the primary source of requirements information must be directly involved in the project and have a clear understanding of the role that they are expected to play. Many projects run into trouble because the stakeholder representatives are not actively engaged in the project and do not provide feedback when it is needed. Stakeholder representatives' indifference may manifest itself by their unavailabil-ity when eliciting project requirements, not making time to review and sign off on project deliverables, not committing themselves for the full lifetime of the project, or just plain forgetting why they are involved in the first place. The quality of the final result is often directly derived from the quality of the participation of the stakeholders.

To combat this, clearly define the stakeholder roles and ensure that stakeholder representatives understand their roles and their responsibilities in representing different stakeholder communities. The role of stakeholder representative includes but is not limited to the following:

• Faithfully representing the views and needs of the section of the broader stakeholder community they represent

• Taking an active role in the project

• Participating in requirements and other project reviews

• Participating in the assessment and verification of the product produced

• Attending workshops and meetings

• Doing independent research

• Championing the project to the stakeholders they represent

There are many ways of involving the stakeholder representatives in the project. If you are developing an information system to be used internally within your company, you may include people with user experience and business domain expertise in your development team. Very often you will start the discussions with the business needs and corresponding processes rather than with the system requirements. Alternatively, if you are developing a product to be sold to a marketplace, you may make extensive use of your marketing people and tools such as questionnaires and surveys to better understand the needs of customers in that market.

Each and every project requires focused stakeholder involvement. For all projects:

• Active stakeholder involvement is imperative.

• A collaborative and cooperative approach involving all the stakeholders is essential.⁴

Remember: The stakeholders own the problem and are the source of the project's requirements. If the system is not a success with the stakeholders, then it is not a success, period.

Users: A Very Important Class of Stakeholder

We now focus on one important type of stakeholder: system users. Users will play most of the roles defined by the system's actors, and their requirements help to shape the use-case model. Every user is a stakeholder, because he or she will be materially affected by the outcome of the system, but not all the stakeholders are necessarily users.

In Chapter 2 we discussed the difference between users and actors. Even in our simple telephone system the difference between the users and the actors is quite clear. The actors define roles, whereas the same user could play many roles. In some cases the caller (the person making the phone call) will be the customer (the payer of the bills). In some cases (if reversing of charges is supported) the person being called could be the customer.

To fully understand the user environment and provide context for the actor definitions, you must undertake a detailed analysis of the various types of users.

User Type: The classification of a set of users with similar skill sets and other characteristics who share the same roles and responsibilities within the system's environment.⁵

A User Type is a fine-grained definition of a particular stakeholder type. Having a full profile of each user type is essential so that you can understand their skill set, attitude, language, and other characteristics. When dealing with the more abstract concept of actors, it is very easy to forget that actual users may have varying skill levels and capabilities.

Some user types⁶ for the simple telephone system example are

• Technology Adopters— Many of the potential users are technology adopters interested in exploiting the full set of facilities provided by the system, especially text and e-mail capabilities.

  • Characteristics: High-volume users of the system. Technology adopters currently make up 40 percent of the company's customer base. They are typically young and highly influenced by trends, fashion, and marketing.

  • Competencies: Technically literate, happy to learn complex operating procedures to set up and use their systems. Have e-mail accounts and other on-line facilities.

  • Success Criteria: Reliability, range of functionality, and low cost of additional facilities.

  • Actors: Caller, Callee, and Customer.

• Standard Users— A large subset of the existing user community having no interest in exploiting the technical capabilities of the telephone network and requiring a simple system that functions in the same way as traditional telephone systems.

  • Characteristics: Low-volume users of the system. Standard users currently make up 60 percent of the company's customer base. They are typically older and resistant to trends, fashion, and marketing.

  • Competencies: Would like to use the more technical features of the system but are frustrated by having to learn complex operating procedures to set up and use their systems.

  • Success Criteria: Reliability, ease of use for traditional features, no increase in cost for, or imposition of, additional facilities.

  • Actors: Caller, Callee, and Customer.

• Messaging Devices— Fax machines, voice-mail systems, answering machines, and other devices capable of sending and receiving telephone communications.

  • Characteristics: Over 50 percent of the current customer base connect secondary devices to their systems to send and receive messages.

  • Competencies: Limited capabilities to respond to messages from the system. Negotiate messaging protocols etc. with each other.

  • Success Criteria: High speed, high bandwidth, low noise connections.

  • Actors: Caller, Callee.

All of these user types play the roles defined by the Caller and Callee actors but they have different characteristics and capabilities. They also have different success criteria and requirements for the system being built. This will impact on the contents and structure of the use-case model and the other requirements documentation. If these variations in emphasis are not considered during the use-case modeling, then the system produced may end up satisfying only a very small segment of the target customers.

As one of the most important types of stakeholder, active users are essential to most projects. The amount of user involvement required is variable; one user may be a full-time user ambassador permanently assigned to the project, another may be a member of a user panel, and yet another may simply submit ideas and feedback by questionnaire. When defining the stakeholder roles, you should take into consideration the amount of user involvement necessary to support the project, the style of user involvement most suited to the project and the users, the availability of the users to the project, and the level of commitment the users have to the project.

In most cases, it will be impossible to involve all of the users. What is essential is that the set of stakeholder representatives includes user representatives and that for each type of user there is clearly defined representation. Users must understand how they are represented in the project, and user representatives must understand their responsibilities toward the users they represent.

For the project developing the simple telephone system, the stakeholder roles have the following responsibilities for representing the users:

• Marketer— The marketing team representative to the project; also represents the interests of the marketing and sales departments as well as the users. The marketer is available to attend workshops and reviews related to the system's requirements.

  • Users Represented: Technology Adopters, Standard Users.

• Ambassador User— A member of the customer support team has been seconded to the project to provide full-time user representation; responsible for representing all the users of the system, including the organization's support and operational teams. The ambassador user is key member of the project's requirements team, creating requirements documentation as well as attending workshops and reviews.

  • Users Represented: Technology Adopters, Standard Users, Messaging Devices, plus the company's internal users (as yet undefined).

• Support Working Group Member— A working group has also been set up to represent the support and operational staff affected by the new system. This is chaired by the Ambassador User and meets once a month to discuss the requirements and progress of the new system.

  • Users Represented: The company's internal users (as yet undefined).

• Focus Group Member— Various focus groups are set up and run by the Marketer to explore requirements issues with representative groups of target and existing customers. These are formed on an as-needed basis and facilitated by the Marketer and the Ambassador User.

  • Users Represented: Technology Adopters, Standard Users.

Stakeholders and Use-Case Modeling

An understanding of the stakeholders and their particular needs is essential to developing an effective use-case model. In many cases, the system has indirect (or secondary) goals that are not directly related to satisfying the needs of the actors (and by implication, the users). Other stakeholders may have a vested interest in the outcome of a particular use case. This is often the case when management reports must be generated or management information captured but none of the managers is directly involved in the use case. "What are the actor's goals? Where is the value to the actor?" ask the use-case modelers. In these cases, the user, playing the role of the actor, is often a more junior employee whose only real goal is to do a job, which is a valid goal for a use case to support and can certainly be considered of value to the actor.

The set of stakeholders who supply the requirements for the use case is not restricted to those who represent the users involved in the use case (that is, play the role specified by the actors). If you want to know the amount of management information that must be captured, you should talk to the managers who will be using the information and not the operators who will be producing the reports. Understanding these indirect relationships can be of great help when viewing the use-case model, because the goals of the broader stakeholder community can often be contrary to those of the actor involved. For example, the stakeholders may require additional security checks or impose limits and restrictions on what the actor is allowed to achieve.

The most effective way to work with stakeholders is to directly involve the stakeholder representatives in the development and review of the use cases themselves. Figure 3-5 illustrates the relationship between the stakeholder representatives and the actors and use cases. As we explain throughout the book, use-case modeling is a synthetic rather than analytic technique. If you do not involve the correct stakeholder representatives in the creation and validation of the use-case model, then the model itself will be worthless. Identifying and involving the correct set of stakeholder representatives is the essential foundation of any successful use-case modeling activity.

Figure 3-5. The relationships between stakeholders and actors and stakeholders and use cases

We have often been subcontracted to facilitate workshops or provide training to software engineers who have been charged with producing a use-case model to express the requirements of the system they are about to build. One thing soon becomes clear: Given a challenge, these highly tal-ented people will rise to the occasion and produce a solution. No matter how little experience they have of the problem to be addressed or the domain in which it occurs, they will produce a use-case model and by the end of its development believe that it is an accurate reflection of the actual requirements. In reality, the use-case model produced will be a fiction, reflecting the technical objectives of the developers rather than the business needs of the stakeholders. Unless the people involved in creating the use-case model have excellent domain experience and communicate thoroughly with the other stakeholders, the model produced will not capture the real requirements.

Knowledgeable stakeholder representatives must be involved in all of the use-case modeling activities throughout the life cycle of the project if the project is to be a success. To facilitate this involvement, it helps to trace the stakeholder roles to the areas of the use-case model where their input is most useful. Table 3-1 shows the relationship between the stakeholder roles and the use cases for the simple telephone system example.

Table 3-1. Relating Stakeholder Roles to Use Cases for the Simple Telephone System