BUSINESS ANALYSIS

Sub Code - 632

Developed by
Prof. Pradeep Pendse

On behalf of
Prin. L.N. Welingkar Institute of Management Development & Research
! 

Advisory Board
Chairman
Prof. Dr. V.S. Prasad
Former Director (NAAC)
Former Vice-Chancellor
(Dr. B.R. Ambedkar Open University)

Board Members
1. Prof. Dr. Uday Salunkhe
 2. Dr. B.P. Sabale
 3. Prof. Dr. Vijay Khole
 4. Prof. Anuradha Deshmukh

Group Director
 Chancellor, D.Y. Patil University, Former Vice-Chancellor
 Former Director

Welingkar Institute of Navi Mumbai
 (Mumbai University) (YCMOU)
Management Ex Vice-Chancellor (YCMOU)

Program Design and Advisory Team

Prof. B.N. Chatterjee Mr. Manish Pitke

Dean – Marketing Faculty – Travel and Tourism
Welingkar Institute of Management, Mumbai Management Consultant

Prof. Kanu Doshi Prof. B.N. Chatterjee

Dean – Finance Dean – Marketing
Welingkar Institute of Management, Mumbai Welingkar Institute of Management, Mumbai

Prof. Dr. V.H. Iyer Mr. Smitesh Bhosale

Dean – Management Development Programs Faculty – Media and Advertising
Welingkar Institute of Management, Mumbai Founder of EVALUENZ

Prof. B.N. Chatterjee Prof. Vineel Bhurke

Dean – Marketing Faculty – Rural Management
Welingkar Institute of Management, Mumbai Welingkar Institute of Management, Mumbai

Prof. Venkat lyer Dr. Pravin Kumar Agrawal

Director – Intraspect Development Faculty – Healthcare Management
Manager Medical – Air India Ltd.

Prof. Dr. Pradeep Pendse Mrs. Margaret Vas

Dean – IT/Business Design Faculty – Hospitality
Welingkar Institute of Management, Mumbai Former Manager-Catering Services – Air India Ltd.

Prof. Sandeep Kelkar Mr. Anuj Pandey

Faculty – IT Publisher
Welingkar Institute of Management, Mumbai Management Books Publishing, Mumbai

Prof. Dr. Swapna Pradhan Course Editor

Faculty – Retail Prof. Dr. P.S. Rao
Welingkar Institute of Management, Mumbai Dean – Quality Systems
Welingkar Institute of Management, Mumbai

Prof. Bijoy B. Bhattacharyya Prof. B.N. Chatterjee

Dean – Banking Dean – Marketing
Welingkar Institute of Management, Mumbai Welingkar Institute of Management, Mumbai

Mr. P.M. Bendre Course Coordinators

Faculty – Operations Prof. Dr. Rajesh Aparnath
Former Quality Chief – Bosch Ltd. Head – PGDM (HB)
Welingkar Institute of Management, Mumbai

Mr. Ajay Prabhu Ms. Kirti Sampat

Faculty – International Business Assistant Manager – PGDM (HB)
Corporate Consultant Welingkar Institute of Management, Mumbai

Mr. A.S. Pillai Mr. Kishor Tamhankar

Faculty – Services Excellence Manager (Diploma Division)
Ex Senior V.P. (Sify) Welingkar Institute of Management, Mumbai

COPYRIGHT © by Prin. L.N. Welingkar Institute of Management Development & Research.

Printed and Published on behalf of Prin. L.N. Welingkar Institute of Management Development & Research, L.N. Road, Matunga (CR), Mumbai - 400 019.


ALL RIGHTS RESERVED. No part of this work covered by the copyright here on may be reproduced or used in any form or by any means – graphic,
electronic or mechanical, including photocopying, recording, taping, web distribution or information storage and retrieval systems – without the written
permission of the publisher.

NOT FOR SALE. FOR PRIVATE CIRCULATION ONLY.

1st Edition May 2018

 ABOUT THE AUTHOR

ABOUT THE AUTHOR

Prof. Dr. Pradeep Pendse BE, MMS, Ph.D. (all from University of
Mumbai) is at present the Dean for IT/e-Business/Business Design at
the Welingkar Institute of Management (WeSchool) which is among the top
20 B-Schools in India.

A pioneer in India in the areas of Project Leadership and Business

Analysis and he has trained over 10000 IT professionals from leading
IT organizations and is the founder President of the Mumbai Chapter of the
International Institute of Business Analysis (proposed). He is the first
Indian to author a book on Business Analysis (Prentice – 2008).

An avid teacher and he has been a visiting faculty to JBMIS, SP Jain,

NMIMS, TISS, IIT Mumbai and nearly 30 other institutes over the past 25
years – primarily in the areas of MIS, Business Analysis, IT Project
Management, Innovation Management, IT Strategy, e-Business and
General Management.

He is credited with designing/nurturing several unique programs/

courses such as the PGDM (e-Business), the PGDM (Business Design
& Innovation), a Case based General Management course called the
Integrative Manager and a program on Enterprise Risk Management
jointly with Deloitte – at WeSchool and the first edition of MMS (Systems),
the MCA program at VJTI and the IT curriculum for the SSC/HSC Board
Pune to name a few.

! !3
 ABOUT THE AUTHOR

He has also contributed to the Advisory Boards/Board of Studies/faculty

recruitment boards etc. of several institutions such as the VJTI, the Tata
Institute of Social Sciences, the ICFAI University (IBS School), the Business
Management Program for Legal Professionals, the PGDM for Family
Managed Businesses, the Executive PGDM program, the Healthcare
Management Program etc.

Apart from mentoring thousands of students on various campuses, he is a

Mentor for several faculty in these campuses and on advisory boards/
mentor for several entrepreneurial ventures.

Through the 1990s and early 2000s, Prof. Pendse founded and lead a 100+
software and IT consulting firm called Hauser Infotech Managers (P) Ltd.
for nearly 15 years and served over 100 leading corporates such as KEC
Intl. Ltd., Mahindra Group, CEAT, Mattel Toys etc. as a Consulting CIO.

! !4
 CONTENTS

Contents

Chapter No. Chapter Name Page No.

1 Business Analysis — An Overview 6-21

2 The IIBA Framework and IIBA BoK 22-29
3 Business Analysis Planning and Management 30-52
4 Requirements Elicitation, Gathering and Analysis 53-90
5 The Flow Perspective 91-128
6 The Information Perspective 129-139
7 The Dynamic Perspective 140-162
8 Business Rules Perspective 163-192
9 The Human Factors Perspective 193-215
10 Security and Compliance perspective 216-233
11 The Enterprise Perspective 234-260
12 Visualizing IT Based Solutions 261-292
13 Requirements Documentation 293-320

! !5
 BUSINESS ANALYSIS — AN OVERVIEW

Chapter 1
Business Analysis — An Overview
Objectives

After reading this chapter, you will be able to:

• Understand the evolution of Business Analysis as a distinct role in the IT

industry

• To understand the role of the Business Analyst in the IT service provider

industry, end-user industry and product based industries

• To understand the tasks and activities of a Business Analyst

Structure

1.1 Introduction to Business Analysis

1.2 Evolution of Business Analysis
1.3 Role of a Business Analyst
1.4 Tasks and Activities of a BA
1.5 What Makes A Good Business Analyst A Great Business Analysts
1.6 The 5 Secrets of Good Business Analysts
1.7 BA Roles in Product Companies
1.8 BA Roles in End-user Companies
1.9 Summary
1.10 Self Assessment Questions
1.11 Multiple Choice Questions

! !6
 BUSINESS ANALYSIS — AN OVERVIEW

1.1 Introduction To Business Analysis

Introduction to Business Analysis

Business Analysts have emerged to have a key role in recent business

scenarios. Some people think that the role of a Business Analyst is to make
money for the organization, which may not be true in direct context. But
indirectly, the action and decision taken by Business Analysts do leave an
impact on the financial prospects of the organization.

Who is A Business Analyst?

The term Business Analyst is used to describe someone who assesses an

existing business and its systems to identify business needs and resolve
business issues.

Business Analyst analyzes the enterprise and design organizations,

ministries as well as non-profit organizations. Business Analysts analyze
the business models as well as their association with technology. Business
Analysis includes at least four levels. They are as follows:

a. Strategic Planning: This level of analysis includes the evaluation of

strategic activities of the company must.

b. Business/Operation Model Analysis: This level includes the

identification as well as evaluation of policies and procedures of the
organization to do business.

c. Process Definition & Design: This level of analysis includes the

business process modeling, which is often the outcome of process
design and modeling.

d. IT & Technology Business Analysis: This level encompasses the

rules as well as needs for technical systems. This analysis is usually
encountered in the IT field.

! !7
 BUSINESS ANALYSIS — AN OVERVIEW

What does a Business Analyst Do?

A primary job responsibility of Business Analyst is to communicate with all

stakeholders & to elicit, analyze and validate the requirements for changes
to business processes, information systems, and policies.

A professional business analyst plays a big role in moving an organization

toward efficiency, productivity, and profitability.

In this chapter, we will see some basic perspective of a Business Analyst to

help the organization succeed.

The foremost priority for any business analyst will be to try understanding
following things:

1. Understand what business does and how it does

2. Determine how to improve existing business processes

3. Identify the steps or tasks to support the implementation of new

features

4. Design the new features to implement

5. Analyze the impact of implementing new features

6. Implement the new features

! !8
 BUSINESS ANALYSIS — AN OVERVIEW

Characteristics of a Good Business Analyst

Basically, a good business analyst is judged on these four attributes

1. Analytical skills: An outstanding analytical skill will separate out a

good business analyst. A good part of BA role includes analyzing data,
workflow, user or stakeholder’s inputs, documents, etc.

2. Leadership skills: Directing team members, forecasting budget,

helping team members with the problem, etc.

3. Business process and planning: Planning the project scope,

understanding and implementing requirement of project, identifying
resources required for the project and so on

4. Technical skill: If a business analyst is in the IT sector, few technical

aspects are expected to know like operating systems, hardware
capabilities, database concepts, networking, SDLC methodology, etc.

1.2 EVOLUTION OF BUSINESS ANALYSIS

Over the years, IT has become pervasive and is being applied to every
single human endeavour, from basic office automation to mainstream
business functions in industries such as banking, manufacturing, retail to
name a few and is now increasingly finding its way in every appliance,
device and equipment be a washing machine, car or a mobile phone. This
pervasive nature of IT has resulted in a need for knowing not just the
technology but the application domain.

! !9
 BUSINESS ANALYSIS — AN OVERVIEW

A parallel development to the evolving IT has been the software

development industry. Like most other industries, the software
development industry has grown from an individual craft (before 1970), to
mass production (80s and 90s – Software Factories), to Mass customization
(2000-2010) and is heading towards co-creation of solutions. Large
software companies (with strength of few thousand to a few lakh
professionals) are organized into small teams with each team providing an
exacting solution to clients. With long relationships with the same set of
clients, there is a gradual trust level leading to more openness in the
relationships. The Software company is now expected to proactively
suggest suitable and often times innovative solutions to solve clients’
business problems and even contribute to clients’ business success.

During the evolution of software development from a craft/art form to a

project form it was found time and again one of the main causes of failure
of software project was management of requirements.

As a result of these trends, software development has become more

organized and more roles have evolved. The customer facing and
application facing roles gradually separated from the technical roles of
design and development. The new Business Analyst role was carved out of
the erstwhile Systems Analysts’ role. The focus of the Business Analyst was
to understand the clients’ needs and translate them in a language suitable
for designers and developers. The emergence of this role in the early
2000s was also an attempt to overcome some of the limitations of the
erstwhile ‘all-rolled into one’ role of a Systems Analysts. The technical
orientation of the systems analysts was often seen as a cause of
communication gaps and poor formed requirements. Add to it the lack of
domain knowledge and skills to converse effectively in the language of the
domain became impediments and sources of frustration among users. The
process orientation of software development also brought in a desire to
systematize the process of Business Analysis.

Several frameworks and processes emerged. The formation of the

International Institute of Business Analysis (IIBA) around 2004 was a step
in that direction. Business Analysis was gradually emerging as a profession
with its own set of processes and methods, tools and techniques, tasks and
roles and knowledge areas and competencies and skills.

! !10
 BUSINESS ANALYSIS — AN OVERVIEW

1.3 ROLE OF A BUSINESS ANALYST

While the core role of a Business Analyst continues to be that of gathering

and documenting user requirements, in practice the role extends into other
related roles such as pre-sales and account management on the
marketing/customer facing side to that of a project leader (in smaller IT
companies) and functional testing in most cases. BAs with several years of
experience are also akin to Management consultants due to their vast
knowledge about business domains, solution vision, change management
skills etc. The role of a BA in pre-sales is required to ensure that correct
need identification and solution visualization and correct scoping and
estimation as early as the proposal stage itself – a stage in the project
which is often prone to incorrect assessment of requirements and scope
and over commitment in various ways leading to problems at the delivery
stages.

! !11
 BUSINESS ANALYSIS — AN OVERVIEW

1.4 TASKS AND ACTIVITIES OF A BA

It is obvious that from the foregoing, the tasks performed by a BA as a

part of his pure BA role could include but not limited to the following:

• Planning and monitoring requirements management activities

• Interacting with users and eliciting and gathering requirements
• Modelling and documenting requirements
• Analyzing requirements and visualizing a solution perspective
• Assessing the viability of possible solutions
• Evaluating and selecting from among technology options
• Acting as interface between development team and users
• Representing the user/client in the development environment and vetting
the developed solution
• Dealing with/managing change requests etc.

In addition, the specific tasks would be added depending on specific

additional roles. Thus, for example in the pre-sales role, the following could
be the tasks which may be added:

• Identifying company’s capability and preparing marketing collaterals

• Identifying target customers and analyzing their needs

• Accompanying sales team for initial discussions and quick study of

clients’ needs

• Study of formal tender documents/Request for proposal

• Visualising solutions and preparing responses to tenders and RFPs

• Presenting proposals to clients and Influencing clients about solutions

• Writing Case Studies of completed projects as reference material, etc.

! !12
 BUSINESS ANALYSIS — AN OVERVIEW

1.5 What makes a good business analyst a great business

analysts

Business Analysts are appreciated by stakeholders, recruiters and hiring

managers. They seem to have a wide variety of career options open to
them and are valued within their organization.

To progress in a role everyone tries to be the best at what they do, the
same goes for BA’s.

We have put together a list of 7 attributes which make a good Business

Analyst a great Business Analyst:

1. They cover the basics

Have the most important business analyst skills covered. Great BA's are
good communicators, problem-solvers, and think critically. They can create
requirements specifications, analyze requirements, create visual models,
facilitate elicitation sessions, and use the necessary business analyst tools.

2. They are resourceful

Business analysts know how to find the answers to questions and don’t
wait for the answers to come to them. They find alternative paths through
the organization and involve the right people at the right time. Great
business analysts rarely get stopped for long and can often work through
challenging situations to come through to a solution.

3. They grow their toolbox of skills

Great business analysts are not content to do the same things the same
way every time. Gaining confidence to apply wide variety of business
analysis techniques increases marketability and can make you more
efficient.
Great BA's select the right tool for the job instead of relying on their go-to
tools and making it work for every situation.

4. They create alignment and ownership around the solution

It’s really easy to be the one who writes down what the stakeholders ask
for. As a new BA, you might be in a role where you are expected to do this
or where it’s the biggest contribution you can make at first.
But great business analysts do more and this means that you are in the
middle of resolving conflicts and ensuring that when the solution is

! !13
 BUSINESS ANALYSIS — AN OVERVIEW

delivered, the business truly owns that this is what they wanted and is
prepared to use it.

5. They create clarity

Business analysts bring a unique blend of critically important soft skills and
analysis skills. Together these two skill sets help the business analyst
create clarity and clarity does not simply mean that you get sign-off on the
spec.

A great business analyst doesn’t rely on sign-offs and hundred-page

documents. They use analysis techniques to drill into details and ask
relevant questions. They get buy-in, not just sign-off, during the
verification and validation process and they get into the appropriate details
to ensure true clarity emerges.

6. They don't rely on cookies

Yes, developers and stakeholders like cookies. Who doesn’t? It’s nice to
feel appreciated for all of your hard work. But good business analysts don’t
rely on bribes to build and sustain positive relationships.
They use active listening techniques to ensure stakeholders feel heard.

They set clear expectations as a way to build trust, consistently follow

through on their commitments, and don’t make promises they can’t keep.

They honor confidentiality agreements, never talk behind anyone’s back,

and are generally seen as above office gossip.

Great business analysts are both professional and good to work with.

7. They have strong knowledge of Project Management

Great business analysts know how to manage within business analysis.

They are proactive and dependency aware.

They manage themselves to commitments and deadlines.

They get stakeholders involved at the right times and in the right ways and
keep everything moving.

! !14
 BUSINESS ANALYSIS — AN OVERVIEW

More than all of this, great business analysts have a strong eye for scope.
While it can be fun to figure out what we might pack if everything but the
kitchen sink fits into the car, great business analysts realize that
implementation constraints nearly always get in the way of achieving the
full vision the first time out, so they keep a close eye on value and
feasibility and guide their stakeholders toward a set of requirements that
can actually get implemented.

1.6 The 5 Secrets of good business analysts

Business Analysts are Jacks-of-all-Trades - and Masters of Some.

Perhaps the most multidisciplinary professional services role, BAs work

with all project stakeholders to elicit, analyze, communicate and validate
requirements for changes to business processes, policies and information
systems, as well as manage on-going stakeholder expectations and
energizing their atmosphere.

The International Institute of Business Analysis (IIBA) defines the role as

“an agent of change,” whose responsibilities are to “identify and define the
solutions that will maximize the value delivered by an organization to its
stakeholders.” This role is particularly important in specialized areas such
as custom software development, where BAs ensure that the development
team has a clear understanding of the customer’s overall needs and,
ultimately, makes sure that business objectives are met.

But, unfortunately, this seemingly endless list of responsibilities and

considerable creative flexibility means many BAs fall short. They often
spread themselves too thin, lack the requisite confidence to speak with
authority, or don’t understand fully the important role they play in
providing recommendations and guidance to the entire team. These
challenged BAs are “thermometers,” simply gauging what’s going on
around them and reporting the results -- but doing very little to change
them.

The rare BA is a “thermostat,” who’s able to alter the environment in order

to reach a desired outcome: the successful completion of a project. Many
BA’s excel in the following five areas:

! !15
 BUSINESS ANALYSIS — AN OVERVIEW

1. Building consensus: The success of a project/team often hinges on

the wide-ranging support of key stakeholders, including executives and
department heads. Obtaining buy-in from these important individuals is no
small feat, and the ability to obtain it is often mastered only after years of
on-the-job experience. A project’s/ team’s success also depends on the
ongoing, enthusiastic efforts of team members. A less-than-energetic effort
by these individuals will result in poor quality, missed deadlines and
personnel issues.

So, how do you get everyone on board? Any number of appropriate

strategies are available to facilitate the team decision-making process, but
one widely used approach is with Six Sigma-based consensus-building
tools. Six Sigma-based decision-making techniques involve using
prioritization matrices to rank the available options by a variety of objective
variables like cost and feasibility.

More complex than a simple list of “pros vs. cons,” this approach is
designed to produce the best outcome based only on the choices that are
available. For example, a project team must choose between 15 different
versions of software. To create consensus within the team, the BA develops
a matrix that includes 20 different variables, such as cost, ease of use and
operating system requirements, then has the team rank each software
version on each variable to arrive at the best choice.

2. Prioritizing among competing interests: BAs also work as

facilitators during the decision-making process. While they do not
necessarily drive subject-matter experts towards specific solutions, or
assume too much influence over project decisions, they enable
conversations and arbitrate territorial disputes among different
departments or individuals. This ensures that the most qualified decision
maker is heard and limits the impact of political or personality-based
considerations.

Additionally, projects often fail because of a lack of leadership,

inappropriate direction or insufficient emphasis on managing requirements.
To keep a team focused and organized, BAs also must understand team
psychology and use their top-notch people skills to remove or circumvent
barriers to success.

! !16
 BUSINESS ANALYSIS — AN OVERVIEW

3. Minimizing process: Process plays an important role in making sure

that products coming off the assembly line are identical, often with
tolerances of a millimeter or less.

Unfortunately, in most business applications, excessive adherence to

process can produce a similar result. Process often considers the
contributions of individuals as an interruption, a distraction that impedes
the quickest route from Point A to Point B.

Process can also contribute to inertia and apathy, which hinder creative
problem solving. BA are skilled at determining what processes are required
for the project to be executed properly – and which ones are superfluous.
For example, a BA might suggest streamlining a decision-making process
for purchase approvals or call attention to the fact that some employees
are being overly managed.

4. Facilitating healthy debate: On project teams, disagreement is not

necessarily something to avoid; in fact, it can often result in a better
outcome.

Often moderating or playing a lead role in meetings, BAs play crucial role
to fostering constructive debate by setting the tone and building trust
among all participants. They also make sure conversations which are
inclusive, positive and focused on the pertinent aspects of the project, not
individuals or personalities.

Elite BAs also interact with team members at their level and ensure team
members don’t feel vulnerable, which can destroy the creative process.

5. Minimizing anxiety and low morale: Anxiety often runs high when
team personalities clash. It’s normal – not everyone always gets along. But
it also can be prevented by creating norms and expectations within the
group and limiting the toxic effects of low morale.

It may sound simple, but BAs can foster one of the best habits of project
teams: to avoid criticism of clients, individuals or, really, anything except
the weather. A positive disposition is both infectious and highly productive,
so BAs are skilled at keeping the griping to a minimum. That extends to
the use of positive body language and non-confrontational phrases like
“what if,” which encourage collaboration and team problem solving.


! !17
 BUSINESS ANALYSIS — AN OVERVIEW

1.7 BA ROLES IN PRODUCT COMPANIES

The BA role in a company which builds generic products is akin to that of a

product manager. The BA has to understand the needs of a segment of
customers for which the product is being designed. His ability to visualize a
generic solution which can cater to the slightly varying needs of various
customers poses a unique challenge. The roles in the context of software
products is in the form of Functional consultants who understand the
functional side of the business (e.g., Finance or HR) and is able to map the
customers’ business processes in the functional area with the features
offered in the product. Here, knowledge of business domains, ability to
study the needs of a specific customer and the in-depth knowledge of his
own product and the ability to related customer needs to product features
makes the role challenging.

1.8 BA ROLES IN END-USER CORPORATES

While many of the extensions of the core BA role was discussed in the
context of software development companies, BA roles are fast emerging in
in-house IT departments of Corporates in every possible business domain.
The need to leverage IT for business success has lead to appointing
Business-oriented Chief Information Officers (as opposed to mere technical
leaders) and has lead to creating roles for BAs. The role of a BA in this
context is a combination of a Relationship manager/Account manager,
Project Manager, Business Analyst, IT Strategist, Change Manager and
Vendor Manager to varying degrees. This happens because in in-house IT
departments, the management expects the CIO and his team to think
about business processes and IT solutions which not merely align to
business strategy but at times influence and contribute to business
success. BAs in this role often are assigned to specific business units and
therefore treat these business units as their clients. Managing
expectations, initiating and convincing BUs to investing in IT in specific
areas, creating business impacts and maintaining relationship between IT
and the BU on the one side and the BU and vendors on the other side are
important aspects of a BA’s role. Since, BAs in this role often have to
outsource the actual development work, they may be required to strategize
for the solution, document the needs, select vendors, and manage the
project involving users and vendor personnel to achieve the stated goals.

! !18
 BUSINESS ANALYSIS — AN OVERVIEW

The role of the BA is thus growing in the industry and is diverse and
important.

1.9 SUMMARY

• The BA role has evolved along with the evolution of the Software
Industry.

• The BA role has been separated from the erstwhile Systems Analyst role
played by technical people. The BA role is client facing and the BA speaks
the language of the clients’ domain.

• BA role can range from pure play requirements management to Process

and IT strategy consulting at the other end.

• BAs can find a career path leading to project management or consulting

or pre-sales depending on whether they have inclination to line
leadership, analysis or customer interaction

• BAs are required both in software industry, product companies as well as

end-user corporate though the nature of their role would differ slightly

1.10 SELF ASSESSMENT QUESTIONS

1. Describe the evolution of Business analysis in the IT industry.

2. What is the role of the Business Analyst in IT service provider industry,

product companies and end-user companies.

3. Explain the tasks and activities of a Business Analyst.

! !19
 BUSINESS ANALYSIS — AN OVERVIEW

1.11 Multiple choice QUESTIONS

1. The new Business Analyst role was carved out of the erstwhile Systems
Analysts’ role.
a. True
b. False

2. The tasks performed by a Business Analysts, as a part of his pure

Business Analysts role, could include but not limited to which of the
following?
a. Planning and monitoring requirements of management activities
b. Interacting with users, eliciting and gathering requirements
c. Modelling and documenting requirements
d. All of the above

3. Business analysts bring a unique blend of critically important

__________, together these skill sets help the business analyst create
clarity.
a. Soft skills
b. Analysis skills.
c. Both A & B of the above
d. None of the above

4. The __________ has to understand the needs of a segment of

customers for which the product is being designed.
a. Functional consultants
b. Business analysts
c. Product manager
d. Customers

5. Which of the following is the secret of good business analysts that

separate the mediocre business analysts from a good one?
a. Have the Basics Covered
b. Are Resourceful
c. Grow their Toolbox of Skills
d. All of the above

Ans: 1 - (a), 2 - (d), 3 - (c), 4 - (b), 5 - (d)

! !20
 BUSINESS ANALYSIS — AN OVERVIEW

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture - Part 1

Video Lecture - Part 2


! !21
 THE IIBA FRAMEWORK AND IIBA BOK

Chapter 2
The IIBA Framework And IIBA BOK
Objectives

After reading this chapter, you will be able to:

• Overview of the Body of Knowledge (BoK) version 2.0 of the

International Institute of Business Analysis

• The knowledge areas outlined in the BoK

• Brief description of each knowledge area

Structure

2.1 Introduction to the IIBA and the IIBA Body of Knowledge

2.2 IIBA Ver 2.0 Framework and the Knowledge Areas

2.3 Summary

2.4 Self Assessment Questions

2.5 Multiple Choice Questions

! !22
 THE IIBA FRAMEWORK AND IIBA BOK

2.1 INTRODUCTION TO THE IIBA AND THE IIBA BODY OF

KNOWLEDGE

The International Institute of Business Analysis (the IIBA) is a one of the

leading professional bodies which has since 2004 attempted to give
Business Analysis the status of a profession. It has over the years
published a Body of Knowledge (BoK) which describes the broad framework
for Business Analysts. It describes the knowledge areas which a BA must
master.

At the time of writing this book, IIBA had very recently published the IIBA
BoK version 2.0. This was a substantial improvement over the previous
BoK version 1.6. What follows is a brief description of the BoK version 2.0.

2.2 IIBA VER 2.0 FRAMEWORK AND THE KNOWLEDGE

AREAS

The above figure shows the key knowledge areas IIBA's Body of Knowledge
version 2.0. Given below is a brief description about each of these
knowledge areas:

! !23
 THE IIBA FRAMEWORK AND IIBA BOK

1. Business Analysis Planning and Management

This emphasizes the need to treat Business Analysis as a project or a

subproject of the full lifecycle IT project. The implication is that the BA
must:

a. Plan the approach to conducting the BA phase.

b. Identify the tasks involved in the Business Analysis Phase.

c. Identify the risks associated with this phase.

d. Estimate the effort, time and costs required for this phase.

e. Allocate the required resources.

f. Assign the roles and responsibilities to the BAs and associated team
members.

2. Enterprise Analysis

a. Increasingly business applications must perform within a larger context

of the organization/enterprise and its socio-economic context. The
competitive positioning of the enterprise, the industry lifecycle, the
overall economic outlook, the business strategy, the top management
view about technology, the organization form and culture, the people,
experience with technology, the various systems and business processes
which the proposed IT application must interface with and several such
factors – a study of all such contextual factors is known as Enterprise
Analysis.

b. Enterprise Analysis could consist of:

i. Establishment of a Business Case for the proposed IT solution
ii. Conducting a feasibility study
iii. Study of the organizational context
iv. Stakeholder analysis
v. Various organizational standards, expectations from the Corporate/
Group HQ, etc.

! !24
 THE IIBA FRAMEWORK AND IIBA BOK

3. Requirements Analysis

a. The actual conduct of the study of a business process, understanding

the needs of various users and stakeholders etc constitutes
requirements analysis.

b. Requirements analysis focuses on a study of the existing system/

business process, the stakeholder expectations about the new
solution.

c. Modelling and understanding of these needs and solution vision.

4. Elicitation

a. Elicitation is a general term used to the describe the act of creating a

favourable context which leads to a user’s sharing of his needs and
expectations. This could involve establishing a rapport, influencing
the users, asking and extracting information, even shadowing a user
or observing a user as he goes about his/her daily task.

b. E l i c i t a t i o n r e q u i r e s s t r o n g c o m m u n i c a t i o n , o b s e r va t i o n ,
inquisitiveness, listening skills, influencing skills among others.

c. Elicitation skills are required at practically all the stages of a Business

analysis project.

5. Requirements Management and Communication

a. Requirements Management is about managing the activities and

tasks associated with requirements gathering and analysis. These
activities and tasks are identified and planned during the BA planning
phase and executed during these requirements management phase.

b. Among other things, requirements management calls for monitoring

and managing the requirements related activities, modeling and
documentation of requirements and communicating the requirements
to various stakeholders in a language and at a level appropriate to
each stakeholder.

! !25
 THE IIBA FRAMEWORK AND IIBA BOK

6. Solution Assessment and Validation

a. The BA after understanding the process also attempts to understand

users'/stakeholders' expectations about a solution. In practice, many
BAs also visualize pieces of the solutions and verify their acceptability
from a users'/stakeholders' point of view.

b. In practice BAs and designers tend to visualize multiple solution

alternatives and the purpose of this phase is to select the most
promising and most viable of these alternative solutions.

c. Solution assessment as a part of the early stages of BA activities may

also involve making a judicious choice of technology consistent with
the current technology in the client’s environment, preferences if any
and other such factors.

d. Solution testing is also done after the solution is ready. This is usually
known as Functional testing. Functional testing involves the
verification of a solution from the standpoint of user expectations. It
is therefore necessary for the BA to identify the criteria for evaluating
and verifying a solution from a business and users' perspective. Such
acceptance criteria are often identified during the earlier phases of BA
activities and are handy for conducting a user acceptance test.

The IIBA framework thus provides a strong conceptual foundation for the
study and practice of Business Analysis. The IIBA BoK also describes each
knowledge area in greater detail in the form of input-process-output. A full
description of the IIBA BoK is beyond the scope of this book. However,
many of these aspects are covered in someways in later chapters.

! !26
 THE IIBA FRAMEWORK AND IIBA BOK

2.3 SUMMARY

• The IIBA is the most leading professional body which advocates

professional practice for the Business Analyst.

• The IIBA has developed a Body of Knowledge and framework for

Business Analysis.

• The key knowledge areas as per the IIBA BoK version 2.0 are:
– Business Analysis Planning and Monitoring
– Requirements Management and Communication
– Elicitation
– Enterprise Analysis
– Requirements Analysis
– Solution Assessment and Validation

2.4 SELF ASSESSMENT QUESTIONS

1. Give an overview of the Body of Knowledge (BoK) version of IIBA.

2. Which knowledge areas are outlined in the BoK?

3. Explain briefly the key knowledge areas of IIBA BoK version 2.0.

! !27
 THE IIBA FRAMEWORK AND IIBA BOK

2.5 Multiple Choice QUESTIONS

1. The International Institute of Business Analysis (the IIBA) is one of the

leading professional bodies which has attempted to give Business
Analysis the status of a _________ since 2004.
a. Profession
b. Professor
c. Analysts
d. Entrepreneur

2. The International Institute of Business Analysis (the IIBA) has over the
years, published a Body of _________ which describes the broad
framework for Business Analysts.
a. Industrialists
b. Knowledge
c. Professionals
d. Members

3. Business Analysis Planning and Management emphasizes the need to

treat Business Analysis as a project or a subproject of the full lifecycle
IT project.
a. True
b. False

4. Which of the following is the implications that business analysts must

have?
a. Plan the approach to conducting the BA phase.
b. Identify the tasks involved in the Business Analysis Phase.
c. Identify the risks associated with this phase.
d. All of the above

5. Which of the following is a key knowledge area of IIBA's Body of

Knowledge version 2.0.?
a. Business Analysis Planning and Management
b. Enterprise Analysis
c. Both A & B of the above
d. None of the above

Ans: 1- (a), 2 - (b), 3 - (a), 4 - (d), 5 - (c) 


! !28
 THE IIBA FRAMEWORK AND IIBA BOK

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture

! !29
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

Chapter 3
Business Analysis Planning And
Management
Objectives

After reading this chapter, you will be able to:

• To study the knowledge area of Business Analysis Planning and

Management

• To understand how to view Business Analysis assignment as a project

• To learn about various Aspects of Business Analysis which need to be

planned — includes tasks and activities, roles and responsibilities,
estimation of BA effort, approach to conducting Business Analysis

Structure

3.1 The IIBA Perspective on Business Analysis Planning and Management

3.2 Viewing Business Analysis as a Project
3.3 Business Analysis as a Projects – Points to Ponder
3.3.1 Linkage with Software Lifecycle
3.3.2 Motivation for Business Analysis and Its Impact
3.3.3 Business Analysis Activities
3.3.4 Estimating Business Analysis Effort
3.3.5 Stakeholder Analysis
3.3.6 Packaging the Communication
3.3.7 Planning the Requirements Management Process
3.3.8 Managing Performance of the BA/BA Team
3.3.9 Risks in Business Analysis
3.4 The Heart of Business Analysis Planning
3.5 Business Analysis Planning Techniques
3.6 Summary
3.7 Self Assessment Questions
3.8 Multiple Choice Questions

! !30
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

3.1 THE IIBA PERSPECTIVE ON BUSINESS ANALYSIS

PLANNING AND MANAGEMENT

Business Analysis Planning and Management as per IIBA BoK 2.0 consists
of planning the the following key tasks:

• Deciding the Approach to Business Analysis

• Stakeholder Analysis
• Deciding on the BA Activities
• Planning BA Communications
• Planning the Requirements Management Process
• Managing the Performance of the Team of BAs

3.2 VIEWING BUSINESS ANALYSIS AS A PROJECT

Business Analysis Planning and Management is an overarching process

which views Business Analysis as a sub-project within the larger IT or
business process project. The need for and the benefit of viewing BA tasks
as a project is that it brings in the project management activities to the BA
tasks which are otherwise very nebulous. It must also be mentioned that
usually Business Analysis is one of the key tasks within any IT/Business
Process project and it is invariably on the critical path. Hence, any delay in
BA activities affects the ability to meet overall project deadlines. It is
therefore important that the BA tasks are planned as if it were a project
applying all the principles outlined in Project Management Institute's (PMI)
Body of knowledge.

In addition, one must identify potential risks in the BA project. This could
include possibility of users' lack of knowledge of technology, non-
availability of key users for discussions during the BA phase etc.

! !31
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

3.3 BUSINESS ANALYSIS AS A PROJECTS – POINTS TO

PONDER

With respect to the above, a few points must be noted:

3.3.1 Linkage with Software Lifecycle

Business Analysis being part of a larger software project lifecycle would

tend to vary depending on the choice of the software project lifecycle. For
instance, in a classical waterfall approach, the Analysis phase appears only
once and is clear and distinct while in iterative or incremental lifecycles or
agile methods the Business Analysis phase is spread across the entire
project lifecycle. Hence, planning the approach to BA is very important.

3.3.2 Motivation for Business Analysis and Its Impact

The approach to Business Analysis depends on the motivation for this

initiative. There are various reasons and motivations for starting up a
Business Analysis initiative. This could include process transformation,
technology migration, driving innovation etc. Depending on the motivation,
the approach to Business Analysis may change. For example, in a mere
process improvement, one may take up a 6 Sigma type approach whereas
if the purpose is to make the organization competitive in the marketplace,
the approach of the BA would be akin to that of a strategy consultant. It
may be noted that along with the approach, the activities, tools and
techniques etc. used for business approach would also change.

3.3.3 Business Analysis Activities

Business Analysis activities include fixing appointments with users,

interacting with users, document reviews etc. Thus, if a BA project requires
the study of an entire manufacturing factory, the BA may have to meet as
many as 20 executives/users (stakeholders) in the factory. To do this, he
has to identify who they are, the process which they manage, fix
appointments with them, spend perhaps half a day visiting and interacting
with them, half a day for modeling and documenting his understanding and
another half a day for verifying his understanding. Thus, BA activities need
to be planned and estimated carefully to ensure timely completion of these
activities.

! !32
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

3.3.4 Estimating Business Analysis Effort

It is frequently seen that when a BA or project leader is asked as to how

much time it would take to conduct the Business Analysis phase, they
would say from gut feel – perhaps 2 weeks, 1 month etc. However, if one
identifies the activities to be performed as was described in the factory
example above, it would be apparent that these gut feel based estimates
may not be valid. Hence, BAs must identify and estimate the effort
required in the BA activities in a ground up fashion say in manhours or
mandays and depending on the available time decide the number of BAs
required to complete these activities and the BA phase.

3.3.5 Stakeholder Analysis

Stakeholder Analysis as mentioned above is primarily done to identify

those who either have some interest in the project or are impacted by or
can influence the project outcomes. For example, a leading tyre
manufacturing company's head office employed a team of about 10 people
exclusively to collect and compile sales, inventory and other branch
statistics. After automating the branch offices, the data could be updated
on a central database which could generate all the necessary reports about
branch and company performance without human intervention. Thus, the
entire team of 10 people was one set of stakeholders who were made
redundant by the system. A BA needs to identify such stakeholders since
they are impacted by the system and may oppose it unless an alternate job
and retraining of such people is not planned. One stakeholder who is often
forgotten is the management – since they are always interested in getting
a performance perspective about any automated business process. Yet
another stakeholder which a BA must enquire about is in the form of
regulatory bodies and other external stakeholders who expect visibility of
process or its controls. It is also necessary today to check if any external
stakeholder such as customer or supplier or business partner may benefit
from the process or system being designed. For example, courier services
allow customers to track the packet. The BA must therefore always ask if
there are such stakeholders and identify their expectations or their ability
to influence the outcomes.

! !33
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

One other aspect of stakeholder analysis is to identify roles and

responsibilities. Often in the business process reengineering projects, IT
projects, it is necessary to appoint process owners from among the
stakeholders. The roles for such stakeholders could range from being the
key users for sharing process details to the BA or they could act as a single
point of contact for their department or be in-charge of driving the
implementation within their departments.

3.3.6 Packaging the Communication

Business Analysis requires communication at different levels. This includes

communication with users, process owners, management etc. Each
stakeholder requires different approaches and forms of communication.
Communication therefore needs to be packaged appropriately to ensure
the correct impact with the stakeholders. Attitude towards the
organization, the project, the perceptions about the changes which the
project may bring in, the Business Analysis etc. tends to place challenges
in communication. Hence, a conscious planning of communication is
important.

3.3.7 Planning the Requirements Management Process

Planning of the Requirements Management process includes the selection

of tools for requirement, the sequence and priority for Business Analysis
etc. are some of the aspects. Many large organizations have well-defined
requirement management processes – the need to adapt this process could
be a one consideration. Requirements Management process may also be
affected by factors such as the geographical spread of the requirements
gathering activities.

3.3.8 Managing Performance of the BA/BA Team

Large projects require many Business Analysts to work on the BA tasks.

Depending on the priority assigned, the work allocation between the BAs
need to be done. Also since Business Analysis is a highly people based
process, it defies precise measurement — making it difficult to control its
pace and completeness. It is therefore best to split the requirement
gathering into smaller tasks and activities in manner that work can be
quantified. For example, if the requirement gathering involves discussing
with 20 department executives/users – this could be split across say 10

! !34
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

working days with detailed meetings with 2 departments every day

assuming only 1 BA were to do this. Thus, the weekly review becomes
easy, since we are able to check if the BA was indeed able to complete his
discussions with 10 executives during the week gone by (2 executives per
day × 5 working days). While quantification helps in making Business
Analysis activities measurable, these measures should be supported by
information about quality and completeness of these tasks.

3.3.9 Risks in Business Analysis

Last but not the least, it is important to identify and manage risks which
may emerge during the Business Analysis Phase. Some risks can be
identified even at the start of the BA phase. For example, the study may
involve interacting with users who have no knowledge about Information
Technology or cannot speak in the language which the BA is comfortable
with etc. Certain risks are not very visible but need to be sensed. For
example, if the Business Analysis phase involves travel to a distant location
such as the client's country or a remote city etc., several risks related to
travel, ill-health of the BA etc. could affect either the quality of the work or
could delay it. These and many other risks which are contextual have to be
accounted for in the planning of the Business Analysis project.

3.4 THE Heart of Business Analysis planning

The Heart of Business Analysis Planning: 8 Questions to Answer In

Your Work Plan

Business Analysis Planning is about identifying the collection of tasks that

need to be completed to ensure that the business analysis effort is
successful. The term, successful, could mean that deliverables are turned
in on time or that the business need is met.

Developing an effective plan involves identifying and outlining all the key
tasks that must be completed within the allotted time. With a detailed plan,
key stakeholders are able to see the estimated amount of time needed to
complete the analysis effort. In some cases, the Business Analyst may use
this plan as a basis of negotiation for more resources like more time, more
staff, etc. on the project.

! !35
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

Who Prepares the Business Analysis Plan?

The Business Analyst is responsible for creating the plan but is expected to
seek input from key project team members like the Project Manager, SMEs
and the technical team in cases where technical expertise is required to
judge the feasibility of requirements to determine how work will be carried
out.

Who signs off on the Business Analysis Plan?

If it's an external project in which the Business Analyst is brought in as a
consultant, the commissioners/sponsors of the project would sign off on
the plan. Depending on the structure of the organization, the Project
Sponsor, Project Manager of the team the BA is assigned to or the
Functional Head in charge of the unit in which the BA works would be
responsible for signing off on the plan.

This paper discusses some of the questions you should seek to answer in
your Business Analysis Plan:

1. What is the scope of work?

Consider the scope of work that needs to be completed and outline all the
tasks and associated deliverables for each task. Part of scope definition is
identifying which business analysis processes need to be initiated and
completed.

2. What methodology will be applied?

The methodology applied on the project has a strong influence on the
activities that will be performed and the sequence of those activities. For
example, using a Plan-driven approach implies that analysis will need to be
completed before development can begin. Using a change-driven approach
on the other hand, implies that requirements elicitation and analysis will be
iterative and those requirements will be developed and clarified as the
project progresses.

3. Who are the stakeholders?

Stakeholders form part of the team that create and validate the
deliverables produced by the BA. BAs need these stakeholders to be
available during the course of the project. You will need to consider them in
your plan by outlining the roles and responsibilities of each of the
stakeholders and the time commitment that will be required of them.

! !36
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

4. What is the schedule?

The BA plan should contain a list of tasks to be completed as well as the
time estimates for each task. This insightful article, How to Compile Your
Business Analysis Work Plan makes a distinction between the actual time
needed to complete a task and the lapse time (duration) needed to
complete the task and recommends that BAs agree with the PM (Project
Manager), which should be documented in the work plan.

5. How will requirements be managed?

As part of developing a comprehensive plan, the BA plan should include the
approach for managing requirements. For example, how will requirements
be traced and prioritized? How will requirements be approved during the
course of the project?

6. What deliverables will be produced?

The main outcome of the Business Analysis effort is a set of deliverables
that result in customers' needs being met. These deliverables must be
clearly outlined in the BA plan to guide stakeholders on what to expect.
Examples of Business Analysis deliverables include Requirements
Specification Documents, Business Case, Process Models, Data Models and
so on.

7. How will communication be handled?

The Business Analysis Plan should indicate how the BA intends to receive,
access and distribute information. When will communication happen? To
whom will the communication be sent to and in what format? Consider the
5 Ws & H of communication (Who, What, Why, Where, When & How of
communication). The plan should also indicate the frequency of
communication.

8. How will Business Analysis work be assessed?

When a BA is hired to do a job, it follows naturally that the requesting
organization would want to assess how well the BA performed or if their
work was up to par. The quickest way to do this is to define a set of metrics
from the beginning for assessing the effort. For example, assessment can
be done by identifying how quickly work was completed.

“As for the future, your task is not to foresee it, but to enable it.” - Antoine
de Saint Exupery.

! !37
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

Planning your work can help you foresee and enable the vision you would
like to achieve on the project. Spend some time planning and you will face
fewer uncertainties down the road.

3.5 Business Analysis Planning Techniques

Business Analysis Planning Techniques

Three Project Planning Techniques that is useful for Business

Analysts to apply

There are a few reasons why it is really good for a Business Analyst to
have some familiarity and practical skills when it comes to some basic (but
powerful) Project Planning Techniques. Apart from the fact that most
Business Analysts operate within a project environment and therefore
should really understand the main planning activities and cycles that is
happening around them, it can also be extremely useful for a Business
Analyst to be able to properly plan for their own Business Analysis
activities on a project using these Business Analysis Planning techniques.

Let’s now have a look at the three core Business Analysis Planning
Techniques that borrowed from the Project Management Profession which
will help you in your role as a great Business Analyst.

These three Business Analysis Planning Techniques are distinct techniques

but they all work together to build up a comprehensive Project Plan which
turns into the Project’s detailed schedule.

! !38
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

The steps to build this overall Project Plan / Project Schedule is as follows:

Step 1: Build a Work Breakdown Structure (WBS)

Step 2: Create a Network Diagram (using your WBS)

Step 3: Create a Gantt Chart (using the Network Diagram)

It is also very useful knowledge for a Business Analyst simply from the
perspective of adding even more value as a Business Analyst within a
project environment.

There are a few specific Project Planning techniques that a Business

Analyst should learn and a few concepts to understand to really perform
optimally within the project environment. These techniques and concepts
are applicable when it comes to Business Analysis Planning and estimation
activities. On smaller projects, where the Business Analyst gets more
involved by working closely with a Project Manager or even play the role of
a pseudo Project Manager.

Business Analysis Planning Technique

#1: Work Breakdown Structure (Step 1 in Building a Project Plan)

The Work Breakdown Structure is a Project Planning technique used to plan

out everything that needs to be delivered by the project in terms of
Phases, Deliverables and Tasks. It deliberately doesn’t take the timeframe,
the sequencing or any dependencies into account yet and should be seen
as the very first step of Building a Project Plan / Schedule.

! !39
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

Let’s first define the specific terms you need to understand when
learning about the Work Breakdown Structure:

1. Phase: The Phase of a project is a logical grouping of activities and

deliverables that is grouped together for purposes of planning for a
project. The Phases often aligns with the phases used in the Systems
Development Life Cycle although this will be different when you plan for
an Agile based Project.

2. Deliverable: A deliverable is a specific output that the project must

deliver along the way of being executed. Examples of deliverables could
be documents, software packages or any tangible result that makes the
project progress to the next stage of the plan.

3. Tasks: A task in the context of project planning refers to a set of steps

or activities that is typically performed to work towards achieving a
deliverable. Therefore, there will be a set of different tasks that needs to
be completed before a deliverable can be achieved. In most cases it
takes more than just one task to deliver an outcome. When you define
your tasks, you should break it down, small enough to assign to one

! !40
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

person or one group with specific skills to execute. A task will be

typically something that requires between 1 and 5 days’ worth of work
effort.

So now that you understand the concepts you need for starting to build
your Work Breakdown Structure. You should also take note that there is
another approach to determining all the required work for a project by
using a Product Breakdown Structure.

How to build your Work Breakdown Structure?

Ideally you should get yourself a big white board or a large table to work
on. Get yourself some large and medium sized “Post It” notes and some
different coloured marker pens. You are going to be sticking things on the
wall and scribbling on them as you go, so make sure you are prepared. The
reason using “Post It” notes are recommended is because you are going to
move the “Post It” notes around and will be using them again when you
start creating the Network Diagram.

1. Give your Project a Name: Take a large “Post It” note and write the
Project Name on it. You then put that note at the very top (in the
middle) of the white board or table as if it was the position of the CEO
on an organisational chart.

2. Define your Phases: The second step you will do is to define which
phases you believe will be involved with your project. For example, if
you are planning a software development project you may want to have
phases such as: Initiation Phase, Analysis Phase, Design Phase, Build
Phase, Test Phase and Implementation Phase.

You should take the large “Post It” notes and write a Phase Name on
each of them. You will then stick them at the top of your white board
from left to right (leave as much space in between each Phase “Post It”
note as you can.

3. Define your Deliverables: Now that you have your Project Name and
Phases defined and up on the white board or the table, you can start
thinking about what key deliverables each phase will be delivering. For
example: Your Analysis Phase will probably be delivering the following
two deliverables (as a minimum): Business Requirements Document
and Business Analysis Approach Document. These are just two

! !41
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

examples but you can imagine the type of deliverables that you need to
think of here.

You should again take the large “Post It” notes and write the name of the
Deliverable on the note. You then stick these “Deliverables” under each
Phase (where they will be completed) as if they are the Phase’s sub-
ordinates on an organisational chart.

4. Define your tasks: Each Deliverable will have to be delivered as a

result of a range of different tasks that was performed by the project
team. This is now where you take each Deliverable and break down
exactly what tasks must be completed in order to deliver that
deliverable. Examples of some tasks required for the delivery of the
Business Requirements Deliverable could be: Perform a Requirements
Gathering Workshop, Document Business Requirements, Review
Business Requirements.

You now take the small “Post It” notes and write each task on the note
and stick the tasks underneath the corresponding Deliverable on your
white board or table. Once you have done all the tasks for each
deliverable you will have the framework for your WBS all set up and
ready for estimation.

5. Estimation

Now that you have all the Phases, Deliverables and Tasks outlined on the
White board or table you are ready to evaluate each task in terms of how
much effort is involved to complete this task. It is typically suggested
that you write the minimum number of days (or hours for a smaller
project) in one corner of the small “Post It” note and the maximum
number of days (or hours) in another corner of the “Post It” note. You
only do this for the Tasks because the tasks are the only things on your
WBS which requires effort to complete.

So now go through each Task with your team and agree on the minimum
and maximum values for each Task.

! !42
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

6. Milestones

As a final step before you complete the Work Breakdown Structure is to

identify the Deliverables and Tasks which you see as Milestones. A
milestone in the context of Project Management is when you feel like you
have reached a critical point or achieved a significant result in the project.

With your team you should review all the Deliverables and Tasks and
decide which ones are deemed “milestones” for your project as it
progresses. For those milestones you should draw a diamond symbol on
the “Post It” note to illustrate that the particular item is a milestone for the
project.

Now you can stand back and admire the WBS. It is a great idea to mark
each Deliverable and Task in a way which will remind you which Task
belongs to which Deliverable and which Deliverable is part of which phase.
This is important especially for the next step where you will start and build
the Network Diagram.

#2: Network Diagram (Step 2 in Building a Project Plan)

The purpose of the Network Diagram is to ultimately determine the critical

path of the project. The Network Diagram shows the sequence and
dependencies that project tasks have upon each other.

How to build your Network Diagram:

You do this by taking all the ‘Post It’ notes which are the Tasks (put the
Deliverables & Phases aside) of your project. Start to take them one by one
and by starting on the left of the white board, you place it in the sequence
of execution. Part of the objective here is to figure out which tasks can run
in parallel and what dependencies exist between tasks.

! !43
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

Example:

!
Let’s say your Project is to make coffee. Pretend you have unlimited people
helping you do this project.

Task 1: Put the kettle on

Task 2: Find a cup,

Task 3: Drink the coffee.

You would place Task 1: Put kettle on and Task 2: Find a cup in the same
invisible column on the white board on the left (working from left to right).
Then you will place Task 3 (drink the coffee) in the next invisible column
along.

Task 1 & 2 are not dependent on each other because they can be executed
at the same time and there were enough people helping to make the coffee
and therefore you place one below the other in the first invisible column.

! !44
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

Task 3 is dependent on both Task 1 and Task 2 to be executed before you

can start executing Task 3. This is why you place Task 3 in the next
invisible column.

You should now try and do this with all the Tasks in your real project.

Critical Path

Once you have all your Project tasks outlined in the way described you
have achieved two key project planning results. You know what sequence
you need to execute the tasks in and you also know which tasks is
dependent on other tasks. You now have to determine what the duration of
the project is by working out what is the longest time-frame the project
needs to execute all the tasks. Keep in mind that the number of people
who you would have available to execute your project has not been
determined yet. It is now just about understanding based on the sequence
and dependencies what is the quickest and the slowest duration of the
project.

How to Determine the Critical Path?

When you determine the critical path, you need to identify each task in
each invisible column on the Network Diagram with the maximum duration
assigned to it. Remember how you placed a minimum and maximum
duration on each task? Now is the time to use this maximum number. So,
for each task that you identify in each invisible column with the highest
maximum value, you should make a circle around the maximum duration
for that task (preferably in a new colour). Once you have determined the
highest maximum task for task in the invisible column and you marked
them out you should add the maximum durations for all these tasks
together. Once you come up with a total duration you will know that
maximum length of time the project should take. These tasks you
identified forms what is referred to as the critical path of your project. If
any of the tasks on the critical path is taking longer to finish than the
maximum duration that was planned for, your project is effectively running
over the critical path and is therefore running late. This is why project
managers are often very focused on doing whatever they can to stay within
the critical path of the projects!

! !45
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

Finally, you can take a similar exercise to determine the quickest that
project can be completed by identifying, marking and adding up the
highest minimum duration values for each invisible column on your
Network Diagram. This is another great measure for project managers
because they will know that regardless of how many people they assign to
their project, the project would need at least that minimum number of
days to be completed.

You have now successfully created the Network Diagram for your Project
Plan. You now only need to finish Step 3 of Building the Project Plan before
you completed!

#3: Gantt Chart (Step 3 in Building a Project Plan)

This final step of creating the Gantt Chart or Project Schedule is where
people often start. Starting with this step is not a great way to build a
project plan because you have not considered the WBS step or Network
Diagram step in any detail. It means you will be guessing a lot of the tasks,
their dependencies and durations while trying to start directly within a
calendar-based planning tool. It is really valuable to first complete the WBS
and then the Network Diagram before drafting the Schedule.

So, what does this step really entail? In short, it is a combination of your
WBS (Phase, Deliverable, Milestones and Tasks!) and Network diagram
(Sequence and Dependencies) with the additional layer of a calendar and
resources. You are essentially combining all your steps with a calendar
where you are able to see specific calendar months and assign and share
tasks among resources for your project. It shows you the “real” duration of
the project in calendar months rather than work effort required.

Use a Gantt Chart (MS Project) to put this together electronically rather
than the “Post It” notes.

In Conclusion

In a nutshell, if you are able to do these three project planning techniques

and you understand the underlying purpose of each step, you are set to
start participating or leading any project planning efforts! You will by now
have a greater appreciation for the benefits of how these Project Planning
Techniques and steps can assist you in your own Business Analysis

! !46
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

Planning activities. Once you applied these three steps in practice, you will
never stop using it – promise! Give it a go!

Example Project Planning - Case Study

What Business Analysts Can Learn from Swiss Cheese

Swiss cheese has holes in various places on different slices of cheese when
you cut it up. Let’s imagine these holes reflect weaknesses in the system
where mistakes can pass through, afterall no system is perfect. One
mistake passing through a hole in one slice of cheese might remain
unnoticed and not lead to a business catastrophe, if it's corrected. If the
mistake slips through all the holes however, across all the layers of cheese
(defences) when all the holes are in alignment, a catatrosphe might result.

The Swiss cheese effect, also known as the “cumulative act effect”, is
based on the contribution of James Reason, a psychologist who explained
systemic failure using four levels of human error: preconditions for unsafe
acts, unsafe acts, organizational factors/influences and unsafe supervision.
The principle of the Swiss cheese model has been successfully applied to
safety engineering and healthcare practices across the world.

Human systems are likened to multiple slices of swiss cheese. The idea is
that since each slice of cheese acts as a layer of defence, it would take a
lot for an error to pass through the system before it’s noticed and resolved.

! !47
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

Though there are many holes in the cheese, they rarely line up to create a
clear passage through it.

These holes may be due to "active failures" or "latent conditions”.

The problems in an organization may be latent, for example, they may be

related to culture, bad management, poor communication, etc. due to the
way the organization is run. Other errors may be as a result of mistakes or
unsafe acts (active failures) in the system such as an employee making a
bad judgment call or ignoring procedure. Latent conditions can be
highlighted and corrected via effective risk management before problems
manifest in the system. Incidents within an organization may arise due to a
combination of both latent conditions and active failures.

Applying the Swiss cheese model is a form of proactive risk management

that should be practiced to prevent disaster. Though defence layers may be
put in place to prevent disaster, what is also critically important is how
these layers interact.

How does this affect business analysts?

Failures can come from any section of an organization and they may be
interconnected. A failed software implementation may have happened for
multiple reasons like bad project management, inaccurate requirements,
poor training, etc. If organizational problems or failures are thoroughly
analyzed and addressed from multiple angles, they can be resolved
completely and provide learning opportunities for project teams.

So also, in solving a problem, the BA should look at it from multiple angles

and propose as many recommendations are needed. One solution may not
address the business problems you see. Systemic solutions are often
needed to bring about widespread and positive change in the long term.

Another key takeaway from this is that when designing processes or

systems, it’s important to build in multiple layers of checks (or defences),
especially when there’s a lot at stake, e.g, review and approval of payment
vouchers above a certain amount may need to be done by more than one
person in the responsible business unit.

What’s your opinion of the Swiss cheese model?


! !48
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

3.6 SUMMARY

• In order to effectively managing Business Analysis, it needs to be treated

like a project.

• The Business Analysis Planning and Monitoring process is an overarching

process which plans and monitors the entire Business Analysis initiative.

• Like any project, the BA project has to planned. Various aspects of

planning include the approach to business analysis which itself depends
on the motivation for the initiative, the stakeholders, the activities, the
estimation of effort etc.

3.7 SELF ASSESSMENT QUESTIONS

1. What is Business Analysis Planning and Management? What are the key
tasks it consists of?

2. How to view Business Analysis as a Project?

3. Describe the various aspects of Business Analysis to be planned.

! !49
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

3.8 Multiple Choice QUESTIONS

1. __________ is one of the key tasks within any IT/Business Process

project and it is invariably on the critical path.
a. Business Analysts
b. Business Analysis
c. Business Management
d. Project Management

2. In a classical waterfall approach, the Analysis phase appears only once

and is clear and distinct while in iterative or incremental lifecycles or
agile methods the Business Analysis phase is spread across the entire
project lifecycle.
a. True
b. False

3. Business Analysts must identify and estimate the effort required in the
Business Analysis activities in a ground up fashion, say in __________
and depending on the available time decide the number of BAs required
to complete these activities and the BA phase.
a. Man-hours
b. Man-days
c. Both A & B of the above
d. None of the above

4. Attitude towards the organization, the project, the perceptions about

the changes which the project may bring in, the Business Analysis etc.
tends to place challenges in __________.
a. Planning
b. Communication
c. Management
d. Approaches

5. Which of the following is the Project Planning Techniques that is useful

for Business Analysts to apply?
a. Build a Work Breakdown Structure (WBS)
b. Create a Network Diagram (using your WBS)
c. Create a Gantt Chart (using the Network Diagram)
d. All of the above

! !50
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

Ans: 1 - (b), 2 - (a) 3 - (c), 4 - (b), 5 - (d)

! !51
 BUSINESS ANALYSIS PLANNING AND MANAGEMENT

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture


! !52
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Chapter 4
Requirements Elicitation, Gathering And
Analysis
Objectives

After reading this chapter, you will be able to:

• To appreciate the purpose and importance of Requirements Elicitation,

Gathering and Analysis in the context of Business Analysis

• To get an overview of the IIBA perspective on Requirements Elicitation,

Gathering and Analysis

• To understand some of the practices pertaining to conducting a

requirements gathering exercise (system study/process study). In
particular, understand the need for studying multiple perspectives and
get an overview of some of these perspectives, viz., flow, dynamic
aspects, process structure, human factors, security, solutions perspective
etc.

• To get an overview of tools suitable for studying and modeling a business

process through each of the above perspective

Structure

4.1 Overview of Requirements Elicitation, Gathering and Analysis

4.2 The IIBA Perspective

4.3 Requirements Elicitation - A Project's Foundation

4.4 Requirements Elicitation & Analysis

4.5 Study of a Business Process

4.6 Summary of Key Perspectives and Tools for Studying a Business

Process

! !53
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

4.7 Who is the BAs' Customer?

4.8 Difficulties Faced in Requirements Elicitation and Gathering

4.9 The Five BIG Challenges of Eliciting Requirements

4.10 Overcoming Some of Challenges in Requirements Elicitation and

Gathering

4.11 A Model for an Effective Requirements Gathering Process

4.12 Summary

4.13 Self Assessment Questions

4.14 Multiple Choice Questions

4.1 OVERVIEW OF REQUIREMENTS ELICITATION,

GATHERING AND ANALYSIS

Requirements Gathering is one of the most important aspects of Business

Analysis. Usually, it involves the study of an entire area of business or a
business process. In the field of IT, it is assumed that requirements
gathering implies the users' expectations of the IT based solution. Limiting
the study to the users' vision for a solution can however be inadequate at
its best and disastrous at its worst.

The aim of requirements gathering should be to uncover the real business

problem/opportunity which needs to be addressed. In practice, therefore, it
is essential to understand the business process thoroughly so as to know
the function it performs, how it is performed at each stage, impediments
and constraints, the core purpose of the function etc. Some aspects of the
solution vision of the user of the analyst may also be discussed during
requirements gathering more to assess the prima facie viability of parts of
the solution. However, the focus must remain on ‘understanding’ rather
than offering solutions so prematurely. 


! !54
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

4.2 THE IIBA PERSPECTIVE

The IIBA BoK ver 2.0 describes all the above across the following broad
processes:

• Business Analysis Planning and Management – where largely the

approach to business analysis and hence the activities, estimates, plan
etc. for Business Analysis are decided. The approach to Business Analysis
depends on the motivation for the Business Analysis initiative. In some
cases, it could be an exercise in process improvement, in some cases it
could be process transformation while in others it could be merely a
migration to a new technology while the process remains the same. The
activities for each type of Business Analysis initiative would be different.
Also the tools used for elicitation, modeling and analysis could be
different.

• Requirements Management and Communication – Here emphasis is

on managing the solution scope, managing requirements traceability,
managing reuseability of requirements, preparing the requirements
package and communicating the requirements.

• Requirements Elicitation – This process as per IIBA focuses on

planning, conducting elicitation of requirements and verifying the
requirements so elicited. Some of the issues pertaining to elicitation and
gathering have been described in this chapter.

• Requirements Analysis – This process focuses on prioritizing

requirements, organizing requirements, specifying and modeling
requirements, verifying and validating requirements. This chapter lays
the base for discussion on specific requirement modeling techniques
based on the concept of multiple perspectives which are very necessary
for requirements study and analysis.

! !55
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

4.3 Requirement Elicitation – A Project’s foundation

Requirements Elicitation - A Project's Foundation

Gathering the requirements that must be accounted for, in order to achieve

a project's goal is the process that forms the foundation for its success.
The BA typically has responsibility for managing this phase. Requirements
elicitation is the set of activities where information is given by
stakeholders, users, and customers to be applied to the design of the
initiative or the solution.

Elicitation is a perpetual process during a project development. It is not a

stagnant, compartmentalized activity. As issues arise, information gaps
occur or new requirements evolve, the BA must initiate or continue
elicitation of stakeholder input. The project's success depends upon the
accuracy, completeness, and detail of the stakeholder requirements.
Eliciting requirements not only involves obtaining documented criteria but
also uncovering latent or potential needs.

Though techniques for gathering requirements may be common, the

deliverables are difficult (at best) to define. Typically, the BA is dealing with
a variety of input points (that is, IT, sales, and finance) where each has a
different documentation and reporting structure, often along with a unique
culture and language. Strong organizational and communication skills are
required during this phase, as it is generally up to the BA to shape the
information into models, diagrams, and other tools to communicate the
findings to decision makers and to team members.

Enterprise opportunities, restrictions, assumptions, and current reality are

all reflected by stakeholders during requirements elicitation. The BA must
be able to resolve conflicts between requirements, eliminate the potential
for conflicts (if possible), and achieve consensus among team members
and stakeholders as requirements are defined and prioritized.

When considering elicitation activities, the BA must develop strategies for

two primary functions:

• Preparing for Elicitation and

• Conducting Elicitation.

! !56
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Requirements Elicitation Functions

Elicitation Process

There are several effective techniques a Business Analysis (BA) can use to
obtain the requirements. Each method has strengths and weaknesses that
affect the quality of the requirements that are elicited.

The BA must base his decision on which techniques to employ by

determining:

1. What methods are appropriate for both the stakeholder and elicitor? and

2. What methods will capture the requirements most effectively and

efficiently.?

What is Elicitation?

A thorough discovery of business requirements is almost never readily

available at an analyst’s fingertips—rarely can requirements be quickly
looked up as one would gather information for a term paper or study for a
test. Much of business or technical requirements is not documented
anywhere—it resides in the minds of stakeholders, in feedback that has yet
to be obtained from end users, and from a study of flowcharts and surveys
that have yet to be created. And so, requirements must be elicited, or
drawn out, and the methodology in doing so must be logical and
meticulous. The importance of elicitation cannot be overstated, as it is
essential to requirements project.

As one scholarly article notes: “Mistakes made in elicitation have been

shown many times to be major causes of systems failure or abandonment
and this has a very large cost either in the complete loss or the expense of
fixing mistakes.”

Adequate study and preparation for elicitation can go a long way to

preventing these types of errors. The purpose of requirements elicitation,
therefore, is to thoroughly identify the business needs, risks, and
assumptions associated with any given project.

! !57
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

A. Prepare for Elicitation

1. The first step in requirements elicitation is gleaning a comprehensive

and accurate understanding of the project’s business need. During the
elicitation process, an analyst’s strong understanding of the business
need will help her guard against scope creep and gold plating, as well as
select the proper stakeholders and elicitation techniques.

2. An analyst’s next step in eliciting requirements is ensuring that an

adequate amount and mix of stakeholders are secured for the project’s
duration. For, as BABOK 2.0 (Business Analysis Body of Knowledge, the
definitive guide to all things related to business analysis) notes, a good
analyst must “actively engage stakeholders in defining requirements.”
According to BABOK, a project’s stakeholders may include customers/
end users, suppliers, the project manager, quality analysis, regulators,
project sponsors, operational support, domain subject matter experts,
and implementation subject matter experts.

An analyst must recruit the participation of appropriate stakeholders based

on the unique business needs of their project. After an analyst has
identified and recruited their stakeholders and chosen the method(s) by
which they will elicit requirements (outlined below), it is advisable for them
to schedule the time for conducting those methods with stakeholders as far
in advance as possible to ensure adequate participation on their parts.

Elicitation Techniques

After securing the proper stakeholders, an analyst must determine the best
techniques for eliciting requirements.

! !58
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Commonly used requirements elicitation methods (as identified by BABOK)

include:
i. Brainstorming
ii. Document analysis
iii. Focus Group
iv. Interface Analysis
v. Interviews
vi. Observation (job shadowing)
vii.Prototyping (storyboarding, navigation flow, paper prototyping,
screen flows)
viii.Requirements workshops
ix. Survey/questionnaire

A. Conduct Elicitation

An analyst’s project’s business needs and the stakeholder mix will

determine which of the above elicitation method(s) are best. Elicitation
does not normally occur prior to requirements however; it occurs
throughout a project—during discovery, modeling, and even testing.
Whenever elicitation takes place during a project’s life cycle, the same
principles apply to make it successful—the correct mix of stakeholders, a
thorough understanding of the business need, properly selected elicitation
techniques, and meticulous attention to detail.

Confirm Elicitation Results

Once the elicitation methods have been employed, an analyst must
document the elicitation quickly, while it is still fresh in their mind, and
share the results with appropriate stakeholders to confirm their agreement
with the findings. This stage is essential to ensure that the analyst has
accurately grasped, and stakeholders have accurately communicated, the
project’s needs.

Elicitation serves as the underlying research to requirements creation

phase. Once an analyst has sufficient material, they can begin crafting
requirements.

! !59
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

4.4 Requirements Eelicitation and Analysis

Requirements Elicitation and Analysis

The Activity of Generating the Requirements of a System from

users, Customers and other Stakeholders.

It’s a process of interacting with customers and end-users to find out about
the domain requirements, what services the system should provide, and
the other constrains.

Domain requirements reflect the environment in which the system

operates. When we talk about an application domain we mean
environments such as train operation, medical records, e-commerce etc.

It may also involve a different kind of stockholders; end-users, managers,

system engineers, test engineers, maintenance engineers, etc.

A stakeholder is anyone who has direct or indirect influence on the

requirements.

The Requirements Elicitation and Analysis have 4 main Processes

We typically start by gathering the requirements, this could be done

through a general discussion or interviews with your stakeholders, also it
may involve some graphical notation.

Then you organize the related requirements into sub components and
prioritize them, and finally, you refine them by removing any ambiguous
requirements that may raise from some conflicts.

Here are the 4 main processes of Requirements Elicitation and Analysis.

! !60
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

The Process of Requirements Elicitation and Analysis

It shows that it’s an iterative process with a feedback from each activity to
another. The process cycle starts with requirements discovery and ends
with the requirements document. The cycle ends when the requirements
document is complete.

1. Requirements Discovery

It’s the process of interacting with, and gathering the requirements from,
the stakeholders about the required system and the existing system (if
exist).

It can be done using some techniques, like interviews, scenarios,

prototypes, etc. which help the stockholders to understand what the
system will be like.

Gathering and understanding the requirements is a difficult process

That’s because stakeholders may not know what exactly they want the
software to do, or they may give un-realistic requirements.

! !61
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

They may give different requirements, which will result in conflict between
the requirements, so we have to discover and resolve these conflicts.

Also, there might be some factors that influence on the stakeholder’s

decision, like for example, managers at a company or professors at the
university want to take a full control over the management system.

Interviews

In Interviews, requirements engineering teams put the questions to the

stakeholder about the system that’s currently used, and the system to be
developed, and hence, they can gather the requirements from the answers.
The questions fall under two categories:

1. Closed-Ended questions: A pre-defined set of question.

2. Open-Ended questions: There is no a pre-defined expected answer,

they are more of generic questions. It’s used to explore issues that’s not
clear in a less structured way.

In practice, interviews usually use mixture of both. Usually, start with the
open-ended questions, and then use the closed-ended questions to be
more specific about some requirements that aren’t clear yet.
Interviews are good to get an overall understanding of what stakeholders
need, how they might interact with the new system, and the difficulties
they face with the current system.

However, interviews aren’t so helpful in understanding the domain

requirements. This is for two reasons:

Domain requirements may be expressed using special domain

terminologies, and software engineers often find it difficult to understand
and it’s easy for them to misunderstand.

Sometimes stakeholders won’t tell you some requirements because they

assume it’s so fundamental and it doesn’t worth mentioning, or they find it
difficult to explain, which won’t be taken into consideration in the
requirements.

! !62
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Use Cases and Scenarios

The use cases and scenarios are two different techniques, but, usually they
are used together.

Use cases identify interactions between the system and its users or even
other external systems (using graphical notations), while a scenario is a
textual description of one or more of these interactions.

! !63
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Use case involves some symbols to describe the system:

Use case diagram symbols and an example

a. Actors: Are those who interact with the system; human or other
systems

b. Interaction (Use Case): It denotes the name of the interaction (verb).

It’s represented as a named ellipse.

c. Connection: Lines that links between the actors and the interactions.

d. Include Relationship: It denotes a connection between two

interactions when an interaction is invoked by another. As an example,
splitting a large interaction into several interactions.

e. Exclude Relationship: It denotes a connection between two

interactions when you want to extend an interaction by adding an
optional behaviour, but you can use the main interaction on its own
without the extending interaction.

Now, we are going to use scenarios to describe the interactions in each use
case textually. They should have a format and include the following:

i. A description of the initial situation.

ii. A description of the flow of the events or interactions with the system

iii. A description of the exceptions, or in other words, what can go wrong,

and how it can be handled.

iv. Any concurrent activities should be mentioned

v. A description of the final state.

Here is the example of a scenario for the use case example above

! !64
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Name Course Registration

Actors Student and University System

Description It shows how a student can register for a course and view
personal info

Pre-condition The student is logged in

Post- The student registered his/her course list for the semester.
condition

Actions 
 1 Student will press on “Course Registration” from Home

(Main Page.
Scenario)

2 Select desired courses for the next semester.

3 Enter personal info.

4 Press on “Register”.

5 Confirmation message upon success.

6 Student can view his/her personal info.

Exception #3 User entered invalid input, thus, an error message will be

displayed

Scenario

Use case and scenarios are effective techniques for eliciting the
requirements. But, because they focus on the interactions with the system,
they aren’t effective for eliciting high-level business, non-functional, or
domain requirements.

The next two phases are about analyzing requirements: determining

whether the stated requirements are clear, complete, consistent and
unambiguous, group related requirements and organize them into related
components, and resolving any apparent conflicts.

! !65
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

2. Requirements Classification and Organization

It’s very important to organize the overall structure of the system.

Putting related requirements together and decomposing the system into

sub components of related requirements. Then, we define the relationship
between these components.

What we do here will help us in the decision of identifying the most suitable
architectural design patterns.

3. Requirements Prioritization and Negotiation

We previously explained why eliciting and understanding the requirements

is not an easy process.

One of the reasons is the conflicts that may arise as a result of having
different stakeholders involved. Why? Because it’s hard to satisfy all
parties, if it’s not impossible.

This activity is concerned with prioritizing requirements and finding and

resolving requirements conflicts through negotiations until you reach a
situation where some of the stakeholders can compromise.

We shouldn’t reach a situation where a stakeholder is not satisfied because

his requirements are not taken into consideration.

Prioritizing your requirements will help you later to focus on the essentials
and core features of the system, so you can meet the user expectations. It
can be achieved by giving every piece of function a priority level. So,
functions with higher priorities need higher attention and focus.

4. Requirements Specification

The requirements are then documented.

It’s the process of writing down the user and system requirements into a
document. The requirements should be clear, easy to understand, complete
and consistent.

! !66
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

In practice, this is difficult to achieve as stakeholders interpret the

requirements in different ways and there are often inherent conflicts and
inconsistencies in the requirements.

As we’ve mentioned before, the process in requirements engineering are

interleaved, and it’s done iteratively. First iteration you specify the user
requirements, then, you specify a more detailed system requirement.

1. User Requirements: The user requirements for a system should

describe the functional and non-functional requirements so, that they
are understandable by users who don’t have technical knowledge.

You should write user requirements in natural language supplied by

simple tables, forms, and intuitive diagrams.

The requirement document shouldn’t include details of the system

design, and you shouldn’t use any of software jargon, or formal
notations.

2. System Requirements: The system requirements on the other hand

are expanded version of the user requirements that are used by
software engineers as the starting point for the system design.

They add detail and explain how the user requirements should be
provided by the system. They shouldn’t be concerned with how the
system should be implemented or designed.

The system requirements may also be written in natural language but

other ways based on structured forms, or graphical notations are usually
used.

3. Ways of Writing Requirements Specification: As we’ve mentioned,

there are different ways to specify the requirements. The most two
common ways are the natural and structured languages.

! !67
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Notation Description

Natural language The requirements are written using numbered sentences in

natural language. Each sentence should express the
requirement.

Structured natural The requirement are written in natural language on a

language standard form or template. Each field provides information
about an aspect of the requirement.

Design description This approach uses a language like a programming

language language, but with more abstract feature to specify the
requirements by defining an operational model of the
system. This approach is now rarely used although it can
be useful for interface specifications.

Graphical notations Graphical models, supplemented by text annotations, are

used to define the functional requirements for the system;
UML use case and sequence diagrams are commonly used.

Mathematical These notations are based on mathematical concepts such

specification as finite-state machines or sets. Although these
unambiguous specifications can reduce the ambiguity in a
requirements document, most customers, most customers
don’t understand a formal specification. They cannot check
that it represent what they want and reluctant to accept it
as a system contract.

Ways of Writing a Requirements Specification

a. Natural Language Specification: It’s a way of writing the

requirements in normal plain text, there is no defined format by default.

Requirements written in natural language are vague, and ambiguous.

Hence, you need to follow these guidelines to minimize the consequences
and misunderstanding:

Create your own format for writing the requirements. For example, you can
write the requirements in this format:

“A/The (Actor) shall (do something), By (how; explain how the user can
trigger this feature), In order to/so that (why; explain the benefits or the
objects of this requirement).

! !68
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Example: “A system shall allow the users to register by entering their

username and password, in order to get an access to the system”.

When we say “a system”, this word is very vague, we need to define what
exactly is the part of the system that will take care of this requirement.

We may highlight the important keywords.

Don’t use abbreviations, and acronyms, and If you want to, you have to
add what’s called “Appendix”. It defines all the abbreviations and acronyms
in your specification and their relevant meaning.

b. Structured Language Specification: It’s a way of writing the

requirements in more formal and structured form.

It uses standard templates to specify the requirements. The specification

can be structured around the functions or events performed by the system.

Insulin Pump/Control Software/SRS/3.3.2

Function Compute insulin dose: Safe sugar level

Description Computes the does of insulin to be delivered when the current

measured sugar level is in the safe zone between 3 and 7 units

Inputs Current sugar reading (r2), the previous two readings (r0 and
r1)

Source Current sugar reading from sensor. Other readings from

memory.

Outputs CompDose - the dose in insulin to be delivered

Destination Main control loop

Action Comp Dose is zero if the sugar level is stable or falling or if the
level is increasing but the rate of increase is decreasing. If the
level is increasing and the rate of increase is increasing, then
CompDose is computed by dividing the difference between the
current sugar level and the previous level by 4 and rounding
the result. If the result, is rounded to zero then CompDose is
set to the minimum dose that can be delivered.

Requires Two previous readings so that the rate of change of sugar level
can be computed.

! !69
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Pre-condition The insulin reservoir contains at least the maximum allowed

single dose of insulin

Post-condition r0 is replaced by r1 then r1 is replaced by r2

Side-effects None

Number - Title

Description

Inputs

Processing

Outputs

Pre-condition

Post-condition

Templates for structured language specification.

Software Requirements Document

The software requirements document (also called software requirements

specification or SRS) is an official document of what should be
implemented. It’s also used as a contract between the system buyer and
the software developers.

It should include both; user and system requirements. Usually, the user
requirements are defined in an introduction to the system requirements.

In other cases, especially if there are large numbers of requirements, the

detailed system requirements may be presented in a separate document.

! !70
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

! !71
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Users of Requirements Document and How they use it

The requirement document has a diverse set of users, ranging from the
customers till the system engineers.

The diversity of possible users means that the requirements document has
to be a compromise between communicating the requirements to
customers, defining the requirements in detail for developers and testers,
and information about predicted changes. It can help system designers to
avoid restrictive design decisions and help the system maintenance
engineers to adapt the system to new requirements.

In agile methods, since the requirements changes so rapidly, it’s a waste of

time to deliver a full document at once, instead, collects the requirements
incrementally, and write them on some cards as user stories.

Each user story has estimated time of completion, and priority. Related
user stories are grouped together.

Requirements Validation

It’s a process of ensuring the specified requirements that meet the

customer needs. It’s concerned with finding problems with the
requirements.

These problems can lead to extensive rework costs when they are
discovered in the later stages, or after the system is in service.

The cost of fixing a requirements problem by making a system change is

usually much greater than repairing design or code errors. Because a
change to the requirements usually means the design and implementation
must also be changed, and re-tested.
During the requirements validation process, different types of checks
should be carried out on the requirements. These checks include:

1. Validity checks: The functions proposed by stakeholders should be

aligned with what the system needs to perform. You may find later that
there are additional or different functions are required instead.

! !72
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

2. Consistency checks: Requirements in the document shouldn’t conflict

or different description of the same function.

3. Completeness checks: The document should include all the

requirements and constrains.

4. Realism checks: Ensure the requirements can actually be implemented

using the knowledge of existing technology, the budget, schedule, etc.

Verifiability: Requirements should be written so that they can be tested.

This means you should be able to write a set of tests that demonstrate that
the system meets the specified requirements.

There are some techniques you can use to validate the requirements, and
you may use one or more of them together, depending on your needs.

Requirements Reviews

A team of system customer; those who interact with the customer to

gather requirements, and system developers start reading the
requirements in the document and investigate in a great detail to check for
errors, inconsistency, conflicts, and any ambiguity.

Then they may negotiate with the customer on how to solve the problems
and errors found.

Prototyping

We’ve discussed the prototyping as one of the (non-standalone) software

process methodology, which is used as part of a full methodologies, and
we’ve also mentioned in can be used in the requirements engineering.

In this approach to validation, an executable model of the system is

demonstrated to the customer and end users to validate and ensure if it
meets their needs.

Prototyping is usually used when the requirements aren’t clear. So, we

make a quick design of the system to validate the requirements. If it fails,
we then refine it, and check again, until it meets the customer needs.

! !73
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

This definitely will decrease the cost as a result of having clear,

understandable, consistent requirements.

Test-case Generation

As we’ve just mentioned, the requirements need to be testable. If the tests

for the requirements are added as part of the validation process, this often
reveals requirements problems.

If a test is difficult or impossible to design, this usually means that the

requirements will be difficult to implement and should be reconsidered.

The term “tests” here doesn’t mean to write and run some code for every
function. It means to write a textual description of the “inputs”, “expected
value”, and “steps taken” to perform each function.

Here’s a template for a test case.

Summary of
Date run Time run Tester Pass/Fall
Failure

Assumptions:

Here you write your assumptions; the pre-conditions; or the initial state.

System Requirement Covered:

The number of the function that’s being tested

Exclusions:

Exclusions, like any un-desired values.

Setup: Steps taken

Write the steps that should be taken by the user for this function

User Action Value(s) Expected Pass/Fail/

Results Untested
What are List all the values The expected
the inputs that will be entered output
by the user

! !74
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

It’s difficult to show that a set of requirements does in fact meet a user’s
need. Because users need to use the system in operation and imagine how
that system would fit into their work. So, it’s inevitable that there will be
further requirements changes.

4.5 STUDY OF A BUSINESS PROCESS

Understanding a business process, however, requires a multi-pronged

approach. This is much like understanding the architecture of a building –
where we look at the front view, top view, the sectional views, the side
view etc. Each view provides a limited perspective and therefore a limited
understanding about the building.

Likewise understanding a business process requires an Analyst to study the

process from various perspectives.

4.6 SUMMARY OF KEY PERSPECTIVES AND TOOLS FOR

STUDYING A BUSINESS PROCESS

Some of the perspectives which need to be considered include but not

limited to the following:

! !75
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Perspective Brief Description Tools Used

The understanding about

• the company, products/ • Porter's 5 forces

services framework
Enterprise • industry, business environment, • Value Stream Analysis
1
Perspective • competitive factors, • SWOT analysis
• internal organizational factors • Zachman's framework
such as culture, • Critical Success
• business and organizational Factors, etc.
architecture etc.

• Data flow diagrams

• Activity diagrams
Flow Understand the flow of work,
2 • Business Process
Perspective information and processes
Modelling Notation
(BPMN) etc.

Understand the information

needs from the standpoint of: • Critical Success
• Information needed by every Factors
Information person in the organization • Study of existing
3
Perspective • Transformation and transaction
computation documents, reports
• Information for decision making etc.
etc.

Purpose is to understand the

components of the process and
their relationships. Components
Process of processes are identified in the • Objects
4
Structure form of Objects – which is any • Object relationships
‘Thing’ which contributes to the
process – or any ‘Thing’ who’s
behavior can affect a process.

! !76
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Many times processes and

systems fail not because of
normal day situations but
because of abnormal situations.
Hence it is necessary to study the
exceptions to the normal. This • Observation
may require study at different • Ethnographic studies
Dynamic times, places, people, days of using photos, videos
5
Perspective week, seasons etc. to identify and living the life
abnormal conditions and the • Object and Event
resulting process behavior – e.g., analysis
study a retail shop not only on a
working day but more
importantly on weekends and on
holiday seasons when foot falls
are high.

• Study of negative
Information Security and various
events – what should
forms of industry specific
not be allowed?
compliances are becoming
• Study of specific
Compliance/ extremely important – hence the
6 compliances, e.g.,
Security study should focus on the
Basel III in Banking,
existing and requirements for
SOX in most export
information security and
oriented companies
compliance requirements if any.
etc.

The purpose is to understand the

nature of users, their knowledge
• Speaking to users
User and of technology, their expectations
• Observing
7 Solution from systems etc. The solution
• Showing prototypes of
Perspective perspective can also focus on
the proposed system
checking viability of certain
pieces of a solution.

! !77
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

Since the final solution to be

proposed will have to take into
consideration the existing • Study of existing
technology available within the technology platforms,
client environment it is important products
to understand, the existing • Discussion with client
Technology
8 platforms, products, tools etc IT department to
Perspective
which the client has been using understand the road
and is familiar with. If the map for technology
proposed solution is to replace an platforms in the
existing software application, the organization
latter can help understand the
application needs.

Several other aspects need to be

studied some of them could
include but not limited to:
• Quality and other IT related • Ask client for access
standards followed by client to quality standards
organization – e.g., some or checklists of any
organizations may have kind etc.
Other standards for documentation, • Use a checklist to
9
Aspects file naming etc. gather information
• Performance expectations about commonly non-
• Volume of transactions and the functional
growth requirements such as
• Constraints – including those performance etc.
such as physical layouts,
environmental conditions (heat/
dust etc.)

The table shows some of the important perspectives, the brief attributes of
each perspective and the tools which could be used by the BA to gather
requirements about that perspective.

In practice, as many perspectives as necessary and possible within the

available time frame must be deployed to get a holistic understanding
about a business process.

While a discussion of each of the tools and techniques is beyond the scope
of this subject, the later chapters do give some examples of use of some of
the more prominent ones from a BA's point of view. A more elaborate

! !78
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

description of most of these tools has been covered in the course material
for IT for Management.

4.7 WHO IS THE BAs' CUSTOMER?

While the user/stakeholder and his organizations are the obvious

customers and the requirements gathering should focus on studying their
business process, requirements and expectations the BA has other
stakeholders on whose behalf he is gathering the requirement. These
stakeholders include the software development team which itself has
several participants such as Technical Architects/Designers, programmers,
Usability experts, security experts, technology platform experts, system
integrators etc. The BA provides the eyes and ears to these people since he
is the only person fortunate enough to directly visit the client and observe
and capture requirements.

Hence, it is imperative that the BA not only observes and captures

requirements and needs and the details of the existing process from a
standpoint of the functionality which it should perform but also from the
point of view of his technical team. Some of the expectations which they
may have may include but not limited to the following:

• Hardware and software platforms existing in user organization and

preferences, if any

• User characteristics and specific expectations about user-friendliness,

cultural context which may have a bearing on the choice of colors,
symbols/icons used, limitations of users if any etc.

• Security and other non-functional requirements

• General environmental requirements and constraints etc.

All these inputs lead to a better understanding and design of solutions by

the backoffice/offshore technical team which has to rely on the BA for
capturing such information.

! !79
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

4.8 DIFFICULTIES FACED IN REQUIREMENTS ELICITATION

AND GATHERING

Requirements Gathering is both an art and science. While methods and

techniques are important, the ability to deal with various types of
stakeholders/people and get their support and the ability to anticipate and
overcome difficulties in requirement gathering is of immense importance.

Some of the problems commonly faced in requirements gathering includes

but not limited to the following:

• User/User organization not familiar with Information technology – hence

do not know what would be relevant to communicate to the BA

• Stakeholder/User is new to the organization and is therefore not very

clear about his own business process

• Stakeholder/User may fear that his own job may be replaced by the
proposed IT based system

• Stakeholder/User is poor at communication in general or has a language

barrier

• Stakeholder/User does not wish to reveal everything at one go – or

wishes to see some results before sharing more information

• Stakeholder/User is unable to visualize his requirement to its fullest

during the study and expects some flexibility in terms of requirements as
the assignment progresses

• Stakeholder/User mentions only the most recent/pressing but perhaps a

one-off requirement

• Stakeholder/User describes an ideal process rather than what currently

exists

• Stakeholder/User believes in discussing the process in his cabin (which

may lead to a poor understanding of the process on the ground level
outside his cabin)

! !80
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

• Stakeholder/User is willing to cooperate and answer every question of

the BA – but it is upto the BA to ask

• Stakeholder/User are not available or cannot spare enough time since he

is the keyperson in his department

• User/Organization assigns a person to give requirements who is

otherwise idle

• Different users have conflicting requirements for the same function

• User/Organization is large and geographically spread with multiple units

etc.

From the foregoing, it would be apparent there are several challenges to be

overcome before ensuring complete and accurate requirements gathering.

4.9 The five big challenges of eliciting requirements

The Five BIG Challenges of Eliciting Requirements

Not overcoming the five BIG challenges of eliciting requirements can have
dire consequences for the success of your project. The challenges of poor
requirements definition and management result in cost overruns, missed
due dates, poorly designed products and, ultimately, a failure to deliver
what the customer needs.

The five BIG challenges faced when eliciting requirements are:

1. Cultural (work environment). Refers to the conditions that exist

within and outside of the project team that are addressing requirements

2. Communications. Refers to the way we elicit and disseminate

information

3. Understanding/knowledge. Refers to the knowledge that the team

members, the customer, and management possess about requirements
and the overall development process

! !81
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

4. Staff/people. Refers to the experience, capabilities, roles, and position

that participants bring to the requirements process

5. Processes, tools and techniques. Refers to the mechanisms we

employ to elicit and manage requirements from users

Let’s look at each challenge in more detail.

1. Cultural Challenges

Examples of cultural challenges include:

• Fluctuating, biased, and politically-based requirements

• Rising expectations by the customer
• Lack of a business strategy or a technology strategy
• Lack of leadership
• Failure to take the long view
• Infrequent assessment of risks
• Fixed-price systems work
• Time to market pressures.

There is no silver bullet for requirements elicitation and management. It

requires hard work, adequate time to perform requirements activities, and
persistence.

Requirements elicitation activities are not typically performed very well.

Many people, including users, clients, management, and project team
members, do not understand the requirements elicitation (capturing and
analyzing) process.

Many projects do not allow sufficient time in the project plan to adequately
elicit requirements, document them, and track & control them throughout
the project’s life cycle.

On average, requirements management activities take approximately 6%

of the project resources. Given their importance, this figure is extremely
low. Over half of rework errors can be traced back to errors in the
requirements definition (Managing Systems Requirements: Methods, Tools,
and Cases, Stephen Andriole).

! !82
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

2. Communications

Communication challenges include:

• Communication and coordination breakdowns among members of the

design and development team

• Lack of client agreement on acceptance criteria

• Poor communications skills that are due to lack of training and

experience.

These challenges are described well in this example: The fact remains that
when trying to build something for which there are no existing, time-tested
design patterns, or when the gap between the patterns and the problem is
large, there is no guarantee of ever finding a solution that meets
requirements.

3. Understanding/Knowledge

Challenges include:

• Thin spread of application domain knowledge

• Lack of training and experience in requirements methods, tools, and

techniques

• Under-appreciation for each other’s environment.

Consider that customer and/or user knowledge of your methodologies and

techniques limits their participation in this requirements management
process.

4. Staff/People

Challenges include:
• Wrong people involved
• Developers do not like users and vice versa
• The right people may not be available often or long enough
• We may wear out our welcome.

! !83
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

5. Processes, Tools, and Techniques

Challenges include:

• Lack of belief in the front end of the process

• Failure to differentiate between purposeful, functional, and Non-

functional requirements

• No trade-off analysis

• Moving too fast or too slow in eliciting and interpreting requirements

• Failure to use prototyping and other techniques

• Difficulty modeling and communicating requirements

• Flawed requirements specification

• Too little testing and internal review

• Missing audit trails

• Too little management and oversight of the requirements process.

Conclusion

There are many challenges in software development. Some of the most

expensive ones occur in the requirements phase because that is where the
foundation for your entire project is laid. Ineffective requirements
elicitation and requirements management techniques lead to problems that
can paralyze your software project.

! !84
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

4.10 OVERCOMING SOME OF CHALLENGES IN

REQUIREMENTS ELICITATION AND GATHERING

Some of the approaches which help overcome many of the problems

discussed include:

• Studying stakeholders and seeking the involvement and time from the
most effective among them – escalating where support is lacking

• Studying the process from multiple perspectives and not relying entirely
on what users/stakeholders have to share – this could include speaking
to stakeholder/user, direct observation of work done by stakeholder/user,
tracing paper flows across the office, inspecting real-life data and
transaction documents, verifying discussions with one person with
another person in the same department or a receiving process – these
and other methods shown the table above must be used to cross verify
and gather more holistic requirements

• Preparing well before meeting the stakeholder/user. Use of Event analysis

helps in identifying atleast 60-70% of the events in the business process.
Such a checklist can be prepared in advance and used for confirming with
stakeholder/user. The discussion then tends to be more productive
leaving more time for stakeholder/user to contribute to those events
which require his experience and expertise to identify

• Documenting the discussions and walking the user through the

documentation to reconfirm the understanding.

! !85
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

4.11 A MODEL FOR AN EFFECTIVE REQUIREMENTS

GATHERING PROCESS

As shown above, the BA has on one hand the task of –

• gathering and sensing requirements (not merely depending on

stakeholders'/users' description

• Shaping requirements – by telling clients how the proposed system

would look like – toning down requirements and expectations throughout
the project

On the other hand after meeting the user and capturing some part of his
process and requirement, the BA must use various visual modeling
techniques such as data flow diagrams, object models etc. as a means of
thinking and understanding the needs. The diagrams invariably generate a
lot of questions in the mind often the BA for which he can seek clarification
during the next meeting.

! !86
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

The BA during every visit is also observing the broader environment in the
client organization or what has been show in the model above as the larger
context in which the process under study is expected to perform.

The model is highly iterative and the BA must go through several rounds of
capture-modeling cycles to ensure completeness in requirements
gathering.

4.12 SUMMARY

• Requirements Elicitation, Gathering and Analysis is the most important

process in Business Analysis.

• Elicitation/gathering refers to the act of extracting/collecting

requirements from various sources and using various tools.

• While studying a business process, it is important to study it from as

many perspectives as possible.

• The various perspectives which a BA could use for understanding a

business process thoroughly include the flow, dynamic perspective, the
business rules perspective, the solution perspective, the enterprise
perspective, the Human factors perspective and the security perspective.
Each perspective provides only one view of the process or system. It is
important — as the BA is able to integrate his understanding gained from
separate perspectives.

• There are several problems which a BA can face during elicitation,

gathering/collection of requirements. He needs to understand how to
deal with these to ensure complete and accurate requirements.

• A simple model of requirements elicitation and gathering would involve 3

broad blocks, viz., the front end task of elicitation, observation, shaping
and gathering a backhome task of modeling and thinking and generating
more questions to ask and the lateral task of studying the larger context
in which the process has to perform.

! !87
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

4.13 SELF ASSESSMENT QUESTIONS

1. What is Requirements Elicitation, Planning and Analysis?

2. Describe the purpose and importance of Requirements Elicitation,

Planning and Anlaysis.

3. Explain the key perspectives and tools for studying a business process.

4. Who is the Business Analyst Customer?

5. Describe the difficulties faced in Requirements Elicitation and Gathering

and how to overcome some of its challenges.

6. Write a note on the Model for an effective requirements gathering

process.

4.14 Multiple Choice QUESTIONS

1. Which of the following is the broad processes as described by The IIBA

BoK ver 2.0?
a. Business Analysis Planning and Management
b. Requirements Management and Communication
c. Requirements Elicitation
d. All of the above

2. This is much like understanding the architecture of a building – where

we look at the front view, top view, the sectional views, the side view
etc.
a. True
b. False

3. Which of the following describes the Flow perspective?

a. Understand the information needs from the standpoint of Information
needed by every.
b. Understand the flow of work, information and processes.
c. Purpose is to understand the components of the process and their
relationships.
d. The understanding about the company, products/ services.

! !88
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

4. Requirements Gathering is both an art and science; while __________

are important, the ability to deal with various types of stakeholders/
people and get their support and the ability to anticipate and overcome
difficulties in requirement gathering is of immense importance.
a. methods
b. techniques
c. Both A & B of the above
d. None of the above

5. Which of the following is an approach which help overcome many of the

problems discussed that include in requirements elicitation and
gathering?
a. Studying stakeholders and seeking the involvement and time from
the most effective among them – escalating where support is lacking
b. Preparing well before meeting the stakeholder/user.
c. Documenting the discussions and walking the user through the
documentation to reconfirm the understanding.
d. All of the above

Ans: 1 - (d), 2 - (a), 3 - (b), 4 - (c), 5 - (d)

! !89
 REQUIREMENTS ELICITATION, GATHERING AND ANALYSIS

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture - Part 1

Video Lecture - Part 2


! !90
 THE FLOW PERSPECTIVE

Chapter 5
The Flow Perspective
Objectives

After reading this chapter, you will be able to:

• To appreciate the purpose of studying the flow perspective of a business

process

• To understand the various levels of flows in an organization

• To learn various methods for studying flows and the pros and cons of
each

Structure

5.1 Introduction to the Flow Perspective

5.2 Diagramming Tools for Flow Perspective

5.2.1 Activity Diagram

5.2.2 Data Flow Diagram

5.2.3 Process Charts

5.3 Summary

5.4 Self Assessment Questions

5.5 Multiple Choice Questions

! !91
 THE FLOW PERSPECTIVE

5.1 INTRODUCTION TO THE FLOW PERSPECTIVE

Usually when studying any business it is a good practice to understand the

scope and nature of business. To gain a better understanding about the
business, a quick study of the flow of work or flow of business process is
necessary, the purpose being to understand the core functions or processes
required in this business and the relationship either in terms of sequence/
timing/dependency or in terms of information flows.

The study of flows can be done at a deeper level as well where the BA is
seeking to not merely identify the functions required but the underlying
process logic. The study of flow can be done at four levels:

• Workflow level which traces actual work done perhaps from desk to desk
• Data flow or information flow level
• Broad process level
• Service level

The work flows are characterized by work instructions (steps to take),

rules, routes and roles for people. Thus, a normal insurance premium case
can be routed through a certain series of steps while a delayed payment or
a payment for lapsed policy may require different steps and are therefore
routed to different desks in the office.

Data flows or information flows are best studied using data flow diagrams
and focus only on processes and the flow, store and transformation of data
or information in these processes. Data flow diagrams do not intend to
imply sequence of execution or timing. They only indicate several
concurrent processes each passing information to other processes through
information flows.

Broad process level studies typically use higher level process mapping tools
such as the Business Process Modelling Notation (BPMN) or activity
diagrams. These study of a broad process such as say a Executive
Recruitment process which may have several sequential steps, a few
decision situations such as accept or reject a candidate, and a few looped
steps such as if candidate is offered the job does not accept it go back and
approach the next best candidate etc.

! !92
 THE FLOW PERSPECTIVE

At the service level, the objective is to study an end-to-end service being

delivered by a business. The service may have several attributes such as
the tangible aspect (such as a product) of the service, the intangible such
as customer experience, the service level agreement (SLA) etc. The service
itself leverages one or more processes to ensure delivery of the services.
Several methods of analyzing services have been defined. Broadly, they
involve service blueprinting and drawing service scapes.

This could lead to understanding how decisions are taken or how data is
transformed to information by the process.

5.2 DIAGRAMMING TOOLS FOR FLOW PERSPECTIVE

5.2.1 Activity Diagram

This diagram is ideally suited for study of detailed workflows and when
analyzing business processes in great details for the purpose of
understanding inherent process logic, sequence of activities and timing.

! !93
 THE FLOW PERSPECTIVE

Some of the salient features of this diagramming technique are

summarized below:

• The figure above shows an example of an activity diagram. Note that

there is a possibility of showing parallel tracks or swim lanes shown
activities done in each department. Also please note that the flow breaks
into parallel flows and then synchronizes the outputs of all three
processes. There could also be a decision box like a conventional flow
chart.

• Uses a few simple symbols used in flowcharting such as the activity box,
decision diamond/branched flows, sequential flows and looped flows and
generating parallel flows (known as swim lanes) and synchronizing them
if required.

• The distinct advantage of the activity diagram over the conventional flow
chart is that it allows the creation of multiple parallel flows. This helps in
representing real-life workflow and process situations. For example,
copies of a document could be sent to several departments in parallel for
process from the point of view of that department – A customer order
can for example be copied to the Production Planning, the Despatch, the
Commercial department, design department etc. so that they could
respectively carry out activities such as production planning, planning of
packaging material, transport and other dispatch documentation,
commercial department to carry out commercial clearances with the
customer and design department to ensure the design/customization of
the product as per customers' requirements. Even more interesting is the
fact that the activity diagram allows the synchronization of these flows –
thus in the previous example dispatch will not be allowed until
commercial clearance, production etc. have taken place.

• Thus, the activity diagram brings in sequence, timing and dependence

into the understanding of the process flow.

! !94
 THE FLOW PERSPECTIVE

Purpose and Use of Activity Diagrams

Activity diagram is another important diagram in Unified Modeling

Language (UML) to describe the dynamic aspects of the system.

Activity diagram is basically a flowchart to represent the flow from one

activity to another activity. The activity can be described as an operation of
the system.

The control flow is drawn from one operation to another. This flow can be
sequential, branched, or concurrent. Activity diagrams deal with all type of
flow control by using different elements such as fork, join, etc.

Purpose of Activity Diagrams

The basic purposes of activity diagrams are similar to other four diagrams.
It captures the dynamic behaviour of the system. Other four diagrams are
used to show the message flow from one object to another but activity
diagram is used to show message flow from one activity to another.

Activity is a particular operation of the system. Activity diagrams are not

only used for visualizing the dynamic nature of a system, but they are also
used to construct the executable system by using forward and reverse
engineering techniques. The only missing thing in the activity diagram is
the message part.

It does not show any message flow from one activity to another. Activity
diagram is sometimes considered as the flowchart. Although, the diagrams
look like a flowchart, they are not. It shows different flows such as parallel,
branched, concurrent, and single.

The Purpose of an Activity Diagram can be Described as −

1. Draw the activity flow of a system.

2. Describe the sequence from one activity to another.

3. Describe the parallel, branched and concurrent flow of the system.

! !95
 THE FLOW PERSPECTIVE

How to Draw an Activity Diagram?

Activity diagrams are mainly used as a flowchart that consists of activities

performed by the system. Activity diagrams are not exactly flowcharts as
they have some additional capabilities. These additional capabilities include
branching, parallel flow, swimlane, etc.

Before drawing an activity diagram, we must have a clear understanding

about the elements used in activity diagram. The main element of an
activity diagram is the activity itself. An activity is a function performed by
the system. After identifying the activities, we need to understand how
they are associated with constraints and conditions.

Before drawing an activity diagram, we should identify the following

elements −

(a) Activities
(b) Association
(c) Conditions
(d) Constraints

Once the above-mentioned parameters are identified, we need to make a

mental layout of the entire flow. This mental layout is then transformed
into an activity diagram.

Following is an example of an activity diagram for order management

system. In the diagram, four activities are identified which are associated
with conditions. One important point should be clearly understood that an
activity diagram cannot be exactly matched with the code. The activity
diagram is made to understand the flow of activities and is mainly used by
the business users.

Following diagram is drawn with the four main activities −

1. Send order by the customer

2. Receipt of the order
3. Confirm the order
4. Dispatch the order

! !96
 THE FLOW PERSPECTIVE

After receiving the order request, condition checks are performed to check
if it is normal or special order. After the types of order is identified,
dispatch activity is performed and that is marked as the termination of the
process.

Where to Use Activity Diagrams?

The basic usage of activity diagram is similar to other four UML diagrams.
The specific usage is to model the control flow from one activity to another.
This control flow does not include messages.

Activity diagram is suitable for modelling the activity flow of the system. An
application can have multiple systems. Activity diagram also captures these
systems and describes the flow from one system to another. This specific
usage is not available in other diagrams. These systems can be database,
external queues, or any other system.

! !97
 THE FLOW PERSPECTIVE

We will now look into the practical applications of the activity diagram.
From the above discussion, it is clear that an activity diagram is drawn
from a very high level. So, it gives high level view of a system. This high-
level view is mainly for business users or any other person who is not a
technical person.

This diagram is used to model the activities which are nothing but business
requirements. The diagram has more impact on business understanding
rather than on implementation details.

Activity diagram can be used for –

(a) Modeling work flow by using activities.

(b) Modeling business requirements.
(c) High level understanding of the system's functionalities.
(d) Investigating business requirements at a later stage.

5.2.2 Data Flow Diagram

As shown in the diagram above, the data flow represents a business or a

business process for an Advertising firm — in the form of flow store and
transformation of data or information. It helps trace the information flow
from its orgin or source and through its various stages of transformation till
it is either sent to a consumer or sink of data/information or to a data
store.

Data flow diagrams can be drawn in the form of higher level abstractions
indicating broad processes and later expanded into more detailed diagrams

! !98
 THE FLOW PERSPECTIVE

on separate sheets depending on the need for understanding greater

detail.

The data flow diagram, however, does not imply timing, sequence or
dependence. Decisions if any taken in business are converted to decision
processes with inflowing data and outgoing decision outcomes
communicated to another process.

Data flow diagrams can however be used effectively by a BA for:

• Defining the scope of the proposed solution – i.e., which processes,

stores and flows are included in the solution and which are deemed to be
outside the boundary of the solution.

• It helps in understanding the board set of processes and functions

needed for an organization.

• It helps in visualizing a new process – by either combining, splitting or

redefining existing processes. Thus, for example, combining the enquiry
handling process with order handling and scheduling process into a single
customer service process can make the overall service delivery extremely
effective. The choice of combining enquiry and order or enquiry, order
and scheduling can be visually simulated using the data flow diagram.

• From the foregoing, it is obvious that reorganizing processes in the

manner described above would invariably lead to a need to redefine the
role and job description and hence indeed the competencies of the
person in that job and role. Thus, the data flow diagram has the potential
to trigger thought around major business process transformation also
commonly called a Business Process Reengineering (BPR). It can also be
a good tool for organizational restructuring which would follow in the
wake of such a BPR.

! !99
 THE FLOW PERSPECTIVE

Introduction to data-flow diagrams

What are data-flow diagrams?

A data flow diagram (DFD) maps out the flow of information for any
process or system. It uses defined symbols like rectangles, circles and
arrows, plus short text labels, to show data inputs, outputs, storage points
and the routes between each destination.

Data flowcharts can range from simple, even hand-drawn process

overviews, to in-depth, multi-level DFDs that dig progressively deeper into
how the data is handled. They can be used to analyze an existing system
or model a new one.

Like all the best diagrams and charts, a DFD can often visually “say” things
that would be hard to explain in words, and they work for both technical
and Non-technical audiences, from developer to CEO. That’s why DFDs
remain so popular after all these years. While they work well for data flow
software and systems, they are less applicable nowadays to visualizing
interactive, real-time or database-oriented software or systems.

! !100
 THE FLOW PERSPECTIVE

Data-flow diagrams (DFDs) model a perspective of the system that is most

readily understood by users – the flow of information through the system
and the activities that process this information.

Data-flow diagrams provide a graphical representation of the system that

aims to be accessible to computer specialist and non-specialist users alike.
The models enable software engineers, customers and users to work
together effectively during the analysis and specification of requirements.
Although this means that our customers are required to understand the
modelling techniques and constructs. In data-flow modelling only a limited
set of constructs are used, and the rules applied are designed to be simple
and easy to follow. These same rules and constructs apply to all data-flow
diagrams (i.e., for each of the different software process activities in which
DFDs can be used).

What Is the Purpose of a Data Flow Diagram?

Data flow diagrams are used by information technology professionals and

systems analysts to document and show users how data moves between
different processes in a system. Analysts generally start with an overall
picture and then move on to the finer details of each process.

Data flow diagrams provide a graphical representation of how information

moves between processes in a system. Data flow diagrams follow a
hierarchy; that is, a diagram may consist of several layers, each unique to
a specific process or data function.

The Benefits of Data-flow Diagrams

Data-flow diagrams provide a very important tool for software engineering,

for a number of reasons:

• The system scope and boundaries are clearly indicated on the diagrams
(more will be described about the boundaries of systems and each DFD
later in this chapter).

• The technique of decomposition of high level data-flow diagrams to a set

of more detailed diagrams, provides an overall view of the complete
system, as well as a more detailed breakdown and description of

! !101
 THE FLOW PERSPECTIVE

individual activities, where this is appropriate, for clarification and

understanding.

Note

Use-case diagrams also provide a partition of a software-system into those

things which are inside the system and those things which are outside of
the system.

Symbols and Notations Used in Data Flow Diagrams

There are essentially two different types of notations for data flow
diagrams. Two common systems of symbols are named after their
creators:

• Yourdon and Coad & Yourdon and DeMarco

• Gane and Sarson

Yourdon & Coad or Gane & Sarson are defining different visual
representations for processes, data stores, data flow and external entities.

Yourdon and Coad type data flow diagrams are usually used for system
analysis and design, while Gane and Sarson type DFDs are more common
for visualizing information systems.

Visually, the biggest difference between the two ways of drawing data flow
diagrams is how processes look. In the Yourdon and Coad way, processes
are depicted as circles, while in the Gane and Sarson diagram the
processes are squares with rounded corners sometimes called lozenges.

Data flow diagramming employs four symbols to illustrate data movement;

squares to represent external entities, the sources and destinations of data
in a system; arrows to represent data flow; open-ended rectangles called
to indicate stationary data stores; and rounded squares indicate
transformations or manipulations to data.

There are other symbol variations in use as well, so the important thing to
keep in mind is to be clear and consistent in the shapes and notations you
use to communicate and collaborate with others.

! !102
 THE FLOW PERSPECTIVE

Using any convention’s DFD rules or guidelines, the symbols depict the four
components of data flow diagrams.

The picture below shows the standard shapes for both methodologies.

! !103
 THE FLOW PERSPECTIVE

The DFD notation consists of only four main symbols:

1. External entity: External entities are objects outside the system, with
which the system communicates. External entities are sources and
destinations of the system's inputs and outputs. The sources from which
information flows into the system and the recipients of information
leaving the system. External entities are notated as ovals.

An outside system that sends or receives data, communicating with the

system being diagrammed. They might be an outside organization or
person, a computer system or a business system. They are also known
as terminators, sources and sinks or actors. They are typically drawn on
the edges of the diagram.

2. Process: A process transforms incoming data flow into outgoing data

flow. The activities carried out by the system which use and transform
information. Processes are notated as rectangles with three parts, such
as “Order Supplies” and “Make Payments”.

Any process that changes the data, producing an output. It might

perform computations, or sort data based on logic, or direct the data
flow based on business rules. A short label is used to describe the
process, such as “Submit payment.”

3. Data store: Data stores are repositories of data in the system. They
are sometimes also referred to as files. Files or repositories that hold
information for later use, such as a database table or a membership
form. Each data store receives a simple label, such as “Orders.” Data
stores are notated as rectangles with two parts.

4. Data flow: The data inputs to and outputs from these activities.
Dataflow are pipelines through which packets of information flow. The
route that data takes between the external entities, processes and data
stores. It portrays the interface between the other components and is
shown with arrows; Label the arrows with the name of the data that
moves through it. It is typically labelled with a short data name, like
“Billing details.”

! !104
 THE FLOW PERSPECTIVE

The diagrams are supplemented by supporting documentation including a

data dictionary, describing the contents of data-flows and data stores; and
process definitions, which provide detailed descriptions of the processes
identified in the data-flow diagram.

DFD rules and tips

1. Each process should have at least one input and an output.

2. Each data store should have at least one data flow in and one data flow
out.

3. Data stored in a system must go through a process.

4. All processes in a DFD go to another process or a data store.

DFD levels and layers: From Context diagrams to Pseudocode

A data flow diagram can dive into progressively more detail by using levels
and layers, zeroing in on a particular piece. DFD levels are numbered 0, 1
or 2, and occasionally go to even Level 3 or beyond.

The necessary level of detail depends on the scope of what you are trying
to accomplish.

• DFD Level 0 is also called a Context Diagram. It’s a basic overview of the
whole system or process being analyzed or modelled. It’s designed to be
an at-a-glance view, showing the system as a single high-level process,
with its relationship to external entities. It should be easily understood
by a wide audience, including stakeholders, business analysts, data
analysts and developers.

• DFD Level 1 provides a more detailed breakout of pieces of the Context

Level Diagram. You will highlight the main functions carried out by the
system, as you break down the high-level process of the Context
Diagram into its sub processes. As these processes are added, the
diagram will need additional data flows and data stores to link them
together.

! !105
 THE FLOW PERSPECTIVE

• DFD Level 2 then goes one step deeper into parts of Level 1. Simply
break processes down into more detailed sub processes. It may require
more text to reach the necessary level of detail about the system’s
functioning.

• Progression to Levels 3, 4 and beyond is possible, but going beyond Level

3 is uncommon. Doing so can create complexity that makes it difficult to
communicate, compare or model effectively. Level 3 data flow diagrams
are detailed enough that it doesn’t usually make sense to break them
down further.

Using DFD layers, the cascading levels can be nested directly in the
diagram, providing a cleaner look with easy access to the deeper dive.

By becoming sufficiently detailed in the DFD, developers and designers can

use it to write pseudo code, which is a combination of English and the
coding language. Pseudo code facilitates the development of the actual
code.

How to create a data flow diagram?

Now that you have some background knowledge on data flow diagrams
and how they are categorized, you’re ready to build your own DFD. The
process can be broken down into 5 steps:

1. Identify major inputs and outputs in your system

Nearly every process or system begins with input from an external entity
and ends with the output of data to another entity or database. Identifying
such inputs and outputs gives a macro view of your system—it shows the
broadest tasks the system should achieve. The rest of your DFD will be
built on these elements, so it is crucial to know them early on.

2. Build a context diagram

Once you’ve identified the major inputs and outputs, building a context
diagram is simple. Draw a single process node and connect it to related
external entities. This node represents the most general process
information undergoes to go from input to output.

! !106
 THE FLOW PERSPECTIVE

The example below shows how information flows between various entities
via an online community. Data flows to and from the external entities,
representing both input and output. The center node, “online community,”
is the general process.

3. Expand the context diagram into a level 1 DFD

The single process node of your context diagram doesn’t provide much
information—you need to break it down into sub-processes. In your level 1
data flow diagram, you should include several process nodes, major
databases, and all external entities. Walk through the flow of information:
where does the information start and what needs to happen to it before
each data store?

4. Expand to a level 2+ DFD

To enhance the detail of your data flow diagram, follow the same process
as in step 3. The processes in your level 1 DFD can be broken down into
more specific sub-processes. Once again, ensure you add any necessary
data stores and flows—at this point you should have a fairly detailed
breakdown of your system. To progress beyond a level 2 data flow
diagram, simply repeat this process. Stop once you’ve reached a
satisfactory level of detail.

5. Confirm the accuracy of your final diagram

When your diagram is completely drawn, walk through it. Pay close
attention to the flow of information: does it make sense? Are all necessary
data stores included? By looking at your final diagram, other parties should
be able to understand the way your system functions. Before presenting
your final diagram, check with co-workers to ensure your diagram is
comprehensible.

! !107
 THE FLOW PERSPECTIVE

!
Sharing your data flow diagram

After completing your DFD, the next step is sharing it. You didn’t create it
just to keep to yourself—whether it’s team members, your boss, or
stakeholders, chances are somebody else needs to see it. If you create a
data flow diagram, you’ll have a variety of sharing options at your disposal.
Diagrams can be sent directly within, giving the recipient access to the
document. Depending on the recipient’s role, you can give them permission

! !108
 THE FLOW PERSPECTIVE

to edit or send the diagram as view only. Extensive integrations allow for
diagram sharing across several other platforms including G Suite and
Slack.

Types of Data Flow Diagram

Physical and logical data flow diagrams

Before actually creating your data flow diagram, you’ll need to determine
whether a physical or logical DFD best suits your needs. If you’re new to
data flow diagrams, don’t worry—the distinction is pretty straightforward.

A. Logical Data Flow Diagrams

Logical data flow diagrams focus on what happens in a particular

information flow: what information is being transmitted, what entities are
receiving that info, what general processes occur, etc.

The processes described in a logical DFD are business activities—a logical

DFD doesn’t delve into the technical aspects of a process or system. Non-
technical employees should be able to understand these diagrams.

B. Physical Data Flow Diagrams

Physical data flow diagrams focus on how things happen in an information

flow. These diagrams specify the software, hardware, files, and people
involved in an information flow. A detailed physical data flow diagram can
facilitate the development of the code needed to implement a data system.

Both physical and logical data flow diagrams can describe the same
information flow. In coordination they provide more detail than either
diagram would independently. As you decide which to use, keep in mind
that you may need both.

! !109
 THE FLOW PERSPECTIVE

Purpose and benefits of each Physical and Logical Data Flow

Diagrams

By starting with a current logical DFD, you map the flow of business
actions as they exist, which can highlight any shortcomings or
inefficiencies. Or, you may already know the type of functionality you’re
seeking to add, and the current logical DFD will help to reveal process
steps that may need to be dropped or changed.

As with any diagram, the logical DFD should be detailed enough to be

actionable. Depending on its scope, the current logical DFD may take time
to produce and seem tedious, but the time may be well spent.

Another benefit of logical DFDs is that they tend to be more easily

understandable to non-technical people. They will likely make sense to the
people working in the business activities. They will serve as a good tool for
collaborating and communicating about better information and functioning,
without concern for the “how” yet. They will serve as a bridge from
business needs to technical requirements.

The discipline of mapping out the current logical flow will help everyone
involved to gain a deeper understanding and reveal mistaken assumptions,
misunderstandings or shortcomings.

Doing logical models reduces the risk of missing business requirements

that otherwise would arise belatedly in the process, causing delays and
rework.

Then, with a solid understanding of the current business activities, you can
model a better way with a new state logical DFD, showing new features
and functioning based on what the business analysis has revealed.

This new logical DFD models what data flows are necessary to create the
better functioning, no matter what the technical solution or how the
system will be implemented.

After the new logical DFD is drawn, it in turn can be used to figure out the
best method to implement the business activities in an upgraded system.
This becomes the basis for the new physical DFD, depicting that physical

! !110
 THE FLOW PERSPECTIVE

implementation of devices, software, files and people to enable the

business processes.

In this sense, the physical DFD becomes the method of giving the business
what it needs. It’s the “how” fueling the “what.” The physical DFD then
provides the basis of an implementation plan to provide the new software,
hardware, people or other physical pieces needed to run the business
process.

Examples of How DFDs can be used

Data flow diagrams are well suited for analysis or modeling of various
types of systems in different fields.

DFD in software engineering: This is where data flow diagrams got their
main start in the 1970s. DFDs can provide a focused approached to
technical development, in which more research is done up front to get to
coding.

DFD in business analysis: Business analysts use DFDs to analyze

existing systems and find inefficiencies. Diagramming the process can
uncover steps that might otherwise be missed or not fully understood.

DFD in business process re-engineering: DFDs can be used to model a

better, more efficient flow of data through a business process. BPR was
pioneered in the 1990s to help organizations cut operational costs, improve
customer service and better compete in the market.

DFD in agile development: DFDs can be used to visualize and

understand business and technical requirements and plan the next steps.
They can be a simple yet powerful tool for communication and
collaboration to focus rapid development.

DFD in system structures: Any system or process can be analyzed in

progressive detail to improve it, on both a technical and non-technical
basis.

! !111
 THE FLOW PERSPECTIVE

5.2.3 Process Charts

Introduction to Process Charts

The charting of work flows, working processes, systems and procedures is

a useful way of recording the essential features of a work situation for
subsequent analysis.

Process Charts are one of the simpler forms of workflow charting and are
still in regular usage but are less common than they once were. This is
unfortunate since it was the ubiquitous nature of the process chart that
made it a common "language" between different groups of people and
across different industries.

A variety of process charts has been designed to meet the needs of a

particular level or stage of analysis; they can be used at a detailed level
(recording activity at a specific work station or workplace), but also at the
wider system, process or procedure level.

The different kinds of process chart share a common core set of symbols,
though some have additional symbols for specific and specialised process
steps. The common symbols (of which there are only five) were first
promulgated by the American Society of Mechanical Engineers and have
become known as the ASME symbols.

! !112
 THE FLOW PERSPECTIVE

These symbols are simply linked together in a vertical chart representing

the key stages in a process; it is usual to place a commentary in adjoining
column recording contextual/environmental information. e.g. against a
Transport symbol would be recorded, start of journey, end of journey,
distance and mode of transport.

The simplest form of process chart is known as an outline process chart

and records an overview or outline of a process. Only those steps of a
process that can be represented by the ASME symbols of operation and
inspection are recorded. An outline process chart is often a useful first step
to identify key areas of concern before recording (part of) the process in
more detail.

In a "full" process chart, where all symbols are used, it is common to chart
the process from the "viewpoint" of the material being processed, the
worker carrying out the work or, less commonly, a piece of equipment.
Thus, the same symbols can be used in different ways. As a simple
example, a piece of equipment can be represented on an equipment-type

! !113
 THE FLOW PERSPECTIVE

flow process chart as a delay because it is not in use; while a material-type

flow process chart of the same process would show the material being
transported to the next work station, and a man-type chart could show the
operator involved in another operation on another machine.

The chart to be used may be determined by the purpose of the

investigation or by the relative costs involved in the process - a highly
capital-intensive process may focus more attention on the equipment being
used.

Process charts may also be used at a more micro level of analysis. An

example is the two-handed process chart which records the motions
performed by both hands during a task. The sequence of motion of each
hand is charted using the same symbols as before. There are slight
changes to the meaning of the symbols, however. The delay symbol is used
to indicate that the hand is waiting to carry out its next task. The storage
symbol is used to indicate that the hand is holding on to a piece of material
or a document. Two-handed process charts are usually drawn on a pre-
formatted diagram. Their use has generally been superseded by the
analyses involved in the use of low level pre-determined motion time’s
systems.

Business Process Modeling Notation (BPMN)

With many definitions going around and multiple ways to go about it,
business process modeling can be a bit confusing, especially for a beginner.
But when you go deeper you’ll realize that there isn’t much of a difference
in most approaches. This business process modeling tutorial will help you
learn more about the various definitions, features, history behind BPM.

Definition of Business Process Modeling

Among many definitions available online for Business Process Modeling,

following are few that captured our attention;

1. BPM is a mechanism for describing and communicating the current or

intended future state of a business process.

2. BPM is a means of representing the steps, participants and decision

logic in business processes.

! !114
 THE FLOW PERSPECTIVE

3. BPM is a method for improving organisational efficiency and quality. Its

beginnings were in capital/profit-led business, but the methodology is
applicable to any organised activity.

4. BPM aims to improve business performance by optimising the efficiency

of connecting activities in the provision of a product or service.

5. BPM is a set of activities for representing business processes in a formal

way enabling analysis and further improvement of these processes.

6. Business Process Modeling is a combination of various process related

steps such as Process Mapping, Process Discovery, Process Simulation,
Process Analysis and Process Improvement.

With all above being true, it can be summarized as how work gets done in
an Enterprise or an organization.

How BPM Evolved?

BPM has emerged rapidly throughout the last two to three decades and has
replaced previous organizational efficiency practices such as the Time and
Motion Study (TMS) or Total Quality Management (TQM). Such demand for
BPM is a result of,

1. Increasing transparency and accountability of all organizations including

public services and government

2. Increase in usage of information and communication systems

3. Modern complexity of business

BPM can be considered as a quality management tool due to its

1. Technical nature,

2. The process emphasis and

3. Analytical approaches & responsibilities arising in the improvement of

quality, in the market.

! !115
 THE FLOW PERSPECTIVE

Business process modeling is highly useful in change management of

organizations.

Notable Business Process Modeling Features

A summarized list of BPM features are as follows;

a. BPM is commonly a diagram representing a sequence of activities. It

typically shows events, actions and links or connection points, in the
sequence from end to end.

b. It mainly focuses on processes, actions and activities, etc.

c. A Business Process Model includes both IT processes and people

processes.

d. Business Process Modelling is cross-functional, usually combining the

work and documentation of more than one department in the
organisation.

e. Resources feature within BPM in terms of how they are processed.

f. People (teams, departments, etc) feature in BPM in terms of what they

do, to what, and usually when and for what reasons, especially when
different possibilities or options exist, as in a flow diagram.

g. Business Process Modelling may also include activities of external

organisations’ processes and systems that feed into the primary
process.

h. In large organisation’s operations Business Process Models tend to be

analysed and represented in more detail than in small organisations,
due to scale and complexity.

i. Business Process Modelling is to an extent also defined by the various

computerized tools or software which is used in applying its methods.
These tools evolve with the change of time and therefore it is advised to
keep an open mind on how BPM can be used.

! !116
 THE FLOW PERSPECTIVE

Business Process Model Hierarchy

Following hierarchy is mainly used in process modelling for large

enterprises. It categorizes all the processes of an organization in to five
levels so that it is easier to streamline the outcome.

5 Tips to Master the Art of Business Process Modeling

Even though Business Process Modeling is a very effective way for business
organizations to keep track of their inner workings, many beginner
modelers tend to design them incorrectly and make mistakes, which
decrease their potential. The following are certain tips and suggestions you

! !117
 THE FLOW PERSPECTIVE

should keep in mind when designing your very own Business Process
Model.

1. Detail Every Step of the Individual Processes: This is a common

mistake that even the most experienced process modelers tend to
make, as they think it would be easier to understand a simpler diagram
as compared to a complicated one. While that may be true, leaving out
important details in a process model can leave the analyst confused as
to how a particular step took place.

Because you’re drawing the process model you might be aware of the
inner working and the logic behind the processes. But remember that
these models are used by analysts and consultants to identify flaws in
the process and improve them. It will be hard to give recommendations
when they don’t fully understand the logic behind the processes.

2. Use a Minimalist Approach: You might think this is contrary to the

first suggestion, but it isn’t. You can keep your business process model
simple without excluding any details.

This can be done by keeping sub-headers in the diagram, which could be

expanded to show details when they are clicked on. Or if you are printing
out the model, you can keep a top page highlighting all the important
processes, with further pages detailing all of them. This will help new
readers to quickly grasp the overall process, while adding sufficient
information to go through a page to get further information of a
particular process.

Although your using a software to model your processes more often than
not you need to take a printout or email an attachment to show them to
your colleagues or clients. So, printer friendly modeling is always a good
idea.

3. Use a Proper BPM Software: While a business process model may

look like a drawing, it is much more complicated than that, with various
elements and shapes used to define specific actions and processes.
Therefore, it is recommended that you use proper BPM software that
has support for BPMN 2.0, the latest business process modeling
standard approved by the object management group.

! !118
 THE FLOW PERSPECTIVE

This provides everything you need, to draw an effective business process

model. A separate library with all BPMN 2.0 symbols, business process
templates and productivity features like object grouping are some of the
highlights.

A complex BPMN diagram with lanes.

1. Create Labels Suggesting the Type of Action: This, again, helps

make the model easier to understand. A common technique used to
create such labels is the action-item methodology, which phrases the
action being performed as a prefix to the item it will be performed on.
For example, if an action is representing a statement validation, use the
label “validate statement” to define that action.

! !119
 THE FLOW PERSPECTIVE

2. Remember to Detail Alternative Routes: What most modelers tend

to do is simply label the alternative path and the end result to it, in case
of the preferred condition not being met, without going into much detail.
In such a scenario, it would be beneficial to explain the workings of the
alternative scenario, along with adding paths where the final preferred
condition can be met, if possible.

Again, remember that the objective is to improve the process even if it’s
an alternative path.

Importance of Business Process Modelling for Your Business

1. Align Operations with New Business Strategy: Implementing or

modifying a business strategy usually requires changes to operations
and people performing the work. And by nature, people resist change.
So, the processes, rules and the personal involved in the old strategy
can have an impact on the new strategy.

Business Process Modeling facilitates this by:

a. By helping managers and executives maintain consistency across

processes while keeping an eye on the overall strategy of the
organization.

b. By ensuring that the operational tasks and activities performed by

the team members actually help the organization implement its
strategy. If the processes and the strategies are not aligned it usually
leads to failure in execution. Because even if the operational tasks
are performed correctly, the overall organizational goals are not
achieved.

c. Implement Business Process Re-engineering (BPR) by understanding

the existing processes and changing them for improved performance
– Business process analysis helps in identifying bottlenecks and
inefficiencies in the processes and thus improving them.

d. Enable Process Agility, an ability to change and communicate

processes quickly to take advantage of new business opportunities or
address business challenges.

! !120
 THE FLOW PERSPECTIVE

!
e. Business process models help to visualize the processes to make
better decision

2. Improve Process Communication: One area that distinguishes

successful businesses and teams is that they have a very clear idea of
what they are supposed to do, how they are supposed to do it and what
is the exact role of every team member. Clear communication of the
operational processes is critical to facilitate a smooth functioning of a
team.

Business Process Modeling enables the documenting and communicating of

the organizations business processes:

a. Process modeling offers a common unified language and methodology

for communicating processes and information about processes and
decision rules.

b. It is ideal for training of new people and rapid knowledge transfer

because with a thoroughly documented process any new team
member can be very quickly trained on what they have to do in any
situation that they may face.

! !121
 THE FLOW PERSPECTIVE

c. Minimizes potential danger of loss of staff resulting in loss of business

process knowledge.

d. It helps business managers communicate their ideas quickly and

clearly.

e. Jump-starts the organizational process documentation initiative.

f. Turns the team’s experience into documented processes.

3. Increase Control and Consistency: Organizations and companies that

succeed are ones that ensure their business processes and rules are well
designed and that they are consistently applied the same way every single
time. This process control and consistency is the key success in any
organization.

Business Process Modeling makes this possible by helping:

a. Formalize existing processes which may not be well documented or

which have evolved over time into “informal knowledge.”

b. Execute a process in consistent manner because instead of relying on

people to remember to do the right thing the documented process
can be given to the business users.

c. Make better decisions because guesswork is eliminated as business

users can have the documented business rules in front of them.
d. Handle exceptions faster and in a better way.

e. Complete regulatory compliance by ensuring that the documented

processes follow the company guidelines and legal regulations.

f. Put business people in charge.

g. Support compliance initiatives such as Six Sigma, ISO 9000.

! !122
 THE FLOW PERSPECTIVE

4. Improve Operational Efficiency: In today’s business environment,

every business and every manager want to ensure that they are achieving
the best possible results with the resources available to them. There is no
room for inefficiencies and wastage.

a. The Process simulation and analysis steps of Business Process

Modeling are critical tools for managers and analysts to ensure that
their processes are optimized and are running accurately.

b. Process Simulation allows analysis and understanding of the process

flows and helps managers know if there is room for further
optimization and efficiencies.

c. It helps spot needed improvements and reduce process cycle time.

d. It increases productivity of existing resources and staff and so allows

the team to do more with less.

e. It facilitates risk free experimentation and encourages exchange of

process improvement ideas.

f. Process simulation allows modeling of process designs before actually

implementing them thus minimizing disruptions.

g. It encourages a mind-set of continually optimizing business critical

processes to incrementally improve operational efficiency.

h. Process analysis enables better resource utilization.

5. Gain Competitive Advantage: All the benefits mentioned above lead

to a significant competitive advantage for an organization that has invested
the time and effort to document, simulate and improve its business
processes.

Studies of many wildly successful companies has often shown that they
succeeded not only because of better ideas or better business models. But
also, because they constantly refined and improve their processes through
business process modeling.

! !123
 THE FLOW PERSPECTIVE

A slight improvement in one activity here and another one there leads to
an overall better process. And those little refinements help organizations
run efficiently and give the edge over their competitors.

Example of a Business Process Modelling Diagram (BPMN)

Several approaches to process mapping exist in literature. The essence of

these is to help depict process steps, decision points, looping and
branching, events which trigger the steps, process inputs and outputs etc.

The Business Process Modelling Notation (BPMN) which has the potential to
become a standard form of documenting a business process combines all
the above elements plus several more. It has outlined several specialized
symbols to indicate types of events such as timer events etc. each with
their distinct symbol.

Clearly identifying inputs and outputs triggered by an event at each

processing stage is an important aspect of a business process modeling
tool.

However, the BA must be judicious and frugal when using a wide variety of
symbols since they can only make it difficult to interpret. Comments and
annotations can at times simplify and reduce the need for a great variety of
symbols.

Process diagrams have the advantage that Non-IT people can easily relate
to them.

! !124
 THE FLOW PERSPECTIVE

5.3 SUMMARY

• Understanding the flow of work or a process is fundamental to

understanding any business.

• Understanding the flow should be first step of any analysis or consulting

exercise.

• Flows can be studied at several levels workflow, information flow, process

flow, service flows.

• Several techniques can be used for studying and analyzing the flow
perspective. The more prominent among these are the Activity diagram,
the Data flow diagram, the BPMN and other process charts – there are
pros and cons of each tool.

• Understanding the flow helps in understanding the core functions that

need to be performed in a business.

5.4 SELF ASSESSMENT QUESTIONS

1. What do you mean by flow perspective? What are the various levels of
flows in an organization?

2. Describe the various diagramming tools for studying flows. Also explain,
the pros and cons of each flow in detail.

3. What is the purpose of studying the flow perspective of a business

process?

! !125
 THE FLOW PERSPECTIVE

5.5 Multiple Choice Questions

1. Data flow diagrams intend to imply sequence of execution or timing.

a. True
b. False

2. __________ diagram is ideally suited for study of detailed workflows

and when analyzing business processes in great details for the purpose
of understanding inherent process logic, sequence of activities and
timing.
a. Activity Diagram
b. Data Flow Diagram
c. Process Charts
d. Business Process Modelling Notation

3. For which of the following reason data flow diagrams can be used
effectively by a Business Analysts?
a. Defining the scope of the proposed solution – i.e., which processes,
stores and flows are included in the solution and which are deemed
to be outside the boundary of the solution.
b. It helps in understanding the board set of processes and functions
needed for an organization.
c. It helps in visualizing a new process – by either combining, splitting
or redefining existing processes.
d. All of the above

4. Clearly identifying __________ triggered by an event at each

processing stage is an important aspect of a business process modeling
tool.
a. inputs
b. outputs
c. Both A & B of the above
d. None of the above

! !126
 THE FLOW PERSPECTIVE

5. The Business Process Modelling Notation (BPMN) which has the potential
to become a __________ form of documenting a business process
combines all the above elements plus several more; It has outlined
several specialized symbols to indicate types of events such as timer
events etc.
a. special
b. standard
c. specific
d. several

Ans: 1- (b), 2 - (a), 3 - (d), 4 - (c), 5 - (b)

! !127
 THE FLOW PERSPECTIVE

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture - Part 1

Video Lecture - Part 2


! !128
 THE INFORMATION PERSPECTIVE

Chapter 6
The Information Perspective
Objectives

After reading this chapter, you will be able to:

• To help BAs understand the importance of Information and Information

systems in organizations

• To understand key concepts and practical issues about information and

Information systems which BAs

• To relate key information concepts to the context of Business Analysis

• To appreciate the use of Information technology in information systems

and in business in general

Structure

6.1 Importance of Information and Information Systems in Organization

6.2 What BAs Must Know about Information Concepts and Information
Systems?

6.3 The Role of Information Technology in Information Systems

6.4 Summary

6.5 Self Assessment Questions

6.6 Multiple Choice Questions

! !129
 THE INFORMATION PERSPECTIVE

6.1 IMPORTANCE OF INFORMATION AND INFORMATION

SYSTEMS IN ORGANIZATION

One of the core purpose of using information technology in a company to

ensure that

• people in the organization get information that they need

• most decisions taken in the organizations are based on information

supplied by formal information systems.

Unfortunately, the aura associated with technology makes us at times to

forget the above fundamental truths. It has been found in many
organizations with sophisticated IT solutions such as ERP, CRM, SCM etc.

• Many decisions are still taken based on gut feel because relevant
information is not available either in time, form or where it is required.

• While transaction systems run on IT, MIS is offline on spreadsheets and

the like – not fully based on underlying transactions – this defeats the
goal of having a ‘fact based’ organization wherein underlying transactions
are used to directly prepare MIS and not cooked up information in
spreadsheets which can be misleading to the decision maker.

One other problem associated with Information is that executives are at

times unable to express their information on the one hand while software
professionals have very little appreciation about Information since they
themselves have never been consumers of information.

It is therefore important that Business Analysts understand the nature of

information and information systems and how they are important in the
context of an organization and a decision maker.

The core concepts relating to information and information systems have

been dealt with in great detail in the course IT for Management. It suffices
here to summarize some of the aspects of Information and Information
systems which are important to remember. Even more important is the fact
that the BA must try and use this list of concepts as a checklist while
studying or designing information systems.

! !130
 THE INFORMATION PERSPECTIVE

6.2 WHAT BAS MUST KNOW ABOUT INFORMATION

CONCEPTS AND INFORMATION SYSTEMS?

Sr.
Information Concept Implication for Business Analyst
No.
1 Data when processed • BAs must try and understand the role of the
and relevant becomes person and therefore what is relevant to him.
information What is
relevant depends on • At higher levels, people prefer summarized,
the role of the person, consolidated information which gives them a
his hierarchical position sense of whether they are in control or not.
etc.

2 Data and Information • The BA must ensure that the system he

Lifecycle – covering designs covers all aspects of from creation to
stages such as creation, disposal — this gives a comprehensive system.
capture, validation,
storage/retrieval,
processing,
presentation, backup,
archival and disposal
3 Information is not what • Presentation of information is a very important
we present but what aspect — BAs must familiarize themselves with
gets constructed in the Information Design in the manner of visual
minds of the reader design to ensure they create a positive
Information is used in presentation bias in the mind of the reader.
decision making
Decision making • BAs should keep in mind how IT can help in
processes are explained supporting all stages of a decision process,
by both rational as well viz., Intelligence, Design (alternatives) and
as behavioural theories Choice (embedding decisions/rules in
software).

• BAs should be able to identify decision points

in the process and ask — what information is
required for taking the decision versus what is
available.

! !131
 THE INFORMATION PERSPECTIVE

• Certain complex decisions taken by 'experts' in

an organizations should be seen as
opportunities to design Decision support
systems which can create a backup for such
expertise and deskill the work.

• Information systems should be designed in a

manner which is appropriate to the risk, risk
appetite of decision makers, speed of work and
other emotional factors which can impact the
need for information.
4 Information is used a • A BA must study the flow of information to
basic organizational ensure that there is no gaps in information
glue across the organization — this includes people
placed in remote and on-site locations —
information and communication systems also
help create a sense of belonging to the
individual and he feels connected and a part of
the organization.

5 Information has several • The BA must use these characteristics as a

characteristics such as checklist to ensure that he gathers these
source, type, age/ characteristics.
currency etc.
• Increasingly external sources of data about
consumers, competitors etc. has to be
combined with internal MIS to provide a
comparative perspective. The BA must check
the sources of information and issues related
to conversion of formats etc.

• Likewise, these days Data includes all types

including photos, scanned documents, videos
etc. The BA must check for this possibility.

! !132
 THE INFORMATION PERSPECTIVE

6 Information is used for • The BA must ask this question during

compliances requirement gathering. He can also study the
domain and its broad compliance requirements
even before meeting the users.

• Each compliance requires that the BA designs

appropriate controls at various points in the
process, make the controls visible, and provide
a facility to provide evidence that the controls
work properly.
7 Information helps • BAs must look for opportunities to capture
create knowledge – knowledge and create a self-learning
knowledge is environment.
information +
experience of using • BAs must be ready to deal with unstructured
information + context information — for e.g., experiences of a user
The purpose of etc. which is captured from user generated
knowledge is to create data.
new business rules
• The BA must build systems which can are
flexible and can adapt to changing business
rules.

8 Information for • BAs must strive to identify how information

competition Information can provide a strategic edge to an
has value organization. The advent of Business
Intelligence tools, data mining, analytics etc.

• BAs must use various tools such

• BAs must find the value of Information and

Value of IT as a part of the business case for
justifying IT investments.
9 Information has value • BAs must identify critical information assets,
and is therefore an identify risks associated with these assets and
asset and needs to be gather requirements about negative use cases
protected (i.e., what users should not be allowed to do)

! !133
 THE INFORMATION PERSPECTIVE

10 • Information systems • A BA must analyze critical success factors

help in aligning each (CSFs) for each individual and design
person in the information systems which provide the
organization to a information which enables control.
common set of
objectives (e.g., Sales • While supervisory control is important, BAs
Budget) must aim at designing information systems
which help each person to succeed by
• Information systems providing information for self-control.
are required to enable
monitoring and • BAs must also design information systems
control. which capture information at source and do
not require people to put effort to get
information either for self-control or for
reporting upwards or for monitoring others of
for coordinating with peers.
11 Information systems • A BA must observe contextual aspects such as
are affected by factors culture (openness, bureaucratic etc.),
such as culture, structure/architecture (hierarchical, flat,
organization structure, collegial etc.) since they have a deep influence
architecture and people on the design of systems.

• Likewise, a study of human factors such as

backgrounds of people, ethnicity, etc help in
understanding the underlying preferences in
terms of language, symbols etc. in a given
context. It also helps define individuals in
broad personas helping in characterizing
groups of users.

! !134
 THE INFORMATION PERSPECTIVE

6.3 THE ROLE OF INFORMATION TECHNOLOGY IN

INFORMATION SYSTEMS

Apart from the obvious benefits which a computer has over human beings
such as speed, accuracy, consistency, repeatability, diligence, ability to
work non-stop etc. computer based systems tend to contribute in four
broad ways:

• Productivity: This is a result of —

- Elimination of multiplicity in processing
- Disintermediation
- Combining multiple process steps into a single step
- 24 × 7 working thereby increasing availability of business to customers
- Direct reduction in manpower and overall transaction costs, etc.

• Business process transformation: This is in the form of dramatic

changes in performance and/or customer experience with respect to a
business process.

• Business network transformation: This would be transformation of

entire network of supply chain and value chain through the use of IT. The
transformation of the entire financial sector in India including broking
houses, stock exchanges, stock depositories etc. is a good example of
how all value chains can be transformed.

• Business scope transformation: This would imply that IT could help

an organization to redefine its business.

The BA must understand these impacts on IT and consciously aim for such
business impacts. It is seen that in many companies in which large
integrated software have been implemented without a proper goal focus,
the benefits accrued from such investments have been limited to
automation or transactions and operational management. However, higher
order benefits were not accured due to lack of focus. Many Enterprise
solutions and consulting firms and equally many end-user companies are
therefore focusing on extracting this value of IT by creating awareness
among users about possibility of exploiting existing applications for higher
order benefits.

! !135
 THE INFORMATION PERSPECTIVE

The BAs' understanding of several common information systems and

domain specific systems and the above concepts would go a long way
towards improving his/her effectiveness as a consultant.

6.4 SUMMARY

• The fundamental purpose of any Information system is to provide the

right information to the right person at the right time.

• The two quick ways to judge whether information systems are effective is
to check if each person in the organization gets the information he needs
and whether decisions in the organizations are taken on the basis of such
information.

• Business Analysts must understand several information and Information

systems concepts such as the data/information lifecycle, characteristics
of information, need and uses of information, relationship between
information and organization.

• This understanding will ensure that the BA understands the needs for
information of all stakeholders in an organization.

• The role of IT in business can be summed up by four ways – productivity,

business process transform, business network transform and business
scope transform.

6.5 SELF ASSESSMENT QUESTIONS

1. Explain briefly the importance of information and Information Systems

in Organization.

2. What must the BAs know about the Information Concepts and
Information System?

3. Describe the role of information technology in Information Systems.

! !136
 THE INFORMATION PERSPECTIVE

6.6 Multiple Choice QUESTIONS

1. Which of the following is one of the core purpose of using information

technology in a company?
a. People in the organization get information that they need
b. Most decisions taken in the organizations are based on information
supplied by formal information systems.
c. Both A & B of the above
d. None of the above

2. The core concepts relating to information and information systems have

been dealt with in great detail in the course IT for Management.
a. True
b. False

3. Which of the following is the implication of business analyst for the

information concept, as Information helps create knowledge –
knowledge is information + experience of using information + context.
The purpose of knowledge is to create new business rules.
a. BAs must look for opportunities to capture knowledge and create a
self-learning environment.
b. BAs must be ready to deal with unstructured information — for e.g.,
experiences of a user etc. which is captured from user generated
data.
c. The BA must build systems which re flexible and can adapt to
changing business rules.
d. All of the above

4. Business ______________ transformation would imply that IT could

help an organization to redefine its business.
a. Network
b. Scope
c. Process
d. Productivity

! !137
 THE INFORMATION PERSPECTIVE

5. ____________________ is in the form of dramatic changes in

performance and/or customer experience with respect to a business
process.
a. Business process transformation
b. Business network transformation
c. Business scope transformation
d. Elimination of multiplicity in processing

Ans: 1 - (c), 2 - (a), 3 - (d), 4 - (b), 5 - (a)

! !138
 THE INFORMATION PERSPECTIVE

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture

! !139
 THE DYNAMIC PERSPECTIVE

Chapter 7
The Dynamic Perspective
Objectives

After reading this chapter, you will be able to:

• Understand the importance of studying the dynamic perspective of a

business process

• To understand the application of the The Objects-Events method for

analyzing dynamic aspects of a business process

• To study the application of the State Transition Method for analyzing

dynamic aspects of a business process

Structure

7.1 Introduction to the Dynamic Perspective

7.2 The Objects and Events Method

7.3 State Transition Method

7.4 State Transition Diagram

7.5 Summary

7.6 Self Assessment Questions

7.7 Multiple Choice Questions

! !140
 THE DYNAMIC PERSPECTIVE

7.1 INTRODUCTION TO THE DYNAMIC PERSPECTIVE

Study of process flows using any of the tools described in the chapter on
flow perspective can mislead a BA into thinking that the flow diagram
completely describes the process. The process diagrams tend to show only
the static aspect of a business process – i.e., to say what happens on
‘under normal situation’. In practice, a variety of business situations could
challenge the smooth running of these processes. Thus, the success or
otherwise of a business process or an IT solution is decided not merely by
its smooth functioning on a normal day but also its ability to respond
effectively to a wide variety of business situations which may arise.

Thus, business analysis is really about identifying a wide variety of

business situations and designing appropriate responses to these
situations.

7.2 THE OBJECTS AND EVENTS METHOD

In formal terms, these could be called as events and responses to these

events.

Identification of events can be done by a combination of sheer

brainstorming as well as deep and wide in-context observation.

Many exceptional situations or extreme situations can either be imagined

or identified during such in-context studies when conducted at different
times and under different conditions. Thus, for example, while a point of
sale system may appear to work well on a normal day the BA would
discover that the system is unable to cope up with the work due to sheer
extreme volumes of transactions on weekends and holidays. Such
exceptional situations can be discovered only if the study is carried out at
different points of time. Failure to conduct the study on a weekend or
holiday would leave the BA with an incomplete understanding of the
business process.

! !141
 THE DYNAMIC PERSPECTIVE

To facilitate the identification of events, the BA can adopt the following

approach:

• Identify objects in the process – By definition, an object is literally

any thing which can affect the business process – it could be a physical,
human, transaction/document or conceptual object.

• Brainstorm on events for each object – This can be done easily by

merely asking the two questions:

– What can the object do ?

– What can happen to the object ?

• Develop appropriate response to each of the events.

The below example will illustrate this approach:

Suppose we were to study the process of storing visitors bags at a bag

counter at a shopping mall. The objects would be as follows:

Object Type Objects

Human Shopper/his representative, staff member

Physical Objects Counter, shelf, bag, token

Transaction/Document –

Conceptual Customer experience

Having identified the objects, we now analyze the possible situations:

Customer

• Customer hands over token back to the counter person

• Customer misplaces token
• Customer is unable to identify his bag
• Customer hands over an invalid token

! !142
 THE DYNAMIC PERSPECTIVE

Staff Member

• Hands takes bag from customer

• Keeps bag into an empty shelf
• Hands over token from the shelf to the customer
• Keeps the bag in the wrong shelf
• Does not find an empty shelf – keeps bag in an open space without
giving token
• Does not find an empty shelf – keeps bag in a shelf which has some
vacant space
• Is not available at the counter – takes a break
• Deals with a customer who has misplaced his token

Thus, from the foregoing, you will notice that it is much easier to focus on
one object or a pair of interacting objects and derive possible situations,
events or object behaviours.

It is now required to design appropriate solutions or responses to the

above situations. Since the process described above is largely manual, a
list of possible situations along with appropriate responses could be
documented in the form of a Standard Operating Procedure (SOP) and
practiced by the store staff.

7.3 STATE TRANSITION METHOD

While state transition diagram is a very familiar tool in the hands of

computer science practitioners, the use of the state transition diagram for
design of business processes is rarely discussed or practiced.

The state transition method studies an object in real life in terms of its
states and its transition from one state to another. Thus, the state of a bulb
is either ‘on’ or ‘off’ and what triggers the transition is the movement of the
switch by a person.

To take a business process example, consider the states and transitions of

a book in a library: 


! !143
 THE DYNAMIC PERSPECTIVE

The above diagram shows the states and transition of the account of a
bank customer. The transitions from one state to another are indicated with
an initial ‘/’ and a descriptor of the transition. A transition is seen as a
process while the state is a relatively stable condition of the object.

Analyzing states and transitions helps in revisiting the various possible

processes which an object undergoes. Many a time, a BA may have missed
out on some of the processes during his previous analysis such as through
process mapping or data flow diagrams. The state transition diagram helps
in inspecting the states and transitions of a few key objects more as a
means of verifying.

Many a time, it is observed states and transitions help identify transitions

for which there are no formal processes or documents or simply such
documents which are required on a really exceptional basis. For example,
the bank manager who may have explained the working of a bank may
have genuinely forgotten to inform the BA that the bank has a document
called suspension order and a document for revoking the suspension of an
account. Asking these questions on the basis of the state transition
diagram helps in ensuring completeness of understanding about the
process.

! !144
 THE DYNAMIC PERSPECTIVE

State Transition Method and Customer Experience Design

The state transition diagram however can be a powerful tool for a process
analyst/designer for designing a process for exemplary customer
experience. For example, in the above case of bank account, we can ask a
question as to how may we provide a great customer experience while
opening a new bank account. This question can lead to a brainstorming of
possible solutions which overcome various customer painpoints and
experience goals. Thus, for example, we could offer all entry of new
accounting forms online subject to submission of the requisite documents
at a branch along with a printout of the online form at the branch for KYC
(know your customer) purposes. We could also think of sending a bank
executive to the residence of the customer. The executive can fill up all the
forms and take the customer's signature. By visiting the customer's
premises, the executive is also assured of finding all the requisite
documents. Often times, it is seen that the customer has to make multiple
visits to the bank solely because he has not carried the requisite
documents at one time. Further, even the customer does not have a photo
copy of the document. The executive takes a photo on his camera or
mobile phone and print it at the bank. He can even click the customer's
photo in case he does not have one. Thus, the customer gets a single
window process and that too at his doorstep.

Thus, transitions are a good opportunity to ask a question as to how we

could enrich the customer's experience of that process.

States are also opportunities for providing unique customer experiences.

For example if we were to draw a state transition diagram of a shopper at a
shopping mall shopping for a pair of jeans, one of the states could be that
the customer is in the trial room trying out a pair of jeans. We could ask a
question as to how we could provide a unique customer experience. One of
the painpoints of a customer in a trial room is to find out how the dress/
jeans fits him/her from all sides. He/she therefore turns around in front of
the mirror or calls a friend or relative to check him/her out. One of the
solutions which a leading innovation company came up with was to allow
the customer to capture an image in the mirror which also doubled as a
screen. The customer could then turnaround see the image and then clear
the screen at the touch of a finger. Another approach for trials as a state is
becoming popular where the customer stands in front of a mirror like
screen in the store itself and at the click of a menu select various dress

! !145
 THE DYNAMIC PERSPECTIVE

options which are superimposed on the customer's image on the screen.

This helps the customer visualize how a wide variety of dresses look on
him/her without actually going through the trouble of changing in and out
of clothes in a trial room.

Thus, states when inspected can provide a great opportunity for process
innovation.

7.4 State Transition Diagrams

State-transition diagrams describe all of the states that an object can have,
the events under which an object changes state (transitions), the
conditions that must be fulfilled before the transition will occur (guards),
and the activities undertaken during the life of an object (actions).

State-transition diagrams are very useful for describing the behaviour of

individual objects over the full set of use cases that affect those objects.

State-transition diagrams are not useful for describing the collaboration

between objects that cause the transitions.

State transition diagrams have been used right from the beginning in
object-oriented modelling. State transition diagrams give an explicit, even
a formal definition of behaviour.

The basic idea is to define a machine that has a number of states (hence
the term finite state machine). The machine receives events from the
outside world, and each event can cause the machine to transition from
one state to another. Thus, you can get a good sense of what events
should occur, and what effect they can have on the object.

! !146
 THE DYNAMIC PERSPECTIVE

!
A big disadvantage is that you have to define all the possible states of a
system. While this is all right for small systems, it soon breaks down in
larger systems as there is an exponential growth in the number of states.
This state explosion problem leads to state transition diagrams becoming
far too complex for much practical use.

To combat the problem of the state explosion, object-oriented methods are

used to define separate state transition diagrams for each class. This
eliminates the explosion problem since each class is simple enough to have
a comprehensive state transition diagram. (However, it raises a problem
where it is difficult to visualize the behaviour of the whole system from a
number of diagrams of individual classes - which leads to people
interaction and activity modelling).

A particularly valuable feature of the approach is its ability to generalize

states, which allows you to factor out common transitions.

Processes that are instantaneous (i.e. cannot be interrupted) can be bound

to the transitions or to the entry or exit of a state; these are called actions.

! !147
 THE DYNAMIC PERSPECTIVE

Processes that are long (and can be interrupted) are bound to states;
these are called activities.

Transitions can also have a condition attached to them, which means that
the transition only occurs if the condition is true.

There is also a capability for concurrent state diagrams, allowing objects to

have more than one diagram to describe their behaviour.

When to Use Them

State models are ideal for describing the behaviour of a single object. They
are also formal, so tools can be built which can execute them.

Their biggest limitation is that they are not good at describing behaviour
that involved several objects. For these cases, use an interaction
diagram or an activity diagram.

People often do not find drawing state diagrams for several objects to be a
natural way of describing a process. In these cases you can try either
drawing a single state diagram for the process, or use an activity diagram.
This defines the basic behaviour, which then need to split across a number
of objects.

What Is State Transition in Testing?

State Transition testing is defined as the testing technique in which

changes input conditions causes state changes in the Application under
Test (AUT).

It is a black box testing technique in which the tester analyzes the

behaviour of an application under test for different input conditions in a
sequence. In this technique, tester provides both positive and negative
input test values and record the system behaviour.

It is the model on which the system and the tests are based. Any system
where you get a different output for the same input, depending on what
has happened before, is a finite state system.

! !148
 THE DYNAMIC PERSPECTIVE

State Transition Testing Technique is helpful where you need to test

different system transitions.

When to Use State Transition?

1. This can be used when a tester is testing the application for a finite set
of input values.

2. When the tester is trying to test sequence of events that occur in the
application under test. I.e., this will allow the tester to test the
application behaviour for a sequence of input values.

3. When the system under test has a dependency on the events/values in

the past.

When to Not Rely On State Transition?

1. When the testing is not done for sequential input combinations.

2. If the testing is to be done for different functionalities like exploratory

testing

Four Parts of State Transition Model

There are 4 main components of the State Transition Model as below:

1. States that the software might get

!
2. Transition from one state to another

3. Events that origin a transition like closing a file or withdrawing money

! !149
 THE DYNAMIC PERSPECTIVE

4. Actions that result from a transition (an error message or being given
the cash.)

State Transition Diagram and State Transition Table

There are two main ways to represent or design state transition, State
transition diagram and state transition table.

In state transition diagram the states are shown in boxed texts, and the
transition is represented by arrows. It is also called State Chart or Graph.
It is useful in identifying valid transitions.

In state transition table all the states are listed on the left side and the
events are described on the top. Each cell in the table represents the state
of the system after the event has occurred. It is also called State Table. It
is useful in identifying invalid transitions.

How to Make a State Transition (Examples of a State Transition)

Example 1:

Let's consider an ATM system function where if the user enters the invalid
password three times the account will be locked.

In this system, if the user enters a valid password in any of the first three
attempts the user will be logged in successfully. If the user enters the
invalid password in the first or second, try the user will be asked to re-
enter the password. And finally, if the user enters incorrect password 3rd
time, the account will be blocked.

! !150
 THE DYNAMIC PERSPECTIVE

State Transition Diagram

In the diagram whenever the user enters the correct PIN he is moved to
Access granted state, and if he enters the wrong password he is moved to
next try and if he does the same for the 3rd time the account blocked state
is reached.

State Transition Table

Correct PIN Incorrect PIN

S1) Start S5 S2
S2) 1st attempt S5 S3

S3) 2nd attempt S5 S4

S4) 3rd attempt S5 S6

S5) Access Granted - -

S6) Account blocked - -

! !151
 THE DYNAMIC PERSPECTIVE

In the table when the user enters the correct PIN, state is transitioned to
S5 which is Access granted. And if the user enters a wrong password he is
moved to next state. If he does the same 3rd time, he will reach the
account blocked state.

Example 2:

Check this video, before you refer the example below:

Please be patient. The Video will load in some time. If you still face issue
viewing video, click here.

In the flight reservation login screen, consider you have to enter correct
agent name and password to access the flight reservation application.

It gives you the access to the application with correct password and login
name, but what if you entered the wrong password.

The application allows three attempts, and if users enter the wrong
password at 4th attempt, the system closes the application automatically.

The State Graphs helps you determine valid transitions to be tested. In this
case, testing with the correct password and with an incorrect password is
compulsory. For the test scenarios, log-in on 2nd, 3rd and 4th attempt
anyone could be tested. You can use State Table to determine invalid
system transitions.

! !152
 THE DYNAMIC PERSPECTIVE

!
In a state Table, all the valid states are listed on the left side of the table,
and the events that cause them on the top.

Each cell represents the state system will move to when the corresponding
event occurs.

For example, while in S1 state you enter a correct password you are taken
to state S6 (Access Granted). Suppose if you have entered the wrong
password at first attempt you will be taken to state S3 or 2nd Try.

Likewise, you can determine all other states.

Two invalid states are highlighted using this method. Suppose you are in
state S6 that is you are already logged into the application, and you open
another instance of flight reservation and enter valid or invalid passwords
for the same agent. System response for such a scenario needs to be
tested.

! !153
 THE DYNAMIC PERSPECTIVE

Advantages and Disadvantages of State Transition Technique

Advantages Disadvantages

This testing technique will provide a The main disadvantage of this testing
pictorial or tabular representation of technique is that we can't rely in this
system behavior which will make the technique every time. For example, if the
tester to cover and understand the system is not a finite system (not in
system behavior effectively. sequential order), this technique cannot
be used.
By using this testing, technique Another disadvantage is that you have to
tester can verify that all the define all the possible states of a system.
conditions are covered, and the While this is all right for small systems, it
results are captured soon breaks down into larger systems as
there is an exponential progression in the
number of states.

The UML notation for state-transition diagrams is shown below:

! !154
 THE DYNAMIC PERSPECTIVE

Notation

For those not familiar with the notation used for state-transition diagrams,
some explanation is in order.

State: A condition during the life of an object in which it satisfies some

condition, performs some action, or waits for some event.

Event: An occurrence that may trigger a state transition. Event types

include an explicit signal from outside the system, an invocation from
inside the system, the passage of a designated period of time, or a
designated condition becoming true.

Guard: A boolean expression which, if true, enables an event to cause a

transition.

Transition: The change of state within an object.

Action: One or more actions taken by an object in response to a state

change.

Syntax Testing

Let's begin with the simplest kind of testing-syntax testing. Syntax Testing,
a black box testing technique, involves testing the System inputs and it is
usually automated because syntax testing produces a large number of
tests. Internal and external inputs have to conform the below formats:

• Format of the input data from users.

• File formats.
• Database schemas.

When performing syntax testing, we are verifying that the state-transition

diagram contains correct and proper information.

We ask three kinds of questions: Is it complete? Is it correct? Is it

consistent?

You do not need to know the answers to any of these questions before
asking them. It is the process of asking and answering that is most

! !155
 THE DYNAMIC PERSPECTIVE

important. Listen to the answers you are given. Are people confident about
their answers? Can they explain them rationally?

Now for the questions:

Correct:

1. Does each state-transition diagram have one and only one initial state?

2. If the state-transition diagram is an open-loop, is there at least one

terminal state?

3. If the state-transition diagram is a closed-loop, is it really? (Almost all

are actually open-loop)

4. Does each state have at least one exit transition?

5. If multiple guards exist for a single event, are the guards mutually
exclusive?

6. Does each state have exactly one transition for each possible event-
guard combination?

7. Have all redundant or duplicate states or transitions been removed?

8. Are all states reachable?

9. Is every "real" state in the world represented by one and only one state
on the diagram?

10.Is each state and transition clearly named?

11.Are all possible paths also valid paths?

12.Are all valid paths represented?

! !156
 THE DYNAMIC PERSPECTIVE

Syntax Testing - Limitations:

1. Sometimes, it is easy to forget the normal cases.

2. Syntax testing needs driver program to be built that automatically

sequences through a set of test cases usually stored as data.

Domain Expert Testing

Domain testing is a software testing technique in which selecting a small

number of test cases from a nearly infinite group of test cases. For testing
few applications, Domain specific knowledge plays a very crucial role.

Domain testing is a type of functional testing and tests the application by

feeding interesting inputs and evaluating its outputs.

After checking the syntax of the state-transition diagrams, we proceed to

the second type of testing-domain expert testing. Again, we have two
options: find a domain expert or attempt to become one. (The second
approach is always more difficult than the first, and the first can be very
hard.) Continuing, we ask three kinds of questions: Is it complete? Is it
correct? Is it consistent?

Complete:

1. Are all of the required states, events, guards, transitions, and actions
shown on the diagram?

2. Are all exceptional cases handled properly?

Correct:

1. Are we using state-transition diagrams only for classes that have

complex, interesting behaviour?

2. Does the diagram correctly represent the open-loop/closed-loop nature

of the class?

3. Are all of the required states, events, guards, transitions, and actions
properly defined?

! !157
 THE DYNAMIC PERSPECTIVE

Consistent:

1. Does a one-to-one correspondence exist between an object's events and

its methods?

Traceability Testing

The significance of traceability within a requirement tool or a test

management tool (like HP Quality Center) enables links between
requirements and tests. This notifies what needs to be changed when a
requirement changes.

Requirements management tools also enable requirement coverage metrics

to be calculated easily as traceability enables test cases to be mapped to
requirement.

Significance of Traceability:

1. To identify the apt version of test cases to be used.

2. To identify which test cases can be reused or need to be updated.

3. To assist the debugging process so that a defects found when executing

tests can be tracked back to the corresponding version of requirement

Finally, after having our domain expert search the state-transition

diagrams, we proceed to the third type of testing-traceability testing. We
want to make certain that we can trace from the requirements to the state-
transition diagrams and from the state-transition diagrams back to the
requirements. Again, we turn to one question: Is it consistent?

Consistent:

1. Do all states, events, guards, transitions, and actions in the

requirements appear in the state-transition diagram?

! !158
 THE DYNAMIC PERSPECTIVE

Conclusion

This set of questions, based on syntax, domain expert, and traceability

testing; and focused on completeness, correctness, and consistency; is
designed to get you started testing in an area with which you may not be
familiar.

7.5 SUMMARY

The flow perspective provides a static view of a process

• Processes and systems may work well on a normal day but fail during
abnormal situations.

• Hence, designing a foolproof process involves identifying as many

possible business situations and designing appropriate responses to
each.

• The Object events method is one approach to study and analyze the
dynamics associated with a business process or a system.

• State transition method is another way of analyzing the dynamic aspects

of a process. In practice, the state transition method could be used to
verify the analysis done earlier and could be limited to a few key objects.

• States and transitions provide an excellent opportunity to design great

customer experiences and for innovating in this area.

! !159
 THE DYNAMIC PERSPECTIVE

7.6 SELF ASSESSMENT QUESTIONS

1. Describe the importance of information and information system in the

organizations.

2. Which information concepts and systems must a Business Analyst know.

3. Briefly explain the role of Information Technology information systems.

7.7 Multiple Choice QUESTIONS

1. The __________ tend to show only the static aspect of a business

process – i.e., to say what happens on ‘under normal situation.
a. Process diagrams
b. State-transition diagrams
c. Data flow diagram
d. Activity diagram

2. To facilitate the identification of events, the BA can adopt which of the

following approach?
a. Identify objects in the process
b. Brainstorm on events for each object
c. Both A & B of the above
d. None of the above

3. The state transition method studies an event in real life in terms of its
states and its transition from one state to another.
a. True
b. False

4. The state transition diagram helps in inspecting the states and

transitions of a few key _____________, as a means of verifying.
a. events
b. documents
c. process
d. objects

! !160
 THE DYNAMIC PERSPECTIVE

5. The, transitions are a good opportunity to ask a question as to how we

could enrich the _______________experience of that process.
a. customer’s
b. analysts
c. designer
d. manager

Ans: 1 - (a), 2 - (c), 3 - (b), 4 - (d), 5 - (a)

! !161
 THE DYNAMIC PERSPECTIVE

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture

! !162
 BUSINESS RULES PERSPECTIVE

Chapter 8
Business Rules Perspective
Objectives

After reading this chapter, you will be able to:

• Nature of business rules in a process

• Identifying inherent business rules in a process

– Study of existing policy, procedures, practices and norms
– Study of object relationships
• Analyzing, modelling and redesigning business rules
– Decision table
– Business Rules Diagram
Structure

8.1 A Primer on Business Rules

8.2 What are Business Rules?
8.3 Identifying Underlying Business Rules
8.4 Analyzing, Designing and Structuring Business Rules
8.5 Object Relationships
8.6 Five Basic Tests of Business Rule
8.7 Business Rules and the Importance of the Business Analysis Discipline
8.8 Steps to Define Requirements for Business Rules and Decisions
8.9 Decision Table
8.10 Five basic Tests of Business Rule
8.11 Business Rules and the Importance of the Business Analysis Discipline
8.12 Steps to Define Requirements for Business Rules and Decisions
8.13 Business Rules Diagram
8.14 Summary
8.15 Self Assessment Questions
8.16 Multiple Choice Questions

! !163
 BUSINESS RULES PERSPECTIVE

8.1 A PRIMER ON BUSINESS RULES

Business rules are a key aspect of a business process. Business rules can
either be structured and nearly automatic. On the other hand, business
rules may have an element of fuzziness, could be discretionary or
situational and may require experience and judgement. Hence, the first
type of business rules could be automated while the second may require
either heuristics and specially designed decision support systems. A third
kind of rule may be completely beyond the bounds of easy automation
perhaps because of the combinatorial explosion which formal algorithmic
methods could lead to or the sheer irrational and impractical solutions
which many mathematical models could provide. The BA must be careful
before committing to the automation of the last type of business rule. For
example, a leading insulator manufacturer wishes to optimize the output of
his furnace in which insulators of various sizes and shapes made for
various customers need to be placed for glazing. The ability of the
shopfloor scheduler to fully occupy the cubic volume offered by the furnace
while ensuring that the insulators do not touch each other and yet fit
comfortably in the furnace without damage or breakage is key to getting
the maximum output from each production cycle of the furnance. Trying to
develop a computerized loading pattern for the furnace may look like an
interesting automation assignment but is fraught with quite a few
challenges. The BA must be aware that he does not commit to such
assignments unless he has had past experience about his teams' capability
in handling such challenges.

The challenge of understanding business rules is twofold – (1) that of

identifying underlying business rules and (2) the design and structuring of
the business rule in manner which can be automated.

! !164
 BUSINESS RULES PERSPECTIVE

8.2 What are business rules?

An Overview of Business Rules

Companies which are not well-organized have employees making and

executing decisions on the fly. Clear rules and guidance is required within
the enterprise regarding Business actions which are permitted and which
are not. In such a scenario, all decisions made in the company would be
without the structure offered by consulting company policies/guidelines.
This would result in general disorder and chaos within the enterprise.
Business

Rules are the constraints and conditions that define how the enterprise
functions and should be analyzed with the help of Business needs.

According to the International Institute of Business Analysis (IIBA), a

Business rule is a precise, actionable and verifiable directive under the
control of an organization which supports a business policy. Business Rules
are derived from Business policies. Business policies however are non-
actionable directives which support Business goals.

! !165
 BUSINESS RULES PERSPECTIVE

Business Rules originate from three components namely, terms, facts and
rules. Terms stand for clear definition, facts feed terms, and rules feed
facts.

Business Rules are a combination of guidelines and inferences from those

guidelines which in turn direct how we conduct Business. A great analogy
to explain and understand Business Rules would be – a world of Business
needs, where Business Rules are important citizens. Business Rules are
frequently brought up in requirements documents and managing them in a
single document eliminates the need to modify separate portions of
requirements documents. This is especially true when Business Rules
should be changed. While Business Rules are not requirements, they can
imply requirements and narrow down the possible proposed solutions.

What Forms do Business Rules Take?

Business Rules are framed to help all stakeholders understand processes in

the Business or the Business itself. Decision tables are used to document
complex Business Rules. An expert system or a rules engine can be used to
implement Business Rules. While technology is used to implement Business
Rules, they are neither the result of supporting hardware or software.

! !166
 BUSINESS RULES PERSPECTIVE

Uses of Business Rules in Different Project Types

"
Business Rules can concern:

a. Access Control Issues: Example: only the Marketing Director can

approve sales forecasts

b. Policy: Example: Eliminate any product with < 10% contribution to the
Business after its initial 8 years

c. Calculation: Example: Minimum buffer stock is calculated as 20% of

monthly sales forecast

! !167
 BUSINESS RULES PERSPECTIVE

Characteristics of Good Business Rules

1. Business Rules should be atomic. They should be expressed in a

granular format and should be as declarative as possible. A Business
rule should always be framed as a precise statement defining a term,
fact, and a constraint.

2. Business Rules guide process flow or how the system works. A Business
rule should be isolated from the process implementing it. Market
experts recommend that BAs should isolate the process flow from
what’s known, meaning the process should be separated from the
various Business Rules. This guarantees that changes to a Business rule
can be made without changing the related process. Since rules are
neither process nor procedure, they should not be contained in
processes themselves.

! !168
 BUSINESS RULES PERSPECTIVE

3. Business Rules are only active or legitimate when stated clearly. They
should not be abstract concepts in a person’s mind but should be
explicitly stated using a simple and comprehensible format.

4. Business Rules should be actively managed. They are essential Business

assets and should be ready for repeated use when required.

5. Business Rules should be documented independently for the conditions

of their enforcement. The conditions can be who, when, where and how.

6. Business Rules should be numbered for convenient identification and

traceability.
7. Business Rules should be documented using attributes like source,
example, name/description, associated rules, revision history, version
number, and more where available.

8. Each Business rule should have a single focus and be cohesive.

Who is a Business Rules Analyst?

Business analysts are regularly needed to produce and analyze Business

Rules. However, there is a specialist BA profile devoted to Business Rules
management and analysis- this is the Business Rules Analyst.

A Business Rules Analyst is usually needed to:

a. Analyse, architect and implement Business Rules that power an

enterprise and its operations

b. Comprehend the method by which Business Rules are decided, imposed,

documented and managed

c. Match Business Rules with the processes they guide

d. Update Business Rules in-keeping with organizational changes

e. Check the rules that will be influenced by specific organizational

changes

f. Manage risks that may hamper implementation of Business Rules

! !169
 BUSINESS RULES PERSPECTIVE

Conclusion

Business Rules can be easily analyzed when they are documented and
managed independent of the processes enforcing them. Occasionally, when
not planned properly, Business Rules may contradict one another when
combined. Business Rules should be progressively maintained to see that
they stay relevant to the enterprise.

What are True Business Rules?

Don't underestimate how pervasively across your organization business

rule is misunderstood.

A true business rule is simply a criterion used in daily business operations

to shape behaviour or make decisions.

The things that IT implements under today’s software platforms are not
true business rules; rather, they are mostly encoded representations of
business rules.

By true business rule mean all the following.

1. True business rules are about running the business, not its systems.

Your company would need its true business rules even if it had no software.
True business rules apply no matter whether activities are automated or
not

2. True business rules are not meta-data or information.

Only through gross misinterpretation or misunderstanding do they fall

under that umbrella (and the related organizational function). Instead, true
business rules are a form of knowledge. They are about what you need to
know to make things work properly in daily business operations.
Knowledge is knowledge. Information is information. They are simply not
the same thing.

! !170
 BUSINESS RULES PERSPECTIVE

3. True business rules are about human communication - people-to-people

communication, people having business conversations.

True business rules enable business people to communicate operational

business knowledge, not just things IT can implement. Such
communication is especially important if (as is so often the case these
days) the people are displaced by time and space.

Achieving these Knowledge-related Goals Requires two things:

1. Business rules must be written. (If you are part of an agile project
that believes otherwise, you need to rethink.)

2. Business rules must be written in declarative form using

structured natural language.

Here is an example of how a true business rule is written.

E.g. An account may be considered overdrawn only if cash withdrawal is

greater than the current balance of the account.

When it comes to communicating knowledge, Murphy’s Law definitely

applies. If something can be misinterpreted it will be misinterpreted.
Capturing and expressing true business rules completely and accurately is
a rich skill.

The Two Fundamental Kinds of Business Rules, Where They Come

from and Why They Are What They Are:

The SBVR (Semantics of Business Vocabulary and Business Rules)

definition for rule is deeply embedded in formal logic, which deals with
propositions. In modal logic, propositions can claim different modes.

For business rules the two relevant modes are alethic and deontic.

1. Alethic rules are true 'by definition'. As such they cannot be violated.
They are about how concepts, knowledge, or information are defined or
structured.

! !171
 BUSINESS RULES PERSPECTIVE

2. Deontic rules are rules that can be violated. They are rules about
behaviour, not concepts, knowledge, or information. Deontic rules are
really about people, what they must and must not do, even if their
activity (and the rules) are automated.

Both kinds of rules are important, of course, but deontic rules are people
rules since, businesses are about the activity of people. This situation is
very different than in the semantic web, for example, where it's all about
only knowledge.

Under modal logic, every rule must therefore 'claim' one of two modes. (In
practice, the 'claim' arises naturally from the syntax of a rule statement or
as a meta-property.)

i. Alethic implications (rules) are established by 'claiming' necessity.

Things are necessarily true. A concept is what it is; says what it says.
That's just the way things are.

ii. Deontic implications (rules) are established by 'claiming' obligation.

Behaviour is 'obliged' to follow the rule. But, of course, people don't
always follow the rules so there can be violations. Major difference.

So, a rule 'claims' either necessity or obligation, which establishes what

kind of rule it is. Therefore, the SBVR definitions for the two kinds of rule
are:
(a) Definitional rule: rule that is a claim of necessity

(b) Behavioural rule: business rule that is a claim of obligation

Why doesn't the definitional rule say "business rule" like the one for
behavioural rule?

Because some definitional rules are not 'under business jurisdiction' (in
other words, business has no choice about them). Examples include the
'law' of gravity and all the rules of mathematics. Those rules are simply
universally true.

So as recommended, the following are pragmatic definitions for business

analysts.

! !172
 BUSINESS RULES PERSPECTIVE

a. Definitional rule: A rule that indicates something is necessarily true

(or untrue); a rule that is intended as a definitional criterion for
concepts, knowledge, or information.

b. Behavioural rule: A business rule that places an obligation (or

prohibition) on conduct, action, practice, or procedure; a business
rule whose purpose is to shape (govern) day-to-day business activity.

Synonyms: Early in the development of SBVR, as introduced the terms

structural rule and operative rule for the two kinds of rules, respectively.
That was before the full implications of modal logic became clear. Since,
then the terms definitional rule and behavioural rule have become
preferred, even in all internal SBVR discussion. The synonyms, however,
remain valid.

8.3 IDENTIFYING UNDERLYING BUSINESS RULES

Many a time, business rules are obvious in the nature of computation

required in a process. For example, calculating the invoice or tax etc. would
need a structured business rule. However, in many cases, the business
rules are not so obvious. These could be in the form of policies,
procedures, practices and norms which can at best be observed and
understood.

The BA will do well to study existing documents such as Standard

Operating Procedures, Procedures and policies documented for various
processes and regulatory standards such as ISO 9000, ISO 2700, SOX.
These standards mandate certain controls and business rules.

Likewise, business rules can be identified by observation and enquiry. The

BA can speak to practitioners and understand the workflows and process
flows and ask why certain things are done the way they are.

Informal norms, however, are more difficult to identify. For example, after
developing a software for the purchase department of a company, the
users who were essentially buyers in the purchase department felt that the
software was difficult to use since it showed a long list of thousands of
items purchased by the company in the drop-down box making it difficult
for them to complete the transaction quickly. The BA replied that since the
company dealt with 30000 items the list was bound to be long. He then

! !173
 BUSINESS RULES PERSPECTIVE

discovered that the buyers had a not so formal work division among
themselves wherein a group of items were handled by a buyer. Hence,
when he raised a purchase order, he would ideally like to see the list of
items which he dealt with and not the entire 30000 items. This came a
surprise since this seemed to be an unwritten business rule. It was more of
a working arrangement or norm. Discovering such norms can be difficult
but important to ensure a better user experience as can be seen from the
above case.

8.4 ANALYZING, DESIGNING AND STRUCTURING

BUSINESS RULES

There are various ways for analyzing and structuring business rules. Some
of these include:

(a) Object/Class relationships

(b) A decision table – especially suited for structured business rules
(c) Business rules diagram

8.5 OBJECT RELATIONSHIPS

One important set of business rules in a business system pertains to the

underlying relationships between objects. For example:

In the above object/class diagram, an employee is shown to be related to

another employee in atleast two ways. One of the above loops could
indicate that an employee could be a boss of another employee. The other
loop could indicate that an employee reports to another employee. Having
understood the range of possible relationships between a pair of objects, it
is important to study their cardinality, i.e., how many of one relate to how
many of the other. Thus, for example, theoretically speaking an employee

! !174
 BUSINESS RULES PERSPECTIVE

can have only one boss, i.e., he reports to only one other employee. On
the other hand, an employee can have many people reporting into him. As
per the theory of span of control, we may decide that an employee cannot
have more than 8 subordinates. Thus, in this fictitious organization, we
have identified the two basic business rules pertaining to the boss
subordinate relationship. In some other organization, they may have more
number of relationships between employees – for example, an employee
may be a performance coach for another employee, or an employee may
have a direct boss as well as a dotted line boss (indirect or administrative
versus functional boss). Equally another organization may not believe in
the concept of span of control and could allow a boss to have more than 8
subordinates.

Thus, object relationships and cardinality describe how objects in business

interact with each other in the given organization and therefore constitute
business rules unique to that context.

The BA should therefore draw a class/object diagram and identify these

data relationships as a major source of business rules.

8.6 Five Basic Tests of Business Rule

One way that business rules contribute to a clearer picture of any given
business process is through a kind of binary concept. Typically, business
theory experts see a business rule as either true or false. Here, business
rules can be used in business planning in many of the same ways that they
are used for algorithm development in programming.

One example is the use of business rules on a flow chart that clearly shows
how a defined true or false case will absolutely affect the next step in a
business process.

Business rules can also be generated by internal or external necessity.

For example, a business can come up with business rules that are self-
imposed in order to meet leadership’s own goals, or in the pursuit of
compliance with external standards.

! !175
 BUSINESS RULES PERSPECTIVE

!
Experts also point out that while there is a system of strategic processes
governing business rules, the business rules themselves are not strategic,
but simply directive in nature.

For business analysts, understanding decision logic from the perspective of

business people is key. For that you need business rules. But when can a
rule be considered a business rule, and when not? Below present five
pragmatic tests for knowing when you have identified a true business rule.

Consider the rule: A log-in must be cancelled if the user enters the
wrong password more than 5 times. Business rule?

The tests for distinguishing business rules from system or IT rules are
straightforward. There are five basic tests. A rule must pass all five tests
before it can be considered a true business rule.

The First three Tests are as Follows

Test 1. The rule must be practicable.

This test entails the question, 'Would a worker who is duly authorized and
capable, know what to do or not to do when she reads it?' Consider the
statement: No shirt, no service. Probably passes the practicable test.

Now consider this statement: Come as you are. Probably not practicable. A
worker can't read it and know exactly what to do or not to do. The
statement must be interpreted into some form that truly is practicable
(e.g., No swimming suits.). More about practicable later.

! !176
 BUSINESS RULES PERSPECTIVE

Test 2. The rule must be about the business, not about either a
system that supports the business, or a platform used to
implement such a system.

A rule of thumb is this: If you threw away the system — any system, even
pencil and paper — would the rule still be important in running the
business? Business people should be managing business things, not system
things.

Test 3. The rule must be expressed in the language of the business,

not in the language of either a system or a platform.

A business person must be able to understand a statement or

representation of a business rule without significant training or experience
in IT or IT-built systems. Business people should be communicating in
business terms, not system terms.

Now back to the original rule: A log-in must be cancelled if the user enters
the wrong password more than 5 times.This rule satisfies tests 1 and 3,
but not 2. Not a business rule.

How about this example: No cash, no order. This rule does satisfy all three
tests. So, yes, business rule.

Does this clear distinction between business rules and system or platform
rules ever break down? One commonly-cited example where the line might
blur is with security rules. However, such rules often pertain directly to a
system or the data in it.

Consider this example: A person logged on to the system as a junior

adjudicator may request customer data from the customer database only
from the local server.

This rule satisfies test 1 above — it's practicable — but not 2 and maybe
not 3. So, not a business rule. Does that mean the rule is any less
important to the business? No. It's a rule all right, simply not a business
rule.

! !177
 BUSINESS RULES PERSPECTIVE

Consider another example: A junior adjudicator may be informed only

about customers in his local district. Throw out the systems, you still need
the rule. So, yes, business rule.

Two Additional Tests for when a Rule can be Considered a Business Rule
are as Follows.

Test 4. The rule must be under business jurisdiction.

"Under business jurisdiction" is taken to mean that the business can enact,
revise, and discontinue the business rule as it sees fit. If a rule is not under
business jurisdiction in that sense, then it is not a business rule. For
example, the law of gravity is obviously not a business rule. Neither are
accepted rules of mathematics.

Test 5. The rule must tend to remove a degree of freedom.

If some guidance is given but does not tend to remove some degree of
freedom, it still might be useful, but it is not a rule per se. Such guidance
is called an advice.

Consider the statement: A bank account may be held by a person of any

age. Although the statement certainly gives business guidance, it does not
directly:

a. Place any obligation or prohibition on business conduct.

b. Establish any necessity or impossibility for knowledge about business

operations.

Because the statement removes no degree of freedom, it does not express

a business rule. Rather, it expresses something that is a non-rule — a.k.a.
an advice.

Is it important then to write the advice down (i.e., capture and manage it)?
Maybe. Suppose the statement reflects the final resolution of a long-
standing debate in the company about how old a person must be to hold a
bank account. Some say 21, others 18, some 12, and some say there
should be no age restriction at all. Finally, the issue is resolved in favour of
no age restriction. It's definitely worth writing that down!

! !178
 BUSINESS RULES PERSPECTIVE

Now consider this statement: An order Rs. 1,000 or less may be accepted
on credit without a credit check. This statement of advice is different. It
suggests a business rule that possibly hasn't been captured yet: An order
over Rs. 1,000 must not be accepted on credit without a credit check. Let's
assume the business needs this rule and considers it valid.

In that case, you should write the business rule down — not the advice —
because only the business rule actually removes any degree of freedom.
Just because the advice says an order `1,000 or less may be accepted on
credit without a credit check, that does not necessarily mean an order over
`1,000 must not. A statement of advice only says just what it says.

Categorization of Business Rules

Figure 1 presents an overall categorization of guidance from the

perspective of business people. All rules are either behavioural (also called
operative) or definitional (also called structural).

Figure 1. Categorization of business guidance

! !179
 BUSINESS RULES PERSPECTIVE

More About Business Rules Being Practicable

In contrast to a business policy, a business rule needs to be practicable.

This means that a person who knows about a business rule could observe a
relevant situation, including his or her own behaviour, and decide directly
whether or not the business was complying with the business rule. In
general, a business policy is not practicable in that sense; a business policy
must be interpreted into some more concrete business rule(s) that satisfy
its supposed intent. (That's what the fact type in Figure 1 worded
practicable element of guidance is derived from business policy is about.)
For example, the following business policy is not practicable: Safety is our
first concern.

Just because business rules are practicable does not imply they are always
automatable — many are not. For instance, consider the business rule: A
hard hat must be worn in a construction site. Non-automatable rules need
to be implemented within user activity. In many ways, managing non-
automatable rules is even more difficult than managing automatable ones.
They definitely have a place in your rulebook.

For a business rule (or an advice) to be practicable assumes that the

business vocabulary on which it is based has been adequately developed
and has been made available as appropriate. Note the fact type in Figure 1,
worded practicable element of guidance is based on fact type. Every
business rule (and advice) should be directly based on a structured
business vocabulary.

Ultimately, all business rules come down to good business vocabulary!

! !180
 BUSINESS RULES PERSPECTIVE

8.7 Business rules and the importance of the business

analysis discipline

Business Rules and the Importance of the Business Analysis Discipline

For most organizations introducing a new product or application system or

responding to a policy or regulatory change can be a daunting process.

Add to this the fact that rule changes or additions are often externally
imposed (by government or regulators), and organizations face significant
risks associated with complying with such new or changed rules in an
efficient, effective, and timely manner. Similarly, most system
replacements or “legacy system modernization” efforts fail, usually after
the expenditure of hundreds of thousands or millions of dollars.

If an organization understands, captures, and documents its business

rules, the understanding of the impact of any change is much simpler;
impact analysis is clear; and, the road to implementation of a change can
be planned and managed successfully.

According to the International Institute of Business Analysis, “a business

rule is a specific, practicable, testable directive that is under the control of
the business and that serves as a criterion for guiding behavior, shaping
judgments, or making decisions.”

! !181
 BUSINESS RULES PERSPECTIVE

How Do We Identify Business Rules and Where do We Find Them?

Business rules guide behavior, shape judgements, and drive decision-

making. Thus, we can extract business rules from company policy
statements, procedure documents, product descriptions, filings, and
operational documentation.

Certain business rules may be maintained only through “tribal knowledge”

and thus exist only in the heads of employees. There will be knowledge
loss associated with staff attrition if an organization has not taken the time
to explicitly document business rules.

Many business rules are hidden in application code. This may be due to the
complexity of many insurance application systems and to the fact that
those systems may be undocumented or poorly documented (or the
validity of any documentation may be in question). Staff members may not
even be explicitly aware that these business rules exist.

Because of the siloed nature of many organizations, conflicting business

rules may exist in different areas of the company, again increasing risk to
the insurer of undesirable outcomes.

The products of business analysis and the use of a business rules approach
can provide clear direction for the discovery of business rules and the
ability to trace business rules to the processes, events, roles, and data that
they impact. Business process models have “decision” points (indicated by
a diamond). For all but the most rudimentary of decisions, these indicate
the application of a business rule. The creation of a use case description
generates questions that are answered by the discovery of business rules.
The analysis of data entities and their attributes trigger the discovery of
business rules through the exploration of “how does A relate to B?”
Assessment of a business role (possibly through the creation of “personas”
– Sally is a twenty-something, tech-savvy individual who hates to have to
“look things up”) can also trigger discovery of business rules.

! !182
 BUSINESS RULES PERSPECTIVE

8.8 Steps to Define Requirements for business rules and

decisions

Imagine you are asked to define business requirements and constraints for
a set of business rules as part of the design of a solution. What approach
would you use?

The definition of the business rules of the solution were part of the design
phase. Because most traditional requirements engineering approaches
focus on defining requirements for IT systems, it was found that using
these kinds of approaches for defining business rules requirements is not
suitable.

Below given are the practical 3 step approach that can be used to define
business requirements for business rules and decisions.

It focuses on 3 aspects that you need to define as a requirement for a

business rule: How, where and what.

Step 1 How: How should the Business Rule Work?

This first step is to gather the relevant knowledge sources that can help
specify how the decision is made and how the business rule should work.
For example: policies, regulation, sources of expertise and best practices
on which the business rule is based. As part of the requirements, it is not
necessary yet to describe the behaviour of the business rule in complete
detail. Only refer to the relevant knowledge sources and add a high-level
description if you like. Important constraints from law and regulations
should be made clear here as well.

Step 2 Where: Where does the Business Rule Apply?

The second step is to define where the business rule applies. This question
should be answered from a business perspective. Therefore, the best way
to determine this requirement is to indicate as part of which business
process (step) the business rule needs to be described. Business processes
define the order of activities that are executed to produce a result to the
customer. A business rule can often be assigned to a single activity or set
of activities. Reference material like existing business process models from
the organization, high level business function models, or business process

! !183
 BUSINESS RULES PERSPECTIVE

reference models from the industry can all serve as a starting point. The
level of detail used to answer the 'Where' question depends on the
availability of this material. If possible, use the organization's existing
business process models. If nothing is available you can still describe in
words using business terminology where the business rule applies.
However, this is far less accurate.

Step 3 What: What Information is Necessary to Execute the

Business Rule?

The final step is about data. A business rule is based on a combined set of
information or data elements. For example, the business rule for whether
an insurance claim is accepted, depends on the amount claimed and the
payment behaviour of the customer. Part of the set of requirements of a
business rule, is to define the essential data elements that are necessary
as input to the business rule. Without these data elements available, it is
not possible to execute the business rule. Existing data dictionaries or data
models can be used as starting point.

In addition, it can help to describe where the data should come from e.g.
which system, which department, which external party, etc.

! !184
 BUSINESS RULES PERSPECTIVE

Next steps

If you describe these three aspects together, this forms a complete set of
requirements for the business rule. A business rule designer can use this
information as input to make a detailed design of the business rule.

Furthermore, the set of requirements can serve as input for the execution
of rules in a business rules engine. In that case a next step is needed to
define technical requirements that arise from constraints of the chosen
implementation platform.

8.9 DECISION TABLE

This is a simple tabulation of various conditions and actions forming part of

a broad business rule. The table below shows an example of use of a
decision table for analyzing a decision to give discount to a customer.

Rules

1 2 3 4

Actions Conditions Customer is new Y Y

Existing Customer Y Y

Bill Amt < Rs. 1000 Y Y

Bill Amt >= Rs. 1000 Y Y

Zero Discount Y

5% Discount Y Y

10% Discount Y

Voucher (Rs. 100) for next Y Y Y

purchase

As can be seen, there are two parts to the table, viz., Conditions and
Actions. Each column represents a distinct rule within the rule set of giving
discounts to customers. Each rule consists of a set of conditions which are
marked as ‘Y’ and the corresponding actions which should be taken. The
rule is to be read from top to bottom in a given column.

! !185
 BUSINESS RULES PERSPECTIVE

Thus, for example, for the condition that the ‘Customer is new’ and has
purchased less than Rs. 1000/- the salesperson should give zero discount
but to tempt the customer to come again he should give a discount
voucher on the next purchase.

Two points to note are:

• The multiple conditions as well as multiple actions can be check marked.

• If the conditions form part of pair of conditions such as customer – old or

new etc., it is easy to guess the number of rules which can emerge from
the decision table. Thus, in the case above, there are two pairs of
conditions – one pair pertaining to old or new customer and the other
pair related to the amount of purchase (above or below Rs. 1000/- ).
Thus, two conditions each with two options gives 2 ^ 2, i.e., four possible
rules. Being able to anticipate the number of rules ensures that the BA
has studied, all the possible rules and has not missed out any aspect.

• The decision table only has ‘Y’ and blanks – this like 0 or 1, i.e., binary. If
a database table of this nature is created, the billing software can pick up
the correct rule based on the conditions inherent in the data being
entered and apply the rule. This is indeed the principle of building
business rule tables and business rule engines. The advantage of this
approach is that the rule is not coded in the software as was
conventionally done and if the rule changes only table values need to be
changed rather than having to change the programs. Thus, for example,
in the above case if it is decided to give a 5% discount in rule 1, 10%
discount in the rest of the rules, the values in the rule table need to be
changed and nothing else. This helps the software to be moregeneric and
the parameterization lies in the table.If two retail outlets are allowed to
give different discounts, they need to only change the values without
touching the programs which can remain common to both the stores.

! !186
 BUSINESS RULES PERSPECTIVE

8.10 BUSINESS RULES DIAGRAM

The business rules diagram uses Boolean Gates to represent a business

rule. It begins with the desired end state assuming the decision is taken
and allows the BAtovisualize the various Boolean conditions which need to
be met to arrive at this final decision state.

The figure below shows how this can be done.

!
The above figure shows an AND gate. This implies that if and only if all the
conditions listed below the AND gate are ‘True’ (or .T.) then the output, i.e.,
‘bill is approved for payment’ becomes true. If any of the conditions fails,
the bill is not approved.

Having identified the basic conditions for the above business rule,the BA
can further analyze it by asking the question – what does it mean by ‘Qty
ok’ or ‘Quality Ok’? Here he may have expand the above diagram to include
the conditions which lead to the state of Qty ok and quality ok. Perhaps
from real life, one can say the qty ok means that the delivered quantity on
the challan and the qty mentioned on the bill match. Further, it may also
require that the quantity on the bill <= (Qty mentioned in Puchase Order)
— (quantity already billed previously)

Thus, each condition can be analysed further.

! !187
 BUSINESS RULES PERSPECTIVE

Remodelling the Business Rule using the Business Rules Diagram

It would be obvious from the previous example that to make the business
rule more rigourous, more conditions must be added to the AND gate. For
example if we wish add the condition that the Delivery time is equal to the
delivery time indicated in the Purchase Order. This additional condition
makes the business rule tougher thereby making the overall purchase and
store processes more stricter.

!
On the contrary if we wish to simplify the business rules, we have three
options:

• Remove a few conditions in the above AND gate — for example in small
companies where there are no formal purchase orders, the condition
pertaining to the purchase order is less thereby providing flexibility to do
cash purchase.

• Provide alternate paths by using an OR gate at appropriate places — for

example in the above if we wish to formally allow emergency
procurement actions, we can model the rule as shown above – the OR
gate thus helps in providing an alternate path and can be used to dilute a
rule in certain situations

Thus, the Business Rules Diagram is a handy and intuitive tool to

understand, analyze and reengineer business rules.

! !188
 BUSINESS RULES PERSPECTIVE

8.11 SUMMARY

• All business processes work on a set of business rules.

• Some of the business rules are well structured and can therefore easy to
automate.

• Some business rules involve human judgement and heuristics which

make them difficult to automate. Business Analysts should be careful on
committing to automate such business rules.

• Business rules can be found in existing documentation in a company. This

could be in the ISO 9000 or such process related documents or domain
specific or regulatary standards or company standard operating
procedures.

• Several other types of business rules can be more difficult to find and can
be identified through observation and interaction with people in that
domain. Such business rules may include norms, practices etc.

• Inspecting object relationships is an easy way of detecting one type of a

business rule which depends on inherent data relationships in business.

• Decision table is a good way to model and document and structured

business rule.

• Business Rules diagram is a good way to model a business rule. It can

also stimulate thoughts on simplifying or toughening a business rule.

! !189
 BUSINESS RULES PERSPECTIVE

8.12 SELF ASSESSMENT QUESTIONS

1. What is a business rule and describe its nature?

2. How to identify the underlying business rules in a process?

3. Which are the various ways of analysing, designing and structuring

business rules? Explain each in brief.

4. Write a note on remodelling the business rule using the Business Rules
Diagram.

8.13 Multiple Choice QUESTIONS

1. Which of the following is the challenge of understanding business rules?

a. Identifying underlying business rules
b. Design and structuring of the business rule in manner which can be
automated.
c. Both A & B of the above
d. None of the above

2. Which of the following is a way for analyzing and structuring business

rules?
a. Object/Class relationships
b. A decision table – especially suited for structured business rules
c. Business rules diagram
d. All of the above

3. Object relationships and cardinality describe how objects in business

interact with each other in the given organization and therefore
constitute business rules unique to that context.
a. True
b. False

! !190
 BUSINESS RULES PERSPECTIVE

4. __________ is a simple tabulation of various conditions and actions

forming part of a broad business rule.
a. Business rule
b. Basic tests
c. Decision table
d. Object relationships

5. Business rules __________ begins with the desired end state assuming
the decision is taken and allows the BA to visualize the various Boolean
conditions which need to be met to arrive at this final decision state.
a. Policies
b. Diagram
c. Steps
d. Tests

Ans: 1 - (c), 2 - (d), 3 - (a), 4 - (c), 5 (b)

! !191
 BUSINESS RULES PERSPECTIVE

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture


! !192
 THE HUMAN FACTORS PERSPECTIVE

Chapter 9
The Human Factors Perspective
Objectives

After reading this chapter, you will be able to:

• To appreciate the need for the study of Human factors in the context of
Business Analysis

• To appreciate some of the Design related subjects/topics which a BA

should be sensitized to

• To get an overview to the subject of Human Computer Interaction (HCI)

and Usability

• To learn how to gather Requirements from a HCI/Usability standpoint

Structure

9.1 Need for the Study of Human Factors

9.2 What BAs Must Know about Design?
9.3 What BAs Must Know about Human Characteristics?
9.4 Human Computer Interaction (HCI) and Usability
9.5 HCI Challenges
9.6 Importance of HCI
9.7 Recent Advances in HCI
9.8 Functional Goals Versus User Experience Goals
9.9 Mental Models
9.10 Use Cases and HCI/Usability
9.11 Requirement Gathering from the Standpoint of the HCI and Usability
Perspective
9.12 Summary
9.13 Self Assessment Questions
9.14 Multiple Choice Questions

! !193
 THE HUMAN FACTORS PERSPECTIVE

9.1 NEED FOR THE STUDY OF HUMAN FACTORS

Gone are the days when Information technology was used only by a select
few in the central IT department. Increasingly lay users, people on the
streets, in rural areas and just about any one may interact with IT. It is
therefore important to understand the profile and characteristics of users of
people who are likely to use a solution.

It is this human centered approach which has made devices such as mobile
phones, smart phones, tablets so intuitive and accepted by society at
large.

The Human Factors perspective has two parts – one an understanding

about human characteristics, and an understanding about design aspects in
general and the application of these aspects to IT based products. Usability
is one view about Human Factors which aims to making products more
useable and useful to the intended users.

9.2 WHAT BAS MUST KNOW ABOUT DESIGN?

A Business Analyst must therefore be sensitized to various topics which

Industrial or Product designer's study. Some of these topics subjects
include:

• Human Computer Interaction/Interaction Design

• Basic design principles such as form, colour, aesthetics

• Typography – which deals with the design of fonts, typefaces etc.

• Visual Design – which deals with design of everything which is visual in

nature – be it design of screens, design of signages, design of brochures
etc.

• Semantics – the study of meaning associated with any design — the

fundamental belief that design can be used as a means of giving new
meaning to a product

• Semiotics – is the study of symbols in a given cultural context – for e.g.,

a Cross may have a meaning to people following a certain religion while

! !194
 THE HUMAN FACTORS PERSPECTIVE

the Om symbol may have a meaning to a certain other person from

another religion.

While it may be difficult to imbibe all these topics in a manner which an

industrial designer who goes through a hands on 4 year degree program
does, a BA must certainly attempt to understand the underlying principles
and over a period develop what one could call Business Aesthetics.

9.3 WHAT BAS MUST KNOW ABOUT HUMAN

CHARACTERISTICS?

An BA must understand human characteristics both – the physical aspects

as well as the cognitive and psychological/behavioural aspects. Generally
for an IT solution, it is necessary to note the types of users who are likely
to use the proposed solution. These users are classified into distinct
personas – personas are described in terms of precise attributes related to
demographic characteristics, psychographic characteristics and other
physical characteristics. Thus, for example, one of the user persona for a
faculty attendance system in an old and established Business school could
include a faculty above 60 years of age, forgetful, may have challenges in
reading small fonts, may not have trouble remembering passwords, may
have unreliable fingerprints etc.

Some of the human characteristics may also be depending on cultural

elements within the organization or the larger ethnic or social backgrounds.
Human characteristics also include education, level of comfort with
technology etc.

Special limitations of certain groups of people should also be noted. For

example, people with disabilities such as the blind, color blind, those
without arms or any other physical disability which may affect the access
or usage of a given IT based device. With an increasing aging population in
many developed countries, it is becoming important to design any device
and certainly IT devices in a manner which can be used by the aged. This
requires a thorough understanding of the type of problems faced by the
aged and in particular the target group for which the device is being
designed.

! !195
 THE HUMAN FACTORS PERSPECTIVE

9.4 HUMAN COMPUTER INTERACTION (HCI) AND

USABILITY

The subject of HCI is about using the understanding of human factors and
design principles to design man-machine interaction which make machines
more usable and effective tool in the hands of human users.

The goals of HCI and usability are to make machines more usable. More
specifically usability can be described in terms of:

• Ease of learning

• Ease of memorizing the steps to use a device

• Affordance (not to be confused with affordability) – which provides the

desired features

• Visibility – which makes interactions more visible providing prompts,

messages and alerts where appropriate

• Safety – which ensures that it does no harm to the user as well as

minimizes the chance of a user making errors – safety in todays context
could also imply health. For example, many disease's related to
prolonged stain to neck, spinal column, lower back, fingers, eyes etc. In
the context of mobile phones, the hazards related to radiation etc. are
important.

• Security – which may relate to access, confidentiality and privacy issues

• Consistency – which ensures ease of use resulting from consistent

layouts, navigations etc.

! !196
 THE HUMAN FACTORS PERSPECTIVE

9.5 HCI CHALLENGES

The development of the silicon chip has changed the way humans work,
play, and communicate. Although it may sound like a cliché, computers are
literally everywhere, and they are advancing at an astonishing rate. The
invention of new hardware, software, and interaction styles are opening up
new possibilities for computing every day. One of the biggest challenges
faced by HCI is keeping one step ahead of new technologies and new
methods of interaction. HCI research must match the evolution of
technology if the usability and efficiency of future devices and software is
to be ensured. The fundamental challenge is guaranteeing new designs
offer good HCI as well as harnessing the potential functionality of the new
technology.

Very few other disciplines receive contributions from so many different

fields of study as does HCI, and this poses unique challenges for those
working in the area. As it would be impossible for one person to be an
expert in every area that contributes to HCI as a whole, it is critical that
experts from various fields work closely together sharing their expertise.
Although this co-operation is often achieved successfully and with great
results, communication problems can arise due to the very different areas
of expertise of the individuals involved.

The remarkable impact of human-computer interaction research and user

experience design compels researchers, practitioners, and journalists to
ask: What is the next big thing?

Therefore, it may be useful for our community to lay out grand challenges
that steer the direction of future research, design, and commercial
development.

As HCI researchers profoundly aware of the immense problems of age:

Growing human populations consume natural resources, flourishing cities
require housing and transportation, families demand education and safety,
and rising expectations from patients put pressure on healthcare and social
systems.

! !197
 THE HUMAN FACTORS PERSPECTIVE

National priorities include economic development, political participation,

civil rights, and achieving the delicate balance between appropriate
security and excessive surveillance while pursuing open government
policies that limit corruption and prevent waste.

While addressing these problems, researchers, designers, and developers

who recognize the aspirations of individuals, their desire for self-
determination, and their hopes to contribute to their communities are more
likely to deliver constructive products and services. These forward-looking
innovators will manifest their sensitivity to individual and community
norms, respect individual differences, and observe ethical codes of
conduct.

The Human-Computer Interaction (HCI) affects many research areas but in

designing computer systems, is a matter of paramount importance.
Although that in the case of special fields such as Psychology or Medicine,
HCI can be seen as a specialized branch of design process despite the vital
information that can provide design, in computer systems should be an
integral part of this process

With these considerations in mind, strategies for effective human-computer

interaction described below are grand challenges for researchers,
designers, and developers:

1. Develop a handbook of human needs. Abraham Maslow’s hierarchy

of needs from the 1940s provides some guidance, establishing a
foundation of survival and safety, embracing love and esteem, and
supporting self-actualization that realizes personal potentials. However,
a contemporary and detailed handbook of human needs would help in
the refining of designs and invention of new tools or services.

2. Shift from user experience to community experience. User

experience designers have cleverly invented interfaces and processes
that support work, communication, and fun. Now there is an opportunity
to shift to community experience design, social media participation,
game theoretic mechanisms, and motivational strategies to engage
growing communities in constructive ways. Successful examples, such
as Wikipedia or citizen science projects, show what is possible, but the
common outcome of community experience design is insufficient
response, raising the question of how to make more consistently

! !198
 THE HUMAN FACTORS PERSPECTIVE

successful outcomes. This shift is mirrored in the theory shift from

emphasis on micro-HCI to macro-HCI.

3. Refine theories of persuasion. Theories of persuasion could lead to

more rapid progress in smoking cessation, obesity reduction, medication
compliance, and cancer prevention. A periodic table of persuasion
strategies would chart the micro-structure of motivation for designers
who create applications for individuals, friends and family, colleagues &
neighbours, and citizens and markets.

4. Encourage resource conservation. The needs of a growing

population will have to be trimmed by efficient strategies for reducing
the use of water, energy, and natural resources while increasing
production from renewable sources. User interfaces and community
engagement will play key roles in providing feedback that encourages
winning strategies.

5. Shape the learning health system. A grand opportunity for HCI

researchers and designers is to help shape massive healthcare systems
that support patients seeking wellness, clinicians delivering care, and
providers eager to reduce costs while increasing the quality of care.
Macro-HCI thinking and big data analytic tools could provide insights at
every level that could be shared with relevant stakeholders but
producing meaningful changes in such massive systems remains a
challenge. Bottom-up strategies could propel patient and clinician
participation, while top-down governance is needed to set policies, cope
with malicious actors, and guide continuous improvement.

6. Advance the design of medical devices. Researchers have been

rapidly developing medical devices that go far beyond current hearing
aids, pacemakers, body sensors, and data-recording tools. As implanted
insulin pumps, vision-restoration systems, prosthetic limbs, brain-
computer interfaces, and Nano devices mature, user interfaces to
monitor performance, log activity, and enable appropriate controls will
be required.

7. Support successful aging strategies. The growing population of

older adults want to maintain their health and independence while aging
in place. They could benefit from interfaces that collect data from
sensors, encourage healthy diet and exercise, promote social

! !199
 THE HUMAN FACTORS PERSPECTIVE

connectedness, and enable balanced involvement from caregivers. How

the growing Internet of Things help older adults improve quality of life?

8. Promote lifelong learning. Traditional educational systems are

expanding to include online learning (massive open online courses, or
MOOCs), professional just-in-time training, learning through games, and
many kinds of social learning. Developing best practices for a range of
ages, motivations, and cultures will help to make these systems more
reliably successful for large numbers of diverse users.

9. Stimulate rapid interface learning. Multilayer user interfaces enable

new users to become experts with basic features; then users can control
their progress to advanced features as needed. Multilayer user
interfaces also simplify design for diverse users and users with
disabilities.

10.Engineer new business models. As existing business models give

way to new ones, user interfaces play a key role in ensuring the success
of peer-to-peer sales of products and services such as taxi rides,
vacation-home rentals, and task completion. Closer business-to-
consumer connections and lower barriers to consumer-to-consumer
collaboration also promise new possibilities if the user experience can be
designed to promote trust, conflict resolution, and open feedback from
consumer reviews.

11.Design novel input and output devices. As user input continues to

shift from keyboards to gestures, speech, and body movement, users
will need reliable mechanisms to express their intentions. Expansion of
tactile and tangible environments provides fresh possibilities. Still and
video cameras, 3D scanners, and sensors will accelerate the capacity to
record, analyze, and share rich data streams. Similarly, as output
display diversity expands, tiny haptic feedback devices, ambient sound
generators, projected displays, and large public displays will challenge
designers to provide information rates and content appropriately
adjusted to current tasks. Transparent glasses, immersive goggles, and
ambient devices offer new possibilities along the spectrum of private to
public presentation. 3D printing and novel fabrication methods will
enable the production of physical items such as jewelry, foods, and
larger objects such as chairs, cars, and building-construction
components.

! !200
 THE HUMAN FACTORS PERSPECTIVE

12.Accelerate analytic clarity. The big data movement is generating a

high volume and a variety of data whose analysis could lead to a better
understanding of invisible processes in business, community growth/
decay, learning, and public health. Supported by well-integrated visual
interfaces and statistical techniques, this better understanding could
result in more confident and bolder decisions that improve individual,
community, and planetary welfare.

13.Amplify empathy, compassion, and caring. Human relationships

flow more smoothly when empathy is expressed for others in
appropriate situations. Similarly, compassionate and caring actions
make life better for individuals, families, and communities.
Understanding and encouraging such behaviours could mean more
hope-filled and satisfying lives for many.

14.Secure cyberspace. Criminal activity and privacy violations threaten

to undermine user participation in every form of transaction,
participation, political engagement, and tool usage. Designing for usable
privacy and security will help ensure that benefits are retained,
intrusions minimized, and expectations of safety realized.

15.Encourage reflection, calmness, and mindfulness. Novel interfaces

that encourage reflection on past experiences and intended actions with
a calm and mindful attitude could enhance life experiences, creative
processes, and self-awareness. Reflection about life’s challenges, the
needs of less fortunate people, end-of-life decisions, and the digital
afterlife, while difficult, could lead to comforting clarity.

16.Clarify responsibility and accountability. Interfaces that clarify

users’ responsibility for their actions by making decisions and their
outcomes visible and sometimes public could promote more appropriate
behaviours with less overt bias or deception. While machine autonomy
is seen as a goal by some designers, in many contexts the preferred
approach may be to ensure human control while increasing the level of
automation. Similarly, algorithmic accountability interfaces would allow
users to better understand underlying computational processes in
search, recommender, and other algorithms, giving users the potential
to better control their actions.

! !201
 THE HUMAN FACTORS PERSPECTIVE

Undoubtedly, other opportunities and unexpected developments in HCI

research will occur. Conducting research on these complex sociotechnical
systems requires fresh thinking as well. The traditional controlled
experimental approaches associated with micro-HCI research will need to
be complemented by rigorous and repeated in-depth case studies, which
are part of macro-HCI research. Addressing these problems will require
improved interdisciplinary methods that emerge from science, engineering,
and design.

9.6 Importance of HCI

In the early days of computing only highly trained specialists could use
computers, and these were massive expensive machines really only found
in industry and research. Today, computers are everywhere, and the range
of knowledge and experience of different users is very broad. Unlike 30
years ago, the majority of computer users nowadays have not received
intensive specialised training.

HCI is extremely important when designing clear intuitive systems which

will be usable for people with a varied range of abilities and expertise, and
who have not completed any formal training. HCI takes advantage of our
everyday knowledge of the world to make software and devices more
understandable and usable for everyone. For example, using a graphic of a
miniature folder in a computer’s interface helps the user understand the
purpose of the folder, as everyone has experience with real paper folders in
their everyday lives. Ultimately, if a system is well designed with HCI
techniques, the user should not even have to think about the intricacies of
how to use the system. Interaction should be clear, intuitive, and natural.

Daily Life

Today computers permeate every aspect of our daily lives. Even if a person
does not directly own or use a computer, their life is affected in some way
by computing. ATM machines, train ticket vending machines, and hot
drinks dispensing machines are just a few examples of computer interfaces
a person can come into contact with daily without needing to own a
personal computer. HCI is an important factor when designing any of these
systems or interfaces. Regardless if an interface is for an ATM or a desktop
computer, HCI principles should be consulted and considered to ensure the
creation of a safe, usable, and efficient interface.

! !202
 THE HUMAN FACTORS PERSPECTIVE

Business and Industry

HCI is an important consideration for any business that uses computers in

their everyday operation. Well-designed usable systems ensure that staff
are not frustrated during their work and as a result are more content and
productive. HCI is especially important in the design of safety critical
systems, such as, for example, those found in power plants, or air traffic
control centers. Design errors in these situations can have serious results,
possibly resulting in the death of many people.

Accessibility

HCI is a key consideration when designing systems that are not only
usable, but also accessible to people with disabilities. The core philosophy
of HCI is to provide safe, usable, and efficient systems to everyone, and
this includes those with different sets of abilities and different ranges of
expertise and knowledge. Any system properly designed with HCI user-
centered techniques and principles will also be maximally accessible to
those with disabilities.

Software Success

Good use of HCI principles and techniques is not only important for the end
user, but also is a very high priority for software development companies.
If a software product is unusable and causes frustration, no person will use
the program by choice, and as a result, sales will be negatively affected.

Untrained users

Today, very few computer users actually read the manual accompanying
the software, if one exists. Only very specialised and advanced programs
require training and an extensive manual. Computer users expect to
understand the main functionality of an average program within a few
minutes of interacting with it. HCI provides designers with the principles,
techniques, and tools necessary to design effective interfaces that are
obvious and easy to use, and do not require training.

! !203
 THE HUMAN FACTORS PERSPECTIVE

9.7 Recent Advances In HCI

Recent Advances in HCI presents recent directions and advances of

research in HCI, namely intelligent and adaptive interfaces and ubiquitous
computing. These interfaces involve different levels of user activity:
physical, cognitive, and affection.

Intelligent and Adaptive HCI

Although the devices used by majority of public are still some kind of plain
command/action setups using not very sophisticated physical apparatus,
the flow of research is directed to design intelligent and adaptive
interfaces. The exact theoretical definition of the concept of intelligence or
being smart is not known or at least not publicly agreeable. However, one
can define these concepts by the apparent growth and improvement in
functionality and usability of new devices in market.

As mentioned before, it is economically and technologically crucial to make

HCI designs that provide easier, more pleasurable and satisfying
experience for the users. To realize this goal, the interfaces are getting
more natural to use every day. Evolution of interfaces in note-taking tools
is a good example.

First there were typewriters, then keyboards and now touch screen tablet
PCs that you can write on using your own handwriting, and they recognize
it change it to text and if not already made, tools that transcript whatever
you say automatically so you do not need to write at all. One important
factor in new generation of interfaces is to differentiate between using
intelligence in the making of the interface (Intelligent HCI) or in the way
that the interface interacts with users (Adaptive HCI).

Intelligent HCI designs are interfaces that incorporate at least some kind of
intelligence in perception from and/or response to users. A few examples
are speech enabled interfaces that use natural language to interact with
user and devices that visually track user’s movements or gaze and respond
accordingly.

Adaptive HCI designs, on the other hand, may not use intelligence in the
creation of interface but use it in the way they continue to interact with
users. An adaptive HCI might be a website using regular GUI (Graphical

! !204
 THE HUMAN FACTORS PERSPECTIVE

User Interface) for selling various products. This website would be adaptive
-to some extent- if it has the ability to recognize the user and keeps a
memory of his searches and purchases and intelligently search, find, and
suggest products on sale that it thinks user might need. Most of these
kinds of adaptation are the ones that deal with cognitive and affective
levels of user activity.

Another example that uses both intelligent and adaptive interface is a PDA
or a tablet PC that has the handwriting recognition ability and it can adapt
to the handwriting of the logged in user so to improve its performance by
remembering the corrections that the user made to the recognized text.

Finally, another factor to be considered about intelligent interfaces is that

most non-intelligent HCI design are passive in nature i.e. they only
respond whenever invoked by user while ultimate intelligent and adaptive
interfaces tend to be active interfaces. The example is smart billboards or
advertisements that present themselves according to users’ taste.

In the next section, combination of different methods of HCI and how it

could help towards making intelligent adaptive natural interfaces is
discussed.

Ubiquitous Computing and Ambient Intelligence

The latest research in HCI field is unmistakably ubiquitous computing

(Ubicomp). The term which often used interchangeably by ambient
intelligence and pervasive computing, refers to the ultimate methods of
human-computer interaction that is the deletion of a desktop and
embedding of the computer in the environment so that it becomes invisible
to humans while surrounding them everywhere hence the term ambient.

The idea of ubiquitous computing was first introduced by Mark Weiser

during his tenure as chief technologist at Computer Science Lab in Xerox
PARC in 1998. His idea was to embed computers everywhere in the
environment and everyday objects so that people could interact with many
computers at the same time while they are invisible to them and wirelessly
communicating with each other.

! !205
 THE HUMAN FACTORS PERSPECTIVE

Ubicomp has also been named the Third Wave of computing.

1. The First Wave was the mainframe era, many people one computer.

2. Then it was the Second Wave, one person one computer which was
called PC era and

3. Now Ubicomp introduces many computers one-person era.

HCI Systems Architecture

Most important factor of a HCI design is its configuration. In fact, any given
interface is generally defined by the number and diversity of inputs and
outputs it provides. Architecture of a HCI system shows what these inputs
and outputs are and how they work together. Following sections explain
different configurations and designs upon which an interface is based.

Unimodal HCI Systems

As mentioned earlier, an interface mainly relies on number and diversity of

its inputs and outputs which are communication channels that enable users
to interact with computer via this interface. Each of the different
independent single channels is called a modality. A system that is based on
only one modality is called Unimodal.

Based on the nature of different modalities, they can be divided into three
categories:

1. Visual-Based
2. Audio-Based
3. Sensor-Based

The next sub-sections describe each category and provide examples and
references to each modality.

! !206
 THE HUMAN FACTORS PERSPECTIVE

Visual-Based HCI

The visual based human computer interaction is probably the most

widespread area in HCI research. Considering the extent of applications
and variety of open problems and approaches, researchers tried to tackle
different aspects of human responses which can be recognized as a visual
signal.

Some of the main research areas in this section are as follow:

• Facial Expression Analysis

• Body Movement Tracking (Large-scale)
• Gesture Recognition
• Gaze Detection (Eyes Movement Tracking)

While the goal of each area differs due to applications, a general

conception of each area can be concluded.

Facial expression analysis generally deals with recognition of emotions

visually.

Body movement tracking and gesture recognition are usually the main
focus of this area and can have different purposes but they are mostly
used for direct interaction of human and computer in a command and
action scenario.

Gaze detection is mostly an indirect form of interaction between user and

machine which is mostly used for better understanding of user’s attention,
intent or focus in context-sensitive situations. The exception is eye tracking
systems for helping disabilities in which eye tracking plays a main role in
command and action scenario, e.g. pointer movement, blinking for clicking.
It is notable that some researchers tried to assist or even replace other
types of interactions (audio-, sensor-based) with visual approaches. For
example, lip reading or lip movement tracking is known to be used as an
influential aid for speech recognition error correction. 


! !207
 THE HUMAN FACTORS PERSPECTIVE

Audio-Based HCI

The audio-based interaction between a computer and a human is another

important area of HCI systems. This area deals with information acquired
by different audio signals. While the nature of audio signals may not be as
variable as visual signals but the information gathered from audio signals
can be more trustable, helpful, and in some cases unique providers of
information.

Research areas in this section can be divided to the following parts:

• Speech Recognition
• Speaker Recognition
• Auditory Emotion Analysis
• Human-Made Noise/Sign Detections (Gasp, Sigh, Laugh, Cry, etc.)
• Musical Interaction

Historically, speech recognition and speaker recognition have been the

main focus of researchers. Recent endeavours to integrate human
emotions in intelligent human computer interaction initiated the efforts in
analysis of emotions in audio signals. Other than the tone and pitch of
speech data, typical human auditory signs such as sigh, gasp, and etc.
helped emotion analysis for designing more intelligent HCI system.

Music generation and interaction is a very new area in HCI with

applications in art industry which is studied in both audio- and visual-based
HCI systems.

Sensor-Based HCI

This section is a combination of variety of areas with a wide range of

applications. The commonality of these different areas is that at least one
physical sensor is used between user and machine to provide the
interaction.

! !208
 THE HUMAN FACTORS PERSPECTIVE

These sensors as shown below can be very primitive or very sophisticated.

1. Pen-Based Interaction
2. Mouse & Keyboard
3. Joysticks
4. Motion Tracking Sensors and Digitizers
5. Haptic Sensors
6. Pressure Sensors
7. Taste/Smell Sensors

Some of these sensors have been around for a while and some of them are
very new technologies. Pen-Based sensors are specifically of interest in
mobile devices and are related to pen gesture and handwriting recognition
areas.

Motion tracking sensors/digitizers are state-of-the-art technology which

revolutionized movie, animation, art, and video-game industry. They come
in the form of wearable cloth or joint sensors and made computers much
more able to interact with reality and humans are able to create their world
virtually.

Haptic and pressure sensors are of special interest for applications in

robotics and virtual reality. New humanoid robots include hundreds of
haptic sensors that make the robots sensitive and aware to touch. These
types of sensors are also used in medical surgery application.

A few research works are also done on area of taste and smell sensors;
however, they are not as popular as other areas.

9.8 FUNCTIONAL GOALS VERSUS USER EXPERIENCE

GOALS

In a world where many technologies are designed as a part of a broader

desire to provide better customer experience, it is important that HCI/
usability be viewed not merely from the point of view of functional goals
but from the standpoint of experience goals. For example while designing
an online game or a gaming device, the experience goals could be
described in terms of the thrilling experience which it gives, or the level of
challenge it provides and not merely the functional logic of the game.

! !209
 THE HUMAN FACTORS PERSPECTIVE

A BA must be able to articulate the experience goals in a manner which

helps the designer to visualize an appropriate solution.

9.9 MENTAL MODELS

One fundamental issue with usability of any device arises when the users
mental model of how such a device works deviates from the actual
interaction which he experiences. For example, we often hear users lament
how it is tedious to get a report from an ERP system whereas they can get
it in the manner in which they want in simple spreadsheet. What they do
not realize it does not help to apply the mental model of spreadsheet to a
transaction processing system. The BA should be able to identify major
shifts in the mental models required for users in a given environment and
notify the same to the designer so that the design could be made in a
manner which facilitates easy transition to new proposed system.

9.10 USE CASES AND HCI/USABILITY

Use case is a very handy method for a customer centered design of a

software. The Use Case represents the users' expectations about why he
would use the system and how he would like to interact with it. A well
designed use case will embed these aspects and will enhance user
satisfaction. However, visualizing good use case dialogs depends on the
inherent skills and design sensibility of a BA or software designer. This
underscores the importance of understanding and imbibing design
sensibilities.

Use cases must therefore be reviewed from the usability standpoint before
accepting them for implementation.

9.11 REQUIREMENT GATHERING FROM THE STANDPOINT

OF THE HCI AND USABILITY PERSPECTIVE

Many a time, BAs and other project team members believe that we should
first get the functionality right and then beautify the screens. However, it is
often seen that good design has to be visualized right from the start to
avoid subsequent changes and client dissatisfaction.

! !210
 THE HUMAN FACTORS PERSPECTIVE

The ability of the BA to gather requirements in a manner which gives

enough information of the HCI and usability requirements and expectations
is key to this success.

Some of the aspects which a BA should therefore include in his

requirement checklist from an HCI/usability point of view could be:

• Use profiles and personas

• Usability goals

• Constraints and special environmental restrictions if any – e.g., hot and

dusty factory environments where users have dirty hands while using
systems or are wearing gloves etc.

• Cultural and other aspects – e.g., the use of appropriate symbols, colors
suited in that culture

• Standard/preferred colour, fonts, screen templates and other

organizational standards

• Limitations of existing devices – both hardware and software

• Specific expectations such as number of clicks to reach the desired

information/function

• Roles of people and rights and privileges assigned to each role

• Nature of existing devices in use, existing mental models, level of

challenge/risk perceived in transitioning from existing models

• Specific expectations about usability and HCI, if any.

! !211
 THE HUMAN FACTORS PERSPECTIVE

9.12 SUMMARY

• With ordinary people using information technology in every walk of life, it

is essential to understand characteristics of human users. In the context
of a specific solution, it is important to understand and classify users into
very well-defined personas. Personas represent the characteristics of the
users for which a solution is being designed.

• A BA must also understand basic design principles and be sensitized to a

wide variety of topics and subjects which industrial and product designers
learn. This will develop in them what could be considered a sense of
Business Aesthetics – which is a subtle judgement of what is good from a
design standpoint and what is not.

• HCI is a subject which deals with developing good man-machine

interactions.

• Usability is related to making an product or solution usable and easy to

use for an end-user.

• A BA must collect requirements and expectations about the

characteristics of users of the proposed system. The BA must also gather
requirements related to the nature of interaction and usability. He must
also be able to capture the user experience goals if any for the propsed
solution.

• Introducing human factors into Business Analysis practice will ensure

that the solutions so developed will be usable and provide a good
customer experience.

! !212
 THE HUMAN FACTORS PERSPECTIVE

9.13 SELF ASSESSMENT QUESTIONS

1. Explain the need for the study of human factors in the context of
Business Analysis.

2. What design and human characteristics does Business Analysts know?

3. Describe Human Computer Interaction and Usability in brief.

4. Outline the points of distinction between functional goals versus user

experience goals.

5. Write a note on Mental Models.

6. How to gather requirements from the standpoint of the HCI and

Usability perspectives?

9.14 Multiple Choice QUESTIONS

1. A Business Analyst must therefore be sensitized to various topics which

Industrial or Product designer's study includes __________ topics
subjects?
a. Human Computer Interaction/Interaction Design
b. Basic design principles such as form, colour, aesthetics
c. Typography – which deals with the design of fonts, typefaces etc.
d. All of the above

2. Some of the human characteristics may not be depending on cultural

elements within the organization or the larger ethnic or social
backgrounds.
a. True
b. False

3. Business Analysts must be able to articulate the __________ goals in a

manner which helps the designer to visualize an appropriate solution.
a. experience
b. functional
c. organizational
d. personnel

! !213
 THE HUMAN FACTORS PERSPECTIVE

4. The Use Case represents the __________ expectations about why he

would use the system and how he would like to interact with it.
a. users’
b. designers
c. both A & B of the above
d. None of the above

5. Which of the following is the aspects that a Business Analysts should

include in his requirement checklist from an HCI/usability point of view?
a. Use profiles and personas
b. Usability goals
c. Cultural and other aspects
d. All of the above

Ans: 1 - (d), 2 - (b), 3 - (a), 4 - (c), 5 - (d)


! !214
 THE HUMAN FACTORS PERSPECTIVE

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture


! !215
 SECURITY AND COMPLIANCE PERSPECTIVE

Chapter 10
Security And Compliance Perspective
Objectives

After reading this chapter, you will be able to:

• To understand why there is a need to gather requirements related to

Information Security, Compliance and Governance while designing an
information system or an IT solution

• To understand what these requirements mean to Business Analysis

• Learn about methods to uncover requirements related to security,

governance and compliance

Structure

10.1 Need for Analyzing Security, Compliance and Governance

Requirements

10.2 What is Negative Testing and Tips on Writing Negative Test Cases?

10.3 Negative Use Cases

10.4 Top 10 Negative Test Cases

10.5 Positive Vs Negative Testing

10.6 Summary

10.7 Self Assessment Questions

10.8 Multiple Choice Questions

! !216
 SECURITY AND COMPLIANCE PERSPECTIVE

10.1 NEED FOR ANALYSING SECURITY, COMPLIANCE AND

GOVERNANCE REQUIREMENTS

Increasingly Information security, compliance and governance aspects are

gaining importance. It is not enough to design a work flow, information
flow and process flow. It is equally important to ensure that we build
appropriate controls at every step keeping in mind:

• information security requirements (ISO 27000),

• compliance to several generic process standards (ISO 9000),
• compliance to industry specific and governance standards (e.g., HIPPA
for health care, Basel III in banking etc.)
• adherence to regulatory and statutory reporting to various external
governing agencies.

The nature of controls and the placement of these controls is indicated in

the respective process standards. The BA must understand these standards
and build adequate controls in the MIS which he designs.

These standards also require regular review of the processes and therefore
it is equally important to provide for audit trails to demonstrate that the
controls are working and provide evidence of this.

An elaborate discussion on specific controls required for security or any

other governance or process standard is beyond the scope of this book and
this course.

However, suffice to say that the BA should prepare a checklist of controls

required in to be placed as per various standards applicable to the
organization and to the specific business process. This checklist becomes a
means of gathering requirements as well as verifying that the solution
meets these requirements during acceptance testing.

! !217
 SECURITY AND COMPLIANCE PERSPECTIVE

10.2 What is negative testing and tips on writing negative

test cases

The primary objective of testing is to make the application under test,

defect free and makes quality application.

Many of us know that there are different types of testing needs to perform
to make application defect free like Functional testing, Integration testing,
system testing, regression testing, sanity testing, smoke testing, alpha and
beta testing, UAT testing etc.

If we think deeper, then you definitely realize that each testing activity is
further divided in to two different categories:

1. Positive testing and

2. Negative testing.

We are concentrating on one of the category called Negative testing. When

any tester starts thinking of testing then every tester is first thinking
around the positive test cases. It is absolutely necessary to know why
Negative testing is essential. The Negative testing plays a vital role in test
case execution.

Negative testing

Negative Testing is a part of testing which tests; what an application is not

supposed to do i.e. what is not defined in the documents or requirements.

Negative testing is the process of applying as much creativity as possible

and validating the application against invalid data. This means its intended
purpose is to check if the errors are being shown to the user where it’s
supposed to or handling a bad value more gracefully.

It is sometimes also called as Destructive Testing and it is commonly

referred to as error path testing or failure testing is generally done to
ensure the stability of the application. When it comes to quality of a
software application, both positive and negative testing plays equally
important roles.

! !218
 SECURITY AND COMPLIANCE PERSPECTIVE

By positive testing, we are making sure that application does what it is

meant for and performs every function as expected.

In negative testing, we find different ways to make the application cry i.e.
it crashes and handles that crash in a graceful way.

For example, if there is a text box which can take only numeric values,
enter an alphabet and test it. It should be able to handle that input and
throw an expected outcome which could be an error message or a pop-up
box saying “invalid value entered” etc.

Let’s take one more example to understand negative test scenario related
to a music application. Say an application named “Abc” can add up to 100
songs at a time in the playlist, so here 100 is our boundary value and when
we enter 101 song to the existing playlist, what would be the outcome?
Will that throw an exception? Or a warning message to the user? Or will it
restrict user to add more songs? Or will application crash?

These were few expected outcomes and reaction of the application to this
test scenario will depend on the requirements. Different music applications
will have different expected results for the same test case.

Stress testing, Load testing and Stability testing are parts of negative
testing.

Basic Factors that Help in Writing Positive and Negative Tests

If you closely observe, you will notice that there can be multiple positive
and negative scenarios in every example. Effective testing is when you
optimize an endless list of positive and negative scenarios in such a way
that you achieve sufficient testing.

Also, you will see a common pattern on how the scenarios are devised.
There are two basic parameters or techniques that formed a basis for
designing sufficient amount of positive and negative test cases.

! !219
 SECURITY AND COMPLIANCE PERSPECTIVE

The Two Parameters are:

1. Boundary value analysis

2. Equivalence partitioning

1. Boundary Value Analysis:

As the name itself implies, boundary indicates limits to something. Hence,
this involves designing test scenarios that only focus on the boundary
values and validate how the application behaves. Therefore, if the inputs
are supplied within the boundary values then it is considered to be positive
testing and inputs beyond the boundary values is considered to be a part of
negative testing.

For example, if a particular application accepts VLAN Ids ranging from 0 –

255. Hence here 0, 255 will form the boundary values. Any inputs going
below 0 or above 255 will be considered invalid and hence will constitute
negative testing.

! !220
 SECURITY AND COMPLIANCE PERSPECTIVE

2. Equivalence Partitioning:
In Equivalence partitioning, the test data are segregated into various
partitions. These partitions are referred to as equivalence data classes. It is
assumed that the various input data (data can be a condition) in each
partition behave the same way. Hence, only one particular condition or
situation needs to be tested from each partition as if one works then all the
others in that partition is assumed to work. Similarly, if one condition in a
partition doesn’t work, then none of the others will work.

Therefore, it’s now very apparent that valid data classes (in the partitions)
will comprise of positive testing whereas invalid data classes will comprise
of negative testing.

In the same VLAN example above, the values can be divided into say two
partitions.

So, the two partitions here would be:

• Values -255 to -1 in one partition

• Values 0 to 255 in another partition

Those who understand and strive for high standards and quality will
doubtlessly enforce negative testing as a must in the quality process.

! !221
 SECURITY AND COMPLIANCE PERSPECTIVE

While positive testing ensures that the business use case is validated,
negative testing ensures that the delivered software has no flaws that can
be a deterrent in its usage by the customer.

How to Write Down Negative Test Cases?

We will see how to write negative test cases with an example. Same rules
will apply to any software application.

In this example. We have a social media application to test and the

requirements are:

1. It requires username and password. Password should be alpha

numeric and minimum 8 characters long.

2. Maximum Limit to add friends to the account is 2000.

3. Minimum age to open an account is 18.

Now, for above 3 requirements, let’s make few negative test scenarios.

Test case 1: Enter only numbers in password field.

Test case 2: Enter special characters in password field.

Test case 3: Enter only alphabets in password field.

Test case 4: Enter less than 8 characters in password field.

Test case 5: Try and add more than 2000 people in the friend list. (This
can be automated, manually it will take a lot of time)

Test case 6: Enter a birth year which calculates your age in negative.

Test case 7: Enter a birth year which calculates your age in minor
category.

These were 7 test scenarios based on 3 given requirements. You can

suggest more in the comments section. Point here is to try every input
which is invalid and then check the behaviour of the app against it. If

! !222
 SECURITY AND COMPLIANCE PERSPECTIVE

application crashes or shuts down without any warning or message then it

needs to fix and give a proper message or warning, so that user would
know what not to do while using the application.

Below is the list of our recommendations that will simplify your

negative testing with Test Complete.

• If you load input data from a file, change its contents so that it contains
both valid and invalid data values. Please keep in mind that when using
invalid values, you need to build your test so that an error message is
not considered as an unexpected window and if this message appears,
the test passes successfully, which means that the tested application
works correctly.

• If you generate a list of testing input values automatically, change the

generating conditions so that it contains both valid and invalid data
values. For example, if your application contains a numeric field whose
bounds are from 10 to 50, test your application with the correct data (for
example, 15 and 45), the bound values (10 and 50) and create a
negative test with values that are not allowed, for example, with 9 and
51. Unlike using only positive tests, this approach will improve the test
coverage as it will test all possible conditions.

• If you input some data manually, create both a test with the correct input
value and a test with invalid data. For example, try to create a file with
an invalid name (for example, *NewFile.txt). In this case, the application
must show an error message (for example, "Invalid file name. The file
name must start with a letter, digit or underscore.") or fail to create the
file.

As you can see, negative testing improves the testing coverage of your
application. Using the negative and positive testing approaches together
allows you to test your applications with any possible input data (both valid
and invalid) and can help you make your application more stable and
reliable.

! !223
 SECURITY AND COMPLIANCE PERSPECTIVE

Advantages of Negative Testing

Below are 3 major advantages of performing Negative Testing:

1. Quality of the application becomes better when negative scenarios are

handled properly. If some application handles exceptions in a user-
friendly way and throws proper warning messages then there are less
chances of crashes and quality will become better as well.

2. When an application crashes frequently, it is considered unstable. If

Negative Testing is applied to it and the load or the root of crash is
fixed then application will become stable and pleasant to use.

3. User will know the limitations beforehand. As we discussed in previous

example where 100 was the limit to the playlist, if user is warned
beforehand that application will not add 101 songs then he will not try
to add more than 100 songs. He will know the limitations of the
application and will use it accordingly.

A negative scenario is based out of the box thinking and has no limitations
of how much you can explore. Bugs found during Negative Testing are
always crucial since they are found by keeping user in mind. It requires
skills and better understanding of the application to test it in a negative
way. Tester can also automate negative test case and automation can also
be used to load the application with data or to do stress testing on it. When
you want a high-quality application, both testing should be given equal
importance.

Is negative Testing Important?

Since testing is time and cost consuming task, deciding 'what', 'how' and
'how much' to test is really important. We have to choose wisely whether
we have to do negative testing in our system or not. So, let's have a look
on the importance of negative testing.

! !224
 SECURITY AND COMPLIANCE PERSPECTIVE

A. Organization Perspective

It is the responsibility of the organization to provide good quality product

to its client. To achieve this, one has to do negative testing.

As a part of confirmation against a failure an organization have to do

negative testing.

Maybe we can't build a 100% error free system, but we have to make sure
that we have done everything to prevent a failure, in order to achieve that
we should do negative testing.

The impact is one factor which we have to consider. Consider we have done
positive testing on an e-commerce site and make sure everything is fine.
But what if there is a loophole in our system that someone can do SQL
injection and erase all our data. That will be a great security breach. To
avoid this type of cases, one has to do negative testing too.

For applications open for public, mainly websites we have to always keep in
mind that we don't have much control the using procedure of the
application, so we have to do negative testing to make sure that all such
cases are covered and contained.

Another thing we need to take care is that there are lot of black hackers
out there who is looking for an opportunity to destroy the system. Hacking
is an important case covered in negative testing

B. Client Perspective

Clients always expect zero vulnerability products, in order to ensure that

negative testing is a must. If it is a sensitive product like e-commerce,
online stock, etc., then security and negative testing is a must.

The only concern to the client regarding negative testing is that the cost.
But once the impact is analyzed it is up to the client to decide whether to
do or not negative testing.

! !225
 SECURITY AND COMPLIANCE PERSPECTIVE

Pros and Cons of Negative Testing

Like all other testing techniques, there are pros and cons for negative
testing mainly based on the 'where', 'when' and 'how' to use. Let's take a
look on this.

Pros

1. As we all know negative testing is very important to ensure the quality

of a product. A good quality product is a zero-vulnerability product, to
ensure that negative testing is very important.

2. Doing negative testing makes sure that all possible cases are covered.
Intentionally or unintentionally there is a chance of negative test cases
to occur. So, to make sure all cases are covered we have to do negative
testing along with positive testing.

3. Negative testing will make more confidence to the client before going
live.

Cons

1. Negative testing in some cases becomes a waste of time and energy. In

many cases, there is no need for excessive negative testing. For
example, if an application is created for a single person use, then we
don't have to consider the case that 100 user uses the system at a time.
So, deciding conditions in negative test cases is very important. There
will be times where we don't have to do negative testing on a particular
system.

2. Require skilled and experienced people to create negative test cases.

3. To client negative testing is another thing that cause unnecessary delay

in release and cost adder.

4. Chance that team spends more time and energy on negative testing.
There is a chance that testers spend a lot of time and energy in
negative testing that results in a lower concentration in positive testing

! !226
 SECURITY AND COMPLIANCE PERSPECTIVE

10.3 NEGATIVE USE CASES

In case of interactive software systems, the BA could use the concept of

Negative Use Cases. Use cases in general are cases of use of a system by a
user. In identifying use case, we generally ask a question as why would a
given user wish to use the system and what purpose. Thus, for example, a
bank customer may wish to withdraw cash – this would be one of the use
cases.

Security and Compliance requirements can be gathered by asking the

question 'what should we not allow the user to do?'or 'what should not be
allowed to happen?'. A brainstorming on this question will give possible
pointers to the security and compliance requirements.

A more detailed description of Use Case is given in the chapter on

visualizing IT solutions.

10.4 Top 10 Negative test cases

Negative test cases are designed to test the software in ways it was not
intended to be used, and should be a part of your testing effort.

Below are the top 10 negative test cases you should consider when
designing your test effort:

1. Embedded Single Quote

Most SQL based database systems have issues when users store
information that contain a single quote (e.g. John’s car). For each screen
that accepts alphanumeric data entry, try entering text that contains one
or more single quotes.

2. Required Data Entry

Your functional specification should clearly indicate fields that require data
entry on screens. Test each field on the screen that has been indicated as
being required to ensure it forces you to enter data in the field.

3. Field Type Test

Your functional specification should clearly indicate fields that require
specific data entry requirements (date fields, numeric fields, phone
numbers, zip codes, etc.). Test each field on the screen that has been

! !227
 SECURITY AND COMPLIANCE PERSPECTIVE

indicated as having special types to ensure it forces you to enter data in

the correct format based on the field type (numeric fields should not allow
alphabetic or special characters, date fields should require a valid date,
etc).

4. Field Size Test

Your functional specification should clearly indicate the number of
characters you can enter into a field (for example, the first name must be
50 or less characters). Write test cases to ensure that you can only enter
the specified number of characters. Preventing the user from entering
more characters is more elegant than giving an error message after they
have already entered too many characters.

5. Numeric Bounds Test

For numeric fields, it is important to test for lower and upper bounds. For
example, if you are calculating interest charged to an account, you would
never have a negative interest amount applied to an account that earns
interest, therefore, you should try testing it with a negative number.
Likewise, if your functional specification requires that a field be in a specific
range (e.g. from 10 to 50), you should try entering 9 or 51, it should fail
with a graceful message.

6. Numeric Limits Test

Most database systems and programming languages allow numeric items
to be identified as integers or long integers. Normally, an integer has a
range of -32,767 to 32,767 and long integers can range from
-2,147,483,648 to 2,147,483,647. For numeric data entry that do not have
specified bounds limits, work with these limits to ensure that it does not
get numeric overflow error.

7. Date Bounds Test

For date fields, it is important to test for lower and upper bounds. For
example, if you are checking a birth date field, it is probably a good bet
that the person’s birth date is no older than 150 years ago. Likewise, their
birth date should not be a date in the future.

8. Date Validity
For date fields, it is important to ensure that invalid dates are not allowed
(04/31/2007 is an invalid date). Your test cases should also check for leap
years (every 4th and 400th year is a leap year).

! !228
 SECURITY AND COMPLIANCE PERSPECTIVE

9. Web Session Testing

Many web applications rely on the browser session to keep track of the
person logged in, settings for the application, etc. Most screens in a web
application are not designed to be launched without first logging in. Create
test cases to launch web pages within the application without first logging
in. The web application should ensure it has a valid logged in session
before rendering pages within the application.

10. Performance Changes

As you release new versions of your product, you should have a set of
performance tests that you run that identify the speed of your screens
(screens that list information, screens that add/update/delete data, etc.).
Your test suite should include test cases that compare the prior release
performance statistics to the current release. This can aid in identifying
potential performance problems that will be manifested with code changes
to the current release.

10.5 POSITIVE v/s NEGATIVE Testing

Differences Between Positive and Negative Testing

Trusting the results of your software tests is one of the most delicate
subjects and thinking negatively about it is an important aspect today. It is
said that testers should not only test for the positive results i.e. whether
the system functions as expected with valid inputs, but also check for
negative value tests i.e. if the application works with quality under
provided invalid inputs.

It is always seen that 85% of the test cases passed are related to only
70% of the total requirements. The other 30% are for failed negative value
testing which is often overlooked. So, the final aim of any software testing
should be to make it 100% reliable and quality application.

Positive Testing
Any software system is highly vulnerable to inappropriate data. This seems
scary, isn’t it? The end users sooner or later always find a way to divert
from the ethical ways, which is dangerous and risky. The positive testing
helps the administrators to quickly understand & learn these practices to
fix issues in no time.

! !229
 SECURITY AND COMPLIANCE PERSPECTIVE

Positive testing also facilitates the sharing of knowledge on system

architecture since the projects are started small and tested thoroughly
through all the phases of SDLC.

Negative Testing

It is interesting to note that negative testing is done to break the project

with respect to its different test conditions. This gives the tester a vision to
test for scenarios that are not designed and provides an invalid set of
input.

Let us differentiate between positive testing and negative testing in a

simpler way by considering a scenario:

POSITIVE TESTING NEGATIVE TESTING

Test for a specific number of user

1 Test for excessive (load) inputs
inputs
2 Checks for valid set of values Checks for invalid set of values

It is done by giving the positive It is done by keeping the negative

3 point of view point of view
Eg: Numbers like 9999999999 Eg: 99999abcde

Done to identify known set of test Done with unknown set of test
4
conditions conditions
To check whether all client
Anything that is not mentioned in the
5 requirements are met while doing
client requirement is tested
the project

In positive test scenarios,

Password test box should not exceed
6 password test should accept 6- 20
more than 20 characters
characters
Accept all numeric and alphabetic
7 Do not accept special character
values

Testing any software is essential to deliver quality software and ensure a

bug-free working. Hence, using both the positive testing and negative
testing techniques give enough assurance about the quality of the product.

! !230
 SECURITY AND COMPLIANCE PERSPECTIVE

10.6 SUMMARY

• Information is increasingly becoming an organizational asset. It needs to

be protected. The challenge lies in identifying need for security
throughout a business process.

• Along with security comes compliances of various kinds – some which are
industry specific while others which are broader in nature. Each
compliance and governance standard specifies the need for adequate
controls and the evidence that these controls work.

• One of the ways to identify security requirements is the use of negative

use cases – i.e., what should the user not be allowed to do?

• For compliance and governance – the BA must study these standards and
identify requirements for controls and for providing evidences and audit
trails.

10.7 SELF ASSESSMENT QUESTIONS

1. Why is there a need to analyse security, compliance and governance

while designing an IT solution?

2. How does a negative use case helps to identify security requirements?

10.8 MULTIPLE CHOICE QUESTIONS

1. Which of the following standards require regular review of the processes

and therefore, it is equally important to provide for audit trails to
demonstrate that the controls are working and provide evidence of this?
a. Compliance to several generic process standards (ISO 9000),
b. Compliance to industry specific and governance standards (e.g.,
HIPPA for health care, Basel III in banking etc.)
c. Adherence to regulatory and statutory reporting to various external
governing agencies.
d. All of the above

! !231
 SECURITY AND COMPLIANCE PERSPECTIVE

2. The __________ becomes a means of gathering requirements as well

as verifying that the solution meets these requirements during
acceptance testing.
a. Checklist
b. Standards
c. Reports
d. Processes

3. In case of interactive software systems, the Business Analysts could use

the concept of __________Use Cases.
a. Positive
b. Negative
c. Standard
d. Neutral

4. __________ requirements can be gathered by asking the question

'what should we not allow the user to do 'or 'what should not be allowed
to happen?'
a. Security
b. Compliance
c. Both A & B of the above
d. None of the above

5. In identifying use case, we generally ask a question as why a given user

wish to use the system and what purpose.
a. True
b. False

Ans: 1-(d), 2 - (a), 3 - (b), 4 (c), 5 - (a)


! !232
 SECURITY AND COMPLIANCE PERSPECTIVE

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture


! !233
 THE ENTERPRISE PERSPECTIVE

Chapter 11
The Enterprise Perspective
Objectives

After reading this chapter, you will be able to:

• To understand the purpose of Enterprise Analysis

• To understand what constitutes Enterprise Analysis

• To learn about various tools and frameworks for the analysis of the
enterprise

• To understand the principles behind developing a business cases for an IT

solution

Structure

11.1 Need for Enterprise Analysis

11.2 The Layers of Enterprise Analysis
11.3 An Overview of Enterprise Analysis
11.4 The IIBA Perspective on Enterprise Analysis
11.5 Enterprise Stakeholder Analysis — Payroll — An Illustration
11.6 The Zachman's Framework
11.7 Uses of the Zachman's Framework
11.8 Structure & Rules of Zachman Framework
11.9 Enterprise Analysis (EA) focus Areas
11.10 Tools for Enterprise Analysis
11.11 Analysing the Intangible Aspects of an Enterprise
11.12 The Business Case and Feasibility Report
11.12.1 Financial Feasibility
11.12.2 Operational Feasibility
11.12.3 Technical Feasibility
11.12.4 Schedule Feasibility
11.13 Summary
11.14 Self Assessment Questions
11.15 Multiple Choice Questions

! !234
 THE ENTERPRISE PERSPECTIVE

11.1 NEED FOR ENTERPRISE ANALYSIS

It is important that a Business Analyst appreciates the fact that every

business process and every IT application is part of a larger organizational
context which in turn is part of a larger socio-scientific-economic
ecosystem. Increasing competition and the need to differentiate in the
marketplace has put tremendous pressure on most businesses. It is not
surprising that business processes must support. It is therefore necessary
that a study of a business process or a requirement gathering for an IT
solution should include an understanding of the broad context within which
the business process or the IT solution is expected to perform.

11.2 THE LAYERS OF ENTERPRISE ANALYSIS

For convenience, we could divide the analysis of the enterprise into several
layers – one above the other as follows:

• The immediate layer – which includes the process itself or the IT

application

• Processes and IT applications with which it has to interact and interface

• The larger organizational context including key stakeholders,

organization's vision/mission/values, goal, strategy, culture etc.

• A group level organizational context particularly when the organization is

a part of a larger group of companies

• The external competitive business environment

• The external regulatory, political and social environments

While the study of the first two layers is generally part of any requirements
study, a study of the other contextual layers helps in identifying any
expectations about the business process or the IT application which may
arise from them. 


! !235
 THE ENTERPRISE PERSPECTIVE

11.3 An overview of Enterprise Analysis

What is Enterprise Analysis?

Enterprise analysis (also known as strategic enterprise analysis or company

analysis) is defined as focusing “on understanding the needs of the
business as a whole, its strategic direction, and identifying initiatives that
will allow a business to meet those strategic goals.” Enterprise analysis
involves a thorough examination of not only the business problem (need)
and its proposed business solution (if one already exists), but also an in-
depth look into whether the proposed solution is truly the best solution, a
detailed analysis of what the solution entails, its risks, and its feasibility in
the existing organizational climate. Because so much research and
examination are involved in the process of enterprise analysis work, they
are routinely done at a project’s inception. (Or, for agile projects, they are
done throughout the project.)

! !236
 THE ENTERPRISE PERSPECTIVE

A thorough enterprise analysis endeavour will include:

a. An examination of currently proposed business initiatives for both

viability and effectiveness.

b. An identification of the true, core business need(s) at hand, regardless

of what has been proposed thus far.

c. A description of the ideal solution to the need.

d. An evaluation of strategic risks and returns associated with any

proposed business solution.

e. The scope of the business analyst’s proposed solution(s) to the business

need, meaning what tools and processes are involved in getting to the
solution.

f. The creation of business requirements defining the business need and

proposed solution, complete with visuals and a sound business case.

Because the work is so specialized—and so crucial—many organizations

have senior analysts to spearhead their enterprise analysis endeavors.
However, the understanding and application of business analysis is useful
for a number of roles in the business world that may have interest in pre-
project research and solution justification, including but not limited to
business analysts, project managers, stakeholders, business owners, and
software engineers.

The Role of Enterprise Analysis in the Requirements Process

As was mentioned above, enterprise analysis is the key starting point to

the requirements process, identifying the scope of the business need and
justifying its solution. According to BABOK, “It is through enterprise
analysis activities that business requirements are identified and
documented.” Enterprise analysis is the foundational research that
undergirds any successful set of requirements. In addition to being a
crucial starting point, enterprise analysis is continually referenced and
refined throughout any business analysis endeavor, particularly in agile
development.

! !237
 THE ENTERPRISE PERSPECTIVE

It is important to note that while many aspects of business analysis—

including requirements gathering and implementation—are often done in
concert with IT, enterprise analysis ideally is performed irrespective of IT.
The work of enterprise analysis is business-focused, and while enterprise
analysis may consider what IT can bring to the table in terms of solutions,
its primary focus is on business, including changes in business processes,
models, and strategies.

A final, polished description of business need, capability gaps, proposed

solution and scope, and business case are normally included in the
business requirements that are presented to stakeholders. As with any set
of requirements, stakeholder involvement, agreement, and communication
are keys to their implementation success.

Core Competencies for Enterprise Analysis

A business analyst must possess certain core competencies in order to

effectively lead enterprise analysis projects. These include (but are not
necessarily limited to) the abilities to:

1. Create and maintain business architecture. To perform this, an

analyst must be able to research and discern where a business is
(baseline architecture) and where it should be (target business
architecture). According to BABOK, business architecture “defines an
organizations current and future state, including its strategy, its goals
and objectives.”

2. Conduct feasibility studies. A feasibility study looks at the options

that are proposed and examines whether they are technically possible
within the organization and whether they will meet the organization’s
goals.

3. Perform opportunity identification and analysis. This is the

practice of identifying and analyzing “new business opportunities to
perform organizational performance. This is typically done in
consultation with subject matter experts.

4. Prepare and maintain the business case. For this competency, an

analyst must be able to identify the cost in time, money and resources

! !238
 THE ENTERPRISE PERSPECTIVE

that the proposed solution will consume and weighs against the tangible
benefits that the solution will offer.

5. Understand and perform risk management. For this skill, an analyst

must understand the risks (technical, financial, business, and so on) of
implementing the proposed solution and weigh those against the risk of
not implementing the solution.

For more information on these competencies, please review their

descriptions within BABOK.

Enterprise Analysis Services

Many able consultants, both individuals and firms, offer enterprise analysis
services that are useful to organizations that may be less experienced or
familiar with enterprise analysis. A few examples of these services include

1. Broad in-depth organizational and industry research, helping to ensure

that all avenues are explored to guarantee the very best business
solution is proposed

2. Business analysis and business development.

3. Capability modelling, business case creation, and decision support,

helping to justify the business solution to management.

! !239
 THE ENTERPRISE PERSPECTIVE

11.4 THE IIBA PERSPECTIVE ON ENTERPRISE ANALYSIS

The IIBA BoK version 2.0 describes Enterprise Analysis as being composed
of the following subprocesses:

• Define the Business Need – This requires that a BA identify and

understand the need from the various stakeholders.

• Access Capability Gaps – This is a comparison between the as-is

business process and the needs expressed by the stakeholders. This
gives a sense of direction and criteria for acceptance of a possible
solution.

• Determine Solution Approach – There could be various approaches to

solve the problems associated with the business process. Some of the
approaches may require automation of some parts of the process. Here,
the BA tries to assess the overall changes required from an automation
point of view as well as in other aspects such as business process itself,
the products and services it renders, the organization structure, roles
and responsibilities etc.

• Define Solution Scope – Here, the BA tries to assess the functional

areas to be covered by the solution, what aspects are to be kept out of
the scope.

• Define Business Case – Finally, the BA prepares a Business Case which

gives a justification for the initiative and highlights the value which the
solution can bring to the organization. This could be a combination of
financial as well as intangible benefits.

! !240
 THE ENTERPRISE PERSPECTIVE

11.5 ENTERPRISE STAKEHOLDER ANALYSIS – PAYROLL –

AN ILLUSTRATION

Usually, several stakeholders are associated with a business process. For

example for a payroll process, employees, the payroll department staff, the
payroll head, all the business Heads and CEO/CFO, the Income Tax
authorities, various government bodies could all be associated in some
ways. Hence, it is important to identify these stakeholders and study their
requirements and expectations about the business process. Following could
be some of the expectations arising from these stakeholders.

• Employees

- May wish to see their earnings and deductions so far and estimated for
the year.

- Should be able to plan their tax and investments.

• Payroll executive

- Should be able to quickly resolve employee queries.

- The software should enable efficient computation of payroll.

- The software should generate all the statutory reports such as

Provident fund etc.

• Payroll Manager

- Would expect the software to help improve the scalability, accuracy and
productivity of his payroll department.

- It should help provide metrics on the performance of the payroll

processes through a dashboard.

- It should help minimize error rates in payroll processing and ensure

110% compliance to rules both in terms of the content as well
reporting.

! !241
 THE ENTERPRISE PERSPECTIVE

• CEO/President HR

- The CEO perhaps is looking at the possibility of accessing payroll on his

tablet or mobile phone so that he knows the employee related costs at
a location which he is visiting.

- He may also need decision support to work out the Cost to Company
(CTC ) for a given band, level, grade , designation so that he can
identify ways to plan financial incentives.

- The CEO/President HR may also wish to benchmark his salaries with

competitors in the industry.

• Accounts

- The accounts department needs to get the pay calculation in time so

that payouts can be made.

- They also need to book the data to be sent to them in a manner which
can easily be merged into the accounting system.

Thus, there are multiple stakeholders with multiple expectations. The

question is whether there is a method, tool or approach for analyzing their
needs.

! !242
 THE ENTERPRISE PERSPECTIVE

11.6 THE ZACHMAN'S FRAMEWORK

One of the frameworks which can help an analyst to study these various
stakeholders from an enterprise point of view is the Zachman's framework.

Perspecti
ves and
questions
to ask
Data Process Network People Time Need

What? How? Where? Who? When? Why?

Planner
Stakehol
ders Process
Owner
Designer

Developer

System
Integrator
User

The Zachman's framework has two dimensions. The rows represents the
various stakeholders and the columns represent the various perspectives
which each of these stakeholders may have.

In the payroll example:

• Planner CEO/President HR
• Process Owner – Payroll Manager
• Designer/Developer/System Integrator – are all roles within the
development team
• User – could include direct users such as the employee, payroll
executives and indirect users such as accounts executives etc.

For each of the above if we ask common management questions, viz.,

What, How, Who, Where, When and Why, we get a much broader
understanding of expectations from these stakeholders.

! !243
 THE ENTERPRISE PERSPECTIVE

For example, the question 'where?' (Network) with reference to the user as
a stakeholder would raise questions such as:

• From where do the users connect to the system – In a global software

company, for example, software engineers may be deputed in various
parts of the world at client locations. Hence, employees may connect
from practically anywhere.

• They could also belong to different nationalities and speak in different

languages. Hence if there is a Chinese or Japanese employee appointed
in the local country for a project there, such a person would prefer to
have an interface to the payroll which shows everything in their local
language – hence the need for a language option for the payroll becomes
important.

• An even bigger question which is one of an architectural nature is –

Should the payroll be run as separate payroll installations in different
countries? Should there be different versions of the payroll system since
local laws in different countries are different ? or Should we have a
common payroll system which can handle multi-currency, multi-language
capability and which can be paramterized to work for different legal
requirements but run centrally from a shared-services department based
in India? Thus, several such architectural questions arise.

11.7 USES OF THE ZACHMAN’S FRAMEWORK

You will realize that the Zachman’s framework helps the analyst to
generate a plethora of questions to ask – most of these questions are
either at a process level, management level or enterprise level. Hence,
Zachman’s framework is a very powerful tool for enterprise analysis if used
effectively by the analyst.

The Zachman’s framework also indicates the importance of studying a

business process or a need for software solutions from multiple
perspectives. It highlights the fact that the BA must not stop at analyzing
the user requirement alone but extend his vision for the solution to include
the needs of top management, process owners and even his own team-
mates within the software development team such as the designer,
developer and integrator. It may be important to highlight here that in
many software export projects it is the analyst who travel abroad to the

! !244
 THE ENTERPRISE PERSPECTIVE

clients' place and the developers and other technical teammates are
located in the offshore base. Hence, he has to study the requirements from
the standpoint of the designers, integrators etc. Several functional as well
non-functional requirements such as performance expectations, interface
requirements, security requirements, target hardware and software
platforms for which the solution is designed are important from the inputs
which the BA should capture during his on-site visit since they are of
immense importance to the technical team.

11.8 Structure and Rules of Zachman Framework

Zachman Framework is a two-dimensional classification scheme for

descriptive representations of an Enterprise that is structured as a matrix
containing 36 cells, each of them focusing on one dimension or perspective
of the enterprise. Rows are often presented as different viewpoints
involved in the systems development process, while columns represent
different perspectives of the stakeholders involved in the organization.

The rows of Zachman Framework focus on describing the enterprise from

six viewpoint perspectives of the stakeholders. These six perspectives are
based on English language interrogatives 'what', 'where', 'who', 'when',
'why', and 'how' (known as W5H).

The description of the enterprise from specific viewpoint to a group of

stakeholders is the columns of the framework that consist of a set of
artifacts. The stakeholders are generally grouped as planners, owners,
designers (architects), implementers, sub-constructors, users, or
sometimes represented as viewpoints: scope context, business concepts,
system logic, technology, physics, component assembles and operations
classes.

The framework enables complex subjects to be distilled into systematic

categories in the column headers, using these six basic questions (known
as 5WH). The answers to these questions will differ, depending on the
perspective or audience (represented in the rows).

! !245
 THE ENTERPRISE PERSPECTIVE

Each view is a description from a particular perspective and has a

representation (a model or functioning system), as indicated in the Table
above.

Here is a brief description of each view and model/functioning system:

! !246
 THE ENTERPRISE PERSPECTIVE

Columns of Zachman Framework

The columns represent the interrogatives or questions that are asked of

the enterprise. These are:

1. What (data): what is the business data, information or objects?

2. How (function): how does the business work, i.e., what are the
business' processes?

3. Where (network): where are the businesses operations?

4. Who (people): who are the people that run the business, what are the
business units and their hierarchy?

5. When (time): when are the business processes performed, i.e., what
are the business schedules and workflows?

6. Why (motivation): why is the solution the one chosen? How was that
derived from? What motivates the performance of certain activities?

Rows of Zachman Framework

Each row represents a distinct view of the organisation, from the

perspective of different stakeholders. These are ordered in a desired
priority sequence.

A row is allocated to each of the following stakeholders:

1. Planner's View (Scope Contexts): This view describes the business

purpose and strategy, which defines the playing field for the other
views. It serves as the context within which the other views will be
derived and managed.

2. Owner's View (Business Concepts): This is a description of the

organization within which the information system must function.
Analyzing this view reveals which parts of the enterprise can be
automated.

! !247
 THE ENTERPRISE PERSPECTIVE

3. Designer's View (System Logic): This view outlines how the system
will satisfy the organization's information needs. The representation is
free from solution specific aspects or production specific constraints.

4. Implementer's View (Technology Physics): This is a representation

of how the system will be implemented. It makes specific solutions and
technologies apparent and addresses production constraints.

5. Sub-Constructor's View (Component Assembles): These

representations illustrate the implementation-specific details of certain
system elements: parts that need further clarification before production
can begin. This view is less architecturally significant than the others
because it is more concerned with a part of the system than with the
whole.

6. User's View (Operations Classes): This is a view of the functioning

system in its operational environment.

Rules of Zachman Framework

The framework offers a set of descriptive representations or models

relevant for describing an enterprise.

a. Each cell in the Zachman Framework must be aligned with the cells
immediately above and below it.

b. All the cells in each row also must be aligned with each other.

c. Each cell is unique.

d. Combining the cells in one row forms a complete description of the

enterprise from that view.

! !248
 THE ENTERPRISE PERSPECTIVE

Integrating UML, BPMN, ERD with Zachman Framework.

"
The Zachman Framework is an ontology (In information technology, an
ontology is the working model of entities and interactions in some
particular domain of knowledge or practices) which helps to create the
structure rather than a methodology which provides the transforming
process. In practice, Zachman Framework is quite popular, since it can be
applied with other frameworks that emphasize the process.

The Zachman Framework can provide guidance on what kind of artifacts

are needed in different stage of the process. The combined application can
produce predictable and repeatable results according to the basic structure
provided by Zachman Framework. The following figures show the ontology
structure of Zachman Framework and combined use of the UML, BPMN,
ERD and other diagrams

! !249
 THE ENTERPRISE PERSPECTIVE

11.9 Enterprise Analysis (ea) focus areas

Enterprise Analysis (EA) focuses on several areas:

(a) Identification of the business need

(b) Understanding of the current state of an organization
(c) Understanding of the existing information landscape
(d) Definition of gaps in capabilities
(e) Definition of an approach to a solution and solution scope
(f) Support in developing a business case.

Engaging business stakeholders in requirements elicitation activities helps

specify the business problem. Enterprise Analysis invokes tasks from
Requirements Elicitation and Requirements Analysis when it is required. It
happens because the accurate definition of the business need is only
possible through communication with the stakeholders.

The expressed high-level requirements have to be analysed and prioritized

to ensure that the requirements are clearly separated from wishes.
Assumptions and constraints related to solution scope are expressed
upfront to support the development of the business case.
EA feeds information about the current business landscape and long-term
business objectives into BA Planning. Several disciplines facilitate obtaining
this information: enterprise architecture, service operation and service help
desk (ITIL), business process management (BPM).

The identified current state serves as a baseline for defining a gap between
the existing and required new capabilities.

Nowadays projects often combine changes to business processes, software

packages, introduction of new business services and even new models of
operation. Process mapping and the enterprise architecture framework
both facilitate gap analysis. They also help in defining scale of possible
changes and identifying business rules governing the existing processes.

After the required capabilities have been specified, it is time to define a

solution approach which should be aligned with the project approach to
ensure effective execution of the project.

! !250
 THE ENTERPRISE PERSPECTIVE

The defined solution approach and required new capabilities enable the
definition of solution scope. Solution scope should be aligned with project
scope.

The business case is the output of EA. It specifies the business need,
required new capabilities, approach to the realization of the specified new
capabilities, project and solution scope, time and cost estimations,
assumptions and constraints, and finally justification of feasibility to
undertake the project.

11.10 TOOLS FOR ENTERPRISE ANALYSIS

The Zachman’s framework also is an overarching framework. For a given

row and column in the above framework, the BA should select an
appropriate tool/technique for analysis. For example, at the planner's levels
– questions such as Why can best be analyzed using an appropriate
Business Strategy and IT strategy framework. At the level of a process
owner, the question of How can best be analyzed using an appropriate
process mapping tools such as an activity diagram, a flowchart etc.
Likewise at the process owner’s level to understand the ‘people' aspect, the
hierarchy chart or organogram would help. Thus within the larger
framework provided by the Zachman's framework, appropriate techniques
should be used.

The table below summarises some of the techniques which could be used
at various levels of the Zachman's framework. 


! !251
 THE ENTERPRISE PERSPECTIVE

Level Purpose Techniques/Tools References

Planner Business Business strategy Any book on Business

Strategy and frameworks such as Porter’s Strategy
competition 5 forces model, Ansoff’s
model, SWOT analysis etc.
Planner IT strategy Frameworks such as Critical IT for Management –
Success Factors, Alfred DLP book – Section 2 –
Chandler's strategy trilogy, chapter on Long range
Macfarlan's Strategy Grid Planning of Systems

Process Understand Data flow diagram, Activity Most of these diagrams

Owner broad process Diagram, Hierarchy chart. have been described in
and service Class Diagram, state these books. Also refer
transition diagram, service IT for Management
Blue printing and service (DLP)
scapes etc.
User Solution Use case diagrams, Use Has been described in
visualization case dialogs, screen based this book. Also refer IT
prototypes/ wireframes etc. for Management

A detailed description of the above methods is beyond the scope of this

book. However, some of these tools are described in great detail elsewhere
– these references are given in the last column in the table above.

The Zachman’s framework thus helps a BA to first look at the critical

business issues which the strategy frameworks are able to highlight . The
alignment of IT to these critical business issues is what many of the IT
strategy framework help a BA or CIO to bring about. The process related
diagramming tools help in understanding a broad level business processes
and can be useful in blueprinting new services and new business processes
as well as transforming existing processes. Finally, the user level view
helps a BA to capture needs of various direct and indirect users and to
visualize an IT Solution.

From the foregoing, it would be clear that the Zachman's framework

provides a good structure for Enterprise analysis.

! !252
 THE ENTERPRISE PERSPECTIVE

11.11 ANALYZING THE INTANGIBLE ASPECTS OF AN

ENTERPRISE

While applying the Zachman's framework and many other tools and
techniques, the focus tends to be on the tangible business aspects. The BA
must however keep in mind that business processes and software solutions
work in human organizations. The Zachman’s framework does require the
BA to look at the people aspect. This usually tends to be in the form of the
experience of users with technology, motivation to use the solution etc.
However, the larger cultural context of the organization, the underlying
philosophies of running business, current levels of positive energy within
the organizations etc. are important aspects to study.

11.12 THE BUSINESS CASE AND FEASIBILITY REPORT

One of the purposes of the Enterprise Analysis is to be able to justify the

investments in the business process or IT solution. The Zachman’s
framework requires the BA to ask the crucial management question of
'why?' at every stakeholder level. This is essentially a question of the
business justification or the business case.

While the business case is about the need and value of a solution to an
organization, the practicality of the solution in atleast four ways, viz.,
financial (economic), technical, operational and schedule needs to be
assessed.

11.12.1 Financial Feasibility

This is an essential part of any business case. Financial feasibility is largely

judged using established financial measures such as Cost versus Benefit,
Payback period, Net Present Value, Internal rate of return etc. However,
these measures are often not appropriate for evaluating investments in
particularly innovative solutions.

! !253
 THE ENTERPRISE PERSPECTIVE

The above table indicates the broad approach required for investments in
solutions depending on two broad dimensions, viz., Costs and Benefits –
each being either soft meaning difficult to quantify exactly (or nebulous) or
hard where they can be precisely measured.

It is apparent that conventional financial approaches are most appropriate

only where both costs and benefits are measurable. In most other cases,
due weightage needs to be given to intangible benefits. Where the costs
are hard but benefits are not quite quantifiable, the best way to justify is
perhaps the savings in management decision making time and effort
required had the solution not been implemented. One example of such an
investment many a time could be the investment in security related
solutions. Such investments give the management a ‘peace of mind’ and
perhaps reduce the need for their intervention since security becomes an
inherent part of the business processes. On the other hand where the
benefits are measurable but the investment is a little open-ended, a more
portfolio type approach is called for. Here, the potential risk and reward
offered by a solution should be evaluated. Finally, there are those
situations where both costs and benefits are not exactly measurable. This
is akin to R&D or innovation where the innovator works on a broad set of
expected outcomes and a broad budget. Depending on management
commitment and the promise of a desired outcome, the management is
willing to perhaps continue funding the project for an extended period. The
outcomes in many R&D type investments are quite unpredictable but if

! !254
 THE ENTERPRISE PERSPECTIVE

they meet with success they may lead to the discovery of a turnaround or
strategic solution for the business.

11.12.2 Operational Feasibility

Many a time, while deciding on an IT investment, the sophistication of the

technology, the inherent attractiveness of the solution from the business or
application standpoint cloud the understanding related to the practicality of
the solution from an operational standpoint. This could lead to huge
investments in IT ending up in unused IT assets due to several operational
inconveniences and impracticalities. The operational issues could be very
situational and contextual for the organization and need to be sensed.

For example, a BA was once asked to design an end-to-end factory MIS.

The software requirements were captured adequately, the software was
developed and at the implementation stage several operational snags
cropped up. The software was implemented on machines kept in the open
in the factory since the management felt that it was improper to create an
exclusive air-conditioned environment for just the computer and its
operators. In addition, the computers were kept near the heat (45 Degrees
Centigrade) and dust of the manufacturing processes. To add to it, the
workers who were expected to enter the data did so with dirty hands. All
this resulted in frequent breakdowns of the machines leading to backlog of
data entry and corresponding flow line problems on the system since the
data was all interconnected. The question to ask is whether the air
conditioning or clean operational space is a requirement which a BA should
‘sense’ or be ‘told’ about?

Similarly, many handheld devices are recommended these days. One of the
operational issue with these handheld devices is the charging of the
battery. As long as the handheld device is assigned to a defined person and
he carries it with him and takes the responsibility of charging it there is
less problem. But if it is assigned to a central department who issues it for
a limited period for a given task, the onus of charging the battery falls on
the issuing department. This creates an operational bottleneck since this
department would perhaps have to charge 50, 110 or even more handheld
devices before issuing every day.

! !255
 THE ENTERPRISE PERSPECTIVE

The above are two simple examples of how operational feasibility needs to
be studied with great care and the requisite manual procedures associated
with the IT systems need to be considered will looking at the feasibility of
the solution.

11.12.3 Technical Feasibility

It is found from research, the most failures of IT systems is due to failure

in understanding complete requirements. Failure due to technology reasons
are much less because in many cases the solution is visualized keeping in
mind the available technology.

Typical technology related issues include – compatibility of hardware/

software platforms, lack of technical skills, integration issues with existing
infrastructure etc.

It can at times happen in a very innovative solution that the technology

required for implementing such as solution may not exist of if it does it has
limitations or it is simply too expensive at this point in time.

11.12.4 Schedule Feasibility

This refers to the possibility of completing the IT project within the given
schedule expected by the users and business planners. The constraints
could come from many directions. For example

• over ambitious and aggressive project plans,

• the business cycle (business ups and downs),

• the company’s own business success which affect motivation levels,

• the sheer timing during the year, for e.g., last quarter of a financial year
is a difficult time to get business users' support for implementing
anything new due to year-end target pressures,

• time zone and holiday lists particularly when the implementation is

spread across various locations with different time zones and different
holidays, and

! !256
 THE ENTERPRISE PERSPECTIVE

• other competing projects and the demand for any common resources.

Thus, BA should check the possibility and the upfront risk which an new IT
initiative may face due to some of the above factors making it difficult to
complete it during the given schedule.

11.13 SUMMARY

• Given the competitive business environment, it is important that each

business process and IT application be aligned to the critical issues of
business and contribute towards business success.

• Enterprise analysis is a means to ensure that the requirements reflect

not just user needs but the larger needs of the enterprise as a whole.

• A BA must therefore ask questions not merely related to the immediate

business process but also about the larger business context and the
internal organizational context within which the business process and IT
solution will have to perform.

• The Zachman's Framework provides an excellent overarching framework

for studying the enterprise context. Specific tools which are appropriate
to the level and the scope of the analysis should be used. These can
range from Business Strategy frameworks, to IT strategy frameworks to
specific modeling and diagramming tools.

• Finally, the assessment of the value which and IT initiative brings to the
organization needs to be assessed. The value of the solution must be
analysed. This is embodied in a Business Case.

• Feasibility of a proposed solution is an important component of a

Business Case. Feasibility must be assessed from a financial, technical,
operational and schedule point of view.

! !257
 THE ENTERPRISE PERSPECTIVE

11.14 SELF ASSESSMENT QUESTIONS

1. What are the importance and purpose of Enterprise Perspective?

2. Explain the various layers of Enterprise Analysis.

3. Describe the various tools and frameworks required for the analysis of
the enterprise.

4. Write a note on Zachman's Framework.

11.15 Multiple Choice QUESTIONS

1. It is important that a Business Analyst appreciates the fact that every

__________ is part of a larger organizational context which in turn is
part of a larger socio-scientific-economic ecosystem.
a. business process
b. IT application
c. Both A & B of the above
d. None of the above

2. Which of the following is a layer that we could divide the analysis of the
enterprise into one above the other for convenience?
a. The immediate layer which includes the process itself or the IT
application
b. Processes and IT applications with which it has to interact and
interface
c. The external competitive business environment
d. All of the above

3. __________ requires that a BA identify and understand the need from

the various stakeholders.
a. Defining the Business Need
b. Access Capability Gaps
c. Determine Solution Approach
d. Define Solution Scope

! !258
 THE ENTERPRISE PERSPECTIVE

4. Which of the following could be an expectation arising from these

Employees?
a. Should be able to quickly resolve employee queries.
b. The software should enable efficient computation of payroll.
c. The software should generate all the statutory reports such as
Provident fund etc.
d. May wish to see their earnings and deductions so far and estimated
for the year.

5. The Zachman's framework has two dimensions; the column represents

the various stakeholders and the rows represent the various
perspectives which each of these stakeholders may have.
a. True
b. False

Ans: 1 - (c), 2 - (d), 3 - (a), 4 - (d), 5 - (b)


! !259
 THE ENTERPRISE PERSPECTIVE

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture


! !260
 VISUALIZING IT BASED SOLUTIONS

Chapter 12
Visualizing IT Based Solutions
Objectives

After reading this chapter, you will be able to:

• To gain an overview of solution visualization

• To understand how scoping of a solution should be approached

• To understand in detail the The Use Case Method for solution

visualization

• To get an overview of processes described in the IIBA BoK pertaining to

Solutions

Structure

12.1 Solution Visualization

12.2 Steps towards Visualization of a Software Solution
12.3 The Use Case Method
12.4 Identifying Potential Users
12.5 Writing Use Cases
12.6 Steps to Write Use Case
12.7 An Example of Writing Use Case for an ATM
12.8 Tips about Use Cases
12.9 Use Case Based Estimation and Use Cases as a Means of Project
Planning
12.10 Use Cases and Usability
12.11 Benefits & Elements of Use Cases
12.12 Usability Mean: Looking Beyond ‘Ease of Use’
12.13 The IIBA Version 2.0 Perspective
12.14 Summary
12.15 Self Assessment Questions
12.16 Multiple Choice Questions

! !261
 VISUALIZING IT BASED SOLUTIONS

12.1 SOLUTION VISUALIZATION

The purpose of analysis is to understand the existing processes and

systems and more importantly the stated and unstated or tacit needs and
expectations about these processes and systems usually in today’s
changed context or for a future context – the latter being towards business
and process transformation.

Having understood the existing processes and the expectations, the

challenge lies in visualizing a solution which meets those needs and
expectations.

Visualization itself can be viewed as an abductive process which transforms

deep understanding of the existing process/systems and a wide variety of
perspectives and expectations of users into a solution which emerges in a
non-linear and abrupt fashion in the minds of the designer.

12.2 STEPS TOWARDS VISUALIZATION OF A SOFTWARE 


SOLUTION

However to make this process of visualization more systematic, the

following steps are suggested:

• Deep understanding of existing processes/systems

• Possible scoping of the solution by placing a Boundary around the

processes on a data flow diagram clearly demarcating the processes
included in the solution scope and the processes falling outside the
solution scope.

• Possible scoping of the solution by identifying the events/situations which

need to be included and those which need to be excluded from the
present solution scope.

• An outside in perspective – in terms of users and their use cases of the

proposed solution – this is done using the Use Case Method.

! !262
 VISUALIZING IT BASED SOLUTIONS

• Building early prototypes of the solution either on paper on screen which

can be used to both understand needs as well as visualize the final
solution.

!
Defining the Scope by Drawing a Boundary in a Data Flow Diagram

12.3 THE USE CASE METHOD

The use case method is a popular method among BAs for visualizing IT
solutions. The Use case method can be summarized as follows:

• Identify potential users (called Actors in formal terms) of the proposed

solution

• Identify the Use Cases of each user

• Visualize the actual dialog between the user and the system in executing
the use case

• Identify screens from the dialog

• Design the screens

• Build a screen based prototype

• Verify the prototype with the users

• Improve and finalize the visualization, i.e., the screen prototype

! !263
 VISUALIZING IT BASED SOLUTIONS

12.4 IDENTIFYING POTENTIAL USERS

Identifying users is not as trivial as it sounds. Missing out a user and

developing a solution can be potentially disastrous since it may be difficult
at a later date to accommodate the needs of such a missed out user.
Identifying users is also difficult because in many organizations there are
several indirect users of the system. Indirect users are those users who
may not directly interact with the system but may be beneficiary of
information and other outcomes of the system. For example, copies of a
report may be used by the executive assistant to the CEO for review. If
such a user is not obvious, the BA must put effort in identifying such users.

One way to identify such users is to send out a mail to all departments
announcing your intent to develop a particular solution covering a certain
business process and asking them about their expectations from such a
system.

In customer facing situations, direct and indirect users take a different

meaning. The customer at a ticket booking counter for example is the
indirect user of the system. The direct user is the customer service agent
who books the ticket on behalf of the customer using the software which
you provide to him.

The purpose of identifying direct and indirect users is that while the former
would require design of a dialog which best suits the users' background
and motivation for using the system, the latter would require the design of
an interaction suited to the agent of such a user as well as the supply of
output such as reports etc. which the indirect user seeks to have from the
system.

In today’s context, it is also important to consider the possibility of having

users who are external to the organization. This provides a means of self-
help to external stakeholders. For example when we send a packet via a
courier service, the courier company provides a facility for external
stakeholders like us to view the status of the packet. Providing such
visibility to an otherwise internal process is increasingly becoming a
common practice in many industries either for regulatory purposes or from
the standpoint of better customer self-help.

! !264
 VISUALIZING IT BASED SOLUTIONS

The BA must, therefore, always ask this question as whether there is any
external stakeholder who may expect something or can benefit from access
to the proposed solution.

In general, a Use Case does represent a significant business transaction

which a user would wish to undertake using the system. It also therefore
serves as a base for developing a program or a set of programs which
could meet a complete functionality for a user.

12.5 WRITING USE CASES

Writing a use case is akin to writing a dialog – in this case between a user
and the system. This is usually written first at a higher level in the
language easily understood by a user. Such use cases are known as
functional use cases. Gradually, once the technology associated with
implementing the use case is decided, the use case can be modified to
reflect technical level details in the interaction. Such use cases may or may
not be understood by lay end-users. They are therefore known as technical
use cases.

For most part, BAs writing functional use cases. However, since the nature
of the interface device such as website, desktop screen, smart phone, ATM
etc. is already known. Many BAs write use cases which include the use of
appropriate technical terms such as screen, home page etc. which are by
and large understood by end-users.

! !265
 VISUALIZING IT BASED SOLUTIONS

12.6 Steps to write use case

Use cases can be valuable tools for understanding a specific system's

ability to meet the needs of end users. When designing software or a
system, enhance your development efforts by thinking through practical
scenarios about product usefulness.

Here are Some Steps to Guide you through the Writing Process. These
Steps Are Divided in Three Parts

1. Defining the Purpose and Scope

2. Writing the Steps of a Use Case
3. Writing Valuable Use Cases

Part 1

Defining the Purpose and Scope

1. Write a Goal Statement

Write a sentence or two that briefly describes the primary goal of
implementing the technology or business process. Define specifically the
goals of the primary user of the system. A use case can be written to
describe the functionality of any business process or piece of software or
technology a business uses.

For example, you could write use cases about logging into a system,
managing an account or creating a new order.

2. Identify the Stakeholders

These are the people in the organization who care about the outcome of
the process. They may not be users in the process described by the use
case. But the system acts to satisfy their interests. List all of the
stakeholders, including their names and their interest with respect to the
operation of the system. Also, note any guarantees they expect from the
system.

For example, if you were writing a use case about how an ATM machine
functions, the stakeholders would include the bankers and the ATM owners.
They are not present when the user uses the ATM machine to withdraw
cash. However, they must be satisfied that systems are in place to verify

! !266
 VISUALIZING IT BASED SOLUTIONS

the amount of money in the user’s account before dispensing cash and to
create a log of transactions in the event of a dispute.

3. Define what is in and out of scope.

Specifically identify the system that is being evaluated and leave out
elements that are not part of this system. It can be useful in defining the
scope of a project to create a spread sheet containing an in/out list. Create
three columns. The left column lists any topic at all that might relate to the
system. The next two columns are titled “In” and “Out.” Go through the list
and determine which topics are in and which are out.

For example, if you were writing a use case implementing software to

create purchase orders, topics that would be “In” would include producing
reports about requests, merging requests to a purchase order, monitoring
deliveries, and new and existing system software. Topics that would be
“Out” would include creating invoices and non-software parts of the
system.

Part 2

Writing the Steps of a Use Case

1. Define the Elements of the use Case

All of these elements are required in every use case. Use cases accumulate
scenarios. They define how a user uses a system, what happens when the
system succeeds, and what happens when it fails. Each scenario describes
a procedure and what happens as each step progresses.

a. Users are all of the people who will engage in the activities described in
the use case. For example, if you are writing a use case for logging into
a software system, the users would be anyone who must log in.

b. Preconditions are those elements that must be in place prior to the start
of the use case. For example, users with permission to use the system
have been identified and entered into the system ahead of time, so the
system will recognize their usernames and passwords when entered.

c. The basic flow is the procedure the users use to achieve the primary
goal of the system and how the system responds to their actions. For

! !267
 VISUALIZING IT BASED SOLUTIONS

example, the user inputs a username and a password, and the system
allows the user in.

d. Alternate flows explain less common actions. For example, the user is
on a different computer and must answer a security question.

e. Exception flows detail what happens when the user cannot achieve the
goal. For example, the user inputs an invalid user name or password.

f. Post conditions are those elements that must be present when the use
case is completed. For example, the user can proceed to use the
software.

2. Define how the user will use the Technology or Process

Each thing the user does become a separate use case. The scope of a use
case is narrow. For example, if a company is implementing new software to
create purchase orders, you could write several use cases about this. One
use case might be about how users log in to the system. Another might be
about how to run requisition reports. List all of the functions of the new
technology or business process you are analyzing and write a use case for
each one.

3. Describe the Normal Course of Events for Each use Case

Outline everything the user does and how the technology or process
responds to those actions. In a use case about how users log into a
software system, the normal course of events would state that the user
enters a username and password. The software responds by verifying the
user and either granting or denying access to the system.

a. Alternate flows and exception flows are written to describe the actions
when there are obstacles to the goal.

b. If the user is denied access because the system didn’t recognize her
computer, she may be prompted to verify her identity by answering a
security question.

c. If the user inputs an invalid username or password, she may be

prompted to answer a security question and enter an e-mail address to
receive new log in information.

! !268
 VISUALIZING IT BASED SOLUTIONS

4. Repeat the Steps for all other Functions and Users

Write use cases for all of the other functions of the software or business
process. Identify the users for each function and write the steps for the
normal course of events. Explain contingencies for when the goal cannot be
achieved. For each step, explain how the system responds to the actions of
the user.

Part 3

Writing Valuable Use Cases

1. Capture what the Technology or Business Process Does

The use case explains the goal of the technology or process, not how the
technology functions. In other words, a use case about logging in to
software does not include how the code must be written or how the
technological components are connected. It simply focuses on what the
user needs to do and how the software responds.

a. Get the level of detail right. For example, if writing a use case about
implementing technology, don't exclude details about how the
software responds to users.

b. Alternatively, adding too much detail about how the software

functions reads more like system design implementation than a use
case.

2. Keep the use Case Primarily Textual

Use cases do not need to include complex flow charts or visual diagrams
that explain the process. Simple flow charts can often be used to clarify
information. However, the use case should be largely word-based. The
style of writing should be very simple so that others can read and
comprehend it without specific training.

3. Learn the most Relevant Details

Writing a good use case helps you learn exactly how a piece of software or
business process works. It educates you and the reader about the correct
use of applicable vocabulary. This way, you know you are not using

! !269
 VISUALIZING IT BASED SOLUTIONS

technological terms incorrectly or gratuitously. You can learn to discuss

technology and business processes in a way that is useful and valuable to
others in the business community.

12.7 AN EXAMPLE OF WRITING USE CASE FOR AN ATM

An ATM provides several possibilities to the bank customer. Each of these

uses are considered as use cases. For example a bank customer could
check the balance, withdraw cash, deposit cash, deposit a cheque, pay his
credit card dues etc. Each of these is a use case.

Writing a Use Case for Withdrawal of Cash from ATM

The use case for withdrawal of cash could be written as follows:

Use Case: Withdraw Cash from ATM

Author: XYZ

! !270
 VISUALIZING IT BASED SOLUTIONS

Date: …/.../...

Version: 1.0

Pre-condition: Customer's ATM card has been found ok

Normal Flow Customer ATM

Selects Withdraw Option Displays menu screen
Types amount Display Withdraw Screen
Customer types 'Y' Asks 'is Amount ok? Y/N'
Processes Request
Collects Cash Dispenses Cash
Customer says 'NO' Asks if more transaction Y/N.
Logs out customer, ejects card
Displays default screen

The above describes the normal flow – the alternate flows and exceptions
are shown below:

Alternate flows:

• Wishes to change withdrawal amount

- Suggested action could be to re-display the withdrawal screen

• Customer has more transactions

- Suggested action could be to show the menu screen

Exceptions

• Requested Amount > Balance

• Requested Amount > Cash in ATM

• Requested Amount > Cash limit for customer

• More than one withdrawal during the same day

• ATM fails – power, link etc.

! !271
 VISUALIZING IT BASED SOLUTIONS

• Error in disbursal of cash

• Customer forgets to take cash

• Customer asks for more transactions

12.8 TIPS ABOUT USE CASES

Please note the following aspects of a use case:

• The header block of a use case looks like the source code of a program.
It contains information to identify the use case. As the functionality of
the device is changed, the first place to implement the change is in the
Use case document and later make those changes in the actual program
corresponding to the use case.

• The pre-condition is a declaration about the state of the system and the
user at before the logic for the use case begins. Thus, in the case above,
the customer has already put his ATM card and the ATM has validated
him and the ATM is now ready to interact with him. This takes away the
need to describe the interaction related to validation. In fact, it may be a
better idea to write a separate use case on validating and logging in a
customer. This use case could be a prerequisite for all other transaction
use cases for the ATM customer and there would be no need to write it
many times.

• The dialog is usually written assuming the normal or usual choices which
a user could make. The other options are treated as alternate flows.
Thus, in the above example, the customer is assumed to select the
option ‘Amount is ok Y’ in most circumstances. The alternate flow is when
the customer wishes to change the amount to be withdrawn. These
alternate flows are documented separately.

• Exceptions are all possibilities of things which could go wrong during the
interaction. These could include failure of the device or some part of it,
user mistakes etc. These BA should then think about appropriate
solutions to these exceptions.

• As mentioned earlier since the ATM as a machine is known quite familiar

to us, the dialog written above tends to use terms such as screen,

! !272
 VISUALIZING IT BASED SOLUTIONS

keypad etc. since the technology is known. In case the nature of the
technology is unknown or we wish to consciously leave the choice of the
technology open at this point of time, we could prefer a technology
neutral description – for example we could say the ATM asks without
assuming the nature of the interface.

• Based on the above use case, the screens required to manage this
interaction which would also include prompts, messages, error messages
etc. can be identified and designed.

• A complete screen based prototype representing the interactions of all

the use cases in the system can be constructed. This serves as a tools to
facilitate further visualization of the final solution and a basis for
discussing the finer aspects of his requirements.

12.9 USE CASE BASED ESTIMATION AND USE CASES AS A

MEANS OF PROJECT PLANNING

As mentioned earlier, each use case represents a complete transaction

from a user’s point of view. Thus, a software solution may be considered to
be a set of such use cases. A project plan could be worked out based on
the business priority assigned to each use case. For example in a branch
accounting system for a FMCG company, the user may prefer to have the
invoice printing module to be implemented first, followed by the sales
analysis reports and then the receipts, collections and outstandings and
finally the inventory and other accounting transactions. Thus, the BA and
project manager can plan their delivery based on the above functionality
and priorities.

Use Cases can also be used as a means of estimation of effort and for
project sizing. Although this is not a perfect science as yet considerable
papers have been written on the same. The length of the use case and
complexity of the dialog in the use case can be the basis for estimation.
Hence, if a software solution has 50 use cases, they can be classified into
simple, medium and complex and accordingly effort could be estimated.
However, one limitation of use cases is that they represent only the
interactive elements of a system. There could several back-end updation
and other processes which are not visible in the use case dialog. This
makes estimation a little difficult.

! !273
 VISUALIZING IT BASED SOLUTIONS

12.10 USE CASES AND USABILITY

Increasingly, lay users interact with systems. Hence, the interaction and
the design of the device should be such that it not only makes it user-
friendly, but also easy to learn, to remember, is safe and secure. In
consumer devices, the design should be a step further and provide a
unique customer experience or delight through the aesthetic look and feel
and its other features.

12.11 Benefits and Elements of use case

Benefits and Elements of Use Cases

A use case is a written description of how users will perform tasks on your
website. It outlines, from a user’s point of view, a system’s behaviour as it
responds to a request. Each use case is represented as a sequence of
simple steps, beginning with a user's goal and ending when that goal is
fulfilled.

Benefits of Use Cases

Use cases add value because they help explain how the system should
behave and, in the process, they also help brainstorm what could go
wrong. They provide a list of goals and this list can be used to establish
the cost and complexity of the system. Project teams can then negotiate
which functions become requirements and are built.

1. It encourages designers to consider the characteristics of the intended

users, their tasks and their environment.

2. Usability issues can be explored at a very early stage in the design

process (before a commitment to code has been made).

3. Scenarios can help identify usability targets and likely task completion
times.

4. The method promotes developer buy-in and encourages a user-centred

design approach.

5. Scenarios can also be used to generate contexts for evaluation studies.

! !274
 VISUALIZING IT BASED SOLUTIONS

6. Only minimal resources are required to generate scenarios.

7. The technique can be used by developers with little or no human factors

expertise.

What Use Cases Include What Use Cases Do NOT Include

1 Who is using the website Implementation-specific language

2 What the user wants to do Details about the user interfaces or

screens.
3 The user's goal

4 The steps the user takes to

accomplish a particular task
5 How the website should respond to
an action

Elements of a Use Case

Depending on how in depth and complex you want or need to get, use
cases describe a combination of the following elements:

a. Actor: anyone or anything that performs a behavior (who is using the

system)

b. Stakeholder: someone or something with vested interests in the

behavior of the system under discussion (SUD)

c. Primary Actor: stakeholder who initiates an interaction with the

system to achieve a goal

d. Preconditions: what must be true or happen before and after the use
case runs.

e. Triggers: this is the event that causes the use case to be initiated.

f. Main success scenarios [Basic Flow]: use case in which nothing

goes wrong.

! !275
 VISUALIZING IT BASED SOLUTIONS

g. Alternative paths [Alternative Flow]: these paths are a variation on

the main theme. These exceptions are what happen when things go
wrong at the system level.

Method

An experienced moderator is recommended for the sessions in which the

scenario is explored.

1. Gather together the development team and other relevant stakeholders

under the direction of an experienced facilitator.

2. Identify intended users, their tasks and the general context. This
information will provide the basis for the scenarios to be created by the
development team.

3. Functionally decompose user goals into the operations needed to

achieve them.

4. Consider which activities should be performed by the user and which by

the computer.

5. Create an outline of the users' activities, goals and motivations for using
the system being designed, and the tasks they will perform.

6. To maintain design flexibility, scenarios should not specify what product

features are used.

7. Assign task time estimates and completion criteria as usability targets.

8. The session can be videotaped for later review or transcribed for wider
distribution.

9. The results from scenario building sessions can be used to plan user-
based evaluations.

! !276
 VISUALIZING IT BASED SOLUTIONS

Practical Guidelines

Try to generate scenarios to cover a wide range of situations, not just the
most common ones or those of most interest to the design team.

Try to include problem situations that will test the system concept, not just
straightforward scenarios.

Work through the scenarios fully and judge the system on that basis rather
than trying to change the system half way through.

Scenarios are most useful when produced early in development as specific

realistic and detailed examples of what a user would do, but without
making any reference what user interface features that would be used.

Scenarios can also be used later to explore how the interface would be
operated.

Next Steps
Use the scenarios as a basis for developing more specific usability
requirements.

12.12 Usability mean: looking beyond ‘ease of use’

The definition of usability is sometimes reduced to "easy to use," but this

over-simplifies the problem and provides little guidance for the user
interface designer. A more precise definition can be used to understand
user requirements, formulate usability goals and decide on the best
techniques for usability evaluations. An understanding of the five
characteristics of usability – effective, efficient, engaging, error tolerant,
easy to learn – helps guide the user-centered design tasks to the goal of
usable products.

! !277
 VISUALIZING IT BASED SOLUTIONS

Meanings of Usability

The word "usability" has become a catch-phrase for products that work
better for their users, but it is difficult to pin down just what people mean
by it is ‘usability.’

1. A result – software that is usable;

2. A process, also called user-centered design, for creating usable

software;

3. A set of techniques, such as contextual observation and usability

testing, used to achieve that result; or

4. A philosophy of designing to meet user needs.

These Different Meanings can be Described in Four Key

Requirements

1. Usability Means Thinking about How and Why People use a

Product.
Good technical writing, like good interaction design, focuses on user’s
goals. The first step in creating a usable product is understanding those
goals in the context of the user’s environment, task or work flow, and
letting these needs inform the design.

2. Usability Means Evaluation.

Usability relies on user-feedback through evaluation rather than simply
trusting the experience and expertise of the designer. Unlike conventional
software acceptance testing, usability evaluation involves watching real
people use a product (or prototype) and using what is learned to improve
the product.

3. Usability Means More than just "Ease of Use"

The 5 Es – efficient, effective, engaging, error tolerant and easy to learn –
describe the multi-faceted characteristics of usability. Interfaces are
evaluated against the combination of these characteristics which best
describe the user’s requirements for success and satisfaction.

! !278
 VISUALIZING IT BASED SOLUTIONS

4. Usability Means User-centered Design

Users are satisfied when an interface is user-centered – when their goals,
mental models, tasks and requirements are all met. The combination of
analysis, design and evaluation all approached starting from the user’s
point of view creates usable products.

Defining Ease of Use

The definition of usability in the ISO 9241 standard is:

"The extent to which a product can be used by specified users to achieve

specified goals with effectiveness, efficiency, and satisfaction in a specified
context of use”.

This definition can be expanded, and made more comprehensive, by

including five characteristics which must be met for the users of a product:

1. Effective
2. Efficient
3. Engaging
4. Error Tolerant
5. Easy to Learn

Effective

Effectiveness is the completeness and accuracy with which users achieve

specified goals. It is determined by looking at whether the user’s goals
were met successfully and whether all work is correct.

It can sometimes be difficult to separate effectiveness from efficiency, but

they are not the same. Efficiency is concerned primarily with how quickly a
task can be completed, while effectiveness considers how well the work is
done. Not all tasks require efficiency to be the first principle. For example,
in interfaces to financial systems (such as banking machines), effective use
of the system -- withdrawing the correct amount of money, selecting the
right account, making a transfer correctly – are more important than
marginal gains in speed. This assumes, of course, that the designer has
not created an annoying or over-controlling interface in the name of
effectiveness.

! !279
 VISUALIZING IT BASED SOLUTIONS

The quality of the user assistance built into the interface can have a strong
impact on effectiveness. The effectiveness of an interface often relies on
the presentation of choices in a way that is clearly understandable to the
user. The more informative an interface can be, the better users are able to
work in it without problems. Good interface terminology will be in the
user’s language and appropriate to the task.

Another design strategy to increase effectiveness is to offer redundant

navigation, especially for ambiguous situations. Although this may create
inefficient paths, it allows the user to work effectively by making more than
one choice lead to the correct outcome. This can be especially valuable in
interfaces which support infrequent users or those often unfamiliar with the
content domain.

Efficient

Efficiency can be described as the speed (with accuracy) in which users can
complete the tasks for which they use the product. ISO 9241 defines
efficiency as the total resources expended in a task. Efficiency metrics
include the number of clicks or keystrokes required or the total ‘time on
task’

It is important to be sure to define the task from the user’s point of view,
rather than as a single, granular interaction. For example, a knowledge
base which doled out small snippets of information might be very efficient
if each retrieval was considered one task, but inefficient when the entire
task of learning enough to answer a user’s question is considered.

Navigation design elements such as keyboard shortcuts, menus, links and

other buttons all have an impact on efficiency. When they are well-
designed, with clearly expressed actions, less time and effort are needed
for the user to make navigation and action choices.

Making the right choices for efficient use of the software depends on an
understanding of the users and how they prefer to work. For example, are
they likely to use the interface infrequently or to be habitual users who
might learn hidden controls and shortcuts? Do they use the keyboard,
mouse or other input devices? For example, keyboard shortcuts can be
extremely efficient for proficient users who work with the interface
intensively. If they are the primary interaction tool, they can slow down

! !280
 VISUALIZING IT BASED SOLUTIONS

users who are unfamiliar with them, or with the software. Similarly, an
interface structured around a set of hierarchical choices which may be the
best solution for one-time or infrequent users, might be frustratingly slow
as the only way of interacting with a frequently-used program.

Engaging

An interface is engaging if it is pleasant and satisfying to use. The visual

design is the most obvious element of this characteristic. The style of the
visual presentation, the number, functions and types of graphic images or
colors (especially on web sites), and the use of any multimedia elements
are all part of a user’s immediate reaction. But more subtle aspects of the
interface also affect how engaging it is. The design and readability of the
text can change a user’s relationship to the interface as the way
information is chunked for presentation. Equally important is the style of
the interaction which might range from a game-like simulation to a simple
menu-command system.

Like all usability characteristics, these qualities must be appropriate to the

tasks, users and context. The style of engagement that is satisfying for a
repetitive work tool is different than an e-commerce site. Even within the
same class of interfaces, different users may have widely divergent needs.
What is important is that the design meet the expectations and needs of
the people who must use the interface.

Error Tolerant

The ultimate goal is a system which has no errors. But, product developers
are human, and computer systems far from perfect, so errors may occur.
An error tolerant program is designed to prevent errors caused by the
user’s interaction, and to help the user in recovering from any errors that
do occur.

Note that a highly usable interface might treat error messages as part of
the interface, including not only a clear description of the problem, but also
direct links to choices for a path to correct the problem. Errors might also
occur because the designer did not predict the full range of ways that a
user might interact with the program. For example, if a required element is
missing simply presenting a way to fill in, that data can make an error
message look more like a wizard. If a choice is not made, it can be

! !281
 VISUALIZING IT BASED SOLUTIONS

presented without any punitive language. (However, it is important to note

that it is possible for an interface to become intrusive, or too actively
predictive.)

For those errors which are out of the control of the interface – system
failures or other disasters - take a lesson from flight attendants and
quietly, calmly guide the user through the process of helping the program
recover from the problem.

Some guidelines for preventing errors are:

a. Make it difficult to take incorrect actions. Design links and buttons to be

distinctive, use clear language, avoiding technical jargon, and be sure
that dependent fields or choices appear together.

b. Make it difficult to take invalid actions. Limit choices when possible to

those which are correct, provide clear examples for data entry, present
only appropriate navigation options.

c. Make it difficult to take irreversible actions. Provide the ability to back

track, provide means to undo or reverse actions, avoid dead-end
screens. Don’t indiscriminately use confirmations – users become
insensitive to them.

d. Plan for the unexpected. Allow for users to add new entries, take
exceptional routes through the interface or make choices you did not
predict. Be polite about "correcting" mistakes that may arise from this
lack of foresight.

Easy to Learn

One of the biggest objections to "usability" comes from people who fear
that it will be used to create products with a low barrier to entry, but which
are not powerful enough for long, sustained use.

But learning goes on for the life of the use of a product. Users may require
access to new functionality, expand their scope of work, explore new
options or change their own workflow or process. These changes might be
instigated by external changes in the environment or might be the result of
exploration within the interface.

! !282
 VISUALIZING IT BASED SOLUTIONS

An interface which is easy to learn allows users to build on their knowledge

without deliberate effort. This goes beyond a general helpfulness to include
built-in instruction for difficult or advanced tasks, access to just-in-time
training elements, connections to domain knowledge bases which are
critical to effective use.

Allow users to build on not only their prior knowledge of computer

systems, but also any interaction patterns they have learned through use
in a predictable way. Predictability is complementary to interface
consistency. A consistent interface ensures that terminology does not
change, that design elements and controls are placed in familiar locations
and that similar functions behave similarly. Predictability expands this to
place information or controls where the user expects it to be. This concept
has been discussed in connection with Palm Pilot design– and especially
important if you make an interface which goes beyond the boundaries of
simple platform design standards. Good use of predictability requires
careful user analysis and observation but can make new functions easy to
learn by providing controls where the user expects them to be.

Working With The Five E’s

Finding the right balance between the usability characteristics for the
specific design context is an important part of the user analysis. The
difference in emphasis is helpful in understanding distinctions between user
groups and in thinking through the implications for the interface design.
Two fictional examples show this at work.

A Corporate Human Resources (HR) Site

A typical web knowledge management system is used by employees to

look up information about their benefits, including options for leave,
medical benefits and scholarship support. These users might express the
following needs (in order of importance)

a. Effective: Users were most concerned that they had accurately found
all of the options which applied to them, and that they understood all
the implications of any choice they made.

b. Easy to Learn: The site used infrequently. When they did visit it, users
needed information about difficult life events, often under personal

! !283
 VISUALIZING IT BASED SOLUTIONS

stress. Users did not expect to gain any mastery of the site and wanted
guidance through any procedures.

c. Efficient: The previous HR system involved completing paper forms and

waiting for an appointment with a specialist – a process that often took
several days. Users wanted to get answers more quickly than that. They
were willing to spend a reasonable amount of time on the site when it
produced answers. They were willing to tolerate minor delays while
forms were processed when they got results within minutes.

d. Engaging: Users wanted a pleasant experience, but were most

concerned with a presentation of the material they could understand
easily than with "whiz-bang" features

e. Error Tolerant: They assumed that they could trust the site to make
calculations correctly. This characteristic was last in their priority,
assuming that the system would not make mistakes.

A Conference Registration System

Contrast the previous example with users of an online conference

registration system. These users (also fictional) will use this site once but
are spending a relatively large sum to register. Their experience of the
conference itself may depend on the success of the registration system.

a. Efficient: The users saw registration as a simple task and were not
willing to spend much time on it, especially compared to filling in a
paper form.

b. Error Tolerant: They were concerned that the system might make
mistakes in processing their choices, and wanted good validation,
confirmation and error notification during the process. They also wanted
to be sure that they could change their minds without needing to start
the process over.

c. Engaging: Some users expected to have options or features explained

during the registration process. All wanted clear, understandable
presentation, citing difficult paper and online forms they had
encountered in the past as problems.

! !284
 VISUALIZING IT BASED SOLUTIONS

d. Effective: They assumed that they would be registered correctly. This

characteristic is placed lower on the list because of user emphasis on
error handling to prevent problems.

e. Easy to Learn: Because they saw the task as simple, users assumed
that they would be able to complete it without assistance.

Thinking though user’s Perspective

Although the examples above are fictional, they illustrate one way to use
the five usability characteristics to understand the user requirements and
mental model for a task. By breaking down the generalized concept of
usability into specific areas, the users can be understood in a multi-
dimensional way, and usability becomes more than a simple requirement
that the program be "easy to use.”

A useful exercise is to write a statement for each characteristic for each

user group. These statements can be written in the third person (as above)
or can be turned into first person statements as a way of capturing a sense
of the emotion or tone surrounding each statement. Where direct quotes
from users are available, they add richness and credibility. Sometimes the
directness of the quote or the diversity of users that the quotes show can
be helpful in making users come alive for both designers and developers.

There are several benefits of this exercise. The first is to help specify the
user groups. When a group of statements seems correct for one user, but
not for another, this may be exposing important differences in user
requirements. Another is to force the user analyst into a clear and concise
expression of user needs. Finally, it can be a useful tool to build a
consensus within a team on the user analysis.

This exercise can be done at the beginning of a project, even before any
user analysis or observation has been done. In this version, the work
focuses on the group’s current understanding of users. Points of
disagreement indicate a need for better understanding of users. Points of
agreement can be confirmed through analysis. The set of statements for
each identified target user group serves as a benchmark for future work.
After user analysis, the exercise is repeated. Places where the team’s initial
version differs significantly from the post-analysis version, it needs careful
attention to be sure the implications for the design are understood.

! !285
 VISUALIZING IT BASED SOLUTIONS

Connection to Usability Goals

Usability goals can also be tied to the five characteristics. Each user need
statement can be turned into a usability goal or requirements. For
example, requirements can be specified with a range of acceptable values,
such as:

1. Efficient: "The user will be able to successfully complete the

registration in under 3 minutes"

2. Effective: "Less than 5% of the registrations will have errors, omissions

or inconsistencies requiring a follow-up contact by the staff."

3. Engaging: "At least 80% of employees will express comfort with using
the online system rather than visiting the HR office."

4. Error Tolerant: "The system will validate all housing, meal and tutorial
choices and allow the user to confirm pricing for these options before
completing the registration."

5. Easy to Learn: "Users will be able to successfully complete a benefits

calculation without needing any external instruction or help screens."

One aspect of transforming typical user statements into usability goals

must be stressed. Users often place a low importance on characteristics
which they simply expect to be well represented in the interface. An
example of this is the assumption by the conference registration system
user that the task was simple enough that ease of learning was not a
critical factor. In creating usability goals, the emphasis must be reversed,
with a priority placed on meeting those base-line assumptions.

An interface that fails in this will not be usable, even if it meets other
requirements. In fact, this basic failure will likely cause failures in other
areas. For example, if the registration is difficult to learn, users are likely to
take longer to complete the task, exceeding efficiency targets, and be less
accurate, failing in effectiveness.


! !286
 VISUALIZING IT BASED SOLUTIONS

Planning Usability Evaluations

Understanding specific targets for these usability goals also helps plan
usability evaluation. The testing techniques selected may vary, depending
on which of the characteristics you are most interested in. Some can be
tested with early prototypes or even paper mockups, but others require
working software or very high-fidelity prototypes.

Characteristic Type of Usability Evaluation

Time (or count clicks or page views) realistic tasks. Must use
Efficient
working versions of the software and plausible sample data.
Evaluate tasks for how accurately they were completed, and
Effective
how often they produce errors.

User satisfaction surveys or qualitative interviews can gauge

Engaging
user acceptance and attitudes towards the software.
Include task scenarios with potential problems in test use
Error Tolerant
scenarios

Control how much instruction is given to test participants, or

Easy to Learn carefully recruit users with different levels of domain
knowledge and experience.

In planning usability evaluations, be sure that the most important

characteristics are included, and tested in a realistic way.

Conclusion

Usability and user-centered design are iterative. The work proceeds in a

cycle of hypothesis and evaluation, with a picture of users and design
solutions to meet their needs building in richness and completeness with
each iteration.

The five E’s (effective, efficient, engaging, error tolerant, easy to learn)
provide the practitioner with a set of characteristics which can be used to
organize and analyze information from users. They offer trace-ability from
initial information-gathering through requirements setting and finally in
evaluation. This might allow the understanding of the specific needs around
each characteristic to grow or be an opportunity to confirm whether the
user requirements were chosen correctly in the early stages of the project.

! !287
 VISUALIZING IT BASED SOLUTIONS

In either case, they let you go beyond "ease of use" in a practical way and
help make it easier to make products more usable.

12.13 THE IIBA VERSION 2.0 PERSPECTIVE

The IIBA version 2.0 describes the various processes associated with
solutions. Some of these include:

• Define needs
• Define solution scope
• Define approach to solution
• Solution verification
• Solution validation

The IIBA version 2.0 does not directly deal with the topic of Solution
visualization perhaps rightly so because this could be within the purview of
the software designer and not the BA. However, in practice, it is found that
since the BA is the only person travelling to client location he has the best
opportunity to bounce off thoughts about the solution with the user. Hence
as described in the chapter on requirements gathering, it may be ideal to
model the requirements while still on site and develop a vision for the
solution — parts of which could be discussed with the user along with the
requirements. This would serve as a good input for the designer who works
offshore.

The IIBA version 2, however, does lay emphasis on solution verification and
validation. This is usually done with the help of test cases identified during
the requirement analysis phase where sample transactions which can be
used as acceptance criteria are identified. Also the documented
requirements serve as a basis for verifying and validating the solution.

Likewise, Documented Use Cases can be an effective way of conducting

functional test on a solution.

In large complex applications, it is usually a practice to populate all the

data from real life for a limited period say month or quarter. The direct
end-users could actually enter real-life transactions on the new system in
parallel to their existing system. The success of these transactions could
signal a possible acceptance of the solution.

! !288
 VISUALIZING IT BASED SOLUTIONS

12.14 SUMMARY

• After studying a business process from various perspectives such as flow,

object-event, security, human factor etc., the BA must model this
information and synthesize. Visualization is a about imagining a new
process of IT solution on the basis of deep understanding of functionality
required and insights derived from the as-is process.

• Visualizing solutions can be systematized – but it is equally a creative

and cognitive process

• Use Case is a simple yet effective method for visualizing particularly an

interactive software solution. It relies on the identifying potential direct
and indirect users of a proposed solution and the use case which they
would like to have.

• Writing a Use Case is an exercise in dialog writing – a dialog between the

user and the system.

• There are several best practices for writing use cases.

• Use cases can be used to build prototypes, clarify requirements, as a

basis for testing a solution, i.e., verifying and validation of a solution
once it is ready and as a basis for estimation and planning a project.

• Since Use cases are converted into interactive solutions, it is important

that all aspects of Human factors and Usability are brought into design of
such use cases – giving a great user experience.

12.15 SELF ASSESSMENT QUESTIONS

1. What is solution visualization? What are the step towards visualization

of a software solution?

2. Describe in brief the Use Case Method for solution visualization.

3. Write a brief note on the IIBA version 2.0 perspective.

! !289
 VISUALIZING IT BASED SOLUTIONS

12.16 Multiple choice QUESTIONS

1. Having understood the existing processes and the expectations, the

challenge lies in __________ a solution which meets those needs and
expectations.
a. Visualizing
b. Imagining
c. finalizing
d. transforming

2. Which of the following is a step suggested to make the process of

visualization more systematic?
a. Deep understanding of existing processes/systems
b. An outside in perspective – in terms of users and their use cases of
the proposed solution – this is done using the Use Case Method.
c. Building early prototypes of the solution either on paper on screen
which can be used to both understand needs as well as visualize the
final solution.
d. All of the above

3. Indirect users are those users who may directly interact with the system
but may not be beneficiary of information and other outcomes of the
system.
a. True
b. False

4. Once, the technology associated with implementing the use case is

decided, the use case can be modified to reflect __________ level
details in the interaction.
a. statistical
b. mechanical
c. functional
d. technical

5. Which of the following includes the various processes associated with a

solution that describes the IIBA version 2.0?
a. Define needs
b. Define solution scope
c. Both A & B of the above
d. None of the above

! !290
 VISUALIZING IT BASED SOLUTIONS

Ans: 1 - (a), 2 - (d), 3 - (b), 4 - (d), 5 - (c)


! !291
 VISUALIZING IT BASED SOLUTIONS

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture


! !292
 REQUIREMENTS DOCUMENTATION

Chapter 13
Requirements Documentation
Objectives

After reading this chapter, you will be able to:

• The appreciate the need and benefits of requirements documentation

• To understand the characteristics of good documentation

• To learn what and how to document

– functional and non-functional aspects
– the IEEE standard for documentation

• A few points for making documentation more usable

Structure

13.1 Need and Benefits of Requirements Documentation

13.2 Characteristics of a Good Requirements Documentation

13.3 The Structure of Business Analysis Documents

13.4 What and How to Document a Requirement?

13.5 Functional Requirements Document

13.6 Why Non-Functional Requirements Matter?

13.7 The IIBA Perspective

13.8 Caselet on Requirements Documentation with Solution

13.9 Summary

13.10 Self Assessment Questions

13.11 Multiple Choice Questions

! !293
 REQUIREMENTS DOCUMENTATION

13.1 NEED AND BENEFITS OF REQUIREMENTS

DOCUMENTATION

There are several reasons and benefits of documenting requirements.

Some of these are:

• It helps in ensuring that all stakeholders' needs, requirements and

expectations have been represented and captured.

• It helps in clarifying requirements with end-users.

• Since many processes are complex and difficult for a BA to remember, it

is better to document the scope and requirements to ensure that the
BA does not miss out on some features.

• It ensures that the requirements expressed are taken forward into the
design of the solution.

• In a large project team, there is always a risk of missing out on some

commitment made to a client – the single consolidated requirements
documents minimizes the chances of missing out on any of the
requirements.

• Once the requirement is baselined, it serves as a touch stone for all

further work. Particularly where there is some dispute as to whether a
user’s request is a change or is part of the original requirement can be
resolved by a well written baselined requirement document

• It helps in verifying and validating the solution.

• It helps in tracing back a feature in the solution to the originating

requirement and even the stakeholder who suggested that requirement.
This could help in conducting an impact analysis of any proposed change
in an existing solution and for subsequent, maintenance of the solution

• From an overall project management standpoint, it helps track changes

and derive useful metrics about requirements changes and scope creep
in the project. Such data improves future estimation and project
planning.

! !294
 REQUIREMENTS DOCUMENTATION

• Requirements documents can also serve as a reference for any similar

project that a company may plan to undertake.

13.2 CHARACTERISTICS OF A GOOD REQUIREMENTS

DOCUMENTATION

Some of the characteristics of a good documentation are:

• It is precise and concise.

• It is readable.

• Each requirement should be functionally complete and distinct from

others.

• It is unambiguous and clear.

• It does not have any vague words such as ‘some’, ‘few’, ‘etc.’ but actually
lists out what needs to be enumerated.

• It is traceable – both forward from requirement source to solution feature

and reverse traceable from solution feature back to the source of the
requirement.

13.3 The Structure of Business Analysis Documents

The structure of business analysis documents isn't a commonly discussed

topic. This chpter will show what documents are produced by a BA and the
main sections they contain.

These are the main documents produced by a BA over the course of a

project:

a. Current state analysis document

b. Project vision document

c. Solution vision document

! !295
 REQUIREMENTS DOCUMENTATION

d. Business requirements document

e. Business process design document

f. Use case model document

g. Use case specification document

h. System-wide requirements document

i. Solution glossary

The diagram below shows the attributes common to all documents:

! 


! !296
 REQUIREMENTS DOCUMENTATION

a. Current State Analysis: Once a project has been mandated and the
Project Initiation Document (PID) is drafted, a business analyst can
start to work on requirements gathering. In my experience the best way
to tackle this task is to start from current state analysis. It helps
understand the business need, primary pain points, business processes
affected, the stakeholders involved in these processes, and so on.

The area of the current state analysis is illustrated below:

!
The main purpose of the analysis is to present the “AS IS” state: the
existing business context, background, business functions and existing
business processes, and finally stakeholders involved in these business
processes. Depending on the project nature, some components of the
underlying infrastructure can be included in the document as well.

A Current State Analysis document lists the key pain points within the
identified business processes and tasks within them and highlights the
areas where a change is expected.

The last section of the document is about presenting recommendations.

It recaps the key findings and lists the key changes expected. Any
caveats should be presented here as well.

The content structure of the Current State Analysis document is

presented below:

! !297
 REQUIREMENTS DOCUMENTATION

This document serves as a foundation or a reference point for other

artifacts produced by a business analyst. The other documents will be
discussed in the following points.

b. Project Vision: The Project Vision is a document which is shared by a

project manager and business analyst. They work together to outline
the problem statement, determine the desired state, describe the
criteria of business acceptance of the deliverables and how project
success will be measured. The document contains a section with
stakeholder analysis which shows all the parties involved along with
their responsibilities and needs:

The business analyst adds the high-level requirements which are within
the scope of the project and marks each requirement as compulsory or
optional. To clearly define the project scope and avoid ambiguity, all out-
of-scope requirements are also listed at the end of the section.

Based on the results of the current state analysis, the business analyst
describes the current business context, the key business processes and
services used to support them. After that the required changes are
mapped to the current business context. It can be a good idea to present

! !298
 REQUIREMENTS DOCUMENTATION

this mapping as a diagram for easy communication of the proposed

changes to the business stakeholders.

c. Solution Vision: Once the Project Vision document is approved, the

preparation of the Solution Vision document starts.

First, the business analyst recaps the problem statement from the
Project Vision artifacts. The solution statement describes the target
audience of the solution, what will be satisfied by the solution and what
the key benefits will be. The statement of differentiation of the solution
from possible alternative options is added as a conclusive point in
positioning of the solution.

The document describes stakeholders within the target audience along

with their roles using a RACI (Responsible, Accountable, Consulted and
Informed) matrix.

The main part of a Solution Vision is a detailed section devoted to the

solution capabilities comprised of both functional and non-functional
features, with priorities given by the business stakeholders.

The next section presents the business context in its future "to be" state.
It's a good idea to include a diagram illustrating the key changes and
additions to the existing state, as well as a brief narrative to clarify the
proposed changes.

Similarly, to the Project Vision document, the features that are out of
scope are clearly listed in the last section to make sure everyone is on
the same page with regards to what will be implemented.

! !299
 REQUIREMENTS DOCUMENTATION

d. Business Requirements: This document focuses on providing details

about the current processes and gives enough information to describe
the business problem and how it fits into the scope of the project. This
section reiterates the findings of the Current State Analysis document,
however here they are aligned with the project objectives.

The business requirements that are going to be fulfilled by the solution,

are listed in the “In Scope” section. Business rules that apply to the
described requirements are presented in a separate section. This
approach simplifies the confirmation of the rules with business
stakeholders. Any assumptions and dependencies identified in relation to
the business requirements are to be listed in the appropriate section. The
proposed changes to stakeholder roles, new or modified business
processes and business services that support them are presented in the
last section.

e. Business Process Design: This document focuses on the scope of

changes to business processes, providing details about the current
business context, existing business processes, and stakeholders
involved in these business processes.

It also describes the future state: the proposed business processes and
the “to be” information environment. The new processes are
accompanied with narratives to facilitate communication of the proposed

! !300
 REQUIREMENTS DOCUMENTATION

changes to stakeholders and business end users. This “as is” section
reiterates the findings of the Current State Analysis document, however
here they are aligned with the changes to supporting business services.

Any assumptions and dependencies identified in relation and changes to

the business processes are listed in the appropriate section.

f. Use Case Model: The Use Case Model lists all the scenarios for using
the solution required by the business stakeholders. It is useful to
describe the solution as a set of functional areas and group the
scenarios as per functional area. Such an approach allows to use this
document more efficiently in communication with the business
stakeholders as they can easily refer to the sections of their interest.

The model lists all possible scenarios in scope, their brief summary,
actors involved in each scenario, frequency of use, triggering events and
the two possible outcomes – success and failure.

One of the key attributes of the scenarios is a reference to the high-level

requirements and required capabilities which allows establishing
traceability.

Note: when making changes to Use Case Specifications, do not forget to

update the Use Case Model document accordingly.

g. Use Case Specification A Use Case Specification document presents

more detailed information about the use cases in the Use Case Model
document.

! !301
 REQUIREMENTS DOCUMENTATION

Each specification includes:

1. Brief use case overview

2. Reference to the functional area
3. Preconditions
4. Actors involved
5. Main flow
6. Alternative flows
7. Exception handling flows
8. Functional requirements for the solution
9. Traceability to the business requirements
10. Market or business rules applicable to the scenario
11. User interface, controls and data

h. System-Wide Requirements: This document is prepared when the

Business Requirements, Use Case Model and Use Case Specifications are
complete. The main purpose of the document is to present a
“qualitative” side of the solution.

! !302
 REQUIREMENTS DOCUMENTATION

The “Load patterns” section is the most interesting as it illustrates how

the solution is expected to be used during a business day. This
information gives good insight into business requirements from the
“non-functional” perspective and helps clarify the business requirements
where required. As solutions are often based on information technology,
some attention should be given to solution resilience.

Disaster mitigation approaches and solution recovery requirements play

a major role here. It is a rare case nowadays that a solution is
completely new. The common practice is to integrate the solution into
the existing business environment. The system-wide requirements
document describes the interfaces with internal and external systems
and solutions, the data flowing between them, its formats and data
elements. Where the solution should interface with external systems,
samples of data must be presented in appendices.

Apart from business reporting capabilities, the solution must provide

reporting capabilities for monitoring how the solution operates. These
reports are listed in the last section of the document.

i. Solution Glossary: Business stakeholders often use terms and jargon

in their communication. To get up to speed with this terminology (you
can be quite new to it), the Solution Glossary document is used. It helps
establish common terminology for the project team and key
stakeholders, and for use within the solution. The structure of this
document is simple:

It's a good practice to divide the solution into functional areas. These
functional areas serve as small knowledge domains for the stakeholders
involved in the project. This document serves as a reference point for all
the previously discussed documents.

! !303
 REQUIREMENTS DOCUMENTATION

13.4 WHAT AND HOW TO DOCUMENT A REQUIREMENT?

The challenge with documentation is what to document and at what level

of detail.

The IEEE has defined a standard for requirements documentation.

According to this standard, requirements document for a software solution
should include the following:

• Introduction and objectives

- Broad overview of the process being discussed

- The problems with the as-is process/system

- The objectives of the initiative

- A broad overview of the solution

• Functional Requirements

- Functional requirements refer to those which correspond to a basic

capability required expected of the solution to meet a specific
business requirement.

- The functional requirements expressed as input, process and output.

This would corresponds to each event associated with each business
object as was discussed in the object-event method. Thus, for
example, in an student attendance system various situations could
occur such as:

❖ Student comes early

❖ Student comes late
❖ Student is absent
❖ Student comes late due to authorized official work
❖ Student goes early due to authorized official work
❖ Student Is absent but on official duty elsewhere

- Each of these situations corresponds to a functional requirement.

These events, the inputs , process of handling the event and the

! !304
 REQUIREMENTS DOCUMENTATION

output must be documented. Thus, in a system which is expected to

have 20 business level objects, each with on an average about 10
such events/situations/ behaviours we would have to describe 200
functional requirements.

• Non-functional Requirements

These are requirements which do not relate to features for delivering

basic functions of the process. However, they are more qualitative and
represent indirect expectations of one or more of the stakeholders or the
organization as a whole for whom the solution is being developed.
Examples of non-functional requirements could include broad
expectations about quality of software code, or documentation, about
hardware/software environment on which it should be deployed, security,
user characteristics, standards for coding, standards for documentation,
corporate group level standards of any kind etc. Sometimes even broad
expectations about performance could also be considered as a non-
functional requirement.

In order to make the documentation useful, each requirement should have:

• A Unique identifier – a structured numbering scheme

• Source of the requirement
• A broad description of the requirement – and the situation or event
associated with it
• A detailed description in the form of input-process-output.

Further from the standpoint of tracking the requirement, it may be useful

to add information such as status of the requirement in terms of its
approval status and implementation in the solution.

! !305
 REQUIREMENTS DOCUMENTATION

13.5 Functional Requirements Document

The Functional Requirements Document (FRD) is a formal statement of an

application’s functional requirements. It serves the same purpose as a
contract. Here, the developers agree to provide the capabilities specified.
The client agrees to find the product satisfactory if it provides the
capabilities specified in the FRD.

Functional requirements capture the intended behaviour of the system.

This behaviour may be expressed as services, tasks or functions the
system is required to perform. The document should be tailored to fit a
particular project’s need. They define things such as system calculations,
data manipulation and processing, user interface and interaction with the
application.

The Functional Requirements Document (FRD) has the following

Characteristics −

1. It demonstrates that the application provides value in terms of the

business objectives and business processes in the next few years.

2. It contains a complete set of requirements for the application. It leaves

no room for anyone to assume anything which is not stated in the FRD.

3. It is solution independent. The ERD is a statement of what the

application is to do— not of how it works. The FRD does not commit the
developers to a design. For that reason, any reference to the use of a
specific technology is entirely inappropriate in an FRD.

The functional requirement should include the following −

1. Descriptions of data to be entered into the system

2. Descriptions of operations performed by each screen
3. Descriptions of work-flows performed by the system
4. Descriptions of system reports or other outputs
5. Who can enter the data into the system?
6. How the system meets applicable regulatory requirements?

! !306
 REQUIREMENTS DOCUMENTATION

The functional specification is designed to be read by a general audience.

Readers should understand the system, but no technical knowledge should
be required to understand this document.

Functional Requirements Deliverables

A Business Requirements Document (BRD) consists of −

1. Functional Requirements: A document containing detailed

requirements for the system being developed. These requirements
define the functional features and capabilities that a system must
possess. Be sure that any assumptions and constraints identified during
the Business Case are still accurate and up to date.

2. Business Process Model: A model of the current state of the process

("as is" model) or a concept of what the process should become ("to be"
model)

3. System Context Diagram: A Context Diagram shows the system

boundaries, external and internal entities that interact with the system,
and the relevant data flows between these external and internal
entities.

4. Flow Diagrams (as-is or to-be): Diagrams graphically depict the

sequence of operations or the movement of data for a business process.
One or more flow diagrams are included depending on the complexity of
the model.

5. Business Rules and Data Requirements: Business rules define or

constrain some aspects of the business and are used to define data
constraints, default values, value ranges, cardinality, data types,
calculations, exceptions, required elements and the relational integrity
of the data.

6. Data Models: Entity Relationship Diagrams, Entity Descriptions, Class

Diagrams

7. Conceptual Model: High level display of different entities for a

business function and how they relate to one another.

! !307
 REQUIREMENTS DOCUMENTATION

8. Logical Model: Illustrates the specific entities, attributes and

relationships involved in a business function and represents all the
definitions, characteristics, and relationships of data in a business,
technical, or conceptual environment.

9. Data Dictionary and Glossary: A collection of detailed information on

the data elements, fields, tables and other entities that comprise the
data model underlying a database or similar data management system.

10.Stakeholder Map: Identifies all stakeholders who are affected by the

proposed change and their influence/authority level for requirements.
This document is developed in the origination phase of the Project
Management Methodology (PMM) and is owned by the Project Manager
but needs to be updated by the project team as new/changed
Stakeholders are identified throughout the process.

11.Requirements Traceability Matrix: A table that illustrates logical

links between individual functional requirements and other types of
system artifacts, including other Functional Requirements, Use-cases/
User Stories, Architecture and Design Elements, Code Modules, Test
Cases, and Business Rules.

13.6 Why Non-Functional Requirements Matter

If you look at the BABOK Guide’s definition of the term non-functional

requirements you will notice that it is described as a type of Solution
Requirements. This is because non-functional requirements are the
requirements that describe the underlying qualities of a system rather than
what specific functions we expect the system needs to be able to perform.

Let’s now Have a Look at the Main Categories of Non-functional

Requirements:

1. Compliance: Compliance non-functional requirements cover the broad

range of specifications to ensure that the solution conforms to rules,
such as a specification, policy, standard or law set by both internal and
external parties to the organisation.

! !308
 REQUIREMENTS DOCUMENTATION

Example Compliance Non-Functional Requirement: “All application data

must be stored in compliance with the Information Security Data Storage
Protection standards.”

2. Performance: Performance non-functional requirements cover the

system qualities that are concerned with the speed of operation of a
system; how well a function is to be executed and/or achieved.

Example Performance Non-Functional Requirement: “The solution must

provide for a current user base of 5,900 (as at Jan 2015), with expected
number of users to increase by 2.37% each month for the next 24
months.”

3. Reliability: Reliability non-functional requirements cover the system

qualities concerned with the ability of a system to perform its required
functions under stated conditions for a specific period of time.

Example Reliability Non-Functional Requirement: “The solution shall be

operational 24 hours a day, 7 days a week”

4. Security: Security non-functional requirements cover the system

qualities concerned with ensuring the safety, confidentiality and integrity
of the total solution; includes software, hardware, communications, user
access and devices.

Example Security Non-Functional Requirement: “The system must

authenticate a user via a user login ID and password.”

5. Support-ability: Support-ability non-functional requirements cover the

system qualities concerned with the ease of changes to the system after
deployment. Also describes the ease with which the system can be
learned or used.

Example Support-ability Non-Functional Requirement: “All servers are

required to have vendor support.”

6. Usability: Usability non-functional requirements cover the system

qualities concerned with the ease with which a user can learn to
operate, prepare inputs for, and interpret outputs of a system or

! !309
 REQUIREMENTS DOCUMENTATION

component. These non-functional requirements measure a products’

potential to accomplish the goals of the user.

Example Usability Non-functional Requirement: “The application

shall be usable by persons with auditory disabilities.”

Ask for Help with Non-functional Requirements

If you are a Business Analyst that doesn’t have a very technical

background and are unfamiliar with non-functional requirements, go and
find a technical business analyst or solutions architect to help you.
Although non-functional requirements gathering can be quite daunting if
this is unfamiliar territory, you should be able to find a previous set of
non-functional requirements that was created by someone else for you to
reference.

Why Non-Functional Requirements Matter

It is always thought that if the ICT Department delivered a system that

satisfied all the functional requirements of users, one could call it a
successful system. It was thought that if the system worked exactly the
way stakeholders said they wanted it to work; everyone could call it a day.
But you can imagine the reaction when this view was challenged. The
author argued that you could build a system that has all the functionalities
in the world if it’s not used however, the system is a failure.

User adoption is one of the main factors that influence project

success. This does not imply that the adoption of a system automatically
makes a project successful. It’s possible to have a widely adopted system
and still have project failure. It all depends on all the other factors you
consider in defining success. Success can only be clearly determined if it is
measured using clearly defined criteria, outlined at the beginning of the
project.

With that said, what's the point of building a system no one wants to use?
Until analysts can specify systems that stakeholders can use effectively,
one that exceeds their expectations (functional requirements), they are like
architects building houses no one wants to live in.

! !310
 REQUIREMENTS DOCUMENTATION

Analysts should go beyond what stakeholders say and explore non-

functional requirements (NFRs) at the beginning of every project when
such requirements can still be accommodated. It’s better to start thinking
about security or performance long before the code is written, or the
software is bought instead of waiting till the system is ready. At this point,
it become exceedingly costly.

Users rarely request for non-functional requirements but they implicitly

expect these features to be part of any system they use. For example, a
user could easily say, “I want the system to store different formulae for
calculations". Rarely will you hear them say, “the system should be able to
perform calculations on 1000 records in 20s”, even though they expect it to
work this way.

Non-Functional Requirements represent the constraints placed on a system

and are an essential category of requirements that should not be
overlooked. They have a strong impact on user experience and can
influence whether the system is adopted or not. They are thus, essential to
producing good quality software that can stand the test of time.

Some recommend that non-functional requirements be treated like other

requirements by sticking them on index cards and using them as a basis
for lightweight planning. Others recommend writing them in the form
of user stories. Regardless of the tools or techniques used for their
documentation, non-functional requirements should be defined precisely,
stating the specific measurements (test criteria) for determining their
successful implementation.

According to BABOK V2, NFRs may be developed for the user community or
the developer community. While users worry about usability, learnability
and reliability, the developer community are mostly concerned about
scalability, maintainability and the like.

! !311
 REQUIREMENTS DOCUMENTATION

What has Been your Experience with Non-functional Requirements?

Non-functional Requirements – Help, these are too Hard to do!

Non-functional requirements are the black sheep of the requirements world

because it is more technical in nature and is the types of requirements you
need but don’t necessarily ever see or directly experience as an end user.
This is why non-functional requirements are often neglected when it comes
to requirements analysis and the documentation stage of any project.

13.7 THE IIBA PERSPECTIVE

The IIBA BoK version 2.0 covers various types of documentation

throughout the Business Analysis exercise – requirements document being
one of them. It also covers other outputs of business analysis such as:

• Business Case (covered in Enterprise Analysis and BA Planning and

Monitoring Process)

• Business Needs (under BA Planning and Monitoring)

• Priorities requirements (Requirements Management) – which is what this

chapter described
• Requirements Re-use – where requirements documents can be reused
either for solution maintenance or for other projects which have similar
requirements.

It also emphasizes the packaging of requirements to suit the target

audience. Thus, the IIBA gives special emphasis to documentation across
the BA knowledge areas

! !312
 REQUIREMENTS DOCUMENTATION

13.8 CASELET ON REQUIREMENTS DOCUMENTATION WITH

SOLUTION

Students Smart Card Based Attendance System

Introduction:

WIM is one of the leading Management institutes in the country. The

Institute runs several full-time and part-time programs. It is proposed to
provide Smart Cards to each student and faculty including Visiting Faculty.
The smart cards could be used for various purposes, Attendance being one
of them. The main purpose is to save time for faculty and students in
recording attendance and minimize administration work in marking and
analyzing attendance.

Detailed Requirements:

1.0 Master Data and Initial Set-up Work Required:

1.1 Each Student would be given a Smart card. The smart card shall
contain a Student Identifier (could be alphanumeric), his/her name, course
(e.g., PGDM), batch (e.g., 2002-2004), date of birth, sex etc.

1.2 Some of the student data should be printed along with his/ her
photograph on the Smart Card. Thus, the Smart Card could be used as an
id-card as well.

1.3 Since the smart card may contain e-cash in future, each student
would have a PIN number as in an ATM card. The student should change
this PIN number ASAP to prevent misuse. The PIN would be used in this
system for authentication while recording attendance.

1.4 Each Classroom would be equipped with a Smart Card reader (Chip
reader) which would be connected to the PC in the classroom.
The Office Administration would key in the all the master tables required
such as the Course Master, Faculty Master, Batch Master etc.

! !313
 REQUIREMENTS DOCUMENTATION

2.0 Recording the Attendance:

2.1 Each class would have a student coordinator for every subject.

2.2 The Subject Coordinator will start up the computer before the class,
launch the attendance application and swipe his/her card, use his PIN No
to run the application and start up the attendance recording process by
entering the course and batch codes. The system would show a list of
subjects from which the coordinator would select the subject code. He will
then confirm that these are ok and allow the attendance recording to
proceed.

2.3 Other students would swipe their cards and type in their PIN number to
record the attendance.

2.4 The Faculty would swipe his/her card. Type the PIN Number and
authenticate the attendance recorded by the students.

2.5 The Student coordinator will then run the upload process which will
upload the attendance to the database on server.

3.0 Backend Processing:

3.1 The system would help the course coordinators to get detailed and
summaries of attendance records by course, student and subject. The
report formats are enclosed in Annexure.

3.2 The System will provide for an option for purging the data.

4.0 Hardware and Software:

4.1 The system would be designed to work on the existing PCs in the
classrooms and the Win2k Servers.

4.2 It would use SQL Server as its database.

[Type a quote from the document or the summary of an interesting point.
You can position the text box anywhere in the document. Use the Text Box
Tools tab to change the formatting of the pull quote text box.]

! !314
 REQUIREMENTS DOCUMENTATION

Given above is a caselet which is in the form of a requirements document

written by a BA for a proposed smart card based attendance system for a
reputed business school. If you were the supervisor of this Business
Analyst, what would be your comment about the quality of the
requirements documentation?

Do not comment on the solution itself but rather the structure and
completeness of the requirements documentation.

Solution to the Case:

Since the focus is on requirements documentation, we will accept the

solution as is it is though we do see some of the limitations of this solution.
There could be three aspects to assess as far as the documentation is
concerned:

• Structure of the documentation vis-à-vis the IEEE format.

• Completeness of the functional aspects of the documentation – i.e., have

they described all possible situations/events?

• Some of the characteristics of good documentation described in the

chapter earlier.

IEEE Format

From a IEEE format point of view, the documentation can be more

complete if it includes aspects such as:

• Personas of users or user characteristics

• Performance requirements, if any

• Interface requirements with other systems, for e.g., the lecturer swipes
his card. This can be used to signal that a lecture was taken and visiting
faculty payments could be calculated based on this.

• Security requirements – Since there is a PIN used and the possibility of

using the card for e-cash, the security aspects could have been detailed
out separately.

! !315
 REQUIREMENTS DOCUMENTATION

Functional Requirements

From a functional standpoint, we can consider the following objects:

Human Physical Document

Student Smart Card Attendance report

Faculty Smart card reader Note for leave of absence

Student-subject Coordinator PC in the class

Admin Coordinator

If we do a brainstorming of the possible situations/events for some of the

key objects —

Object : Student

• Comes late
• Goes early
• Comes early
• Is absent
• Forget to carry his card
• Has lot or misplaced the card
• Tries to swipe someone else’s card (proxy), etc.

The way to judge the completeness of the documentation is to prepare a

checklist of the possibilities as shown above and verify if these have been
described in the document. Also the event or situation should be
mentioned – such as student goes early – and the procedure to deal with
this situation should also be described because that is the procedure which
the user wishes to implement.

In many events, the procedure to follow is not described adequately — for

example if a student forgets to swipe or has forgotten his card, he can go
to the coordinator and get his attendance marked in the backend. How this
updation will be done and what the crosschecks to ensure that a student
who was otherwise absent is not misusing to get an backend attendance
marking is something which has not been described.

There are many such incompletely described aspects.

! !316
 REQUIREMENTS DOCUMENTATION

Finally, we need to look at the characteristics of a good documentation –

some of the aspects from the case above which do not conform to these
good practices include: the use of vague words – you will notice the
phrases ‘the institute runs several programs’, the smart card contains some
data about the student have been used these are not acceptable in a good
documentation.

13.9 SUMMARY

• Requirements Documentation is vital and the most important output of a

Business Analysis exercise.

• The IEEE format for requirements documentation read along with the
characteristics of good requirements documentation and other tips for
good documentation should be imbibed and practiced.

13.10 SELF ASSESSMENT QUESTIONS

1. Explain the need and benefits of Requirements Documentation?

2. Describe the essential characteristics of a good documentation

3. What standards are required for documentation and how to document a

requirement.

4. Write a short note on the IIBA Perspective.

! !317
 REQUIREMENTS DOCUMENTATION

13.11 Multiple Choice QUESTIONS

1. Which of the following is a reason and benefits of documenting

requirements?
a. It helps in ensuring that all stakeholders' needs, requirements and
expectations have been represented and captured.
b. It helps in clarifying requirements with end-users.
c. It ensures that the requirements expressed are taken forward into
the design of the solution.
d. All of the above

2. Which of the following is the standard requirement document for

software solutions that should be included as defined by the IEEE
standard for requirements documentation in Introduction and
objectives?
a. The objectives of the initiative
b. A broad overview of the solution
c. Both A & B of the above
d. None of the above

3. The Functional Requirements Document (FRD) is a formal statement of

an application’s __________ requirements.
a. Functional
b. Non-functional
c. Financial
d. Standard

4. _________ is where requirements documents can be reused either for

solution maintenance or for other projects which have similar
requirements.
a. Priorities requirements
b. Requirements Re-use
c. Business Needs
d. Business Case

5. The way to judge the completeness of the documentation is to prepare a

checklist of the possibilities and verify if these have been described in
the document.
a. True
b. False

! !318
 REQUIREMENTS DOCUMENTATION

Ans: 1- (d), 2 -(c), 3 - (a), 4 - (b), 5 - (a)


! !319
 REQUIREMENTS DOCUMENTATION

REFERENCE MATERIAL
Click on the links below to view additional reference material for this
chapter

Summary

PPT

MCQ

Video Lecture

! !320