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

Are visualizations the answer to gathering requirements?

Requirements elicitation is one of the most challenging parts of software developments. By using visualization software, business analysts are able to create working simulations to gather customer requirements. Vendors, analysts and users give their thoughts on the benefits and challenges of using visualizations.

It's no secret that gathering business requirements can be one of the most challenging parts of a new software...

development project. It's difficult for business users to describe exactly what they want in such a way that the end product will be exactly what they pictured. Some development teams are finding relief from these problem in new visualization technologies; but others warn that new technologies can only aid and not replace traditional requirements gathering methods.

Last month, SSQ interviewed some leaders at iRise about their visualization software, and how it's being used by business analysts to create working simulations, allowing for a visual way of gathering requirements. The subsequent blog post that was written on this topic sparked some interesting conversation and debate. Is gathering requirements in this manner dangerous, emphasizing the user interface (UI) over the business rules? Will such tools replace more traditional modeling techniques? What are the benefits and drawbacks? Users and experts weigh in to answer these questions and give their thoughts about the effectiveness of this technique used for requirements elicitation.

What is a visualization?
First we need some clarification on what is meant by the term visualization, and how it differs from prototypes or storyboards. Prototypes are typically quick applications written by the development team. Often, prototyping is done after the requirements are gathered, when the team is trying to get some additional input on the user interface from the business folks.

Visualization differs in that it is used very early in the application lifecycle, during the requirements stage. Tools are used which will create an application similar to a prototype; however, it's not the development team that creates this simulation and no coding skills are necessary. Business Analysts (BAs) or User Centered Designers (UCDs) work with end-users or stakeholders to determine the requirements using the visualization. This is different from a storyboard, because these visualizations can actually be integrated with real data, creating a hands-on, working simulation.

Benefits
Gathering requirements using visualizations allows for a working discussion of details that would typically take an incredibly long time to document and review. Furthermore, the earlier in the application lifecycle that defects can be resolved, the more cost-effective the project. "An error found during the coding process typically costs 10 times more to fix than one found and fixed at the requirements development stage," writes Barry Bohem in "Software Engineering Economics." Project teams are finding that they are able to collaborate more effectively and easily change requirements by using visualization software.

Theresa Lanowitz, founder of analyst firm voke inc., describes the importance of requirements when she says, "It is clear from the amount of failed applications that requirements definition is an area that requires attention. It is far easier to visualize a requirement than search through large documents and interpret what something should look like. The goal of each and every software project should be to get requirements right from the beginning. If requirements are not correct from the beginning, there is quite a bit of rework involved and rework is just another word for patch. Requirements are the central foundation to all software and software is central to running the business and keeping the business competitive."

Keith Pelletier writes on a LinkedIn discussion, "One big advantage is that it is so much more intuitive to discuss the fine points of software using visual prototypes. When dealing with abstract requirements (words), there is a lot of room for visual interpretation. In a sense, everyone is forming pictures in their head anyway. Why not just make it objective by creating a common picture that everyone can point at and discuss."

Sherry Preston who manages a group of 16 Business Analysts at M.D. Anderson emphasizes that visualizations go beyond pictures. Preston said that in the past her team had tried various ways of collecting requirements, including documentation using Excel, Word, Powerpoint and Visio. "You can get creative, but there's nothing like having a simulation that allows for hands-on. We can show [the users] functionality that they're going to get. It helps our stakeholders understand what's going to be deployed."

Her team has been using visualizations for the past three years as a core part of their methodology. "Simulation is required before handing off to our developers," she says.

In talking about the decision to use visualizations, Preston said, "We needed to have an expeditious way of eliciting requirements. We needed it to be quick, visual, and something that [the business users] could interact with; something that would provide good, solid feedback. I needed a tool that could supplement the documentation. It helps with the workflow. You can get the workflow down pat and come back and document requirements. If you don't do the simulation, you're probably going to miss something."

Drawbacks
What are the drawbacks to this approach? It's important for the requirements to be focused on the "what" rather than the "how." Some feel that requirements should state what needs to be done but that user interface design should be left to the development team.

Furthermore, there's concern that it may be premature to create a working model without having been through the design and architecture of the application. A blog comment warns, "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."

Other users note that modeling would be needed to capture business rules or other requirements that can't be gathered through visualization software. Another issue raised was that by using visualization, the business folks might have the impression that the system was already built, when, in fact, the development team hadn't yet begun.

When asked about disadvantages of the approach, Preston, who uses iRise software, warned that users needed to be aware of system requirements, especially memory, of the visualization software they used. "You want to be able to transport your laptop to meetings." She also felt it was important that the staff was well trained in the use of the software and recommended having a couple of super-users that would be able to help the team with complex visualizations.

In an interview with Blueprint leaders, President and CEO David Nyland answers that he felt the biggest challenge was getting the message out and the acceptance of change in the way requirements were being gathered. "Change is always difficult," he said.

Does the use of visualizations emphasize UI design over business rules?
Users, vendors, analysts and experts all agree that the requirements elicitation should be about gathering the 'what' rather than the 'how.' In other words, the requirements should define the features and functions, but not describe how these will be implemented in the code. This criticism is one that suggests that visualizations may focus more on UI design rather than requirements.

One misconception is that visualizations are only about defining the User Interface. Chuck Konfrst, a senior visualization designer and director at OneSpring, says on this point, "We use a highly iterative approach that focuses on the 'what.' Our goal is to clearly and accurately capture what the business wants their software to do. That is not to say we ignore the 'how,' but in early iterations, it is typically not essential to the discussion. Many times the stakeholders aren't even in sync yet on what they want. Visualization gives them the ability to swiftly come to a consensus. This needs to occur before the development team even gets involved so as to not squander their time (which frequently occurs). The development team should be an important part of the entire process including requirements. As we iterate the project definition, we bring in more and more of the development/system/design as needed."

Preston describes the original reluctance of using visualizations from the development team. "Because we have an on-site development team as well as an off-shore team, we rely on the simulation a lot. At first there was considerable push-back from the developers because they thought we were going to be designing the GUI. But we wanted to establish the workflow. We continued to tell the stakeholders, 'This is not how it's going to look.' It's not a prototype. Often it's not what it ends up like.

Overall, there's generally some resemblance, but not a whole lot, because when the developers get it and there are technical challenges, it helps them to have the discussion of what they can and can't do. It gives us feedback from the developers as well. Now the developers want us to do simulations for change requests."

Lanowitz notes that while visualization tools are meant for requirements gathering, UI design can often be ad hoc. She says, "Very few enterprises have a UI designer for their applications. Design today is largely ad hoc, which is problematic. The responsibility of design is a new and emerging constituent within the application lifecycle. Microsoft is taking this role seriously and sees the need for proper design of the application to effectively run the business. The Microsoft Expression Studio is one of the only tools on the market to focus on design. This type of tool should not be confused with a requirements definition tool to visualize requirements."

Will such tools replace more traditional modeling techniques?
The common consensus seems to be that the tools will not replace other techniques, but will augment them. Certainly there are many requirements that still need to be described with the written word. There may be capability to capture written requirements from within the visualization tool. If not, those requirements will need to be communicated as supplemental documentation. Visualization tools also may have the capability to generate documentation that can then be used for review in a traditional manner.

Visualizations are being used in both traditional and agile environments, though Konfrst recommends the use of agile. "While our process works with any development methodology, we try to avoid the waterfall approach," he says.

How does the use of visualizations compare to use cases, storyboards, wireframes or other more traditional methods of gathering requirements? Konfrst says, "The bottom line is that all of these lack the ability for stakeholders to truly experience their requirements. You cannot deeply interact with any of these. With visualization and our process, you can actually interact and experience your project requirements."

The importance of setting expectations
Another area in which all parties seem to agree is the importance of setting expectations with the stakeholders. Preston says, "We set the expectations up front. Because it looks so real, we have to remind people that it's just a simulation. Our director was clear that the expectations must be set that it wouldn't always look like the simulation. It has helped tremendously for our user group because they can see it in their mind. It makes it so much easier for them than looking through pages and pages of documents. It's so much better. Most of the time, the development team has made it better."

When asked whether or not stakeholders had a false sense of ease of development by seeing a working model before development was even done, Konfrst answered, "There is a small danger of this and certainly something we encountered five years ago when we first started using visualizations. However, it was quickly solved by simply setting the proper expectations. Because of the way we conduct our projects and that the focus so much on the 'what,' it is never an issue anymore."

The consensus
Overall, vendors, project teams and analysts that have used visualizations are in agreement about how to use them to elicit requirements successfully. Keep the visualizations focused on the 'whats,' set appropriate expectations and use the tools to foster more effective communication and collaboration between all project members, including development, BAs or UCDs, and end users. While visualizations will not reduce your written requirements to nothing, it appears to be an effective method of gathering discussing and refining them, allowing the end-users to focus on giving input in a way which will reduce defects and enhance team communication and collaboration.

Dig Deeper on Software Usability Testing and User Acceptance

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close