 |
|
|
| From Stakeholders to Actors and Use Cases |
|
|
|
It can be said that a stakeholder is any individual or group with an interest in the success of an organization in delivering intended results and maintaining the viability of the organization's products and services. A stakeholder therefore can affect either project scope or product scope. In this thread I’d like to focus on users. It is our users, be they managers or clerical staff, which we depend on to determine the functionality of a system. I strongly believe in the business taking ownership for its own requirements. Who better to document user requirements than the users themselves?
Users tend to think of functionality in terms of needs. “I need the system to do this.” “Wouldn’t it be great if the system could do that?” The ever persistent “the system won’t do what I need it to do because of something.” Users drive change because they need ‘things’ to perform their duties and make decisions. It’s the Business Analyst that makes those things happen and thus leads the business to its own solution. This brings me to a technique which I have had much success with; a stakeholder analysis.
|
|
|
A stakeholder analysis can uncover so many interesting things for example: who needs and does not need access to the system, who has overlapping responsibilities, who’s goals do not align with the responsibilities assigned to them, which business processes are common and which are redundant. I could go on, but let me get right to it. I use the stakeholder analysis to determine who my users are, what needs they have, how they expect to have those needs met; ultimately what they will do with the system.
A stakeholder analysis should be done at the very beginning of the project and feed directly into the initial vision and scope documents.
To achieve this I generally do the following:
- Determine who all the stakeholders are.
- Categorize them into people and non-people, users and non-users.
- Build descriptions, goals and responsibilities for each.
- Confirm that the goals and responsibilities are aligned.
- Work with the project group, staff, SMEs and general user community to determine everything that the user needs and might need from the system.
- I usually assign the above tasks to a SME or other lead. This gives me time to begin collecting business objects, rules or other requirements.
- In addition to the activities/business processes, I also ask for the stakeholder’s physical location and any other general characteristics that might be important.
- If there is a high volume of activities and users, I may create a matrix that associates the users to the activities. This is really helpful to see overlap, redundancies and common activities.
- Where the environment is very dependant rules, or has a highly functional org-chart I may use a legend in the activity/user association that looks something like this:
- ‘A’ – Basic and persistent association.
- ‘RA’ – Persistent association that is based on some to be determined rule.
- ‘TA’ – Non-persistent association that is transient in nature. The user’s association to this activity is dependant on a condition. Once the condition is met the association is only available temporarily.
- I then begin to abstract the stakeholders looking for those common activities that can be rolled up to an abstract user.
- This allows me to take advantage of inheritance and is the first step to creating system actors.
- Just as you’d expect I can now begin to abstract actors. My diagram may look something like this:
- This leads me to an actor model, which includes inheritance between actors and associations back to the stakeholders (traceability!).
- I now have a very clear picture of who needs to what, who has access to what and who might not need access at all.
- With my users associated to my business processes and my actors associated to my users it is very clear to see which use cases I will need and how much usage those cases will have.
- I then begin to translate my activities into use cases and start to determine which scenarios I will need.
- If I was able to assign the stakeholder analysis to someone else I may have an idea of which business objects and rules will fall into which use cases.
- I may also know something about the business events and pre/post-conditions.
- With a decent list of use cases, actors, users, business objects, triggers and invariants I am ready to begin an effective use case model.
Remember, I mentioned that a stakeholder analysis should be done at the beginning of the project. Within a short period of time I have determined who is touching the system, how they will touch it and what their needs are. I also have an understanding of which business objects I will need, what rules will be employed and where the subject boundaries will fall. If this exercise moved at a good pace, the project may not even be out of the inception or elaboration phase. Now that my project manager is super impressed I can get to work on building models and the BRD. I don’t have to tell you how many artifacts can use this analysis - security models, training and process diagrams or workflow analysis, just to name a few.
I hope that you found this exercise helpful. I encourage you to try it on your next project.
|
|
|
|
|
 | |
|
|
| Re: From Stakeholders to Actors and Use Cases |
|
|
Hi Perry,
This is great! On my projects I use a very similar artifact - I call it "Actor Overview". I do the same thing you do with stakeholder analysis which leads to an actor model showing both more general roles as well as the more specialized roles played by stakeholders/users.
For those out there still learning the business analysis trade, a very effective way to discover requirements and needs is to begin with the actor diagram and for each actor as questions such as:
- What are the main roles and responsibilities of the actor?
- What is the expected computer literacy level of the actor?
- What is the expected business knowledge level of the actor?
- What are the key deliverables/outcomes that are produced by the actor?
- What does the actor need to be able to do with the system?
Another aspect of the application where the actor diagram is useful is defining system entitlements and role-based security.
- Adrian
Adrian Marchis
Business Analyst Community Blog - Post your thoughts! |
|
|
|
| |
|
|
| Re: From Stakeholders to Actors and Use Cases |
|
|
We are on the same page with respect to attributes in the artifact ... except I use the term stakeholder then translate to actors in a more abstract fashion because I want to take advantage of inheritance and the eventual creation of an ALL_ACTORS_CLASS. Abstracting the actors FROM the stakeholders allows me to only have one PRIME actor per use case. It also helps me resolve transience issues.
Not to confuse the community with these concepts .... at the end of the day calling them actors or just non-union extras ... ( HA HA) is academic. the point is ... and Adrian is totally right here, to do a careful analysis of your user community and profile them.
Much of what we do ...believe it or not is diagnostic modeling. Our trade is similar to that of physiologists and other clinical analysts. Remember these simple things and you may find yourself getting comfortable sooner than you thought.
- The 5 W's (who, what, when, where, why) and sometimes why-not
- How much? give me an example...plan, elicit, structure, document and communicate requirements that are always visible, accountable, measurable and traceable.
- be as specific as you can - i have to know when the requirement has been met and how I'm going to measure that it has been met.
- All analysis activities and requirements must always solve business problems that are related to culture, capital, costs, customers, compliance, competition and competence. Known as the 7C's
- Questions strategy should be as follows: start with open-ended, then ask for the closed short answer, clarify then confirm
When ever you tell somebody something you always have to tell them what you are going to tell them, tell them, then tell them what you just told them ... each time every time.
- Take advantage of verbal protocols...get them to think out loud as they do their work.
- Finally diagnostic modeling: Investigation, diagnosis, treatment plan, and prognosis.
|
|
|
|
| |
|
|
| Re: From Stakeholders to Actors and Use Cases |
|
|
Coming from a 'soft skills' point of view it is important to recognise the political aspects of stakeholder management. It's also important to realise that stakeholder monitoring is an ongoing activity. People's stakes change over time.
Project managers are also looking for stakehodlers but sometimes you see things they don't. This is especially true if you have worked in the organisation you are in for a while. Two eyes are better then one.
Read more detail on my views at the BetterProjects blog.
|
|
|
|
| |