I was asked a few years ago by a project manager to outline the process I follow to gather and communicate requirements for projects. After some thought I came up with an initial version of the diagram below, and over the years have refined it as new techniques such as User Stories became more popular.
This diagram shows the primary activities I perform as a Business Analyst in support of IM/IT projects, and the typical order in which these activities are initiated. The arrows do NOT indicate a waterfall approach. I revisit each of these activities throughout the life of the project.
Depending on the complexity of the project, the amount of existing material for reuse, and the experience of the Business Analyst team, a project team can choose to risk* skipping several of the initial activities to start working on the IM/IT solution sooner.
*Risk: Skipping the earlier activities often leads to an increase in the amount of rework that needs to be done by the IM/IT solution provider, essentially removing the assumed benefit of an earlier start.
The diagram shows the 3 main branches of work I find myself doing as a Business analyst in an information based organization:
- Models and catalogs for the information being consumed, created and managed by the organization (activities 6,7,8,13)
- Models and catalogs for the services, process and activities that that process that information (activities 10, 11, 12, 16)
- Requirements management in general, where I maintain traceability, and capture my work in a way that facilitates reuse from project to project.
Through out all of these steps I’m interacting with the other team leads, contributing to plans, and all the other generic responsibilities I have as a member of a project team.
I’ve decided that this diagrams and the activities it describes would be a effective way to categorize the contents of this site, so I’ve mirrored this blog entry as a static page that I will update as I add more content to this blog.