# 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