Software Documentation
Start with one rule and follow one operation
Imagine a fictional board with columns Ready and Working. Card C-1 begins in Ready. The chosen rule is that every active card has exactly one location on this board. This original rule sheet follows a move to Working. It is a reasoning exercise, not a report that any application has implemented or passed a test.
01
Define the objects and the scope of the rule
Write the card identifier, the two column names and the meaning of active beside the rule. For this exercise, active means included in the board’s current card set. C-1 is the same card before and after a move; its identifier does not change with its column. The rule concerns location within this board, not ownership, scheduling or another feature. Keeping the scope narrow lets a reviewer inspect the example directly. Additional features would need their own definitions instead of being silently included in the word location.
02
Describe the move as a complete state change
The starting state lists C-1 in Ready only. The proposed ending state lists it in Working only. A move must therefore remove the old placement as well as establish the new one in the resulting state. Listing C-1 in both columns would conflict with the chosen rule; listing it in neither while still calling it active would also conflict. This description concerns the states being compared. It does not prescribe a particular implementation or establish how a real application handles intermediate steps, concurrent edits or failures.
03
Record the exception that needs another decision
Ask what should happen when a card is deleted or archived. The present sheet does not define that operation. Mark it unresolved rather than assume that removal from a column automatically changes active status. The reusable fields are object identifiers, scope, rule, starting state, proposed operation, ending state and open cases. A later design decision can extend the sheet with explicit archive behaviour. Any implementation would then need appropriate verification against those stated requirements; the worksheet itself remains a record of the intended model.