Business Requirements Analysis T2 2017

vApproaches to requirements elicitation

vQuality Function Deployment with House
of Quality

Refs:
q Morgan Masters, “An Overview of Requirements Elicitation”,
Business Analyst Articles: Business Analysis & Systems
Analysis, 2010, modernanalyst.com.
q A.J. Lowe (2000): “The House of Quality Interactive Tutorial,”
URL: http://www.webducate.net/qfd/qfd.html
q K. Crow (2016): “Customer-Focused Development with QFD,” URL:
http://www.npd-solutions.com/qfd.html

1
Elicitation of Information

Elicitation of requirements is the process of

communication with stakeholders for the
purpose of discovering relevant information,
such as:

• stakeholder needs / problems

• requirements for systems / solution
• alignment of needs with requirements
• documenting all insights
• deciding what to do next

© Deakin University, Dept of Information Systems and Business Analytics 1

Business Requirements Analysis T2 2017
Traditional methods of eliciting
Collect Information
information:
• Interview people informed about
the operation and issues of the
current system and needs of the
system in the future activities;
• Observe workers at selected
times to see how data are
handled and what information
people need in their job;
• Study documents to discover
reported issues, policies, rules,
and directions as well as concrete
examples of the use of data and
information in the organisation;
• Survey people via questionnaires
to discover their specific issues
and their needs;
• Bringing together in one session, e.g. • Delphi method is an approach of
Group Techniques
JAD, Focus Group or Delphi, users,
sponsors, analysts and others to
discuss and review business /
system requirements;
• Using group support systems to
facilitate online sharing of ideas and
voicing opinions;
• Using tools to analyse the current
systems to discover new
requirements;
• Prototype poorly understood
requirements.
• Create simulations to engage end-
users in scenarios.
• Reuse requirements of existing
systems.
© Deakin University, Dept of Information Systems and Business Analytics
• Focus groups to find synergy and
contrasts between their views and
opinions;
• JAD meeting for collaborative
development of requirements and
designs;
• Delphi/ExpertLens technique to
facilitate online and focused
discussion to converge on a
common view.
Deliverables:
• Business objectives
• Information needed
• Data handled
• Processes transforming data
• Sequences and dependencies
• Rules governing data
• Policies and guidelines
• Events affecting data
structuring communication among
geographically distributed
individuals to deal with a complex
problem.
• The method relies on the facilitator
who sets the tasks, collects, compiles
and tabulates information, organises
ranking of the collected information.
• Delphi process includes:
• Setting questions or issues to be
debated;
• Collection of feedback from
individual contributors;
• Review and assessment of the
collected information by all
participants;
• Providing opportunities for
individuals to revise their views.
2
Business Requirements Analysis T2 2017

Planning and preparation: Conducting a session:

Elicitation Process
• Setting goals and objectives for – As a facilitator, the skills
the elicitation session; required are the ability to
• Preparing questions; converse in a professional
• Acquiring background knowledge business context using
of the subject matter; appropriate questioning
• Organising the environment for techniques;
conducting an effective elicitation – As a note taker, the skills
session. include the ability to analyse
what is being said without
imposing subjective ideas,
prejudices and feelings on the
elicitation subject.

Validating the model with Consolidate and model the

participants: information gained:
– Conduct follow up sessions • Consolidating notes;
to validate assumptions that • Producing structured models of
lead to the construction of a information contributed by a
model; number of participants;
• Elaborating the model by adding
– Provide feedback to information from other sources.
participants;
– Finalise decisions.
5
Requirements Elicitation
Focus on

This form Answers these questions -

which you already know
Purpose of the system Why is the system being designed?
Scope of the system Who will use the system and how often?
What is the expected growth of the system?
What areas of business does it affect?
What are the system interfaces?
Management objectives What do you want to gain from the system?
What measurable results do you expect?
Functions What functions will the system provide?
What is the priority of these functions?
For each one, what is "must" and "nice"?
Constraints What limitations need to be considered?
What are the deadlines?
What is the budget?
Any space, security, regulations constraints?
Can system support on-line processing?
Additional user resource What are the user requirements for additional
requirements staff, equipment and physical space?
Assumptions What decisions have already been made?
Open issues What unresolved questions should be
addressed prior to the session?
Participation list Who should attend the session?

© Deakin University, Dept of Information Systems and Business Analytics 3

Business Requirements Analysis T2 2017

Requirements
Alignment of Needs with
Having collected stakeholder needs and
requirements, the next issue is their
alignment. One method of achieving this
is:

• QFD with HOQ

• The ultimate goal of QFD is to • The method involves cross-

QFD & House of Quality?
What is the

translate subjective quality functional teams relying on a set

criteria into objective ones that
can be quantified and measured
and which can then be used to
design and manufacture the
product.
• QFD was developed by Yoji Akao
in Japan in 1966 and initially used
at the Mitsubishi Kobe Shipyard.
of matrices translating product
features from most general
(requirements) to most specific
(production details).
• At each stage the most important
product aspects are passed from
one matrix to the next.
• The matrix is called “the House of
Quality”.

© Deakin University, Dept of Information Systems and Business Analytics 4

Business Requirements Analysis T2 2017

The environment Project - Improve university facilities

Example: • Students: I want to have fun, pay little $$$ and get a big $$$ job at the end
• Publisher: I want to sell lots of books and if not then videos
• Practitioner: I want graduates with the lot to make lots of money for me
• Academic: I want to pump out as much knowledge and wisdom as possible
• University: I want to use as little resources and minimise trouble

University Academics
Temple of Wisdom
Students Endangered Species

The Winging Lot

$$$

ge
Resources Trouble ed
owl m
Kn Kn isdo
ow W
led
ge
Theory
Methods
Experienc
e

y
Theor
ds
Metho
Welcome to … Practitioner /
The Machine Employer
Publishers The Evil Empire
The Tree Killers
9

View business functional

To align needs with reqs
Purpose:

needs requirements Note on Terminology:

point
Academic Students to know Enable students to
As the purpose of a
topics attend intro lecture business project is
Students to know Enable students to often to build some
theory read textbook “system”, we will refer
Students to know Enable students to
methods attend tutorials to its stakeholders as
Students to reflect on Enable students to
“users” and the aim of
own knowledge undertake research business requirements
project analysis is to translate
Student Know topics Enable students to “business needs” into
watch videos “system requirements”.
Know methods of Enable students to
solving problems attend tutorials
Enable students to So…
have fun with games
Solve exam problems Enable students to QFD project = system
attend tutorials QFD customer = system user
QFD customer reqs = user needs
Practition Know theory Enable staff and
er Know methods students to read QFD engineer reqs = system
textbook reqs
Enable students to
attend tutorials
Apply theory and Enable students to
methods work experience
Gain experience

Problems Solutions
10

© Deakin University, Dept of Information Systems and Business Analytics 5

Business Requirements Analysis T2 2017

Beware of poor quality QFD software!

By hand? Or with the use of software?
Software
House of Quality:

http://www.edrawsoft.com/housequality.php
(Template Drawing Only) 11

• As in any business project, the first step in a QFD

project is to determine the system users (QFD

Another Example:
customers).
• Subsequently the user needs are identified (QFD
customer requirements), which are called “Voice of
Studying at the Uni Customer”.
• Simple tools are often used in this process, e.g. Affinity
Charts or Tree Diagrams.
• Each of business needs are entered into a HoQ matrix
and its user importance is also specified (here “weight”
of between 1 and 5).

• It is common to derive relative importance (weight) for

each of the needs (as %).
• Sometimes, for each user need we also define a
baseline, i.e. the minimum standard that any
considered solution must meet.
• In addition, the significance of each of the user needs
can also be analysed from several perspectives, e.g.
• Satisfaction rating
• Competitive products
• Improvement factors
• Sales points
• Here we use a subjective importance factors identified by users
themselves.

12

© Deakin University, Dept of Information Systems and Business Analytics 6

Business Requirements Analysis T2 2017

• In a similar way, the “Voice of Engineer” is determined. In

the process:
Another Example: • We identify the system
features (or technology
Studying at the Uni capabilities) that need to
be developed or acquired
to satisfy the user needs.
• As a result we will provide
a list of functional system
requirements (or their
groups).
• Often a super-list or a
hierarchy of available
technologies have already
been developed by
system architects.

• Sometimes for each

functional requirement, we
also define their “target”,
which identifies
performance or quality
requirements that must be
met by the system – these
correspond to non-
functional requirements.

13

Another Example:
Studying at the Uni The relationship matrix
allows to determine the
relationships between user
needs and the system
ability to meet those needs.
The strength of the
relationship can either be
weak, moderate, or strong
(represented as numbers,
e.g. 1, 3 or 9).

These relationships are

often represented in
symbolic fashion.

14

© Deakin University, Dept of Information Systems and Business Analytics 7

Business Requirements Analysis T2 2017
Another Example:
Studying at the Uni
The HoQ allows us to determine:
What can HoQ tell you?
House of Quality:
• what are the user needs and how
important they are to the user;
• what system components are needed
to fulfil what user needs and to what
extent;
• what is the overall importance of
each system component to the
success of the project;
• what are the synergies and conflicts
between the groups of system
components;
• what system requirements need to
be considered first for further
refinement (in the HoQ matrix of the
next QFD stage).
© Deakin University, Dept of Information Systems and Business Analytics
The correlation matrix
allows to examine how
each of the technical
requirements
impact each other.
The correlation matrix
resembles the roof over
the matrix thus making
it look like a house.
The requirement’s
absolute importance
is given as a weighted
sum of each strength
multiplied by the
importance of the
corresponding need.
The relative
importance is
represented as a
percentage across all
requirements.
15
The extended HoQ also:
• provides detailed analysis of
factors related to the
customer satisfaction,
product improvements and
competitiveness, and sales
opportunities;
• allows more detailed analysis
of required changes to the
product design to make it
competitive against other
products;
• difficulties and risks faced by
designers when aiming for
target product
improvements.
16
8
Business Requirements Analysis T2 2017

Summary • The House of Quality is the main tool of the QFD process.
• It starts with identification of the Voice of Customer, i.e. all
system users and their needs, as well as, the importance of
each of these needs to the users.
• Next we determine the Voice of Engineer, i.e. all system
features and capabilities described by the system requirements.
• Relationships between user needs and system requirements are
then defined in terms of the strength between these two
groups.
• This characterisation allows us to calculate the absolute
importance of each system requirements to the project.
• Having determined the most important system requirements,
we then assess their interdependencies – both positive and
negative.
• The results of the analysis conducted with the
need-requirements HoQ can be used in further
system refinement into design elements and their
later development cycle.

17

© Deakin University, Dept of Information Systems and Business Analytics 9