Wikis and other Web 2.0 technologies are fast becoming commonplace in the workplace - but can they be leveraged for fast and effective requirements definition and management?

Forrester Research found that in 2008 nearly 50% of enterprise organisations were planning to invest in some form of collaboration technology or best practice associated with this genre. Indeed within HP itself the use of Web 2.0 technologies such as wikis, blogging, bookmarking and other social sharing initiatives is becoming more commonplace - hey this blog itself is part of that trend. However, the question becomes whilst wikis and other collaboration technologies provide obvious benefits can they really be leveraged by more traditional disciplines such as requirements definition where the focus is less on open commentary and more on rigour. After all, we all know that poorly defined requirements lead to poorly developed products so can we really use these flexible technologies to define robust requirements specifications.

In order to answer this lets look at some of the common advantages and disadvantages of wikis for requirements:

Advantages

• They are simple and it is very easy to learn how to use and create content
• There is nothing to install on a client machine
• They are platform independent
• They help to keep conversations in sync - no fear of dropping a participant of an e-mail thread
• Users can easily create links to other pages, attachments etc to identify source requirements or supporting data
• Open access to wikis means participants beyond the initial project group can get access to information meaning more rounded requirements are created
• Wiki content is often searchable in internal and external search engines
• Built-in version control system so you can see complete requirement history (not just the last set of changes)
• As they are often hosted on a centralized server, the information is always avaliable and is less likely to get lost or accidentally deleted (if it does it can be easily restored)

Disadvantages

• Because of their simplicity users might not be able to create content in the manner and format they might like. So for those of you wanting to develop rich requirements (with images, pictures, use case diagrams etc) this might not be that easy
• It can be difficult to capture content in a medium outside of the wiki for distribution
• Wikis are a new technology which may encounter resistance from stakeholders
• Can't always create traditional requirements views such as traceability matrix etc
• If the server is unavailable, no one can access any information
• Security can be an issue depending on where the wiki is hosted or if an external wiki resource is used

What's the ideal?

In my opinion wikis are a great way to do the initial phase of your requirements specification process as they provide a means by which multiple stakeholders can work together to define requirements in a easy to access and easy to document manner where collaboration is not only supported but encouraged by the nature of the technology itself.

However, I believe that once as a team a consensus has been reached on what each requirement means we should move to more traditional tools to manage those requirements and move them through the development lifecycle. My reasoning for this is because whilst wikis can be great for scoping of requirements as long as requirements remain in a form which is not easy to integrate with other phases of the lifecycle such as test and development the benefits of creating "solid and sound" requirements is lost. I.e. if we can't easily link requirements to other assets in the development lifecycle (which would not be that easy to do from a wiki and maintain full downstream traceability) then we are no further along in advancing our requirements processes than we were when we still used MS Word or MS Excel.

Hints and Tips to wiki Acceptance

If you do decide to go ahead and adopt wikis as your primary means of requirements elicitation it is important to remember that wikis are just a tool and just because you use a wiki it doesn't guarantee a project's success or that collaboration will occur (although it will probably be much more likely). In light of this if you do decide to go ahead and adopt wikis as your primary means of requirements elicitation what should you look out for in terms of gaining the acceptance of your Business Analysts (BA) to use this medium???

According to both academic researchers and practitioners in the field there are 4 key factors which will affect how a new technology (such as wikis) gets accepted by end users - and if we as an organisation can influence these factors we can make the first step in leveraging the power of the wiki within our requirements processes:

Effort

Highlight the ease of use of the wiki to the BA - use the advantages listed above

Performance

Make sure the BA understands that they can access their wiki anywhere and as long as the web works they work

Social

Emphasize the "coolness" of wikis - let the BA know they are just as dynamic as the rest of the stakeholders in the development lifecycle, they are using the latest technology, and they are on trend. See Gartner's hype cycles which promote wikis and Web 2.0

Resources

Leverage existing RM wiki tools to kick-start your wiki process, thereby taking the effort out of adoption, examples include: WikiSolutions, TWiki, OpenCollective

For me the key to successful requirements definition and management is remembering that it's not just about leveraging the latest and greatest technologies but more about ensuring that as an organisation you develop the right methodologies and practices to support successful requirements specifications - and once you have this you can leverage the latest and greatest technologies and tools in the safe knowledge you will be capturing the right information and using it in the right way.

That's all from me for now - tune in another time for more RM blogging!!!!

Thanks

Genefa