using a wiki for requirements

Question

I'm looking into ways of improving requirements management. Currently, we have a Word document published on a Web site. Unfortunately, we cannot (to my knowledge) look at changes from one revision to the next. I would greatly prefer to be able to do so, much like with a wiki or VCS (or both, like the wiki's on bitbucket!).

Also, each document describes changes devs are expected to meet by a given deadline. There is no collection of accumulated app features documented anywhere, so it's sometimes hard to distinguish between a bug and a (poorly-designed) feature when trying to make quick fixes to legacy apps.

So I had an idea I wanted to get feedback on. What about:

1. Using a wiki so that we can track who changed what when (mostly to even see if any edits were made since the last time one looked).
2. Having one, say, wiki page per product rather than one per deadline, keeping up with all features of the product rather than the changes that should be implemented. This way, I can look at a particular revision of the page to see what the app should do at a given point in time, and I can look at changes to the page since the last release for the requirements to be implemented by the next deadline.

Waddayathink?

Answer 1

Yes, that's sound a good solution, if you organize the page in a simple structure, easy to browse.

Choose a wiki with a simple syntax. ( Dokuwiki is a simple one and not require a DB )

Edit: if you use a version control system, that is SVN or BZR, try Trac, where you can define milestone, keeping bug and features request, and define your own workflow to manage a bug! Wiki is included!

Answer 2

I like your per-project wiki approach. You mentioned bitbucket, I assume you're using them as your repository host. If not I would also take a look at the wikis on GitHub.

If your willing to spend a little money, checkout Lighthouse. Its my favorite way to track feature request and bugs at the moment. I'm also quite fond of using Pivotal Tracker, pivotal was free but is moving towards a paid model now.

Answer 3

A wiki is a good way to go. I think it would be best if the documents were still versioned. You can have floating documentation that keeps with the most current features. Still take snap shots that way it is easy for someone looking back to find documentation for that software three versions ago, without having to look through the document history, which is made for quick reversions and not well suited to look back years or months.

I started off using Media Wiki, but now we are using Xwiki. It has a pretty good GUI editor which anyone should be able to use without any training. It also has an idea called 'spaces' each space creates a new name space so different products can all have a page called "features", rather than product_x_features or something silly, this then greatly reduces the need to manage multiple wiki installations. Also there are tools to integrate word and xwiki, letting you save word documents directly to the wiki. All said it is far more feature rich.