Revision notes for OCR AS Level Computer Science Stakeholders. Open the guide for explanations and worked examples. Written against the OCR AS Level Computer Science specification, so the content matches what's examinable rather than general Computer Science background.
Stakeholders
What you'll learn
- What a stakeholder is, and why stakeholders matter in project analysis.
- How to identify named individuals, groups, and personas for a software solution.
- How to describe stakeholder needs rather than just listing people.
- How to explain why your proposed solution is appropriate for those needs.
Why stakeholders matter
In OCR H446, this topic sits inside Analysis of the problem for the programming project. Before you design data structures, algorithms, interfaces, or tests, you need to understand who the solution is for and who will be affected by it.
A good project is not just “a program that works”. It is a solution to a real problem for real or realistic people.
Definition
Stakeholder
A stakeholder is a person, group, or organisation that has an interest in a software solution because they will use it, manage it, pay for it, maintain it, provide data for it, or be affected by it.
Definition
Solution
A solution is the proposed software system you will create to address the problem. It may include the program itself, the data it stores, the user interface, validation, reports, security features, and supporting documentation.
Key Idea
Stakeholder needs drive the project
Your stakeholder analysis should connect people’s needs to requirements, success criteria, testing, and evaluation. If you cannot explain who benefits from a feature, it may not belong in the project.
The diagram below shows how different stakeholders can shape the same software solution.
Types of stakeholder
A stakeholder may be a named individual, a group, or a persona.
Definition
Named individual
A named individual is a specific real person, such as “Mrs Patel, the school librarian”, who can explain their needs and give feedback on your solution.
Definition
Group
A group is a category of people who share a similar role or interest, such as “students using the booking system” or “office staff who update customer records”.
Definition
Persona
A persona is a realistic fictional profile representing a target end user. It describes the user’s role, goals, skills, frustrations, and context of use.
You do not always need every type, but you should choose the most useful way to describe the people involved.
| Stakeholder type | What they are interested in | Example |
|---|---|---|
| Client or sponsor | Whether the solution solves the business or organisational problem | A teacher requesting a homework tracker |
| Primary end user | Whether the system helps them complete their tasks | Students submitting homework online |
| Administrator | Whether data can be added, edited, removed, backed up, and checked | A club secretary maintaining member records |
| Manager or decision-maker | Reports, summaries, costs, efficiency, and reliability | A café owner viewing stock levels |
| Data subject | How their personal data is stored, processed, and protected | Customers whose contact details are saved |
| Maintainer or IT support | How easy the system is to update, fix, and deploy | A technician installing the software |
| Indirectly affected person | Effects of the system even if they do not use it directly | Parents receiving automated school messages |
Common Mistake
Only naming the main user
A weak analysis says “the user is the stakeholder” and stops there. Strong analysis considers everyone who uses, manages, funds, provides data for, or is affected by the solution.
Example
Identifying stakeholders for a club booking system
A school wants a system for booking places on after-school clubs.
-
Identify the people who directly use the system. Students and parents may need to view available clubs, book places, cancel bookings, and receive confirmation.
-
Identify who requested or owns the solution. The activities coordinator is the client because they want fewer manual forms and need accurate booking records.
-
Identify people who maintain the data. Office staff or club leaders may need to add clubs, update capacities, mark attendance, and correct mistakes.
-
Identify people affected by the stored data. Students are data subjects because names, year groups, medical notes, or emergency contact details may be stored.
-
Identify indirect stakeholders. Senior leaders may want summary reports, and IT support may care about account access, backups, and reliability.
Describing interests and needs
It is not enough to write a list of names. For each stakeholder, you need to explain their interest in the solution.
Definition
Interest
A stakeholder’s interest is what they care about in relation to the solution, such as saving time, reducing errors, protecting data, improving access, or receiving accurate reports.
Definition
Need
A need is something the stakeholder requires from the solution for it to be useful, acceptable, or safe in their context.
Needs often become requirements.
Definition
Requirement
A requirement is a clear statement of what the system must do or how well it must work. A functional requirement describes behaviour, such as “allow users to search by surname”. A non-functional requirement describes a quality or constraint, such as “the interface must be usable on a tablet”.
A strong stakeholder description links these ideas together:
| Weak description | Stronger description |
|---|---|
| “Students will use the app.” | “Students need to view their club bookings quickly on a phone, so the solution should show a personalised booking list after login.” |
| “The teacher wants reports.” | “The activities coordinator needs to see how many places are left in each club, so the solution should generate a capacity report.” |
| “Admins need access.” | “Office staff need to correct booking errors, so the solution should include an administrator screen with edit and delete options.” |
Tip
Use the need → feature → reason chain
For each stakeholder, write: who they are, what they need, which feature supports that need, and why that makes the solution appropriate.
Example
Linking a need to a requirement
A food-bank volunteer says that donated items sometimes expire before they are distributed.
-
Identify the actual problem behind the comment. The issue is not just “stock management”; the stakeholder needs to reduce waste caused by expired items.
-
Convert the need into a functional requirement. The system should store an expiry date for each batch of food and allow volunteers to search or sort by expiry date.
-
Add a non-functional requirement based on the user context. Volunteers may be busy and not highly technical, so adding an item should require as few fields as possible and use clear validation messages.
-
Make the requirement testable. A suitable success criterion could be: “The system can display all items expiring within the next 7 days.”
Explaining appropriateness
The spec asks you to explain how the solution is appropriate to stakeholder needs. This means you must justify the match between the proposed system and the people who will use or be affected by it.
Definition
Appropriate solution
An appropriate solution fits the stakeholder’s tasks, skills, environment, constraints, data, and priorities. It is not automatically appropriate just because it is technically possible.
When judging appropriateness, consider:
- Tasks: Does the solution support what the stakeholder actually needs to do?
- Usability: Can the intended users understand and operate it?
- Data: Does it store the right data, at the right level of detail?
- Security and privacy: Does it protect accounts and personal data appropriately?
- Environment: Will it work on the devices, network, and time constraints available?
- Maintenance: Can someone update data and fix errors after the system is delivered?
- Evaluation: Can you later test whether the stakeholder’s need has been met?
If personal data is involved, your analysis should also be aware that the solution must handle data responsibly. In the OCR specification, relevant legislation includes The Data Protection Act 1998.
Common Mistake
Feature dumping
A long list of features is not stakeholder analysis. Every major feature should be linked to a stakeholder need and a reason why it helps.
Example
Judging whether a homework tracker is appropriate
A teacher wants a homework tracker for a Year 12 Computer Science class. The proposed solution is a web-based dashboard where the teacher can set tasks and students can mark work as complete.
-
Compare the solution with the teacher’s need. The teacher needs to see who has completed each task, so a dashboard with completion status is appropriate.
-
Compare the solution with the students’ need. Students need quick access to deadlines, so a personalised task list is appropriate if it is simple and works on their usual devices.
-
Check whether the solution creates new problems. If the teacher must manually enter the same class list every week, the solution may be inefficient unless it supports saving classes or importing student names.
-
Turn the judgement into a requirement. A suitable requirement could be: “The teacher can create a task once and assign it to all students in a saved class group.”
Gathering stakeholder information
To identify and describe stakeholders well, you need evidence. Common ways to gather information include:
- Interviews: asking detailed questions to a client or user.
- Questionnaires: collecting views from a larger group.
- Observation: watching how the current process works.
- Document analysis: examining forms, spreadsheets, reports, or existing records.
- Research into similar systems: seeing how comparable solutions support users.
Common Mistake
Do not invent needs without basis
If you use a persona, make it realistic. A persona should be based on sensible research or a plausible user context, not invented afterwards to justify features you already wanted to build.
Writing stakeholder analysis in your project
A good stakeholder paragraph often follows this structure:
- Identify the stakeholder by name, group, or persona.
- Describe their role in the current problem.
- Explain their needs, priorities, and constraints.
- Link those needs to proposed features.
- State how you could later check whether the solution meets their needs.
For example:
Mrs Kaur, the school librarian, is a named stakeholder because she manages book loans and overdue returns. She needs to search for pupils quickly, issue and return books accurately, and identify overdue loans without manually checking paper records. The solution is appropriate for her needs if it includes barcode or ID-based searching, loan status updates, and an overdue report. These features would reduce manual checking and give her clear evidence for following up missing books.
Notice that this does more than say “Mrs Kaur uses the system”. It explains her role, her problem, the required features, and why those features are suitable.
Exam technique
In the exam
-
For each stakeholder, write more than a name: include their role, interest, need, and how the solution supports them.
-
Use the chain stakeholder → need → requirement → justification to avoid vague statements.
-
Remember indirect stakeholders, especially administrators, managers, maintainers, and people whose data is stored.
Self review
Check yourself
- Can you explain the difference between a client, an end user, and a persona?
- For your own project idea, can you identify at least three different stakeholders?
- Can you link one stakeholder need to a specific functional or non-functional requirement?
Keep learning
Make a free account to read the full revision notes and worked examples.