Tirsvad-Udemy-100-days-of-code/031-flash-card
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add the plan baseline: business case, stakeholders, plan, design and milestones

Browse Source 
Business Case, Stakeholder Analysis, Project Plan, use case chain
(UCD, US, UC, DM, SSD, OC, SD, DCD, DICT), three ADRs, milestones
MIL-001 to MIL-007, the traceability matrix and 22 review records
(autonomous mode, AI as stand-in for S01).
This commit is contained in:
Tirsvad
2026-10-14 21:33:25 +08:00
parent 97eec837a4
commit c3fbcbcfaf
49 changed files with 3484 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/stakeholder-analysis.md
+83
View File
@@ -0,0 +1,83 @@
# Stakeholder Analysis: Flash Card
## Metadata
| Key | Value |
| --- | --- |
| ID | SA-001 |
| CrossReference | [BC-001] |
| Language | en |
| Domain | it |
## Version History
| Date | Status | Author | Reviewer | Change | Commit |
| --- | --- | --- | --- | --- | --- |
| 2026-10-14 | Accepted | Jens Tirsvad Nielsen | AI as stand-in for S01 | Initial version | pending |
---
## Purpose
This analysis names the people who influence the flash card project or are affected by it, so that owners, reviewers and readers can be cited by a stable ID in every other document. It follows the power and interest grid: each stakeholder is placed in one quadrant, and the quadrant sets how closely the project engages that stakeholder.
## 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 | Self (Tirsvad) | HIGH | HIGH | Manage Closely | Finish the assignment with a working, understood and documented solution |
| S02 | Udemy coursists | Fellow participants of the 100 Days of Code course | Udemy course community | LOW | HIGH | Keep Informed | Readable, runnable code that keeps the assignment's function names, and instructions to run it, so that solutions can be shared and compared |
| S03 | GitHub viewers | Visitors who browse the repository for ideas | Public | LOW | LOW | Monitor | A clear repository description, topics and README, and no runtime dependencies to install |
## Power/Interest Classification Rationale
- **Manage Closely (S01):** S01 decides scope, writes the code and accepts the result, so both power and interest are high. S01 is the only stakeholder who can accept or reject a milestone.
- **Keep Informed (S02):** S02 cannot change the project, so power is low. They share code and compare solutions, so interest is high; the project informs them through a README that explains how to run the program and tests, and through function names they recognise from the assignment.
- **Monitor (S03):** S03 arrive occasionally and have no stake beyond finding the repository useful, so power and interest are both low. The project serves them with a repository description, topics and a README, and does not require them to install runtime dependencies.
S02 and S03 are classified by S01 as Product Owner; neither can be interviewed, so the classification is an assumption recorded in BC-001.
## Primary Concerns and FURPS+ Mapping
| ID | Concern | FURPS+ attribute |
| --- | --- | --- |
| S01 | The four assignment steps work and progress is saved | Functionality |
| S01 | Work is tracked step by step, each step reviewed | Supportability (+ Process) |
| S01 | Malay words are spoken, in Danish translation | Functionality |
| S02 | Code is readable and runnable with the assignment's function names | Usability, Supportability |
| S02 | Instructions to run the program and its tests | Usability |
| S03 | Repository description, topics and README are clear | Usability |
| S03 | No runtime dependencies to install | Supportability (+ Implementation) |
## Communication Requirements
| ID | Channel | Frequency | Deliverable | Phase / Milestone |
| --- | --- | --- | --- | --- |
| S01 | Chat session and pull request review | Once per milestone | Pull request with the milestone's changes and review record | MIL-001 to MIL-007 |
| S02 | README and wiki | Once, at the documentation milestone, then on change | Run and test instructions, assignment function names | MIL-007 |
| S03 | Repository description, topics, README and wiki | Once, at the documentation milestone | Description, topics, README, screenshots | MIL-007 |
## Conflicting Interests and Mitigations
| Conflict | Stakeholders | Mitigation |
| --- | --- | --- |
| S01 wants spoken Malay words (needs `gTTS` and `playsound`), S03 wants no runtime dependencies | S01, S03 | Speech is an optional extra (`pip install .[speech]`) behind a port; the core program uses the standard library only |
| S01 wants clean architecture with layers, S02 wants code that is simple to read and compare with the assignment | S01, S02 | The assignment's function names (`next_card`, `flip_card`, `is_known`) are kept at the presentation layer, and the wiki maps each assignment step to the files that implement it |
## Traceability Analysis
### Business Goal Alignment
| Stakeholder | Concern | Business Case objective |
| --- | --- | --- |
| S01 | Four assignment steps work, progress is saved | Objective 1 of [BC-001] |
| S01 | Spoken Malay word, Danish translation | Objective 2 of [BC-001] |
| S01 | Step-by-step tracking | Objective 5 of [BC-001] |
| S02 | Readable, runnable code with assignment function names | Objectives 1 and 4 of [BC-001] |
| S03 | Description, topics, README, no runtime dependencies | Objectives 3 and 4 of [BC-001] |
## Sign-Off
Proposed by the author. Accepted when `RC-*` for SA-001 has the verdict Go; in autonomous mode by the AI as stand-in for S01, and open to challenge by S01 in the end-of-run summary.
---
[BC-001]: ./business-case.md