Software Quality Insights

Jul 8 2010   6:27PM GMT

Requirements debate continues: Are visualizations beneficial or dangerous?

Yvette Francino Yvette Francino Profile: Yvette Francino

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?

 

5  Comments on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
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
  • RobinGoldsmith
    My biggest challenge is that people don't understand there's a difference between software requirements and REAL, business requirements. These are two very different parts of software development. Both are important, as is understanding the difference between them. Satisfying business requirements deliverable _whats_ provides value. That’s why I refer to them as the REAL requirements. There are usually many possible ways to satisfy the REAL business requirements. Most development and other requirements authors focus only on software requirements. Software requirements represent one of the possible ways presumably _how_ to satisfy the REAL business requirements. Software that satisfies its software requirements provides no value unless it also satisfies the REAL business requirements. Creep and its accompanying overruns and disappointment of not getting what’s expected (and more importantly, needed) generally occurs because software satisfies the software requirements that have been defined but doesn't satisfy the REAL business requirements, usually because the REAL business requirements have not been defined adequately, in turn usually because people thought the software requirements were _the_ requirements. Visualization, UIs, and the like indeed are helpful for defining software requirements but have only marginal impact on controlling creep. The emphasis on their use in requirements definition frequently leads to seemingly sound software requirements that end up creeping because that emphasis almost always comes at the expense of adequately discovering the REAL business requirements. Get the REAL business requirements right first, then use UIs, visualization, and the rest to define software that will satisfy the REAL business requirements.
    135 pointsBadges:
    report
  • CraigDR
    An interesting article and I would agree with Robin's emphasis on trying to get to and understand the REAL business requirements more effectively. We adopt a visualisation type approach during our development, but perhaps not in the same sense as referred to in the article(s). The visualisations we use are of the actual requirements themselves. More specifically, we use flowchart type representations for capturing the various workflows and business processes which are to be implemented. These allow us to express the requirements that are to be implemented but in a way that will be understandable to both technical (e.g. developers) and non-technical (e.g. customer/domain expert) project members, using a standard, common diagrammatical representation. We feel that this allows everyone to talk about the system functionality using a common 'language' that everyone can understandard and could help to bridge the expectation gap between what a customer really wants implemented, and what we have actually implemented, etc. Of course, not everything can be captured in a flowchart, but we use it where applicable. Look forward to hearing the experiences of others.
    0 pointsBadges:
    report
  • Yvette Francino
    Thanks Robin and CraigDR for your comments. It's always good to get discussion and debate and hear about how others are handling the challenge of requirements elicitation.
    900 pointsBadges:
    report
  • SteveWhisenhant
    Visualizations seem best for usability studies and requirements validation. Read more at http://wp.me/pZpNT-Q
    0 pointsBadges:
    report
  • Arvind25
    Visualizations are beneficial but it becomes a problem when Visualizations and simulations become the only source of requirement specifications for the testers. When a business requirement is translated to visual form, you still need to have a solid document mentioning the original specs. With just visualization, there is a possibility and more probability of the initial requirement getting lost. The tools used by Business analysts helps them to come up with easy simulations which is useful for their demo, but proves to be of less value to a tester. IMHO, visualizations and simulations can be used to aid the basic requirements doc and should not even remotely try to replace them. Unfortunately, this has started happening in the place i work..
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: