- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 2 Jun 2010 00:26:37 +1000
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>, Janina Sajka <janina@rednote.net>, Charles McCathieNevile <chaals@opera.com>
On Tue, Jun 1, 2010 at 11:35 PM, Laura Carlson <laura.lee.carlson@gmail.com> wrote: > Hello everyone, > > The definition of wishlist: > > <q cite=<http://www.merriam-webster.com/dictionary/wishlist"> > Main Entry: wish list > Function: noun > Date: 1970 > : a list of desired but often realistically unobtainable items <a wish > list of useful changes> > </q> > > Some requirements may not be not be technically achievable on all > devices for all users at this time but it is still useful to identify > needs in the requirements document as Janina pointed out. > > As Chaals mentioned it might be good to prioritize. "Ranking" is one > of the desirable of the characteristics for a requirement > specification. Others characteristics are "complete", "consistent", > "correct", "modifiable", "traceable", "unambiguous", and "verifiable" > [1] [2]. Ranking requirements is essential for scope management. > > In fact it might be helpful to prioritize requirements in multiple > dimensions. Typical schemes for prioritization of requirements include > importance to user groups, stability, risk, technical difficulty, > cost, etcetera. > > Janina, you mentioned that in many instances the requirements in the > current doc are close to governmental requirements. That would also be > useful to document for the "traceable" characteristic of a good > requirements document. Requirements are not written in isolation. > Traceability provides a mechanism for finding and referring to the > origin of the requirement. > > Best Regards, > Laura We have already in the past collected legal requirements for media accessibility at http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations_Requirements . None of the legal requirements come to the level of sophistication requested in the requirements document that is currently under discussion. For example, even where captions are required, there is no requirement on formatting and styling of captions, not to speak of extended captions. I would not have that limit us, though, since we know that in the past many of the requirements that users had were limited by technical possibilities and many of the laws were similarly built to work within technical possibilities. I would rather we assume a perfect world where everything is possible for the purposes of gathering requirements - which is essentially what we have done. In a next step, it will be good to compile a priority list from the given list. Regards, Silvia.
Received on Tuesday, 1 June 2010 14:27:33 UTC