We encourage Business Analysts to use Display Action Response models to capture user interface requirements for pretty much any application that has a UI – custom built or configurable. A post long ago described Click-Action-Response tables, but we have since renamed this model to the Display Action Response model, or DAR for short. We use DARs on a lot of projects, in fact two active ones right now are creating them. My personal favorite image that captures the essence of why we use DAR models is this:
As in this picture, typically UI requirements, if captured at all, are captured with a screen shot. And sometimes, if you are lucky, you will also find your faithful Business Analyst wrote a list of requirements out about that screen shot. But if I give you 80 UI requirements next to a screen shot, there is no possible way you could tell me if I have missed any requirements or have any errors in the list. It’s just not practical. So we created the DAR model as part of RML® to make that link of UI requirements to screens, in a way that we can systematically ensure we have not missed any.
The DAR model is made up of a screen shot or wireframe and a set of element tables that describe the requirements for every single element in the screen. The first part of an element table is a basic description of the element including a name, ID, and plain description. The second part of the table captures the element display requirements. The third part describes the element behavior requirements. For display and behavior requirements, we capture them based upon states of objects in the system. For example if a User is “not logged in” the button may say “Login” versus “Log out” if the User is in a state “logged in”. We like these tables because they force you to consider each element in a low level of detail. Here is a DAR table filled out for that one button, but keep in mind you have to do one of these for every button, link, or block of text on your screen!
In the end, if you don’t specify at this level of detail, I guarantee your dev and test teams are going to spend a lot of their and your cycles asking questions at this level of detail…or worse, making it up on their own!
