Fog Creek Software
Discussion Board




Requirements Creation/Management Software

I've been tasked with researching requirements software. I've done the standard googlisationmentlessness and landed on three that I like (based on their website-y goodness). They would be:

- SteelTrace Catalyze
- Telelogic DOORS
- Rational Requisite Pro

I did a little search around here because I remembered Philo having a bit of a go at requisite pro (as did others in the thread).

What I'm after is anyone who's used any of these (or any I haven't looked at) and what they thought/found/tripped over.

I've looked at others (RMTracker and Analyst Pro come to mind) and they seem aimed more at management of requirements than creation and management.

Ta.

Geoff Bennett
Wednesday, September 03, 2003

Requisite Pro sucks.

HTH,
Philo

Philo
Wednesday, September 03, 2003

Requirements are so 1998!

We use Microsoft Word.

m
Wednesday, September 03, 2003

Hmmm - would a wiki work?

(by the way, I consider wiki an incredibly unfortunate name. It's a very, very useful tool but man does the name make it tough to pitch to clients. It's too "cute")

Philo

Philo
Wednesday, September 03, 2003

Geoff,

You forgot to mention in your post what you expect from a RM software tool.

DOORS probably has more functionality than the other RM tools you mentioned, however, I have read that it's user interface is sucky and it is expensive.

I would like to tell you that you only need to use a word processor, however, I am not sure what your needs currently are.  Microsoft Word, a drawing program, and source control software are the only software tools I have ever needed and used.

One Programmer's Opinion
Wednesday, September 03, 2003

Then, if wiki is open source, why not branch wiki and call the new version "Enterprise Requirements Gathering System" (ERGS) ?

That will sound very cool to corporations!

The CEO will be able to say: "We use ERGS for requirements gathering."

Thunderstone
Wednesday, September 03, 2003

I tried Requisite Pro a few years ago and it was just a horrid, horrid product. The UI was cryptic and in general, it was a pain to use. Perhaps it's gotten better.

While it's important to document requirements, make sure you aren't falling into the documentation trap, or "paralysis by analysis".

Don't underestimate using something as simple as Word.

Mark Hoffman
Wednesday, September 03, 2003

"Perhaps it's gotten better."

No, no it hasn't.

The only reason I'm edgy about word is the need for consistent group access to the document. Word has some fairly advanced group versioning, but
a) it bloats the document
b) someone needs to be "in command" - controlling versions and submissions. IMHO this impairs free contribution to the document
c) Even though it's pretty good, it still has issues regarding merging (esp. where formatting is concerned)

A wiki gets around all of that. However, an interesting problem is that I don't believe wikis are geared towards document generation, are they?

Philo

Philo
Wednesday, September 03, 2003

"IMHO this impairs free contribution to the document"

In my experience, that is the point.

We'll have brainstorming sessions, we'll have requirements meetings, we'll have any number of places where we attempt to extract the user's ideas and get them on paper.

However

We have a small number of people that actually document the requirements. Users are generally horrible at writing a good requirement, so I don't even want them doing it. Tell me what you want, I will write it out and read it back to you and you tell me if that satisfies what you need.

Rinse. Repeat. Until we have a document that everyone agrees on.

Mark Hoffman
Wednesday, September 03, 2003

I've used DOORS for years and it's probably the best of the 3 in terms of power. Unfortunately, getting it to really perform takes a heck of a lot of work/training since it's power is hidden.

A few years back, a company sent me a glossy flier for a new requirements management tool. The descriptions and screenshots were EXACTLY what I wanted and the price was right. Unfortunately, the corporation I was at INSISTED on DOORS. Thus, I accidentally tossed the brochure. Now that I am no longer under the thumb of DOORS, there's not a day that goes by that I don't regret tossing that flier or forgetting the firm's name. :-(

StickyWicket
Wednesday, September 03, 2003

Mark - I agree. The problem was that there were four of us working on the document and we were still slaves to the process of coordinating updates - changes were lost, change annotations appeared out of nowhere (probably the result of a wayward carriage return), etc. IIRC, it even annotated changes in font or layout.

And by the way, I personally have always had issues with Word's outlining. But that's just me. :)

Philo

Philo
Wednesday, September 03, 2003

Since nobody else has said it:  Have you tried note cards?

Personally, even though I use an XP-inspired process, I don't use note cards for tracking user stories.  I use an outline in OmniOutliner instead, which works just about as well for me.

But if your development process is so heavyweight you're thinking about using specialized software to track requirements, I think that's a sign to start looking at your process itself.

Chris Hanson
Wednesday, September 03, 2003

Personally my requirements gathering is highly low-tech. A printing whiteboard, a bunch of text files (text is easy to diff), etc. If we need to send anything out to a client, we can easily generate a PDF.

For distributed text editing, I like http://www.codingmonkeys.de/subethaedit/ (formerly known as hydra) however I am one of the few here who owns a powerbook.

Something similar and more cross platformey would be nice...

Rhys Keepence
Wednesday, September 03, 2003

Thanks for all the input. The Requisite Pro issue is a curly one, seeing as another division in the company has purchased a license for it, but seeing as they don't track requirements, they've not used it. Management of course will be interested in the fact that they don't have to fork out money, and that usually has a ridiculous amount of pulling power. :(

DOORS does seem interesting, but now that someone mentioned the price, it's a bit scary.

For the explanation on what we expect from RM software:

We are only a small team (for a laugh, 6 managers, 4 programmers), but we operate on relatively big dollar software for the finance industry. Each sale is accompanied by countless customisations, and they are usually very strict.

The attitude amonst most of the managers here (there are 2 who don't fall into this category) is very blase towards requirements gathering and management. This is without software, so I don't expect things to get any better with software, but we (the people who give a salty pecan's pecker about what we do) have got to do something.

The rest of the company here (we are one division within 4) is very process oriented (but not process heavy).

The lifecycle of a project here starts out meaning well, with what could be called high-level, semi-functional specifications being written that are basically ambiguous, and everyone is in a feel-good back patting mood. When we actually start to develop, knowing we haven't got the requirements to pull it off, things start to go pear shaped. Then the clients start to complain about "this is not what we wanted etc", then the arguments start, the accusations fly, and threats of a legal nature are made.

So, we want to try and force people to use the software, and create a policy based on the fact that if it's not documented in the requirements tool to the satisfaction of the developer, it's not a requirement. Then we want to be able to track changes and the impact they'll have on the bottom line etc etc as the client requests them. We want to get the client to sign of on a requirements specification generated by the requirements gathering process, and we (the developers) want to know that we have basically got it covered.

Due to the nature of the finance industry there is a bucket load of terminology that gets used slightly differently between each client, so the ability to maintain a project glossary and cross reference it with requirements would be a major bonus.

Basically, we're trying to put *some* process in place here so we can at least start to get the runaway development lifecycle under control.

Geoff Bennett
Thursday, September 04, 2003

[Disclaimer: I sell CollaborativeAID]

I currently use both ReqPro and a Wiki-like tool (commercial) called CollaborativeAID (for Agile Integrated Doc).

The pro of ReqPro is that you can use the requirements attributes.

The con is that you can not work with subparts of the documents, which is pretty annoying and becomes a bottleneck.

The first time I used ReqPro, I found it bad but you have to dig under the surface and work the way it was intended. Then it works pretty well (just work like it wants to).

But it becomes difficult to use for a big team. As I mostly work myself on my specs, it works very well... The baselining features are great.

For CollaborativeAID, it's great to be able to work on parts of documents on the web, include parts, draw stuff (it has an integrated UML design tool (java web start based).

I was pissed off by the need to work with Word docs over the web and was trying to find something to solve that need. I stumbled across CAID and it worked so well that I decided to resell it.

It generates SVG graphics, allows for WYSIWYG design of GUIs etc. A very good tool to work like Joel outlines in his specifications writing articles.

As an added benefit you can generate static HTML pages for a set of docs.

http://www.highoctane.be/articles/Sphinxmodeler.html
http://www.highoctane.be/articles/CollaborativeAID.html

The best would be a combination of an attribute db and a wiki. I am trying to make that work by writing an extension to CAID but it's not there yet.

Phil
Thursday, September 04, 2003

The CAID "eat their own dog food", which is good:

http://www.self.com.au/aid/visit/project/self/aid/requirement/Index

(if asked for UID & PWD use guest/guest)

Phil
Thursday, September 04, 2003

*  Recent Topics

*  Fog Creek Home