Requirements elicitation can present a variety of challenges. Visualization tools that allow for working simulations are now being used to help facilitate communication and collaboration in requirements gathering. SearchSoftwareQuality spoke with David Nyland, President and CEO of Blueprint Software, to find out more about visualization software and its use in the software community.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Q. What are visualizations?
Nyland: Visualizations in the context of requirements is the bringing to life the requirements in a visual way. This allows people to interact with all aspects of the requirements, allowing them to see, touch and feel them rather than reading a very monolithic-type document.
Q. Might this approach put too much emphasis on the User Interface?
Nyland: It’s very important for the UI to be visualized in context with all the other requirements. UI visualizations alone don’t tell the full story.
Q. If you were doing a simulation, how would stakeholders be able to review those requirements that can be seen?
Nyland: It could be a combination of business process walk-throughs with traceability detects and functional decomposition of lists containing text with all traceability exposed.
Q. Do you think this method of gathering requirements might replace more traditional methods?
Nyland: I think in the foreseeable future, a requirements document will always exist; however the process to get that document can be done differently. Visualizations and simulations and validation of requirements can be done first and used to then create the requirements document.
Q. So can the document be created from the visualizations with screen shots of the UI, for example?
Nyland: Exactly. It can be one or many documents. The information can be integrated or separate depending on the audience. It will be the same information that was validated visually, automatically transferred into templates for the customer’s organization.
Q. Are we shifting the responsibility of the design? Are the developers and architects involved? Is it too much design work up front?
Nyland: We find that the role of the business analyst and the process of creating requirements is done earlier in the process than design, so the early UI definition is low fidelity with emphasis on functional definition and not on the rich design. Downstream the designers take over. Once the designers do take over, we want to capture that information and bring it back so we can enrich the requirements.
Nyland: Some of our customers update the requirements as things change.
Q. Do customers have unrealistic expectations about what they’re seeing in terms of the UI and timeframe?
Nyland: Most of our customers have a lot of early, positive interactions because they’re contributing. There’s a sense of relief that the system is properly validated and that the system will meet the requirements. The key thing is they can see all the changes as part of the review. They see all the requirements, beyond the UI, so they can see all the complexity and detailed requirements.
Q. Are the developers involved in the early processes?
Nyland: It tends to be the architects and development leaders who are involved early. Once the requirements are approved, the developers have access in paper form or can run a simulation. Particularly in instances with off-shored development, using a rich simulation rather than reading a document makes a tremendous difference to developer context and productivity.
Q. What challenges are you finding with this approach?
Nyland: Getting the message out that this exists. It’s relatively new.
Q. What do business analysts think?
Nyland: It’s change and change is always difficult. With some training and pilot projects we find most organizations pick up use of the tool quickly and see the benefits.
Q. How difficult is it to build the simulations?
Nyland: Without simulations, business analysts may use a tool like Visio to describe requirements. The key approach for the vendor community is to develop editors or methods of capturing data that are very similar to the way people author documents; but the net effect is that it’s going into a system that can be verified, validated, and most importantly, it can be simulated.