Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm interested if there are any websites or software out there to aid in initial project design, and then management of the project's design over time as features are implmented, bugs are found, etc... My design will include requirements (functional & non-functional), use cases, and basic database schema design.

Most sought-after feature:

  • Being able to define requirements and track their changes over time (i.e. how is version 1.5 different than 1.0?)


  • Being able to collaborate with other project managers and the team when putting together the specifications

What I'm not looking for:

  • Ticket trackers (JIRA, fogbugz, etc...)
  • Software version control systems
  • Wikis (unless they are built with requirements management in mind)


share|improve this question

closed as off-topic by gnat, MichaelT, GlenH7, World Engineer Oct 22 '13 at 1:09

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, MichaelT, GlenH7, World Engineer
If this question can be reworded to fit the rules in the help center, please edit the question.

I'm amazed nobody has mentioned the Rational suite.. maybe nobody uses it due to cost/fit? – JBRWilkinson Nov 16 '10 at 0:28

11 Answers 11

up vote 11 down vote accepted

Some remarks:


I will start out with explaining some properties of Requirements Management because I all too often am in situations where people think they are doing some kind of Requirements Management using Sharepoint, documents, spreadsheets and are doing all kinds of stuff but basically have no clue what Requirements are and have no clue what Requirements MANAGEMENT is.

Requirements Management is not a process area you make up or where you invent yourself how you are going to do it. It is defined. There are pre reqs and there are ISO standards. All in all it should minimal align with the goals and thus requirements as e.g. mentioned in CMMI ( and click REQM and RM). If you are not confirming to being able to do bidirectional tracability you are not doing RM but e.g. making "documents where some requirements are somewhere INSIDE". So you are probably doing designs but you are definitely not doing any requirements management.

Requirements Management is not about the content but being able to MANAGE the changes. So e.g. be able to do impact analysis effortlessly due to tracebility throughout the chain etc...


  • requirements are traceability items. Thus meaning everything that you can TRACE to something else. If you specify multiple houses that have multiple persons inside them living and you have a lot of them then "abcstreet 5" is a requirement and "person John" is another requirement. Again these are not documents but atomic items with some properties.

  • if you collect stamps and you have thousands of them you start by sorting them e.g. by country. With requirements you start by making requirement types and then make relations between the requirement types. This Requirement Type Traceability Model you can place in your Requirements Management Plan (ISO template). There are many ways to model this but one is to split requirements in use cases on the one hand for all functional stuff and architectural decisions on the other hand for all non functional stuff. The use cases go to the software developers and the non functionals to the operational guys who can start making their designs based on it. If there are extra functional and non functional asides use cases you can define an additional type (with the exception of SOA). Example Requirement Types (from top to bottom): business driver, business goal, business use case, use case, architectural decision, business scenario. Again these are not documents.

  • Requirements have attributes thus e.g. priority or state or even owner. Thus for all these individual requirements you can see the state e.g. "proposed". Hundreds of attributes are possible here. With this you empower your Requirements approach. You can also think of attributes that hold the list of RFC's and Defects that were related to it...

  • Requirements have history and can be versioned. So you have control on who changed what when.

  • The Requirement TYPES traceability leads to traceability on requirements. Some which you specicify as required and others than can be implemented when needed. With this you enable doing Requirements Management: if e.g. one non functional requirement changes (someone changes "within 10ms" to "within 5ms" you know 2 things: a) that someone changed it and thus this better be as a result of an official change b) all related requirements that are impacted (because of the traceability) it makes it a breeze to do impact analysis in this way: you see immediately what potentially changes. For example: that single non functional change leads to 2 use case (steps) changes, 1 screen that changes (also defined as requirement type) and 1 documentation help part that changes. You then ask these persons how long it takes them and you have your impact. But more importantly: it helps you control this process and govern the process of all these little changes. Also for bugs: you can pinpoint which requirements were impacted and thus get a feeling for metrics on which part of the requirement most bugs occur.

  • Requirements and Modeling are layered: you do business requirements, then the busines model, you do use case requirements, then drag them to your modeling tool, do modeling, then do deeper technical requirements then drag these back to do technical modeling etc... So you NEED to be able to trace individual requirements to model parts to keep being able to have full traceablity.

  • some requirements have a relation to *requirements document*s e.g. a use case requirement (consisting of a hierarchy of requirements e.g. use case steps and alternative flow steps) related to a Use Case document. There is probably a lot more in that document but these are the requirements you trace to and want to manage. Designs are OPTIONAl. If you set up the correct Requirements Model you can choose to have no designs. You will only have Requirements and listings of requirements. Use Cases will lead to more technical requirements deeper down in the hierarchy e.g. 1 use case req leads to 7 screen req with 5 applets req on it. If you want to put that in a document to distrubute around, fine. This also more helpful for testers: they can link their testcases and do some automated testing instead of "here you have a design base you testcase on it". Other requirements have NO documents associated. Maybe you get a list of non functionals initially as a company standard and decide to enter them as individual requirements and maitain and extend them individually another example are a glossary and terms. You can obviously generate report out of it to list them all in a doc but the other way around "getting them from the doc" means you need to maintain the doc instead of the requirements in the first place. Double work.


To be able to manage the whole chain you need reports. So your tooling needs to be able to produce a lot of reports out of the box and some kind of handy reporting tool. Furthermore it obviously needs a integreated database behind the requirements/change/etc tooling so that you are able to say e.g. "how many high priority items have not been finished yet" or "what is planned versus actuals" etc...


Your question in broad but in general I read: traceability over the full lifecycle so from business decision to architecture to analysis to design to modeling to build to test to production. 3 people above mentioned Rational / Doors for Requirements Management.

I think you would need at a minimum such a thing for doing the requirements management. You do not ask for a ticketing system though you do need one integrated with all of this since you need to setup the traceability from the tickets, hotfixes, RFCs, defects, questions, etc.. etc.. to your requirements to manage scope and to have overall reporting.

Since Doors was mentioned 3 times take a look at : it is a more or less integrated suite for a lot of these things and do some googling on it on the web. You will see Rational Requirements Composer in relation to the future of Doors:

(Rational always had RequisitePro, then they bought Telelogic so now own the #1 and #2 solution in terms of marketshare, the Jazz platform is the new move, could compare it to Microsofts move to .NET : new platform, new technology and according to gartner/forrester the only solution that leads the way).

If you go for this I would advise to also include RTC: RTC = version management, change management, build management etc... all-in-one and also plugs in the Jazz layer. (its free for 10 users, no need to install, just click start on the server, start on the client and there you go to test it). (also a lot of reporting in it).

So for the tooling question: take a good look at Jazz and read up on the articles on there, also check for independent reviews on IT sites on it. RTC is a free download for up to 10 users (and e.g. syncs with svn/git/etc not your question just mention it).


"Being able to define requirements and track their changes over time (i.e. how is version 1.5 different than 1.0?)"

You toch 2 different process area here: 1 is requirements management that lets you have traceability over requirements. The other is configuration management where one of the basics is to include requirements in each baseline. By combining both you get your requirement. And yes: that is possible in the above solution. If you just want to look at individual requirement it is ofcourse just right mouse click to walk along the versions. If you want to compare greater sets e.g. domains or even a complete release you use a baseline comparion on the requirements and output that.

Probably if you write some custom reporting on it (remember you have a database behind it so you can do basically anything in your wildest dreams) you can even do more like specifying also "only interesting ones because of..."

Being able to collaborate with other project managers and the team when putting together the specifications

tools support several layers of that.

In the first place, since you have indidividual requirements you can open discussions traced to one requirement or a set and maintain the discussions on it instead of having to collect each individual mailbox afterwards to learn about he non trivial decision.

For project managers I dont think you want to micro manage each individual requirement change. I think the reports from the Collaborative Application Lifecycle Management tool should provide you with the issues to focus on e.g. the top 5 requirement parts scheduled next and which are way behind. (so in the case of Jazz this is the RTC part).


Probably a lot

share|improve this answer

Google Docs

  • Free, you just need a Google account
  • Online, no software to install
  • Excellent collaboration tools, multiple people can edit in real time, it will resolve most conflicts
  • Version history, easy to track changes
  • Export to PDF


  • Not as fully featured compared to Microsoft Office
  • Doesn't render other document formats created outside of Google Docs pixel perfect
  • They don't have offline support (at least on the one I use)

For functional specification and requirements I try to go with the simplest tool, Google Docs is easy to use, easy to collaborate and easy to export.

share|improve this answer
Interesting idea, thanks for the comments – Jon Onstott Nov 12 '10 at 23:44
I use Google Docs. In addition to allowing multiple users to edit at once, it also has a chat box on the side so they can chat with each other while editing. – Rachel Nov 18 '10 at 16:07
Putting your requirements in documents is NOT requirements MANAGEMENT. Read the requirements for requirements management... You need bi directional traceability between your atomic requirements. To be able to do impact analysis, phase out, phase in requirements. Trace them all the way down, etc... So maybe you do "requirements management" as "i manage something" but this is NOT requirements management. – edelwater Nov 21 '10 at 15:36

Use a wiki with logins.

share|improve this answer
+1 If done correctly, your product is documented before you write a single line of code :) – Tim Post Nov 15 '10 at 4:27
documented may mean specified; this is a substantial win. – Tim Williscroft Nov 15 '10 at 4:35
I've done this - it was fairly effective. – AShelly Nov 16 '10 at 21:13
@Tim Willscroft @Tim Post @AShelly : What wiki software do you recommend for this? :) – Jonathan Nov 17 '10 at 23:33
@Tim Post - That sounds a lot like waterfall to me! – adamk Nov 21 '10 at 20:14

Many big engineering organizations, including mine, use Doors, "A requirements management tool for systems and advanced IT applications". It's designed for things like requirements flowdown and traceability. It has a web interface client for allowing users to collaborate on requirements development.

However, it's definitely geared more toward the big enterprise than small teams, and I suspect (although I do not know) that it's very pricey. I don't use it personally, but I haven't been impressed by the interface when I observed others using it.

So I'm including this answer more for completeness than as an actual recommendation.

share|improve this answer
+1 the video demo is cool ! – barjak Nov 17 '10 at 13:20

AShelly has already mentioned DOORS but we actually use it in development, so I thought I'd give a more complete answer.

DOORS has some great features for traceability, if combined with a supported tracking, and source code management toolset (we use Rational Change and Synergy) it can allow you to trace requirements all the way down to code which implements it, and back up again. Which is great in the highly regulated environment we work in. It also supports versioning and baselines of requirements, and impact analysis of changes, which are VERY useful in large developments.

However it adds a significant overhead to development, as to have all those features you really need to put all your documentation into DOORS itself, including any design documentation, test specs and even project plans. This wouldn't be too bad except the user interfaces is not good, it is clunky and not always obvious how to do what you need to do. The table format lends itself well to requirements but not too any other type of document. It's also very slow, even with a fast server and fast pc you can expect a few seconds between entering one entry and the next.

share|improve this answer
Thanks for the first-hand account – AShelly Nov 22 '10 at 20:29

This answer can get very complicated very quickly. In particular, it depends on what level of the design you are working on. If you are focused only on the requirements, then Google docs and other collaborative document tools will be the best choice (since it gives you transparency between your team members and potentially stakeholders - also Google docs has a version control system built into it).

However if you are looking at mid-level design and subsystem design, then actual diagramming tools will be better. I have not found anything like Google docs that works well with this (and Google's drawing tool falls short also). Personally I would use a wiki or Google docs to show the exported diagram image and use Dia (an opensource diagramming tool) with a version control system (mercurial maybe) to create my actual diagrams.

A wiki might be a good place to organize everything and provide links to the other tools and locations as needed. I experimented with this on a class project earlier this year. I personally thought it ended well, but I did not have complete buy in from my teammates, so it ended with me using the wiki primarily.

One final note of caution: try not to let your tools dictate what you do, but rather decide what you (and the team) want to do and find tools that will enable you.

share|improve this answer

This doesn't exactly meet your requirements, but if your team is dedicated to test driven development you might be interested in Concordion, where your specifications and automated tests are one and the same.

share|improve this answer
Thanks, interesting concept – Jon Onstott Nov 15 '10 at 22:28

On The .Net side of things, I have been on a few project that use team foundation server to hold and manage requirements.

its good in that it is nicely intergrated with the visual studio, really helps the whole team (PM, BA, testers...) get on the same page, and work with the same set of artifacts.

It only for .Net though...

share|improve this answer

Lot's of tools out there, depending how much time and money you want to invest, we are doing most of what you have in your requirements using Visual Paradigm and Pivotal Tracker

share|improve this answer

If an application is your cup of tea,

Try CaliberRM from (inprise?) Borland. It's a bit painful, and acts somewhat like another digital ghetto, but has reporting and traceability,

I've used it for a number of real projects, and apart from the excessive price (30k per seat IIRC) it sort of worked.

share|improve this answer

I create test suites where the test methods map to requirements. This allows me to make sure I don't break existing functionality/requirements when I make changes. I suppose you could generate a listing of method added over time to reflect added functionality.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.