Re: Why we don't require requirements

["william(at)elan.net" <william@xxxxxxxx>]

On 1 Oct 2004, John Levine wrote:

> I'm not sure what "requirements" means in our context, but I don't
> like any of the meanings I can think of.
> 
> It certainly seems logical that one would start by defining
> requirements and then refine them into a spec and eventually into
> working code.  This is basically the waterfall model of software
> design that was popular in the 1960s.  It's fallen our of favor,
> because it's proven many times to be a one-way ticket to disaster.
> The short reason is because if we knew what we were going to build, we
> would have built it already.

That is not true. When you're facing a new project it is not unusual to 
first go through all major requirements and taking quite some time talking 
to people who need what is being requested. This allows to codify the 
project into written text which makes it easier to create further plan.
It is not unusual that database scheme design is built at that time
but not the working code. Based on the requirements, team leader creates
plan for the project and tries to separate it into multiple parts and
then assigns them to actual programming teams. This system is used in
almost every major software programming business.

> One version of requirements I can imagine is general motherhood-type
> principles on which we all agree, like it has to work with existing
> SMTP implementations, it has to work when deployed incrementally
> without a flag day, it has to scale to a billion hosts or whatever the
> target size of the Internet is these days, and, oh yes, it has to make
> it at least somewhat more likely that a recipient can tell whether the
> claimed sender of a message (for some definition of sender) is the
> actual sender.  Those are all fine, but I think we all know them
> already, so there's not much point in reiterating them.

I don't think this is true that we know all the requirements or otherwise
we'd not have this conversation in the first place.
 
> Once we get past the area of unanimous agreement, we move into the
> realm of war by proxy.  We have at least five proposals on the table,
> and any detailed arguments about requirements will in fact be
> arguments among various proposals.  If I like Domain Keys, I think
> it's a requirement that the verification keys be in the DNS and a
> domain be able to publish multiple keys.  If I like TEOS, I think it's
> important that a signature include forgery-resistant author assertions
> about the message.  And so on.  These arguments aren't hypocritical.
> If I think a proposal is good, it's because I think it does the right
> things, so of course those things should be in the requirements.  If
> we're going to argue proposals, which we will, we should admit that's
> what we're doing and go ahead and do it.

I think it its find for requirements to include key words as we have
done in IETF standard documents. Some requirements are MUST, some
are SHOULD (greatly desired, but we're willing to drop it if it is
a real big problem) and some are MAY (desired as additional optional
feature but not directly a must for solution).

---
William Leibzon, Elan Networks:
 mailto: william@xxxxxxxx
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/