Using a Wiki for Requirements Management? [closed]

Question

I have been looking for a collaborative tool for developing functional specifications. I am looking for the ability to:

• Have multiple users contribute to the specification.
• Provide some form of traceability, which could be done manually if needed.
• Provide users with the ability to add comments and notes.
• Upload and display Visio documents
• Upload and display mockup screens using Balsamiq Mockup.

My initial impression is that using a wiki could be a good tool for this task. Does anyone have experience with using a wiki for creating functional specifications? What would be the pros and cons to using a tool like this as opposed to a requirements management tool?

Your input is greatly appreciated!

Answer 1

It's possible to do what you describe, to develop requirements in a collaborative way, in spite of using a wiki. Nothing about the wiki paradigm assists in this process.

I managed a wiki on the Zend Framework project to track proposals for components. They're still using it. Proposals are different from functional specifications, but the usage is similar enough to your question that I think this is relevant.

A wiki doesn't take care of itself. Unless you have someone responsible for managing it and making sure there is some structure and consistency, it quickly becomes a mess. The real-world analogy would be to hand each of your team a blank sheet of paper and tell them to write up their part of the requirements. Problems with this are:

• Every contributor has to make up their own document structure, and write about different things in a different order. So it's impossible to compare one page to another.
• There's no "index page" to organize all the disparate contributions. No one wants a page to "fall through the cracks," but in a wiki that's the default destiny of any page as soon as it's written.
• There's no feedback loop to make sure the writing actually gets done.

The way to make it work is to apply some process to the project, and use the wiki in accordance with that process.

• Give people the ability to create a new page in the wiki, but only through an interface that automatically links the new page into the right index.
• Define a lifecycle for documents, so they are sure to be drafted, reviewed, and approved at the appropriate stages.
• Provide a template for a new page. Provide the section headings that you need in each of these pages, and make part of the review process a confirmation that head section has been filled out adequately.

Answer 2

"What would be the pros and cons to using a tool like this as opposed to a requirements management tool?"

While it seems like a great idea, what you run into are people who can't and won't write.

People who can't write -- well -- can't write. They can't communicate with an email or a wiki or any medium outside voice.

• Some people are "disorganized". Actually, writing is too linear and they don't think linearly.

• Some people don't get the "write to your audience" and write stuff that's incomprehensible.

• Sometimes you can't even figure out what they're talking about, much less what they're writing about. They talk in jargon or code. They don't know much but insist on being heard.

Some people won't write.

• Some people refuse to make commitments. Even in a wiki where it can be retracted. They feel they must pre-discuss everything.

• Some people are in the habit of doing everything by giving direction to someone else. They either don't write for themselves, or, they make people stand around in their office and listen to them talk and type.

• Some people are generally toxic on any kind of project. They spring new requirements at the last minute. Their first response is "that will never work". They don't brainstorm well. When they say it work work, and you beg them for an improvement, they don't have one. They just know it won't work.

My experience is that only programmers can use a Wiki successfully. And only senior-level programmers.

• N00bz don't have enough experience to sort out requirements from design from rumors and management fluff.

• N00bz don't always have the language skills to write clearly. They may eventually, but one look at their Javadoc comments indicates that they're struggling with the "clarity" part of writing.

It's very appealing. I'm hoping for people to get better at using wiki's because I think it could have a lot of advantages over more traditional approaches where one person interviews everyone and writes things down. But it requires a level of confidence and skill in communication that few people seem to have.

Answer 3

Consider researching Fog Bugz. They tout themselves as the best of the best for project management. Considering Joel's history I'd give them the benefit of the doubt. They use a wiki in the way you've just described.

I would suggest signing up for the free trial, if you're serious. Depending on the size of your project, buying it might be a very good option.

At very least you could look at how they've structured it, or read the forums for ideas on how to build your own stripped down version