Gathering Requirements: Stakeholders and Interviews

The Role of the Business Analyst

The business analyst (BA) turns a business problem into clear requirements that a team can build and test. They don’t start with the solution: they first try to understand which problem is being solved, for whom, and how you will know it has succeeded.

Running case for the course: the fictional retailer Les Paniers du Coin wants to computerize the preparation of online orders picked up in store.

Identifying Stakeholders

A stakeholder is any person or team affected by the project or able to influence it: the management that funds it, the daily users (order pickers, customers), the IT department that will maintain the tool, the data protection officer, accounting… Forgetting a stakeholder means discovering a blocking requirement too late.

You classify them in a power/interest matrix:

	Low interest	High interest
High power	Keep satisfied	Manage closely
Low power	Monitor	Keep informed

Stakeholders to “manage closely” take part in workshops and validate decisions; those to “keep informed” receive regular write-ups and can be asked about their day-to-day work.

Running an Interview or Workshop

A one-on-one interview lets you go deep with one person; a workshop brings together several stakeholders to compare viewpoints and make decisions. In both cases:

1. Prepare: objective, list of topics, existing documents (procedures, spreadsheets, screenshots).
2. Get them to tell the story: “Show me how you process an order today.” Observing the workstation reveals workarounds (side spreadsheets, sticky notes).
3. Ask open questions and follow up: “What happens when a product is out of stock?”, “How often?”.
4. Rephrase to check your understanding: “If I sum up, you…”.
5. Write up the notes the same day and have the interviewee validate them.

Working Back from the Solution to the Need

Interviewees often state a solution: “We need an Excel export.” That’s not wrong, but it’s rarely the real need. The 5 whys technique consists of asking “why?” several times:

"We need an Excel export."
  Why? "To count orders per time slot."
  Why? "To know how many pickers to schedule each morning."
→ Need: know each morning how many orders have to be prepared per time slot.

The open need leaves several possible solutions (an export, a planning screen, an alert); the team will choose the best one.

Functional and Non-Functional Requirements

• A functional requirement describes what the system does: “The picker can mark an order as ready.”
• A non-functional requirement describes how it does it, or under which constraints: response time, availability, security, accessibility, data hosting, regulation.

Non-functional requirements are often forgotten because nobody states them spontaneously. Ask the question explicitly: how many concurrent users? What happens if the tool is unavailable? What personal data is processed?

A good requirement is measurable: “fast” can’t be tested; “the order list displays in under 2 seconds for 500 orders” can.

Key Takeaways

• Understand the problem before the solution.
• Map stakeholders and adapt how involved they are.
• Open questions, observation, rephrasing, validated write-up.
• Functional and non-functional requirements, always measurable.