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?