Phone: (678) 366-1363 | Toll Free: (866) 675-2125

Why do we need detailed business requirements?

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. 

Comments

  1. I totally agree, but allow me to add that the BABOK 2.0 perspective helped me to put things in place. Once I start working in the right level and domain, things are discussed at the right time. Those levels would be:

    Business need – the main reason the project is being created.
    Business requirements – business goals and objectives that have to be achieved or helped by the project outcomes.
    Stakeholders requirements – probably the costumer notification from your example would be placed here, as “the costumer wants to be aware of what’s going on with the order”.
    Solution approach – what kind of solution are we thinking about in general therms (even for a new solution, most of the times you have an general idea of the kind of technology that will be involved).

    After that it gets easy to rate the solutions options and go ahead with the solution’s requirements that can be also analyzed in an iterative development life cycle. (take care not to transform this logical flow into a waterfall!).

    I believe that calling all requirements “business requirements” is a generalization that is becoming less and less useful and a source of lots of misunderstandings.

  2. Thanks Kerber – I do support the BABOK’s categorizations of requirements and I do concede that generally we do have a pretty good idea of the Solution Approach at the beginning of the project.

  3. On my projects, we break out requirements into business requirements, functional, and non-functional. We use use cases to discover the functional requirements.

    One thing with regard to business requirements is that we require detailed business requirements from the business. We work with the business to help them draft the text but in the end they own the document.

    With that being said, I do have a question. I noticed that the BABOK defines business requirements as high-level objectives and goals. Why high-level? In my opinion, for a business requirement to be useful, it has to be detailed. All of our system requirements (functional and non-functional) trace back to detailed requirements. To me, with all due respect, I do not see the value in high-level business requirements. The business requirements need to be detailed.

    Thoughts?

    Thanks,
    Brian

Leave a Reply