Using the Right Medium for System Requirements Gets Buy In - Part 2Getting Buy InEach builder presented the system requirements, as it were, for a specific house model, i.e., the goods. You do in fact want the goods. You planned these three interactions because you do want a new house. However, wanting goods and being presented goods was not sufficient with at least two of the builders. You needed something more to make an informed decision. Sophisticated providers of goods realize that people do not usually become customers just because they want the goods they have. Customers buy because they want more than just the goods. They want experiences. Frequently, potential customers are not consciously aware of the experiences they want. They cannot articulate the experience that will sway them to buy the goods they want from a provider. Experience Is PowerfulThe first two builders only presented the goods. All they did was describe the goods they wanted to provide as system requirements. Homes ‘R Us provided an experience — a full-sized Upton as system requirements plus as a direct experience. You could walk into it, explore rooms, open doors and drawers, and imagine how you would place your furniture in your very own Upton home.Granted, the model had upgrades you didn’t want. You had to ask repeatedly “Is this included?” The colors and the décor weren’t to your taste. But you could get past that, mostly, as we will soon see. In any case, as far as you were concerned Homes ‘R Us was by far the best presentation. You experienced yourselves in an Upton model. After a brief discussion, your family decides to take the next step with Harry. 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. I'm sure you will like it.” Any guess on what is soon asked after "How much does it cost?" 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 piece of 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. Human Brains and ComplexityMost people cannot process a simple four-foot extension of a static room. Yet the IT industry as a whole expects stakeholders to validate system requirements for 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 system requirements. But that is rare. So, how can we give stakeholders the experience of the system requirements? Mature Simulation Tools Now AvailableTo 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 system requirements. Text (e.g., line item requirements), screen mockups and technical models (e.g., UML diagrams) dominate.Today, there are tools that enable the creation of interactive simulations of requirements. These simulations are completed and viewed prior to the start of implementation. 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. 
Cook Enterprise Corporation is a Blueprint Business Partner. We believe that their tool, Requirements Center, is the best requirements discovery and documentation tool available. Gartner agrees and presented Blueprint with its Cool Vendor Award in 2008. Additionally, Requirements Center automatically generates test scenarios directly from the requirements.
Simulation ExampleConsider a simple example: system requirements for 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. 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! Discussion Is GoodThis discussion is a good thing. In fact, 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 and delights customers. Who Should Be Involved in the Discussion?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.Benefits of Early InvolvementWhen 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. ConclusionA 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 video game 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.
|
