Barriers to Eliciting User Requirements

Requirements elicitation is the process of gathering requirements from stakeholders (users, clients, domain experts). Several barriers make it difficult to obtain complete, accurate, and consistent requirements.

1. Communication barriers / different vocabularies

Users describe needs in business/domain terms, while developers think in technical terms — the "language gap." Terms like "fast", "easy", "report", or "processing" mean different things to each side, causing misunderstandings and ambiguous requirements.

2. Tacit / unstated knowledge ("users don't know what they want")

Users often cannot articulate their real needs because the work is automatic/habitual for them. They may also not know the possibilities of software, so they under-specify or ask for what's easy to describe rather than what is needed.

3. Social and political barriers (organizational conflict)

Stakeholders have conflicting objectives and priorities; different departments/users may compete for limited resources or disagree on who the system should favour. Users may fear job loss, loss of autonomy/power, or added work, so they resist or withhold information. Reluctance to delegate decisions leads to bottlenecks.

4. Volatile / changing requirements

Requirements change over time — the business, market, technology, or user understanding evolves during the project. Elicited requirements may be obsolete by the time they are implemented, and users keep adding "corrections."

5. Incomplete knowledge of the problem domain

The analyst may not understand the business process deeply; users may reveal requirements incrementally only as prototypes emerge. Domain complexity (regulations, workflows) is hard to capture fully in one pass.

6. Undiscoverable/implied requirements ("whatever is cheapest/fastest")

Stakeholders often assume certain things are obvious and omit them; ambiguity in terminology/scope leads the developer to guess, producing wrong assumptions that surface much later.

7. Lack of stakeholder availability/commitment

Busy users give limited time; meetings are skipped; priorities are low — resulting in incomplete elicitation. Without a committed "champion," requirements gather slowly and inaccurately.

8. Ambiguity & interpretation of requirements data

Even recorded requirements can be ambiguous — multiple interpretations (see IEEE's unambiguous characteristic). Requirements that cannot be verified and are not traceable create confusion later.

How to reduce these barriers (brief)

• Structured elicitation techniques: interviews, questionnaires, brainstorming, focus groups, facilitated workshops (JAD — Joint Application Development), prototyping, use cases/user stories, observation, and document analysis.
• Iterative elicitation: involve users throughout; prototype to reveal implicit needs.
• Formalize & validate: record in the SRS, review with all stakeholders, use verification/validation to resolve ambiguity and conflicts.

Summary table

Barrier	Nature	Mitigation
Communication gap	Different vocabularies	Workshops, JAD, visual models
Tacit knowledge	Users can't express needs	Prototyping, observation, scenarios
Politics/conflict	Conflicting interests & fears	Facilitated negotiation, stakeholder management
Volatility	Requirements drift	Change control, iterative development
Domain complexity	Analyst lacks domain knowledge	Domain experts, iteration
Unstated assumptions	Hidden/implied needs	Questioning, checklists, formal SRS review
Low availability	Users not engaged	Scheduling, sponsorship, champions
Ambiguity	Multiple interpretations	Unambiguous SRS, validation

Summary: the main barriers to eliciting user requirements are communication gaps, tacit/unarticulated knowledge, socio-political conflicts among stakeholders, requirement volatility, domain complexity, unstated assumptions, limited stakeholder availability, and ambiguity — all best overcome with structured techniques, iteration, prototypes, and formal SRS validation.