[horde] Idea for new Horde project

[Jeff Donnici]

First, no sooner did I send my original message than I found a link to
some of the API documentation for the framework (the javadoc type docs).

> Could you be a bit more narrative about what a "requirements
> management system" is exactly?! Is it like a project 
> manager with dependencies?

When I say "requirements management", I mean a system that would allow
for managing all the requirements for a software project, thoughout its
lifecycle. There are a number of commercial applications that do this
(RequisitePro is probably the most well known), and I know of a couple
of open source, web-based apps that are underway but not complete and/or
have limited features (one is reqzilla, hosted at SourceForge, and the
other is called DRES at http://ophelia.cs.put.poznan.pl/dres/).

In any case, you have projects where you're building something... And
the project is made of components. For example, Horde has components for
data access, security, permissions, etc. At the beginning of a project,
there are requirements. Things like "The shopping cart portion of the
site shall be accessed through HTTPS/SSL", or "The user shall be able to
preview their document prior to printing it." Even small projects may
have dozens of these requirements and large ones typically have
hundreds.

Now, requirements have a number of attributes themselves -- date, status
(approved, under discussion, denied), priority (must-have, would be
nice, etc), a description, a component/module that they apply to, maybe
a developer who's responsible for it, etc.

As a project gets underway, the requirements get fleshed out until the
team knows what it is they're building and then they build. These
requirements represent the functionality and features that must be met
by the project. Throughout the project, a good requirements system will
provide traceability -- you can see when a requirement was entered, when
it was approved, when it was implemented, in what component/module, in
which build, when it was tested, when the customer saw it, etc. Not only
does this help the development team know what they need to build, it
also helps the QA team know what to test for... The requirements for a
project are often the starting point for its QA test plan.

When I think of a "project management" system, I think partially of
requirements, but I tend to think more of tasks, resources, and
timeframes. While I'd love to see an open source project management app,
and there may be some for all I know, I think a requirements management
system is something that would get a lot of use and it doesn't seem that
there is much out there already. Plus, I think it's something that fits
in well with the other Horde apps. 

When putting together a project management plan, many tasks come from
requirements, but not all... For example, the project manager would
track "install/config server" as a task, though that's not something
that would be in the software requirements. The project manager also
makes sure that a resource (developer, system admin, tech writer, etc)
is assigned to a task and that the timeframe for the task is tracked.
The last piece of that they would track are the dependencies... That is,
task B can't happen until task A is complete.

So... There you have it, the quick rundown of what I view a requirements
management system doing (and how it differs from a full-fledged project
management system).

Hope that helps,

Jeff