Problems Requirements Modularization and Profiles
From zedwiki
Initial notes on problems, requirements, modularization and profiles
This document was initially part of a presentation held by mgylling at the Z39.86 Committee meeting held in London in October 2007 during early preparations for the Zed Revision process.
The problem space revisited
Identification of application domain problems that need to (ought to?) be solved
Form the rationale for, and direction of, ZedNext
Sketchy (and incomplete) problem space summary from Copenhagen
- 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?
- The “book” content type is insuffucient
Problems vs Requirements
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"
Types of requirements (systems engineering)
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.
Types of user requirements
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
Requirements engineering
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 requirements
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)
Remember - Out-of-scope documentation is as important as in-scope
Requirements driven spec development, rationale
- 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
What about modularization and profiles?
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 characteristic 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)
