A friend asked me to come to dinner one Sunday and I gladly accepted.  When I rang the bell at four o'clock, my friend angrily answered the door and informed me, "dinner was ruined" because I was so late.

Late for dinner at four o'clock in the afternoon?

In my world, 'lunch' occurs during midday whereas 'dinner' is after twilight every day of the week.  I discovered too late, my friend refers to 'dinner' on Sunday as being served midday.

I failed to clarify what was meant by 'dinner', so the result was overcooked chicken.

We do the same in our requirements sessions; we assume everyone knows the definitions of common terms that may have completely different meanings for each stakeholder.  Once, I started a requirements-gathering session by asking the stakeholders to define the term 'customer'.  The stakeholders were rather upset with me for asking such a silly question and told me that a "good BA" would know such a basic concept.  As they were chastising me for wasting their time, we discovered there were three very different versions of 'customer' being used by the group:  a wholesale customer who bought product for resale from a specialized sales team; a business customer who consumed the products and services ordered from a specific call center; and a retail customer who bought retail products at brick-and-mortar stores across the country.  They realized … not such a silly question after all.

As BAs, we sometimes hesitate to ask questions because we don't want the stakeholders to think we aren't the expert.  We need to check our egos and not let pride get in the way of doing our job.  Terms need to be defined and confirmed, regardless of the stakeholder attitude.

As a best practice, review the documentation and prepare a glossary before the requirements gathering meetings, and review the meaning of each term with the team.  Refrain from using jargon, slang, or using the same term in the definition as the word being defined.  There is nothing more maddening than to see the definition of "jarlang" is "jarlang"!  

When writing the definition, do not confuse the 'definition' with the 'definitional rule', as these are different.  When defining the term, the definition should describe "what is" for the stakeholders.  The definition is virtually immutable; it should not change.  A 'definitional rule' — also known as a 'structural rule' — identifies the criteria of the definition and can differ.  For example:

• Definition of 'dinner':   a meal


• Friend's definitional rule of 'dinner':  a meal eaten between 11:00 a.m. and 2:00 p.m. on Sunday.


• Dagmar's definitional rule of 'dinner':  a meal eaten between 4:00 p.m. and 8:00 p.m. any day of the week.

As you can see by this example, the definition of 'dinner' is the same for both definitional rules, but the conditions for each definitional rule are different.

# # #