The word "gather" does not truly communicate the nature of the Business Analyst's (BA) job. You do not gather requirements-they are not just lying around on the ground waiting to be picked up.

The word "elicit" more closely matches the job, because it connotes a more active role for both the BA and for those with whom the BA works. The dictionary defines elicit as:

1. To draw forth or bring out (something latent or potential)
2. To call forth or draw out (as information or a response)

There are many ways to elicit requirements from your stakeholders. A BA should be proficient in all of these: interviews, workshops, focus groups, brainstorming, observation, and surveys/questionnaires. While all of these methods involve three basic parts: preparation, conducting, and follow-up, they do have differences.

We've all used the swim lane diagram. It's simple and easily demonstrates a process, but I've often thought it could do more. When I document a business process, I want to show more than just who is doing what; for example, indicating which systems they are using, what kind of data they are updating, and illustrating a wider picture of the process. These are all factors that render significantly improved results and refined clarity. In this article we'll look at some ways we can take the basics of the swim lane diagram and add some heightened functionality.

Please click on any image to view an enlarged copy

This article is a continuation of the "Reinventing the Swim Lane Diagram" process. Part 1 concentrated on ways to increase the efficacy of the swim lane diagram. Methods such as using color in a sparse and efficient manner, clearly defining each color's meaning, and the induction of labels and annotation led us to realize to a more profound exchange of information.

Before we start Part 2, let me take pause to respond to some of the feedback from Part 1.