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 be leave you 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 that we need to determine the requirement elicitation stakeholders (BABOK vs. 1.6). Well, yes, there are the stakeholders of the project and there are also those who will use the end product of the project: The Mud on the boot folks! Most of the time, we fail to bring them in the picture and if a Business Analyst wants to be successful at gathering the user requirements, they must make sure they consider this group.
That said, how do you go about getting to know your users?
1. Create a User Profile
How do you know who are your users? Depending on industries, your users may be fixed or may be spread. For example, if you are going to develop requirement for a software that will go on a cell phone, you will have a variety of users, older folks who may have some challenges picking up on the technology, the young folks who will try to break the features, and the busy middle aged users who may feel that it's a waste of money to have more features and higher price.
And there are your other organization whose users will remain fixed, such as software developed for children learning computers. You will have a fixed group mostly!
A user profile is a detailed description of the users' attributes (experience level, age range, education, job title or role, work hours, user category...etc)
You and go in as much detail as you want! There are so many usability books that go into detail about this.
The user profile is a great help with scoping the issues you want to deal with as well. If you don't think you want to deal with the issues of technology challenged users because you believe they represent a small group of your users then you have part of your scope statement right there :). It can also give you the availability of your users if you wanted to perform job shadowing ... etc
If you hade a big amount of data and you didn't know how to go about figuring it out the characteristic of your users, use the affinity diagram to sort and organize your data.
2. Build Personas
Now that you have a generic idea of who your users are, now it's time to get more specific. This is where I believe business analysis become an art and requires some imagination.
A persona is the details about a typical user within your user profile. Think about your user profile as a class or envelop of a set of humans - let's say teachers. Now your persona is the description of a teacher who could be female, 24 years old and single with a degree in Information Technology (instead of teaching).
So all the fields you used for your user profile, you will use them here too.
Personas give you a good sense of reality. Let's say you are in a meeting and you described the above teacher as Jane. Now, if I was to build a software for curriculum planning for teachers, I would say that Jane would need some instructions on how to build a curriculum where may be another persona, Ellen, who had gone through the teaching progam, may not need this feature. And a little secret on our scope again, if you have more Ellens than Jane, guess what? your stakeholders may decide that Janes may just get some manual training and this feature is not needed. Yes you got it, you have just reduced your scope future or you found you some good data to help negotiation if your stakeholders are pushing for all functionality with a fixed budget!
Once you have all this information, now you are ready to begin some conversation with your users to perform you following step: Gathering Requirement: Part 5: Create User Scenario
