Requirements Model 3 - Click-Action-Response Tables

My latest requirements model discussion centers around a tool that we developed at Seilevel for a very large and complicated web-based application a few years ago. These tables can be a real life saver when used on the right kind of project.

A click-action-response table can be intimidating at first blush. When you break it down, however, they are simple to fill out and read (a requirement of any good model). Each UI element on a screen gets its own table. There is a description section that provides some simple layout and size requirements as well as any related use cases. There are also conditional display and behavior sections.

The conditional display section shows how the UI element is displayed under various conditions. In the example diagram, there is one button that is used to log the user in and out. When the user is logged in (the 'Logged In' state of the system), the button looks different than when the user is logged out. This section captures those various states and displays.

The conditional behavior section shows how the system responds to user input on that specific UI element under various conditions. In this example, when the user is logged in, the button logs the user out. This section shows how the various states affect the reactions of the system.

These tables are almost like a cross between a state table (discussed earlier) and a use case. Use cases take system state into account in a similar way, but these tables are at a much lower level of detail.

You're probably wondering if anyone could ever complete one of these tables for every UI element on every screen of a large application. Well, let me tell you, they can. We did it. Yes, it is a lot of work, but the UI was very important to the business and it is much less work to hammer out the details here than after development.

The project we used these on was a spec for an online storefront system. Each UI element had different reactions depending on the type of actor using the store. Home users, business users, and government users all had different UIs. The elements also had different displays and behaviors depending on previous choices made by the user. We still used use cases to capture the high-level flows, but these tables ensured no gaps were present in the low-level requirements.

The value you get out of these tables is in the extremely low level of detail you can uncover through their use. There is no other model I know of that breaks down the user interaction at this low level.

Once you get used to using these, they can be turned out very quickly. If the UI isn't that important to the business, they are really too much work. Once again, knowing when to use the right tool is crucial.