swurslisted

# /swurs — User Requirements, and what a rewrite changed **In plain words.** Before anyone can say a rewrite is as good as the version it replaces, someone has to write down what that older version actually does. This makes that list: one line per job the software has to do, and for each one, what goes wrong for a real user if it doesn't, what the user supplies, what comes back, and which test will prove it. Run it on both builds and it holds the two lists against each other and tells you what the rewrite changed — and, for each change, whether it matters. Two jobs that are really one. A URS says what a build is required to do. A rewrite comparison is two URS documents held against each other — which is only possible if both were written to the same shape, which is why one skill owns both. | Mode | Produces | Script | |---|---|---| | **Specify** (default) | one URS per build | `build_urs_md.py` | | **Compare** | one difference document per pair | `compare_urs.py` | ## 0. Establish the build Same four questions as `/swvalidation`, for the same reasons: **subject**, **variant**, **where the source is**, **which commit**. A URS that does not name the build it describes cannot be compared to anything. In compare mode you need two finished URS runs, each with its `--emit-keys` JSON. Never write a comparison from one URS and an impression of the other. ## 1. Specify — one requirement at a time Work use case by use case. A use case is a **goal a named actor has** ("Practiti