Monday, 09 April 2012 23:00

The Lexicon of the Solution: Eliminate the User

Written by
Rate this item
(3 votes)

We talked about getting rid of the customer in the last episode, which got a couple of people riled up thinking that I was actually advocating the removal of the role of the customer. I was simply wondering whether we should still be using the term “customer” in the same way we have used it in the past. Now I’d like to go a bit further in our war on words that have lost their meaning and talk about the term “user.” When addressing the issue of the customer, I admit that I don’t have an alternative term in mind, only that the term “customer” has become ambiguous and can tend to establish the wrong relationship nowadays. I have more concrete suggestions when it comes to the word “user.”

The basic problem with the word is that it has been overused to the point of no longer having any specific meaning. “The dictionary’s first meaning is ‘the exercise of a right to the enjoyment of property’ (it’s a legal term). Also there is the meaning understood in the IT world: ‘a person or thing that uses [italics mine].’ I wonder how many of us perceive a ‘user’ in non-human form? And then there is the definition from Dave Barry, the humorist: ‘User, n. The word computer professionals use when they mean “idiot.”’ Putting aside the non-common use of the word, using the term ‘user’ conveys no specific, concrete, consistent usefulness to either the business community or the developers; we’ve just become used to the term ‘user’” [repetitive use of the word is intentional].

The term user refers to a vague, undefined, amorphous something that is interacting with our computer systems or our processes. In other words, specifying a “user” in our documentation does not really specify anything. The individual members of the business community define user to mean how they specifically use the system, and the developers just think, “idiot.”

Start with “User”

When we are starting out defining a system or the problem domain or a business process which we are going to improve everyone on the business side is either a stakeholder or a user. And that is all right. The term can be used as a placeholder until more information is available. But only at the beginning. If we are still referring to users in our final requirements we are essentially admitting we still don’t really know what the users use the system for.

Process Worker

We can start by separating the users, those who physically lay hands on the system, from those who work in the business process but don’t happen to sit at the monitor or interact in other ways with the system under consideration. As business analysts, we should be concerned with the entire business process in which the system under consideration plays a part, rather than just the system itself. We should identify the information that is entered into the system, of course, but also where that information comes from: when, where and how is that information created, and the processes the information goes through before being entered into our system. And, of course, where does information extracted from the system go, what is the final resting place for the information and what steps does it go through to get there? To help us remember the whole picture, the bigger system that our digital part fits into, we call anyone involved Process Workers. This helps us remember that in any business process there are more than users involved: there are customers (the organization’s customers), customer relations agents, salespeople, marketers, managers, mailroom workers, factory line workers, inventory control people, engineers and so forth, all of whom contribute to the overall business process but may not be users. Any changes we make to the “system” may cause a positive or negative impact on any of those process workers. As business analysts we must keep all the workers in mind when we are solving a problem or when our point of contact says “I need….” Remember that the point of contact or product owner is focused on his or her specific area of the overall process; we need to look at the bigger picture.

Consider a requirement that incorporates the term “user”:

“The user enters the name and address of the new account and presses ‘Submit.’

The system validates the information entered and assigns a unique account number…”

(Note that the requirement is purposefully not complete.)

Position

As we begin to gather more information about the business process, the users or process workers become more specific. Instead of a user, the person is an Account Representative, or a Customer Relations Specialist, or some other position in the company. Typically when asked “What do you do?” the responder will start by saying, “I’m a [title of position] and I …” At this point we replace “user” with that position in our notes and conversations. No longer is that person a “user” to be clumped in with all the other “users” of the system, but is now a more specific “user,” one who performs specific tasks and functions with the system. At this point your terminology changes and you make a specific effort to eliminate “user.” Assume that wherever you have the term “user” you are missing information. 

When you replace “user” with the position — and replace the term everywhere, in your use cases, in diagrams, in documentation and in conversation — you informally categorize your requirements and make things easier. For example, when it comes time for review, those sections of the requirements in which Account Representative appears are the sections that will be reviewed by the Account Representatives and the Account Representatives only. You can have shorter, more effective review meetings when you are meeting with only those who have something to contribute about their process.

The agile concept of user stories emphasizes the use of positions or roles. The format of the user story is, “As a [specify role], I want to [specify function] so that I can [specify reason].”

Bottom line: “user” should not appear in your finished set of requirements or any diagram or reference to the requirements. Changing the example requirement above yields the following:

“The Account Representative enters the name and address of the new account and presses ‘Submit.’

The system validates the information entered and assigns a unique account number…”

Personal

But, you say, Steve, what about those people who use the system that we really don’t know anything about, who don’t have a title or position, like people using our websites? For years, the user-experience analysts have known that it is better to personify those who we expect to use our websites rather than refer to them as generic users. They create “personas.” The persona is a fictional creation that embodies all the characteristics of a typical member of the target audience for the website. The persona has a name, demographic description, and typical style and motivation of use. Personas are used not just by user-experience analysts to help define the look and feel of the web pages, but also by marketing to assist in creating the content.

As human beings, we react better to personalization than to generalization. The developers can design a better website for Rita the 67-year-old grandmother interested in buying gifts for her eight grandchildren online instead of fighting the crowds at the mall, or Tommy, the tech-savvy graduate student in Computer Science who needs more information about Predictive Analytics than for some gray ghost of an anonymous user out there.

We may not want to go as far as specifying the persona name in the requirements, but we certainly can specify the target user, by description, that we expect to be using each function.

Performer

Now I’m going to get real picky. In the name of precision and better technical communication, I suggest going one step further. Let’s not stop at the corporate position, let’s move on to the role.

Every position in the organization plays multiple roles during a given workday. Part of our analysis is to identify these roles, especially those played in the business process we are focusing on, and more especially the system. An Account Representative may enter customer information, add a new sale, create a contract, review a sales order, inquire into previous sales information, review new product information, and so forth. When Account Representatives do each of these functions, they are playing different roles. And these roles are ultimately what we want to capture for the developers. 

The system, and the code we are putting into the system, cannot distinguish between Tommy or the Account Representative. (You might suggest that by virtue of the Login Process the system knows who is using the system at any given point. But consider this: Alan, the Account Representative, logs on to the system and then leaves the computer to go to a meeting. Anyone else can sit at Alan’s computer and enter data or perform any function. How is the system going to know that the person pressing the keys is not Alan?) The system knows that a button is pushed, or a mouse click has taken place. Regardless of who pushed the button or what caused the mouse to click, the system must respond in the predetermined way. 

This approach now lines up with the concept of roles in use cases. The role of “adding an account” can be played by anyone with authorization to add an account. That role might be called “Account Adder.” Should we wish to specify this in a set of requirements we might say:

“The Account Adder enters the name and address of the new account and presses ‘Submit.’

The system validates the information entered and assigns a unique account number…”

Note the similarity in wording to that of a use case description Main Success Scenario.

You might think that writing requirements in this fashion perhaps seems a little silly. 

But wait, as they say in the infomercials, there’s more. We have one more step in our elimination of the user.

Gone

We’ve gone from totally abstract and generic wording, “user,” to totally specific wording “the account adder.” And since we really don’t care who is actually performing the function, perhaps we should go back to the term “user” instead of a silly moniker like “account adder,” which might sound like a poisonous snake with glasses. 

Rather than return to “user,” for purposes of clarity and specification to the developers, who have to analyze the requirements to produce the software, let’s go one step further and remove the user completely from the requirements. 

All the words about “user,” “Account Representative,” “Tommy” or “Account Adder” are meaningless to the developer writing the code to add a new account, and even less meaningful to the computer, which has to perform the function. Suppose in the requirements we state just what happens rather than who does it.

“When the name and address are entered and ‘Submit’ is pressed, the system validates the name and address and assigns a unique account number…”

When implemented, the code based on this requirement will execute the same as that of any of the previous requirement statements. However, with this stated requirement there is no uncertainty or questions about use.

Requirements are about specificity, preciseness, lack of ambiguity. We all agree that most of the communication problems we encounter that end up with contention on delivery are the result of vagueness and intentional or unintentional ambiguity. By changing a few words and phrases here and there, words we have used for so many years, they no longer have any real meaning, we can eliminate obfuscation and write better requirements, not to mention have more understandable conversations.

Don't forget to leave your comments below

Read 9024 times
Steve Blais

Steve Blais, PMP, has over 43 years’ experience in business analysis, project management, and software development.  He provides consulting services to companies developing business analysis processes. He is on the committee for the IIBA’s BABOK Guide 3.0. He is the author of Business Analysis: Best Practices for Success.

Comments  

+2 # Alan 2012-04-10 17:44
Hmmm, that sounds like removing reference to all roles in the requirements document. I need to give that some more thought as explicit reference to roles is important for some aspects, though that could be handled by the other documentation the Business Analyst prepares like Business Process Models, and their role based swimlanes.
For example, as an ex-auditor, being able to show appropriate segregation of duties will be enforced in certain key processes is important, and that is at the level of defined role.
Reply | Reply with quote | Quote
+2 # SimonTheBA 2012-04-10 20:55
I was with you all the way - until "Gone". Until you turned a requirement which involved a person (whatever their label) into a system function which doesn't involve a person at all.

I agree with getting as specific as possible about defining the people interacting with the system. For starters, not all people are users of the system; some people are merely recipients of information from the system, with no actual interaction. Also, different people use the system in different ways. So, I use specific labels where possible: buyer; accounts clerk; and so on. This makes the requirements real and personal. It shows the stakeholders who we're working for, and who needs to be involved.

But, that final step leaves me cold. We started with active voice: "As a buyer, I want to..."; "When the accounts clerk enters the invoice details, the system will...". But then we move to passive voice: "When the credit card information is entered..."; "When the invoice details are entered...". There's no focus on the user in these requirements.

That takes us back to the bad old days when we weren't considering users at all, when our only focus was the system - and users had to put up and shut up.

I think we need to keep the people visible in our requirements. What's a system for if not to help people?
Reply | Reply with quote | Quote
+2 # Jess Hurchist 2012-04-11 03:31
Agree totally with not referring to 'User' I've been saying for more years than I care to remember that 'a User is a person who consumes illegal narcotics' .
Really don't like the idea of removing role references including the role in the requirement means (surely) that only people with that role assigned within the system are able to carry out the action which is important for the developers to know.
Reply | Reply with quote | Quote
+1 # Russ Luzetski 2012-04-11 07:57
For assignment of permissions, alone, the "Gone" section is not something I would recommend. I remember those days as a developer, getting requirements that did not specify the role(s) appropriate to the requirement. We had a lot of issues with issues in production that were never caught in testing, because testing traced to the requirements, which were ambiguous as to the role...

Admittedly, some systems don't need that; if permissions are not role-based, there's no need. In my experience, though, that's a rare situation.

I completely agree with everything else you've described here, but taking out that level of detail is asking for a great deal of pain down the road.
Reply | Reply with quote | Quote
0 # Mark Hunt 2012-04-11 10:53
I totally agree (with one caveat). I think too often we as BA's perform too much mental shorthand by simply stating "User" in our Use Cases, requirements, business rules and so on.

In actuality there are often behaviors, rules, limitations (i.e. requirements) that surround a given role; so being specific on who is doing something helps not only the developers but even the BA as they work through what they are writing.

One issue however is when any number or roles are going to use a function. Take for example a customer profile display screen... this might be viewed by the credit department; shipping; order processing, even the customer themselves. So in this case, how do you specify the role? "When the (credit approver/shippi ng department/acco unt holder/order processor/....) "?

Yuck.

On a recent project the BA's on the team I was on actually discussed this at length-- we wanted to be as specific as possible about "who" was going to use or need the requirement, but needed to handle situations where there were any number of roles, and there really weren't any role based differences (i.e. regardless of who sees this and what their job function is they should see the same thing). In this case we fell back to... ummm... the term "User".

Note however that we treated this as an exception; if a rule, process or function was being written for a specific user role, then describe it. If it applies to "anyone", then you can use 'User', signifying that there are no security, log-in or any other limitations to who this applies to. I think that also helps address at least some of Russ' concern about rework and reusability down the road.
Reply | Reply with quote | Quote
0 # Helene MacLean 2012-04-11 11:34
I agree with the use of roles or personas, to ensure appropriate scope and requirements elicitation, but I think you've sold-short the potential importance of identifiying users in the sense of a thing. Other systems (including equipment with microchips, etc.) may be creating the inputs, sending the inputs to the system in question, or receiving outputs. Those interdependent "things" should be indentified as early as possible and being "provocative" by including systems/equipme nt as potential users can help ensure they will be considered before much rework/delay is involved. And with respect to the generic use of "user" in detailed requirements if a function will be used by all, I'd recommend "all roles" just so it's clear that this determination has been made. Where the list of roles gets long and amny but not all have a particular permission, "all roles except..." may be preferable.
Reply | Reply with quote | Quote
0 # Vivek 2012-04-17 00:51
A totally new perspective on how to handle a user!!
Reply | Reply with quote | Quote

Add comment

Security code
Refresh

© BA Times.com 2016

DBC canada 250