business analysis

I frequently employ an exercise when teaching my courses; I ask the audience members to think for one moment of their idea of a "dream home". I ask them whether they thought about this before and the majority of them agree that yes, indeed over the course of their lives they have given this topic a lot of thought and can envision this building pretty well.

Then I tell them that they now have to sit down with me - and I am willing to invest as much time as needed - and describe the house to me in detail, down to the type of flooring in the kitchen and living room, colour of the walls in the master bedroom including the exact shade, specific type and model of faucets in the bathrooms, molding in the dining room area, etc., etc., etc. The goal of this exercise is that at the end of it I should have a detailed blueprint of the building and the bill of materials including product SKUs I can go to, say, Home Depot with and purchase all the necessary supplies.

After a couple of minutes someone in the room exclaims,

“But that is impossible! How can you expect us to know all the little details about the house?”

Why am I telling this story? The reason is that thinking that one can easily come up with a complete list of detailed requirements at the beginning of the project is a self-deception. Requirements elicitation is a long and at times painful process of probing, asking questions analyzing the preliminary results, coming up with more questions and investigating again.

Furthermore, once the technical experts sit down to have any kind of requirements elicitation interaction with customers or users, they (the users) do not necessarily provide the analysts with a structured model of requirements that follows a predefined taxonomy. In other words, the customers rarely start these conversations by saying, “I will cover all of the high-level business requirements first, followed by product features. And at the very end I will provide you with all the functions and attributes of the product".

The requirements management domain is by far the most advanced in the technology field where the requirements are (see Figure 1) traditionally broken into:

• Business Requirements (or problems, or objectives)
• Features (epics in the Agile world) and
• Functional and Non-Functional Requirements (user stories in Agile)

Requirements analysts in the IT and software development fields also have tools like use cases, constraints, business rules and data definitions to better define the detailed level requirements.

Here is an example of such hierarchy. Let us assume that a small business producer of, say, scented candles decided at one point that she wants to sell them online. What is the resulting Business Requirement?

• BR 1.0 “We need to sell our products online”

Features that naturally flow from it include but are not limited to:

• F 1.1 "Customer Login"
• F 1.2 “Product Catalog”
• F 1.3 “Search Function”
• F 1.4 “Shopping Basket”
• F 1.5 etc.

The features are later broken into functional and non-functional requirements. For example Feature 1.4 (Shopping Basket) can be broken into the following functional and non-functional requirements:

• FR 1.4.x “The user shall be able to add products to the shopping basket”
• NFR 1.4.x “The process of adding a product to the shopping basket shall not exceed 1 sec”