You can grab the Business Requirements Document TEMPLATE from the video in our Business Analysis Templates and Elicitation Questions Package here: the-business-analysis-doctor-self-paced-learning.thinkific.com/courses/business-analysis-template-package Also, your next video should be my tutorial on the Software Requirements Specification (SRS): ua-cam.com/video/M5DY3eTyhUA/v-deo.html
Thank you very much, u really don’t know how it helped specifically after the confusions that i get from AI when i asked for the best practice for BRD 😂
Oh wow! I'm so glad the content was able to help clarify the concept for you. Yes, sometimes AI can cause more harm than good for topics that you are not already familiar with.
Great video! This really clears up what makes a BRD effective. I’ve got a few tweaks to make to my own documents, especially around defining objectives and scope. Thanks for the awesome tips!
Wow, this tutorial contains so much useful information about BRDs! I like how you split down each component and clarified the distinctions between problem statements, goals, and objectives. The examples were very useful in connecting the SMART criteria and process maps. Do you have any ideas for dealing with stakeholder disagreements during the BRD sign-off process? Thank you for making these difficult subjects clear and actionable. Appreciate it so much!
Thank you! To handle stakeholder disagreements during the BRD sign-off process, focus on facilitating open, structured discussions to address concerns. Clearly document all points of disagreement and use techniques like prioritization matrices or impact assessments to evaluate each issue objectively. Emphasize the alignment of requirements with business goals and encourage stakeholders to focus on shared outcomes. If necessary, involve a neutral party, such as a project sponsor, to mediate and make final decisions. Ensure that all agreements are documented and communicated transparently to maintain accountability and foster trust. Let me know if this approach works for you moving forward!
This is well detailed and very useful. Thanks for the wonderful video. Hopefully we get some more on the functional and software requirements documents. Thank you🙏
Thanks for breaking down BRDs so clearly! The example really made the structure and key components easy to understand. How do you keep all stakeholders aligned throughout the project's lifecycle?
Hi, I’m searching for videos that provide overview of how the requirements documents work for my new consultants who were bringing in from the business, to teach them the tech. I have to share that in my 15+ years of working in healthcare data management, developing data products, I’ve never had a sponsor or senior executive look at a business requirements document. I wish!!!!! Love it though!
Ha! Yes, the sign-off process varies greatly by organization and industry. My background is in Banking and Finance and I've been at companies where the sponsor is expected to review and sign-off on the BRD and SRS. And then I've been at other companies where the Sponsor comes to the project kick-off meeting, then I don't see them again for the remainder of the project....lol.
Great tutorial! You explained the BRD framework in a clear and easy-to-understand manner, particularly when you underlined the distinction between business goals and objectives. Quick question: when dealing with projects that employ a hybrid methodology (part agile, part waterfall), do you believe it's better to change the BRD to incorporate high-level user stories from the start, or remain with the traditional style and change later? TIA!
Thanks for the feedback! In terms of your quest, I would incorporate the user stories from the start so that the information confirmed by the stakeholders doesn't get lost in translation from traditional to the stories.
Hey BA Doc! When it comes to estimate the time required to create a BRD from 0, for example for the project that you showed in the video, how long would you estimate the total creation? In general, when it comes to predicting the required time and effort, how would you do it, when you have so much dependencies (aligning with stakeholders, creating the document from scratch, revising it with your teammates, etc.)?
Yes, there are SO MANY variables that can impact this. A general common rule of thumb is to allocate 10-20% of the total project time to requirements gathering and analysis. So for a 10-week project, you would expect to spend 1-2 weeks on requirements. But this is just a starting point. I usually start with this and then use the bottom up estimation technique to calculate a more realistic estimate. You can also look at the the amount of time it took you to create the BRD from previous projects and adjust based on the relative size of the current project. I hope that helps.
So from watching the video my understanding is that the requirements in the BRD is just business requirements? And then example functional requirements document is created into more in-depth from each business requirement from the BRD. So functional requirements is a separate document
That's correct. While some organizations include all requirements in one document, it's best practice to include the business requirements and stakeholder requirements in the BRD document. Then create the SRS document for the detailed functional and non-functional requirements. You can learn more about the SRS in this video: ua-cam.com/video/M5DY3eTyhUA/v-deo.html
Oh wow! Thank you for that feedback! I'm glad you found the video to be helpful. Yes, some long courses miss the mark on delivering value to the students. I hope this info serves you well.
So is the brd , a high level overview ? contains the as is , to be , high level process flow and business rules . iam a lil confused as there are some who say .... " put everything int he brd" and others who say " keep the brd simple " and the functional requirement document (frd) extensive and detailed which one is the norm ??? cheers
Great question. Generally, it depends on the organization. The best practice, however, is to create a BRD with the high-level requirements first, then create a more detailed document such as an SRS or FRD afterward to outline the detailed specification. This is because your stakeholders should approve the BRD to confirm that everyone is in agreement on the solutions scope (high-level requirements) prior to putting in the effort of analyzing and decomposing the detailed requirements. It will greatly minimize wasted effort if you break them up into separate documents or have a living document where the BRD transitions into the SRS after the BRD is approved. I hope that helps. Also, be sure to check out the SRS tutorial here: ua-cam.com/video/M5DY3eTyhUA/v-deo.html
You can grab the Business Requirements Document TEMPLATE from the video in our Business Analysis Templates and Elicitation Questions Package here: the-business-analysis-doctor-self-paced-learning.thinkific.com/courses/business-analysis-template-package
Also, your next video should be my tutorial on the Software Requirements Specification (SRS): ua-cam.com/video/M5DY3eTyhUA/v-deo.html
Wao,This is the best explanation on BRD that i have seen, Thank yo BA Doctor.
Thank you for that feedback! I hope the info is a value add for you!
A very concise summary and great presentation. Thank you.
You are very welcome and thank your for the feedback! I hope the info is beneficial to you!
This has served as a very helpful reminder for what needs to go into a BRD, thanks!!
You are very welcome! I'm glad it was helpful to you.
Thank you very much, u really don’t know how it helped specifically after the confusions that i get from AI when i asked for the best practice for BRD 😂
Oh wow! I'm so glad the content was able to help clarify the concept for you. Yes, sometimes AI can cause more harm than good for topics that you are not already familiar with.
thank you so much, this is extremely easy to follow and very intuitive in BRD preparation
You are most welcome! I'm glad I was able to communicate the information in a way that resonates with you. I hope the information serves you well!
This was great! I’m excited!
Thank you! I'm glad you connected with the content. Nothing beats being excited about your career. Cheers!
Thank you for this useful info. Much more informative than many of the others I've come across.
You're welcome! I appreciate that feedback!
This one was comprehensive, thorough, and helpful!
Thank you so much for the kind feedback! It is greatly appreciated. Glad you found the information to be helpful!
Hi @thebadoc, thanks for putting out this video, it is one of the most simple yet effective explanations I've come across reg. BRD!
You are most welcome! And thank you for that kind feedback. I'm glad it is being consumed as intended. I hope the information serves you well.
Very precise and detail oriented.... Thank you....very helpful!
You are very welcome! Thanks for the kind words and for watching! I hope it serves you well.
This is a really great and simplified tutorial! Thank you Michael!
You're very welcome! I'm glad you were able to easily consume the information. Thanks for watching!
Thank you, Michael. Very well designed and simplified tutorial. Very helpful.
You are very welcome, Rahul! I'm glad I was able to present the information in a way that resonated with you! I hope the information serves you well.
I really needed this! Thank you so much.
You're so welcome! Glad to help!
The lecture is awesome, comprehensive and helpful ❤
Thank you for the positive feedback! I hope the information serves you well!
Hi Victoria are you from 3MTT?
This is wonderful lecture about business requirements, this is great
Thank you so much for the feedback and for watching! Glad you enjoyed it.
Wow this BRD video just nails it. Thanks Doctor White
You are very welcome and thank you for watching! Also, be on the lookout for the video on the SRD/FRD..
Awesome sir .. nice explanation.
Thank you for the feedback and for watching! Glad to help! Also be sure to watch the SRS tutorial! It complements this video very well!
awesome analysis on BRD. Thank you
You are very welcome! I hope it's helpful to you!
You're very good at this. Thank you for sharing your knowledge.
Hi, James! You are very welcome! Thank you so much for that feedback! I hope the info serves you well!
Great video! This really clears up what makes a BRD effective. I’ve got a few tweaks to make to my own documents, especially around defining objectives and scope. Thanks for the awesome tips!
You are most welcome! Glad I was able to add clarity to your understanding of this critical document.
Wow, this tutorial contains so much useful information about BRDs! I like how you split down each component and clarified the distinctions between problem statements, goals, and objectives. The examples were very useful in connecting the SMART criteria and process maps. Do you have any ideas for dealing with stakeholder disagreements during the BRD sign-off process? Thank you for making these difficult subjects clear and actionable. Appreciate it so much!
Thank you! To handle stakeholder disagreements during the BRD sign-off process, focus on facilitating open, structured discussions to address concerns. Clearly document all points of disagreement and use techniques like prioritization matrices or impact assessments to evaluate each issue objectively. Emphasize the alignment of requirements with business goals and encourage stakeholders to focus on shared outcomes. If necessary, involve a neutral party, such as a project sponsor, to mediate and make final decisions. Ensure that all agreements are documented and communicated transparently to maintain accountability and foster trust. Let me know if this approach works for you moving forward!
This is well detailed and very useful. Thanks for the wonderful video. Hopefully we get some more on the functional and software requirements documents. Thank you🙏
Glad you found this video useful and thank you for watching it! Yes, the FRD/SRS video will be released next, so be on the lookout!
Great video, thank you very much!
You are very welcome! Thank you so much for the feedback and for watching!
Thanks for breaking down BRDs so clearly! The example really made the structure and key components easy to understand. How do you keep all stakeholders aligned throughout the project's lifecycle?
Your welcome! In terms of keeping the stakeholders aligned, I found gaining consensus via requirement workshops to be very effective.
It was so informative. Thanks :)
You're very welcome! I hope the information serves you well.
Excellent content, great job! Thank you very much!
You are most welcome! And thank you for the feedback! I appreciate it!
Good presentation. Great job
Thank you! Glad to know you enjoyed the presentation.
Great job
I was so surprised by your voice lol great video
LOL..that's interesting! What were you expecting? Glad you enjoyed the content.
Thank you, It was very Informative session.
You are very welcome! I hope the information serves you well!
thank you very much for this insightful session, I really learned a lot
Hi, Rodney! You are very welcome. Glad to help. Also, be on the lookout for the SRS tutorial coming soon!
Awesome 👌
Thanks for the feedback! Glad you enjoyed the content!
Great 😃
Thanks for the feedback! Glad you enjoyed the content!
That was awesome!
Thank you for that feedback and for watching! Glad to be of service!
Hi, I’m searching for videos that provide overview of how the requirements documents work for my new consultants who were bringing in from the business, to teach them the tech.
I have to share that in my 15+ years of working in healthcare data management, developing data products, I’ve never had a sponsor or senior executive look at a business requirements document. I wish!!!!!
Love it though!
Ha! Yes, the sign-off process varies greatly by organization and industry. My background is in Banking and Finance and I've been at companies where the sponsor is expected to review and sign-off on the BRD and SRS. And then I've been at other companies where the Sponsor comes to the project kick-off meeting, then I don't see them again for the remainder of the project....lol.
Very interesting l like it thank you
You are very welcome! Glad you found the content to be interesting!
Great tutorial! You explained the BRD framework in a clear and easy-to-understand manner, particularly when you underlined the distinction between business goals and objectives. Quick question: when dealing with projects that employ a hybrid methodology (part agile, part waterfall), do you believe it's better to change the BRD to incorporate high-level user stories from the start, or remain with the traditional style and change later? TIA!
Thanks for the feedback! In terms of your quest, I would incorporate the user stories from the start so that the information confirmed by the stakeholders doesn't get lost in translation from traditional to the stories.
I would love to see something related to Reporting Requirements.
Would be helpful and it's hard to find about it.
Check out my tutorial on Software Requirement Specifications. I discuss reporting requirements there. ua-cam.com/video/M5DY3eTyhUA/v-deo.html
Hey BA Doc!
When it comes to estimate the time required to create a BRD from 0, for example for the project that you showed in the video, how long would you estimate the total creation?
In general, when it comes to predicting the required time and effort, how would you do it, when you have so much dependencies (aligning with stakeholders, creating the document from scratch, revising it with your teammates, etc.)?
Yes, there are SO MANY variables that can impact this. A general common rule of thumb is to allocate 10-20% of the total project time to requirements gathering and analysis. So for a 10-week project, you would expect to spend 1-2 weeks on requirements. But this is just a starting point. I usually start with this and then use the bottom up estimation technique to calculate a more realistic estimate. You can also look at the the amount of time it took you to create the BRD from previous projects and adjust based on the relative size of the current project. I hope that helps.
So from watching the video my understanding is that the requirements in the BRD is just business requirements? And then example functional requirements document is created into more in-depth from each business requirement from the BRD. So functional requirements is a separate document
That's correct. While some organizations include all requirements in one document, it's best practice to include the business requirements and stakeholder requirements in the BRD document. Then create the SRS document for the detailed functional and non-functional requirements. You can learn more about the SRS in this video: ua-cam.com/video/M5DY3eTyhUA/v-deo.html
@@thebadocthank you
Thank you very much.
You are very welcome! Glad to be of service.
It was useful to me
Excellent! Glad you found the information useful! Thanks for tuning in.
I am tired of long courses with no point, your video clip is better than most courses
Oh wow! Thank you for that feedback! I'm glad you found the video to be helpful. Yes, some long courses miss the mark on delivering value to the students. I hope this info serves you well.
Thanks so much!!!
You are very welcome! I hope you gained a lot from the video.
Thank you so much
You're most welcome! I hope you gained a lot from the video.
So is the brd , a high level overview ? contains the as is , to be , high level process flow and business rules .
iam a lil confused as there are some who say .... " put everything int he brd" and others who say " keep the brd simple " and the functional requirement document (frd) extensive and detailed
which one is the norm ???
cheers
Great question. Generally, it depends on the organization. The best practice, however, is to create a BRD with the high-level requirements first, then create a more detailed document such as an SRS or FRD afterward to outline the detailed specification. This is because your stakeholders should approve the BRD to confirm that everyone is in agreement on the solutions scope (high-level requirements) prior to putting in the effort of analyzing and decomposing the detailed requirements. It will greatly minimize wasted effort if you break them up into separate documents or have a living document where the BRD transitions into the SRS after the BRD is approved. I hope that helps. Also, be sure to check out the SRS tutorial here: ua-cam.com/video/M5DY3eTyhUA/v-deo.html
@@thebadoc awesomeness and thank you for clearing my doubt :) 🔱
Iam so glad I found your channel.... 👍
Cheers
@@Lord.murugan Me too! And you're welcome!
Thanks bro🎉
Hi, Deepak! You are very welcome!
Watching from kaduna state. Musa Danlami
Thank you so much for tuning in! I hope the information serves you well.
Frami Crescent
Thanks for watching!
044 Torrance Canyon
Thanks for stopping by! Appreciate the view!
042 Langworth Points
Thanks for watching
Spencer Meadows
Thanks for tuning in.
Prosacco Drives
Thanks for stopping by!
Jaida Street
Thanks for stopping by and watching.
039 Eveline Mountain
Thank you for stopping in to watch the content!
Benjamin Circles
Thanks for tuning in! Hope you enjoyed the content.
Heller Glen
Thank you for checking out the video!
Terrance Burgs
Thank you so much for tuning in!
Lourdes Harbors
Thanks for stopping by!
Collier Flats
Thanks for watching!
Jacobs Ways
Thanks for watching!
Marcella Mall
Appreciate the view. I hope the content serves you well.
Murray Forks
Thank you for tuning into the video!
Mathew Common
Appreciate the view!
Howe Knolls
Glad you were able to watch the video!
Upton Points
Appreciate the view! Hope you enjoyed it!
Prohaska Overpass
Thanks for watching!
Emanuel Villages
Thanks for stopping by!
Von Gateway
Glad you stopped by!
Flavio Mountains
Thanks for stopping by! I hope you enjoyed the content!
Veum Port
Thanks for tuning in!
Trisha Club
Thank you for watching!
34503 Luettgen Canyon
Thanks for watching! I hope the information serves you well.
24999 Haag Centers
Thanks for tuning it!
64398 Gerry Inlet
Thank you for tuning in!