CHAPTER 6 Finding the

voice of the user

• Jeremy walked into the office of Ruth Gilbert, the director of the Drug Discovery Division at Contoso
Pharmaceuticals. Ruth had asked the information technology team that supported Contoso’s research
organization to build a new application to help the research chemists accelerate their exploration for new
drugs. Jeremy was assigned as the business analyst for the project.
• After introducing himself and discussing the project in broad terms, Jeremy said to Ruth, “I’d like to talk
with some of your chemists to understand their requirements for the system. Who might be some good
people to start with?” Ruth replied, “I did that same job for five years before I became the division director
three years ago. You don’t really need to talk to any of my people; I can tell you everything you need to
know about this project.”
• Jeremy was concerned. Scientific knowledge and technologies change quickly, so he wasn’t sure if Ruth
could adequately represent the current and future needs for users of this complex application. Perhaps
there were some internal politics going on that weren’t apparent and there was a good reason for Ruth to
create a buffer between Jeremy and the actual users.
• After some discussion, though, it became clear that Ruth didn’t want any of her people involved directly
with the project. “Okay,” Jeremy agreed reluctantly. “Maybe I can start by doing some document analysis
and bring questions I have to you. Can we set up a series of interviews for the next couple of weeks so I can
understand the kinds of things you expect your scientists to be able to do with this new system?” “Sorry,
I’m swamped right now,” Ruth told him. “I can give you a couple of hours in about three weeks to clarify
things you’re unsure about. Just go ahead and start writing the requirements. When we meet, then you
can ask me any questions you still have. I hope that will let you get the ball rolling on this project.”
• Success in software requirements, and hence in software development, depends
on getting the voice of the user close to the ear of the developer. To fnd the voice
of the user, take the following steps:
• Identify the different classes of users for your product.
• Select and work with individuals who represent each user class and other
stakeholder groups.
• Agree on who the requirements decision makers are for your project
• Customer involvement is the best way to avoid the expectation gap
• It’s not enough simply to ask a few customers or their manager what they want once or twice and
then start coding.
• If developers build exactly what customers initially request, they’ll probably have to build it again
because customers often don’t know what they really need.
• In addition, the BAs might not be talking to the right people or asking the right questions.
• The features that users present as their “wants” don’t necessarily equate to the functionality they
need to perform their tasks with the new product.
• To gain a more accurate view of user needs, the business analyst must collect a wide range of user
input, analyze and clarify it, and specify just what needs to be built to let users do their jobs.
• The BA has the lead responsibility for recording the new system’s necessary capabilities and properties
and for communicating that information to other stakeholders. This is an iterative process that takes
time.
• If you don’t invest the time to achieve this shared understanding—this common vision of the intended
product—the certain outcomes are rework, missed deadlines, cost overruns, and customer
dissatisfaction
User classes
• People often talk about “the user” for a software system as though all users
belong to a monolithic group with similar characteristics and needs.
• In reality, most products of any size appeal to a diversity of users with different
expectations and goals.
• Rather than thinking of “the user” in singular, spend some time identifying the
multiple user classes and their roles and privileges for your product.
Classifying users
• user class is a subset of the product’s users, which is a subset of the product’s customers,
which is a subset of its stakeholders.
• An individual can belong to multiple user classes.
• For example, an application’s administrator might also interact with it as an ordinary user
at times.
• A product’s users might differ—among other ways—in the following respects, and you can
group users into a number of distinct user classes based on these sorts of differences:
• Their access privilege or security levels (such as ordinary user, guest user, administrator)
• The tasks they perform during their business operations
• The features they use
• The frequency with which they use the product
• Their application domain experience and computer systems expertise
• The platforms they will be using (desktop PCs, laptop PCs, tablets, smartphones, specialized devices)
• Their native language
• Whether they will interact with the system directly or indirectly
Contd..
• A better way to identify user classes is to think about the tasks that various users will perform with the
system. All of those types of financial institutions will have tellers, employees who process loan
applications, business bankers, and so forth.
• The individuals who perform such activities—whether they are job titles or simply roles—will have similar
functional needs for the system across all of the financial institutions.
• Tellers all have to do more or less the same things, business bankers do more or less the same things, and
so on.
• More logical user class names for a banking system therefore might include teller, loan officer, business
banker, and branch manager.
• You might discover additional user classes by thinking of possible use cases, user stories, and process flows
and who might perform them.
• Certain user classes could be more important than others for a specific project.
• When resolving conflicts between requirements from different user classes or making priority decisions,
favored user classes receive preferential treatment.
• This doesn’t mean that the customers who are paying for the system (who might not be users at all) or
those who have the most political clout should necessarily be favored. It’s a matter of alignment with the
business objectives.
Contd..
• User classes need not be human beings.
• They could be software agents performing a service on behalf of a human user,
such as bots.
• Software agents can scan networks for information about goods and services,
assemble custom news feeds, process your incoming email, monitor physical
systems and networks for problems or intrusions, or perform data mining.
• Internet agents that probe websites for vulnerabilities or to generate spam are a
type of disfavored non-human user class.
Identifying your user classes
• Identify and characterize the different user classes for your product early in the
project so you can elicit requirements from representatives of each important
class.
• Start by asking the project sponsor who he expects to use the system.
• Then brainstorm as many user classes as you can think of.
• Don’t get nervous if there are dozens at this stage; you’ll condense and categorize
them later.
• It’s important not to overlook a user class, which can lead to problems later when
someone complains that the delivered solution doesn’t meet her needs.
• Try to pare the list down to about 15 or fewer distinct user classes
Contd..
• Various analysis models can help you identify user classes.
• A corporate organization chart can also help you discover potential users and
other stakeholders
• Nearly all of the potential users for the system are likely to be found somewhere
in this chart
• While performing stakeholder and user analysis, study the organization chart to
look for:
• Departments that participate in the business process.
• Departments that are affected by the business process.
• Departments or role names in which either direct or indirect users might be found.
• User classes that span multiple departments.
• Departments that might have an interface to external stakeholders outside the company
Contd..
• Document the user classes and their characteristics, responsibilities, and physical
locations in the software requirements specification (SRS) or in a requirements
plan for your project.
• Check that information against any information you might already have about
stakeholder profiles in the vision and scope document to avoid conflicts and
duplication.
• Include all pertinent information you have about each user class, such as its
relative or absolute size and which classes are favored.
• This will help the team prioritize change requests and conduct impact
assessments later on.
• Estimates of the volume and type of system transactions help the testers develop
a usage profile for the system so that they can plan their verification activities.
User personas
• To help bring your user classes to life, consider creating a persona for each one, a description
of a representative member of the user class (
• A persona is a description of a hypothetical, generic person who serves as a stand-in for a
group of users having similar characteristics and needs.
• You can use personas to help you understand the requirements and to design the user
experience to best meet the needs of specific user communities.
• A persona can serve as a placeholder when the BA doesn’t have an actual user representative
at hand.
• Rather than having progress come to a halt, the BA can envision a persona performing a
particular task or try to assess what the persona’s preferences would be, thereby drafting a
requirements starting point to be confirmed when an actual user is available.
• Persona details for a commercial customer include social and demographic characteristics and
behaviors, preferences, annoyances, and similar information.
• Make sure the personas you create truly are representative of their user class, based on
market, demographic, and ethnographic research
Contd..
• Here’s an example of a persona for one user class on the Chemical Tracking System:
• Fred, 41, has been a chemist at Contoso Pharmaceuticals since he received his
Ph.D. 14 years ago. He doesn’t have much patience with computers. Fred usually
works on two projects at a time in related chemical areas. His lab contains
approximately 300 bottles of chemicals and gas cylinders. On an average day, he’ll
need four new chemicals from the stockroom. Two of these will be commercial
chemicals in stock, one will need to be ordered, and one will come from the supply
of proprietary Contoso chemical samples. On occasion, Fred will need a hazardous
chemical that requires special training for safe handling. When he buys a chemical
for the first time, Fred wants the material safety data sheet emailed to him
automatically. Each year, Fred will synthesize about 20 new proprietary chemicals
to go into the stockroom. Fred wants a report of his chemical usage for the
previous month to be generated automatically and sent to him by email so that he
can monitor his chemical exposure.
Connecting with user representatives
• Every kind of project needs suitable representatives to provide the voice of the user.
• These users should be involved throughout the development life cycle, not just in an
isolated requirements phase at the beginning of the project.
• Each user class needs someone to speak for it.
• It’s easiest to gain access to actual users when you’re developing applications for
deployment within your own company.
• If you’re developing commercial software, you might engage people from your beta-
testing or early-release sites to provide requirements input much earlier in the
development process.
• Consider setting up focus groups of current users of your products or your competitors’
products.
• Instead of just guessing at what your users might want, ask some of them.
• One company asked a focus group to perform certain tasks with various digital cameras
and computers.
Contd..
• The results indicated that the company’s camera software took too long to
perform the most common operation because of a design decision that was made
to accommodate less likely scenarios as well.
• The company changed their next camera to reduce customer complaints about
speed.
• Be sure that the focus group represents the kinds of users whose needs should
drive your product development.
• Include both expert and less experienced customers.
• If your focus group represents only early adopters or blue-sky thinkers, you might
end up with many sophisticated and technically difficult requirements that few
customers find useful
Resolving conflicting requirements
• Someone must resolve conflicting requirements from different user classes,
reconcile inconsistencies, and arbitrate questions of scope that arise.
• The product champions or product owner can handle this in many, but likely not
all, cases.
• Early in the project, determine who the decision makers will be for requirements
issues
• If it’s not clear who is responsible for making these decisions or if the authorized
individuals abdicate their responsibilities, the decisions will fall to the developers
or analysts by default.
• Most of them don’t have the necessary knowledge and perspective to make the
best business decisions, though