Trying to decide what goes into the BRD and what goes into the SRS can be a daunting task.
Here, I provide some guidance on how to make the judgement call.
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 from your career, regardless of which types of business analyst 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 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 body 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 suit in your functional specification or your software refinement 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 an 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 IIBA or they might come from the PMI. Do 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. 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 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. It’s 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 directorV.P. VIP 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. B D. Bullet point level of what it is that the project is going to produce and so you’ll be. It could be a simple couple of page document that basically outlines a very high level what it is that the project’s going to deliver. That all goes into your BRT 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 going to do is they’re going to 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 that the client’s area of business functions properly. And so the user level detail you can split that depending on the situation into BRT 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 BRT because the BRT is really the contract between the business side and theI.T. side you include that into the BRT 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 BRT 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 ideas and your specs are on the business side. The third level of detail is what I like to call the builder level or the developer or theI.T. level. This is the level of detail that you need in your requirements 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 requirements 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 PR deed and the rare instances would be is that. When.
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 is. If you’re ever in a situation where the business folks are so savvy or they are so adamant about wanting to know the details that they want the details of 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 BRT documents for your business customers to sign off on. In many cases and in many organizations. 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 ideas 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 of detail is the first thing that you start considering when you’re trying to decide. Is this. A priority. Or is this a functional specification. So I’m writing a use case. I’m going to am I going to put that use case and my business requirements document or am I going to put that use case in my functional specification document. Right. Consider the level of detail those three different levels. Who is your audience and who is 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 signoff. 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 the. And that is. A really really good starting point because.
That would 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 to 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 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 going to have very different expectations of what their business requirements documents look like. If they have any expectations at all and sold 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 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. Why don’t wanna sey advice but you can’t rely on any external standards to dictate to you about what is a body 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 start 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 going to want to see. And so you start thinking about that in advance as you become a little bit more expense so that’s what your goal should be.
But for the internal debate out there between what is a business requirement vs. 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 are 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 Web site. LearnedB.A. and start reading some of the articles that I have published on there about the different subjects related to business analysis. One of the articles that I have written there is related to. Its 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 consultI.T. 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. 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 ability. As you’re producing the requirements and there’s a lot of benefits to doing things that way. 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 comments section and I’ll try to address your questions either in the comments section or if it’s if it’s a big enough topic I’ll make another video about it.