The Actors in your Requirements Model are Not Just Stick Figures

When gathering requirements there is a natural desire on part of both the requirements analyst and the subject matter expert to “just get on with it.” Both sides want to see models, use cases, functional requirements, non-functional requirements and all the myriad other artifacts that are created as a prelude to the actual creation of the software. In the process of doing this one thing that very often gets a short shift is properly identify and defining ALL the actors – the people who will actually be using the software that is being built.

This point hit home last week when I was surfing the web looking to see if I might be able to refinance my current home mortgage at a lower rate. On the one hand, with the current melt down of the housing market, they tell us that the sky is falling on our head. On the other hand, the Federal Reserve seems to be cutting rates every 30 minutes. So, I figured that this might be a good time to see if I could save some money with a better mortgage rate.

The first site I went to was one that advertises heavily on any number of television channels. They had gotten my attention and I figured this was as good a place as any to see if it was possible to shave a few points off my current rate.

To my dismay, I was confronted with a one page form that I was asked to fill out BEFORE I could even get an idea of what current rates might be. I looked around in other parts of the web site to see if the information I was looking for was available. No such luck. After a few minutes of this futility I gave up and moved on to another site that did not make me jump through hoops just to see what rates were.

I was mouthing some choice expletives under my breath about the sheer stupidity of the first site and how many potential customers they were losing this way when I started thinking as to whether this whole fiasco could have been avoided in the first place.

I could not have possibly been the only person who had come by their site looking for some information before delving deeper. And again, my behavior was not particularly unusual or radical as to be a corner condition. Many, if not most, potential customers were likely to first check out the rates before they spent fifteen minutes or more filling out an online form. So, how could a company that spends hundreds of thousands of dollars on advertising get something so basic as who is using their web site so wrong?

One possible answer might be that they did not spend enough time fleshing out their “actors.” In the above situation if you describe your “actors” as people who are applying for loan, then the rest of the site makes sense.

On the other hand, they are missing a whole lot of potential customers like me. People, who, while they might be in the market for a loan are not yet ready to apply for one. These are people who want to see what you have to offer before they start giving you a whole lot of personal information.

If this is indeed the case, a little bit of time spent up front in properly fleshing out their actors would have resulted in a radically different user experience and web site. If this is not the case and they are really looking only for people who want to apply for a loan, then their site should reflect clearly the kind of “actors” they are looking for. So, you either have missing requirements or actors who were not properly fleshed out. Not good whichever way you look at it. The sad part is that this is eminently avoidable with basic requirements methodology and techniques.

The next time you are starting off a project, spend some extra time up front properly identifying your actors. A few simple tips / questions you can use when identifying your actors.

1. Who else will use this software?
2. In what way are they different from the actors we have already identified?
3. Are there any other subject matter experts I need to be talking to who could identify other potential users of the software? In the above example, if you just spoke to the people who approved loans, you are likely to have just one actor identified – “borrowers.” However, spreading the net out wider to the Marketing or Sales Department could have netted you “browsers”. “agents”, “dealers”, etc. that someone in loan approvals did not even consider.
4. Try to be as precise as possible in describing your actors. For example, do not just identify your buyers as “customers.” Something more descriptive like “browsers”, “agents”, “bargain hunters”, “dealers”, etc. is a lot more useful.

Obvious? Yes. Common sense? Yes. Rocket science? No. Done always? Unfortunately no.

Resist the temptation to just get on with it and pay attention to your actors. Actors are real people not much different from you or me in many ways. So, if you are part of a project building software that is likely to get under your skin or drive you up the wall, chances are that you are not alone. Stop them.

You are not a stick figure. Nor are the actors in your requirements models.