3 Commits
Author SHA1 Message Date
Tirsvad a999fcda34 Merge pull request 'G1 inception baseline' (#21) from g1-inception-baseline into main
TirSystem/github-action: Sync GitHub mirror metadata / sync-metadata (push) Successful in 5s
Reviewed-on: #21
2026-10-04 17:15:12 +02:00
TirsvadandClaude Sonnet 5.5 cb28865787 Resolve pending commit links in Version History
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-04 23:11:32 +08:00
Tirsvad ddfe96ffa4 Add inception baseline and milestone plan for Higher Lower
Add the Business Case, Stakeholder Analysis and Project Plan, and four
milestones (MIL-001 Project setup, MIL-002 Game logic, MIL-003 Console
game, MIL-004 Documentation and release) with Go/No-Go criteria and
task tables.

Set the PO language to en in the artifact registry. Link the synced
Gitea Milestones (36-39) in the Project Plan. The 20 task rows were
synced as issues #1-#20.

Refs #5
2026-10-04 23:09:31 +08:00
10 changed files with 638 additions and 0 deletions
+3
View File
@@ -0,0 +1,3 @@
[submodule "framework"]
path = framework
url = ssh://git@git.tirsystem.com:10022/TirSystem/SQA-QC-Framework.git
+43
View File
@@ -0,0 +1,43 @@
# Artifact Registry
This project's artifact state. Types, short names and `CrossReference
Candidates` come from the framework catalog
(`framework/registry/artifact-catalog.md`); this file only records where
each document lives in *this* project and the next version to use.
Delete rows for types you don't use. Add a row the first time you create a
document of a type. `Primary File` may contain a glob (e.g.
`docs/uc-*/uc.md`); `framework/scripts/find-crossreferences.sh` reads it.
| Short Name | Artifact Type | Primary File | Next Available Version |
| --- | --- | --- | --- |
| BC | Business Case | docs/business-case.md | 002 |
| SA | Stakeholder Analysis | docs/stakeholder-analysis.md | 002 |
| PP | Project Plan | docs/project-plan.md | 002 |
| MIL | Milestone / Gateway | docs/milestones/*.md | 005 |
## Languages
Set the PO language when the project starts; `project-planning` asks for it
if it is missing. A translated artifact is named `<artifact>.<language>.md`
(for example `business-case.da.md`); the English file stays the source.
| Setting | Value |
| --- | --- |
| PO language | en |
| High-level register | IT Executive English |
| Technical register | IT Professional English |
| Artifact types | Register | Also kept as a PO-language file |
| --- | --- | --- |
| BC, KPI, PP, MIL | IT Executive English | Yes |
| SA, BMC, BPMN, UCD, US, UC, SSD, DM, RA, GOV, DICT | IT Professional English | Yes |
| OC, SD, DCD, ERD, ADR, TM, RC, QC, source code | IT Professional English | No |
## Notes
- "Next Available Version" is the zero-padded (3-digit) version to use the
*next* time a new document of that type is created. Increment it only when
a brand-new document is created, not when an existing document's
`## Version History` gets a row.
- `ADR` uses 4 digits (`0001`); `RC` is sequential across all artifact types.
+125
View File
@@ -0,0 +1,125 @@
# Business Case
## Metadata
| Key | Value |
| --- | --- |
| ID | BC-001 |
| CrossReference | [SA-001], [PP-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-04 | Proposed | Jens Tirsvad Nielsen | S01 | Initial version | [ddfe96f] |
---
## Executive Summary
Build the "Higher Lower" console game from Udemy's 100 Days of Code (day 14) as a small, readable, dependency-free Python project. The player compares two Instagram accounts and guesses which has more followers; a correct guess adds a point and continues, a wrong guess ends the game. The repository is a learning artefact that other course participants and GitHub visitors can read, run and compare against.
## Methodological and Standards Foundation
Planning follows the project's SQA/QC framework (`framework/`): Business Case, Stakeholder Analysis, Project Plan, milestones synced as Gitea Milestones and Issues, then code. Product quality is described with ISO/IEC 25010:2023 characteristics.
## Problem Statement
The course assignment gives only a brief and a data set. Without a structured, tested and documented solution there is nothing to share, compare or reuse, and the practice value of the exercise is lost.
## Business Opportunity
A clean reference solution with the assignment's function names, tests and run instructions lets fellow participants compare approaches, and shows the author's practice of planning-first, tested development.
## Objectives
1. O1 — Deliver a playable console Higher Lower game using the assignment's data set, art and function names.
2. O2 — Keep the code readable: constants in `constants.py`, Doxygen comments in source, Python 3.13+.
3. O3 — Provide pytest tests for the game logic and the game loop.
4. O4 — Provide a README with venv, pip upgrade, run and test instructions, and a Doxyfile.
5. O5 — Publish the repository with a clear description and topics.
## Scope
### In Scope
- Console game: random pair selection, score tracking, one session that ends on a wrong guess.
- Assignment data set (50 entries), `logo` and `vs` ASCII art.
- `src/`, `tests/`, `docs/` layout, `pyproject.toml`, Python `.gitignore`, `Doxyfile`, `README.md`.
- Repository description and topics on the Gitea repository.
### Out of Scope
- Graphical or web user interface.
- Live data from Instagram or Google Trends.
- Persistent high scores.
- Runtime third-party dependencies.
- Committing or pushing (done by the author after review).
## Expected Benefits
### Tangible Benefits
- A runnable, tested repository other participants can clone.
- A reusable planning and documentation trail.
### Intangible Benefits
- Practice in decomposing a problem into small tasks and testing incrementally.
- Visibility of the author's work to GitHub viewers.
## Strategic Alignment
Supports the author's goal of completing the 100 Days of Code bootcamp with professional-quality practice (planning, tests, documentation).
## Success Criteria
| # | Criterion | Target | Measure |
| --- | --- | --- | --- |
| 1 | Game is playable | A full game runs from `python -m higher_lower` | Manual run |
| 2 | Tests pass | All pytest tests pass | `pytest` exit code 0 |
| 3 | No runtime dependencies | `dependencies = []` in `pyproject.toml` | File inspection |
| 4 | Docs complete | README, Doxyfile and Doxygen comments present | Review record |
| 5 | Repository metadata set | Description and topics visible on the host | Host page |
## Risks
| Risk | Impact | Mitigation |
| --- | --- | --- |
| Token from `.env` leaks into the project | Credential exposure | Keep `.env` gitignored; never import or test it; use only for host sync |
| Data set has entries out of order (e.g. Cardi B, David Beckham) | None for gameplay; may confuse readers | Keep data verbatim; the game compares counts, not list order |
| Same account drawn twice in a round | Meaningless round | Pair selection forces two distinct entries; tested |
## Assumptions
- The README template referenced in the brief will be supplied before the README task starts (see Project Plan open issues).
- Python 3.13 or newer is installed on the author's machine.
## Constraints
- Python 3.13+, `venv`, pytest, `pyproject.toml`, `constants.py`.
- No runtime dependencies unless needed.
- Do not commit, push or open a PR without the author's request.
- Product Owner language: English.
## Cost–Benefit Assessment
| Costs | Benefits |
| --- | --- |
| About one to two evenings of the author's time | A shareable, tested, documented reference solution |
## Stakeholders
| Stakeholder ID (SA) | Interest in this project |
| --- | --- |
| S01 | Product Owner, developer and reviewer; wants a correct, well-practised solution |
| S02 | Udemy coursists; want readable, runnable code with the assignment's function names |
| S03 | GitHub viewers; want a clear description, topics and README, and no dependencies |
## Recommendation
Proceed — the scope is small, the risks are low and the result serves all three stakeholders.
---
[SA-001]: ./stakeholder-analysis.md
[PP-001]: ./project-plan.md
[ddfe96f]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/014-higher_lower/commit/ddfe96ffa459d5e4b2e30d71bd53878aba2cfc5d
+72
View File
@@ -0,0 +1,72 @@
# MIL-001 Project setup
## Metadata
| Key | Value |
| --- | --- |
| ID | MIL-001 |
| CrossReference | [BC-001], [PP-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-04 | Proposed | Jens Tirsvad Nielsen | S01 | Initial version | [ddfe96f] |
---
## Purpose
Decide whether the project foundation (configuration, layout, tooling files and repository metadata) is ready for code to be written on top of it.
## Deliverable
`pyproject.toml`, Python `.gitignore`, `Doxyfile`, the `src/`, `tests/`, `docs/` layout with an importable empty package and `constants.py`, a passing smoke test, and the repository description and topics on the git host.
## Go / No-Go Criteria
| # | Criterion (objectively checkable) | Go | No-Go |
| --- | --- | --- | --- |
| 1 | `pyproject.toml` declares Python `>=3.13`, no runtime dependencies, pytest as a dev dependency | Present | Missing or has runtime dependencies |
| 2 | `.gitignore` excludes `.venv/`, `.env`, `__pycache__/`, `.pytest_cache/`, Doxygen output | All excluded | Any missing |
| 3 | `pip install -e ".[dev]"` and `pytest` succeed in a fresh `.venv` | Exit code 0 | Fails |
| 4 | `Doxyfile` exists and points at `src/` | Present | Missing |
| 5 | Repository has description and topics | Visible on host | Not set |
| 6 | `.env` is not referenced by any file under `src/` or `tests/` | No references | Any reference |
## Dependencies
| Depends on | Reason |
| --- | --- |
| None | First phase |
## Traceability
| Business Case objective / KPI / user story | Reference |
| --- | --- |
| O2, O4, O5 | [BC-001] |
## Ownership
| Role | Stakeholder ID (SA) |
| --- | --- |
| Owner | S01 |
| Approving reviewer | S01 |
## Target Date
2026-10-06 — first window of [PP-001], inside the proposed two-week-or-less target.
## Tasks
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
| --- | --- | --- | --- | --- |
| 1 | Create pyproject.toml | Project configuration for a package named `higher_lower` under `src/`: `requires-python = ">=3.13"`, `dependencies = []`, an optional `dev` group with pytest, and pytest settings (`testpaths = ["tests"]`, `pythonpath = ["src"]`). Keeps runtime free of dependencies for S03. | No | |
| 2 | Verify Python .gitignore | A Python `.gitignore` already exists; confirm it ignores `.venv/`, `.env` (token file, personal use only), caches and Doxygen output (`docs/doxygen/`), adding entries where missing. | No | |
| 3 | Create src, tests and docs skeleton | Add `src/higher_lower/__init__.py`, `src/higher_lower/__main__.py` stub, `src/higher_lower/constants.py` (empty module with Doxygen header) and `tests/` with a smoke test importing the package. `docs/` already holds the planning artifacts. | No | |
| 4 | Add Doxyfile | Doxygen configuration with `INPUT = src`, `OUTPUT_DIRECTORY = docs/doxygen`, Python optimisation (`OPTIMIZE_OUTPUT_JAVA = YES`), recursive scan and `EXTRACT_ALL = YES`, so Doxygen comments in the source can be rendered. | No | |
| 5 | Set repository description and topics | Use the Gitea API with the token from `.env` (personal use; the token is never imported, copied or tested by the project) to set a description and topics such as `python`, `udemy`, `100-days-of-code`, `higher-lower`, `game`, `pytest`. Needs S01's go-ahead before it is run. | No | |
---
[BC-001]: ../business-case.md
[PP-001]: ../project-plan.md
[ddfe96f]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/014-higher_lower/commit/ddfe96ffa459d5e4b2e30d71bd53878aba2cfc5d
+74
View File
@@ -0,0 +1,74 @@
# MIL-002 Game logic
## Metadata
| Key | Value |
| --- | --- |
| ID | MIL-002 |
| CrossReference | [BC-001], [PP-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-04 | Proposed | Jens Tirsvad Nielsen | S01 | Initial version | [ddfe96f] |
---
## Purpose
Decide whether the game's data and pure functions are correct and tested before the interactive loop is built on them.
## Deliverable
The assignment data set and art as modules, constants in `constants.py`, and the pure functions `get_random_account`, `pick_pair`, `format_data` and `check_answer`, all with Doxygen comments and pytest tests.
## Go / No-Go Criteria
| # | Criterion (objectively checkable) | Go | No-Go |
| --- | --- | --- | --- |
| 1 | Data module holds the 50 assignment entries with `name`, `follower_count`, `description`, `country` | 50 entries, all keys | Count or keys differ |
| 2 | `logo` and `vs` art are available unchanged | Present | Missing or altered |
| 3 | Magic strings and numbers live in `constants.py` | None left in logic modules | Any left |
| 4 | `pick_pair` never returns the same entry twice | Verified by test | Can repeat |
| 5 | `check_answer` returns correct result for A, B and equal counts | Verified by tests | Any wrong |
| 6 | `pytest` passes; every public function has a Doxygen comment | Exit code 0, comments present | Fails or missing |
## Dependencies
| Depends on | Reason |
| --- | --- |
| [MIL-001] | Needs the package layout, pytest and constants module |
## Traceability
| Business Case objective / KPI / user story | Reference |
| --- | --- |
| O1, O2, O3 | [BC-001] |
## Ownership
| Role | Stakeholder ID (SA) |
| --- | --- |
| Owner | S01 |
| Approving reviewer | S01 |
## Target Date
2026-10-09 — second window of [PP-001].
## Tasks
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
| --- | --- | --- | --- | --- |
| 1 | Add game data module | Store the assignment's list of 50 dictionaries (`name`, `follower_count`, `description`, `country`) verbatim in `src/higher_lower/game_data.py` as `data`. Order is kept as given; the game compares counts, not position. | No | |
| 2 | Add ASCII art module | Store `logo` and `vs` from the assignment in `src/higher_lower/art.py`, unchanged (raw strings so backslashes survive). | No | |
| 3 | Define constants | Put in `constants.py` the account dictionary keys, choice letters `"a"`/`"b"`, prompt and message texts, and the starting score, so the logic modules hold no magic values. | No | |
| 4 | Implement pair selection | `get_random_account()` returns a random entry; `pick_pair()` returns two distinct entries. Accept an injectable `random.Random` so tests are deterministic. | No | |
| 5 | Implement format_data and check_answer | `format_data(account)` returns "name, a description, from country"; `check_answer(guess, a_followers, b_followers)` returns whether the guess is right, using the assignment's names. Ties count as correct for either choice. | No | |
| 6 | Write unit tests for game logic | pytest tests for the data shape (50 entries, required keys), distinct pairs, `format_data` output and `check_answer` for A higher, B higher and equal. | No | |
---
[BC-001]: ../business-case.md
[PP-001]: ../project-plan.md
[MIL-001]: ./mil-001-project-setup.md
[ddfe96f]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/014-higher_lower/commit/ddfe96ffa459d5e4b2e30d71bd53878aba2cfc5d
+73
View File
@@ -0,0 +1,73 @@
# MIL-003 Console game
## Metadata
| Key | Value |
| --- | --- |
| ID | MIL-003 |
| CrossReference | [BC-001], [PP-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-04 | Proposed | Jens Tirsvad Nielsen | S01 | Initial version | [ddfe96f] |
---
## Purpose
Decide whether the game can be played from start to finish in the console, with score tracking and robust input handling.
## Deliverable
An interactive console game started with `python -m higher_lower`, built on the [MIL-002] functions, with automated tests of the game loop.
## Go / No-Go Criteria
| # | Criterion (objectively checkable) | Go | No-Go |
| --- | --- | --- | --- |
| 1 | `python -m higher_lower` shows logo, Compare A, `vs` art, Against B and a prompt | All shown | Any missing |
| 2 | A correct guess increases the score by one and B becomes the next A | Verified by test | Not so |
| 3 | A wrong guess ends the game and shows the final score | Verified by test | Not so |
| 4 | Invalid input is rejected and re-asked, never crashes | Verified by test | Crash or accepted |
| 5 | Game ends gracefully if the data runs out | Verified by test | Error |
| 6 | `pytest` passes; no runtime dependencies added | Exit code 0 | Fails |
## Dependencies
| Depends on | Reason |
| --- | --- |
| [MIL-002] | Uses the data, art, constants and logic functions |
## Traceability
| Business Case objective / KPI / user story | Reference |
| --- | --- |
| O1, O3 | [BC-001] |
## Ownership
| Role | Stakeholder ID (SA) |
| --- | --- |
| Owner | S01 |
| Approving reviewer | S01 |
## Target Date
2026-10-12 — third window of [PP-001].
## Tasks
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
| --- | --- | --- | --- | --- |
| 1 | Implement display and input helpers | A function that prints the logo, "Compare A: ...", the `vs` art and "Against B: ..." using `format_data`, and one that asks for "A" or "B" and re-asks until valid (case-insensitive). Input and output go through injectable callables so tests need no real console. | No | |
| 2 | Implement the game loop | `play_game()` keeps the score, starts with a random pair, compares guesses with `check_answer`, moves B to A after a correct guess and picks a new B that differs from A. Prints the score after each round and "Sorry, that's wrong. Final score" at the end. | Yes | UC-001 Play a game (to be created with the SSD before this task starts) |
| 3 | Handle exhausted data | If every account has been used, end the game with a win message instead of failing to find a new B. | No | |
| 4 | Add entry point | `python -m higher_lower` runs `main()`, which calls `play_game()`; no side effects on import. | No | |
| 5 | Write game loop tests | pytest tests with scripted input and a seeded random generator: correct streak, wrong first guess, invalid input then valid, data exhausted, and the score printed. | No | |
---
[BC-001]: ../business-case.md
[PP-001]: ../project-plan.md
[MIL-002]: ./mil-002-game-logic.md
[ddfe96f]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/014-higher_lower/commit/ddfe96ffa459d5e4b2e30d71bd53878aba2cfc5d
+72
View File
@@ -0,0 +1,72 @@
# MIL-004 Documentation and release
## Metadata
| Key | Value |
| --- | --- |
| ID | MIL-004 |
| CrossReference | [BC-001], [PP-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-04 | Proposed | Jens Tirsvad Nielsen | S01 | Initial version | [ddfe96f] |
---
## Purpose
Decide whether the repository is ready to be shared with S02 and S03: documented, reviewed and verifiable from a clean clone.
## Deliverable
`README.md` with venv, pip upgrade, run and test instructions, a Doxygen build that renders the source comments, review records for the project artifacts, and a verified clean-clone run.
## Go / No-Go Criteria
| # | Criterion (objectively checkable) | Go | No-Go |
| --- | --- | --- | --- |
| 1 | README follows the supplied template and states how to create `.venv`, run `python -m pip install --upgrade pip`, install, run and test | All present | Any missing |
| 2 | Following the README on a clean clone, the game starts and `pytest` passes | Yes | No |
| 3 | `doxygen Doxyfile` builds without warnings on public functions | No warnings | Warnings |
| 4 | Every reviewed artifact has an `RC-*` record in `docs/sqa/reviews/` | Present | Missing |
| 5 | `pyproject.toml` still lists no runtime dependencies | Empty | Any |
| 6 | No `.env` content or token appears in tracked files | Clean | Found |
## Dependencies
| Depends on | Reason |
| --- | --- |
| [MIL-003] | Needs the finished game to document and verify |
## Traceability
| Business Case objective / KPI / user story | Reference |
| --- | --- |
| O2, O4, O5 | [BC-001] |
## Ownership
| Role | Stakeholder ID (SA) |
| --- | --- |
| Owner | S01 |
| Approving reviewer | S01 |
## Target Date
2026-10-14 — final window of [PP-001].
## Tasks
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
| --- | --- | --- | --- | --- |
| 1 | Write README.md | Follow the template S01 supplies (still outstanding): what the game is, how to create and activate a local `.venv`, `python -m pip install --upgrade pip`, install with `pip install -e ".[dev]"`, run with `python -m higher_lower`, test with `pytest`, and how to build Doxygen docs. Serves S02 and S03. | No | |
| 2 | Audit Doxygen comments | Check that every module, function and constant group in `src/` has a Doxygen comment (`@brief`, `@param`, `@return`) and that `doxygen Doxyfile` builds cleanly. | No | |
| 3 | Review artifacts and record reviews | Review BC, SA, PP and the milestones against their QC checklists and create `RC-*` records in `docs/sqa/reviews/`; update version history rows to Accepted on a Go. | No | |
| 4 | Verify from a clean clone | In a fresh clone follow the README exactly: create `.venv`, upgrade pip, install, run the game, run pytest. Fix any gap in the README. | No | |
---
[BC-001]: ../business-case.md
[PP-001]: ../project-plan.md
[MIL-003]: ./mil-003-console-game.md
[ddfe96f]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/014-higher_lower/commit/ddfe96ffa459d5e4b2e30d71bd53878aba2cfc5d
+96
View File
@@ -0,0 +1,96 @@
# Project Plan
## Metadata
| Key | Value |
| --- | --- |
| ID | PP-001 |
| CrossReference | [BC-001], [SA-001], [MIL-001], [MIL-002], [MIL-003], [MIL-004] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-04 | Proposed | Jens Tirsvad Nielsen | S01 | Initial version | [ddfe96f] |
---
## Purpose
Schedule the four phases that deliver the Higher Lower game ([BC-001] objectives O1–O5) as a small, tested, documented Python project, with S01 reviewing each phase through its own branch and pull request.
## Planning Assumptions
- Week 1 starts 2026-10-04; the plan ends by 2026-10-14 (the Business Case sets no hard date; this is the author's evening-sized target, see Open Issues).
- One phase per branch and pull request, each closing its issues.
- Nothing under `src/` or `tests/` before the milestone is accepted and the task is a row in it.
- Only S01 reviews ([SA-001]).
## Gateway Schedule
| Gateway | Document | Window | Decision date | Owner | Stories | Main deliverable | Milestone |
| --- | --- | --- | --- | --- | --- | --- | --- |
| Project setup | [MIL-001] | 2026-10-04 – 2026-10-06 | 2026-10-06 | S01 | — | pyproject, Doxyfile, skeleton, repo metadata | |
| Game logic | [MIL-002] | 2026-10-07 – 2026-10-09 | 2026-10-09 | S01 | — | Data, art, constants, pure functions, tests | |
| Console game | [MIL-003] | 2026-10-10 – 2026-10-12 | 2026-10-12 | S01 | — | Playable game loop with score, tests | |
| Documentation and release | [MIL-004] | 2026-10-13 – 2026-10-14 | 2026-10-14 | S01 | — | README, Doxygen run, review records | |
```plantuml
@startgantt
Project starts 2026-10-04
[Project setup] starts 2026-10-04 and ends 2026-10-06
[Project setup Go/No-Go] happens 2026-10-06
[Game logic] starts 2026-10-07 and ends 2026-10-09
[Game logic Go/No-Go] happens 2026-10-09
[Console game] starts 2026-10-10 and ends 2026-10-12
[Console game Go/No-Go] happens 2026-10-12
[Documentation and release] starts 2026-10-13 and ends 2026-10-14
[Documentation and release Go/No-Go] happens 2026-10-14
@endgantt
```
## Scope Coverage
| Business Case scope item | Gateway |
| --- | --- |
| `src/`, `tests/`, `docs/` layout, `pyproject.toml`, `.gitignore`, `Doxyfile` | [MIL-001] |
| Repository description and topics | [MIL-001] |
| Assignment data set, `logo` and `vs` art | [MIL-002] |
| Random pair selection, answer checking | [MIL-002] |
| Console game, score tracking | [MIL-003] |
| `README.md`, venv and test instructions | [MIL-004] |
## Dependencies
```
MIL-001 → MIL-002 → MIL-003 → MIL-004
```
A No-Go on any phase moves all later windows by the rework time.
## Plan Risks
| Risk | Impact | Mitigation |
| --- | --- | --- |
| README template not supplied | README task blocked | Ask S01 before MIL-004 starts |
| Host token missing or lacking scope | Cannot sync issues or set topics | Token read from `.env` for personal use only; ask S01 if absent |
| Doxygen not installed locally | Cannot verify docs build | Treat as a No-Go note; install or review comments manually |
## Open Issues
- README template: the brief says "using the template below" but none was included. Needed before MIL-004.
- Python version: "greater than 3.13" is planned as `>=3.13`; confirm if strictly 3.14+ is meant.
- Target dates are proposed, not stated in the brief; confirm.
- The brief links the organisation; the `origin` remote is the repository `014-higher_lower` within it, which is what will be synced.
---
[BC-001]: ./business-case.md
[SA-001]: ./stakeholder-analysis.md
[MIL-001]: ./milestones/mil-001-project-setup.md
[MIL-002]: ./milestones/mil-002-game-logic.md
[MIL-003]: ./milestones/mil-003-console-game.md
[MIL-004]: ./milestones/mil-004-docs-release.md
[Milestone MIL-001]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/014-higher_lower/milestones/36
[Milestone MIL-002]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/014-higher_lower/milestones/37
[Milestone MIL-003]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/014-higher_lower/milestones/38
[Milestone MIL-004]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/014-higher_lower/milestones/39
[ddfe96f]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/014-higher_lower/commit/ddfe96ffa459d5e4b2e30d71bd53878aba2cfc5d
+79
View File
@@ -0,0 +1,79 @@
# Stakeholder Analysis
## Metadata
| Key | Value |
| --- | --- |
| ID | SA-001 |
| CrossReference | [BC-001], [PP-001] |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-04 | Proposed | Jens Tirsvad Nielsen | S01 | Initial version | [ddfe96f] |
---
## Purpose
Identify who is affected by the Higher Lower project and what each needs, using a power/interest grid. Stakeholder IDs are stable and cited by every other artifact.
## Stakeholder Summary Table
| ID | Name | Role/Title | Organization | Power Level | Interest Level | Quadrant | Primary Concern (Business Language) |
| --- | --- | --- | --- | --- | --- | --- | --- |
| S01 | Jens Tirsvad Nielsen | Course participant; Product Owner, developer and reviewer | Tirsvad | HIGH | HIGH | Manage Closely | A correct, tested, well-documented solution that shows good practice |
| S02 | Udemy coursists | Course participants who share and compare solutions | Udemy community | LOW | HIGH | Keep Informed | Readable, runnable code with the assignment's function names, and README instructions to run it |
| S03 | GitHub viewers | Visitors browsing the repository for ideas | Public | LOW | LOW | Monitor | Clear repository description, topics and README; no runtime dependencies |
## Power/Interest Classification Rationale
- **Manage Closely (S01):** decides scope, writes and reviews everything.
- **Keep Informed (S02):** no decision power, but they are the main audience; served by README and code clarity.
- **Monitor (S03):** casual visitors; served by repository metadata and a short README.
## Primary Concerns and FURPS+ Mapping
| ID | Concern | FURPS+ attribute |
| --- | --- | --- |
| S01 | Game behaves correctly and is covered by tests | Functionality, Reliability |
| S01 | Planning trail and review records exist | Supportability |
| S02 | Code is readable and uses the assignment's function names | Supportability |
| S02 | Can run the game and tests from the README | Usability |
| S03 | Findable and understandable repository | Usability |
| S03 | Nothing extra to install | Implementation (no runtime dependencies) |
## Communication Requirements
| ID | Channel | Frequency | Deliverable | Phase / Milestone |
| --- | --- | --- | --- | --- |
| S01 | Pull request review | Per milestone | Reviewed milestone deliverable | MIL-001 to MIL-004 |
| S02 | README | At release | Run and test instructions | MIL-004 |
| S03 | Repository description, topics, README | At release | Repository metadata | MIL-001, MIL-004 |
## Conflicting Interests and Mitigations
| Conflict | Stakeholders | Mitigation |
| --- | --- | --- |
| Heavy tooling (Doxygen, review records) versus a simple repository for visitors | S01, S03 | Keep tooling in `docs/` and config files; README stays short and runtime stays dependency-free |
## Traceability Analysis
### Business Goal Alignment
| Stakeholder | Concern | Business Case objective |
| --- | --- | --- |
| S01 | Correct, tested game | [BC-001] O1, O3 |
| S02 | Readable code, run instructions | [BC-001] O2, O4 |
| S03 | Description, topics, no dependencies | [BC-001] O4, O5 |
## Sign-Off
| Stakeholder | Decision | Date |
| --- | --- | --- |
| S01 | Pending review | |
---
[BC-001]: ./business-case.md
[PP-001]: ./project-plan.md
[ddfe96f]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/014-higher_lower/commit/ddfe96ffa459d5e4b2e30d71bd53878aba2cfc5d
Submodule
+1
Submodule framework added at 14d221ec1c