[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@cisco.com> 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@sandelman.ottawa.on.ca 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@cisco.com