Who’s on First

Written by James Rivera on July 7, 2009. Posted in Articles.

Who’s on First is one of the greatest and funniest comedy routines of all time, and in 1999, Time magazine named the routine Best Comedy Sketch of the 20th century. This routine still stands up today because it illustrates a universal truth we all understand and have experienced: that just the slightest misunderstanding in simple common terminology can lead to a complete breakdown of communications.

In this skit Costello plays a peanut vendor and fan of the St. Louis Wolves Baseball team, and Abbott is the team coach. Costello wants to know the names of the team’s players so he can “say hello if he meets them on the street.” The source of the miscommunication is the players strange nicknames that are interpreted by Costello as non-responsive answers to his continual questioning. The lineup for the team is; Who’s on First, What’s on Second, I Don’t Know is on Third, Why is Left Field, Because is Center Field, Tomorrow is Pitching, Today is Catching, and I Don’t Care is Shortstop. Here is a sample;

Costello: What’s the guy’s name on first base?
Abbott: No. What is on second.
Costello: I’m not asking you who’s on second.
Abbott: Who’s on first.
Costello: I don’t know.
Abbott: He’s on third, we’re not talking about him.
Costello: Now how did I get on third base?
Abbott: Why you mentioned his name.
Costello: If I mentioned the third baseman’s name, who did I say is playing third?
Abbott: No. Who’s playing first.
Costello: What’s on first?
Abbott: What’s on second.
Costello: I don’t know.
Abbott: He’s on third.
Costello: There I go, back on third again!

In the end, Abbott’s explanations leave Costello hopelessly confused and frustrated. The entire time I am laughing out loud at the exchange. Inside, I cringe because at times I have experienced this same level of confusion and frustration when eliciting requirements from stakeholders due to the subtle differences in our understanding of the basic terminology such as “What are Needs?” or “What are features?” or “What is considered a Requirement?” The problem for Abbott and Costello stems from the fact that even though they think they are talking about the same thing, in reality, they are not, and for a business analyst this disconnect is caused many times by a stakeholders’ colloquialisms, cultural norms, organizational tribal knowledge, or just plain ignorance.

If Abbott and Costello had agreed on some simple guidelines before engaging in this conversation, it may have gone very differently, for example if Abbott had said.

Abbott: Now, before I tell you the names of the players, I want to make sure there is no confusion. You see, as a joke, we came up with some very strange nicknames to confuse the ball game announcers, and boy do we get a laugh.

Costello: That sounds like fun, do tell

Abbott: Yes it is, you see some players have nicknames that are actually words that are questions like “Who,” “What,” or “Why.”

Costello: Well that is really clever. I can just imagine the confusion that creates.

Abbott: Yes, you have no idea!! So for example, the first baseman chose the word “Who” for his nickname, and the second baseman chose the word “What” for his nickname, isn’t that hilarious.

Costello: Ha, Ha, Ha, oh my that is funny

Abbott: Ha, Ha, Ha, makes me laugh every time. So here are the names of the ball players.

Abbott: Who’s on First, What’s on Second, I don’t know is on Third, Why is Left Field, Because is Center Field, Tomorrow is Pitching, Today is Catching, and I don’t care is Shortstop

Costello: Hey, What about the right fielder?

Abbott: Oh, he didn’t think it was very funny so his name is just Fred.

Costello: Got it, thanks see you later

Well this is certainly not as funny as the original routine, but it is much clearer, much shorter, and no one is frustrated. This is an example of what I call “orientation.” In this modified version of the skit, Abbott, spends some time getting Costello “oriented” to the terminology to make sure the conversation gets off on the right foot. The result is clear, succinct, and frustration free communication.

To achieve this type of orientation, you have to ensure that you are relying on not just the definition of common terms, but also the semantics or meaning. The best way to do this is to begin by asking some simple clarifying questions to make sure you are talking about the same thing.

Because you will be talking about software or product development and not baseball, you most likely will not encounter such strange nicknames as “Who” “What” or “Why.” However I have encountered some awkward and perplexing interpretations of common requirements terminology that has created some very challenging communications.

To understand the right questions to ask, for example, let’s first lay down some guidelines around two common terms, needs and requirements.

Understanding Needs

A need is a deprivation or something that is missing. In requirements terms, here are a few examples:

Something the stakeholder or a customer cannot do

“Customers do not have the ability to pay the bill from their cell phone.”

Something the stakeholder or a customer cannot do adequately

“The call centers experience high call volumes due to difficulties customers have paying their bill on their cell phone.”

Something they cannot see or don’t have

“The monthly call center report does not provide details on customer complaints by region.”

When thinking of clarifying questions, remember you are trying to determine what is missing or what they are deprived of, here are some guidelines.

Questions that pertain to something the user is attempting to do that they cannot do today
Questions pertaining to information that is lacking or insufficient to perform a task or make a business decision.
Capabilities that are insufficient, cumbersome, or prevent the user from performing a business task
Capabilities that cannot be performed in the correct order, or performed in a timely manner

You will notice that I am intentionally avoiding the use of the word “need” when suggesting clarifying questions about needs. The reason for this is that it is very common to confuse needs with requirements mostly because in our every day lives we don’t make the distinction between the two. I can remember my children telling me how much they “needed” the hot new video game, and I would very calmly tell them. “Well actually, you do not need that hot new video game, the only things you need are food, shelter and love, all of which your mother and I provide. What you really mean to say is you “want” or “desire” to have a new video game. As you can imagine, my children just roll their eyes, complain louder, and typically get their way.

Needs are not necessarily tangible things; they are a description of a condition or state. Much like hunger is a physiological condition that results from the lack of food, a need is a business condition that results from the lack of a capability. Make sure when you are discussing needs that you are talking about conditions or states of deprivation, and this will ensure that you are talking about a need and not something else.

One other distinction in regards to needs is whose needs you are referring to, business needs, customer needs, stakeholder needs. This distinction is based on who is experiencing this condition or state. In other words, who cannot perform the task, who cannot see what they want to see, or who is having an inadequate experience.

Understanding Requirements

Requirements on the other hand, exist only to satisfy needs. Requirements can also be classified as desires or wants unlike needs which specify something that is missing. There is a very important relationship between requirements and needs, and you must be able to demonstrate this relationship to ensure that you have a valid requirement. The following example also demonstrates that there are typically many requirements necessary to satisfy a single need.

Here are some examples:

The “Pay by Cell” feature will provide the customer with the following capabilities:

The system will provide the customer with the ability to look up their existing monthly bill on their cell phone.
The system will provide the customer the ability to pay by credit card on their cell phone
The system will provide the customer the ability to store their credit card information from their cell phone.

Note: you will notice I cleverly inserted the term “feature” without any explanation. For clarification, in this example a feature is a collection of requirements which also exist to satisfy a need.

When thinking of clarifying questions, remember you are trying to determine what capabilities will satisfy or fulfill a specified need. Here are some examples of categories of questions to ask:

Questions about how a specific capability will help the customer to perform a task they could not perform before
Questions about how having specific information will help the stakeholder make better business decisions or perform specific tasks
Questions about how specific sequence or timing of capabilities will provide a better experience for a user

A good rule of thumb is to avoid using the terms you are trying to clarify in a questions, such as What do you Need? What do you Want? or What do you Require?

Remember requirements exist to satisfy a need or condition. Much like food satisfies hunger, requirements satisfy needs. Also, like needs, you must also make the distinction between the various types or sub classifications of requirements such as customer requirements, business requirements, system requirements, product requirements, technical requirements, etc. This distinction is very important because the methods used to document these different types of requirements can be substantially different.

In the previous example, the requirements were specified in a functional form, that is to say, they describe the requirements in terms of the functionality or capabilities the product must have to satisfy the need.

Another common form of describing requirements is in terms of the experience the user has when interacting with the product, for example;

The user requests their monthly bill from the system and the system displays the bill to the user
The user chooses to pay their bill by credit card, and the system prompts the user for credit card information
The user chooses to store their credit card for future reference, and the system validates and stores the user’s credit card information

To ensure you and the stakeholder are talking about the same thing with regard to the style in which to document the requirements, here are some useful guidelines to ensure you both have the same perspective.

Should the requirements describe the experience the customer/user has when interacting with the product or service?
Should the requirements describe the capabilities that the product/service must have to support the customer interaction?
Should the requirements describe the capabilities the organization must have to support the customer interaction and the product/service capabilities?
Should the requirements describe the technical capabilities that must be present to support the customer interaction, product/service, and organizational capabilities

I have seen many different terms used to describe these four types of requirements, some that make sense and some that don’t, however, what is really important is that you use the guidelines above to ensure that you and the stakeholder are talking about the same thing, and then you can agree on what term to use to describe the final artifact.

For example, I have seen the following

Use Case, User Requirement, Business Requirement
Product Requirement, Functional, Non-Functional, System Use Case
Operational Requirement, Business Use Case,
Technical Requirement, System Use Case

Again it is all a matter of perspective and what is most important is that you and the stakeholder are talking about the same thing.

Is summary, the key to ensuring that you have a productive requirements elicitation experience is to first ensure that both you and the stakeholders are oriented to the same understanding of the goals to be achieved. These goals include, ensuring the needs are well understood and documented, ensuring there is a common understanding of what is and is not a requirement by associating with a defined need, and ensuring you clearly understand the perspective from which the requirements are to be written and agree to the final style of documentation.

James Rivera is a Project Solutions and Services Delivery Professional with over 17 years experience in Program Management, Business Analysis, Process Improvement, Education and Instructional Design and he currently leads the Enterprise Business Analyst team at a mobile telecommunications company in Seattle. He is a Contributing Author to : The Fast Forward MBA in Project Management 3^rd Edition (Portable Mba Series) by Eric Verzuh (Paperback – April 25, 2008), where he wrote the Requirements Engineering Chapter, is a co-author of: Business Analyst Certification Program taught at University of Texas at Austin, Rutgers University – New Jersey, UNCC – Charlotte, North Carolina, and has been a Business Analyst and Project Management instructor at University of Texas at Austin, Rutgers University of New Jersey, St. Edwards University in Austin, Austin Community College, University of North Carolina Charlotte (UNCC) [email protected].