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

tutos

[AX.25]

http://www.tutos.org

Seems pretty complete. I'm looking at using it.

Tigris?

[Anonymous Coward]

We had a similar requirement at our place of work. At that time Tigris was open source and we were able to get it to work for us. The software is truly amazing...

Though no longer available as OpenSource (Free!) product, CollabNet provides this platform for Collaborative Development to interested parties as a Hosted Model for a fee. Check them out at http://www.collab.net/ and while you are at it, you might get a feel of the features provided by checking out http://www.tigris.org/

We tried SourceForge too when it was open source/free. But finally decided to go with Tigris as it was more flexible and suited us better. YMMV!!

-Sumit Dhar

Re:Tigris?

[Phoukka]

Okay, I am not familiar with the SourceCast product from CollabNet, so I can't speak to its features, and I'm talking out of my wazoo. However. Every piece of software on www.tigris.org is open source, most using the Apache license. And, while I'm sure that CollabNet is doing something really interesting to add value to the packaged-up whole that is SourceCast, I'd be willing to bet that what they are doing isn't THAT much more than building an integrated package. If anyone out there has more info, please chime in, but my bet is that SourceCast is an extremely cleanly-integrated packaging of www.tigris.org components such as Subversion, Scarab, Anzu, Eyebrowse, etc. And, frankly, those individual components look very useful in their own right. So, maybe your first project might be to find individual components that meet some of your requirements, and integrate them yourself.

To the original poster: I don't know if it could be adapted for your purposes, but you may well want to check out Forrest, at xml.apache.org. I have been examining it for my own use, and it looks like it might make a very interesting part of a distributed development framework.

Good luck, and let us know how it turns out.

Your Are Asking For A Lot From One Tool.

[fleabag]

Here are a few thoughts - I've done similar things on large projects, so it might be useful.

1) For requirements documents, Word is not a bad choice. You will need narrative, formatting and pictures - becuase the one of the target audiences for this is the sponsor of the project and the business people who are paying for it. They have Word on their desktop, they understand it and they can print from it. (Note: I don't like MS any more than the next person, if you have a company preferred alterntive, then use it). Without nice pictures explaining what is happening, the people who are paying for your project won't understand what is going on - and confused managers are dangerous managers in my experience!

2) The point at which we reduce the requirements document to something unreadable is the creation of the Test Model - linking requirements to test conditions. For this we use a home rolled Oracle DB that we use to populate test scripts via ODBC. The test scripts and model are all Word based. (Sorry :-) ). We may be going to RTF soon becuase they are easier to generate from the Sun boxes we have at the back end.

3) You are asking for a CMM 3/4 type of environment. That implies a very rigorous development approach - in order to do the impact analysis of changing your encryption algorithm, you need the developers and designers to be really thorough. If they are not, then all the tools in the world won't help.

4) If find it strange that you are not starting with version control. From my perspective, knowing that encrypt.c version 21 was changed by developer Fred and went into build 723 which became Release 3 is the most important thing. I have seen many projects fail becuase of a lack of version control, and I have seen projects fail becuse they did not write down the requirements. I have never seen a project fail becuase they did not use the right tool for their requirements.

5) We make sure that bugs fixed in one release get fixed in the next by raising multiple problem requests; one for every phase in flight. That way it doesn't matter if Phase 5 is in design or build - someone has to address the problem request and sign it off.

Re:Your Are Asking For A Lot From One Tool.

[fleabag]

CMM is Capability Maturity Model. The scale goes from 1 - 5. It's focus is on repeatability of process. So:

CMM Level 1 - the project is fairly shambolic, but you have version control and the basics are in place.

CMM Level 2 - you have tight version control, defects are linked to item changes, all docs are under version control.

CMM Level 3 - as per 2, but your process is the same on several projects - this is "repeatibility". The advantage is that good management is becoming a process, rather than just being lucky enough to have a good manager.

CMM 4/5 - Never really researched these, but it seems to be about having such a repeatable process that any project you do could be run by a zombie, and it would all come out OK.

Caveat: This is massively paraphrased. There are loads of books on this subject. Do a Google for more.

Most normal development shops are CMM 2 - 4. Many places that have 5 do it by treating a defect as a project in its own right - so after 2000 defects, you can be damned sure you are repeatable.

Why web based?

[dmouritsendk]

"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."

Why is it that every time somebody plans a new multi-tier application, it seems like a browser is the only "realistic" option for the client? Don't get me wrong, i think browser based clients (if designed correct) can be great. They offer ease of use to the user, and are basically platform agnostic. Also, web servers offer are a easy way for a developer to use server side program logic(as opposed to using component services of some sort in a custom build client app).

But just remember, web clients aren't always the way to go. In your case for example, I would think a custom created client might be a better solution. Since a custom MDI applications still offers far superior multitasking capabilities as opposed to a browser client solution, meaning you spend less time working with the application and more time working with the data in the application. The larger a application get, the less suited for a browser it becomes. Who for example would like to use a browser based C++ IDE? It would be possible (though stupid) to create, but 1000000:1 you would prefer to use a compiled gkt/kde/mfc/whatever based application.

Also, when using a custom client you can actually use that 500Mhz+ badasso processor that resides in most computers today. So instead of doing EVERYTHING on one maschine(the server), you can spead some of the application logic (like generating rapports ect) out on the client. And then just handle the most basic program logic(log in/out etc) on the server.

The geographical differences aren't a problem either, just use a database that's accessible from all the companies locations (simple networking task) in conjunction with the custom made client app.

Just my 2cents =)