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.
7
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
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