I created the diagram above (click the image to view full-sized) a long time ago (and updated it on 2012-06-04). I included it in a slide deck I was presenting to describe and clarify the BA role in the context of the organization. My intent with the graphic was to convey the notion that the business analyst’s output shouldn’t be seen simply as a specific document or set of documents in which “done” is defined as having completed all the sections of a canned template. I wanted to show that there are lots of common components which might be part of a good requirements model. I also wanted to emphasize that a good requirements model typically doesn’t need all of the above. In fact, trying to include too much can lessen the communicative value of a requirements model.
In my view, “a good requirements model” consists of whatever combination of textual requirements, visual models and other pertinent information is required to effectively capture and communicate (ideally recap) scope and requirements. Templates may come in handy, and in some environments, one project’s model may may be very similar to the next, but we don’t want to constrain the quality and content of our requirements to fit a cookie-cutter format.
I’m convinced that there is no perfect, fits-all template or set of documents which will be effective across all companies or even for all of a given company’s projects. The business analyst should work with internal and external stakeholders to determine which communicative tools will best serve for each project effort and model requirements accordingly.
You can view the full-sized image by clicking on the one above, and I’ve posted the original Visio (2010 format) for the diagram in case anyone might have use for it to reuse, tweak or re-purpose. Hopefully it will come in handy for a few of you. I’d also be appreciative of any feedback you may have on the content or format of the diagram.
Hello,
Very aptly explained with a model. Many people think that a BA understands the problem, does some magic and deliver tools or solution.
Regards,
Sudhi.
Thanks, Sudhi. You’re right, it’ seems to be either the “magid” or the notion that “requirements” is filling out forms x and y, which is always the same for every project.
This is a very useful diagram. Depending on your viewpoint, you could add further lines connecting the various shapes, but this would ultimately complicate the diagram and proabably detract from its visual simplicity and original purpose. I am preparing a presentation on development of user specifications/requirements and would love to make use it. Thanks very much for sharing. Regards, Nan
Nan, thanks for the comment. My line of thought was similar to yours. There is more I could illustrate, but I wanted it to be simple.
I am glad that you’ll be able to make use of it for your presentation!
Great insight! I recently started at a company that has these exact “cookie cutter” templates you mentioned, and has an entire QA team to review (and almost constantly fail) them upon completion. Any advice to initializing the steps to getting this process to change? It really can be a burden to the overall requirements process.
Thanks for the kind comment, Joe.
I’ve had the same experience. I hate to say “it depends”, but it really does depend on the openness of the organization to try something a bit different.
When I was faced with a similar situation in the past, what got me moving in the right direction was to take some liberty with the existing templates by making modifications to include the ways of communicating requirements that I thought would be most effective for the particular effort.
I found that if the materials I presented were actually more appropriate and intuitive for helping document consumers to understand the requirements than what came “out of the box” with the template, they would generally buy-in.
In another case, I simply asked if I could take a shot at doing requirements a different way to see how it worked. I told my team that if, after I tried things my way, they still preferred for me to fill out the old template, I’d do it.
The most important thing is to help the team understand that the way you add value as a BA is not in “filling out the template(s)”, but in creating shared understanding among stakeholders of what is needed for a solution to be successful. Because every work effort is different, you sometimes need to model requirements in different ways in order to create that shared understanding. If you can get that across, you’ll be well on your way.