Stakeholders, viewpoints, and the first questions

Everyone who benefits, not everyone who pays

A stakeholder is any person or group that stands to gain from the system once it exists — directly, by using it, or indirectly, by depending on what it produces or on the money it saves. That definition is deliberately wide. It sweeps in business operations managers, product managers, marketing, internal and external customers, end users, consultants, product and software engineers, and the support and maintenance engineers who will still be living with your decisions in five years. If your stakeholder list has one entry on it called the customer, you have not made a list; you have made an assumption.

The list is built at inception and it grows, because you end every conversation with the same question: whom else should I be talking to? The answer is almost never nobody.

Viewpoints conflict by construction

Each stakeholder sees a different system, gains a different benefit, and is exposed to a different risk if the project fails. Marketing wants the feature that makes the product easy to sell. A business manager wants a feature set that fits the budget and hits a market window. End users want the things they already know how to do. Software engineers care about functions no non-technical stakeholder can see, because those functions are what make the visible ones possible. Support engineers care about maintainability, which nobody else has mentioned once.

So the requirements you collect will be inconsistent, and some of them will flatly contradict each other. This is not a failure of elicitation. It is the normal output of asking several honest people what a system should do. Elicitation is made harder still by unclear project goals, differing priorities, unspoken assumptions, words that different people read differently, and requirements phrased so that nobody could verify them.

What the requirements engineer actually does

Two jobs. Find the commonality — the requirements every stakeholder agrees on, which is where the system's spine is. Then find and name the conflicts, rather than quietly picking a side. Every piece of stakeholder information, including the inconsistent and conflicting parts, gets categorised and kept, so that a decision maker can later choose an internally consistent set from it.

Note what this is not. Collaboration does not mean requirements are defined by committee. In many real projects the stakeholders contribute their views and a strong project champion — a business manager, a senior technologist — makes the final call on what makes the cut. Your job is to make that call an informed one.

The first questions are context-free

The opening questions should be context-free: they ask about the customer, the stakeholders and the overall goals rather than about the solution. Who is behind the request? Who will use it? What is the economic benefit of success? Is there another source for what you need? A second set probes the problem — what would good output look like, what problems will this address, what constraints affect the approach. A third set, the meta-questions, audits the conversation itself: am I asking the right person, are my questions relevant, is there anyone else I should see. Use the format once, to break the ice, then replace it with something better — a question-and-answer session is not a strong elicitation instrument.

Worked example — five people who all want BorrowBox

The member wants a tool in thirty seconds and no queue; she risks turning up to a jammed locker with a job half done. The librarian wants an accurate condition history for every tool; he risks being blamed for damage he never saw. The depot admin funds the thing and wants utilisation and fee revenue; she risks paying rent on lockers nobody uses. The locker vendor's field engineer wants a stable firmware contract; he risks eating support calls caused by our software. The neighbourhood board wants evidence the grant was worth it; it risks funding a service the least mobile residents cannot use. Two of those pull against each other immediately: the member wants the hold on a reserved tool to last all afternoon, and the admin wants it to expire in two hours so the tool goes back into circulation. Neither is wrong, and neither can be silently discarded — that conflict is an input to negotiation, and it is why the hold window ends up in the requirements with a number attached.