Brian E Carpenter
brian at hursley.ibm.com
Tue Feb 4 16:02:26 CET 2003
"Ayyasamy, Senthilkumar (UMKC-Student)" wrote:
> > I certainly agree with the "problem statement" version of a
> > requirements document.
> You have to be little pedantic for me. when do IESG insists
> on *requirements* and *problem statement* spec?
Provocative answer: when they suspect that the proponents
of a new protocol design are confused about their goals.
> In general, when
> a BOF is initiated for working on new protocols (like dccp), WG
> was asked to work on a problem statement. If we have a *problem
> at hand* and just want to propose change to protocols, IESG
> insist on a requirement draft.
No, if a *change* to existing protocols is proposed, it seems
to me less likely that a requirements draft will be essential.
It is for completely new and more complex topics that
requirements tend to be ...required.
> So, where comes the *problem
> statement* version of a requirement spec? You mean, its always
> better to work on problem statement (be it new protocol or
> just changes) before writing requirements?
It's always a good idea to know what the problem is before
solving it. Whether we always need to write down formal
requirements is what we are debating here.
More information about the Problem-statement