This section is in an early stage and will be changing, yet it is a great starting point for thought and conversation.

There are all sorts of tools and techniques used by Business Analysts and Business Process Engineers. After all my years, I still believe that the simpler, the better. One thing that continually amazes me is that a lot of people will skip many of the good ones because they see them as “too simple” (or they don’t see them at all).

To me, the most important consideration for tools selection is effectiveness in communicating. You can have a really fancy diagram or a super high tech requirements management application, but if it is not easy to use and understand, you will alienate your internal business people and suffer greatly for it.

Additionally, you have to ask what makes the most sense for communicating with the development team? Since developers are largely visually-oriented like everyone else (but in their own way), then going overboard on the verbiage is a waste of time – unless you think they will actually read every word of a mega document.

Following are some samples of documentation I have found essential in the course of my work. I call them “tangibles”. Whereas a “deliverable” is something that is formally required by the PMO in complying with the project charter, a tangible is something just as valuable and useful, except is not formally required. In fact, many times the producing of a tangible is necessary in order to achieve completing some deliverable.

Early in the initiative or upon the BA’s arrival, there are lots of ideas flying around, and they are always being changed. It is very difficult to document and explain them clearly. During the first several weeks, I prefer to use a basic mind map to organize my thoughts. Here is an example of a mind map depicting the identification of an organization’s business process areas.

Here is an example of a proactive communique when there is a challenge in getting requirements from an SME. (Also, it is wonderful when your boss agrees!).

Understanding the business processes and how they relate is essential to properly capturing, interpreting, and representing the requirements. Just as “a picture is worth a thousand words”, so is a process flow worth thousands of dollars in terms of quality and project expense – not to mention all those words. Sometimes I think of a process flow as a visual use case.

Documenting requirements statements can be done in a variety of ways. Typically people do it in either Word or Excel, or migrate it from the latter to the former. However, on a recent project I have been using an MS Access Requirements Database. It is invaluable in accommodating traceability among requirements statements, use cases, mockups and visuals, test cases, issues and action items, defects, artifacts, release schedules, and anything else you are tracking and want to easily cross reference and report on.

One requirements management applications that I really like is Caliber RM by Borland. But, MS Access can help out in a lot of ways, though it definitely has its shortcomings.

Requirements DB Report example – This is a sample of requirements relating to a specific use case, also showing the related wire frames, and the various statuses of the different elements.

Use Case Map Example

Functionality Task Analysis Grid example (not created by me) that uses a little story with scenario variations to represent functionality, much like the use case map, but graphically aesthetic and marketing person-oriented.

Here is a Process Flow with Data Annotations. The lead developer on this project preferred a single document versus separate requirements and diagrams. For all the different complex variations, I used a simple flow of decision points versus a matrix. The developers found this easier to design and code from.

This Executive Summary that I wrote was used by my boss and his superiors to champion the cause of the project.