Using the Right Medium for System Requirements Gets Buy In - Part 1
Three Home Builders
The opening story on this page is a metaphor for the state of system requirements practices. We examine how three different requirement mediums:
3) interactive models
affect people in everyday decisions.
Suppose your family is in the market for a new house. Your plan is to get recommendations, interview three builders and then choose one to build your new home. Let's see how it goes after you select the three builders.
Interviewing Acme Builders
First you meet with Ann, a salesperson at Acme Builders. Ann asks some questions about what you have in mind and you describe your ideas. Ann tells you that Acme’s Bainbridge model would be perfect for you. You reply, “Sound good. Let’s take a look.”
Ann says, “Here is the description of the Bainbridge model complete with all available upgrades and options” while handing you a two-foot tall stack of printed materials. You leave — Acme, Ann and the printed materials.
Interviewing Kelly & Sons
Next you meet Kim at Kelly & Sons. After learning about your house ideas, Kim says that the Sanford model meets your needs. Kim hands you a scroll of large-sized paper while saying, “Here are the complete technical schematics of the Sanford model. See, page 1 shows the exterior view with optional elevations; page 3 the floor plan; page 8 the plumbing.”
“We don’t know how to read technical schematics and I don’t see why we should learn how!” you say to yourself as you walk out.
“That salesperson wasn’t listening to us,” your spouse says in the car. “We don’t want elevators.”
Interviewing Homes ‘R Us
Then you meet with Harry at Homes ‘R Us. Harry asks what you like in a home. He listens and says, “The Upton model sounds like it might work for you. Would you like to go through one?”
“Finally,” you say, “something we can understand!” as you are walking through the Upton model.
Which of these three builders do you think has earned the right to build your new home? Right, Homes ‘R Us.
Looking at the discussions with the three builders, probably without even being aware of it, your family interacted with them via several mediums. All three builders presented the house they believed would meet the needs of your family, albeit in quite different ways.
How Does This Apply to System Requirements?
What does all this have to do with system requirements, you ask?
Well, just as you wouldn’t buy a new home based on written descriptions or technical diagrams, why would you expect business stakeholders to buy applications that way? Especially since there is a huge difference in complexity between static houses and dynamic applications that change behavior based on user actions, data values, rules and current state.
We Are Using the Wrong Medium
Simply stated, we are using the wrong medium to discover and document business system requirements and software requirements. We need to give stakeholders an experience of the proposed process or application that they can validate. We need to place them inside it so they can directly experience how the process or application will meet their needs — before implementation starts.
And maybe along the way even help stakeholders discover something dramatic — an innovation — during system requirements discovery and documentation when it costs the least to implement.
From Part 1 to Part 2
From Using the Right Medium for System Requirements Part 1
to Building Requirements Consensus™ Home