The Who, When, Why & How of Requirement Analysis

Requirement analysis is the process understanding what the user wants from a product or service. Many articles focus on what requirement analysis looks like and how it varies across industries. Very few discuss the who, when, why and how of requirement analysis. Here they are briefly:

Who? Analysts (usually business analysts).
When? Before a project and intermittently throughout.
Why? To save resources and prevent useless products.
How? Using questionnaires, face-to-face discussions, and techniques we’ll outline below.

There are nuances to each of these response. Let’s take a look at them below.

Who does requirement analysis?

Business analysts perform requirement analysis. That said, it is a general concept at the core. You’re simply looking to understand what the product’s final users expect from it. From that perspective, everyone performs requirement analysis in one way or another during production.

But in practice, it is not usually that simple. Requirement analysis in its purest form uses structured questionnaires and discussions to understand what the real user expectation is. Since this is a communication effort, requirement analysis is heavily based on intuition. It’s a skill you must learn through experience.

More often than not, business analysts are the ones performing structure the requirement analysis. They build up the skill of asking questions. Different companies may refer to the position differently, such as software systems analyst, systems analysts, managerial analysts, process analysts, and a variety of others.

The tasks for these roles may differ slightly, but they’re all based on the original business analyst role.

Wholistic approach

In some cases, companies take a wholistic approach to requirement analysis by employing all members in a team to seek requirements independently.

For example, in a B2C company, account managers may try to source information about final users via intermediaries. Developers may try to understand requirements through their networks. Project managers and product owners may call on experience, or do the analysis themselves.

But in the end, this information will come back to the business analyst who uses his/her experience to interpret the information gathered.

While it is very rarely a preconceived part of the hierarchy, business analysts receive requirements in advance from their superiors. This may be product owners who believe they already understand what the user wants. It could also be strategic decisions passed down from management.

In these cases, the business analyst role become one of pure execution. Their role is to translate and communicate the requirements to their team(s).

How do business analysts perform requirement analysis?

You will hear a lot about the steps to requirement analysis. Most people discuss eliciting, analyzing, and modeling. These are all valid steps that we’ll explore in other articles on Analyst Answers.

For now, let’s look more at what a business analyst would physically do in the overall requirement analysis process. Most of these would fall under a requirement elicitation umbrella. Check out the following steps to get a better idea.

Steps:

1. Write down the name of the client
2. If it’s not a client, skip to step #11
3. Read through all previous email correspondance that other members have had with the client
4. Write down a 1 sentence goal for the project that you understand form the emails
   • For example: “Joe’s Burger Shack wants his valued customers to be able to easily request their favorite burger quickly in the Joe’s Burger Shack app.”
5. Create a questionnaire to explore unknowns in the request
   • Example:
     1. Does the app have a membership function?
     2. Who built the application?
     3. How often do you spend on the app before leaving?
     4. How many items do you normally order?
     5. Do you have a favorite burger?
6. Meet Joe face-to-face
7. Ask Joe to give this to his customers, or go on site and ask several customers to respond to the questions
8. Collect the answers
9. Perform an analysis
   • For example, if none of the customers answer yes to quest 5, then the project goal is invalid
10. Rework the product goal until you identify what Joe’s customers really need
    • In our example, let’s say that they simply needed to see a picture of the burgers to place an order online, not a way to order their favorite burger
11. Define an initial profile of end users, made of at least the following
    1. Age
    2. Gender
    3. Education level
    4. Location
    5. Occupation
12. Define the problem these users are facing with the product or service
13. Develop a questionnaire that challenges this theory
14. Give it to those customers either digitally in mass, through a focus group, or in person
15. Analyze the results
16. Reformulate the goal as needed

Functionalities and Intuition

Thus far we’ve looked at the goal-setting part of requirement analysis. The next step is to analyze the functionalities in the same iterative, customer-centric way. The ultimate goal is that all functionalities have been tested on real people before the final product goes active.

This process is reflective of agile methodologies and the iterative process outlined in The Lean Startup.

There is, of course, an intuition that business analysts must built up over time in order to interpret responses to their questions. They become skilled question askers, identifying the best possible question to understand the necessary requirements for solving the problem.

This skill becomes an integral part of the “how.” It’s also one of the main reasons the same person should go through the requirements elicitation steps above. They will build the skill over time and ultimately perform better than anyone else.

Why do requirement analysis?

The rigid process of requirement analysis described above helps prevent technical teams from building products that nobody will want to use. In fact, the business analyst role materialized when software production took off.

Think about it. Before software development in the digital age, most products were physical. It was thus relatively easy to manufacture any kind of product as a prototype. That product could then go straight to customers for testing. You simply needed to order only one.

But with the invent of software came a bigger challenge. How could teams get a “prototype” of a piece of software? The production of even the smallest units took immense effort from teams that must collaborate extensively. And that’s just to get the prototype.

Requirement analysis helped these teams avoid going through entire functionality or product production cycles, only to find out the product doesn’t work. Ultimately, the Lean Startup developed the idea of the Minimum Viable Product — the smallest unit of software necessary to test.

This reflects the Lean Startup philosophy. The principal is that neither a team nor a company can effectively guess what customers really want. Why go through an entire production cycle, waste money and time, and be wrong? Instead, the principal says, we should build small parts and test them as we go.

When do business analysts execute requirement analysis?

Business analysts always initiate requirement analysis before the project starts. In fact, teams cannot start building until they know what requirements they will need to fulfill. If they do, it could make for a lot of extra work. This initial stage is called requirement elicitation — it makes up the biggest bulk of the process.

A lot of business analysts make the mistake of assuming that an initial elicitations is sufficient. They forget to, or lack the desire to, revise requirements throughout the project. You almost never get requirements 100% correct on the first try.

Sometimes tech teams get it wrong. As technical teams build up the project, you may identify lapses in communication or outputs that don’t align with the original vision. This is the point when business analysts must refocus their teams’ efforts on the original requirements.

Other times, external changes mean that functionalities need to be revised. A BA colleague of mine was helping her team build a “story” feature for a nascent social media website. By the time they were halfway through, other leading sites moved the location of the story button.

Then-present test groups responded positively to the location, but over time users follow the rythme of major social medias. She needed to change. That’s why performing requirements analysis on a regular basis through the product or functionality product cycle is a must.

You can liken the process to checkpoints during surgery. You go in for a pre-operational evaluation. Then you get an evaluation several times during the surgery to make sure there are no mistakes. Finally, you go through several checkups after the operation to make sure the surgery has indeed solved the problem.

Conclusion

Requirement analysis aims at preventing technical teams from making products or product features that nobody wants. It does so by gathering perceived requirements from clients or directly from end users before the project, then adapting those requirements throughout production.

Business analysts are often the designated role for requirement analysis. The process of eliciting requirements is more of a soft skill based on one’s ability to listen and “read through the lines” of what people say to find out what they need. It’s skill that takes intuition and time to build, so experienced business analysts take the lead.

One last time:

1. Who? Business analysts.
2. How? Through a series of questionnaires, meetings, and interpretations.
3. Why? To prevent useless products.
4. When? Before and throughout production.