Turn a stakeholder's one-paragraph ask into a BRD a developer won't have to guess at

Turn the stakeholder request below into a business requirements document precise enough that a developer or vendor wouldn't need to guess at anything material.

BUSINESS PROBLEM AS STATED
"We need a dashboard so managers can see team performance without asking finance for reports every week."

REQUESTER AND OTHER STAKEHOLDERS
Requested by the VP of Operations; other stakeholders include team managers who'd use it and Finance, who currently owns the underlying data.

WHAT'S IN SCOPE (AS UNDERSTOOD SO FAR)
A dashboard showing per-team KPI actuals vs targets, refreshed weekly, viewable by managers for their own team only.

WHAT'S EXPLICITLY OUT OF SCOPE
Not building any new data source — pulls only from existing Finance spreadsheets; not giving managers edit access to underlying numbers.

HOW SUCCESS WILL BE MEASURED
Given as 'managers stop asking Finance for reports' — no number attached yet.

Start by restating the business problem in your own words, separate from any solution — stakeholders often describe a desired solution when they mean to describe a problem, and conflating the two locks in an approach before the actual need is fully understood; if the input reads like a solution disguised as a problem, name that distinction explicitly. Write the in-scope section as concrete, testable requirements, not aspirations — each requirement should be something a developer could build against and a reviewer could verify as done or not done. The out-of-scope section matters as much as the in-scope one: state explicitly what this project will NOT do, especially anything a stakeholder might reasonably assume is included but isn't, since unstated scope assumptions are the most common source of late-stage rework and disputed 'that wasn't in scope' arguments. Where the input leaves a requirement ambiguous — timing, volume, edge cases, who approves what — do not silently pick an interpretation; list it as an open question requiring stakeholder confirmation, tagged with who should answer it. State the success metric as something measurable with a real number or checkable condition, and if what was given is vague ('improve efficiency'), push back on it in the document by proposing a specific measurable version rather than accepting the vague one as-is.

WHAT NOT TO DO
Do not fill scope gaps with your own assumptions presented as settled fact — every genuine gap becomes a flagged open question, not an invented default. Do not write requirements as user-story fluff without concrete acceptance criteria.

OUTPUT FORMAT
1. Business Problem (restated, solution-neutral).
2. In-Scope Requirements (numbered, each testable).
3. Out-of-Scope (explicit list).
4. Success Metric (measurable, with a pushback note if the original was vague).
5. Open Questions for Stakeholder Confirmation, each tagged with who should answer it.