Heather Shanholtzer interviewed Seilevel's Joy Beatty about the benefits of using visual modeling instead of traditional requirements documents and why writing good requirements might not be your best point of focus.
Joy Beatty is vice president of research at Seilevel, where she is responsible for developing new methodologies to help improve requirements elicitation and modeling approaches for her customers. I had the opportunity to talk to Joy about the benefits of using visual modeling instead of traditional requirements documents and why writing good requirements might not be your best point of focus.
Heather Shanholtzer: What is requirements modeling and why is it more effective than a regular requirements document?
Joy Beatty: A long list of “system shall” statements is literally unusable by stakeholders. Requirements models enable us to visually represent the information in a way that allows us to identify missing, inconsistent, and unnecessary requirements. If I try to capture how a user performs his tasks in just a list of textual requirements statements, there is almost no way the user can confirm that the steps are correct. In fact, he probably won’t even read the document. But if I model his tasks in process flows, he can quickly see how he does his job visually and confirm or update it. We like to say “Pictures are easy, words are hard.”
Heather Shanholtzer: What are some specific limitations of text-based requirements data and how are they overcome using a visual model?
Joy Beatty: We like to reference the 1950s work by George Miller that says people can only remember seven plus or minus two things at once. If I ask a stakeholder to read 500 requirements statements looking for errors, by the time she gets to number ten (let alone number 500), she has probably begun to forget what one and two were. So it’s very hard to look at the whole set of textual requirements and identify gaps.
Instead, we model the information, keeping it organized into seven plus or minus two things. For example, a feature tree is a model that shows all of the solution’s features in one page. We organize the features into tree branches with only seven plus or minus two main features, and each feature has sub-feature branches with no more than seven plus or minus two features, which also have no more than seven plus or minus two features.
One more point, for those working with teams where English is not the first language for all the participants, visual requirements are accessible regardless of language barriers in ways that text-based requirements are not.
Heather Shanholtzer: Are there circumstances or projects in which a visual model is not the best approach to specifying requirements?
Joy Beatty: Actually, no. It’s not a question of visual models versus textual requirements. You really do need visual models and textual requirements. Visual requirements models help us identify complete sets of requirements; but, in most cases, we still need to write those requirements out for development and test teams.
Also, while you always need visual models, the visual models you select for one project might be very different from the ones you select on another. We have developed Requirements Modeling Language, which currently has twenty-two models and it is rare that you need all of them. It’s equally rare that you would use only one.
Heather Shanholtzer: Why is it more important to focus on ensuring a complete system instead of writing good requirements?
Joy Beatty: If you create perfectly clean blueprints for a house but forget to check that there is a back door, and you end up with a house where your kids have to go out the front door to get to the back yard, are you going to be happy? No! The same is true of requirements and systems. If we have well-written requirements, that certainly helps ensure a complete system, but it does not guarantee it. For example, the development team could overcommit, the well-written requirements might be twice as big in scope as there is budget, and, further, the requirements might not solve the actual business problems.
To address this, we start by understanding the real business problems and business objectives and derive requirements to solve those problems and meet those objectives. In fact, throughout the project, the entire team needs to keep a razor sharp focus on solving those business problems. If they do that, they can help ensure a successful project—a complete system that also delivers business value.
Heather Shanholtzer: If you had to pick one requirements model to recommend, which one would it be and why?
Joy Beatty: This is a tough question because models each serve a different purpose and projects vary so much. However, almost without fail, every project needs a Business Objectives Model, and when it is used, it is the most important model. The Business Objectives Model is what allows us to ensure that every feature developed helps solve the business problems. This model also lays the groundwork for us to be able to drastically cut scope on projects in a quantitative manner, taking the emotions out of scoping decisions.