Requirements Before Proposals?

["Eliot Kimber" <ekimber@innodata-isogen.com>]

In the process of working through the 1.2 issues for which I'm a 
champion of record, it started to occur to me that we're getting a bit 
ahead of ourselves, in that most, if not all the issues as written are 
presented as proposals for specific functionality.

But what we really need first are agreed-upon statements of requirement, 
from which we can then identify specific features that would satisfy 
those requirements and then, from that, specific implementations of 
those features.

That is, in an engineering activity, I would not normally accept an 
implementation proposal before I had a clear and accepted statement of 
the requirements that implementation claims to satisfy.

I would like to propose that we, the champions of each proposal, take 
the time to write up a clear, implementation-neutral, statements of 
requirement for their issues. For many proposals the proposal itself 
will not change but it will be much clearer what the requirement is. But 
for some it may make it easier for us, as a group, to evaluate the 
requirements on their merits and then more clearly and productively 
formulate proposals for satisfying those requirements, where the 
existing proposal is either underspecified, non-existent, or controversial.

To take a simple example, my issue 12022, Make @role unenumerated, can 
be restated as a requirement like so:

"Authors and specialization designers should be able to specify 
arbitrary values for the role= attribute of link elements."

Given an acceptance of that requirement, the implementation solution is 
obviously "make @role unenumerated". But there could be other reasons 
for making rule unenumerated that have nothing to do with the needs of 
authors, so just stating the implementation is not sufficient to 
unambiguously indicate the driving requirement.

At a minimum, this will validate that the champions of the different 
issues have sufficient understanding of them to clearly state the 
requirements implicit or explicit in them.

Note too that there may be more than one feature resulting from a single 
requirement, depending on the nature of the requirement and how it 
interacts with existing DITA functionality and design principles.

Cheers,

Eliot

-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
8500 N. Mopac, Suite 402
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com