Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Feb 2 '11 at 3:24

This question came from our site for professional and enthusiast programmers.

add comment

3 Answers

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!

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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