Harald Tveit Alvestrand
harald at alvestrand.no
Tue Feb 4 05:30:41 CET 2003
There seems to me to be an opportunity to do work here....
it's clear that we've had quite varying experiences with writing
requirements documents, and the documents we've produced have been all over
the map from "the protocol should be useful for this function" to "the
boojum must be distimmed by the doshes".
if someone were to volunteer to write an "IETF's guide to writing a
requirements document", with pointers to particularly good examples of
processes that worked well or badly, we actually might manage to identify
the useful tool and forget the time-wasting rathole.....
(this sounds awfully like a requirements document for requirement
documents.... the group now has the opportunity to step straight into all
the ratholes previously identified - but might want to do so based on a
draft, rather than on a discussion......)
(no, I'm not suggesting this as part of this WG's output. It might be an
official output of the next phase, or not - but there seems no harm in
trying to start....)
--On 4. februar 2003 06:30 +0200 john.loughney at nokia.com wrote:
> Hi all,
>> The push for "requirements" documents came from a realization that many
>> groups have suffered from a failure to identify or constrain the problem
>> they were trying to solve. This remains a serious problem. But we
>> need to stop asking for "requirements" and start asking for "problem
>> definitions". "Requirements" should only be only one part of a problem
>> definition, and should be limited to things that are essential for
>> technical (NOT market) success of the protocol (where "success" is not
>> only interoperation of the protocol itself but also ensuring that the
>> protocol does not break other things). Other parts of the problem
>> definition might be called "goals" and "non-goals" and
> One undocumented feature of Requirements docs is that it often serves
> as a good way to get a diverse group of people to speak the same
> language. I have noticed that when a new WG is formed, many different
> groups of people tend to try to push their own pet protocol, even
> if there is no relation to the charter. Also, people with different
> appear, with different agendas and backgrounds. It takes some time
> before things get sorted out.
> Requirements docs should not, when used, be a straight-jacket, but should
> be a way forward, refining the WG scope and settling out the future work.
> This, alas, often does not happen & often WGs start to breakdown even
> in the early phase.
More information about the Problem-statement