In software requirements engineering, requirements elicitation, stakeholders, and SRS are tightly connected. Within the broader module on Requirements Analysis, SRS Standards, and Requirements Gathering Tools, one of the most persistent causes of project failure is not coding error but poor understanding of what users actually need.2 ISO/IEC/IEEE 29148 defines elicitation as the systematic use of techniques such as prototyping and structured surveys to identify and document customer and end-user needs, emphasizing that requirements must be understood in relation to stakeholders, operating environment, and constraints. In practice, this means barriers arise whenever analysts fail to bridge the gap between the user world and the technical world.2

Barriers to eliciting user requirements commonly include communication gaps, hidden or tacit expectations, domain complexity, stakeholder conflict, limited access to the right people, organizational politics, and volatility in business needs.2 These barriers distort requirement quality by introducing ambiguity, omissions, contradictions, and weak traceability into the final specification.2 Because the SRS should support validation, testing, and agreement, poor elicitation often produces downstream defects, rework, and disputes over scope.2

A useful way to view the problem is as a translation challenge:

For this course section, the central learning task is not only to list barriers, but to diagnose how each barrier affects requirement accuracy and to select suitable countermeasures such as interviews, workshops, observation, and prototyping.3

Footnotes

1. Requirements Elicitation in Software Engineering: A Complete Guide - Overview of elicitation, common barriers, stakeholder roles, and techniques. ↩ ↩² ↩³

2. Requirements Gathering in Software Engineering: Process, Techniques, and Best Practices - Explains elicitation versus broader gathering, technique selection, traceability, validation, and documentation quality. ↩ ↩² ↩³ ↩⁴

3. IEEE 29148-2018 Standard for Requirements Engineering - Summarizes ISO/IEC/IEEE 29148 concepts including stakeholder needs, environment, and requirements definition. ↩ ↩² ↩³

4. Issues and Challenges of Requirement Elicitation in Large Web-Based Information Systems (PDF) - Discusses communication barriers, stakeholders expressing solutions instead of needs, and environmental/domain constraints. ↩

5. Requirement Elicitation Techniques in Software Engineering - Reviews interviews, workshops, observation, prototyping, and typical elicitation obstacles. ↩ ↩²

6. Study Notes Week 2: Requirements Elicitation & Collaboration (PDF) - Covers planning for elicitation, collaboration, logistics, and stakeholder engagement risks. ↩

1. Major Barriers and Why They Occur

The first major barrier is the communication gap. Users often speak in business, operational, or domain terms, while analysts and developers think in models, data, interfaces, and constraints.2 Even when both sides use the same everyday words, they may assign different meanings to them. Research on multidisciplinary collaboration shows that different groups often operate in different “object worlds,” making mutual interpretation difficult unless concepts are externalized through artifacts such as prototypes or models.

The second barrier is tacit knowledge. Stakeholders frequently know how work is done, but not how to express it as formal requirements.2 They may omit exception paths, workarounds, regulatory concerns, or quality expectations because these seem “obvious” to them. Tacit knowledge is especially problematic in environments where much expertise is experiential, local, or embedded in routine practice.2

The third barrier is domain complexity. In complex domains such as healthcare, finance, logistics, or industrial control, requirements are shaped by business rules, compliance obligations, legacy systems, and environmental conditions.2 Asking stakeholders alone is not enough, because some requirements are embedded in documents, regulations, workflows, and interactions with surrounding systems.

The fourth barrier is stakeholder conflict. Different groups may legitimately want different things: users want convenience, managers want reporting, legal teams want compliance, security teams want control, and developers want feasibility and maintainability.2 When these viewpoints are not surfaced and negotiated, the resulting requirement set becomes inconsistent or politically biased.2

The fifth barrier is unstable expectations and changing priorities. Since elicitation takes time, requirements may change as policies, markets, technologies, or organizational structures change.2 Long delays between interviews, documentation, and confirmation can cause the final requirements to reflect an outdated understanding of user needs.

The sixth barrier is poor stakeholder selection or limited access. Effective elicitation depends on speaking with the right representatives: end users, decision makers, domain experts, operators, regulators, and support staff.2 If only sponsors or only managers are consulted, important operational knowledge is lost and the SRS becomes unbalanced.2

Footnotes

1. Issues and Challenges of Requirement Elicitation in Large Web-Based Information Systems (PDF) - Discusses communication barriers, stakeholders expressing solutions instead of needs, and environmental/domain constraints. ↩ ↩² ↩³ ↩⁴ ↩⁵

2. Axel van Lamsweerde Chapter 02 (PDF) - Lists distributed knowledge sources, conflicting viewpoints, tacit knowledge, terminology issues, and stakeholder-driven elicitation techniques. ↩ ↩² ↩³ ↩⁴ ↩⁵

3. The (New) Roles of Prototypes During the Co-Development of Digital Product Service Systems - Explains how prototypes help diverse stakeholders communicate across disciplinary language boundaries. ↩

4. "The Stakeholder-Profile Framework for Tacit Knowledge Acquisition in RE" - Describes tacit knowledge as a critical but difficult-to-elicit source of requirement quality. ↩ ↩²

5. Tacit Requirements Elicitation Framework (PDF) - Discusses tacit requirements, domain understanding, and combining ethnography, focus groups, and interviews. ↩

6. IEEE 29148-2018 Standard for Requirements Engineering - Summarizes ISO/IEC/IEEE 29148 concepts including stakeholder needs, environment, and requirements definition. ↩ ↩²

7. Requirement Elicitation Techniques in Software Engineering - Reviews interviews, workshops, observation, prototyping, and typical elicitation obstacles. ↩

8. Requirements Gathering in Software Engineering: Process, Techniques, and Best Practices - Explains elicitation versus broader gathering, technique selection, traceability, validation, and documentation quality. ↩ ↩²

9. Issues in Requirements Elicitation (PDF) - Notes that volatile requirements and delayed interpretation can cause misalignment with evolving stakeholder expectations. ↩ ↩²

2. How Specific Barriers Distort Requirement Quality

The effect of elicitation barriers can be explained using classic quality properties of requirements: correctness, completeness, consistency, unambiguity, feasibility, and verifiability.2 A communication gap primarily damages unambiguity and correctness. Tacit knowledge weakens completeness. Domain complexity threatens correctness and feasibility. Stakeholder conflict undermines consistency and prioritization. Volatility affects traceability and baseline control.3

The distortion pathway is often cumulative rather than isolated. For example, an analyst with weak domain knowledge may misinterpret a user statement; because the user assumes shared understanding, they do not correct the analyst; the documented requirement then becomes ambiguous in the SRS; developers implement one interpretation; testers validate another; and the project later experiences rework.3

The relationship can be represented as follows:

In standards-based requirements practice, this is why elicitation cannot be treated as a one-time interview activity. ISO/IEC/IEEE 29148 places stakeholder needs in relation to the defined environment and encourages structured documentation, validation, and traceability. Similarly, requirements gathering guidance stresses that no single technique is sufficient; teams should combine multiple methods because different stakeholders hold different kinds of knowledge.2

A concise analytical model is:

$$\text{Requirement Risk} \approx f(\text{ambiguity} + \text{omission} + \text{conflict} + \text{change} - \text{validation})$$

This formula is conceptual rather than numerical, but it captures an important engineering idea: requirement risk increases when barriers accumulate and decreases when elicitation is triangulated through multiple validating techniques.2

Footnotes

1. IEEE 29148-2018 Standard for Requirements Engineering - Summarizes ISO/IEC/IEEE 29148 concepts including stakeholder needs, environment, and requirements definition. ↩ ↩² ↩³ ↩⁴

2. Study Notes Week 2: Requirements Elicitation & Collaboration (PDF) - Covers planning for elicitation, collaboration, logistics, and stakeholder engagement risks. ↩ ↩²

3. Issues and Challenges of Requirement Elicitation in Large Web-Based Information Systems (PDF) - Discusses communication barriers, stakeholders expressing solutions instead of needs, and environmental/domain constraints. ↩ ↩²

4. Issues in Requirements Elicitation (PDF) - Notes that volatile requirements and delayed interpretation can cause misalignment with evolving stakeholder expectations. ↩ ↩²

5. Requirements Gathering in Software Engineering: Process, Techniques, and Best Practices - Explains elicitation versus broader gathering, technique selection, traceability, validation, and documentation quality. ↩ ↩²

6. Requirement Elicitation Techniques in Software Engineering - Reviews interviews, workshops, observation, prototyping, and typical elicitation obstacles. ↩

3. Scenario Analysis Example

Consider this scenario: a university wants a new advising system. The dean says the system must improve student retention, advisors want a faster interface, the compliance office requires audit trails, IT wants integration with legacy records, and students want mobile self-service.2 After two short meetings, the analyst writes requirements mainly from the dean's perspective.

This scenario contains several likely elicitation barriers. First, stakeholder coverage is incomplete because advisors, students, compliance staff, and integration specialists have different knowledge and constraints.2 Second, “improve retention” is a business goal, not yet a software requirement; it must be decomposed into measurable capabilities, workflows, data needs, and reporting criteria. Third, usability, auditability, and integration may conflict on effort, interface design, and data handling.2 Fourth, important tacit knowledge is likely hidden in advisor workarounds, exception cases, and semester-cycle pressures, which short meetings rarely expose.2

A better response would use mixed elicitation methods. Interviews with each stakeholder group would capture role-specific needs; observation of advising sessions would reveal actual workflow and bottlenecks; a facilitated workshop would negotiate conflicting priorities; and a prototype would help students and advisors react to concrete screens rather than abstract statements.3 This combination improves the accuracy, completeness, and testability of the resulting SRS.2

Footnotes

1. Requirements Gathering in Software Engineering: Process, Techniques, and Best Practices - Explains elicitation versus broader gathering, technique selection, traceability, validation, and documentation quality. ↩ ↩² ↩³

2. IEEE 29148-2018 Standard for Requirements Engineering - Summarizes ISO/IEC/IEEE 29148 concepts including stakeholder needs, environment, and requirements definition. ↩ ↩² ↩³

3. Axel van Lamsweerde Chapter 02 (PDF) - Lists distributed knowledge sources, conflicting viewpoints, tacit knowledge, terminology issues, and stakeholder-driven elicitation techniques. ↩ ↩² ↩³

4. Issues and Challenges of Requirement Elicitation in Large Web-Based Information Systems (PDF) - Discusses communication barriers, stakeholders expressing solutions instead of needs, and environmental/domain constraints. ↩

5. "The Stakeholder-Profile Framework for Tacit Knowledge Acquisition in RE" - Describes tacit knowledge as a critical but difficult-to-elicit source of requirement quality. ↩

6. Tacit Requirements Elicitation Framework (PDF) - Discusses tacit requirements, domain understanding, and combining ethnography, focus groups, and interviews. ↩

7. Requirement Elicitation Techniques in Software Engineering - Reviews interviews, workshops, observation, prototyping, and typical elicitation obstacles. ↩

8. The (New) Roles of Prototypes During the Co-Development of Digital Product Service Systems - Explains how prototypes help diverse stakeholders communicate across disciplinary language boundaries. ↩

4. Recommended Techniques Mapped to Barriers

A mature elicitation strategy chooses techniques according to the barrier being addressed rather than using one preferred method for every project.2

One strong lesson from both standards and practice literature is that elicitation is collaborative, not extractive.2 Analysts do not simply “collect” ready-made requirements; they help stakeholders discover, clarify, compare, and confirm them. That is especially important in software engineering education, because students often assume users fully know their requirements in advance. In reality, users frequently refine their understanding only after seeing models, examples, and trade-offs.2

Footnotes

1. Requirement Elicitation Techniques in Software Engineering - Reviews interviews, workshops, observation, prototyping, and typical elicitation obstacles. ↩ ↩² ↩³

2. Axel van Lamsweerde Chapter 02 (PDF) - Lists distributed knowledge sources, conflicting viewpoints, tacit knowledge, terminology issues, and stakeholder-driven elicitation techniques. ↩ ↩²

3. IEEE 29148-2018 Standard for Requirements Engineering - Summarizes ISO/IEC/IEEE 29148 concepts including stakeholder needs, environment, and requirements definition. ↩ ↩² ↩³

4. The (New) Roles of Prototypes During the Co-Development of Digital Product Service Systems - Explains how prototypes help diverse stakeholders communicate across disciplinary language boundaries. ↩ ↩²

5. Tacit Requirements Elicitation Framework (PDF) - Discusses tacit requirements, domain understanding, and combining ethnography, focus groups, and interviews. ↩

6. Study Notes Week 2: Requirements Elicitation & Collaboration (PDF) - Covers planning for elicitation, collaboration, logistics, and stakeholder engagement risks. ↩ ↩² ↩³

7. Requirements Gathering in Software Engineering: Process, Techniques, and Best Practices - Explains elicitation versus broader gathering, technique selection, traceability, validation, and documentation quality. ↩ ↩²

8. Issues and Challenges of Requirement Elicitation in Large Web-Based Information Systems (PDF) - Discusses communication barriers, stakeholders expressing solutions instead of needs, and environmental/domain constraints. ↩ ↩²

9. Issues in Requirements Elicitation (PDF) - Notes that volatile requirements and delayed interpretation can cause misalignment with evolving stakeholder expectations. ↩