Poll: What do you use for requirements management?

What requirements management tool do you use and why do you use it? I've placed a poll on the right menu bar.

What do you like about it and what don't you like?

Some web apps to get you going

Here are some web applications that you can use to improve your productivity as a business analyst. All of these are free! But you should realize that there are some things you need to consider when using these types of products:

• Confidentiality - Should business critical information be placed online?
• Acceptability - Is the use of these tools acceptable to your client(s)?
• Availability & recoverability - Can you get to your valued work products?

List of web apps

• Gliffy - A diagramming tool that supports online collaboration. Easy to make simple process flow diagrams.
• Google Notebook - A tool that allows you to make collections of information that you can arrange by subject.
• Google Spreadsheets - Online spreadsheets! Not as powerful as Microsoft Excel but still useful.
• Imagination Cubed - An online whiteboard where multiple people can collaboratively diagram and brainstorm ideas. Drawings can be saved and emailed.
• Remember the milk - A to-do list application. You can email tasks to add to your list.
• Thumbstacks.com! - A web-based presentation application.
• Voo2do - A to-do list application that is suitable for project task lists.
• Zohowriter - A word processing application.

Unfortunately, I have not found any free online tools that support things central to business requirements such as traceability and change request management. Perhaps that's an idea for a Web 2.0 start-up. Hmmm...

Thoughts on decision-making

According to new research on the Discovery Channel's website, cockroaches get together to make group decisions about things that affect them as a community. Even more astonishing, cockroaches do so without being able to make sounds. Perhaps, we can learn something about the science of decision-making from them.

Common myths about decision-making

1. The more time I spend analyzing before making a decision, the better the decision I will make. Sometimes you can spend too much time making a decision. Your indecision could allow a competitor to seize the initiative.
2. In retrospect, a decision that did not work out was a bad one. Because something did not work out does not mean a bad decision was made. There are many things that are beyond your control that can affect a situation and cause an undesirable outcome. This does not imply the decision was incorrect.

What's it worth?
Here are some basic questions that you should consider to understand the importance of a potential decision.

• Does it contribute towards meeting your goals or objectives?
• Does it contribute towards the goals and objectives of the company or greater good?
• What is the risk associated with an inappropriate choice?
• How much time are the key decision-makers and you willing to provide? If no one is willing to give time, then how important do they really view it? (I'm a little draconian here, I'll admit.)
• What are the associated benefits and costs of making the decision?
• What happens if I do nothing?

Some decision-making techniques

To help you with your decision-making needs I have listed off a few different techniques that may be useful.

• Paired comparison analysis is very useful when there are defined alternatives. The basic premise is to use a grid to directly compare one alternative versus another. The alternative that wins out against the others the most will be chosen.
• Use a SWOT analysis to evaluate different solutions to a problem or opportunity. This will give you an understanding of their overall appropriateness.
• Grid analysis involves comparing alternatives against a defined set of important criteria. The winning alternative will be the one that scores the best.
• When you have a few different issues to address and you are trying to determine which one to attack first, Pareto Analysis, can be very useful. It involves identifying the most pressing problems.
• Decision-trees are very useful to help you visualize all of the possible outcomes. You need to be able to estimate the likelihood of a path being followed as well as the value of the path (e.g., outcome.)
• One can use the 6 Thinking Hats methodology to examine the different aspects of a situation before settling on a solution. This methodology was developed by Edward de Bono and can be applied to innovative thinking as well as decision-making.
• Force field analysis is extremely useful to understanding the different forces that affect an issue. The great benefit from this technique is that it will illustrate all of the areas that will be impacted and may require a change management process because of a pending decision.

Some other great resources

• Mindtools
• 6 Thinking Hats
• Management Methods

Stay committed to your decisions, but stay flexible in your approach. (Tom Robbins)

Moving forward

Over the weekend I decided to change the look and feel of my blog. I'm using one of the default templates from Blogger with some additional scripting for items such as:

• Del.icio.us tags
• Newsblitz
• Feedburner

Aesthetically, I think it is a little easier on the eyes though I'm annoyed that my name keeps wrapping but I can let that slide.

For my next set of posts, I will be focusing on the tasks that a Business Analyst will be expected to perform during the different activities that occur in a system development life cycle. I am using the word activities rather than phases, because the latter leads people to think of a more waterfall-type of approach.

While there is nothing wrong with that, I want you to realize that when Agile methodologies are employed, some requirements sets will be in the process of being implemented, while others will be in the process of being built, while others will still be in requirements gathering stages. Based on the stage a requirements set is in, different support activities will be needed.

First things first: learn the skill

I was reading a post on Tyner Blain entitled, "Requirements management software will not solve the problem." Scott's point is the use of requirements management software does not mean you will have decent requirements for your project. I agree whole-heartedly.

I have found writing requirements is very different from writing prose or telling a story. Just because you have MS Word or another word processor it does not mean you are a writer. A person could be a writer using a word processor, an old-fashioned typewriter, or even pen and paper. The skills and talent to be a writer do not come from the tools used.
Writing requirements is a skill. And as with any skill, it needs to be cultivated and practised. To help you learn this I have put together a lot of posts on items that will help you improve. After you have increased your proficiency, you will be ready to use requirements management tools to improve your productivity. Note that it will take time to learn how to use the tools properly to gain all of the benefits they provide.

Cultivating the skill
Below are some of my older posts that will help you hone your requirements writing skills.

Tips on how to gather requirements: Understanding the Situation, Requirement Gathering Techniques, Expectation Setting, Time Estimation, Preparation and Words to Look Out For.

Tips for writing requirements: Correctness, Completeness, Clarity, Consistency, Testability, Traceability, Feasibility and Design Independence.

Things to avoid when writing requirements: Ambiguity, Multiple Requirements, Escapes Clauses, Rambling & Mixing, Speculation & Jargon, and Wishful Thinking.