Add planning baseline: BC, SA, PP and two gateways
Create the Business Case, Stakeholder Analysis (S01 course participant, S02 Udemy coursists, S03 GitHub viewers), Project Plan and the milestone documents MIL-001 (project setup, 6 tasks) and MIL-002 (game implementation, 8 tasks) for the console Blackjack game. Register PP and MIL in the artifact registry, set the PO language to en, and link the synced Gitea milestones in the Gateway Schedule. Refs #1 Refs #2 Refs #3 Refs #4 Refs #5 Refs #6 Refs #7 Refs #8 Refs #9 Refs #10 Refs #11 Refs #12 Refs #13 Refs #14
This commit is contained in:
@@ -0,0 +1,27 @@
|
||||
# Operation Contract (OC)
|
||||
|
||||
Cite in `CrossReference` only if the instance exists (`new-artifact.sh` checks this for you):
|
||||
|
||||
- **SSD** — **Required source**: each contract traces to exactly one SSD message
|
||||
- **DM** — Classes/associations named in pre/postconditions
|
||||
- **SD** — Forward: the design realizing each contract's postconditions
|
||||
|
||||
## Required sections (after Metadata / Version History)
|
||||
|
||||
One block per system operation, each containing:
|
||||
|
||||
1. **Operation** — complete signature: name, parameter types, return type
|
||||
(must match the SSD message).
|
||||
2. **Cross References** — the SSD message it traces to (one contract per
|
||||
message) and the Domain Model concepts touched.
|
||||
3. **Preconditions** — required state before execution, expressed in Domain
|
||||
Model terms.
|
||||
4. **Postconditions** — state changes only, in Larman's style: *instance
|
||||
created / instance associated / attribute modified*. Declarative ("what"),
|
||||
never algorithmic ("how"); avoid vague text like "system processes the
|
||||
request".
|
||||
5. **Exceptions** — error conditions, each with the failing precondition.
|
||||
|
||||
## Terminology
|
||||
|
||||
Use the IT terms from the dictionary (`DICT`), not the PO terms the Domain Model uses.
|
||||
Reference in New Issue
Block a user