Working Up

by Dwayne Phillips

I experimented with using a wiki to gather and trace requirements. I tried the MediaWiki software. While it works well for building a flow down of requirements, it is not good at placing the individual requirements into a single Word document.

A systems engineering project is looming at work. We don’t have a commercial requirements documentation and tracing product here. In the past, we have used Office software such as Word and Excel. One of the things I have heard people use is a wiki.

So, I tried an experiment – how would a wiki work for requirements documentation and tracing?

The short answer: pretty well, but not great.

The long answer follows.

I downloaded the MediaWiki software from this site. This is the software that runs Wikipedia and a large number of lesser known wikis on the Internet. I had used this before at work and at home, so I was familiar with the syntax and other features.

To run MediWiki requires an Apache server, MySQL, and PHP. Since I was running on a Windows XP system, I downloaded and installed Z-WAMP from this site. Okay, everything downloaded, installed, and MediaWIki is running fine.

I started a little set of requirements using the classic top-down approach. A system (0.0 System) has two subsystems (1.0 Subsystem One and 2.0 Subsystem Two) and each subsystem has several types of requirements in several components. I quickly became lost and frustrated.

Scrap it and start over.

This time I just entered requirements as they came to my head. Each requirement had a simple structure of:

• Content
• Parent
• Child

What I didn’t know at the time, I left blank. I used the Category feature of MediaWiki to create tags. For example, each requirement that didn’t yet have a parent was given a “Category: No Parent.” Clicking on “No Parent” at the bottom of a page showed me all requirements that didn’t have any parents. That let me know where I needed to work, places where I needed to enter parents and build the requirements flow down.

In the same manner, I could click on “No Child” and see parts of the flow down that went no where. Again, that was a place to go to work.

WikiMedia is a good tool for building a flow down. Using the Categories as tags, you can easily see the holes in your flow down.

Now for the not-so-good news for MediaWiki. I couldn’t think of a good way to move the requirements from many pages to one document. Our customer likes to see one printed document in their hands. The only method that comes to mind is to visit each requirement page, copy the text, and paste it into a single Word document. That is a pain; it is slow, and it is error prone.

A little more good news for MediaWiki. If I have a team of engineers working together, they can each enter requirements on individual wiki pages. A systems engineer would have to go through these pages and use tags to create a flow down. This is a much faster way of gathering and documenting requirements than taking turns editing a single Word document. There would be a little learning curve, but we could work with that.

Conclusion:

A Wiki is an acceptable tool for documenting and tracing requirements. If I could find a wiki tool that would quickly collapse into a single Word document, I would use it.