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.
User Comments
While I completely agree with much of what Ms Beatty says, there are a few statements that are questionable, if not in fact in intent.
If you need 500 textual requirements to specify something, that is because there are 500 things to be specified. Even if you do this in a model, it is still 500. You get around this in models by structuring, hierarchy, etc. You do exactly the same thing in text. I would no more give someone a requirements document of 500 statements with no structure than I would give them a novel with all the words sorted into alphabetical order. You can maintain seven plus or minus two in text, and should strive to do so.
As for models making things easier for non-English speakers, well, up to a point. But a collection of graphics without words is meaningless, and if they have words, then those words had better be in some language.
I love the example of having to go out the front door to get to the yard. This is a clear case where a model (picture) would help. Of course, we have to be wary of imposing solutions when we start modelling, and that also applies for text. In both cases, one of the most important things to remember is to always ask "why?".
Thanks for the great questions and comments Keith! Let me try to respond to all of them!
Regarding using text to specify 500 things:
Sure, you can add structure to the text, for example a Requirements Mapping Model is a model to help you do that. But just saying you can group text into 7+/-2 groups is easier said than done. You have to find something to group them by, be it features, process flow steps, business objectives, etc. One of the concepts we talk about is how no one model is sufficient. The same is true if you organize 500 text statements - it's still not sufficient to fully analyze the solution and know you have no gaps. Finally, visual models are easier to look at than a list of 500 statements of text as well.
Regarding models not fully helping non-English speakers:
That's absolutely a fair statement. I think models only but help to supplement text, but do not fully address this issue alone.
Finally, your point about asking why:
Absolutely! I think this is very much the role of the person identifying requirements - to facilitate determining whether something is truly a requirement or if it is a solution that no one really "requires". We actually use some of the objectives models (Business Objectives Model, Objective Chains, and Requirements Mapping Matrix) in particular to help ensure that requirements truly help solve a business problem and add value to the business. If something isn't a requirement, but rather a piece of solution, it should become obvious in those models and can be cut from the requirements.