Q&A – Inside Effective Requirements Documentation Inside Effective Requirements Documentation is all about knowing what information must be present in high quality business requirements documentation, and seeing how defects impact project performance. The session outlines how to simplify your strategy for documentation by focusing on the right information at the right time. What is effective documentation? It has quality – Clear, accurate, and complete It is useful - It serves the intended purpose and needs of intended audience It is efficient - Has all the needed information and none of the information that is unnecessary at this point in time
Below is a selection of participant questions from IAG Consulting’s webinar on Inside Effective Requirements Documentation with answers and explanations from VP Keith Ellis. To sign up for this, and other IAG webinars, visit: http://www.iag.biz/resources/webinar-events/
Q: How bad is it if the Business Requirements Document (BRD) refers to a specific system? In my company they usually have a solution in mind when they get to the BRD phase. This happens as we do a concept document that usually already points to a solution. Keith Ellis: This is not a good idea. You should be executing the activity with situational awareness (meaning: if you're pretty sure it's a package buy, then you tune your process to this). You really want to have clear articulation of the "what" the business wants to accomplish. Don't start with "how" to do it. If you move requirements into or in place of your 'concept' document creation process, the whole process will move faster.
Q: Do you have any recommendations as to what should precede a BRD? What would best prepare you for the BRD? KE: Generally you are setting the scope of analysis. You need this to create an 'elicitation plan' which is used to organize the stakeholders, define the specific tuning on deliverables, define specific techniques that will be used, and the communication with stakeholders. All this happens ‘pre’ BRD.
Q: When the developer has been conditioned to get the "how" from analysts, how do you suggest we bridge that gap? For more business analysis resources visit www.iag.biz
KE: You do it in two stages: get the "What" agreed to‌ then have another iteration to get the "How". It also gets you a great opportunity to negotiate up front what 'ideal' looks like from a content perspective to the developer team. Once you have this BRD format in place, it’s very easy to service whatever downstream request that might emerge.
Q: In the data model are you just describing the change or the old vs. new? KE: It depends on the engagement, but generally we are defining all. Where you tune this is in the picking up of new attribute or entity information which you might tag in the data dictionary as 'new' and ensure that these are better elaborated for developers.
Q: If I think that a detail is obvious how do I know where I have to stop? KE: You know the stopping points based on how you've broken the work down to begin with. You have certain processes to elaborate. These processes have certain activities, there is a process for these activities, and each process of an activity has variations and conditions that exist. It's a tree structure. With a strong foundation, it becomes very simple to determine if you have looked at all the branches. Knowing the level of detail on each branch depends on what the next steps in your SDLC look like. If it's a commercial application buy you don't need much more detail than the above (unless you expect a high degree of customization). If it is an offshore build, however, it had better be detailed.
Q: Where do you start if you're on your own, if your organization is not mature enough to complete all this as a team? KE: You really need an elicitation methodology that's solid. You'll run the same basic process using sequential series interviewing. BUT - what happens when executive #2 disagrees with executive #5 on a particular project? You'll spend a lot time trying to sort through all of this unless you do it using group sessions.
Q: Who does the actual writing of the BRD? It is one person or several? If several? How do you ensure flow of document and the same writing style? KE: It can be one or many. On large projects we do, we can have many authors all working into a common technology-based repository (just to add yet another layer of complexity). Consistency comes with standardization of methodology and technique - this will remove many of the issues. You can also do something simple like implement peer review to remove some of the issues of multiple authors on a report.
For more business analysis resources visit www.iag.biz