6 Basic Techniques for Successful Software Requirements Elicitation with Remote International Customers

In this global environment, there is rarely a project we work on that doesn’t have some set of customer users in a remote location, inevitably overseas. While we are typically eliciting requirements in English, we are always faced with ESL customers. So here are a few tips I shared with my team this week as we prepped for such a session with users in China.

1. Communicate their value. Help them understand how important they are to the success of your project. After all, you couldn't possibly understand their business needs as well as they do – with differences in business practices, culture, and preferences.
2. Talk slow. This should be obvious, but it always happens that we talk much too fast, so slow it down. Be very thankful they are willing to talk back to you in English! So whatever you need to do to remind yourself frequently through the discussion to talk slow, do it. Ideas I have include a post-it on the corner of your screen or a co-worker sitting beside you to remind you frequently.
3. Eyes in the room. Have someone in the room, if at all possible, to facilitate the discussion. If you cannot hear or clearly understand a comment (this often happens with large rooms of people and a speaker phone), that person can sit beside the phone and repeat it. Have a communication tool such as Instant Messenger open on a computer that isn’t projecting, so that person can communicate with you about body language – to tell you if you are going too fast or if people in the room look lost.
4. Visual is important. I like to prepare powerpoint slides with small bits of information on each slide pertaining to what we are talking about. So perhaps a screen shot or mock-up with a few features list on a slide. Diagrams and visual models are also extremely helpful.
5. Send materials ahead. As important as visual materials are, they are ten times more useful if you send them ahead. I know I have a better time reading foreign languages than I do hearing them, and this is the case for most. So if you send the materials ahead, they will have a chance to read them and more likely follow along with you during the discussion.
6. Open questions, not closed. Depending on the culture, some people are hesitant to ask questions or tell you something negative. So be sure to ask open ended questions. Instead of “are there any questions?” you would ask “what questions do you have?” – because we know they have some. Then call on people by name to ask what questions they have. Ask their leader what questions he/she has. If they say they are ok with you are presenting for requirements, then you really should ask “What are you concerned about?” or “What have we not captured that you need to have?” or “What are you not ok with” instead of “Is this ok?”.

Reqlish: Part I: English Usage and Syntax for Software Requirements

Justin Burrows says:
Hey James. I got a sooooooooooooper dorky idea: Let's do our blog post on Requirements English (I'm calling it Reqlish) over Skype.

*Justin Burrows is pleased with himself *

James Hulgan says:
LOL. Alright, ready set go.

Justin Burrows says:
We're brought up to mind our p's and q's, but is good English really suited to Requirements? Especially when working with global teams, a simplified "pidgin" may actually work better for requirement documents. The pidgin that I use has this consistent structure similar to simple, formal language:

[Subject] [Verb] [Object] [Exception/Modifier].

But I also drop articles (e.g. a, the, an) and instead use all caps to indicate specific systems.

James Hulgan says:
Yes, "proper" grammar does not always buy us what we want as requirements analysts--that the requirements are easily consumable and understood. Often, the way in which requirements statements are structured grammatically is ignored, but it is crucial to how well the requirements are understood. Some grammatical purists may disagree and claim that we should always use proper rules of grammar in our writing. I would respond by staking out two possible positions with respect to grammar:

1. The Orthodox: Think your junior high or Freshman English comp teacher. Motto: “There is a Correct and Proper English Grammar, and anyone who deviates from that grammar deserves to be publicly humiliated.”


2. The Pragmatist: Not sure there is an archetypal linguistic pragmatist, but I think of my sophomore English teacher who encouraged my fiction-writing. Motto: “Grammar is a tool: Use it and modify however you can in order to get your point across the best way possible”.

As a requirements analyst, we have to be pragmatists.

Justin Burrows says:
I find this "Reqlish" is often a battle between logic and ear. For example, saying "a equipment" instead of "a piece of equipment" sounds awful to me, but perfectly normal to consumers to whom English is a second language.

But, James, I put it to you:

Are these grammar shortcuts that this crap up anymore with which the latent grammar nazis on the team will not put?

James Hulgan says:
I don't think that we should care so much about the grammar nazis. We should spend the effort to ensure our requirements are grammatical only if it serves the purpose of ensuring that the requirements are unambiguous. If making the requirements "ungrammatical" furthers the cause of consumability and understandability, then it is worthwhile to discover the structures which make this possible. Not too many people these days, besides crotchety junior high English teachers, believe in "one true grammar" for English anyway.

Justin Burrows says:
I think there are a lot of closeted Junior High English Teachers out there (and you know who you are-- Alright is a word, btw. :P). Do you think there are "rules" that Reqlish would play by?

James Hulgan says:
Well, it probably depends on the project, but I think something like [Subject] [Verb] [Object] [Exception/Modifier] is a good start. Trying to avoid ambiguity is an awesome goal, but to very loosely paraphrase John Searle, “Syntax does not suffice for semantics”. In other words, one particular grammatical structure is not guaranteed to be less ambiguous than another.

*Justin Burrows rings the idiot bell.*

Justin Burrows says:
Ok, smart guy, want to explain the distinction between Syntax and Semantics?

James Hulgan says:
Briefly, a language's syntax is the rules for how items (words) in a sentence of a language can be arranged. Semantics is the meaning of the strings in a particular language. So, while the meanings of sentences certainly depend on syntax, a particular syntax is not sufficient for conveying meaning.

Justin Burrows says:
Huh…

James Hulgan says:
There, like, has to be a balance, man.

Justin Burrows says:
Ok, I can dig it. Can we talk more later about building a formal syntax for Reqlish?

James Hulgan says:
Sure! I chatting syntax. Let's go more into the subject-verb-object structure and what structures are most easily understood. And next time let's give people some practical examples to use in their own documentation.