RE: New requirements draft!

Hi!!

I like all of the momentum that is showing up on the list.

A MILD RANT

I just noticed something that has also struck me before, but I couldn't 
figure out what I was reacting to.  It seems funny to me to remove 
requirements by wanting to have some kind of convergence.  What it looks 
like is that the requirements document is being evolved into essentially a 
functional specification.  When I read it I notice that too.  (I think this 
is partly because the responders are also the authors of the requirements, 
which is an unusual situation compared to what we at least pretend to do in 
customer-supplier situations.)

It was your saying

"So the essence of the problem is that a requirement which is 
unimplementable shouldn't be in the requirements document"

I think one could agree not to meet a requirement.  Or give up on meeting a 
requirement because of practicality or it is seen as overconstraining the 
problem.  Then I suppose the way one responds to the requirement is to say 
that with a particular prioritization no practicable solution was found 
that had the requirement be satisfied.   Also, what one might want to get 
into the requirement is the prioritization that is acceptable.  (E.g., I 
want locking, but it is not ok to give up x and y to get it.)

It is, in a way, important to say what was intentionally not done, 
especially when there might be an obvious requirement that needs to be 
accounted for.

I think the way this happens in practice, when people are using lifecycle 
models involving specifications, that a functional specification is part of 
a response to a set of requirements.  It needn't match the requirements, 
and it might not respond positively to all of them.  On the other hand, 
there's some prominence about a particular requirement (like locking) that 
an account is called for.

Requirements changes, generally, are changes of requirements and they may 
be based on more experience, better understanding, and so on, but I notice 
a trend toward having that be different than what someone offers to 
produce.  That is, it is not necessary to change requirements in order to 
match up with what the functional specification achieves.

I don't want to make anything of this.  I just noticed that I have an odd 
reaction to what looks like an effort to have the results and the 
requirements match up positively.  It feels almost like there's something 
disreputable in having everything come out so nice.

I also notice that there are constraints and "out of scope" situations. 
 This comes up in your comments about query and also your constraint that 
whatever the requirement statement is on internationalization, it be 
satisfiable by employing ISO 10646 encoding.  There's probably a way that 
says what you want more directly, in that case, as a constraint on the 
scope of attention to internationalization.

NO REQUEST

I'm not asking that anything be done.  I just wanted to say what came up 
for me to see if it provides anything in balancing between the requirement 
activity and the specification activity.

I've been paying attention to requirements processes in my own work lately 
-- not particularly successfully -- and this is what my attention was drawn 
to.

Dennis

----------
From: 	Jim Whitehead[SMTP:ejw@ics.uci.edu]
Sent: 	Wednesday, July 30, 1997 18:21
To: 	'WEBDAV Mailing List'
Subject: 	RE: New requirements draft!


Comments below:

[ . . .]

So the essence of the problem is that a requirement which is
unimplementable shouldn't be in the requirements document. This boils down
to whether we should require server implementors to include an atomic
locking capability in their systems.  I think we need some feedback from
list participants with server experience to determine how to proceed.

[ . . .]

[end] Dennis

Received on Thursday, 31 July 1997 13:11:46 UTC