Live from BAWorld: A Case For Visual Models

I heard a presentation at BAWorld, but for this one I won't mention who it was, because I'm going to critique it in a very specific way. The talk wasn't bad per se, but one thing about it really bothered me. You see, the speaker displayed a slide that was supposed to convey traits of an effective team. The slide contained a circle with 16 lines coming out from it (like a sunshine almost). Each line had a trait on it, for example "committed", "conflict management", "self directed", etc.


The speaker then asked us "What traits are missing?" And my immediate reaction was to go to a place of "Seriously? You want me to read a list of 16 things and tell you something meaningful that is missing?"


So this is another fine example of Miller's Magic number, aka 7 +/2, where the human brain can only hold that many things. So by the time I get to item 10 out of 16, it's unlikely I remember the first.


Add to that, the ideas around the wheel aren't parallel ideas, so it's even more frustrating. If you are going to make a list like this, make them the same type of word - i.e. verb, noun, etc. Ideally they should be of similar type too, but that's harder to measure.


And finally, if you are going to use a visual to display your list, that's great, except that it needs to be one that actually organizes the information in a way that is useful. A circle of lines did not help organize the list. Maybe if he had grouped items together, there would have been 7+/2 items at the first level, with a few branches off each of those.


People did play along and shout ideas, but honestly, I thought the ideas overlapped with what he already had up there. Who knows.


This whole example is simply more justification for why we use visual models to represent information. With an appropriate model choice, we wouldn't have to remember 16 things, it might have helped force a parallelism, and finally it will help organize the information.

Diagrams 2008 Day 3 Highlights: (Useful) Eye Candy

In a word: Awesome. There really is no other way to describe today’s Keynote Presentation by W. Bradford Paley (link). Paley has done a ton of work in Graphical Design and implementation which has touched many industries—from revolutionizing the ways in which Wall Street traders to their job, to creating stunning displays for the New York Museum of Modern Art, to creating tools which aid in literary analysis. To sum up, he has created exciting new ways to model a large amount of very complex information, as well as provide the ability to analyze the information easily and in a visually captivating way. His creations blur the line between design, art, and analysis. Here is one sample of his work, which can be explored more at www.textarc.org



An interactive map of Alice’s Adventures in Wonderland used for literary analysis. The entire story is displayed around the circumference of the map. In the middle, sits all the words in the story, with the more frequently used words displayed the brightest and biggest.
Clicking on a word will display in a map all of the places in the story that word is used. This provides a very simple visual cue to the user. While this tool was designed with structuralist literary analysis in mind, there’s no reason why it couldn’t be used for requirements analysis.
Paley has also designed a tool to create org charts, but in a much more sophisticated way than Visio. Paley’s tool allows the user to define more informal relationships, as well as drag and drop nodes into several different clusters. It looks like a great way to create an org chart from scratch when all you have is a list of people, their positions, and a few loosely-defined relationships among them:



You may be able to make out a tree structure on the left hand side of the diagram. This is a directory structure which mirrors the visual structure on the org chart. It seemed as though, according to the demonstration, that one could drag names from the structure on the left into the space on the right, creating a new node on the org chart.

A few more examples of Paley's work, many of which are described on his website. All of these were fully interactive, allowing the user to pull apart, zoom in, and highlight nodes:



This was a model Paley created of a social network.



A model of the relationships among scientific paradigms.

Finally, something a little more applicable to requirements: A concept mapping of items in an online catalog. One of the cool things about this application was that it allowed the user to design her own icons which represented each concept in the hierarchy using a freehand drawing:



Well, today was the final day of Diagrams 2008. The agenda has been intense and has covered everything from Euler Diagrams to Animation. Because Diagrams was so interdisciplinary, there was no specific requirements engineering agenda; however, that does not mean it wasn’t useful to RE practitioners. Quite the contrary, many of the presentations were not only inspiring, but directly applicable to Requirements Engineers. Just having the exposure to a vast array of brilliant minds thinking about how to represent complex information efficiently and more simply made the conference well worth attending for someone with an interest in RE.

Now, off for a day of sightseeing—and most likely a little more beer, followed by a long commute home.

Diagrams 2008 Day 1 Highlights: From Models to Code (and Back)

Today's Keynote address, given by Wilhelm Schäfer, discussed something called Mechatronic UML: A subset of UML 2.0 with applications in industries which intersect EE and ME, and actually in use on the Railcab project.

This subset of UML is used to generate code for systems in which there is heavy interaction among several different components—especially designed for safety-critical applications (such as public transportation). Although such a language is definitely beyond the scope of most requirements engineers, it made me reflect on the “Requirements/Design/Implementation” distinction, in that even though the distinction between requirements and design will never be resolved, the distinction between design and implementation always seemed more concrete. I think that Schäfer’s project has sort of blown a hole in this belief for me, as the design work done in UML is used to generate code directly and successfully in very complex systems. Now, if there were a requirements modeling language which could be translated into Mechatronic UML (or even a fragment of it), it would not only blur the line between requirements and design even more, but also the line between requirements and implementation. Scary.

Also, today during the welcome and introduction, it was revealed that the authors for the best paper in the conference would be awarded two Nokia N810s tablets! Cool! One of the great things about a conference such as this, is that despite the diverse interests of many of the participants, all of them almost universally believe in leveraging technology to solve complex representational problems. As a result, I would say that around 50% of the people here are using a tablet PC or convertible.

At the poster session, I encountered some interesting studies about diagram placement and comprehension of supporting text. It turns out that placement of diagrams in relation to the supporting text may not be as important as our intuitions might reveal. Additionally, diagrams with which one must interact in order to view (e.g., a clickable thumbnail) are more likely to be ignored. The sample for this study was college students, however, and not requirements engineers or their audiences. It would be interesting to run a similar study with an RE orientation. By the way, there was plenty of German snack food at the reception and poster session—pretzels, dark bread, wurst, mustard. And of course, beer. It was a long and cold—but happy—walk back to my hotel.

Why Should You Use Requirements Models?

Why should you use requirement models? Isn't it faster to just start listing the functional requirements? In this post I'll explain why you shouldn't do that - and why requirement models are so powerful.

Provide Context
You cannot pick up a list of 500 system shall statements and quickly get a grasp of what the system needs to do. Higher level models, such as System Context Diagrams, Entity Relationship Diagrams, Process Flows, and Organizational Charts are great ways to understand the complete picture. Other models can provide important contextual reference for developers, testers, and others that need to consume the requirements (Use Cases are great for doing this).

Help Derive Requirements
Models can help you generate requirements quicker than you could than without them. Use Cases are a great example of this - once you've generated the series of interactions, it is relatively easy to examine each step and ask the question "what does the system need to do to support this step?" Likewise, you can examine interfaces within a System Context Diagram and start thinking about what requirements are necessary to support them.

Prevent Missing Requirements
Going back to the proverbial list of 500 system shall statements - it is nearly impossible to look at a list like that and determine if anything is missing. There's a post here that describes this in more detail.

Easy to Utilize
Most models are easy to read and use. If you've ever had difficulty getting stakeholders or end users to review your 200-page document (and who doesn't love to read those!?), consider leveraging models to shorten the review time. It's a lot easier for someone to validate requirements while using a Process Flow or Use Case than it is without them.

So avoid the temptation to jump straight into the requirements - your requirements will be more complete, have more context, and will make it easier for others to validate and use your requirements.