A complementary tool for managing httpd requirements?

[Steve Bannerman <st...@comlab.ox.ac.uk>]

All,

I've been lurking on this list for a couple of weeks to try to understand
how requirements for current or future versions of requirements for the
httpd product are "managed" by the team.

My observation, although it may not be a complete view is that the following
mechanisms drive httpd work:

(1) email discussions;
(2) defects in bugzilla.

Maybe you guys feel these mechanisms are sufficient and they work for you.
If so, that's great.  However, if there are some "pains" associated with
them, I'd like to see if I can help.

I'm researching requirements management; in particular, I'm proposing a
"lightweight" way to manage requirements, much in the same way we manage
source code (I'm a developer too, although not on httpd).  I think it is
applicable for open source development projects.

Would you guys be interested in hearing more?  If not, please disregard the
rest of the note...otherwise, I'm sure your first question would be: "how
can it help us."

Here's how I think that "lightweight requirements" could help:

(1) the requirement files (in RML [1], an XML variant) would be managed
alongside your source code, in the same streams of development.  Thus, the
"up to date" requirements would be accessible by all;

(2) the attributes that you find helpful in managing your releases could be
tagged on the requirements.  For example: estimates of how long the
developer thinks it will take, the priority that the team lead assigns the
requirement, and an estimate of how long it actually took to implement the
requirement.

(3) any associations that you find helpful in managing your releases could
be embodied in the requirements.  For example: requirements could be linked
with any automated test cases that "verify" the requirements and if defects
are found (and entered in bugzilla), the requirement could be linked to its
related defect(s);

(4) by keeping the requirement files up to date (with as little information
as you actually use), you could use them to generate "reports" for you.  For
example, using XSLT you could generate an HTML page which identifies the
requirements implemented in a certain release, as well as any other
"important information" (like the estimates, priority, and known defects).

I could go on, but I don't want to waste your time if you're not
interested...

[1] http://reqs.comlab.ox.ac.uk:8080/reqs

Cheers
--
   Steve Bannerman
   steve.bannerman@comlab.ox.ac.uk
   44.(0)1865.273866