021-snake-game/docs/stakeholder-analysis.md

Stakeholder Analysis: Snake Game (Day 21)

Metadata

Key	Value
ID	SA-001
CrossReference	BC-001
Language	en
Domain	it

Version History

Date	Status	Author	Reviewer	Change	Commit
2026-10-08	Accepted	Jens Tirsvad Nielsen	S01	Initial version, reviewed in RC-002 (Go)	f13d004

---

Purpose

This analysis names the people and groups who have a stake in the Snake Game (Day 21) project, a solution to the day-21 assignment of Udemy's 100 Days of Code: The Complete Python Pro Bootcamp, and classifies each one on a power/interest grid so the project knows how closely to involve them. The stakeholder IDs (S01 to S03) are the IDs every other artifact uses for owners, reviewers and RACI (Responsible, Accountable, Consulted, Informed) assignments. The method is the power/interest grid: the quadrant decides how often and with what deliverable a stakeholder is addressed.

The Product Owner stated S01, S02 and S03, the Power and Interest levels of S01, and the deliverables of S02 and S03. The Power and Interest levels of S02 and S03 were not stated; they are proposed here, as in the day-20 repository, and are open for confirmation by the reviewer.

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 (personal learning project)	HIGH	HIGH	Manage Closely	A correct, tested and documented solution of the assignment that is worth keeping and showing
S02	Udemy coursists	Fellow course participants who share code and compare solutions	Udemy course community (external)	LOW	HIGH	Keep Informed	Readable, runnable code that uses the assignment's function names, with README instructions to run it
S03	GitHub viewers	Visitors who browse the repository for ideas	Public (external)	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, adopts and checks the code, and reviews every artifact, so power and interest are both high. S01 is author and reviewer of the same documents; no independent reviewer exists in this project (see the conflict table).
• Keep Informed (S02): S02 cannot change the scope or accept a deliverable, so power is low. They compare solutions with their own, so interest in the code's readability and in the way to run it is high. They need the code and the README, not a say in the plan.
• Monitor (S03): S03 arrive by chance, do not take part and cannot influence the project, so power and interest are low. Their first impression is only the repository page, which is why description, topics and README are checked once.

Primary Concerns and FURPS+ Mapping

FURPS+ stands for Functionality, Usability, Reliability, Performance, Supportability and the added constraints (design, implementation, interface, physical).

ID	Concern	FURPS+ attribute
S01	The game behaves as the day-21 lectures describe: the snake eats the food and grows, the score rises, and the game ends at the wall or at its own tail	Functionality
S01	The day-20 behaviour is kept: a three-segment snake that moves by itself and turns with the arrow keys, without a reversal	Functionality
S01	Behaviour is proven by tests that run without a display	Reliability
S01	Every step is a branch and a pull request, reviewed before the next	Supportability
S02	The code is readable and keeps the assignment's names (Food, Scoreboard, Snake, refresh, extend, add_segment, increase_score, update_scoreboard, game_over, create_snake, up, down, left, right, segments, head, game_is_on)	Usability
S02	The README tells how to create the .venv, run the game and run the tests on their operating system	Usability
S03	The repository page says what the project is, with description, topics and README	Usability
S03	Nothing must be installed to run the game apart from Python itself	Implementation (constraint)

Communication Requirements

ID	Channel	Frequency	Deliverable	Phase / Milestone
S01	Pull request review in the git host	Once per milestone	Pull request with Closes #N lines and the review record	Every milestone (PP-001)
S02	README in the repository	Once, updated when the game changes	Set-up, run and test instructions per operating system	MIL-001, completed in MIL-003
S03	Repository description, topics and README	Once, updated when the game changes	Description, topics and README overview	MIL-001, checked in MIL-003

Conflicting Interests and Mitigations

Conflict	Stakeholders	Mitigation
S02 wants plain code in the style of the lecture; S01 wants constants, tests, Doxygen comments and packaging, which add structure	S01, S02	Keep the lecture's identifiers and flow in Snake, Food, Scoreboard and in the main flow; put the extra structure in separate places (constants.py, an injectable segment factory) so the main flow stays readable
S03 wants nothing to install; S01 needs pytest and Doxygen	S01, S03	The project has no runtime dependencies; pytest is an optional dev extra and Doxygen is a documentation tool that the README lists as optional
S01 is author and reviewer, so a review is not independent	S01	Use the Quality Criteria (QC) checklists as the objective measure, record every review as an RC-*, and treat the pull request as the second look; recorded as a plan risk in PP-001

Traceability Analysis

Business Goal Alignment

Stakeholder	Concern	Business Case objective
S01	Game behaves as the day-21 lectures describe	BC-001 objectives 2, 3 and 4
S01	Day-20 behaviour is kept	BC-001 objective 1
S01	Tests run without a display	BC-001 objective 7
S01	Every step is a branch and a pull request	BC-001 objective 9
S02	Readable code with the assignment's names	BC-001 objective 5
S02	README with run and test instructions	BC-001 objectives 6 and 8
S03	Description, topics and README on the repository page	BC-001 objective 10
S03	No runtime dependencies	BC-001 objective 6

Sign-Off

Stakeholder	Decision	Date
S01	Go in RC-002 (not independent; S01 can overrule)	2026-10-08

---