Dear Laura, you have no idea how this video helping me. I was stuck at the design phase lost in all the requirements and all the tech details. Thank you so much for this valuable content.
I was writing Use Cases before they were cool. Your presentation was a great explanation of the tool. We wrote them in workshops with the customer, technical lead, and facilitator. Our first step would be a brainstorming session to identify the Use Cases. They had to be named noun-verb as you said in the video. Once we had the list, we would go through the process of filling out the Use Case Form. When that task was complete, the technical team decomposed the system using Sequence Diagrams to lay out the top-level system design. The test team used them to begin writing their top-level test plans. This material would be used to put together the project plan. They are indeed a very powerful tool.
There was a time when use cases weren't cool?!? Says who? 🙂 This sounds like a great approach, and very engaging with the end users, to ensure they got what they wanted and needed out of the project!
@@BridgingtheGapBA It was back in the 90s, and I knew a number of people who thought the idea was another gimmick. I did too, at first. End users took ownership and became good partners in the development phase. The noun-verb structure of the use cases made it very easy for the entire team to talk about the project. It is good stuff. Thanks to you for a good presentation.
I have watched so many videos, and this is is the only one with such a great explanation! Thank you!!!! All the other videos get stuck in the description of what UC diagram is, but they don't show how to create it.
Dear Laura - Timeless video, thank you. It helped me to setup a BAU service specifically to replace aged PCs connected to laboratory instruments at the University of Newcastle.
Laura- these videos are for all types of businesses and professionals. They are easier to follow, practical in use, and increase engagement for improved productivity.
I am a newbie and the ping pong makes a lot of sense. You also made me get the Clare difference between use case and user story. Thank you so much. You are building the gap.
Again you put the ABCs in writing a use case. 😁 You make it seem so doable. I love you style of teaching. By describing the players as actors gives you allot of creative space. Thanks again
You are so welcome Rafeal! Laura certainly has a teaching style that many find help them break what are often abstract BA concepts down and make them concrete and actionable.
Thank you Laura. You are so right. I finally found my role after listening to you. I love systems and I love Python programming. You are right about the non tech speak. As I am learning Python, we are always told to leave comments and write code that is readable and to give descriptive meaningful names. So, even in coding the human interaction and basic understanding is still true.
Very helpful explanation of use cases. It made sense, as I imagined the use case perspective is sitting above both the user and system to document the "ping pong" between them, whereas user stories are written as if I was sitting in the chair of the user to document interaction from his/her perspective primarily. In a way, the difference between describing via 3rd person omniscient vs. first person singular.
Thanks so much for the information! I am really enjoying your videos! I have a question, if you don't mind. If you are working on a large system project with many different features, how do you decide where to break up the use cases? Or do you break up the use cases? Thanks
Hi Autumn, You want to make sure that each use case has a specific goal that is meaningful to the user and that the system can accomplish. The reality is that often as you start digging into use cases, the flow is more complex than you thought, and you begin to break them apart as you go.
Thanks for sharing Adam. That's such a key point in terms of getting to the right level of detail in a use case or any type of functional software requirement. Glad you picked up on that.
Hey. Thanks for the great video. I've got 2 questions about breaking the rules, if you don't mind. 1) What should I do if I have a vision of the algorithm behind the scenes and I want to capture this in requirements? Let's say we are developing a new feature that gets some tasks and processes them one by one in the background (asynchronously) and I want to specify in requirements how should it actually work (I mean the 'queue', statuses of tasks, logs, etc.). What would you do? I described this background logic in a separate use case with 'system' as an actor. Is this acceptable? 2) Also, some business analysts say that a 'fully-dressed' use cases are hard to read and scan (look through). So, many business analysts remove some of the unnecessary use case attributes. Even more, they say that if you have one or two minor variations/exceptions, then it's okay to include them right into the 'main scenario' as it improves the readability of the use case. So I wonder to know what you are thinking about it. Thank you!
HI Stanislav, There are definitely scenarios where it makes sense to do a system-level use case to specify specific business rules and logic, and it sounds like this might be the case for you. Once you know the rules, you can certainly decide to break them. We always teach those new to use cases to break out exceptions as it encourages strong analytical thinking. And what makes a short use case more readable can quickly make a more complex use case confusing. So, as always, use your judgement and collaborate with your team to apply best practices in a way that works for you.
Thank you Laura for the video. I am practicing BA and have a question relates to Use Case that hope you can help to explain. Given I know the starting point A and the ending point B. While analyzing the steps, I found that there may be some set of steps like: "ping - ping - pong" or "ping - pong - pong" or "ping - pong - pong - ping",... also work with the use case. I wonder which set of steps should I choose to put into the Use case document? Should I choose the first one I found, then go to another use case. Or should I keep analyzing until I found some more set, then compare them to select the most valuable one? When can I step to another use case? Thank you.
HI Hoang, It's not uncommon to have more than 1 user step or system steps in a row - you just wouldn't want the use case to be two lopsided, there should always be some back and forth. Typically a separate use case is only broken apart when there is a repeatable set of functionality that might be referenced by multiple use cases.
Laura, could you tell me the difference between use case diagrams and process flow diagrams and what point we create this during the agile scrum? Do we have separate documentation to create those or do we do it in jira?
As a next step, check out this video about analyzing a business process. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-5-r7oQwZ5Uo.html We don't teach use case diagrams at BTG, because we don't find them particularly practical and useful except in very rare situations. And there is no one answer to your question - finding the answer starts by learning these techniques and WHY you do them, and then forming a process that works for you and your stakeholders.
Hi Laura Here is one of the interview questions related to use case, so what should be the answer, please give your points Question: Suppose you have 30 applications built up and maintained by system 1, now the requirement is only 10 applications you need to move to system 2? how do you write use cases for this?
Hi Sowmya, That's a great interview question that enables you to show your practical application of use cases and system migration projects. It's out of scope for me to provide a full answer for you here, but I would suggest leaning on your past experience doing a project like this to provide an example of what you did.
@@BridgingtheGapBA Thank you! I am not from a BA background. I have experience as a QA, Now I want to switch my role as BA. So I got this question in of the Job interview.
Starting a BA career does not require a masters degree. We see more success with our participants going through a practical and application-focused BA training program, like what we offer with The Business Analyst Blueprint certification program. bridging-the-gap.com/business-analyst-blueprint
Hello Mam, is n’t the use case template is somewhat similar to business process analysis framework? Also please tell is use case is part of BRD or FRD?
Hi Laura, I have bought your book and other materials. I have displayed it all on my resume. I want to get into BA. After a year, I had no chance in getting in to BA role. Should I start as a trainee instead of BA Entry level?
Nes, There are a lot of factors to that decision, and we are not in a position to provide specific career advice here. But here's a video Laura did on entry-level business analyst roles, and how to know if they are a good fit for you. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-o0VUPkgEu7E.html&t
what is the user is another system which is interacting with your system and just one way. ex. System1 will do something which impacts system2 and then system2 has to perform a series of operations and alternative steps based on what System1 has done. there is also system3 which will get impacted due to system 2 changes . so how to capture this in use case
Hi Shakeel, System-to-system use cases is a more advanced and less common technique for getting into more technical requirements. However, the same basic concepts apply, your users are all systems. When working on the requirements, I would still start by modeling the user-system interaction (where "system" is a compilation of all 3 integrated systems) and the "user" is the actual human user who has a goal to achieve to get clear on the functional requirements first before digging deeper.
Here's a link to the form to download: www.bridging-the-gap.com/uctemplate/ If this doesn't work, please contact us at info@bridging-the-gap.com and we'll help you trouble shoot!
Great Video , Just my perception on how do i define/describe and Alternate flow would be - If lets say am able to navigate to a page by clicking on a hyperlink directly- This is the basic flow of the use case Now an alternative flow would be - To right click on the same URL copying the link and pasting the URL in a new window. An Alternative flow would describe how the same objective can be achieved in one or more different ways. Correct me if am wrong..Thanks.
Thanks for sharing. Best practice is not to use words like click in a use case, or other specific UI details. So different functions for executing the same system behavior would be captured as one alternate flow.
The material is fine, but the presentation is too verbose. I suggest cutting down the excess verbiage. The material would be clearer and easier to digest if the video was refined down to around 8-9 minutes.
