In brief
The first IncluLearn.AI requirements analysis does not start with a feature list. It starts with observable workflows: How are textbooks, examinations, graphics and other materials adapted today? Where do time costs, duplicated work and particular quality risks occur?
Public sources already provide concrete signals. For us, however, these signals are the starting point for hypotheses, not a substitute for interviews, user tests and subject-matter validation.
What the public research already shows
Several organisations describe substantial manual and subject-specific effort. Landesmedienzentrum Baden-Württemberg reports that its text service can require 20 minutes to one hour per textbook page, depending on subject and material. The Friedberg media centre specifies four to eight weeks of lead time and describes additional bottlenecks during examination periods. Mediablis recommends registration for centrally set examinations at least three months before the first examination date.
These figures are not universal productivity measures for every organisation. They do show that accessible adaptation cannot be reduced to OCR or a single export step.
From observations to needs hypotheses
The research has therefore been mapped into a traceable chain:
Source/evidence → target group → need → use case → requirement → acceptance criterion → implementation → evaluation
Twelve needs hypotheses are currently documented. They range from semantic document preparation and STEM-diagram understanding to expert review, multi-format output, reuse, examination workflows, provenance and individual output profiles.
The status matters: these needs have not yet been validated through our own interviews. A plausible inference from publicly documented processes is not yet a confirmed user requirement.
How validation is planned
An interview guide has been prepared for discussions with media centres. It starts by asking openly about real workflows: What materials arrive? Where do media breaks occur? Which steps are particularly time-consuming? How is quality reviewed? Which errors would be especially problematic in STEM or examinations?
Only afterwards are concrete IncluLearn.AI ideas such as semantic pre-analysis, a diagram interpreter, expert review or version comparison introduced for assessment. This is intended to avoid presenting our own solution concept as if it were already a user need.
Requirements will also be linked to later acceptance criteria, implementation and evaluation. Early formative tests with blind and visually impaired learners are intended to reveal concrete barriers and preferences without prematurely generalising to the entire target population.
Why this matters to the advisory board and practice partners
In requirements work, disagreement is valuable. If a hypothesis derived from public research does not hold in practice, that is not a failure of the analysis; it is an important result.
For media centres and other partners, this means that we do not merely want to ask whether a proposed feature sounds “interesting”. The key questions are whether it fits real workflows, addresses relevant time or quality risks, and preserves human subject-matter judgement at the right points.
Next step
The public research is therefore being unpacked into three deeper posts: observed bottlenecks, the twelve resulting needs hypotheses, and the first prioritisation of possible IncluLearn.AI services. These three levels — finding, needs hypothesis and solution hypothesis — should remain visibly separate throughout the project.