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:

Part of my job as a Business Analyst, it is my responsibility to facilitate business process analysis meetings with a group of very knowledgeable folks. As I stood in front of my audience, I couldn't stop thinking: "What if I don't understand what is going on here? What if I can't comprehend the issues at hand? What if i steer this group to an outcome that is completely irrelevant to the issues at hand?" I was hired in the public health industry at the time and prior to that, I worked in the gaming industry, healthcare, computer software and hardware.

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

Follow us