Most of us, Business Analysts, are more familiar with gathering system requirements because they are more interesting to our organizations and customers than the user requirements. But user requirements are absolutely of equal importance if not more important that the system requirements. You may ask me why is that?

In this series of blogs, I am going to take you through understanding the importance of user requirements and how to gather them.
If the goal of your organization is to develop products that has a good reputation and requires less training and support in the backend (sells well, keeps customers happy, and produces referrals), your focus should be on the users of the product. The main reasons that drive customers away from products are:

Now what are user requirements?

According to the Business Analysis Body of Knowledge version 1.6 definition, "they are statements of the needs of a particular stakeholder or class of stakeholders. they describes the needs that a given stakeholder has and how that stakeholder will interact with a solution. They serve as a bridge between business requirements and the various classes of solution requirements.

They must be collected in order to determine the direction of the product. There are various sources of user requirements.

Have you ever been in an elicitation meeting and the users refers to some functionality in your product and you have absolutely no idea what they are talking about? Well, this has happened to me a few times. I was thrown in with the high level description of the product but had never seen the real product because the organization had only the "in-development" products. And, as a débutante in business analysis, I really didn't know what I was doing most of the time. But I have learned my lesson since then.
That's why, I believe the first commandment to a Product BA, is to KNOW THY PRODUCT.

You may ask, but how do i do that?

I wanted to expand a little bit more on your notion of users. In Part 2, I mentioned that there are group of users from which you can get great requirements about product. But as a Business Analyst, I don't want you to believe you are hanging at the high levels, so let's dig a bit deeper on this subject. Many of us Business Analyst fail to recognize the users of the products or services offered by an organization. We are more interested in our high level stakeholder that we don't spend much time with the user. Yes, this is the job of a usability analyst but why shouldn't we get more familiar with their approach?
Prior to choosing your methods, even the BABOK® recognizes

Call it Use Case, Scenarios, User Stories...etc depending on the methodology used by your organization, you have to create some kind of scenarios. When getting to know your product, you should have some high level scenarios developed with the help of other department.
Don't forget, that this is an iterative process. You may develop some high level scenarios and then refine them as you are learning more.

Scenarios are stories about the personas you just created. These stories describes how each personas would complete their jobs. There is a lot involved in creating scenarios. The things to consider are:

<< Start < Prev 1 2 3 4 5 Next > End >>
Page 5 of 5

Follow us