This month SSQ is focusing on software requirements and ways to overcome the challenges so that defects can be eliminated up front.
One method of requirements elicitation that I blogged about recently is the use of visualizations. Visualization software is used by business analysts to create a working simulation that can be used to help communicate with stakeholders when gathering requirements. This blog post sparked enough debate to motivate me to write a full feature story: Are visualizations the answer to gathering requirements? In this piece, I interview several project team members and analysts about their experiences with using visualization, exploring the benefits and drawbacks.
One of the biggest points of contention is the concern that visualizations will focus on the User Interface design, or on ‘how’ the software should work, rather than ‘what’ the software should do. Requirements expert Robin Goldsmith describes how to “discover REAL business requirements” in Problem Pyramid discovering REAL software requirements – Part 1.
I asked Goldsmith what he thought of introducing UIs as part of the requirements gathering process and in his expert response he answers rather adamantly, “Focusing on the UI, system use cases, prototypes, visualization, and other forms of product/system/software solution description in the name of requirements makes it virtually certain that the developers (which include analysts and testers as well as programmers) will not be paying sufficient attention to what is really needed.”
However, after talking to those who experienced such success with visualization software, my impression is that there can be a lot of benefit from introducing the UI at a high-level as a tool for communication and collaboration. In my opinion, if you don’t talk about these things with the stakeholders they are almost certainly going to end up with something they didn’t expect when the product is delivered.
What about you? What are your opinions and experiences?