requirements-design

Record the original request verbatim, then rewrite evaluative words like "fast" or "user-friendly" into observable quantities such as response time limits or step counts. Each criterion must be observable, unambiguous, and reproducible via a test or command.

A good acceptance criterion is observable (judgable from output, state, or logs), unambiguous (all readers reach the same verdict), and testable (reproducible by a procedure or command). Write one condition per line at a granularity that maps directly to a test name.

Skip them when the change does not alter behavior, such as wording, formatting, or configuration value edits, or when the request already states verifiable conditions. Also skip when the task is investigation-only with no resulting change.

Rewrite the acceptance criterion and preserve the change as a visible record, for example striking through the old condition and noting the new value, date, and who requested it. Deleting conditions silently makes it impossible to distinguish missed requirements from changed ones.

Cover only the categories the change actually touches among availability, performance and scalability, operability, migration, security, and system environment. Omit untouched categories entirely so reviewers can distinguish intentional omission from forgotten items.