Slashdot Mirror
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."
post your requirements on /., as you've done in this case.. :)
Version control would get a little difficult though.
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?
Well, may I humbly offer my company's open-source contribution, which we call "Outreach Project Tool."
It was really developed as a way to allow us to keep in touch with multiple customers and partners for various projects, and includes incident management, a knowledge base, bulletin board, document repository with versioning and notification, and a handy e-mail archiving system too. It has a few plug-in options, including a GANTT tool, and an on-line update capability. It uses LAMP, but will also run under Windows if you're able to set up MySQL, Apahce and PHP correctly.
See: http://outreach.sourceforge.net.
Paul Gillingwater
MBA, CISSP, CISM
Seriously, roll your own.
There's nothing that meets your requirements better than something you rolled yourself, so get to it!
Aegis is a nice configuration management tool:
http://aegis.sourceforge.net/
It has some of the wanted features.
I agree it won't be fully integrated solution, but you may consider some tradeoffs.
;)
Wiki (the interactive collaborative system, implementations I know of being TWiki and MoinMoin Wiki) can be used pretty effectivly for a lot of these things.
I have tried using it. It does take a little getting used to, but once people (developers I am assuming) are hooked to it, there's no turning back. And i'm speaking from experience
As T/MoinMoin are open source implementations, you may even be able to integrate it into bugzilla without too much difficulty.
Hrishikesh
US is now divided as the "Red" and "blue" states. Red States = communist countries. Coincidence? I think not
http://www.tutos.org
Seems pretty complete. I'm looking at using it.
What is pirate software? Software for inventory of stolen treasure?
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
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.
"Consider yourself a member of a virtual corporation with Mr. Torvalds as your Chief Executive Officer." - Linux Advocac
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?
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
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
****
"I'd never want to join a club that would have me as a member" - G. Marx
Here are a few thoughts - I've done similar things on large projects, so it might be useful.
:-) ). We may be going to RTF soon becuase they are easier to generate from the Sun boxes we have at the back end.
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
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.
"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 =)
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.
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.
I would like to have this sort of tool myself. I've been at enough startups where the requirements are in constant flux and are "managed" in the great verbal tradition. I used Requsite/Pro once (4+ years ago) and it was awful.
I used Xplanner (http://sourceforge.net/projects/xplanner/) for a small project last spring and found it useful for a small project.
You might also look at Jakarta Maven as a related useful tool
I would add to your wishlist:
* linkages to design specs, test cases, defects and source modules.
* Team-based time estimates, project management hooks and actual time effort measures. (how can you commit to a schedule without knowing you velocity, vicinity and vector?)