Communication Theory & The RE Role
Requirements must be communicated between people who often have very different backgrounds. This lesson covers the communication challenges in RE and the unique skills a requirements engineer needs.
Why Communication Is Hard in RE
The sender-receiver model tells us that for information to travel successfully from one person to another, both parties need a common code. When a domain expert talks to a developer, they share a language (e.g., English) but often not the same domain vocabulary, cultural context, or implicit assumptions.
Three factors make communication especially tricky in requirements engineering:
- Different domain vocabularies: The customer says "account" and means something entirely different from what the developer pictures.
- Communication medium: Verbal communication carries redundancy (gestures, tone). Written requirements strip away that redundancy, increasing the risk of misunderstanding.
- Implicit background knowledge: Stakeholders assume many things are "obvious" and leave them unstated. These invisible assumptions become the most dangerous gaps in requirements.
Human perception applies two natural transformations to information:
Focusing means we pay attention to certain parts of a message and ignore others. What gets focused on depends on the receiver's interests and expertise.
Simplification means we unconsciously reduce complex information to simpler mental models. When a stakeholder describes a business process, they simplify it, leaving out edge cases they consider "common sense."
Both effects are unavoidable. The requirements engineer's job is to actively counteract them by asking clarifying questions, using glossaries, and validating understanding with models or prototypes.
Mitigating Communication Problems
IREB recommends several strategies:
- Glossaries: Define all important terms in a shared glossary so everyone uses the same vocabulary (covered in Chapter 4).
- Formal modeling languages: Use UML or similar notations to remove ambiguity from natural language (covered in Chapter 6).
- Validation techniques: Review requirements with stakeholders to catch misunderstandings early (covered in Chapter 7).
The Requirements Engineer Role
The requirements engineer sits at the center of the project. She is typically the only person with direct contact to all stakeholders and must act as a translator between the business domain and the development team.
Think of the RE as a bridge: she understands the domain language well enough to identify the real needs behind stakeholder statements, and she understands enough about IT to communicate those needs to architects and developers in a way they can implement.
Seven Capabilities of a Requirements Engineer
The IREB syllabus identifies seven essential capabilities:
What is the most common reason for deficient requirements according to IREB?
- Communication between stakeholders and developers fails because of different vocabularies, implicit knowledge, and the limitations of the communication medium
- Focusing and simplification are natural human transformations that cause information loss
- Glossaries, modeling languages, and validation are the main countermeasures
- The requirements engineer is a translator between the business domain and the development team
- IREB defines 7 key capabilities: analytic thinking, empathy, communication, conflict resolution, moderation, self-confidence, and persuasiveness