Business analysis and software requirements - What is a 'user'?

When working as a business analyst several users ago, I had an amazing experience when I very casually asked a client something like, "What requirements do you want to put on passwords for external users?"

Several weeks later we decided what we meant by "external user", had redefined "internal user", learned that their company had at least four different customer applications with four different user databases, and my company gave them a presentation on LDAP systems and identity management.

Users, customers, and roles

Until that meeting I had been led to believe that there was just one "external user", and they all had the same role: They were a user of the software system we were developing. After all the other meetings, our team decided that external users could be defined as many different roles, including a manager role, a user role, and another role that had read-only access to the system.

Beyond this, we redefined what "customer" meant. Until this meeting, we all assumed that a customer meant a business at one office. While this worked for 95% of their customers, their larger customers have multiple offices, and different offices interacted with my client's company differently. Although these customers represented only 5% of my client's customer base, they couldn't be ignored under any circumstance, and in this case, these customers accounted for 30% of the client's revenue, so they certainly couldn't be ignored.

To keep this short, I'll skip all the other details, but suffice it to say that our client realized that they needed a more powerful database configuration to manage their user and customer accounts. (Our client actually maintained user accounts for their customer's customers, so that's another reason I'm stopping the story at this point.)

The moral to this story is that the next time you say "user" in a software requirements meeting, or software requirements specification, be sure that everyone is in agreement about what a user is. If you think in terms of "roles" more than "users", I think you'll be much happier with your results.

Internal user roles

On a related note, this same client was able to define internal user roles much more easily than they could define external user roles. They were used to referring to people as Customer Service Rep, Sales Rep, Invoicer, and so on, so that part of our meetings was much, much shorter compared to the process of learning who their external users really were.

Note: Alvin Alexander is a member of the International Institute of Business Analysis, and has worked as a Business Analyst for twelve years.