Digisign Business Requirements Document Template (BRD) Made Easy

Digisign business requirements document template brd

learn ba in the last video I talked about how regardless of whether you want to be a business process analyst or a business systems analyst when you're starting off in your career regardless which types of business analysts you want to be the core skill that all business analysts have to acquire first is the ability to produce business requirements and specifications so I talked about that in at length in the last video in this video I want to talk a little bit more about the difference between business requirements and specifications this is an area where a lot of new business analysts have a lot of difficulty because the challenge there is that there is no standard for what is a business requirement versus what is a specification and so for new business analysts there I see that they're constantly always seeking an answer to that question how do I know what to put in my BRD versus what I should put in my functional specification or my SRS document and the answer really to that is that there is no standard and it is unique to every situation it is unique to the company that you work for and at times it's even different depending on the project that you're working on at the same company but what I'm going to do in this video is I want to give you some guidance on how you can learn to make that judgment call on your own so on a project-by-project basis you as a business analyst have to be able to make a judgment call on what you should put in your business requirements document versus what you should put in your in your functional specification or your software requirement specification document and for a second here so you should learn how to make that judgment call and that is one of the hallmarks of what a inexperienced business analyst does because as you become more experienced as a business analyst you start you stop relying on things like templates and on things like standards that might come from the iba or they might come from the PMI you stop relying on those standards because you see how things actually work inside the company that you're working for and a big part of you being able to be effective in that environment is that you have to learn how to make the judgment call on a case-by-case basis so here's a little bit of advice on how to do that number one when you're trying to figure out whether something is a requirement or whether it's a specification you have to always consider the level of detail that you're dealing and there are three different levels of detail at which you can document two requirements and specifications the first level is what I like to call the client level or you can call the customer level depending on your company but the client and customer level is the level of detail this is the broadest level of detail and it's the primary audience for that is your customer or your client so if you're working inside a company the person on the business side of the company who's funding the project is the client or they're the customer that person normally is a senior level person director VP level president that person is responsible for making sure that the resources are available for your group to be able to produce the solution that you need to produce so they're the client at their level of detail you're talking very broadly about BYOD bullet point level of what it is that the the project is going to produce and so you're BR these could be a simple couple page document that basically outlines at a very high level what it is that the projects going to deliver that all goes into your PRD document the second level of detail is what I like to call the user or the operational level so the client who's funding the project is not going to be in your requirements meetings in most cases what they're gonna do is they're gonna tell you who the right people are within their organization who deals with the issues on a day to day basis and that person typically is the user of the system that you're putting into place and they're the person that works at the operational level to make sure that the that the clients area of business functions properly and so the user level detail you can split that depending on the situation into BRD or into specifications because the at the operational level depending on the situation of course you can have users or operational folks who understand system logic in a very clear way and so what you can do is that you can include that into the BRD because the PRD is really the contract between the business side and the IT side you include that into the BRD and you don't ask the client necessarily to read it all but you have to get them to rely on their operational folks to validate that what's written in the BRD is right so that's the second level of detail so we've covered the client level detail we've covered the user level detail and both of these different groups these different audiences for your be RDS in your space are on the business side the third level of detail is what I like to call the Builder level or the developer or the IT level this is the level of detail that you need in your requirement specifications at a grueling and excruciating level of detail that a developer needs to be able to make sure that they can write the code to satisfy the requirement and so that level of detail is almost always a functional specification level detail there is very rarely a situation where you would put that level of detail in a B Rd and the rare instances would be is that one you have a lot less time than you need to actually produce requirements and specifications so you don't make the difference between them and you produce one single set of documents that contains both requirements and specs that's the first instance that you would do that in second instance that you would do that in is if you're ever in a situation where the business folks are so savvy or they are so adamant and wanting to know the details that they want the details are something that they want to sign off on and so that's the second situation where you would actually include that builder level detail the developer level detail in your BRD documents for your business customers to sign off on in many cases and in many organizations the the company that you work for especially if it's a larger organization that has a very methodical way of implementing projects in those instances there's going to be a different set of documents that's produced for business requirements or BRD and a different set of documents that are produced for the functional specifications of the software specifications which which is all of the details of how the business requirements are actually supposed to work now those that's the so considering the level of detail and looking at those three different levels the detail is the first thing that you start considering when you're trying to decide is this a B Rd or is this a functional specification so I'm writing a use case I'm gonna a my gonna put that use case in my business requirements document or am I going to put that use case in my functional specification document right consider the level of detail at those three different levels who is your audience and who's signing off on which document the second piece of advice I would give the second consideration I would give there is that you depending on the situation that you're in what you should do is you should always consult the people who have the best chance of knowing and those people are usually the manager that you report to or the project manager that has been assigned to your project and if there is no project manager try to find a project manager who has experience if you're working in a company where there is no project management discipline what you have to do is you have to find the first person who would know the answer to that question and you have to approach them and say hey can you give me a little bit of advice on how I should structure my documents and who I should ask for what kind of sign off on and what you'll get in most cases is that people will tell you about their previous experiences especially if it's somebody that has had a lot of history doing the type of work that you're doing they will tell you about the history of what they've done and how things have gone based on the different ways that they've done them and that is a really really good starting point because that what that helps you do is it helps you to learn what the norms are what the cultural norms and what the unwritten procedures in your company are right when it comes to dealing with when it comes to dealing with dividing up requirements into business requirements versus specifications right and like I said this may change on a project to project basis because you might have one project that's one for that's for one line of business and then let's say for example you have a project that is for the finance department in your company your next project might be for the accounts and that accounts payable let's say might be for the warehousing unit inside your company those two are two completely different areas of your business you're gonna have very different clients and they're gonna have very different expectations of what their business requirements documents look like if they have any expectations at all and so on a project-by-project basis especially if you're working at a much larger company you're gonna you're gonna have to probably structure your documents your business requirements documents and your functional specifications is very very differently depending on what project you work on inside the same company so for a business analyst to be able to survive and to be able to thrive in that type of an environment you can't rely on any external advice well I don't want the advice but you can't rely on any external standards to dictate to you about what is a BRD versus what is a functional specification you have to learn to be able to make that judgment call on your own on a case-by-case basis now when you're first starting off it's very very difficult to do that because you don't have any of the experience and you don't have any of the background in the company but over time your goal should be to be able to look at a situation or hear about a project and immediately started thinking to yourself how am I going to structure my documents based on what I know about that client what's the most likely version of a business requirements document that they're likely gonna want to see and so you start thinking about that in advance as you become a little bit more experienced so that's what your goal should be but for the internal debate out there between what is a business requirement versus what is a functional specification or what is a software requirement specification that is the answer the answer is is that there is no standard and no amount of philosophical debate is going to solve that problem and no amount of philosophical debate about that issue is going to help you to come to any meaningful conclusions the answer is is that you have to learn how to make your own judgment calls based on the level of detail and based on the norms of the organization or the client that you're trying to satisfy with the with what it is that you're producing so that's what I wanted to get across in this video if you are interested in learning more about issues related to business analysis head over to the website I learned that BA and start reading some of the articles that I have published on their about the different subjects related to business analysis one of the articles that I've written there is related to it's very specifically related to how much technical input you should have when you're producing your requirements and specifications right it talks a lot about the different approaches that different people take it says there's one approach where you don't consult ite or the developers at all until you've produced your document you've gotten it signed off and you just kind of throw it over the fence there is that's not a good approach by the way the approach that you want to take is that you constantly want to be validating your requirements with the technical team to make sure that you can consider their implement implement to ability as you're producing the requirements and there's a lot of benefits to doing things that way and I talk a lot more about that in the article which is I believe it's called developer input or technical input into requirements something along those lines I'll put a link in the description but go and read that article specifically and if you have any questions leave them in the comment section and I'll try to address your questions either in the comment section or if it's if it's a big enough topic I'll make another video about it