Software Requirements Prompts: Define and Check a Feature
Before asking AI to generate code, make the requested behaviour clear. A small feature needs a user, inputs, outputs and rules for unusual cases. These prompts are for describing a feature and checking its acceptance criteria; the beginner coding and debugging resources cover implementation.
A small workflow
- Describe the user task and current problem without selecting a solution too early.
- Write examples of expected behaviour, including missing or invalid inputs.
- Confirm the brief and acceptance checks before coding starts.
Worked example
‘Add a search box’ is incomplete. For a prompt library, specify which fields are searched, whether category filters remain active and what appears when nothing matches. A sample query and its expected result make the requirement easier to discuss and test.
Define the user task
You get: A small problem statement and essential questions.
Bring: request, user, current, problem
I want a feature described as [request] for [user]. Current behaviour is [current] and the problem is [problem]. Rewrite this as a clear user task, then list the smallest useful outcome and up to three questions that would change the design. Keep suggested features separate from requirements. Do not add accounts, tracking or storage unless requested.
Follow-up
Which part of the request describes a solution rather than the user’s underlying need?
Write observable acceptance checks
You get: Examples of behaviour that can be tested.
Bring: brief, rules, examples
For this confirmed feature brief [brief], write acceptance checks as starting situation, action and expected result. Use these supplied rules [rules] and examples [examples]. Cover the normal path and a no-result or empty-input case where relevant. Mark unresolved behaviour instead of choosing it. Avoid checks that merely repeat implementation details.
Follow-up
Which check would reveal a result that looks correct but does the wrong thing?
Choose the important edge cases
You get: A short prioritised list of unusual inputs.
Bring: feature, rules
Review this feature [feature] and its known input/output rules [rules]. Suggest up to six edge cases, explaining the user impact of each. Distinguish cases supported by the brief from new policy decisions. Prioritise likely or consequential failures, not every hypothetical combination. Ask me to decide missing rules.
Follow-up
Keep only the three cases worth checking in the first version.
Prepare the development brief
You get: A concise brief with decisions and open questions.
Bring: requirements, checks, issues
Assemble a brief from these confirmed requirements [requirements], acceptance checks [checks] and unresolved issues [issues]. Include user purpose, inputs, outputs, constraints and what is outside scope. Keep approvals and unanswered questions visible. Do not invent a technical stack or promise a delivery date. The result should help a developer estimate the work accurately.
Follow-up
Read the brief as the developer and ask the two questions most likely to change the estimate.
Check the result
- Separate confirmed requirements from suggested conveniences.
- Do not add tracking, payments or data storage implicitly.
- Review security and privacy needs appropriate to the actual feature before implementation.
