02 · Requirements · Rule table
“Extra sign-off depending on the case” cannot be written as a requirement
The requirements analyst writes rules already chosen for phase one as if, then, not allowed. He does not decide commercial priority. The twenty-thousand-yuan threshold is not his.
| If | Then | Not allowed |
|---|---|---|
| Under 20,000 yuan, and within budget | Ends when the department manager passes | The requester adds the finance director on their own |
| 20,000 yuan or above, or over budget | Must reach finance after the department manager | Skip finance and end |
| Attachment found wrong only after paid | Void and reverse with a red-ink voucher, open a new document | Directly change the amount on a paid document |
| Claimed urgent, attachment later | Reserve budget first, attach within three working days, otherwise freeze that person's new documents | “Attach later” with no due date |
The requirements analyst folds facts into sentences that can have only one reading
The business analyst brings contradictions back. The product manager decides which contradictions enter phase one. The requirements analyst only handles the chosen part, and writes it as sentences engineering can implement, testing can judge, and the business can recap. The mark of the role is allergy to fuzzy words. Flexible, intelligent, as far as possible, depending on the case, appropriate, relevant people — all get sent back. Those words can get everyone to nod in a meeting. In a system they have no matching judgement. Whoever has the right to interpret “depending on the case” at runtime becomes an approver outside the system, and the document goes back to WeChat.
He does not decide commercial priority. The twenty-thousand-yuan threshold is set by finance and product together, not because the analyst finds it reasonable. He has to make sure that once the threshold is written, there is no second oral threshold. He is also not the prototyper. He will not let the prototype place buttons before the sentence is finished. Buttons make the customer think the rule already exists.
A rule has to be able to be turned into a failing case
DaXi Technology requirement entries are fixed to three columns: if, then, not allowed. If writes the trigger, including amount, state, time, and role. Then writes the result the system must leave, including where the state moves, whose to-do appears, which ledger changes. Not allowed writes the shortcut most easily dressed up as “convenient”. Missing one of the three columns, testing can only say it looks normal. Example: “large amounts need extra sign-off” without amount and role. Engineering will build an optional CC. The business will think that is extra sign-off. At acceptance both sides will feel the other did not understand.
Exceptions must write a due date. Urgent attach-later without three working days and a freeze becomes permanent. If a paid document is allowed to change amount, the accounting trail breaks. These not-allowed lines are not the analyst making life hard for the customer. They are real edits he has seen on past documents. A rule with no historical document, he marks “not yet verified against an old document”. He does not write a guess as an acceptance standard.
How forty expense documents folded into the table above
A trading company said approval was fairly flexible. The business analyst brought back forty closed expenses. The requirements analyst classified by amount and path, not by story. Documents under 20,000 yuan mostly ended at the department manager. Finance appeared only when over budget. Of documents at 20,000 yuan and above, three had the requester pull the finance director into the group at the last minute, and one of those was paid with no finance comment. Two documents had the amount changed after paid. Finance later made a red-ink reversal, but the original amount was still wrong. Six documents attached later. Two were still missing at month-end.
The table was therefore written as four rows, not “extra sign-off per company policy, flexibly”. After go-live nobody asked in the group whether this one needed extra sign-off: amount and budget can be calculated, and there is only one path. The requester can still remark “please have the director look”. The remark does not change the flow, and does not let the document end while the director has not acted. Testing builds one pass and one not-allowed for each of the four rows. If the not-allowed row fails, there is no sign-off.
Only after the sentences are clear do they go to the Prototyper. If at prototype review the business says “sometimes we still need extra sign-off”, the analyst sends “sometimes” back to product and finance. He does not add a free people-picker on the prototype to stand in for a rule that is not yet decided.