Perspectives & Strategy

It has always been clear that the process of defining application requirements has always been a collaborative process, not simply involving IT people, but a whole raft of people across the business. So for such a collaborative process why do we tend to document the results in a private way?

What I mean here is that during the discovery phase we involve a wide audience, we gather information from everyone. Yet in the documentation phase we will write down our discoveries into a word document that is often only published to a limited audience. Yet there is a distinct advantage in writing our business requirements and specifications on a more modular basis, in a form of documentation that becomes available for comment and change by a larger audience.

My thinking here is that documentation, like programs, relate to specific problems each of which need to be documented in turn. Obviously discussions have to be documented, usually by a business analyst and that is often best accomplished by one person. It is better to publish the results of our findings a few days after the original meeting in order that this is fresh in everyone’s mind. Obviously a good BA has always published their findings, most often done in the form of an email. Many times the documentation is not as visible as perhaps it should be in a world where visibility is increasingly key.

This is perhaps one of the original ideas behind CASE tools to make the documentation available to everyone. However CASE tools are  possibly not the right tools to achieve this goal. Whilst diagrams do convey concepts they often do not include the detailed descriptions. Besides CASE tools have always remained a high-cost per user item and are generally limited to development team members, and sometimes only a subset of them. The idea of a Wiki on the other hand provides the capability to publish our results to a wider audience, and have them remain in the public eye. I would love to see a CASE to Wiki publication mechanism that ensures diagrams that all updates can become visible to a wider audience without having  to manually re-publish. On the whole Requirements Management should be about collaboration within the company.

Some of the pain points should our BA leave the project is having the new recruit understand their predecessor’s thinking. The point here is as far as possible to have the thinking available to a wider audience in the company.

The other aspect that concerns me is that once the project is delivered and the corporation is now working with its shiny new system the documentation is forgotten about, then eventually lost, even if those involved in the project remain in the company. At then end of the day though we need to be able to take the new enquirer back to the “large wall and the bunch of colour post-it notes” (with all the modifications in place of course) so that they may understand the thought processes that were in play. This should short-cut future investigations in this area. The truth of the matter is that we are all busy people and cannot be experted to remember all the aspect of a project that we worked on five years ago, our focus has moved on.

One of the first uses of a Wiki that I encountered was in the area of user documentation and corporate terms. This was useful because it was a public resource and was visible across the corporation.