Dan Moore!

Wiki practices for requirements documentation

I have been heads down for the last couple of weeks helping write requirements and design documents. The team I'm on is building them using a wiki. (I discussed the wiki selection process a few weeks ago.)

I just wanted to outline a few practices (I hesitate to call them best practices) for using a wiki to document business and technical requirements.

• Having a wiki allows anyone to edit the requirements. This doesn't mean that everyone will or should. Documents should still have an owner.
• Require folks to identify themselves. Require Author met our needs, as it requires an editing user enter some identifier. A history function, without tracking who made which edit, is fairly useless. Note that our solution works for a small team. A larger team may want to authenticate every user.
• Make sure you lock down the wiki. We have ours behind the firewall, which means that we don't have to require a user to remember yet another password, or even login at all (beyond providing some kind of identifier once, as mentioned above).
• PDF generation allows you to generate decent looking print documents. I found PmWiki2PDF to be adequate.
• Think carefully about document structure. We broke out the requirements into sections, and had each section on its own wiki page; more than that, we have pages for each section for each type of requirements (business, technical) or design document. These three section pages are pulled into a page for that one component, via the page include directive, which should describe everything known about a particular component. This kind of page seems useful at present, but we haven't begun coding.
• However, if I had to do it over again, I'd build each main document as one wiki page, and then pull the component info out of that. This allows a user to view the overall history of the document, as opposed to the above setup, where, to see what has changed in the requirements, you have to visit as many pages as there are sections. (You can also look at the RecentChanges page for a group, but that has only a page level granularity, as opposed to the line leve granularity of the page history.)
• Choose page names carefully. While it's easy to move content from one page to another, realize that you lose all the history when you do that. Well, actually, you might be able to move the file on the filesystem and retain the history, but for normal users, moving a pages (that is, changing a page name) causes history loss.
• Keep requirements, whether in sections or in one document, in a different group than the design document. This allows you to lock down the requirements group, via a password while letting other documents, like design, continue to evolve.
• Cross reference extensively. Don't cut and paste, link or include.
• Use pictures. The support for uploading pictures in PmWiki is alright, though the support for removing them isn't great. Regardless, don't shy away from diagrams and other graphics in the wiki.

I'm going to be interested to see how the process continues to evolve as we get further into development. But so far, I think that a wiki has everything you really need to generate requirements documentation for a small team of developers.