Open Source Requirements Management Systems?

scphantm asks: "I have the wonderful (and rare) job of building a development department from scratch. One of the things im doing right now is looking for the software im going to use company wide to manage the department and the various projects we are going to have. I have some great ideas for OSS project management software, but the one piece of the puzzle that im missing is a good requirements management system. I have found a few that will do what i want but i have serious issues spending $1200 to $10,000 a seat! I sat down and put together a wish list for what I would want in a Requirements Management System, is there anything like this out there?" While SourceForge and it's free counterpart Alexandria may have a few of the pieces to his wishlist, scphantm has some decent ideas that Project Managers might want to think about.

"I have used your basic Word docs and Excel spreadsheets in the past for this but it just simply wasn't up to snuff as far as I'm concerned. How have Slashdotters solved these problems?

My Wishlist

• Has to be web based. We are going to be spread all over the country and i see no other realistic way of doing it.
• Has to handle multiple projects
• I want it set up so I can take the tree of requirements, click on a button and have it take a snapshot of those requirements and mark them as the requirements for version 1. I can then still use the original requirements tree to create the requirements for version 2.0, in the future. I then want the ability to compare the two snapshots and generate a report that I can give to marketing which says: "these are the changes from version 1.0 to 2.0"
• I want the defect tracking integrated into it. Source code management I don't really care about, but bottom line, I want to be able to click on my snapshot of version 2.0 and run a report that itemizes everything in it, from requirements to bug fixes. I want to be able to look at a closed bug and see what release of the product it was integrated into. on this level, I really don't give a rats @$# about what version of data.h the fix was integrated in.
• If I have a bug reported in version 1 of a release, I want it to flag the developers of version 2 that this may be an issue for them as well. Basically have a little bit of AI as far as who needs to know about a bug, and make sure to incorporate the fix for that bug into future releases.
• I want security set up so there is a free communication during the process of requirements management. anyone who is anyone will be permitted to add input to new feature ideas using this system. the Development Director for the particular project would be the only one permitted to make a suggestion a requirement.
• I want an impact tree. I want to be able to run a report to show the CEO that if he wants to change the encryption from Blowfish to AES, its going to impact these requirements."

Comments

why?

[Mr. Slippery]

I have used your basic Word docs and Excel spreadsheets in the past for this but it just simply wasn't up to snuff as far as I'm concerned.

Why not?

Seriously. I've worked on a few projects of some magnitude and we never used any "requirements management system" more special than standard document files. (Of course, you shouldn't be putting any data at all in proprietary and virus-ridden Word or Excel formats, but there are safe and open alternatives.) Heck, they managed to put a man on the moon with a "requirements management system" that probably consisted of three-ring binders.

Ask yourself: is using an fancy-pants automated system going to simplify or complicate the process?

2nd vote for "Roll your own"

[the red pen]

Every software development life cycle (SDLC) methodology I've ever seen starts with a phase called "requirements analysis." They always will, but what's implicitly understood is that the definition of "requirement" varies radically with the type of project.

One place you won't find the terms "requirements analysis" or "requirements management" used outside of specific examples is in the Project Management Institute Body of Knowledge (PMBOK), which is (get this) an ANSI standard for project management.

The PMBOK dispenses with the concept of a project as a sequence of segmented phases and describes a project as the outcome of several "process groups" that wax and wane in importance during the project. When you talk about "requirements management" you are cutting a broad swath across these process groups and invoking activities such as risk management, scope management, resource management. time management, and so forth.

For example, the first process group is "initiating processes." What drives your organization to authorize a project? If your requirements don't relate directly to that, you're already on the wrong track.

My main exposure to SDLCs was in professional services; limiting the context to "outsourced project" already answers some of the questions I raised above. Some guys I worked with at PwC consulting had the best approach to requirements management (within this context) that I saw. (Yes, I realize that PwC Consulting changed its name to "Monday" and sold iteself to IBM, but despite outward signs of insanity, these guys had the SDLC methodologies down.) Anyway, at the commencement of each project, they would write a custom requirements manager in Microsoft Access. At the end of the project, they'd throw it away, because it was never quite the right one for the next project.

The cliché that comes up in every Java vs. Perl flame session is "use the right tool for the job." Unless your projects need to follow some kind of rigorous methodology (like DOD contracts), you should plan for variation. Put together a suite of tools (there are already some excellent suggestions) and include as part of the planning for a new project "tool selection" and let the project team deploy these tools as best suits each project.

The PMBOK definition of "project" specifies that a project be "unique." If it's not unique, then it's not a project, it's part of some ongoing process. Very insightful: all projects are unique.

Which is the cart and which is the horse?

[Gerry Gleason]

Projects can be killed by poor process. One company I worked for had sufferred under a badly done attempt to add process after the fact. By the time I was there, this was all company history, but it was a horror story, and everyone was a little skittish about implementing more process.

If you are a software company, then you had better pay close attention to having the right process from the start. Once your into the project, you won't have time to go back and do planning and process. If your design and project methods aren't good, how can you even make a schedule or know how many programmers to hire? This is by definition more than a one or two person project or you wouldn't need a software company to do it.

That being said, don't go nuts on process either. Figure out what is most important to your project, and implement something that hits the important points. Use it and build good habits on your team, and you will be able to refine the process as you go. At the end of each product cycle you have to evaluate the performance of everything and make adjustments.

This is just like the extreme programming model where you prototype quickly and test constantly. Unlike writing programs, it's harder to automate the testing because your evaluating a human process, not a program. Performance metrics can help, but sometime they hide more than they reveal.