Exploring the “Real” Business Requirements

Most organizations claim to value the importance of good requirements, but are often disappointed that nobody seems to have the time or support to make sure the requirements are clearly defined. During the requirement gathering process, customers provide their vendor with a lot of information about their problem. This information is generally not in a form appropriate for consumption by a development team. It must be first be filtered and analyzed in order to define the requirements accurately (which of course, is why they hire us). In this article, I want to focus on how to discover ‘real’ requirements, as this is perhaps the hardest part of the software development life cycle, and is often not given nearly enough consideration.

Sometimes, customers have only a vague idea of what they need, and it’s up to the analyst to ask the right questions and perform the necessary analysis in order to turn their vision into a formally-documented software requirements specification that can be later used as the basis for software development and design. I’ve compiled a list of questions that you can ask yourself and your clients whenever possible when reviewing the requirements. Asking these 3 basic questions can help us get one step closer to gathering the real business requirements and writing more detailed and accurate specification documents and use cases.

1. WHY – Ask “Why” and the answer will most likely take you to the kernel of the requirement: the user’s motivation

Many statements provided to us by the customers are not requirements. Before starting to design the solution, it is well worth the up-front effort to ensure that we are analyzing the root cause of the problem and not only the symptom of another issue. If this step is skipped, it may end up costing us a lot for what amounts to a ineffective solution that does not address the all-important root cause. Finding the real cause of the issue will help identify the solution that is long lasting and accurate.

A great technique to explore a problem and identify the possible root cause is the ‘Five Whys’. This technique requires the analyst to keep have to be asking ‘Why’ until you reach the root cause of the issue. Very often, the answer to the first “why” will prompt another “why” and the answer to the second “why” will prompt another and so on 1. Going through this exercise helps us achieve user goals, instead of simply cataloging all of the product’s features. In addition, writing down the “why’s” often helps both the customer and the development team remember these reasons later on down the line.

2. WHO – Who are the users and stakeholders?

During the analysis phase, discovering the real requirements can become very complex because the source of the requirements is not just one person but all of the people who are stakeholders in the project. Since different customers have different visions of what the business needs are, it is very important to identify who the key stakeholders are as it will help reconcile conflicting requirements. The main goal is to get hold of as much knowledge of the users as possible through interviews, observations, questionnaires, reports, etc.

Once the primary and secondary stakeholders are clearly identified, the next step is to work out which ones can properly represent their respective organizations, so you know who to concentrate on. The final step is to develop a good understanding of these most important stakeholders so that you know how they are likely to respond, and so that you can work out how to win their support 2.

One of the techniques used to define the stakeholders effectively is User Personification. Personas describe the user’s daily behavior patterns, allowing us to focus on users from the project’s point of view. Personas not only bring users to life by giving them personalities but also help us identify their motivations and expectations responsible for driving the system behavior. Once these user profiles have been created they help to keep the focus on the users and their needs instead of focusing on the end product deliverable.

3. WHAT – What value does it provide you?

Once the stakeholders have been identified, it is important to discover the value of implementing a particular feature or set of features, from their perspective. This often involves visiting their business environment when gathering the requirements and perhaps even shadowing them while they work.

One of the biggest disadvantages of using product requirements is that they represent a system that is assumed to satisfy the business requirements. And as we all know, the more the assumptions, the more likely they are to be wrong. Therefore, instead of asking the stakeholders requirements about a specific product or system, we should focus on the users’ required business objectives. This allows us to understand the real business deliverables which will provide value when delivered.

One way to discover the requirement from the user perspective is to create User Stories. User stories are often written by the customers that describe a scenario that the user find themselves in and talks about things that they need the system to do for them. The stories typically don’t involve a lot of technical jargon and are not limited to a single user interface, which makes it easier to acquire the real motivations behind the requirements. Once a user story has been prepared, it is important to derive the specific user tasks that the user must perform to successfully accomplish the story.

To conclude, different stakeholders often have different perceptions of the system to be developed and how it should work. That is why it’s crucial for any project’s success to clearly define and clarify the requirements by asking the right questions so that everyone is on same page and clearly understands them.

  1. The technique was originally developed by Sakichi Toyoda and was later used within Toyota Motor Corporation during the evolution of their manufacturing methodologies
  2. International Institute of Business Analysis (IIBA), Business Analysis Body of Knowledge, Version 2 (BABOK v2), International Institute of Business Analysis (IIBA), Toronto, 2009

Add a comment

Comment feed
The better to greet you with
No one will ever see this
Your pride and joy
The reason this comment form exists

The crew behind ASOT

We're a team of interactive, software, and business intelligence experts skilled in the design, construction, and management of online enterprise systems.

Visit The Jonah Group site

Get in touch with us