In William Shakespeare’s famous play, Romeo and Juliet, Juliet tells her sweet Romeo:

“What’s in a name? that which we call a rose

By any other name would smell as sweet”

Short answer in the requirements world: No.

If you have ever been tasked with writing software requirements, you may be forced to disagree with our old friend Shakespeare. I worked on a project that involved eliciting requirements from several departments within an organization that did not communicate often or at all in most cases. I started the project like most others, creating models, identifying business objectives, and scheduling elicitation sessions. The fun started when I was reviewing the Business Data Diagram I had created for the project.

The objects on the diagram I had were customer, profile, order, and account. I would show this model to group A and they would confirm and agree on the relationships between the objects I have identified. I would take the same model and show it to group B and they also confirmed the relationships between the objects identified. As I continued the requirements elicitation process and investigating the needs of the business, I began to receive contradicting information from group A & group B. Group A claimed that the customer does not require a profile to view targeted content and group B claimed that a customer cannot view targeted content without a profile. Why does one group think that customers require a profile to view targeted content and the other does not? I asked both groups to come together for a session in order to get the two communicating. The moment we got together, both groups began to realize that there is a gap in their understanding. Group A claimed Group B was crazy and didn’t know what they were talking about and Group B found it obvious that Group A has been under a rock for the last decade. I was stuck with a predicament. In order to properly write the requirements for the project, I needed to understand what language we were going to use for the objects we needed to refer to. My next step was to take a few steps back and visit the Business Data Diagram once more. Now both parties agreed that a customer and profile are involved. They are disagreeing about how they are involved. What’s interesting here is that both groups are referring to the exact same concept but in different ways, but when it came time to investigate the relationship between the customer and the profile it was difficult to find common ground. So I went to each group and asked them to define what each term mean to them. Group B referred to a profile as a set of permissions that are assigned to a user and group A defined a profile as a user’s set of contact information. Each group used the same name to refer to different things.

At first glance, one would assume that an entire organization would call the same objects the same name. In reality, it’s not so hard for departments within an organization to become “siloed” and not communicate with one another.  One measure I would take to prevent this from happening in the feature is to create a glossary of terms up front for a project. This would ensure that the terminology used is consistent throughout the organization.  A colleague of mine discusses glossaries in a previous blog post. He’s got some great insight on how to leverage the concept!