Home / Projects / QSEN Business Analysis
Turning fragmented pupil support into a connected school workflow.
QSEN is my concept for how school staff could find, share and transfer support information for pupils with special educational needs and disabilities (SEND). This is the business analysis case study: the problem, the workflows, the requirements and how I would check them.
- MY ROLE
- Business Analyst
- PROJECT TYPE
- Self-directed concept project, informed by my experience in secondary education
- METHODS
- Process mapping, MoSCoW prioritisation, user stories, traceability
- STATUS
- Requirements defined. Not yet validated with stakeholders.
AT A GLANCE
What this page is, and what it is not
What I produced
- The problem, defined and scoped
- Current and future workflows for sharing strategies and transferring pupils
- 11 prioritised requirements with acceptance criteria
- Three user stories, a traceability table and a risk list
- Success measures and a validation plan
What I have not done
- No interviews with teachers, SENCOs or data protection leads
- No measured timings, so no time saving is claimed
- No usability testing
- No live pupil data and no working system
Where the problem comes from
The pain points come from my professional experience in secondary education. They are hypotheses until stakeholders confirm how often they happen and who they affect. QSEN is the working name of the concept.
The problem is not the spreadsheet
The right information may not reach the right member of staff at the right time, and support knowledge can be lost when teachers or pupils move.
Business objective
Reduce the effort needed to find and apply relevant support information, and improve continuity between staff and between schools.
Scope decision
Reliable profile access, contextual strategy sharing and tracked pupil transfers come first. Integrations and advanced reporting come later.
In scope for a first release
- Search and view an authorised pupil profile
- Role based access
- Recording and sharing context specific strategies
- Tracking and acknowledging a pupil transfer, using the school's existing secure route
- Audit events (Must before any live data)
Out of scope
- Replacing the statutory pupil record transfer
- Integration with school MIS platforms
- A parent portal
- Any use of live pupil data
Assumptions and constraints
- Schools already have a secure way to send pupil records
- Staff accounts and roles are managed by the school
- SEND information is health related, so a data protection impact assessment is needed before any real data is used
- Everything here uses synthetic examples
Fragmented workflows create repeated admin and lost knowledge
- Support information may be split across shared drives, spreadsheets, emails and paper records.
- Subject teachers need a concise, relevant view of agreed strategies without searching a whole record.
- Teachers have no consistent place to record what they tried, the context and how the pupil responded.
- When a pupil changes school, information can be delayed, incomplete or hard to reconcile with the receiving school's records.
- SENCOs may need to chase updates and bring information together by hand.
PROBLEM STATEMENT
How might a school help authorised staff find, apply and carry forward useful support information without creating another burdensome or unsafe record keeping process?
Discovery would test how often each issue occurs, who is affected, and which systems and policies already govern the work.
Six groups create, use, govern or receive the information
The workflow crosses professional boundaries, so the requirements need checking with each group. These conversations have not taken place yet.
| Stakeholder | Primary need | Discovery question |
|---|---|---|
| Subject teachers | Fast, relevant guidance and a low effort way to record observations | What do you need before a lesson, and what is realistic to update afterwards? |
| SENCO and SEND team | Oversight, quality control and clear ownership of pupil information | Who can approve, amend and share each type of record? |
| Receiving school SENCO | Timely, complete and usable transfer information | How are identity, authority, receipt and completeness confirmed today? |
| Senior leadership | Consistent practice, accountability and proportionate reporting | Which outcomes matter, and how are they measured? |
| Data protection and IT | Appropriate access, retention, secure transfer and auditability | What legal basis, policy, system controls and retention rules apply? |
| Pupils and families | Respectful, accurate information and continuity of support | How are views, corrections and appropriate involvement handled? |
How discovery would run
- Interview a small, varied group of teachers and SENCOs, with consent, and anonymise the notes
- Walk through current profile updates and transfers using synthetic examples
- Review school policies, retention schedules, access rules and existing MIS capabilities
- Time a baseline task before setting any time saving target
Where the friction appears
The current state is a series of handoffs and workarounds. The spreadsheet is only one part of it. These steps come from my experience and would be confirmed in discovery.
Friction points
- Searching for and interpreting the right information
- Duplicate or out of date copies
- Manual chasing and consolidation
- Knowledge lost at handover
What this means for requirements
The requirements must cover ownership, freshness, permissions and exceptions, not only a faster search screen.
Two workflows that carry knowledge forward
The proposed future state connects daily classroom use with two continuity workflows: sharing contextual strategies, and transferring information when a pupil changes school.
Flow A: Share a useful strategy
01 | RECORD
Capture context
Staff record the strategy, lesson context, date and observed response, in factual and respectful language.
02 | REVIEW
Check and attribute
Permissions and any moderation apply. The note shows who added it and when.
03 | REUSE
Find and reflect
Authorised staff find relevant notes, judge whether they fit, and add their own observation.
Flow B: Transfer a pupil to another school
01 | PREPARE
Verify authority
An authorised SENCO confirms the pupil, recipient and permitted information before a package is created.
02 | SEND
Secure and track
The package goes by an approved secure route. The sender and time are recorded and delivery is tracked.
03 | RECONCILE
Acknowledge receipt
The receiving SENCO confirms receipt, checks completeness and flags missing or different items.
A transfer is not complete because a file was sent. It ends when receipt and completeness are acknowledged, or when an exception has a named owner.
Where QSEN sits next to the existing transfer route
In England, pupil records move between schools as a Common Transfer File, sent through the Department for Education's secure s2s service or a local authority system. The file should reach the new school within 15 school days of the pupil leaving (Norfolk County Council guidance).
QSEN would not replace that route. In the first release it would track and log transfers that the school sends by its existing secure route, and add the support information and receipt checks around them. A school that does not use QSEN would receive a standard export. This keeps the value of the tool from depending on both schools adopting it.
This is my proposed position. Which route a school already uses, and what it already records, is a discovery question.
Eleven requirements, six of them Must
Safe, dependable core workflows come first. Six of eleven is 55% Must, inside the DSDM guidance that Must items should take no more than about 60% of effort. The acceptance criteria are proposed and the thresholds would be agreed with stakeholders.
| ID | Requirement | Priority | Acceptance criteria (proposed) |
|---|---|---|---|
| BR-01 | Search and view an authorised pupil profile | Must | A teacher finds a named pupil's profile with one search or no more than three taps, and the last updated date is visible without scrolling. |
| BR-02 | Role based access and least privilege permissions | Must | A test account for each role sees only the records and actions its role allows. A request outside the role is refused and logged. |
| BR-03 | Record and share contextual strategy notes | Must | A note cannot be saved without strategy, context and observation. Author and date are added automatically. It is labelled as an observation, not a plan or assessment. |
| BR-04 | Find, review and flag shared strategies | Must | Authorised staff can find notes and flag any as outdated or unsuitable. Flagged notes appear in a SENCO review list. |
| BR-05 | Prepare and send a pupil transfer package | Must | A transfer cannot be sent until pupil, recipient and contents are confirmed on one summary. Each transfer shows a status and a timestamped history. |
| BR-06 | Receive, acknowledge and check a transfer | Must | The receiving SENCO can mark each item Complete, Missing or Different, raise an exception with a named owner, and record receipt and review as separate steps. |
| BR-07 | Audit significant access, edits and transfer events | Should | Each profile view, edit and transfer event records user, action, time and outcome. The log is readable only by roles the school authorises. Becomes Must before any live data is used. |
| BR-08 | Show upcoming lessons and reminders | Should | Each lesson on the day view links to the profiles of pupils in that group who have support information. |
| BR-09 | Draft differentiated resources with AI assistance | Should | The teacher reviews, edits or rejects the draft and sees what changed. No pupil identifiers go to a model the school has not approved. |
| BR-10 | Provide aggregated operational reporting | Should | Reports show counts and trends only, with no pupil names. |
| BR-11 | Integrate with school MIS platforms | Could | Starts only after the supplier confirms access, data mapping and governance. |
Representative user stories
US-03 | Strategy sharing
As a subject teacher, I want to record a strategy and the context in which it helped, so that colleagues can learn from it without assuming it will work in every setting.
Acceptance criteria: the note records strategy, context, date and author; uses factual and respectful language; respects role permissions; can be flagged as outdated; and stays distinct from a formal assessment or approved plan.
US-05 | Secure school transfer
As an authorised SENCO, I want to send the permitted pupil information to a verified receiving school and track acknowledgement, so that support can continue with fewer avoidable gaps.
Acceptance criteria: confirm pupil and recipient; verify the sender's authority; show what is included before sending; use an approved secure route; log the event; let the receiver acknowledge receipt and check completeness; route failures or missing items to a named owner.
US-06 | Receiving school review
As a receiving SENCO, I want to review an incoming transfer and identify missing or inconsistent items, so that I can resolve gaps before relying on the information.
Acceptance criteria: show transfer status and sender; give a clear checklist; distinguish received from reviewed; record questions and resolution; never silently overwrite an existing record.
Linking requirements to design and to tests
| Requirement | BA artefact | Design in the UX case study | Validation |
|---|---|---|---|
| BR-01, BR-02 | Profile access and permissions | Day view, pupil profile, role aware navigation | Task based test with each role, plus permission checks |
| BR-03, BR-04 | Strategy sharing stories | Strategy note form, contextual notes, flag action | Check findability, note quality and interpretation |
| BR-05, BR-06 | Transfer preparation and receipt stories | Transfer hub, outgoing and incoming review, status and acknowledgement | Test wrong recipient, missing item and failure paths |
| BR-07 | Audit requirement | Event history and transfer status | Check the required events are recorded and access is restricted |
| BR-08 | Day view story | Day view linking to profiles | Check links go to the right authorised profile |
| BR-09 | AI resource story | Resource setup, explanation of changes, teacher review | Evaluate accuracy, editability and data handling |
| BR-10, BR-11 | Reporting and integration | Not designed in this concept | Not yet planned |
Key risks and proposed controls
- Unauthorised disclosure: school approved access controls, secure transport, audit logging, retention rules and a data protection impact assessment before any pilot.
- Incomplete or misdirected transfer: verify recipient and authority, show a summary before sending, require acknowledgement and track exceptions.
- A second, competing transfer route: position QSEN as a tracking layer around the existing secure route, and confirm that position with the school.
- Stale or over general strategy notes: show date and author, allow flagging, and label each note as context specific.
- Over reliance on AI: keep a teacher in the loop, show edits, and send no sensitive data to an unapproved service.
- Low adoption or duplicate admin: test with staff and check fit with existing systems before proposing a rollout.
Proposed success measures
| Measure | How to establish it | Success signal |
|---|---|---|
| Time to find the right profile | Time a representative task before and during a pilot | A meaningful reduction without more wrong record selections |
| Transfer completeness | Track acknowledged transfers with missing item exceptions | Fewer unresolved gaps and a named owner for each exception |
| Strategy usefulness | Ask staff whether notes were relevant and actionable; review flags | Staff can judge context and outdated notes are corrected promptly |
| Admin effort | Time SENCO tasks and count repeated chasing or duplicate entry | Less effort without weaker oversight or record quality |
No target is presented as achieved. Baselines, sample size and thresholds would be agreed with stakeholders first.
A requirements foundation, ready to be tested
The main output is a set of requirements that connects the classroom problem to practical workflows, priorities and testable acceptance criteria.
- I reframed the problem from "replace the spreadsheet" to improving access, ownership, continuity and safe handling of information.
- I made sharing and transfer part of the core scope, because both address the loss of support knowledge, then limited the first release so it does not depend on two schools adopting the tool.
- I defined a transfer as complete only when receipt and completeness are acknowledged.
- I linked requirements to proposed screens and to validation activities.
Next steps, planned for December 2026 to January 2027
- Interview a varied group of teachers and SENCOs and a data protection lead, and update the requirements
- Confirm which secure transfer route schools use today
- Run a task based test of the prototype with synthetic data
- Complete a data protection impact assessment before any live use