Just a Small Change
“We do like this house except for one thing,” you say. “The family room is too small.”
“Fortunately,” Harry replies, “we offer an option to extend the family room by four feet. It really opens up the room! It feels much bigger.”
Any guess on what is soon asked? Right! “Do you have an Upton with the extension we could walk through?” Why? Because most people need to experience something to understand it. You will never know what a chocolate cake tastes like by looking at a picture of it no matter how many pixels it has!
By providing the experience of a model, Homes ‘R Us earned the right to negotiate to build your house. However, the experience they provided did not answer all your questions. Because the builder’s model does not have the four foot extension, Harry is forced into the position of the first two builders on this point.
Most people cannot process a simple four-foot extension of a static room. Yet the IT industry as a whole expects stakeholders to validate applications with very complex behavior and multiple simultaneous changes. Human brains are not wired to handle this level of complexity. Sometimes, we (eventually) train non-technical stakeholders to grasp technical requirements, but that is the exception.
So, how can we give stakeholders the experience of the requirements?
To be fair, requirements tools that enable the kind of experience we are discussing have only recently become mature enough to consider using. We did not have much choice in how to document requirements. Text (e.g., line item requirements), screen mockups and technical models (e.g., UML diagrams) dominate.
Today, there are tools from various vendors that enable the creation of interactive simulations of requirements. These simulations are completed and viewed prior to the start of coding. Simulations are very useful because they have the characteristic that they either work a specific way or do not work at some point and just stop.
Consider a simple example: an application where a user adds a new customer. When information for a new customer is filled in the user submits it. So far so good. Some stakeholders, however, think the application should present the main screen next because they only occasionally add a customer while others think a default customer form should be presented next because they enter many new customers one after another. Navigating to the add customer screen from the main screen every time will irritate users by slowing them down.
Whichever group you are in, you are likely to think that your view is covered in text or screen mockup requirements because dynamic navigations are often not documented carefully or completely. However, a simulation will either pick one of these two or maybe even a third path. No matter which option is simulated, it is sure to start a conversation among these stakeholders!
This discussion is a good thing. It is one of the main goals in using simulation. Instead of discovering that the application does not meet expectations in user acceptance testing, or even worse, in production, and must be corrected at high cost, we discover this disconnect early in the lifecycle where it can be addressed at the lowest cost.
Now there is the possibility that by making ideas visible a new, innovative solution that meets stakeholder’s needs even better can be found, simulated, validated and implemented the first time the application is deployed. One innovation can make all the difference between an okay project and a truly innovative project that elegantly meets a business need.
Ideally, technical staff will be involved in the simulation creation process as part of high-level design. It is an optimal time for technical creativity—e.g., simulate an existing SOA service (instead of building from scratch) or using a new UI widget (instead of what we always use) to get buy in from other stakeholders who can directly experience how it will work.
If stakeholders have a say in the solution early they are more likely to buy into the choices made. This will help improve application acceptance in the field and increase customer satisfaction ratings.
Simulation is extremely valuable in an outsourced environment, as well. A simulation reduces reliance on words that must be translated and increases reliance on movies that can be taken at face value. Because of the medium itself, a simulation reduces ambiguity by providing a direct experience of the application to be built.
A large part of the reason that business stakeholders are reluctant to engage in requirements is that they do not understand the medium used. Prototypes are a step forward. Simulation takes it further.
A simulation is like a movie that unambiguously shows dynamic interactions. You can deliver a simulation to architects and developers and say “Make it work like this.” Words will still be necessary because not everything can be simulated, e.g., nonfunctional requirements. But the words can be organized so that they are in context of the functional requirements where they apply. If a picture is worth a thousand words, a simulation is worth a thousand pictures.
Brian Cook was a Senior Software and Systems Architect for Zurich Insurance for six years and prior to that an Information Architect, Information Modeler and trainer for Perot Systems for four years. Currently, Brian is President of Cook Enterprise Corporation whose primary mission is to help clients discover, document, simulate and validate processes, scope and requirements visually so they are understandable to nontechnical people. A description of the Building Requirements Consensus Methodology can be found at Brian’s website: www.building-requirements-consensus.com.
“If a picture is worth a thousand words, a simulation is worth a thousand pictures.”