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(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/