Brian E Carpenter brian at
Tue Feb 4 12:12:29 CET 2003

Scott W Brim wrote:
> On Mon, Feb 03, 2003 01:43:21PM -0500, Keith Moore allegedly wrote:
> > 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 "considerations".
> I was thinking something along those lines too.  Requirements WGs often
> seem to produce both requirements and a framework, and the requirements
> documents are vulnerable as noted.  If a WG is in the problem definition
> stage, we should require a framework doc, and require that there be a
> requirements section of that doc, which should just be part of the
> framework.

I certainly agree with the "problem statement" version of a requirements
document. I think the meta-problem here is actually linguistic; in some
approaches to systems engineering "requirements" is a much stronger word
than in others. Thus, different participants in a WG have different
expectations about the document. However, I have a little trouble with 
"framework". In at least one WG I could name, the framework draft became 
sufficiently contentious that it became a barrier to progress, and was 
dropped (not without complaints). Just changing the word used to 
describe the document is not sufficient. We need to define its scope

Also, I personally applaud the IESG for insisting on a "what are we
doing here?" phase before picking a protocol design. The problem is
that for complex topics, that phase can loop.


More information about the Problem-statement mailing list