[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Requirements process suggestions

Good ideas.

One plea: can we start with the scenarios? They should be key
in helping to drive the itemized requirements list.  We can't
afford another "accommodate a subset of the scenarios and
shoehorn in later the stuff we forgot".

As I said in MSP, the WG needs to determine the following:
(a) do the listed scenarios (admittedly some of them not
all that well fleshed-out) the ones we want to be the list
of core scenarios for SOI?  What needs to be added? What
needs to be removed?

The core scenarios represent the things that *must* be
accommodated by SOI and its companion protocols. If
a scenario is in the list, and we don't meet it's needs,
we've failed.  [And we also don't want to expend a lot
of excess energy on scenarios that the WG doesn't feel
are important.]

(b) I attempted a model to represent the key needs for each
scenario. Is the model reasonable? Sufficient?

(c) Look at the scenarios themselves. What's missing? What's
incorrect?

I desperately need help in fleshing out the mobile ip/wireless
and IPv6 scenarios (v6 isn't simply a larger address; we need
to start becoming more intelligent in addressing that problem
space). I am hearing from certain folks that IPsec is a poor fit
for these problem spaces; if so, now's the chance to influence
future design. [In other words, those who care need to put some
skin in the game...]


When we make reasonable forward progress on the scenarios,
I'll feel more comfortable about discussing the requirement line
items...

thx - C



At 09:44 AM 3/27/2002, Michael Richardson wrote:

>>>>> "Melinda" == Melinda Shore <mshore@xxxxxxxxx> writes:
    Melinda> The requirements process doesn't seem to be going very well,
    Melinda> which isn't that surprising - requirements documents are hard
    Melinda> to do.  I think it might be possible to have the son-of-IKE
    Melinda> requirements through WG last call before Yokohama
    Melinda> by applying some discipline, if that's what the working group
    Melinda> wants.

    Melinda> In particular, it's impossible to develop a good requirements
    Melinda> document by evaluating it in terms of whether or not it presents
    Melinda> a harmonious, pleasing whole.  It's got to be taken apart and
    Melinda> put back together again.  What I've found to be effective (but
    Melinda> a lot of work) is:

    Melinda> 1) take the requirements document, turn it into a numbered
    Melinda>    list of crisp, declarative sentences
    Melinda> 2) make a quick first pass through the list and identify items
    Melinda>    on which there's already consensus either to keep or to
    Melinda>    drop.  If there's any - *any* - disagreement about anything,
    Melinda>    it goes on the "unresolved" list.

  Yes, I agree with this process. Make three lists:
  a) requirement is in scope           (no debate)
  b) requirement is out of scope       (it may never be discussed again)
  c) requirement is eligble for debate.

Melinda> I've found that the only thing that requires face-to-face interaction
Melinda> is item 2 - doing it on the mailing list is too slow. However, given
Melinda> the 30-day-notice requirement for interim meetings waiting for an
Melinda> interim meeting may take too long, too, and perhaps instead everything
Melinda> could go on the unresolved list. It's a lot of work for the chairs

We should start on the mailing list anyway.

I am willing to keep track of the list.

] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@xxxxxxxxxxxxxxxxxxxxxx http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ 


====================================
Cheryl Madson
Core IP Engineering; Security and Services
Cisco Systems, Inc.
cmadson@xxxxxxxxx