Protocol
Specify the needed outcome before prescribing the solution
Add another dashboard may be a solution to a question nobody has asked yet.
When it fits
- A feature request names a particular tool or interface before the underlying need is clear.
When to avoid it
- Do not remove security, compatibility or other binding constraints in the name of creativity. A solution-neutral sentence can still be vague or untestable.
Why it matters
Restate the required outcome and how it can be checked. Separate that requirement from a proposed implementation. Preserve genuine constraints, but label them as constraints with a reason. This leaves room to find a simpler solution without weakening what the system must achieve.
Steps
- Ask what the proposed feature must enable someone to do.
- Write an observable result and relevant operating conditions.
- Record mandatory implementation constraints separately from preferences.
An example
Instead of requesting a new dashboard, specify that the operator must identify every rejected record and its actionable reason after a run.
Check your result
Two different designs could be compared against the same stated outcome, unless a justified constraint excludes one.
Keep this limit in mind
- Do not remove security, compatibility or other binding constraints in the name of creativity. A solution-neutral sentence can still be vague or untestable.
Connected ideas
Useful withCheck that it meets the specification and solves the real problem
Evidence and sources
NASA's requirement-writing guidance recommends stating what is needed rather than prematurely specifying how, with precise verification criteria.
Necessary implementation constraints must still be retained and justified rather than removed merely to make the statement solution-neutral.
Appendix C: How to Write a Good Requirement · C.2 Product Requirement; C.4 Verifiability/Testability