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?
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.