The Actors In Your Scenarios / Use Cases

Often overlooked, an analysis of the different actors in your identified scenarios can provide benefits in diverse ways. Not only does this help in creating requirements, it can also help in creating relationships, understanding the product ecosystem and identify new opportunities for the delivered product. The product owner, SME or project manager may have all these in their head and a BA can be successful with it ending right there. However, the BA shouldn't rely on that too much because it could be a missing crutch if project team members change.

Actors have tasks that they will perform in the "as is" and "to be" states of your software project. These tasks are a key resource in visualizing and documenting the solution requirements (functional and to a lesser degree non-functional). I would never recommend using actual stakeholder names in your actors list. 

There are many methods to help the BA get a handle on the various actors and their associated needs for a desired software system. I really like the power and simplicity that was introduced in Allister Cockburn's "Writing Effective Use Cases." The techniques include a simple actor-goal table and a use case brief. 

The actor goal table has three columns consisting of actor name, their goal and a priority. The use case brief replaces the priority column with a narrative brief. Obviously, it would be easy to integrate the two into one. This fundamental table can be a column in which the BA can lean on to define and manage scope related challenges.

STEP 1: Build the list of actors, use general roles and add the most brief details like explained above.

STEP 2: Build a list of activities for the system but don't immediately place them next to the roles. Do not itemize the steps just yet but you can add a brief description. Try to capture end to end activities and place them on a timeline. Some activities can overlap and this is natural. 

OPTIONAL STEP 2A. You can try to do a value stream analysis for this timeline if your comparing "as is" and "to be" states. Refer to one of my other articles on this topic.

STEP 3: If you uncover missing actors or activities, add them to your backlog and work them into the overall process. 

OPTIONAL STEP 3A: Create a breakdown structure for your actors and/or activities.

STEP 4: Begin creating your use cases and iterate all the included processes as needed before you review them with your stakeholders.

STEP 5: Iterate as needed based upon your stakeholder input.

©2015 Dwayne Wright