REQUIREMENTS AND

CUSTOMERS
1
Edited by:
Dr Ahmad Nabot
As with the previous story, the expectation gap comes as a rude surprise to all stakeholders.
2
THE EXPECTATION GAP
Two issues
 Without adequate customer involvement, the certain outcome at the end
of the project is an expectation gap, a gap between what customers
really need and what developers deliver based on what they heard at the
beginning of the project

 Requirements also get out of date because of changes that occur in the
business, so ongoing interactions with customers are vital

So how to minimize the gap ?

3
The best way to minimize the expectation gap is to arrange frequent contact
points with suitable customer representatives.

Each contact point affords an opportunity to close the expectation gap: what
the developer builds is more closely aligned with what the customer needs. 4
WHO IS A STAKEHOLDER?
A stakeholder is a (person, group, or organization)
 that is actively involved in a project,
 is affected by its process or outcome,
 or can influence its process or outcome.
 Stakeholders can be internal or external to the project team
and
to the developing organization.
 Stakeholders are considered key sources of requirements.

 Stakeholder analysis is an important part of requirements

development
5
WHO IS THE CUSTOMER?

 Customers are a subset of stakeholders.

 A customer is an (individual or organization) that derives either
direct or indirect benefit from a product.
 Software customers could request, pay for, select, specify, use, or
receive the output generated by a software product.
 The customers shown in the next Figure include the direct user,
indirect user, executive sponsor, procurement staff, and
acquirer.
 Some stakeholders are not customers, such as legal staff, suppliers,
contractors, and venture capitalists.
6
WHO IS THE CUSTOMER?
 User requirements should come from people who will actually use
the product, either directly or indirectly.
 These users (often called end users) are a subset of customers.
 Direct users will operate the product hands-on.
 Indirect users might receive outputs from the system without
touching it themselves, such as a warehouse manager who receives
an automatic report of daily warehouse activities by email.

 Users can describe the tasks they need to perform with the product,
the outputs they need, and the quality characteristics they expect
the product to exhibit.
7
 Potential The Figure
stakeholders identifies many
within the of the potential
project team, stakeholders in
these categories.
within the
Not all of these
developing
will apply to
organization, every project or
and outside situation, of
the course.
organization.

8
One way to help identify stakeholders is by answering the
following set of questions:
 Who is paying for the system?
 Who is going to use the system?
 Who is going to judge the fitness of the system for use?
 What agencies (government) and entities (nongovernment) regulate any aspect of the
system?
 What laws govern the construction, deployment, and operation of the system?
 Who is involved in any aspect of the specification, design, construction, testing,
maintenance, and retirement of the system?
 Who will be negatively affected if the system is built?
 Who else cares if this system exists or doesn’t exist?
 Who have we left out?
9
TWO EXAMPLES

A point of sale (POS) is a place where a customer executes the payment

for goods or services and where sales taxes may become payable.

Baggage handling is the process of transporting

passenger luggage from a check-in counter at a departure airport, onto
a plane cargo hold and then to a collection point at an arrival airport

10
let’s try this set of questions on the pet store POS system.
 Who is paying for the system?—pet store, consumers.
 Who is going to use the system?—cashiers, managers, customers (maybe if self-service is
provided). Who else?
 Who is going to judge the fitness of the system for use?—company execs, managers,
cashiers, customers. Who else?
 What agencies (government) and entities (nongovernment) regulate any aspect of the
system?—tax authorities, governing business entities, pet store organizations, better business
bureau. What else?
 What laws govern the construction, deployment, and operation of the system?— tax laws,
business, and trade laws. What else?
 Who is involved in any aspect of the specification, design, construction, testing,
maintenance, and retirement of the system?—various engineers, CFO, managers, cashiers.
We need to know them all.
 Who will be negatively affected if the system is built?—manual cash register makers,
inventory clerks. Who else?
 Who else cares if this system exists or doesn’t exist?—competitors, vendors of pet products.
Who else?
 Who have we left out? 11
“rich picture,” which shows various users along with their goals, wants, and needs.

12
STAKEHOLDER/USER CLASSES
 Once the stakeholder (including user) groups have been identified, it may
be necessary to divide these groups into classes to adequately address
their needs and desires. For example, we already saw in the POS system
that the stakeholder “pets” might consist of various kinds of animals with
different product needs that could influence system requirements.

 A stakeholder/user class subdivision is usually necessary when the

classes are large and/or heterogeneous. In many cases, class subdivision
will be needed for the collection of system users.

13
STAKEHOLDER/USER CLASSES
 For example, consider the baggage handling system, where users include the
following:

 System maintenance personnel (who will be making upgrades and fixes)

 Baggage handlers (who interact with the system by turning it on and off,
increasing/decreasing speed, and so on)
 Airline schedulers/dispatchers (who assign flights to baggage claim areas)
 Airport personnel (who reassign flights to different baggage claim areas)
 Airport managers and policy makers

14
STAKEHOLDER/USER CLASSES
For the pet store POS system user classes would include:
 Cashiers
 Managers
 System maintenance personnel (to make upgrades and fixes)
 Store customers
 Inventory/warehouse personnel (to enter inventory data)
 Accountants (to enter tax information)
 Sales department (to enter pricing and discounting information)

15
SELECTING A CHAMPION
 For each of these classes and subclasses, we need to select a
champion or representative sample of the group to interact with
during requirements elicitation.
 One approach could be to select a single representative for the group.
Such an approach would work well when the class is relatively small
and uniform in composition.
 Another strategy would be to select a small subset of the class. Such
an approach would apply when the class is large but we don’t want to
rely on a single person to represent the class.
 Once we have selected how we will seek input from each
stakeholder group we can select the appropriate elicitation
technique(s) to use. Requirements elicitation techniques will be
discussed later.
16
STAKEHOLDERS
PRIORITIZATION
 Because we have many stakeholders and some of their needs and
desires may conflict, we rank or prioritize the stakeholder classes to
help resolve these situations.

 Usually rank denotes the risk of not satisfying the stakeholder (e.g.,
legal requirements should be #1 unless you want to go to jail). Ranking
the stakeholders will lead to requirements prioritization, which is the
key to reconciliation and risk mitigation.

17
Partial Ranking of Stakeholders for the Pet Store POS
System
18
Partial Ranking of Stakeholders for the Baggage Handling System

19
REQUIREMENTS BILL OF RIGHTS FOR SOFTWARE CUSTOMERS
FOLLOWING ARE 10 RIGHTS THAT CUSTOMERS CAN EXPECT WHEN IT COMES TO REQUIREMENTS ISSUES.

20
REQUIREMENTS BILL OF RESPONSIBILITIES OF SOFTWARE CUSTOMERS
FOLLOWING ARE 10 RESPONSIBILITIES THAT CUSTOMERS HAVE.

21
REACHING AGREEMENT ON
REQUIREMENTS
 Reaching agreement on the requirements for the product to be
built, or for a specific portion of it, is at the core of the customer-
developer partnership. Multiple parties are involved in this
agreement:
Customers agree that the requirements address their needs.
Developers agree that they understand the requirements and
that they are feasible.
Testers agree that the requirements are verifiable.
Management agrees that the requirements will achieve their
business objectives.
Don’t use the sign-of as a weapon, changes are inevitable.

22
THE BUSINESS ANALYST
 The business analyst is the individual who has the primary responsibility
to elicit, analyze, document, and validate the needs of the project
stakeholders.
 The analyst serves as the principal interpreter through which
requirements flow between the customer community and the software
development team.
 The BA plays a central role in collecting and disseminating product
information, whereas the project manager takes the lead in communicating
project information.

23
The business analyst bridges communication
between customer and development stakeholders
24
 Business analyst is a project role, not necessarily a job title.
 Synonyms for business analyst include requirements analyst, systems
analyst, requirements engineer, requirements manager, application analyst,
business systems analyst, IT business analyst, and simply analyst.
 These job titles are used inconsistently from organization to
organization.
 One or more dedicated specialists could perform the role on a given
project or it could be assigned to team members who also perform other
project functions. These team members include project manager, product
manager, product owner, subject matter expert (SME), developer, and
sometimes even user.
25
THE BUSINESS ANALYST’S
TASKS
 The analyst must first understand the business objectives for the
project and then define user, functional, and quality requirements
that allow teams to estimate and plan the project and to design,
build, and verify the product.

 The BA is also a leader and a communicator, turning vague

customer notions into clear specifications that guide the software
team’s work.
26
Following Are some main Tasks of a business
analyst:
 Define business requirements
 Plan the requirements approach
 Identify project stakeholders and user classes
 Elicit requirements
 Analyze requirements
 Document requirements
Read the two
 Communicate requirements
pages about the
 Lead requirements validation description of the
 Facilitate requirements prioritization tasks
 Manage requirements
27
FEASIBILITY STUDIES
 A feasibility study decides whether or not the proposed system is
worthwhile
 A short focused study that checks – If the system contributes to
organizational objectives
–  If the system can be engineered using current technology and
within budget
–  If the system can be integrated with other systems that are used

28
REFERENCES
 This presentation material has been prepared from the references below:

29