Now what are 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.
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?
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.
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.