The essential role of communication among all parties involved in a software development project is clear. Equally clear: the power of graphical models and similar visualizations to enhance communication. More problematic are questions of deciding what kinds of visualizations should be used, at what point in the development process are they most useful, and do automated visualization tools add value?
A a recent article in Computerworld, Visualize First, build later: the advantage of simulation tools, by Esther Shein advocates comprehensive use of an automated visualization tool early in the development process. This position is consistent with traditional, waterfall-like, development methods. A recent webinar Leveraging Requirements Visualization – A Biotechnology Company’s Agile Case Study, offered by Susanna Goldenstein, suggests that the use of a visualization tool, but using a non-traditional (agile) method, is also highly effective. Both the article and the webinar talk about the same automated tool, iRise, described as "an enterprise visualization platform used to quickly assemble working previews of business software that mimic the exact look, feel and behavior of the final product."
The Shein article suggests that the use of automated tools that visualize user interfaces, model business processes, and simulate user interactions are held to be superior to more common tools, like spreadsheets, that capture long lists of system requirements in primarily textual form. Goldenstein's webinar implies that visualization tools are a necessary enhancement of, or replacement for, story cards as a primary agile communications tool.
Shein quotes Melinda-Carol Ballou, an analyst at IDC in Framingham, Mass on the importance of good requirements, particularly in today's economic climate.
The challenge that business stakeholders face in trying to communicate their requirements to software developers isn't a new problem. But dealing with that challenge has become more critical in the wake of the economic downturn. With increasingly scarce resources, there isn't any margin for error. So if there's a disconnect between what you create and what the business actually needed, the costs of failure are more pronounced. When you're visualizing requirements and looking at a screen, it gives users something tangible" so they can see what "something means in physical terms.
Being able to capture better requirements should, Shein suggests, also address the well known problems of "challenged" and "failed" projects.
The Standish Group reports that there was a decrease in project success rates from 2006 to 2008. ... In 2008, about 44% of projects were late, over budget and/or came in without all of the required features and functions [challenged], and 24% failed and were canceled prior to completion or delivered and never used, according to Standish. In 2006, the failure rate was at 19%.
If requirements visualization tools can improve this situation, their value is obvious. To what degree does this kind of tool actually help? A lot of people believe that such tools are essential. iRise is but one example in an increasingly crowded market. Some alternatives mentioned in the Computerworld article include:
- Blueprint, a CSS framework
- RavenFlow offering a visual requirements definition software designed to parse English-language text to structure requirements.
- The Blueprint Requirements Center provides a foundation for defining requirements including business process diagrams, use cases and UI mockups.
- Microsoft Corp.'s Visual Studio 2010 Ultimate and its Expression SketchFlow product, offer several tools for visualizing requirements and "storyboarding" application interfaces.
- IBM offers its Rational Jazz platform, which includes the Rational Requirements Composer to helps teams define and use requirements effectively across the project lifecycle.
These kind of tools provide ways to graphically depict user interfaces, simulate user interaction, and graphically model business processes and logic.
As Shein noted, the capture of complete, accurate, and unambiguous system requirements is not a new problem. Fred Brooks suggested (in, "No Silver Bullet: Essence and accident in software engineering") that the lack of a conceptual construct (a mental or visual representation) of software was THE essential difficulty.
The use of automated tools to capture requirements has an equally long history. Dan Bricklin (co-inventor of Visicalc, the first commercial spreadsheet and often credited as the 'killer app' that sparked the desktop computer revolution and Apple's early success) created Demo a "rapid prototyping tool" that allowed graphical depiction of user interfaces and simulated the basics of interaction with those interfaces - in the 1970s. The value of using such tools to improve communication and to increase customer satisfaction with software interfaces was clearly demonstrated and Demo was soon followed by numerous similar products. Two problems slowed the adoption of this kind of tool in the decades that followed: first, the idea of prototyping was very controversial, with software engineering proponents deriding it as dangerous and error prone; and second, user expectations were faulty - seeing the complete prototype, they tended to think the application was essentially done!
The market for requirements visualization tools is seen as a growing one; increasing from the $194 million reported in 2007 to a projected $290 million by 2013. This is not explosive growth and it remains to be seen if the more sophisticated products available today can deliver on what their predecessors were not.