Eliciting business requirements is a critical skill for a business analyst. Although we hear the phrase business requirements over and over again by software vendors, by training companies, by business analysts of various industries, and by speakers in our IIBA chapter meetings – is everyone defining the term in the same way? I would like to define business requirements this way. Business requirements includes an emphasis on “why” and “what” operations and processes in the organization are necessary to be performed without an initial focus on the way they are performed, or more specifically “how” they are performed. The aim is to first recognize what is critical to the business, and why it is critical, before trying to develop solutions.
A very simple of example would be a business process which notifies a customer regarding their current order status. A customer may be contacted through email, phone, fax, an IVR solution, or directly via some other software like a CRM application etc. How the process is accomplished does not matter during business requirements but understanding why there is a need to make customer contact is important and additionally the information or data that needs to be communicated to the customer is also important. The mechanism to be used to accomplish this communication is not yet necessary and if determined too early limits the solution options.
Most people agree that Business Requirements include high level statements such as the project mission statement, business objectives, scope, out of scope items, any assumptions and the constraints in a project. I would add that a crucial part of the business requirements are details about the affected core business processes, the data needed by those processes, the business rules, and the external entities that will interface with the business system under investigation. Until we have a detailed understanding of the business processes and interfaces we will continue to be challenged in defining the right solutions. Without understanding the “why” and “what”, sometimes we fix what’s not broken. Other times in solving one problem others are created. As in the worn out phrase…”the devil is in the details” this really holds true in the BA’s world. A business analyst cannot be expected to enhance the levels of efficiency and effectiveness in business operations if he or she does not understand specifically where there are bottlenecks, redundancies, defects, and other inefficiencies that affect service, quality, timeliness or cost.
- Being part of the solution - May 1, 2012
- What’s the difference between ordinary and extraordinary… - March 14, 2011
- Lots of resources to learn about agile - May 10, 2010
- Agile and the BA – Part 1 - March 23, 2010
- Is It Really Tyranny of Best Practices? - February 20, 2010
- BAs are Bridge-Builders Instead of Bridges - January 25, 2010
- James Bond and Business Analysis - January 18, 2010
- Should the BA scribe at a team meeting? - August 4, 2009
- Why do we need detailed business requirements? - July 28, 2009
- Updated CBAP® Handbook now available for download - July 14, 2009