Identification of application domain problems that need to (ought to?) be solved
Form the rationale for, and direction of, ZedNext
Complexity, cost of implementation
"Bordering" disability user groups, on the verge of finding DTBs usable (dyslexics, learning disabled, blind-deaf, mh)
Insufficient support for targeting certain user groups / use cases via subsetting
Missing features
e.g. video
e.g. switching (languge training, learning disabled)
Lack of uptake in commercial publishing sector
Adoption rate/backwards compatibility
Scaling
i18n and visual rendering
Audio codec support becoming dated?
Terminology
Problem: an abstract notion that something is faulty or missing in a (social or technical) system
"The Daisy DTB feature set does not sufficiently cover the needs of the learning disabled user group"
"It is not possible to use DTBs with DTBook in Japan due to the lack of support for Ruby"
Requirement:
an [inverted] operationalized reformulation of parts of or a whole problem,
a singular documented need of what a particular product or service should be or do.
"It is possible to switch between parallell renditions (for example, speed of narration or language) of the same presentation during reading time."
"It is possible to create a DTB with Ruby content that displays correctly in off-the-shelf browsers"
User Requirements (often initial step)
High level. Statements in natural language,
diagrams of the services the system provides and its operational constraints.
System Requirements (often second step)
A structured document setting out detailed descriptions of the system’s functions, services and operational constraints. Defines what should be implemented.
Functional Requirements
statements of services the system should provide,
how the system should react to particular inputs
produce particular outputs
behave in particular situations.
what the system should not do.
--> consistent, complete, and unambiguous
Non-functional Requirements
not directly concerned with the specific functions delivered by the system
relate to the system as a whole rather than to individual system features
s the services or functions offered by the system,
the organization(s) involved
the standards to be used
Arise because of budget constraints, because of organisational policies,
because of the need of interoperability with other software or hardware systems
or because of external factors such as safety regulations, privacy legislation, etc
--> May be more critical than functional requirements. If these are not met, the system is useless.
--> sometimes difficult to verify
Who constitutes a user?
Any stakeholder - (direct or indirect) user of the spec
End users (DTB consumers)
in our current world
of a future expanded world (the "borderline" groups)
Producers
Publishers
Distributors
Tool providers (authoring tools, user agents, etc)
Spec owners/maintainers (ourselves)
How are requirements gathered and validated?
Difficulties
Informant data often requires interpretation/analysis
Contradictions and collisions (viewpoints)
Many real-world gathered requirements are possible features of implementor services, not features of the spec, but are still critical information
Gathering, organizing and filtering User requierement
A database type of system is needed
Use a standard format and ensure that all requirement definitions adhere to that format.
Distinguish between mandatory and desirable requirements. 'shall' and 'should’.
Take note of Inter-requirement dependencies and conflict
Methods for discovery
Different methods for different types of users
Requirements Reporting
Scenarios and use cases
Interviewing
Viewpoint-oriented elicitaiton
Ethnography
An organisational function with mandate to filter is needed (=this committee)
- filtering means discarding or deflecting to another project/organisational entity
Remember -
A requirements body changes (additions, withdrawals, refinements, reinterpretations)
Out-of-scope documentation is as important as in-scope
Maximizes the probability that ZedNext gets increased usability
--> minimize risks of missing community needs
Helps correct prioritization
--> If we cant do all of it, then what should we focus on?
During development, enables validation vis-a-vis the real world
--> Given that natural language presentation is possible
Gives ability to measure efficiency of spec (drafts and final)
--> enables controlled incremental and/or iterative spec building
Still only a hypothesis that modularization and profiling will address [solve] certain problems/requirements
More or less guaranteed to not address *all* requirements/problems; certain problems will require other solutions
Terminology
Module: A sub-part of a system/spec with only internal meaning. Can not be used on its own.
Profile: A set of modules that are combined to form a logical whole - external meaning
Desired Characteristics
Modules are cohesive and have low coupling - appropriate intimacy - allow efficient reuse in different contexts
Profiles target specific use cases as stringently as possible - no fluff, no extra burden for implementors
option to add more modules is a desired characterstic as well
Modularization of what?
Modularization of the zed spec
Modularizarion of DTBs
Modularization of the DTBook grammar -- compound content documents
Modularization of the SMIL grammar -- SMIL profiles (DAISY profile, Tiny profile, Video profile?)
Types of profiles
We dont know what we need yet!
Consumption/Distribution profiles
Authoring profiles
Exchange profiles
Archival profiles
...
Non-exclusive, cascading (all books can present themselves as the least common denominator profile)