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

Do you already know who/what/why

[jukal]

I quess you already have a valid requirement basis for selecting the requirements management system. I might be perverted, but I would not even install a separate requirements management system before seeing who i will have working, what will they be doing, and how they will be doing it. You must be building a seriously complex software product, otherwise I do not really see your way of prioritizing things - or have you gone through this process before and already know exactly how you want things done?

Re:Do you already know who/what/why

[InternalWave]

I agree. This to me sounds like someone putting the technology ahead of the humans.

I'd start out with a decent version control system and that's about it. I'd make that work first, and also concentrate on proper coding standards (comments etc etc) before ever worrying about the rest of the infrastructure.

The build system would be a close second. For Java I like Ant...I've been using it for years, and the company I work for right now uses it big time.

Configuration and documentation management would come third, and not too late either.

OK, it sounds like I am discounting requirements management and high level design and traceability - definitely not. But I think you can do this without resorting to systems. Just make sure that the business analysts are hardnosed SOBs that know requirements analysis inside and out. All you need from them are decent System/Software requirements specs that could be in ASCII for all I care.

Do your spec review. Make sure the senior programmers are on board and understand the requirements. Give them their bits and let them loose. Let them use UML if they like but don't demand it, and curb excessive use of it. If they want to use something else that's fine. Require traceability.

Review again. Intensively. All docs at this point are still ASCII/Word/XML/LaTeX/images - no fancy expensive systems are in play. None required, as far as I am concerned. Your best bet is people, not technology.

I, or other commentators here, could follow the entire lifecycle through - what's the point? The thng is, you don't need the technology - you can do very well with email and simple document formats. It comes down to human skills and training and doctrine.

Re:Do you already know who/what/why

[mickwd]

".....concentrate on proper coding standards (comments etc etc) before ever worrying about the rest of the infrastructure"

"Configuration and documentation management would come third, and not too late either"

How can you mention requirements specs and design specs and say that coding standards, of all things, should be tackled before configuration control, document management and project infrastructure ?

support oss

[raffe]

If you want to support oss buy sourceforge or sourcecast from collab.net! Good companies that could use the money!

Scale? Objectives? Tracking?

[Steve G Swine]

It's hard to recommend something without knowing what your typical project size is. You want to run something that'll take 500 staff hours of effort much differently than something that'll take 5000 staff hours... or 50, or 50,000.

And what's your key objective? Do you need to show something by December 1, or can you project any date as long as it clears a well-defined quality test on that date?

What's your need for accurate tracking of progress? Do you need to tell people something believable every week about when they can expect the THING that they've ordered, or can you just say "we're working on it, and we're somewhere in the middle?"

All that said, the approach I've seen work the best is an email folder, a spreadsheet, and a brilliant dedicated experienced person who kept it all in her head and spoke the right language to everyone concerned. Get whatever tools you want - as long as the craftsmen are right, everthing else will be fine...

Or, y'know, not. Good luck, comrade.

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?

Technology v. Management

[kerskine]

I read your specification for your requirements system, and it left me with a distinct impression that you're trying to use technology as a substitute for your company's management. No system is going to make a mediocre team better - this is true for any organization regardless of size. If you're putting together a team, concentrate on the people first. A strong team will be able to credibly explain to management the impact of requirements changes better than some report from a system that most of your management can't even grasp.

Remember - build a great team! Good Luck

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.

Dollar costs

[john.r.strohm]

You say that you have issues with spending $1200-$10K per seat for a requirements package.

Let me point out that your company is already planning on spending, fully-burdened with overhead, nominally $250,000 per seat on your developers. That is salary, benefits, cost of office space, cost of lights, cost of PCs, secretarial support, janitorial support, bathrooms, water fountains, time spent perusing the lastest zero-information-content puffery from the Board of Directors, everything. $1200-$10K per seat is pretty small potatoes by comparison.

Having said that, I suggest you take another look at your wish list and ask yourself how often you REALLY are going to *USE* all those bells and whistles. Do you NEED them, or do you just WANT them? Do you NEED one-button brass-band-Mozart, or do you just need to be able to pull the data out OCCASIONALLY for a right-now CEO presentation?

Your payoff occurs when you automate the things that happen every day. Spending a fortune to automate the things that never happen is wasting time and money.