Interview Questions for Business Analysts and Systems Analysts

Recent Interview Questions | Search | Subscribe (RSS)


What are some of the formats used for writing use cases?

Posted by MostafaElbarbary

Article Rating // 10940 Views // 0 Additional Answers & Comments

Categories: Business Analysis, Use Cases


To ensure that we understand what is meant by the term format, consider the following. Most authors and practitioners do not clearly differentiate between style and level of detail when defining use case writing formats. Style refers to the structure of the use case or how the use case information is presented. Level of detail refers to the state that a use case is in as it evolves from nothing more than a use case name to a fully described or fully dressed use case. Most authors and practitioners generically use the term format to describe some combination of these two concepts.

Alistair Cockburn (2001) defines the following types of use case writing formats in his book Writing Effective Use Cases:

  • Brief - A use case brief is typically one paragraph which summarizes the main success scenario and at times the main failures. It is written during early requirements analysis and only takes a few minutes to create.
  • Casual - A casual use case consists of multiple paragraphs which cover the main success scenario and alternative success and failure scenarios. It is written in a narrative form without the use of numbered steps.
  • Fully Dressed - A fully dressed use case describes the main success scenario, alternative scenarios, and failure scenarios in full detail. They typically use numbered steps to aid readability of alternative scenarios that branch from the main scenario and to clearly convey where a scenario that returns back to the main flow would continue.

Kurt Bittner and Ian Spence (2003) differentiate a bit further between style and level of detail. They describe a Use Case Authoring Life Cycle as having 6 states (which describe the level of detail provided). The 6 states are:

  • Discovered – The initial identification of the use case. At this state it is just a named use case.
  • Briefly Described – A single paragraph description. It is usually between 2 to 6 sentences in length.
  • Bulleted Outline – This outline will typically cover the main success scenario in 5-10 steps and is focused on the users intent. The outline will also cover the high level steps of the most important alternative flows and exception flows.
  • Essential Outline – This outline state is also focused on the user’s intent but begins to clearly show the interaction between the user and system. It does not go into detail about how the system internally accomplishes the goal.
  • Detailed Description – The detailed description expands on the bulleted outline, describing steps in greater detail using full descriptive sentences. At this state, it is determined whether to write the use case in a narrative or conversational style.
  • Fully Described –This is the final state and has a complete flow of events including the main success scenario, all alternative scenarios, and exception scenarios. The terminology used is usually defined in a supporting glossary. All preconditions and post-conditions have been identified. A fully described use case is Testable, Understandable, Unambiguous, Correct, Complete, and Attainable.

In addition, for the Detailed Description and Fully Described Use Cases, Bittner and Spence (2003) identify two popular writing styles that are used:

  • Conversational Form – The conversational form is written in a two column format. All user steps are in one column and the system response is documented next to the user step in the second column. The conversational form is often called the Dialog Form. It emphasizes user-system interaction and works best for use cases where only one actor is interacting with the system.
  • Narrative Form – The narrative form is written in a single column format. Each step consists of a sentence or two and the use case is more of a narrative description or story. This style works better for use cases that describe the interaction between a system and multiple users.


Bittner, Kurt and Ian Spence. 2003. Use Case Modeling. Addison-Wesley Professional. pp 152-159.
Cockburn, Alistair. 2001. Writing Effective Use Cases. Addison-Wesley Professional. pp 37, 119-129.



Only registered users may post comments.

Do your homework prior to the business analysis interview!

Having an idea of the type of questions you might be asked during a business analyst interview will not only give you confidence but it will also help you to formulate your thoughts and to be better prepared to answer the interview questions you might get during the interview for a business analyst position.  Of course, just memorizing a list of business analyst interview questions will not make you a great business analyst but it might just help you get that next job.



Select ModernAnalyst Content

Register | Login

Copyright 2006-2024 by Modern Analyst Media LLC