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 Tips and Traps article 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!). Example:

• 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.

Please forward your comments, questions or suggestions to This email address is being protected from spam bots, you need Javascript enabled to view it