3.3
Come up with some raw material for next session...
Practice and refine. Many of is will be repeating this in our home organisations/companies.
Define the attributes of a ZedNext requirement
If you write direct requirements,
follow Minimal submission syntax below
If you write scenarios,
assume an explicit user role
extract requirements in Minimal submission syntax
- An introduction (context, actors)
Scenario; a sequence of actions
In a highschool classroom. A teacher and 23 students, whereof 1 student is blind, and one student is learning disabled. Both have access to a DAISY book. The other 21 have print books. The book in question is (in Danish and) Advanced Chemistry, 2500 pages
The teacher asks everybody to look at the example in the blue box on page 1870.
The students with the DAISY books uses the reading device to navigate to that page.
The reading device locates page 1870 no later than when the students reading print reach the page.
The reading device indicates to the user that it has reached page 1870.
The learning disabled user navigates to the blue box by clicking on it on the screen.
The blind user navigates to the blue box by selecting the “next box” option of the navigation facilities the reading device.
The users instruct the reading devices to play.
Description: Allow navigation to constructs of arbitrary semantics
Rationale: Certain publications contain unique layout schemes (such as blue boxes) that carry a specific and important meaning
Reference: Scenario 123
Source: XX
Source (type): consumer, student
Id
Description: what
Rationale: why
*Reference (detailed spec)
Committee comments
Source: identity
Source: type of stakeholder [enum]
Source: scenario/use case [idref]
Type: (func, non-func, domain)
Dependencies [idrefs]
Conflicts [idrefs]
History
Value: should or must (in submitters opinion) (volere suggests rating of 1 to 5)
http://www.volere.co.uk/template.htm
Description: what
Rationale: why
Reference (detailed spec or scenario, may be empty)
Source: who (identity for feedback)
Source: stakeholder type (user category)
Value: should or must (in submitters opinion) (volere suggests rating of 1 to 5)
Id
Description: what
Rationale: why
*Reference (detailed spec)
Source: identity
Source: type of stakeholder [enum]
Source: scenario/use case [idref]
Type: (func, non-func, domain)
Dependencies [idrefs]
Conflicts [idrefs]
History
Value: should or must (in submitters opinion) (volere suggests rating of 1 to 5)
submission requirement submission form, examples; links to renderings of previously inserted reqs
scenario submission form, a template, examples; links to renderings of previously inserted reqs
- final requirement submission form (for WG only)
See: http://www.daisy.org/tools/d3pt/
See: The IEEE/ANS1830-1993 standard
1. Introduction
Purpose of the requirements document
Scope of the product
Definitions, acronyms aud abbreviations
References
Overview of the remainder of the document
2. General description
Product perspective
Product functions
User characteristics
General constraints
Assumptions and dependencies
3. Specific requirements
covering functional, non-functional requirements, external interfaces, performance, logical database requirements, design constraints, and quality characteristics.
4. Appendices
5. Index