Requirements management software for mere mortals

Question

I would like to discuss with you a special case of requirements management. I call it “requirements management for mere mortals”.

I had worked as a project manager in a small web development company. Significant part of my daily job was talking with our clients to translate their wishes into the tasks for our developers.

The problem I faced is that most of the approaches and tools I used previously simply did not fit.

The root cause is that I had to work with completely non-techie stakeholders who do not care about requirements.

Another issue is a large volume of data. I had to organize info on dozens of small projects each month.

While I have adapted to the process in general there is an issue that I did not manage to overcome – software. It seems that there is no such thing as “RQ management software for mere mortals”.

There are tools like DOORS, Polarion and ton of other RQ systems targeted to enterprise (read terribly expensive and complicated) but there is nothing for a small business.

Here is a list of my wishes for a simple RQ management system:

• Web interface
• Each RQ is a separate entity with unique ID
• Each RQ is versioned (I should be able to see who changed what)
• RQs have tags for easy navigation/grouping
• A list of RQs (current state of RQ document) can be tagged/baselined
• Instant full-text search through all versions
• Primitive access control (as simple as “read/write” permissions)
• Built-in comments/chat to quickly discuss RQs in context
• Simple markup language support like Markdown instead of bloated rich text editor.
• Integration with email (i.e. I can discuss RQ via email but the message will be imported/stored in the system)
• Export of RQ document to the PDF or other commonly used format
• There should be no traceability or other features that regular user has no idea about. Basic links (i.e. "related RQs") between RQs would be enough.
• Extremely minimalistic and straightforward UI so any user familiar with GMail will be able to use/understand it from the first sight.

To summarize, I want something like Basecamp but targeted exclusively to requirements gathering process from regular people.

Did some of you experience the problem described above? Do you find yourself in a need of such software or you are perfectly fine with MS Word/Excel?

Edit: in response to angeline answer

I totaly agree with your recommendations but I do not have an issue with customers not getting RQ management.

I am having problem on my side - it is hard to manage RQs when working under certain conditions.

Even if there is no strict process (e.g. I am an independent IT consultant and decide for myself) you still have to take RQ management serioulsy.

For example, right now I have 350+ email messages regarding one of the projects. Now I need to find some specific RQ to take a decision. Even with smart features like labels and buit-in search in GMail it is incredibly hard to work with. Note that this is not a single issue - there are different problems with small projects as well.

If you have an Excel or Word document you will face with another issues:

• Changes tracking - can you effectively see who changed what in an Excel sheet?
• Versioning - having 10 version of a document doesn't make you life easier
• You still can't prevent customer from sending you info via email which quickly makes your document out of date.
• Collaboration - tossing MS Word document around is not a joy
• etc.

In my opinion, software described above can solve all of these issues. On customer side it will be either plain old email messages or some simple web UI like one we have on stackexchange.com sites.

The obvious benefits are:

• all information will be in one place and I will be able to easily manage it
• there will be little or no effort for customer to use this system

Edit 2: in response to Adam Wuerl comment:

Currently, I am using Redmine for requirements management. I think that bug tracker is the closest approximation of ideal tool described above. The problems with bug trackers is that they are either non-customizable (to the degree I need) or too flexible (read complicated).

I asked this question in the LinkedIn Requirements Engineering group and of the members has recommended to use Trac.

Unless there is a simple RQ management system available, customized bug tracker would be a good choice.

Answer 1

Have you considered re-purposing bug tracking software? I've never used it, but based on the marketing materials it looks like the web-based FogBugz could probably do everything you want.

You could make each RQ a "bug" in the database. They're taggable, searchable, have a unique ID and version control. (I think) there are access controls (e.g. full, read-only), email integration, etc.

I'm not sure about PDF export.

Answer 2

Is this an accurate summary of why you need a system?

We can't find information we need

because

There is no single repository of information to refer to

because

There are lots of emails and documents with scattered information

so

We need a system to centralise information from emails and documents

If the answer was yes, I understand how you got to the "I need a system for this" solution.

But what if we keep going?...

We can't find information we need

because

There is no single repository of information to refer to

because

There are lots of emails and documents with scattered information

because

There are frequent changes in requirements

because

Customers aren't yet sure what they want

so

I need to help my customer develop their wishes into something I can work on.

Even then, there is probably another layer (or more) of "because" that you need to get to. Solving it might mean the problem of constant change and the associated emails and document revisions goes away.

Answer 3

No tool is going to solve the issue of stakeholders not understanding what a good requirement is and why it is important. It is the process you need to work on - if you have bad requirements, no matter how fancy and sophisticated your software is, you will still get bad requirements (rubbish in, rubbish out).

Personnally I find that MS Excel works perfectly fine. I like to keep things simple and avoid over-engineering things - I find that unless you are in an organization/industry that demands stringent control over requirements definition/validation there are a lot of features you mention that you can do without (and some of them can be done in MS Excel).

Some recommendations:

• Educate your stakeholders on requirements definition: organize a workshop and share with them principles and ground rules of effective requirements gathering, using examples of "good" and "bad" (and "ugly"!). Get them to work with sample requirements - don't take their own requirements as examples, try to use requirements from a different project so your stakeholders can look at them and practice in a neutral, objective manner.
• Use techniques that help your stakeholders define requirements: use imagery, visualisation techniques, process mapping, mind mapping, user case or user stories to help your stakeholders define and articulate their needs. Help them write good requirements by suggesting appropriate wording.
• Get them to focus on value: when defining requirements, make your stakeholders put a value (business benefit) on each of them: e.g. what will this enable? how will it impact our ability to execute a business process? how will it help us improve what we do? etc. Focus on tangible benefits rather than loose improvements (eg. "will reduce time to produce analytics by 80%" vs "faster reports").
• Be clear about roles in the requirements definition process: business requirements should not be defined by the technical team because they are not be technical requirements. The fact that your stakeholders are not technical is actually an advantage because when you have stakeholders who are (or think they are...), you often end up with people thinking about the solution before the need (eg. "we need a button to click on to do X..."). You can however educate them on basic technical terms and concepts. Conversely it is not up to your stakeholders to define tasks for the developers; it is the project team's job to translate business needs into tasks.
• Prioritize & validate requirements: include a prioritization process as part of requirements gathering and definition, and get stakeholders to sign-off on requirements.

Answer 4

The closest product that I can think of that matches a large portion of your list is Pivotal Tracker.

Note, that this tool is an agile project management tool, however I think you may be able adapt it to fit your needs. At the very least you can signup for a free trial and check it out.

Answer 5

This is a tough question because I see lots of underlying questions/assumptions.

Requirements management is huge and often over complicated. It is one of the main reasons for the huge focus on prioritization and user stories in the Agile methodologies and approaches, so that we keep teams and customers conversations focused. A lot of times, the behavioral change and approach change can often make the requirements management easier in itself because the group is focused on the highest priority section of the list instead of the full thing.

Why I say this is a tough questions is because if your project is run more traditionally, the is a much bigger conversation.

To answer the tool question in specific, I would search for some Agile requirements management tools, like Rally or VersionOne where you can at least save your conversations and requirements as well as start trying to stack rank them to increase focus on the highest priority items.

Answer 6

It seems to me you should give Google Docs a real try in this capacity. It seems to address all your concerns in your first Edit section.

With it's new issue-like comment system that integrates with email it can really help track the consensus process.

I've actively contributed to documents with over 5 concurrent people editing and commenting and it seemed "natural".

One thing I wish was better was search and navigation of the revision history but the raw rev tracking is good and hopefully they continue to improve it.

Answer 7

After reading the whole question and the answers so far, I can find no reason not to suggest Atlassian's Jira.

I know it's paid software, but it really is worth the price.

The latest version I used (v4) had a fancy interface, was straightforward enough for our clients and enough customization for our management.

I believe it's worth your time to take a look at it.

Answer 8

I would suggest Atlassian Confluence with the Requirement Yogi add-on.

• Easy for non-techies: Confluence has an easy, MS Word-style wysiwyg editor,
• Unique number: Yes
• If you link to a requirement, you can see an excerpt when you hover over it,
• Versionned: Yes for Confluence pages,
• Search: Yes
• Links: As you suggested, traceability matrix aren't human-ready, so it's just links,
• Export to Excel

Here's an example of inserting a link to a requirement key and showing an excerpt in view mode:

Disclaimer: I'm the author of Requirement Yogi.

Answer 9

I recommend taking a deeper look at Atlassian's JIRA with the JIRA Agile plugin. If you need to document relatively extensive requirements or general documentation in the future, it integrates well with Atlassian's Confluence. When used appropriately with a workflow that everyone understands, this can be a very effective team of tools and it looks like they meet most of your requirements.

As an admin user of JIRA, you can customize the interface, permissions, etc. There are a lot of options available on the default interface that could be confusing, but you can customize the interface and simplify it to the point where it's easily understood by your "non-techies", but still has the robust features that are needed to meet your requirements.

This was the system I had in place and it worked well for the context of our organization. The biggest issue we had was applying a standard; everyone needs to understand the workflow (and actually follow it).

Answer 10

I have used several requirements management tools - ReqTest, Jama, Modern Requirements, Xebrio, ReqSuite

Except for the 'Simple markup language support - the above-mentioned tools support the full feature list. Having a simple markup language support certainly adds value. One more issue is that the above-mentioned tools have extensive traceability features. I guess a simple and easy to understand UI will solve the issue of traceability. And, in terms of the simplicity of UI and processes, I would weigh in for Xebrio.

Answer 11

zAgile's Wikidsmart PM seems to match up with the request. It enables requirements management within the Atlassian Confluence wiki by offering structured wiki templates for Requirements definition that are then tied to JIRA for task management. It's open source and free to download at www.zAgile.com

Disclaimer: I'm affiliated with this company.