- From: Dennis E. Hamilton <hamilton@parc.xerox.com>
- Date: Thu, 31 Jul 1997 08:45:49 PDT
- To: "'Jim Whitehead at UCI'" <ejw@ics.uci.edu>
- Cc: "'Judith A. Slein at Xerox Systems Architecture'" <slein@wrc.xerox.com>, "'Web DAV'" <w3c-dist-auth@w3.org>
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