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,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/mil-*.md | 003 |
|
||||
|
||||
## 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.
|
||||
@@ -0,0 +1,129 @@
|
||||
# Business Case
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | BC-001 |
|
||||
| CrossReference | [SA-001] |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-04 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | pending |
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
This project delivers a console Blackjack game written in Python as the first capstone of the Udemy course *100 Days of Code: The Complete Python Pro Bootcamp* (day 11). The player plays against a computer dealer under simple house rules, using emoji playing cards. The project doubles as a worked example of the SQA/QC framework: a small, fully planned, tested and documented Python 3.13+ code base that is easy to review.
|
||||
|
||||
## Methodological and Standards Foundation
|
||||
|
||||
The work follows the project's SQA and QC framework (artifact-first, plan-first gate, review records per artifact). Quality criteria are tagged with ISO/IEC 25010:2023 characteristics. Source code follows the framework's Python coding conventions and is documented with Doxygen comments.
|
||||
|
||||
## Problem Statement
|
||||
|
||||
The course assignment asks for a complete program that combines functions, lists, loops, conditionals and user input. Without a plan, the work is easily done as one unstructured script that is hard to test, review or reuse, and that loses the course's learning value.
|
||||
|
||||
## Business Opportunity
|
||||
|
||||
A small, well-structured game shows the full delivery chain (plan, tracked issues, branches and pull requests, tests, generated documentation) on a problem that is simple enough to finish quickly. The result can be reused as a template for the remaining capstone projects.
|
||||
|
||||
## Objectives
|
||||
|
||||
1. Implement Blackjack for one player against a computer dealer following the house rules below.
|
||||
2. Render cards as emoji and show the course's ASCII logo at the start of every game.
|
||||
3. Separate game rules (pure functions) from console input/output so the rules can be unit-tested.
|
||||
4. Provide a reproducible local setup (venv, `pyproject.toml`) and run/test instructions.
|
||||
5. Document the source with Doxygen comments and ship a `Doxyfile`.
|
||||
6. Track every step as a milestone, issue and pull request on the project's git host.
|
||||
|
||||
House rules: unlimited deck, no jokers, Jack/Queen/King count 10, Ace counts 11 or 1, drawn cards are not removed, the computer is the dealer and draws while its score is below 17, a two-card Ace + 10 hand is a blackjack.
|
||||
|
||||
## Scope
|
||||
|
||||
### In Scope
|
||||
|
||||
- Game logic: `deal_card`, `calculate_score`, `compare`, dealer play, game loop and restart prompt.
|
||||
- Emoji card rendering and the logo from the assignment.
|
||||
- Project scaffolding: `src/`, `tests/`, `docs/`, `pyproject.toml`, `constants.py`, Python `.gitignore`, `Doxyfile`, `README.md`.
|
||||
- Unit tests for the rules and the console flow (with scripted input).
|
||||
- Git host housekeeping: repository description and topics.
|
||||
|
||||
### Out of Scope
|
||||
|
||||
- Splitting, doubling down, insurance, betting and multi-player.
|
||||
- Graphical or web user interface; network play.
|
||||
- Packaging for PyPI or any deployment.
|
||||
- Runtime third-party dependencies.
|
||||
|
||||
## Expected Benefits
|
||||
|
||||
### Tangible Benefits
|
||||
|
||||
- A working, tested console game that matches the assignment's behaviour.
|
||||
- A reusable project skeleton and documentation set.
|
||||
|
||||
### Intangible Benefits
|
||||
|
||||
- Practice of planning-first delivery with traceable issues and pull requests.
|
||||
- Confidence in the Python tooling chain (venv, pyproject, tests, Doxygen).
|
||||
|
||||
## Strategic Alignment
|
||||
|
||||
The project supports the owner's goal of completing the 100 Days of Code course while building a public portfolio of repositories that follow one consistent, reviewable quality process, shared with fellow coursists and useful as an idea source for GitHub visitors.
|
||||
|
||||
## Success Criteria
|
||||
|
||||
| # | Criterion | Target | Measure |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | Functional suitability: the house rules behave as specified | 100 % of rule unit tests pass | `python -m unittest` exit code 0 |
|
||||
| 2 | Maintainability: rules are testable without console I/O | `calculate_score`, `compare` and `deal_card` contain no `input()`/`print()` calls | Code review |
|
||||
| 3 | Portability: runs on Python 3.13+ with no runtime dependencies | `pyproject.toml` lists zero runtime dependencies | Inspection of `pyproject.toml` |
|
||||
| 4 | Usability: documentation lets a new user run and test the game | Setup to first game in under 5 minutes following the README only | Walkthrough on a clean clone |
|
||||
| 5 | Maintainability: source documentation is generated | `doxygen Doxyfile` completes without warnings | Doxygen log |
|
||||
|
||||
## Risks
|
||||
|
||||
| Risk | Impact | Mitigation |
|
||||
| --- | --- | --- |
|
||||
| Emoji cards render badly in some Windows terminals | Cards unreadable, poor usability | Document a UTF-8 capable terminal; keep the card symbols in `constants.py` so they are easy to change |
|
||||
| Randomness makes tests flaky | Unreliable tests | Patch `random.choice` or inject the card source in tests |
|
||||
| Scope creep (betting, splitting) | Late delivery | Out of Scope list; changes need a new milestone |
|
||||
| Secrets in `.env` leak into the repository | Credential exposure | `.env` is git-ignored and is never imported or tested by the project |
|
||||
|
||||
## Assumptions
|
||||
|
||||
- The Product Owner and sole developer is stakeholder `S01`.
|
||||
- The repository is public, so coursists (`S02`) and viewers (`S03`) can read it.
|
||||
- The git host is `git.tirsystem.com`, organisation `Tirsvad-Udemy-100_days_of_code`.
|
||||
- Python 3.13 or newer is installed locally.
|
||||
|
||||
## Constraints
|
||||
|
||||
- Python 3.13+ and a venv-based workflow; `pyproject.toml` for configuration.
|
||||
- Constants live in `constants.py`; layout is `src/`, `tests/`, `docs/`.
|
||||
- No runtime dependencies unless needed.
|
||||
- Nothing is committed, pushed or merged without the owner's request; work is done on branches and pull requests.
|
||||
|
||||
## Cost–Benefit Assessment
|
||||
|
||||
| Costs | Benefits |
|
||||
| --- | --- |
|
||||
| About two evenings of developer time (qualitative: learning project, no budget) | Completed capstone, reusable skeleton, practised process |
|
||||
|
||||
## Stakeholders
|
||||
|
||||
| Stakeholder ID (SA) | Interest in this project |
|
||||
| --- | --- |
|
||||
| S01 | Owns scope and acceptance; takes the course, builds and reviews the game |
|
||||
| S02 | Fellow coursists who share code and compare solutions |
|
||||
| S03 | GitHub viewers who browse the repository for ideas |
|
||||
|
||||
## Recommendation
|
||||
|
||||
Proceed - the scope is small, the rules are fully specified by the assignment and the risks are cheap to mitigate.
|
||||
|
||||
---
|
||||
|
||||
[SA-001]: ./stakeholder-analysis.md
|
||||
@@ -0,0 +1,71 @@
|
||||
# Gateway 1 - Project Setup
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | MIL-001 |
|
||||
| CrossReference | [BC-001] |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-04 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | pending |
|
||||
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
Decide whether the project foundation (repository metadata, layout, tooling, documentation skeleton) is ready so that game code can be added on top of it.
|
||||
|
||||
## Deliverable
|
||||
|
||||
A repository with `src/`, `tests/`, `docs/`, a `pyproject.toml` (Python 3.13+, no runtime dependencies), `constants.py`, a Python `.gitignore`, a `Doxyfile`, a `README.md` that documents the local `.venv` and the pip upgrade, and a repository description with topics on the git host.
|
||||
|
||||
## Go / No-Go Criteria
|
||||
|
||||
| # | Criterion (objectively checkable) | Go | No-Go |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | `pip install -e .` works in a fresh `.venv` on Python 3.13+ | Succeeds | Fails |
|
||||
| 2 | `python -m unittest` runs (with at least one smoke test) | Exit code 0 | Non-zero |
|
||||
| 3 | `doxygen Doxyfile` runs | No errors | Errors |
|
||||
| 4 | README documents venv creation, `python -m pip install --upgrade pip`, run and test | All present | Any missing |
|
||||
| 5 | Repository has a description and topics | Visible on the git host | Missing |
|
||||
| 6 | `.env` is git-ignored and not referenced by any file under `src/` or `tests/` | True | False |
|
||||
|
||||
## Dependencies
|
||||
|
||||
| Depends on | Reason |
|
||||
| --- | --- |
|
||||
| None | First gateway |
|
||||
|
||||
## Traceability
|
||||
|
||||
| Business Case objective / KPI / user story | Reference |
|
||||
| --- | --- |
|
||||
| Objectives 4, 5 and 6 | [BC-001] |
|
||||
|
||||
## Ownership
|
||||
|
||||
| Role | Stakeholder ID (SA) |
|
||||
| --- | --- |
|
||||
| Owner | S01 |
|
||||
| Approving reviewer | S01 |
|
||||
|
||||
## Target Date
|
||||
|
||||
2026-10-06 - within the two-evening effort assumed in the Business Case.
|
||||
|
||||
## Tasks
|
||||
|
||||
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1 | Add repository description and topics | Set a one-line description and topics (python, blackjack, udemy, 100-days-of-code, cli-game) on the git host repository through its API, using the token from the local `.env`. The `.env` file is for personal use only and is never imported, tested or committed. | No | |
|
||||
| 2 | Create project layout and pyproject.toml | Create `src/`, `tests/` and a `pyproject.toml` that requires Python 3.13 or newer, defines the package under `src/`, has no runtime dependencies and configures the unittest entry. Verify the existing Python `.gitignore` covers `.venv/` and `.env`. | No | |
|
||||
| 3 | Add constants module | Create `constants.py` with the deck list `[11, 2, 3, 4, 5, 6, 7, 8, 9, 10, 10, 10, 10]`, the blackjack target 21, the dealer stand threshold 17, the ace values and the emoji card faces, so no magic numbers appear in game code. | No | |
|
||||
| 4 | Add Doxyfile | Add a `Doxyfile` that reads `src/`, writes to `docs/doxygen/`, and extracts Python documentation from Doxygen-style comments. | No | |
|
||||
| 5 | Write README with venv and run/test instructions | Write `README.md` (standard layout) with description, requirements, creating and activating a local `.venv`, `python -m pip install --upgrade pip`, installing the project, running the game, running the tests and generating Doxygen documentation. | No | |
|
||||
| 6 | Add smoke test for package import | Add one unittest that imports the package, so the test command is proven to work before any game logic exists. | No | |
|
||||
|
||||
---
|
||||
|
||||
[BC-001]: ../business-case.md
|
||||
@@ -0,0 +1,74 @@
|
||||
# Gateway 2 - Game Implementation
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | MIL-002 |
|
||||
| CrossReference | [BC-001] |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-04 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | pending |
|
||||
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
Decide whether the Blackjack game is complete, correct under the house rules and ready to be played from the console.
|
||||
|
||||
## Deliverable
|
||||
|
||||
A runnable console game (`python -m blackjack` from the activated venv) with emoji cards and the course logo, a unit-test suite covering the rules, and Doxygen comments on all public functions.
|
||||
|
||||
## Go / No-Go Criteria
|
||||
|
||||
| # | Criterion (objectively checkable) | Go | No-Go |
|
||||
| --- | --- | --- | --- |
|
||||
| 1 | Unit tests for `deal_card`, `calculate_score` and `compare` cover every house rule | All pass | Any fail |
|
||||
| 2 | An Ace + 10 two-card hand scores 0 (blackjack); an Ace is demoted from 11 to 1 when the hand exceeds 21 | Verified by test | Not verified |
|
||||
| 3 | The dealer draws while its score is below 17 | Verified by test | Not verified |
|
||||
| 4 | A scripted full game (hit, stand, restart answer) runs to the end without error | Passes | Fails |
|
||||
| 5 | Rule functions contain no `input()` or `print()` calls | True | False |
|
||||
| 6 | `doxygen Doxyfile` documents every public function | No warnings | Warnings |
|
||||
|
||||
## Dependencies
|
||||
|
||||
| Depends on | Reason |
|
||||
| --- | --- |
|
||||
| [MIL-001] | Needs the layout, constants, tooling and test runner |
|
||||
|
||||
## Traceability
|
||||
|
||||
| Business Case objective / KPI / user story | Reference |
|
||||
| --- | --- |
|
||||
| Objectives 1, 2, 3 and 5 | [BC-001] |
|
||||
|
||||
## Ownership
|
||||
|
||||
| Role | Stakeholder ID (SA) |
|
||||
| --- | --- |
|
||||
| Owner | S01 |
|
||||
| Approving reviewer | S01 |
|
||||
|
||||
## Target Date
|
||||
|
||||
2026-10-11 - five days after the setup gateway, within the Business Case effort estimate.
|
||||
|
||||
## Tasks
|
||||
|
||||
| # | Task | Summary | Needs its own Use Case/User Story? | Reference |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 1 | Implement deal_card | Return a random card from the deck constant using `random.choice`. The deck is unlimited and cards are never removed, so each draw is independent. Add a Doxygen comment and unit tests with `random.choice` patched. | No | |
|
||||
| 2 | Implement calculate_score | Sum a list of cards, return 0 for a two-card Ace + 10 blackjack, and replace an 11 with 1 while the total exceeds 21. Pure function without console I/O; unit-tested for blackjack, bust, multiple aces and normal totals. | No | |
|
||||
| 3 | Implement compare | Take user and computer scores and return the outcome: draw on equal scores, user loses on dealer blackjack or user bust, user wins on user blackjack or dealer bust, otherwise the higher score wins. Check order follows the assignment's hint 13. | No | |
|
||||
| 4 | Render emoji cards and logo | Convert card values to emoji faces (suit emoji with the card rank) from the constants, and print the course logo from `art.py` at the start of each game. Keep rendering separate from the rules. | No | |
|
||||
| 5 | Implement dealer play and game loop | Deal two cards each, show hands, let the user hit or stand until bust, blackjack or stand, then let the dealer draw while below 17, compare and print the result. Console input and output sit in one module that calls the pure rule functions. | No | |
|
||||
| 6 | Implement restart prompt and console clear | After each game ask whether to play again; on yes clear the console and start a new game, on no exit cleanly. Handle invalid answers by asking again. | No | |
|
||||
| 7 | Add scripted end-to-end test | Run a full game with `input` and `random.choice` patched, covering hit, stand, bust, blackjack and restart, and assert the printed outcome. | No | |
|
||||
| 8 | Add Doxygen comments and generate docs | Ensure every public module, function and constant has a Doxygen comment, run `doxygen Doxyfile` and fix any warnings. | No | |
|
||||
|
||||
---
|
||||
|
||||
[BC-001]: ../business-case.md
|
||||
[MIL-001]: ./mil-001-project-setup.md
|
||||
@@ -0,0 +1,83 @@
|
||||
# Project Plan
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | PP-001 |
|
||||
| CrossReference | [BC-001], [SA-001], [MIL-001], [MIL-002] |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-04 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | pending |
|
||||
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
Schedule the two gateways that deliver the Blackjack game within the Business Case's two-evening effort constraint ([BC-001]).
|
||||
|
||||
## Planning Assumptions
|
||||
|
||||
- Week 1 starts 2026-10-04; the plan ends by 2026-10-11.
|
||||
- Phase length: setup 2 days, implementation 5 days (part-time).
|
||||
- Communication follows [SA-001]: one pull request review by S01 per gateway; S02 and S03 are served by the published repository.
|
||||
- PO language is English; no translated copies are kept.
|
||||
|
||||
## Gateway Schedule
|
||||
|
||||
| Gateway | Document | Window | Decision date | Owner | Stories | Main deliverable | Milestone |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| Gateway 1 - Project Setup | [MIL-001] | 2026-10-04 to 2026-10-06 | 2026-10-06 | S01 | none | Layout, pyproject, constants, Doxyfile, README | [Milestone-34] |
|
||||
| Gateway 2 - Game Implementation | [MIL-002] | 2026-10-07 to 2026-10-11 | 2026-10-11 | S01 | none | Playable, tested, documented game | [Milestone-35] |
|
||||
|
||||
```plantuml
|
||||
@startgantt
|
||||
Project starts 2026-10-04
|
||||
[Gateway 1 - Project Setup] starts 2026-10-04 and ends 2026-10-06
|
||||
[Gateway 1 Go/No-Go] happens 2026-10-06
|
||||
[Gateway 2 - Game Implementation] starts 2026-10-07 and ends 2026-10-11
|
||||
[Gateway 2 Go/No-Go] happens 2026-10-11
|
||||
@endgantt
|
||||
```
|
||||
|
||||
## Scope Coverage
|
||||
|
||||
| Business Case scope item | Gateway |
|
||||
| --- | --- |
|
||||
| Project scaffolding and README | [MIL-001] |
|
||||
| Git host description and topics | [MIL-001] |
|
||||
| Game logic, emoji cards, logo, restart | [MIL-002] |
|
||||
| Unit tests | [MIL-002] (smoke test in [MIL-001]) |
|
||||
| Doxygen documentation | [MIL-001] (Doxyfile), [MIL-002] (comments) |
|
||||
|
||||
## Dependencies
|
||||
|
||||
```
|
||||
Gateway 1 - Project Setup -> Gateway 2 - Game Implementation
|
||||
```
|
||||
|
||||
A No-Go on Gateway 1 moves every Gateway 2 date by the same number of days.
|
||||
|
||||
## Plan Risks
|
||||
|
||||
| Risk | Impact | Mitigation |
|
||||
| --- | --- | --- |
|
||||
| Part-time availability | Dates slip | Dates are targets; a slip is recorded here, scope is not cut |
|
||||
| Git host API token lacks permission to edit repository metadata | Task 1 of Gateway 1 blocked | Set description and topics by hand in the web UI |
|
||||
|
||||
## Open Issues
|
||||
|
||||
- No use cases or user stories are modelled: all tasks are plain technical tasks because the assignment is a small single-actor console program. Say if a use case (for example "Play a game of Blackjack") should be added first.
|
||||
- The reviewer for every artifact is S01 (sole stakeholder); an independent reviewer would need a new stakeholder ID.
|
||||
- No README template was supplied, so a standard layout is used.
|
||||
- The Python `.gitignore` already exists in the repository and is verified in [MIL-001] task 2.
|
||||
|
||||
---
|
||||
|
||||
[BC-001]: ./business-case.md
|
||||
[SA-001]: ./stakeholder-analysis.md
|
||||
[MIL-001]: ./milestones/mil-001-project-setup.md
|
||||
[MIL-002]: ./milestones/mil-002-game-implementation.md
|
||||
[Milestone-34]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/011-black-jack/milestone/34
|
||||
[Milestone-35]: https://git.tirsystem.com/Tirsvad-Udemy-100_days_of_code/011-black-jack/milestone/35
|
||||
@@ -0,0 +1,79 @@
|
||||
# Stakeholder Analysis
|
||||
|
||||
## Metadata
|
||||
| Key | Value |
|
||||
| --- | --- |
|
||||
| ID | SA-001 |
|
||||
| CrossReference | [BC-001] |
|
||||
|
||||
## Version History
|
||||
| Date | Status | Author | Reviewer | Change | Commit |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 2026-10-04 | Accepted | Jens Tirsvad Nielsen | S01 | Initial version | pending |
|
||||
|
||||
---
|
||||
|
||||
## Purpose
|
||||
|
||||
Identify who has an interest in the Blackjack project and what they need, using the power/interest grid. IDs are stable and are cited by all other artifacts.
|
||||
|
||||
## 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, reviewer | Tirsvad | HIGH | HIGH | Manage Closely | Complete the course assignment with a correct game, built and tracked with the planning process |
|
||||
| S02 | Udemy coursists | Fellow participants of the course who share code | Udemy course community | LOW | MEDIUM | Keep Informed | Readable, runnable code they can compare with their own solution |
|
||||
| S03 | GitHub viewers | Visitors who browse the repository for ideas | Public | LOW | LOW | Monitor | A clear README and a clean structure that gives them ideas to reuse |
|
||||
|
||||
## Power/Interest Classification Rationale
|
||||
|
||||
- **Manage Closely (S01):** decides scope, accepts every milestone, writes and reviews the work.
|
||||
- **Keep Informed (S02):** share and compare solutions; they do not decide anything but benefit from readable code and clear instructions.
|
||||
- **Monitor (S03):** browse occasionally; no direct communication, they are served by the README and the repository description and topics.
|
||||
|
||||
## Primary Concerns and FURPS+ Mapping
|
||||
|
||||
| ID | Concern | FURPS+ attribute |
|
||||
| --- | --- | --- |
|
||||
| S01 | Game behaves per the assignment's house rules | Functionality |
|
||||
| S01 | Easy to run on a clean machine | Usability / Implementation |
|
||||
| S01 | Rules can be tested and reviewed | Supportability |
|
||||
| S02 | Code is readable and follows the assignment's function names | Supportability |
|
||||
| S02 | Can run the game and tests from the README | Usability |
|
||||
| S03 | Finds the idea quickly: description, topics, README | Usability |
|
||||
| S03 | No setup surprises: no runtime dependencies | Implementation |
|
||||
|
||||
## Communication Requirements
|
||||
|
||||
| ID | Channel | Frequency | Deliverable | Phase / Milestone |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| S01 | Pull request review on the git host | Once per milestone | Reviewed milestone deliverable | MIL-001, MIL-002 |
|
||||
| S02 | Repository, README, source comments | On publication | Runnable game with documented code | MIL-002 |
|
||||
| S03 | Repository description, topics and README | On publication | Discoverable, understandable repository | MIL-001 |
|
||||
|
||||
## Conflicting Interests and Mitigations
|
||||
|
||||
| Conflict | Stakeholders | Mitigation |
|
||||
| --- | --- | --- |
|
||||
| Course hints suggest one flat script; the framework asks for testable, documented modules | S01, S02 | Keep the hint function names (`deal_card`, `calculate_score`, `compare`) but place them in importable modules |
|
||||
| Coursists want a simple read-through; viewers want a polished project | S02, S03 | Keep modules small with Doxygen comments, and put the overview in the README |
|
||||
|
||||
## Traceability Analysis
|
||||
|
||||
### Business Goal Alignment
|
||||
|
||||
| Stakeholder | Concern | Business Case objective |
|
||||
| --- | --- | --- |
|
||||
| S01 | Correct game | [BC-001] objective 1 |
|
||||
| S01 | Reviewable, tracked steps | [BC-001] objective 6 |
|
||||
| S02 | Readable, testable code | [BC-001] objectives 3 and 5 |
|
||||
| S02, S03 | Run and test instructions | [BC-001] objective 4 |
|
||||
| S03 | Discoverable repository | [BC-001] objective 4 |
|
||||
|
||||
## Sign-Off
|
||||
|
||||
Pending review by S01.
|
||||
|
||||
---
|
||||
|
||||
[BC-001]: ./business-case.md
|
||||
Reference in New Issue
Block a user