Eliciting requirements from stakeholders

Stakeholder analysis

List everyone affected or with influence: sponsors, users, managers, operations, compliance, IT, customers. Map them on a power/interest grid:

• High power, high interest: manage closely.
• High power, low interest: keep satisfied.
• Low power, high interest: keep informed.
• Low power, low interest: monitor.

A RACI matrix clarifies who is Responsible, Accountable, Consulted and Informed for each decision.

Elicitation techniques

• Interviews: one-on-one; open questions, then specifics.
• Workshops: bring stakeholders together to agree on requirements and resolve conflicts quickly.
• Observation / job shadowing: watch the actual work; people often describe processes differently from how they do them.
• Document analysis: existing procedures, forms, reports, system screens, regulations.
• Surveys/questionnaires: reach many users.
• Prototyping / wireframes: show something tangible to get better feedback.
• Brainstorming, focus groups, reverse engineering of existing systems.

Asking good questions

• Start with the why: "What problem are we solving? What happens if we don't?"
• Use the 5 Whys to reach root causes.
• Ask about exceptions: "What happens if the document is missing? Who approves when the manager is on leave?"
• Ask for examples and data: "How many applications a day? How long does each step take?"
• Confirm understanding by paraphrasing and documenting.

Handling conflicting requirements

Bring the stakeholders together, go back to business objectives, make trade-offs explicit (cost, time, value, risk), use data, and escalate to the sponsor for a decision when needed. Document the decision and its rationale.

Check yourself

• Who would you interview to improve a hospital's patient admission process?
• Write five questions for the first meeting with a sales head who wants "a better CRM".
• How would you resolve two departments wanting opposite things from a system?