If you’re a Business Analyst, you’ve probably been asked: “What do Business Analysts do?” A common response might be, “I gather and write requirements, and hand them to IT to do the actual coding and development of the system.” You might keep it short for simplicity’s sake. But there’s also an important component that not all analysts integrate into the requirements-gathering process, even though they should – Visualization.
Showing vs. Telling
Let’s be honest, we’ve all bought IKEA furniture. Some of those pieces are hard enough to put together with the numerous diagrams, pictures, and instructions. Can you imagine putting together a piece of furniture with multiple drawers, a couple of cabinet doors, knobs and hardware, and doing it all from written instructions only? Sure, if you’re handy, maybe you could do it, but we doubt the average person could (without giving up a few times first). And for those who manage to put it together, it would take an inordinate amount of time.
A Picture’s Worth a Thousand Words
Let’s compare that to coding and developing a system. Imagine describing a backend system process using only requirements. We lose half the group after reading five “system shall” statements aloud. We get a lot of “can you repeat that?,” “Sorry, where are we?,” and “This would be a lot easier if we could see it.” It’s much easier to envision a process from the beginning to the end if we use process flows. Using a single flow diagram, we may communicate the same or even more information than we can in 50 “system shall” statements. In a process flow, we have the trigger, decision points, and the expected results from those decisions. It’s much easier to visualize what’s happening and to validate whether a requirement is meeting business needs if everyone’s looking at a process flow – rather than reading 50 “system shall” statements.
Let Visualization do the Work
So, why write “system shall” statements when you can show the user what the system may look like? Instead, we use visualization as a main tool, so the client can see exactly what they want before months or years are spent building a system that is not up to their expectations. We don’t write thousands of system shall statements during elicitation sessions. We don’t need to. Visualization allows us to present information in a way that the clients can see exactly what they have described to us, to make sure we’ve also understood the process and expected end result correctly. If we are having the conversations, and we don’t understand what we’re describing, how can we expect developers to read thousands of requirements and understand exactly what is expected of them? Our goal is to have minimal written requirements, and use visualization as the source of requirements.
Using tools such as JustInMind or Axure, to rapidly create prototypes has been a game changer for eliciting and validating system requirements. Modeling out multiple screens to elicit requirements has been a new method for our clients. We start by creating a few screens in low fidelity from information we have gathered from our initial sessions, and then use those screens in sessions and update them as they see fit. Visualization makes it easy to change wording, actions, buttons, screen layouts, etc., so it’s easy for the client to see the bigger picture of what they want when the system goes into production. Visualization allows us to communicate complex functionality and allows the stakeholders to experience their ideas more efficiently and clearly well before development, saving money on development rework and defects. And it is a lot easier to write requirements after creating visualization than it is to create the visualization based on the text requirements that keep changing. Trust us – we’ve done it before. Using visualization to elicit requirements is what companies want a piece of now. It’s something we’re working toward and clients are embracing. It’s easier.
It’s more fun. It works.
