News Stay informed about the latest enterprise technology news and product updates.

A modern way of gathering requirements: Visualizations

If a picture’s worth a thousand words, a visualization’s worth a thousand pictures. A “visualization” is a term used to describe a functional software prototype.  This form of rapid User Interface (UI) prototyping is now being used by business analysts as an effective method for gathering customer requirements.

In the software development lifecycle, it’s the business analyst’s responsibility to work with business stakeholders to determine the requirements of a software application. There are many ways that this can be done. Traditionally, after many long meetings and countless interviews, a big, thick requirements specification would be written, attempting to describe the requirements of the system.  This would then get passed to a design team who would create a functional specification which developers would ultimately use to write code. The end result would be an application that often looked very different from what the business had originally envisioned.

Some reasons this approach leads to an end product that can be so different than what the business wants are:

  • It’s difficult to describe exactly what you want when you don’t have a starting point.
  • Requirements can change over the lifecycle of a product.
  • The details of what the business wants need to be continually clarified as the project evolves.
  • It’s much more difficult to describe a user interface and functionality in words than it is to work with the actual screens.

These problems are some of the reasons the waterfall methodology has gotten such a bad rap and why so many people are switching to an agile methodology. It’s become recognized that more effective collaboration and communication with the business is required in order to accurately understand exactly what business users want.

But switching to an agile methodology isn’t the only solution to this problem. Another technique that is being used is to gather requirements using visualizations.

SearchSoftwareQuality met with iRise leader Mitch Bishop last week to discuss their product line.   Their tools are meant for the business analyst, not the developer.  Working with the iRise applications, business analysts are able to collaborate with stakeholders to create working models, going beyond mock-ups or wireframes.  Visualizations can be integrated with data to provide an actual functional preview of a finished application.

A quick search revealed this informative blog post listing 41 prototyping tools that can be used for rapid UI generation. iRise was included in the list, described as “A very complex tool used to model business process and prototype application interfaces.”  It’s not surprising to me that the tool is listed as “complex” as it does allow for quick prototyping for a variety of product types including Web 2.0, mobile applications and SAP Extensions across several industries.

Being the devil’s advocate that I am, I asked Bishop whether the problem they were trying to solve was already solved by the trend of agile teams. In an agile environment, the product owner works on the same team as developers and testers, producing functional code in short sprints. This cross-functional team addresses the improved collaboration and communication with the business and allows for the continual product review throughout the lifecycle.

Bishop answered that rapid prototyping tools can be used in an agile environment as part of the short sprint. He’s finding that all teams, regardless of methodology, are effectively using visualizations to help better define requirements.

It’s good to know that the industry is finding effective ways to gather requirements. Let’s hope the days of thick requirements specifications are quickly coming to an end.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Prototypes are not new by any means. The problem with relying on prototypes is that you begin with an assumption of what the system should do (I want to click here and do that), instead of understanding what the system should do to meet the business and user needs. Getting to the answer does not require a thick document; it does, however, require modeling skills that many business analysts simply do not comprehend. Visualizations can be helpful, but in the long run they can cause more harm than good if the underlying data model and system requirements have not been adequately, robustly, and flexibly defined.
Interesting point of view, Joyce. As a former developer, I was very familiar with prototyping. However, I've never worked in an environment where the business analysts used visualization tools to describe the requirements. Ultimately, it would probably be best if a cross-functional team were involved in requirements gathering, including the developers. I asked the folks at iRise about this and they agreed. I'd love to talk further and hear more about your experiences. If you're interested, please feel free to contact me directly at Perhaps a follow-up to this post with the alternative point of view is in order.
I think Joyce touched on one of the major challenges in requirements gathering: getting stakeholders to concentrate on what the SUD has to do, rather than how it does it. So many times my stakeholders are enamored with a trendy tool ("We want it to be like Facebook!") or they're fixated on a specific feature or technology. Remember when frames were all the rage? When I'm gathering my requirements I try to extrapolate from my elicitations what the user really means as opposed to what he/she actually says. I also try to avoid getting too specific in the "how" because I like to see what potential vendors will come up with. The iRise tool sounds interesting, though, and I will certainly check it out.
Hi Garry, Thanks for your insights! Bridging the gap between the "What" and the "How" can be a major challenge. We are looking at doing more coverage on the Requirements gathering process. I welcome you, too, to contact me at to speak further or contribute to a future article or blog post on this topic.
For Prototypes, I agree with Joyce, although I have used them in special circumstances. Storyboards (Visualisations), provide a less deep visualisation, and they are better. Firstly, they are quicker to produce, which is good for agile. Secondly, they allow people to look more closely to the 'What' and NOT the 'How'. They must look 'Wire Framed' otherwise the Business start refining the screens rather than listening to what they say. A mix of very high level use cases and very simple Domain Model in UML, when properly presented to the Business is quick, precise and 'What' focussed. I prefer this, although MOST analysts do NOT understand what a Use Case is or what the Domain diagram should show. With education, this is a winner in my book. An interesting variation on this level analysis is BDD (Behavioural Driven Development) which is being fostered by Liz Keogh. See Wikipedia BDD. It focuses more on the user's behaviour and NOT just on what they see. Yet it is NOT a prototype. By the way, I did my first 'Visualisation' presentation in 1970. I hope that includes me in the 'Modern' frame. Gil Gil
Great commentary! Well, perhaps I'm just behind the times. I was in software for 27 years and had done plenty of prototyping, but had not been aware of "visualizations." In talking to iRise, it appears their software provides much more that story boards or wireframes. They integrate in the data a visualization that includes working business logic. This seems to be sparking some interesting feedback, so definitely worth some more exploration! I really appreciate the insightful comments. Keep it up! And Gil, I offer you the same deal as the others: email me at if you'd like to chat more or be quoted for a potential follow-on story. Thanks for the great discussion!
Thick requrement specifications have their place - you have to capture the detailed business rules somwhere. I've been using non-functional prototypes since the 1990s, so they are not particulalry new. I think they have their place once you are talking about detailed systems design, but there is usually a lot of upfront business analysis to understand the business problem. It is dangerous to dive into the detail of screen design, though if you are changing an exisiting system it may be appropriate. I like Balsamiq's mockups for protyping as they are loose and sketchy, easier for the business to challenge and don;t give the impression that the sysyem is already built!
I love the dialog and participation here! So I have a question for the group. We've established that prototypes are not new, but are "working visualizations" new? When I was a developer, we used IDEs to build a quick working prototype... often the prototype code would be used as a base to build the end product. As a developer, it was easier for me to design a system and figure out how I would implement the requirements by building a prototype using the same platform. This is different. These are tools used by business analysts, but they do produce a working prototype. However, they do not generate code for the developer. The developer needs to figure out how to implement the prototype using whatever code they do their development work in. I question iRise about this, thinking that might be very difficult for the developer. I thought it would probably be impossible for the development team to code something to the exact requirements unless the visualization code could be migrated or used in some way to create the shell of the application. iRise assured me that developers were able to create the code that matched the prototype and have much more clear requirements, thanks to the visulaizations. I'd really like to delve deeper into this and it looks like there's interest from this group. I'd encourage you to keep up the dialog and, again, feel free to contact me for further comment at
I must concur with Joyce and the other postings that have followed on his/her comment. While rapid data-enhanced prototyping ("viusalization") can be extremely powerful in quickly reaching consensus and setting proper expectations, it can be very dangerous to rely on the users/stakeholders for the design of the user interface and functionality of the system. Along the same lines, I also firmly believe that Agile (particularly SCRUM) is fundamentally flawed in that the method depends on developers and stakeholders to make decisions about how the system will function. Often, neither group is well-versed enough in usability principles to properly make the necessary concessions to produce a usable and efficient end product. And, as many have pointed out, the resulting product may also not be properly informed by business needs. Any of us who used to subscribe to the principles of JAD sessions ten years ago, or have relied a little to heavily on focus groups, know that user centered designers and business analysts are critical to a successful outcome. There must be some middle ground to the requirements/design conundrum. Getting designs directly from the users or directly from the developers is not the answer. That said, I also would like to hear how iRise, and other folks who rely heavily on prototyping for requirements, manage their requirements changes. How do you measure and control your churn once your product goes to O&M? How do you manage traceability and analyze potential impacts when the product is very large and complex?
Hi Ashleycook38, You bring up another interesting point: "it can be very dangerous to rely on the users/stakeholders for the design of the user interface and functionality of the system." It sounds like you are saying the user interface should be designed by "user centered designers," a term I hadn't heard before. (Boy... 27 years in the industry and I'm still finding all kinds of things I didn't know!) In my opinion, for every person you ask, you will get a different opinion of what the best user interface is. Whether you ask users, stakeholders, product owners, developers, or "user centered designers," you will probably get different answers, with no one being right or wrong. We are all different in our opinions of what type of user interface we think is best. However, when working on a project we do need to move forward with a software product and assign someone (or some group) the responsibility of making decisions about requirements. The point here is that discussing using a visualization is much easier than discussing a large technical document. If you were to describe a new color to someone, you could do it with words, but it would be much easier to just show them that color so they would know exactly what you were talking about. All that being said, there are some very interesting points of discussion that have been brought up in this thread that are worthy of follow-up stories or articles. I thank you all for so clearly articulating your opinions and once again welcome you to contact me at if you'd like to be further interviewed for a potential follow-up story.
This is a great piece. Great feedback all around. I love this topic. We've been using Visualization as a method to elicit and document software requirements for over 5 years now. I think the thing to remember about Agile, RUP, Waterfall and the myriad of other methodologies is that they are [I]development[/I] methodologies. While requirements are part of the work, it's relatively small. The fundamental problem with software requirements is the lack of clarity. Written requirements are difficult to read and mentally process. They introduce all sorts of ambiguity. And no one ever spends enough time on the requirements phase. It's important not to confuse visualization with wireframes, storyboards, use cases, etc. With visualization, stakeholders can not only [B][I]see[/I][/B] their requirements, they can more importantly [B][I]experience[/I][/B] them. There is nothing left to the imagination. No one has to "guess" or "assume" what a button or widget on the page does, they can actually click and interact with the visualization. Everyone is in sync with what they are asking for and what they are getting. The comparison of visualization to prototyping is a good one, but there are two major distinctions. Prototyping is typically done late in the requirements process (or at the beginning of the development process) and is done with development resources. Visualization, when done properly, is done very early in the requirements process and helps business stakeholders to visually think through their needs and wants. Visualization can be done using business resources such as business analysts or user experience professionals. We begin visualizing requirements within the first few hours of a project. In fact, we just got back from a three-day session with a client where we visualized 17 scenarios, 60+ pages and documented 100's of requirements. And this was the project kick-off. Fixing a requirement problem early is a lot less expensive in cost, time and morale than if discovered late in the process. The classic stat is that if you spend $1 to fix a requirement early in the process, that same fix would have cost you at least $100 if caught during development. Think about most projects. When stakeholders experience a project for the first time, it is either at the prototype stage, QA testing or user acceptance testing. Most of the time, the stakeholders have some (or many) issues with the software that will require costly rework. The cause was either poorly thought-out, ambiguous or incorrect requirements, Effective use of visualization moves this to very early in the project where it can be dealt with cost-and-time effectively. We have carefully developed a methodology around using visualization for requirements. In fact, our entire company is founded on the principle that visualization is the most effective for requirements gathering and management. Chuck Konfrst Senior Visualization Designer/Director, Branding & Communications OneSpring
Hi Chuck, Thanks for your contribution. You sound very knowledgable on the subject! I'm off to STAREast this week, but when I return, I'd love to follow-up and do another piece on this. You sound like you'd be an excellent resource! Thanks!
Chuck - You hit my nail right on the head! I am a user centered designer by trade and a requirements manager by practice. We try to introduce wireframing and storyboarding in the process as early as we can to support exactly what you describe. It would be fabulous to also utilize visualizations there as well. I would love to hear more about how you document and manage the requirements that come from your cycles. My initial point, which was not very eloquently or effectively raised, was that visualizations are valuable but not the only documentation necessary for proper requirements management. Yvette - I would be happy to be further interviewed for other articles. There is a very robust community of UCD (user centered design) professionals who advocate, with metrics, practices that produce usable and pleasurable user experiences. But, you are correct, "best" is in the eye of the beholder.
AshleyCook38 and others, I'm preparing now for my follow-up feature article and would very much like to interview any of you that might be willing. Please contact me at if you would like to contribute your thoughts. Thanks! Yvette
Great article by the presenter and wonderful discussions by followers. Appreciate your feedback to improvise my knowledgebase and hence i am here and putting down my two cents... (Yvette, though i am not as experienced as you all others... perhaps, the thinking makes me stand alone is...) a) When we talk about Requirements, user's stories and blah blah, its important to identify the Requirement Life Cycle as equivalent to SDLC or Testing Life Cycle. I Used in my recent project which was similar to the techniques of Requirement Based Testing and found that the stakeholders were more happy for such innovative ideas b) As parallel to RDBMS, i feel the need of understanding 'Relational Requirements" takes us to more perfection comparitively... Make sense ??
GopalSrBA, thank you for joining in the discussion and adding your insights! I'm working on a feature article and we hope to get more content on Requirements on SSQ. Clearly, this is an important part of the lifecycle that deserves a lot of attention.
My feature article, [A href=",289142,sid92_gci1515961,00.html"]Are visualizations the answer to gathering requirements[/A], is complete. Thanks to all of you for your insightful questions and comments.