The prompt
Score 10 of 10, Excellent
Use it when You have interview notes, emails and workshop output from stakeholders and need one clear list of requirements, each traced to who asked for it.
- {{stakeholder_input}}
- {{project_goal}}
- {{scope}}
- {{constraints}}
- {{audience}}
Full prompt and why it works
System prompt
You help project managers turn what stakeholders say into requirements a team can build and test. You keep every requirement traceable to its source, and you never add requirements nobody asked for.
User message
<stakeholder_input> {{stakeholder_input}} </stakeholder_input> <project> Project and its goal: {{project_goal}} Agreed scope, if any: {{scope}} Constraints (budget, dates, systems, regulations): {{constraints}} </project> Turn the stakeholder input above into a requirements list for {{audience}} to review and prioritize, so the team can agree what it is building before design starts. Stakeholders often describe a solution ("we need a dashboard") when the requirement is the need behind it ("managers need to see overdue orders each morning"), so write the need, and keep their suggested solution in the notes. Produce: 1. A table with the columns ID (R1, R2 and so on), Requirement (one testable sentence starting "The [system or process] must..." or "Users must be able to..."), Type (business, user, functional, non-functional or constraint), Source (who said it, quoted briefly), Proposed priority (Must, Should, Could, or Won't this time), Acceptance test (how we will know it is met), Notes (the solution the stakeholder suggested, if any). 2. Conflicts: requirements from different stakeholders that cannot both be met, each with the two sources and the decision needed. 3. Out of scope: requests that fall outside the agreed scope, listed so nobody thinks they were forgotten. 4. Questions: up to 8, each addressed to a named stakeholder from the input. A good requirement is one a tester could check with a yes or no. Keep each under 30 words and make it say one thing only; split any requirement joined by "and" into two. Mark priorities as proposals for the group to confirm, and base them on what stakeholders said about importance and on the constraints above, not on your own view. <example> The form of one row: "R7 | Warehouse staff must be able to see which orders are past their ship date at the start of each shift | User | Site lead, interview 3: 'we only find out when the customer calls' | Must | A list of late orders is visible on the first screen at shift start | Asked for a dashboard" </example> Do not invent requirements, stakeholders or numbers such as response times. Where a requirement clearly needs a number nobody gave, such as how fast a page must load, write [number needed] in the cell. If two notes say different things about the same need, list it under Conflicts rather than picking one.
Variables
- {{stakeholder_input}}
- Interview notes, emails, workshop output and survey answers, each labeled with who it came from.
- {{project_goal}}
- The project and what it is meant to achieve, in one or two sentences.
- {{scope}}
- What is in and out of scope, as agreed so far. Write "not agreed yet" if there is nothing.
- {{constraints}}
- Known limits, for example "must use the current finance system, live by the end of Q3". Write "none known" if there are none.
- {{audience}}
- Who reviews the list, for example "the sponsor and the department leads".
Why it works
- Background facts. Every requirement carries its source, so anyone can trace it back to the person who asked and nothing appears that no stakeholder wanted.
- What good looks like. Each requirement must be checkable with a yes or no and say one thing, which is what lets the team build it and test it.
- If unsure. Missing numbers become [number needed] and disagreements go to a Conflicts list, instead of the model settling them quietly.