Nowadays, accountants are called upon by businesses to play significant role in system migration and other major business turnaround programmes. Business requirements are those deliverables that a project must convey if value is to be added, without it, measuring the success or failure of a project will be difficult.
Organizations constantly challenge finance professionals to ensure that their investments in IT yields the anticipated benefits and who else is better equipped to provide this input than an accountant who understands business languages and also use technology?
As a modern day accountant, you cannot shy away from assuming your vital role as a strategic business adviser and a partner during the ever changing and challenging business environment. You will always be called upon, so your best bet is to acquire skills that will help you deliver.
As an accountant working from the perspective of business analyst, one of your greatest tools that will allow you to quickly find your bearing in any business environment is your ability to write a good, high quality, and effective business requirement document. Trust me; it takes more than conventional accounting wisdom to write a meaningful business requirement document.
A business requirement document is likened to a business case but slightly different in the sense that while business case has some elements of marketing pitch, business requirement document that is written by a business analyst or an accountant is neutral- you can organise a debate later if you are not in agreement with this point.
This article is written for those accountants that have significant part to play during new system development and deployment. Business analysts with pure coding and programing skills would still benefit from this article. But, if you are one of the agile developers that completely misunderstood the concept of agility in programing and business solution developments, please don’t bother reading further.
Fundamental steps in writing a business requirement document
- Familiarise yourself with the unique business need of the company: every business is unique and has a unique burning issue that needs to be resolved uniquely. The first step in writing a bankable business requirement is to understand the unique position of a company within its industry. Classic business tools like Porter’s five forces and SWOT analysis can do this.
- Interview the end users of the legacy system to find out what they liked and disliked most in the old system: companies don’t just wake up one day and decide it is time to get rid of the old systems for a new one. A business need that is not met by the existing software must exist before a decision to either expand or upgrade the system is made. Through interaction with the users of the old system, unimaginable insight would be gained. This step provides useful information for the programmers.
- Gather information on the economic and technological landscape in the company’s industry: as an accountant working within the migration team, you must leverage on your strategic managerial accounting skill to gather relevant financial and non-financial information from both micro and macro environment of a business. By so doing, we will be able to tell if the identified difficulties in business processes are unique to our businesses or if it cuts across the industry. If the problem affects other companies, we must find out how they managed to solve it and then benchmark their solution and also learn from their mistakes.
- Set measurable criteria that the requirement can be tested against: it is a popular saying in performance management that you cannot manage what you cannot measure. For a useful business requirement document to be written, the deliverables of a project has to be identified and agreed upon ab initio. These deliverables are identified and agreed on during the user requirement stage of the project.
- Discuss with the developers and testers to have an idea of what the best practice is in the industry- this step is very important as you need to be satisfied that the kind of solution sought is feasible within the budget of the company.
- Do not produce documents for the sake of having documents; you must give ‘spirit’ to the requirement. One way of injecting life into business requirement document is to make sure that stakeholder’s inputs are given fair treatment. There is no point of engaging end user at the design and development stage of a project if their well-meaning inputs are ignored. It is better to argue it with them at the early stage than give them ‘unpleasant’ surprise at the end of it all.
- Avoid the use of jargons: this is to make sure that business process owner and managers understand what the business requirement document is talking about. A balance between the use of atomic approach and comprehensive approach is to be used. This also includes making sure that unnecessary details are omitted when possible.
What makes a good business requirement document?
At the very least, business requirement documents should reflect the classic Ws of all business processes as briefly introduced below:
- Why: you must understand the rationale behind the production of this document and then make that the document reflects this.
- What: state what this document is and what it is not.
- Who uses the document? The intended audience of the document should be stated.
- When: it is important that the document is properly dated- obviously.
- Where: include country where the document was prepared and highlight any legal requirements.
- How: technical or functional requirements procedures must be included
Components of requirement documents
- Bullet form Requirements
- Scope
- Plain language contents
- Structure
- Process models and diagram (pictures)
- Clearly defined goals
- Stakeholders
- Business use cases and user use cases
- Narratives
- Traceable and auditable
- Glossary
- Highlight the constraints of the projects and the proposed solution
- Agreed framework
- Reflects customer experience journey
Am sure you will agree with me that the process of writing effective business requirement document is what every accountant should be conversant with and that the skills required are not easily picked up from traditional training of accountants. Writing effective business requirement is a fundamental component of a business due diligence in the sense that it takes constant learning, practice and experience to be rounded in the art of writing quality, operational and effective business requirement document.
Thanks for reading
Please do leave your thoughts in the comment box below.
Leave a Reply