Did I confuse you with the title of my post, I apologize if I did, what I wanted to say was what my manager always says, “how you say something is as important as what you say”, so the point is if you have an use case to explain the way you present it to the target audience is nearly as important as the use case.
In my previous post I was sharing my experience of looking at a requirements gathering session wearing a different hat, I will continue from there and so now that I have the requirements documented with me and the business user’s vision in my head how do I go about sharing this with the various other stakeholders involved in the implementation and how will I go about doing this, that is how will I say what I have to say[Symbol].
So I have completed a requirements gathering workshop and the next steps would be that I would get the business user who was part of the workshop to agree on the requirements that I have documented so that we are sure that we are In sync. Apart from the daily minutes circulated at the end of each day of the workshop, a comprehensive requirements document is shared with all the major stakeholders and once they give the go-ahead on the same, the gates will now be opened to welcome other stakeholders into the implementation. We will look at this situation involving many players from different streams next but before that a question would be how do I structure my requirements document aka the BRD, the Business Requirements Document, as it is intended for the business user I would elucidate on the requirements from his/her angle, the headings I would typically include in the BRD would be the Objective of the application envisioned, the Benefits the Business would accrue from implementing this vision, the pain areas and the inadequacies of the current system (could be manual and mail based in many cases) that is making the business to look for an alternative, how the application being considered for implementation would address these concerns from an operational, administrative and executive angle and finally the business processes involved in the implementation.
And returning to the scenario where the business has given the go-ahead based on the BRD, the other stakeholders now have to be run through the requirements, one such stakeholder would be the Project Manager and QA Manager identified for the implementation, then the Information Security or similar team in the organization who will typically study , understand and identify the data security threats and issues of the implementation in question, this according to me is an important stakeholder as now organizations are going the Cloud way, your organization will have certain guidelines and these are the best guys to assess your implementation vis-à-vis the established guidelines, the architects would be another team that you will bring in at this stage to study and approve the solution you are suggesting or recommend an alternate. Now would I share the same document with all these folks? Obviously not.
The Project Manager and the QA guy would expect the requirements spelled out comprehensively in the form of a Functional Requirements document which would provide the framework for their Technical or Low Level Requirements document and the Test Cases Repository, the Information Security team would prefer a modified version of the BRD with more emphasis on how the proposed application would interact with other application and the internet, and the architects would like a Solution Approach document which talks about the functionality of the application, details of the software (including the RDBMS if applicable) that will be used, the intended workflows and their touch points within and outside the proposed application and perhaps the load the system is supposed to handle on a daily basis, monthly, quarterly and annual basis (this is very important for Financial applications) and also the anticipated increase in the number of users on a yearly basis.
So this roughly is an outline of how I would typically handle my post requirements workshop tasks and life [Symbol] , and more on the various stakeholders, their expectations and the documents they would want from a BA in my next post….
Be Right Back folks…..