As a business analyst, one of the things you have to do sometimes is organize your client's thinking. For instance, I've worked on several projects where clients didn't know anything about the Unified Modeling Language (UML), or thinking about projects in terms of Use Cases and Actors. As a result, they came up with some very elaborate diagrams in an attempt to explain their thinking.
Rather than laugh at them -- I was once where they are -- I patiently listen to them, try to understand them, organize their thinking into Actors, Use Cases, database designs, and architectural diagrams, and I'm glad to say the response is usually a happy client. Yes, some of them joke about "Al and his stick figures", but they also knew we were all on the same page, and I had captured what they were trying to say.
A UML "List of Actors" diagram
One of my favorite things to do on large, complicated projects -- especially where business customers have a hard time organizing their thinking -- is to create a "List of Actors". This list is something like a playbill (programme) you'll see if you go to a theater to watch a play or opera.
This List of Actors diagram is a simple list of UML Actors that might look something like this (if I was analyzing a software system for a company that creates websites for online magazines):
Along with that simple list of actors, I'd add some brief text to describe their roles, like this:
Prospect - A prospect of our organization, someone who is interested in becoming a Publisher.
Publisher - A customer who is publishing a magazine or website.
Advertising Manager - The people who sell advertising for the Publisher.
Author - People who create content for the Publisher.
Editor - People who edit content for the Publisher.
Salesperson - Our salespeople, people who provide demos to Prospects, and convert Prospects into Customers (Publishers).
Customer Service - The people who support our customers.
Order Entry - The people who key in our customer's orders.
Invoicer - The people who create the invoices and send them to our customers.
Designer - The individuals who provide design support for our customers.
Programmer - The people who provide custom programming support for our customers.
Mailing List Manager - The people who manage mailing lists in conjunction with our customers.
(In a more complicated analysis I would organize this list of actors a little more, but for this simple example, this will do. Also, this is just an example; in an actual analysis, I doubt there would be a simple role like "Publisher".)
Use Cases and Actors
After sharing a diagram like this, I'll break it down into more details, showing all the Actors with their Use Cases. These are the more typical UML Use Case "bubble diagrams" you've seen, so I'll just link to one of those, rather than repeat them here.
Benefits of the "List of Actors" diagram
To summarize my "List of Actors" diagram, here are the reasons behind creating this diagram:
- To get agreement from everyone involved that these are the Actors in our "play".
- Making sure we all understand the roles and descriptions of each Actor.
- Making sure there are no other Actors ("roles", or "user roles") in our software system.
This may seem like a trivial point to some people, but I can still clearly recall flying from the U.S. to London, England one time many years ago for a "three day installation" that ended up taking more than three weeks, all because of several misunderstandings on a project that could have easily been caught months earlier with a proper application of UML Actor and Use Case modeling techniques. Since then I've learned that it's much easier for everyone involved to understand, organize, and capture everyone's understanding of the software system that's being developed.
books by alvin
 |
 |
 |
 |