Your videos are one of the best materials for newbies in BA as well as professionals in BA. You made it so simple that a newbie would understand and you made it so detailed that a professional would need it. Thanks for all the effort you're putting into your videos.
Hi, Ajibola! You are most welcome! And thank you for your kind words. They really help motivate me to continue putting out valuable content! I hope it serves you well!
Great discussion on use case diagrams! The tips on keeping use case names short and action-oriented are super practical too. Thanks for making this topic so accessible!
You are most welcome. Glad it was helpful! And yes, keeping the use case simply and easy to comprehend is essential to the comprehension of the digram.
This was an extremely clear and informative breakdown of use case graphics! I enjoyed how you discussed the various interactions, such as "include" and "extend"; it definitely makes comprehending use cases a little easier. The banking system provides an excellent example of how everything is connected. Thank you for making this so easy to follow!
Thanks for this content - What I like about this channel is how the BA role and documentation is structured. Too many times BAs get mixed up and try to jump straight into functional requirements without fully developing the use case.
You are very welcome! And I totally agree with your point about jumping into functional requirements too soon. There are so many elements that need to be understood before properly eliciting and specifying these requirements.
Thank you for this simplified tutorial and for clarifying the positions and roles of the primary and secondary actors. Please can you do a session for documenting a Use Case Specification?
In the above example [complete online transaction] is at the top; is that the normal case, or can you have the resulting behavior e.g., [build a home] and the construction or acquire materials at the top
Hi, Donald! Yes, you can have the resulting behavior. The title of the use case diagram should clearly indicate the "main goal" of the completed use case. I hope that helps.
Excellent breakdown of use case diagrams! The example with the banking system really hit home for me. Those relationships can be hard, but you presented them so clearly. Quick question, while determining which actors to include, how do you know whether a system actor should be major or secondary? Thank you for the wonderful content, as always!
A system actor is considered major if it has a direct, critical role in achieving the primary goals of the use case or if it initiates or directly interacts with the main system processes. Secondary actors, on the other hand, provide support or are indirectly involved, such as systems or users that provide data inputs, receive outputs, or facilitate background tasks. To determine the type, evaluate the actor's influence on the system's core functionality and its relevance to the use case's primary objectives. I hope that helps!
Thanks Mr. White for this comprehensive tutorial. I had a better understanding of use case diagram and use case documentation after watching the relevant videos. However i have two questions to ask. One is regarding the placement of primary and secondary use case actors and the other is about a scenario where the use case diagram is too large and complex. Q1 => You made mention that the secondary actors should be placed in the right side of the use case diagram. What if an actor serves as a primary actor to a use case but also serves as secondary actor to another use case. Are we to duplicate the actor in both sides of the use case diagram? Q2 => Is it allowed to divide a use case diagram of a system into different sub-diagrams especially if the system use case diagram is too large and complex? Thank you.
You are very welcome! In regards to your questions, see my responses. 1. If you are representing an entire system (system use case) the actor's position will never change because you are looking at the entire use case from start to finish. If you are breaking the use case up by the base use cases, you represent the actor according to how they interact with that specific part of the use case. So the actor's position may change according to what you are focusing on. 2. Yes, you are able to divide the use case up by its components when the system use case is too complex. These are referred to as "base use cases" and also the "sub-use cases". It's also common to represent the use case components using sequence diagrams or activity diagrams. I hope that helps.
Literally, thank you so much! This helped me so much to study for an upcoming exam. I'll make sure to remember the theoritical basis you showed us and excel in that exam!
Hi Michael, thanks for the in-depth video. Learned quite a lot. I do have a question. In BA literature I've read elsewhere, I've seen them saying you should only include use cases in a diagram that enable users to achieve a goal. I saw that you have said the same in the tips list. I've heard that a use case such as 'Login' is not considered a goal since users don't really 'want' to login. It has no inherent business value so it's not the actual goal. It's just a task they have to do it in order to get to do something that has business value to reach a goal. But I see that you have still included 'Login' use case in the diagram. I'm confused about this because of the conflicting viewpoints I've been seeing. I'd love to know your rationale behind this.
Hi, Isuru! Great question. In the lesson, I spoke about "base use cases" and "sub-use cases". The base use cases represent the core functionality and generally have some goal. This is what is mostly referenced in discussions regarding use cases. The sub-use case, on the other hand, is a smaller, more specific use case that is part of a larger, overarching use case. It represents a distinct function or interaction instead of a goal. So here, the "login" use case would be a sub-use case and not a base use case. With that said, if the solution was focused on setting up password credentials or security profiles, there may be times where a login will serve as the base use case. I hope that helps.
@@thebadoc Thank you so much for answering. I'm just confused a bit, but what if the intranet is capable of assessing and doing core operations of a system, wouldn't it be apart of a system. Or maybe I'm confused about what a system is.
@@didistone8482 A "system" represents the software application that is being modeled in the use case. It's essentially the subject of the use case diagram.The system/application that is being examined in the project is considered the main system and is the primary focus of the use case. Use cases, actors, and their relationships are all centered around this main system. External systems are those that interact with the main system but are not part of the main system. These external systems are considered actors (which can be a human or a system). I hope that helps!
Thanks for this tutorial. How you do Use Case Diagram and Description for a change to an existing system like making existing fields manadory or removing a option from a drop down list.
You are very welcome! Based on what you've described, I'm thinking a use case would not be the best option. Maybe data mapping combined with a wire frame would be more effective for that type of change.
You're very welcome! And thank you for watching! Also, check out the videos on Use Case Descriptions and Sequence Diagrams if you haven't already. Those videos compliment this one very well.
![Use Case Description EXAMPLE [ Use Case Tutorial and Best Practices ]](http://i.ytimg.com/vi/WuNQLhx3dd8/mqdefault.jpg)
![Use Case Description EXAMPLE [ Use Case Tutorial and Best Practices ]](/img/tr.png)
Your videos are one of the best materials for newbies in BA as well as professionals in BA. You made it so simple that a newbie would understand and you made it so detailed that a professional would need it.
Thanks for all the effort you're putting into your videos.
Hi, Ajibola! You are most welcome! And thank you for your kind words. They really help motivate me to continue putting out valuable content! I hope it serves you well!
Great discussion on use case diagrams! The tips on keeping use case names short and action-oriented are super practical too. Thanks for making this topic so accessible!
You are most welcome. Glad it was helpful! And yes, keeping the use case simply and easy to comprehend is essential to the comprehension of the digram.
Definitely one of the best and most concise tutorials that I've seen on this topic. Thanks for sharing this!!
agree
Thanks for the feedback! Glad I could help.
This was an extremely clear and informative breakdown of use case graphics! I enjoyed how you discussed the various interactions, such as "include" and "extend"; it definitely makes comprehending use cases a little easier. The banking system provides an excellent example of how everything is connected. Thank you for making this so easy to follow!
You are most welcome! The use case diagram is widely used, so I'm glad I was able to help you gain a better understanding of this tool.
@@thebadoc Yes and I know you are helping more aspiring BAs! Thanks again!
Thanks for this! The explanation on the primary and secondary actors really helps!
You're very welcome! Yes, this is an area of confusion for many.
Your channel is a gold mine 😂
Excellent! Glad you are finding the content valuable. Thanks for the feedback.
@@thebadoc wc.
Thanks for this content - What I like about this channel is how the BA role and documentation is structured. Too many times BAs get mixed up and try to jump straight into functional requirements without fully developing the use case.
You are very welcome! And I totally agree with your point about jumping into functional requirements too soon. There are so many elements that need to be understood before properly eliciting and specifying these requirements.
Thank you for this simplified tutorial and for clarifying the positions and roles of the primary and secondary actors.
Please can you do a session for documenting a Use Case Specification?
Hi, Ikenna! You are most welcome! I'll look into making the use case description my next tutorial!
@@thebadoc Thank you!
@@greatiyk You're welcome! Be on the lookout!
@@greatiyk The use case description/specification video is now posted! Be sure to check it out!
12:29 thank you very much sir and 5:58 clear!
You care very welcome! Glad to help.
I like how you explained everything. Good work! The examples really made it easier to understand how to create use case diagrams. Thanks!
You are most welcome! I'm happy I was able to make your learning a little bit easier.
In the above example [complete online transaction] is at the top; is that the normal case, or can you have the resulting behavior e.g., [build a home] and the construction or acquire materials at the top
Hi, Donald! Yes, you can have the resulting behavior. The title of the use case diagram should clearly indicate the "main goal" of the completed use case. I hope that helps.
Excellent breakdown of use case diagrams! The example with the banking system really hit home for me. Those relationships can be hard, but you presented them so clearly. Quick question, while determining which actors to include, how do you know whether a system actor should be major or secondary? Thank you for the wonderful content, as always!
A system actor is considered major if it has a direct, critical role in achieving the primary goals of the use case or if it initiates or directly interacts with the main system processes. Secondary actors, on the other hand, provide support or are indirectly involved, such as systems or users that provide data inputs, receive outputs, or facilitate background tasks. To determine the type, evaluate the actor's influence on the system's core functionality and its relevance to the use case's primary objectives. I hope that helps!
Thanks Mr. White for this comprehensive tutorial. I had a better understanding of use case diagram and use case documentation after watching the relevant videos. However i have two questions to ask. One is regarding the placement of primary and secondary use case actors and the other is about a scenario where the use case diagram is too large and complex.
Q1 => You made mention that the secondary actors should be placed in the right side of the use case diagram. What if an actor serves as a primary actor to a use case but also serves as secondary actor to another use case. Are we to duplicate the actor in both sides of the use case diagram?
Q2 => Is it allowed to divide a use case diagram of a system into different sub-diagrams especially if the system use case diagram is too large and complex?
Thank you.
You are very welcome! In regards to your questions, see my responses.
1. If you are representing an entire system (system use case) the actor's position will never change because you are looking at the entire use case from start to finish. If you are breaking the use case up by the base use cases, you represent the actor according to how they interact with that specific part of the use case. So the actor's position may change according to what you are focusing on.
2. Yes, you are able to divide the use case up by its components when the system use case is too complex. These are referred to as "base use cases" and also the "sub-use cases". It's also common to represent the use case components using sequence diagrams or activity diagrams.
I hope that helps.
Literally, thank you so much! This helped me so much to study for an upcoming exam. I'll make sure to remember the theoritical basis you showed us and excel in that exam!
Excellent! I'm glad I was able to assist you in understanding the concepts for your exam! Let me know how things go on the exam!
You explain things very clear. Thank you so much.
You are so welcome! I'm happy to be able to explain the information in a way that resonates with you! Cheers!
Hi Michael, thanks for the in-depth video. Learned quite a lot. I do have a question.
In BA literature I've read elsewhere, I've seen them saying you should only include use cases in a diagram that enable users to achieve a goal. I saw that you have said the same in the tips list. I've heard that a use case such as 'Login' is not considered a goal since users don't really 'want' to login. It has no inherent business value so it's not the actual goal. It's just a task they have to do it in order to get to do something that has business value to reach a goal. But I see that you have still included 'Login' use case in the diagram.
I'm confused about this because of the conflicting viewpoints I've been seeing. I'd love to know your rationale behind this.
Hi, Isuru! Great question. In the lesson, I spoke about "base use cases" and "sub-use cases". The base use cases represent the core functionality and generally have some goal. This is what is mostly referenced in discussions regarding use cases. The sub-use case, on the other hand, is a smaller, more specific use case that is part of a larger, overarching use case. It represents a distinct function or interaction instead of a goal. So here, the "login" use case would be a sub-use case and not a base use case. With that said, if the solution was focused on setting up password credentials or security profiles, there may be times where a login will serve as the base use case. I hope that helps.
@@thebadoc Understood. Thanks so much for taking the time to answer. Appreciate it! 🙏
Can an Intranet be/is an Actor or is it part of the system
Yes, external systems can be actors. As long as it has some type of interaction with the core system of the use case.
@@thebadoc Thank you so much for answering. I'm just confused a bit, but what if the intranet is capable of assessing and doing core operations of a system, wouldn't it be apart of a system. Or maybe I'm confused about what a system is.
@@didistone8482 A "system" represents the software application that is being modeled in the use case. It's essentially the subject of the use case diagram.The system/application that is being examined in the project is considered the main system and is the primary focus of the use case. Use cases, actors, and their relationships are all centered around this main system. External systems are those that interact with the main system but are not part of the main system. These external systems are considered actors (which can be a human or a system). I hope that helps!
@@thebadoc Thank you it does. My course in basically Business Analysis. So I'm glad I found your channel. Thank you
@@didistone8482 You're welcome! I'm glad you found me as well! I hope all the content serves you well!
Thanks for this tutorial. How you do Use Case Diagram and Description for a change to an existing system like making existing fields manadory or removing a option from a drop down list.
You are very welcome! Based on what you've described, I'm thinking a use case would not be the best option. Maybe data mapping combined with a wire frame would be more effective for that type of change.
Great video
Thank you! Glad you enjoyed it.
This video is very helpful. Thank you so much.
You are very welcome! I hope it serves you well! Also, be sure to check out the other BA technique videos!
this was great.more examples would be superb 💯
I'm glad you found it helpful! And thanks for the feedback!
Best One
Thank you for the feedback! Glad you enjoyed the content!
amazing, thanks so much. very simple and clear.
You are very welcome! Glad you enjoyed it!
Thank you
You're very welcome! And thank you for watching! Also, check out the videos on Use Case Descriptions and Sequence Diagrams if you haven't already. Those videos compliment this one very well.
thanks
You're very welcome! Thank you so for the note!
Also, be sure to check out the video on Use Case DESCRIPTIONS here: th-cam.com/video/WuNQLhx3dd8/w-d-xo.html
value stream mapping, please
@@FedericoGomezg Thanks for the feedback! This has been noted! Be on the lookout!