• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Display Action Response Models for User Interface Requirements

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!

7 Responses to Display Action Response Models for User Interface Requirements

  1. Nitin January 18, 2013 at 2:18 am #

    Currently I am doing requirement gathering of CRM. I am working on screen where we register customer.
    I don’t think use case can help in this case,
    as only action that user is performing is submitting the application related to a customer.
    Before submitting this application he has to fill 100 fields in four different tabs.
    So, What should be correct approach in this case.

  2. Joy Beatty January 23, 2013 at 9:10 am #

    Thanks for the comment! You probably should have a use case that is more breadth than just register, where register is one step. Your fields are absolutely something you can capture in DAR models if there is a lot of conditional behavior behind them. If not, a Data Dictionary might be more appropriate.

  3. Clinton Eidelman April 3, 2013 at 6:44 am #

    Just bookmarked this post – thanks!

  4. vab April 9, 2015 at 7:13 am #

    Nice article on DAR, there are few resources available on Internet that can help a reader to understand what is DAR model

  5. Joy Beatty April 9, 2015 at 8:13 am #

    Thanks – I actually love this model and think it’s probably under used. We have a quick description online here: http://seilevel.com/business-analyst-resources/business-requirements-models-templates/display-action-response/ or there is a chapter in the Visual Models for Software Requirements book on them!


  1. Re-using DAR models in Your Software Requirement Specification - May 16, 2016

    […] recently wrote about one of my favorite RML® models, the Display Action Response (DAR) model. This model has been on my mind a lot and I do hope it finds its way into every Business […]

  2. Live from REFSQ 2011: Starting the Conversation - Seilevel Blog - Software Requirements - May 16, 2016

    […] to mine data for use in their own projects.  I had an opportunity to share Seilevel’s own research idea with other participants in the conference, and I am grateful for the feedback I received, which […]

Leave a Reply

Your email address will not be published. Required fields are marked *