Business Analyst Times

How many times have you been in a meeting discussing a set of requirements, a methodology, or a project plan etc and someone has gotten up from their chair and said "where's the whiteboard let me draw what I mean"?

I can tell you for me it has been plenty!!!!

Whilst requirements specifications are a great way to document the detailed information related to a new or existing product's functionality we all live in a time poor society and few of us have the time to trawl through large documents and extract the information we need and then start the seemingly endless e-mail threads to discuss the individual use cases associated with each requirement consisting of many messages that start and end with "what did you mean by X?", " I meant X and Y but I think you thought I meant Z!" Instead why don't we adhere to the adage of a picture tells a thousand words and instead of page after page of documents create a visual representation of those requirements - hopefully communicating a thousand words in a single picture.

However, what we must remember is that visualization of requirements can vary in its meaning. For example, some people may view requirements visualization in the same context as simulation diagrams, whilst others interpret visualization to mean simple use case diagrams or business process flows typically created in a MS Visio type tool. For me, all of these usage contexts can represent visualization, so instead of trying to classify visualization into one genre I thinking it is best to view it on a scale with simple flows at one end and high end simulations at the other - and the user selects which method is most appropriate for them at any given time. For example, if you are trying to show how a user will move through an application to make a purchase then using MS Visio to define process flows may be enough. However, if you are trying to envisage how a new UI (User Interface) may look then mockups and more rich content visualizations would serve you better. Whichever method is selected there are a number of benefits that come from visualization these include:

• Flexibility and Usability - flow diagrams can be easier to navigate helping to find content
• Mistakes can be easier to identify in a visualization
• Easier to identify potential parallelisms between requirements and business processes
• Easier to spot missing Use Cases in business process
• Increase understanding of the requirements themselves
• Increase understanding of the dependencies between requirements
• Visualization of business flows can provide a first bridge to Business Process Models or SOA repositories

Now that we have explored some of the benefits of visualization the question now becomes when should it be used? Should we visualize every requirements we write or just some and if we are going to be selective which requirements should we chose?

In my opinion there are a number of questions we can ask ourselves which can help to determine when to and when not to visualize. These include (and there are many more):

• Type of development method - we need to ask ourselves the question do requirements visualizations fit in with the need for more agile and rapid requirements definition or will they add more time to the development process?
• Complexity of the requirement - if a requirement has too many sub requirements will this create a "spiders web" diagram which may overcomplicate the definition of the requirement?
• Type of requirement - should we visualize the user story only and define the functional requirements associated with this user story as text or do we want to visualize all requirements?
• Risk level of the requirements - should only high priority or high risk requirements be candidates for visualization?

It is important to note that I am not saying that requirements visualization is a "panacea" for enabling effective business and IT communication but what it will do is act as a good facilitator to help initiate a better degree of communication and understanding between the two parties.

So now the decision is yours. Why not try visualizing requirements and feed back to the group how things go.

Genefa Murphy works and blogs with Hewlett-Packard where she is Product Manager for Requirements Management. This article first appeared in HP Communities.

© Copyright 2009 Hewlett-Packard Development Company, L.P.

Comments (14)

Subscribe to this comment's feed

...
written by lilydang, May 19, 2009

Thanks Genefa Murphy for writing a great article on the requirement visualization. I have been using this technique so many times in entire my BA career. It's extremely helpful when we want to communicate to off-shore developers.

• 
• +0
• 
• 

...
written by mbajt, May 19, 2009

I've tried to use a combination of visualization and traditional text based approaches when it comes to requirements and have generally found this to be quite successful. Business users on the receiving end of requirements that must sign off appreciate not having to read through endless pages of written specifications and the downstream consumers of the requirements (e.g. systems analysts, developers, etc) also find visuals a useful component of the requirements specs. Visualization can be particularly powerful at the outset of the requirements gathering process when concepts may still be somewhat vague in a users mind; starting off with a visual and then supplementing with text for items that are concrete is a great way to build the requirements on an iterative basis.

• 
• +0
• 
• 

...
written by rforsberg, May 19, 2009

I have always been a very visual person - my office is filled with drawings and diagrams and chicken scratches. For me sketching is short-hand.

A picture can truly tell a thousand words - and in multiple languages. Static prototypes aka mock ups aka wireframes or whatever you want to call them are indispensable tools for me - assuming the usual high-level project objectives are in place.

For example; User Interface, functional and data requirements are quickly and effectively communicated to a variety of stakeholders - technical and non-technical alike. DBAs can see the data requirements and relationships implied by the screens and forms. Application developers can easily see the data and system functionality required by the choices of form controls and labels that are displayed. The client / users can see the workflows (use cases) and glimpses of the end product.

I also find that these illustrations help to minimize the dreaded tech-talk that finds it's way into meetings where text-based requirements are being interpreted by technical folks - sorry tech guys. Yes - this is that awkward part of the meeting everybody loves so much.

In my humble opinion - static prototyping really works well for eliciting, confirming, validating, and communicating system requirements in a quick and effective way. For me it is a universal way to describe with a fair amount of detail the functional, data and UI requirements of a system - it's all there - in a very concrete illustration.

Moreover - if done well - much of the UI work gets a head start as this deliverable can form iteration 1.0 of the actual UI design. And... the clients get confidence in the team as they see what appears to be actual system development phase work being done early in the project.

Enough from me. I could go on but I am sure my excitement for simple drawings is wearing thin about now.

Great article.

• 
• +0
• 
• 

...
written by Genefa Murphy, May 19, 2009

Thanks for the comments – it’s great to see that requirements visualization is live and active in the BA community – I believe that there is definitely great value to be had from using multiple elicitation techniques in conjunction with one another – and it definitely helps break down the communication barriers!!!

To read my other blog entries on RM and blogs on other topics here’s the link for the HP communities’ site: http://www.communities.hp.com/...fault.aspx

Thanks
Genefa

• 
• +0
• 
• 

...
written by gcuenca, May 19, 2009

A very good article indeed. It highlights the point about the business usually not having the luxury of time to actually read pages and pages of documents (let alone read the e-mail where those documents are attached!) when in fact the content may have been more effectively presented using a graphic or a diagram. And even if they do have the time, they sometimes get lost right in the middle of it which leads to assumptions being made or completely misunderstanding what is being conveyed. At the end of the day, however, it is really up to the BA and his or her familiarity of the audience which will help determine what medium will be the most effective.

• 
• +0
• 
• 

...
written by Riz, May 20, 2009

Very informative article Genefa and yes I do agree with you visualisation really help the BA to define the complex requirements and work flow in an easy way. This is also useful for the stakeholders to understand how their process is going to be developed and that will be the work flow.

Cheers,

Riz

• 
• +0
• 
• 

...
written by aliqa01, May 20, 2009

Thanks Genefa for highlighting the power of visualisation. Since, I am a visual person I do try to include diagrams like; Context, Swimlane, Use Case and WBS in my documentation and I can tell you it's usually well recieved by the stakeholders and makes my life simpler when I do walkthroughs with business or technical primes.

Fish bone analysis is yet another great visual tool for doing problem analysis and brain storming.

Once again thanks Genefa for writing this article, this gives fresh ideas on how to write better documentation

Regards,

Syed Ali

• 
• +0
• 
• 

...
written by gkinne, May 20, 2009

Yes, good article. We have used Visio to do a mock user inteface to get the ball rolling for look and feel of the program.

• 
• +0
• 
• 

...
written by reynardb, May 20, 2009

Great timing of this article. I am a new BA, being a developer and systems analyst for most of my carreer. I am still struggeling to find a standard for myself (and the company). I love using visuals and hate typing long req. docs. I still do not really know which visuals is the best to use. So far screen mock-ups has had the best impact on my stakeholders in my last 2 projects (Audit Department & Store Ops). So I will continue using this method (and some long lists of req, that are hardly ever read).
Must say, I get most of my insight from guys like you on these blogs...thanks

• 
• +0
• 
• 

...
written by 5ToolGuy, June 04, 2009

Hooray for visual modeling of requirements.
I agree it makes it easier to spot missing use cases and flows. It is also great for feeding the developers to realize the use cases and class diagrams.
A few years ago the tools available limited fulling realizing the value, but now that some things as simple as spell-checking are included make it the best of both worlds.

http://www.linkedin.com/in/scottpollino

• 
• +0
• 
• 

...
written by cclloyd, June 10, 2009

Excellent article. I would love to see some examples of requirements visualization in action. Would you be able to provide or suggest places to see some good examples?

Thanks!

• 
• +0
• 
• 

...
written by A M, June 10, 2009

Totally agree that requirements visualisation is necessary and I use it myself a lot. It is important to remember that a combination of diagrams and text conveys more than each by itself - Business rules form an important part of requirements and have to be documented as text.

• 
• +0
• 
• 

...
written by rakesh300, June 17, 2009

Thanks Genefa,

I've came across several PM in my career and most of them appreciate the visual diagrams however, some simply ask me to avoid it as they think that it contains half information and is time consuming.

I genreally avoid the diagrams my self as mostly our requirements gathering time limit is most minimum and we need to cover the requirements in it entirety. Also sometimes when we document the spec with diagrams, the stake holders expect us to have it for all other processess as well.

Is it in the hands of PM, System Analysts and developers to decide on where we need to provide diagrams or does the BA have rights to limit on the diagrams? A question I still have no clear idea.

Please comment.

rgds,
Rakesh

• 
• +0
• 
• 

...
written by ronp, August 25, 2009

Nice article, Genefa. Being able to key in to how members of your team best consume information is an important skill. Some people are "word oriented" and others think visually. A lot of us are somewhere in-between and need some pictures or diagrams to set the context for the more weighty stuff.
I'm preaching to the choir, of course, when I point out that diagrams and other visualizations tell part of the story but not the whole story (just like text in a document doesn't tell the whole story - can you imagine describing what a GUI is supposed to look like using only text?!?). There are myriad non-behavioral requirements in any system that need to be documented and explained in more precise terms.

• 
• +0
• 
•