Use cases are a very popular tool for new business analysts, but they can be overused.
In this video, I provide some guidance on the types of requirements that can be expressed well via Use Cases.
LEARN.BA. In this video I’m going to talk about use cases very specifically I’m going to talk about what use cases are and I’m going to give you a few things that you should consider. What if you’ve chosen to use used cases as a way of documenting your requirements. Now if you’re a new business analyst or you’re somebody that’s trying to get into the career of business analysis and you’re googling around what the different types of tools and techniques are for documenting requirements.
Chances are that you’re going to run across a lot of material out there that talks about use cases and you want to be a little bit careful because if you’re completely new to the profession that’s might leave you with the impression that use cases are actually a lot more important than they actually are.
So if you don’t have a whole lot of direction and you haven’t yet learned that there are a lot of other tools out there and that there are different types of requirements that have to be expressed. You might fall into the trap that many new analysts fall into which is over using a tool that you know very well. But for the wrong purpose and so don’t let the fact that a lot of people are talking about use cases force you to second guess. So don’t let the fact that there is a lot of materials about use cases lead you down the path of using use cases for expressing the wrong kind of requirements. So number one what is the use case a use case is a B a tool that you use to express the user interaction with the system. So as you’re producing requirements there are many different types of requirements that have to be captured and documented and analyzed the user interaction is one of those types of requirements. And even more specifically use cases are just one tool that you have to express the users interaction with the system. There are other tools out there so that should give you an idea of where use cases actually fit in.
And so you should dedicate the right amount of time and resources to learn. Use cases not too much not too little. Okay. So just remember that it’s one tool that helps you express one layer of requirements. So the way that you document to use case typically is that you start to document the main part of a use case which is called usually the primary flow.
The primary flow is a sequential set of steps of what it is that a user does and then what does what it is that a system doesn’t respond. So basically it’s like user does X system does Y user does a system does B and it’s basically just a sequential list of steps that the user and the system perform in order for the user to achieve some goal.
Now there are many different levels of detail that you can express your use case in so if you’ve chosen to use it. The second point that I want to talk about is the different levels of detail and how you can start to decide what level of detail you need to document at. The very base level of detail for a use case is for you to just have a title for use case and then just have the primary flow possibly have what’s called an alternate flow. That is the most bare bones version of a use case that you can have and that’s at the extreme like very bare bones level of detail on the opposite side of that the polar opposite is what is typically referred to as a fully dressed use case. So what if fully dressed use cases is a very comprehensive version of a use case and the way that you make your use cases more comprehensive is by adding a lot of extra attributes to the use case other than just the title the primary flow and the alternate flows you start to add a lot more attributes. For example you can start to add things like preconditions post conditions you can start to describe the triggers that.
That starts off that kicks off the use case you can add versioning information in there and so there’s a whole host of other attributes that you can start to add into your use cases depending on how much detail you need to add so you can go from a very vague bare bones version of a use case to a very detailed comprehensive version of a use case and the way that you typically decide the way that I normally decide what version of We use cases that I start with the bare bones and I leave it that way until I start to see that there are elements of the use case that are very important that haven’t been captured in there and then I start to decide what other attributes I need to add in to the use case. Typically there isn’t a whole lot like I haven’t been in many situations where I have to write fully dressed use cases I actually have never written a fully dress use case so it is one of the primary things that you want to learn. If you’re trying to learn use cases and you wanted to try to figure out when and where and how to use them is number one. Tried to decide. Is your business requirement or a functional specification that you’re writing is a trying to describe a user interaction.
And if it is then a use case is a very good candidate for you to use as a tool to express that requirement. If you’ve chosen to use the requirement. Then what you want to do is you want to start off with the very barebones use case. Which means that you have a title.
You have the primary flow and you have the alternate flows of a use case at that point what you’re going to do is you are over time as you’re having more requirements sessions and more people are looking at that use case and possibly asking you additional questions about X Y and Z then you may choose to add additional attributes all the way down to making you use cases what’s called fully dressed. So that’s what I wanted to say about use cases. Now the warning that I want to reiterate is the fact that again. A use case is a single tool in your toolbox. Right. I’ve mentioned that at the beginning of the video now. If it’s a single tool then the question might be going through your mind about well what are some of the other tools. Well very specifically at the user interaction layer of requirements you have things such as Mock ups mock ups are very important requirements tool that helps the users and helps your subject matter experts to start to visualize what it is that the part of the system you’re talking about might actually look like. So a mockup is basically just a very rough sketch of what the screen might possibly look like. There are many other types of requirements that neither a use case nor a mockup is a good candidate for it. OK so an example of that would be at the next level lower than the user interaction which is the business logic layer. The way you typically document.
Requirements at the business logic layer there are multiple tools. The single most important way of documenting those requirements it is what is referred to as business rules. So if you’re trying to become a business analyst or you’re starting your career as an analyst or you’ve been working as aB.A. for for a while and you have not yet learned how to write good business rules. That is one of the skills that you want to start to try to focus on because again it’s one of those tools that gets used fairly heavily. And so one of the things I would recommend is to look up the author by that goes by the name of. Ronald Ross which has written more or less the definitive guide of what business rules are and how they should be expressed and you how you should use them to express your requirements.
So again his name is Ron Ross or Ronald Ross and he’s written a book specifically on business rules. I’m not necessarily suggesting that you read the entire book but what you want to do is you want to start to look down that path a little bit more to learn a tool that is available to you. That’s not a use case because when you’re trying to document business rules you can’t use a use case in a lot of examples you’re not going to be able to use a use case to document those types of rules. So the lesson that I want you to walk away from in this video is the fact that use cases are important but they are not necessarily the right tool for expressing every type of requirement. In other videos I’m going to talk to you about the different types of requirements that are out there and what kind of tools are available to you to be able to use to document those types of requirements. As a new analyst this is probably one of the most difficult things to learn is that when you’re in front of a client and you’re talking to them and they’re talking to you about the different needs that they have it’s very difficult for new analysts to try to parse out.
A single sentence that a client might say in to what kind of requirements they should be expressed. And so as you start to do more and more requirements and I’ll give you more guidance on that but as you start to do more requirements.
That’s one of the key skills that you want to pick up. It’s one of the hallmarks of a senior analyst. So typically when I’m in front of a client and they’re talking to me about the different types of issues that they have and some of the different things that they’re looking for out of the solution usually I can almost immediately start to pass out that into requirements in my mind as they’re speaking and as I’m asking questions and we’re going through the conversation. When I first started my career out that was not the case what I had to do at that time was I had to basically jot down everything that. The conversation was I had to learn how to be very good at taking notes write everything down as quickly as I could. Sometimes I would take sometimes I would write but I would get that stuff done and then I would go back to my desk and then it would take me a long time to try to figure out how am I going to actually capture and express these requirements in my requirements documents.
So it’s something that I’ve learned over a long period of time and if it’s something that you’re not good at right at the beginning of the career you shouldn’t beat yourself up because that’s a very difficult skill to pick up and it does come over time as you get more experience. So I hope that that advice helps a little bit. And what I’ll be doing in other videos is I’ll be talking a lot more specifically about the different types of requirements and I’ll be trying to give more pointers on what types of the things you should and should not do to be able to become a more experienced analyst a lot more quickly.