A Stakeholder Requests Template · Business Analysis Notes

Key ideas#

What it is for#

Pererva and Ivanova include this template as an appendix to their guide. In their model of requirement types, it holds the raw stakeholder requests (they label this type STKR) before you turn them into business requirements, business rules or quality requirements. The RUP Requirements Management Plan template also puts stakeholder requests at the start of its traceability chain, so this document is the first link you can trace back to.

Two properties make it useful:

One stakeholder per document. You capture one person’s view, not a negotiated consensus. Conflicts become visible when you compare documents.
No approval. Nobody signs it off. That frees you to record everything, including half-formed ideas, without a review cycle slowing you down.

Three design choices worth copying#

Prompts to keep going. The problem section reminds the interviewer to keep asking “Anything else?” so the conversation does not stop at the first answer.
A recap step. Before closing, you summarize the stakeholder’s problems in your own words and ask directly whether the summary is accurate and complete. This is the cheapest validation you will ever do.
A separate section for your hypotheses. Problems you suspect but the stakeholder did not raise go into their own section, each checked with the stakeholder: is it real, what causes it, how is it handled today, how important is it compared with the problems they named? Keeping them apart preserves the origin of every item.

What it covers#

Beyond problems, the template asks about the stakeholder’s role and what success looks like for them, their working environment and computer skills, their reaction to a proposed solution, how many people would use it, expectations for reliability, performance and support, and legal or regulatory constraints. These sections act as a checklist of questions that are easy to forget in a free-flowing interview.

How to apply it#

Before the interview, fill in what you already know about the person: name, role, main responsibilities. You arrive prepared and spend interview time on problems.
Use the problem section as your interview guide. For each task the person needs help with, ask: what is the problem, why does it happen, how do you handle it today, how would you like to handle it?
After each answer, ask “Anything else?” at least once.
Recap before you finish. Read back your summary and ask what is wrong or missing.
Raise your own hypotheses last, so they do not steer the stakeholder’s answers. Record their reaction in the analyst’s section.
Close by asking whether you may follow up, and list open questions.
Afterwards, extract business requirements, business rules and quality requirements into your requirements repository, linking each one back to this document.

Fill the document during the conversation or right after it. For repeat interviews with the same person, extend the same document.

Template#

Template

# Stakeholder Requests: <name>, <role>
Interviewer: <name> · Sessions: <dates> · Status: working document, not for approval

## 1. Introduction
- Purpose — record this stakeholder's problems for later analysis
- Audience — business and system analysts on the project
- References — optional: related documents

## 2. About the stakeholder
- Organization, job title, main responsibilities
- What they produce, and who uses it
- How their success is judged
- What gets in the way; what makes the work easier or harder

## 3. Problems (repeat per task)
- Task —
- Problem and its cause —
- How it is handled today —
- How they would like to handle it —
- Anything else? —

## 4. Working environment
- Users' background and computer skills; experience with similar tools
- Platforms in use or planned; applications this must work with
- Expectations for ease of use, training time and documentation

## 5. Recap
- Analyst's summary of the problems, in the analyst's words
- Stakeholder's response: accurate? anything missing?

## 6. Analyst's hypotheses (repeat per hypothesis)
- Suspected problem — is it real? what causes it?
- Current handling / desired handling
- Priority compared with the problems the stakeholder named

## 7. Reaction to a proposed solution (if any)
- Capability presented — reaction — importance to them

## 8. Opportunity
- Who in the organization would use it; how many of each type
- Value of a successful solution to this stakeholder

## 9. Reliability, performance and support
- Availability and speed expectations; who supports it
- Security, installation, licensing, distribution, branding needs

## 10. Other requirements
- Laws, regulations and standards that apply
- Anything else that came to mind

## 11. Wrap-up
- Open questions
- Permission to follow up: yes / no

Example#

At The Workshop (a fictional bike-repair chain), an analyst interviews a front-desk employee.

Problem: customers phone to ask whether their bike is ready. Today the employee walks to the workshop floor to ask a mechanic. They would like to see each repair’s status on their own screen.
Anything else? Customers sometimes arrive to collect a bike that is waiting for a part nobody told them about.
Recap: “So the main pain is answering status questions without reliable information. Is that right?” The employee adds that the evening rush is the worst time.
Analyst’s hypothesis: phone and walk-in bookings may collide in the paper diary. The employee confirms this happens and ranks it below the status problem.

Each item now has a clear origin: said by the stakeholder, or suggested by the analyst and confirmed.

Pitfalls#

Merging several people into one document. You lose who said what.
Writing your solution into their problem. Record the problem as described; solutions belong in section 7.
Treating the document as an agreed baseline. It is raw input; agreement happens later, on the analysed requirements.

Sources and further reading#

A. Pererva, V. Ivanova. The Analyst’s Path: A Practical Guide (in Russian), appendix “Stakeholder Requests”.
IBM Rational Unified Process (RUP) document templates: Requirements Management Plan (stakeholder requests as the first traceability item).