Who the stakeholders are
A stakeholder is anyone affected by a product or able to influence it. That is a wider group than the person paying for it. A typical list includes the people who will use it daily, the customer who commissions it, the managers who sponsor it, the people who install, maintain and support it, the team that builds it, and sometimes regulators or neighbours who are affected by its operation.
Missing a group is one of the commonest causes of late surprises. The support technician who has to repair the product in a cramped cupboard will often have strong views that nobody asked for. A short exercise at the start, listing every group and asking “who else is touched by this?”, costs little and prevents awkward discoveries later.
What you are trying to learn
You are looking for needs, not solutions. People tend to describe what they think they want, which is often a proposed fix. “We need a bigger spreadsheet” may hide the real need, which could be to see a trend across several months without copying data by hand. Asking why a few times, politely, usually moves the conversation from a suggested answer to the underlying problem.
You also want constraints, such as deadlines, budgets, existing equipment and rules, and the priorities among competing wishes. Later work, such as separating functional and non-functional requirements, depends on having good raw material from these conversations.
Stakeholder interviews
Interviews are the most common technique, and they work best when prepared.
Before:
- Learn the basics of the person’s role and the existing situation, so you do not spend their time on questions you could have answered yourself.
- Prepare open questions and a few topics, not a rigid script.
- Decide how you will record the answers, and ask permission if recording audio.
During:
- Start with the person’s work and problems before discussing any solution.
- Prefer open questions: “Walk me through the last time that happened” tends to produce more than “Do you like the current system?”
- Ask for specific examples and recent events, since memory of general habits is often tidier than reality.
- Listen more than you talk, and tolerate pauses.
- Avoid leading questions that suggest the answer you want.
- Ask “what else?” and “is there anyone else I should talk to?” before closing.
After:
- Write up notes promptly, while they are fresh, and send a short summary back so the person can correct misunderstandings.
Good listening and clear questions are part of soft skills, and they improve with practice. One-to-one interviews also suit sensitive topics, since people may be more candid than in a group.
Observation
What people say and what they do can differ, usually without anyone being dishonest. Routine tasks become invisible to the person doing them. Watching someone work, sometimes called job shadowing or contextual observation, can reveal workarounds, sticky notes on monitors, steps done in a different order than the procedure says, and interruptions that never come up in conversation.
Observation takes more time and needs consent. Where the work involves safety, privacy or confidential material, follow the site rules and get proper permission. Keep a respectful distance and do not interfere with safety-critical tasks. Hazard identification can be informed by what you see, for instance when a task regularly involves an awkward or risky action.
Workshops and group sessions
A workshop brings several stakeholders together to explore needs, resolve conflicts and set priorities. Groups help when people need to hear each other, for example when two departments assume different things about the same process. They carry risks too: a senior person may dominate, and quieter members may not speak. A facilitator who invites everyone’s input, and a clear agenda, help. The practices in running effective technical meetings apply directly.
Other sources
- Existing documents. Manuals, procedures, previous specifications, incident logs and complaints show what has already gone wrong.
- Surveys and questionnaires. Useful when you need breadth across many users, though the questions must be carefully written and the answers are shallow.
- Prototypes and sketches. People often react more clearly to something they can see than to a description. A paper mock-up or rough prototype can draw out requirements nobody could articulate.
- Existing products. Looking at what competitors or earlier versions do, and where users struggle with them.
Using several techniques together generally gives a more reliable picture than relying on one.
Dealing with conflicting needs
Stakeholders will disagree. Operators want speed, maintainers want access panels, finance wants low cost. Your role is not to pick a winner silently but to record each need, make the conflict visible and take it to whoever has the authority to decide. A neutral summary of the options, perhaps scored in a decision matrix, can make the discussion calmer. Where the disagreement is technical, the advice on handling technical disagreements applies.
Checking what you heard
Before treating anything as a requirement:
- Restate it in your own words and confirm it with the source.
- Check that it is a need and not a disguised solution.
- Ask how it could be verified.
- Note who raised it and why, so that its origin is not lost.
- Record priority, if stakeholders can give one.
Then turn the notes into well-formed statements, following the guidance on writing requirements, and have stakeholders review them.
Common pitfalls
- Speaking only to managers and not to the people who do the work.
- Accepting the first answer without asking for examples.
- Letting one loud voice stand for the whole group.
- Treating gathering as a one-off event. Needs surface gradually, and revisiting stakeholders as understanding grows is normal.
- Hearing only what confirms your existing design ideas.
Curiosity, patience and a habit of checking back are the most useful tools. The aim is a shared, accurate picture of what people need, recorded in a form the whole team can use.