[stdsreg] Requirements document(s)

[Robin Cover <robin@isogen.com>]

On the matter of a possible requirements specification:

I don't want to take up a lot of time in the next
'stdsreg' meeting, so as followup to the post
earlier today [1], I'll simply finish my thought here
in writing.

The genre 'Requirements Document' (under various names)
is common enough to standards work [2], so what I'm
suggesting involves nothing complex or new: just a
list of features/functions we want to support; a list
of features which have been judged out of scope;
(optionally) with prose justification/rationale for
each requirement statement.

Here's an example, though not intended to privilege
this particular writing style:

"A user querying a registry that implements the
specification should be able to filter the hit
list to include ONLY standards written principally
in English or French." [Use case: "I've only got
10 minutes to check this out, no time to look online
for English summaries of Japanese specs"]

Stated this way, we have something to focus upon
for discussion and evaluation. One person might
say: "Naw, I only want English standards listed in a
registry anyway."  Another might say: "OK, just
do this in software by sniffing the probable language
of the standard's title, looking at the characters, and
infer that the discourse language is the same as the
title; that will be close enough."  Another might say:
"Yes, we need both language and script attributes for
any data element which stores natural language text, and
we should have a separate language declaration field/object
to (allow one to) specify the principal language(s) used
in the body/text of the standard."

So, one possible implication of the decision on this
requirement is to add something to the data model
(and later to the syntax formalism, whatever we use)
to allow one to say what the principal language is.
At the moment, the "straw man" proposal [3] appears not
to anticipate that anyone will want to declare this
property for any reason.

In our setting, such a requirements document could:

1) help us clarify in our own minds, and as a matter
    consensus, what we are trying to build, stated
    in functional terms; I would conceive of such a
    document as evolving, not constituting a law written
    in stone that cannot be changed when a majority
    perceives a need for revision

2) help newcomers better understand what the committee
    is trying to achieve, in functional terms

3) provide representatives of SDOs with information
    essential to their evaluation of the project --
    whether they should get involved, or plan ultimately
    support the specification, and why

4) provide a framework for documenting our decisions to
    support certain features/functionality and not to
    support other features/functionality; this record helps
    other specialists review the work, providing them with
    a basis for constructive suggestions that may
    enhance the specification

5) provide information relevant to a possible "phase 2"
    specification and to a recommended extension mechanism;
    having a documented list of requirements "out of scope
    for the phase one specification" should help improve
    the abstract design of the phase one spec in terms
    of forward migration and forward-compatible local
    extensions

Robin Cover
XML Cover Pages
http://xml.coverpages.org/

Refs:

[1] Requirements document(s) for 'stdsreg' [posting 04/23]
http://lists.oasis-open.org/archives/stdsreg/200204/msg00008.html

[2] Sample requirements documents

DCMI. Draft DCMI Open Metadata Registry Functional Requirements
  http://dublincore.org/groups/registry/fun_req_ph1-20011031.shtml

IETF. AAA Requirements for IP Telephony/Multimedia
  http://search.ietf.org/internet-drafts/draft-calhoun-sip-aaa-reqs-04.txt

OASIS. OASIS Vocabulary for XML Standards and Technologies TC,
Requirements
  http://www.oasis-open.org/committees/xmlvoc/doc/020419_requirements.html

W3C. SVG 1.1/1.2/2.0 Requirements
  http://www.w3.org/TR/2002/WD-SVG2Reqs-20020422/

W3C. Requirements for a Web Ontology Language
  http://www.w3.org/TR/2002/WD-webont-req-20020307/

[3] Strawman metadata proposal
http://lists.oasis-open.org/archives/stdsreg/200202/msg00003.html