I'm a programmer currently working in rounds of meetings along with BAs and PM to gather/describe modules and functionality of our case management system; after a few meetings I saw that using 'use cases' would be a very very good fit to document many of the things and functions discuessed and/or proposed for the new system. When I suggested we needed to create 'use cases' so that we don't forget what we said/concluded and also to have programers know what they should code, the leading BA mentioned don't like 'use cases'.

What can be used to gather/document requirements when people supposed to write user requirements say they don't like 'use cases', or when you realize that they don't want to write 'use cases' to describe what the system should do?

I'm trying to find out if there's a close or effective substitution to using 'use cases' to document system functionality/scenarios.

  • 4
    What does the BA mean by not liking use cases? Does the BA have a better suggestion?
    – superM
    Mar 15 '13 at 14:21
  • 1
    Good questions which, I did not ask but will ask next time we meet.
    – Only You
    Mar 15 '13 at 14:55
  • 2
    Call them something different and try again. They probably got burned once by some agile snake-oil methodology salesman and find the whole concept distasteful. Emphasize the content - high-level descriptions of features and functionality with an emphasis on what the business value of the feature is. The whole point is to avoid getting bogged down in REQUIREMENT 1.23.1-8b : The Frobnosticator MUST kerwizzle the hurfberg modulator on alternate Tuesdays unless the hurfberg modulator is presently engaged and losing sight of why the system is being built in the first place. Mar 15 '13 at 23:16
  • We create what we call User Requirements Documents (URDs) with the typical long narrative; we separate out requirements into sections, including business need, scope, time frame, some design specifications as well as screen shots where appropriate; never included 'use cases'. Our URDs might not be correct technically speaking but, have been good and have worked out fine in many instances; and we are going to create another URD again. However, it was pretty obvious that including 'use cases' this time would be very helpful, only to face unexpected answer the BA not liking use cases.
    – Only You
    Mar 18 '13 at 13:51
  • I was trying to find a substitution for the 'use case' part, not for the whole user requirements document. The reference in John Niedzwiecki's answer to 'user stories' seems pretty good and it could face less resistance than 'use cases'.
    – Only You
    Mar 18 '13 at 13:58

Depending on your/their definition of a 'use case' you could instead look at 'user stories'. I say this if you define a use case similar to Usability.gov's definition

A use case is a description of how users will perform tasks on your Web site. A use case includes two main parts: the steps a user will take to accomplish a particular task on your site the way the Web site should respond to a user's actions. A use case begins with a user's goal and ends when that goal is fulfilled.

You can instead use user stories, which come from the agile development methodologies. They are more about what you want to do, then how to do it. There are many different articles and definitions about user stories out there. This older article actually presents what they see as the difference between use cases and user stories (New to User Stories?) And in the end, they really do the same thing. They just frame them differently. You still need the same information, who, what and why (goal). Their meant to be more narrative, with personas linked to real user types of your system. They're more descriptive, but still contain all the information you need.

It sounds like in your case, representing the same information you need differently might be exactly what you need.


It's quite strange that the BA rejects a requirements' template without proposing another one. Generally the BA should make suggestions about the documentation (if there aren't already accepted standards in the company), or at least inform in what format he/she will prepare the requirements.

Typically business requirement documents (or BRD) don't have a strict format, but there are some topics they should cover:

  • general information (purpose, references, assumptions, etc.)
  • business processes
  • requirements scope
  • functional requirements (can include use-cases as well)
  • data requirements (data volume, data conversion, etc.)
  • non-functional requirements (security, performance, scalability, etc.)
  • UI requirements
  • etc.

Covering all the topics above will possibly be enough to document all the decisions made during the meetings. I also suggest that in addition to describing the final decisions, you also mention why this or that decision was/wasn't made and why a certain solution works/doesn't work. This will help you avoid having the same discussions all over again.

From my experience, the BA I worked with gave us the requirements in the form of UI diagrams. Since we worked on the same project all the time, there were some conventions which we all knew and there was no need to include those in requirements every time. Along with the diagrams the functionality was described. These documents were used both by developers and the UI designer, and whenever we had questions we were welcome to ask. After the requirements were ready and the developers have studied them, we had a planning meeting during which the PM prepared user stories and tasks.

  • 1
    +1: The entire point of a Business Analyst is to produce requirements in some form to guide design and implementation. A BA that doesn't do so isn't doing the most basic part of their job. Mar 15 '13 at 22:45

Another option would be Personas and Stories. Personas go a step beyond Use Case actors because the represent an actual person using the system and how they might interact with it. For example for a payroll system, you would have personas such as:

  • Bob from accounting
  • Alice from hr
  • Tom the manager
  • Bill the employee
  • John the CEO

This allows you to create stories around how these users go about their day using the system. To help get started with the concepts, check out Mike Cohn's book User Stories Applied

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.