Business Analyst Interview Question Answers

Enterprise Analysis (BABOK KA)
What is Business Capability Mapping and why it is beneficial?

ANSWER
Business capability mapping depicts what a business does to reach its strategic objectives (its
capabilities), rather than how it does it (its business processes). Business capabilities are the
connection between the business strategy and business execution.
The image above demonstrates how business capabilities bridge the gap between the strategic
objectives (what) and the business processes (how).
Enterprise and business architects model business capabilities and then assess the degree to which
the capability is fulfilling its strategic objectives which may be impacted by things like available
capacity, materials, expertise, and technology. They may also model business capabilities that don't
yet exist but are needed in order to meet future business objectives thus creating a roadmap for
capabilities which must be built out.
Each capability should have a unique name (usually a noun) and a concise one-sentence definition.
A good way to create a capability definition is to use the following pattern:
(Capability Name): Ability to (actions) on/with (business concepts or business entities) in order to
(outcome).
Customer Management: Ability to capture, process, analyze, and report on all customer
information related to an individual or organization that does, has done, or plans to do business with
the company. (Note: Customer Information is an entity documented in the business concept model)
Capabilities are defined in a hierarchy. The process of decomposing capabilities helps ensure that
capabilities are non-overlapping and unique.
Capabilities are unique based on the information they require and use. One capability may use or
produce certain information that a similar sounding capability may not require or use making them
two different capabilities. Similarly, child capabilities should be interpreted within the context of the
parent (for instance, two separate capabilities both named Risk Assessment could exist under
different parents named Solution Management and Capital Management).
Business capability mapping presents a number of benefits. The first goal of business capability
mapping is to create a stable model of the key elements of the business. The basic capabilities of a
business (the what) tend to remain constant while, in comparison, the way a business implements its
processes (the how) is likely to change frequently. Thus a capability map makes an excellent
reference point for business planning. Changes to how capabilities are implemented do not impact
the base model. Therefore, mapping and planning solutions based upon the stable business
capabilities map leads to less change to IT infrastructure over time.
Using a business capability map to connect key strategy pillars to their methods of execution make
the business strategy tangible and more visible to the entire enterprise. This leads to more effective
and efficient use of technology by identifying and eliminating enterprise-wide redundancies. A
capability-centric organization also helps overcome the common problem of organizational silos. As
such, both software and hardware assets may be leveraged, shared, or reused saving costs. The
resulting organization is a more agile and adaptable one, leading to faster time-to-market.
How is the Purpose Alignment Model used to prioritize requirements?

ANSWER
The Purpose Alignment Model aids in prioritizing requirements and guiding investment decisions by
rating requirements (which may be capabilities, processes or tasks) along two dimensions:
 whether it creates market differentiation or contributes to the value proposition
 whether it is critical for ongoing operation of the organization
The rated requirements are then organized into four quadrants:
 Differentiating quadrant – includes requirements that rate highly on both dimensions. These
requirements offer the most value to the organization.
 Parity quadrant – includes requirements that are low in market differentiation, but high for
organization operations. Examples include personnel management, asset management, finances
(accounts payable and receivable), etc.
 Partner quadrant – includes requirements that rate highly in market differentiation, but lower for
organization operations. An alternative approach to acquiring capabilities in this quadrant is an
outsourced or partnership model.
 Who Cares quadrant – includes requirements that have low ratings on both dimensions.
Requirements in this quadrant could potentially be removed from scope, as they offer minimal
value to the organization.
What is a Business Architect and is it different from a Business
Analyst?
ANSWER
The term Business Analyst is broad. The name alone implies that a business analyst performs
some form of business analysis, but that’s not very specific.
When using the term business analyst broadly it may in fact be describing any number of more
specialized roles, including:
 Business Process Engineers
 Product Managers
 Systems Analysts
 Requirements Engineers
 Financial Analysts
 Business Architects
 Usability Analysts
 Data Analysts
 etc.
In comparison, a Business Architect focuses on the activity of creating and managing the business
architecture. So what is business architecture exactly?
The OMG Business Architecture Special Interest Group and the Business Architecture Institute have
developed the following definition.
“A blueprint of the enterprise that provides a common understanding of the organization and is used
to align strategic objectives and tactical demands."
It’s a good one-liner but requires much more detail to fully articulate what is intended by the term
business architecture.
Business architecture describes the structure of a business. Much like an architect creates the
blueprints for a skyscraper a business architect creates and manages the blueprints for how the
business should be constructed.
The business architecture primarily focuses on the business organizational structure, the business
capabilities, the business value streams or business processes, business knowledge, and finally the
business strategy.
~The organizational structure of the business defines how the organization and its people are
structured into business units, teams, and reporting hierarchies. It describes management of the
business units and teams as well as the relationship between people and roles.
~The business capabilities describe the primary business functions of the organization and typically
distinguish between those business functions with are supplier facing, customer facing, business
execution, or business management and administration.
~The value streams of the business (business processes) describe how specific sequences of
activities, either with a business unit or cutting across business units, deliver value to the internal
and external stakeholders of the organization.
~Business knowledge describes the information and things that an organization uses or deals with in
order to accomplish its work. These can be customers, contracts, orders, products, suppliers, etc.,
as well as the relationships between this information. It forms the vocabulary of the business and is
what the organization relies upon to communicate and carry on its work.
~The business strategy describes the strategic goals and key drivers of the business. It goes further
to describe higher level tactical approaches that can be used to achieve these goals and maps it to
various parts of the organization. It also defines the metrics required to measure and track progress
towards these goals.
So, a person who is broadly defined as a Business Analyst could also be a Business Architect.
However, given the specialization of knowledge and skills required to be an effective business
architect, few would use a term as broad a business analyst to define themselves.
It should also be noted that there is some debate over how the terms Business Architecture and
Enterprise Architecture relate to one another. Enterprise Architecture was born out of the world of
information technology and comprises Application Architecture, Data Architecture, and Infrastructure
Architecture. However, more recently practitioners have broadened the definition of Enterprise
Architecture to also include Business Architecture as a fourth sub-component, leaving Enterprise
Architecture as the overarching concept.
How does Enterprise Analysis bring value to an organization?
ANSWER
Enterprise Analysis activities are intended to achieve a number of outcomes that contribute directly
to project success:
 Ensure that the business problems to be solved and / or opportunities to be leveraged through
any project are fully understood and clearly articulated
 Assess the capability of the organization and identify any gaps that would prevent it from meeting
business needs and achieving the desired outcomes from any project
 Determine the most feasible business solution for the identified problems and opportunities
 Establish the high-level scope and business case or plan for a recommended business solution
The information produced through Enterprise Analysis is the basis for critical project decisions –
what the project is expected to cost, what value it is expected to bring, whether any solution can be
reasonably expected to address the business needs, which solution is the ‘best’ when alternatives
are available, and the ultimate decision- should the organization even proceed with a particular
project or course of action.
These are decisions that every organization has to make for every major project or initiative.
Enterprise Analysis brings a structure and a methodology to the way that information is collected and
documented for those decisions. Put very simply, more informed decisions produce better results.
Well-executed Enterprise Analysis helps the organization predict, monitor and manage the key
factors that are critical to project success.
What is Gap Analysis?

ANSWER
Gap Analysis is the process of comparing two things in order to determine the difference or “gap”
that exists between them. Once the gap is understood, the steps required to bridge the gap can be
determined.
Most often gap analysis is used to compare two different states of something; the current state and
the future state.
Gap analysis can be conducted on:

 a system – features that exist in the system now versus the features that need to exist in the
future
 a system interface – data that a system provides to an interface now versus data that will need to
be provided in the future
 a business process – activities and steps of a current business process versus the activities and
steps that will be supported by the business process in the future
 Business goals and metrics – how well a business meets certain goals and metrics now versus
the targeted goals and metrics at some point in the future.
What is DMN and how is it used to support BPMN?
ANSWER
BPMN is used to define business processes as a sequence of activities. Gateways are used to show
branching of different process paths. For many years, analysts would clumsily model decision logic
directly in business process models in an attempt to fully define process branching logic. This made
process models messy.
DMN or Decision Modeling Notation was published in 2015 by the Object Management Group. It's a
graphical language for specifying business decisions. DMNs primary purpose is to give analysts a
tool for separating the business decision logic from the business process. This serves to greatly
reduce the complexity of business process models and facilitate their readability. The encapsulation
of business decision logic with DMN also allows the business process or business rules to change
without impacting the other.
DMN is made up of 4 elements and 3 requirements as defined by specification published by the

Object Management Group:
 Decision (element) - A decision denotes the act of determining an output from a number of inputs,
using decision logic which may reference one or more business knowledge models.
 Business Knowledge Model (element) - A business knowledge model denotes a function
encapsulating business knowledge (e.g., as business rules, a decision table, or an analytic
model).
 Input Data (element) - An input data element denotes information used as an input by one or
more decisions. When enclosed within a knowledge model, it denotes the parameters to the
knowledge model.
 Knowledge Source (element) - A knowledge source denotes an authority for a business
knowledge model or decision
 Information Requirement - An information requirement denotes input data or a decision output
being used as one of the inputs of a decision.
 Knowledge Requirement - A knowledge requirement denotes the invocation of a business
knowledge model.
 Authority Requirement - An authority requirement denotes the dependence of a DRD element on
another DRD element that acts as a source of guidance or knowledge.
What is the different between a business policy and a business rule?
ANSWER
Business Rules and Policies tend to be complicated for analysts to untangle because they are so
closely related. Policies are typically more general assertions or guidance about how an
organization is intended to operate, while business rules describe the specific execution of the
business policy.
The BABOK describes a policy as “a non-actionable directive that supports a business goal', and a
business rule as 'a specific, actionable, testable directive that is under the control of the business
and supports a business policy'
The Business Rules Group goes further in their definition of business rules describing it as an atomic
statement that defines or constrains some aspect of the business. They categorize business rules
as one of three sub-classifications; structural assertion, action assertion, or derivation. The
definitions of these get quite detailed and while knowing them, along with understanding things like
fact models, may help elaborate one’s understanding of a business rule, at a summary level
business rules are best understood by a higher level definition (like the IIBA’s) and a few examples.
Additionally, policies, being more general, typically change less often than business rules which are
specific implementations of policies.
To restate, a policy is:

 A non-actionable directive
 Often requires employees to translate into specific statements of what to do (business rules)
 Supports a business goal
 Supported by one or more business rules
A business rules is:

 Actionable
 Specific
 Testable
 Supports a policy
Examples of policies for a car rental company:

 Maintenance must be performed in a manner which maximizes the life and value of the car
 Renters must have valid insurance
Example of business rules that may support these policies:

 All vehicles are required to have a 58 point inspection after every 3 months of use before re-
renting.
 A car which has accumulated more than 3500 miles must have its oil changed before re-renting.
 Tires with less than 1/16th inch of tread must be replaced.
 Renters in the state of Texas must have insurance covering $100,000 of liability or more.
 Renters in the state of Arizona must have insurance covering $50,000 of liability or more.
Notice that each of the business rules are written as a level which is actionable, specific, and
testable.
In which document do you include the Class Diagram (business requirements,
functional requirements, software specification document)?
ANSWER
The easy answer is “It depends!”
Just like any other diagram, the Class Diagram is just a tool at the disposal of the analyst. In the
absence of a set process, it is at the analyst’s discretion to determine when to use a class diagram.
Therefore, in which analysis artifact/document a class diagram should be included depends on its
use.
But first, let’s determine what a Class Diagram can do for you by looking at some of its
characteristics:
 A Class Diagram models “classes” also known as types. It shows what types of things can exist in
the domain being analyzed. Remember: things = nouns!
 A Class Diagram can show the “attributes” of the classes, that is it shows what type of data can
be used to describe a given thing.
 A Class Diagram illustrates how “classes” are related to each other. It depicts the relationships
which can exist among the various things which exist in a given domain.
 A Class Diagram shows “multiplicity” also known as “cardinality”. This concept is used to further
clarify the relationships between things by specifying how many things of one type can related to
how many things of another type.
Therefore, if the analyst uses the Class Diagram to depict the key nouns found in the lingo of the
business users (aka the business domain) and the relationships among those things, then this class
diagram would represent a domain model and would probably belong in one of the earlier artifacts of
the project such as the Business Requirements Document (BRD).
On the other hand, if the Class Diagram is used to explain what C# classes will be used to realize
the functional requirements and the types of data attributes which describe those classes, then this
diagram would be considered a design artifact and would probably belong in the System
Specification/Technical Specification document.
What is Enterprise Architecture, and why is it relevant to a Business

Analyst?
ANSWER
Enterprise Architecture (EA) is the practice of fully describing and viewing an enterprise through the
use of models and other representations. EA’s views of the enterprise cut across all of the domains
that a complex enterprise contains: security, strategy and performance, business, data,
infrastructure, and applications.
For each of these domains, EA asks the questions of Who, What, Where, Why, When, and How
related to absolutely everything an enterprise does. It answers those questions using a number of
different perspectives you will find in an enterprise ranging from the highest level executive
perspective to the lowest level perspective of software engineers and configuration specialists.
EA primarily provides value through the use of taxonomies and architectural models. Taxonomies
are a sort of “dictionary” that describes something an enterprise does using a common language so
that everyone is on the same page. For example, an enterprise might have a business taxonomy
that names and lists every single process of an organization. That helps keep the enterprise keep
track of what it has, and also minimize duplication of effort when new work is being done.
Architectural models provide views of different enterprise systems. These views show the important
entities and relationships between those entities. The business process model is an example of an
architectural view that helps describe the business domain, with entities being actors and decision
points and relationships being the process flow.
EA’s end goal is to describe an enterprise as fully as possible, for only if you know what you
currently have can you safely and efficiently make changes to it. EA provides current state views,
future (target) state views based on the needs of the organization, and road maps from getting from
point A to point B. All of this work is guided by certain EA principles such as scalability and re-using
things whenever possible to eliminate duplication and waste.
This is all important for a Business Analyst in a number of ways. EA provides the desired target state
and road map for the organization, and everything that a BA does must adhere to them. When a BA
does business process re-engineering or captures new requirements, for example, the BA must
ensure that the proposed work is consistent with the EA target state that reflects the overall goals
and objectives of the organization.
EA can also make a BA’s life easier. If EA maintains an updated list of all business processes or a
repository of business process models, for example, these artifacts can serve as resources upon
which the Business Analyst can do her work rather than forcing her to create things from scratch.
Third, EA may ask the BA for help in defining business views of the organization. This gives the BA
the opportunity to help guide what the future organization is going to look like, since her feedback
will translate directly into the EA target state.
How would you build a Business Process Model?

ANSWER
Building a Business Process Model is a complex task that requires a number of successful steps to
complete.
1) Determine scope
First, you need to figure out the actual scope of the work you are doing. Since business processes
often interact with other processes in a complex fashion, it’s important to draw a line between the
process that is in scope and the associated processes that are out of scope.
Another important item to determine is whether you are documenting the process that exists
(“current state,”) documenting an anticipated future change to the process (“target state,”) or both.
You may also be building an entirely new process from scratch.
2) Gather background information
The first step is to fully understand the process that you will be documenting as a Business Process
Model. You may read available documentation and Standard Operating Procedures. You may also
speak to people who are involved with the process on a day-to-day basis. The goal is to gain a high
level understanding of what the process is about.
3) Conduct interviews
Now that you have a high level understanding of the process, it’s time to dig into the details. This
often requires interviews with the subject matter experts most familiar with the new or existing
process you will be modeling. As you facilitate these interviews you must be able to aggressively
question every step of the process. Make sure you fully understand every decision point, activity,
manual or automated step, data source, message, and event.
As you do this you must define the “happy path” of the process, which is the default path when there
are no exceptions, problems, or conditions. This “happy path” must be clearly expressed in your
model. Once you fully understand the “happy path” you can delve into the necessary exceptions.
4) Begin Modeling
At this point you can start your Business Process Model. Ideally you should use Business Process
Modeling Notation (BPMN) 2.0, which is the current standard.
How you model depends on your organization’s capabilities. Many places use Visio, which is
perfectly adequate. If Visio is not available, then a tool such as PowerPoint can be used although
this makes modeling more difficult as it is not a dedicated platform for that purpose. A step up from
Visio would be a dedicated Business Process Management suite, which has features such as a
model repository and in some cases the ability to generate software code automatically.
5) Validate and iterate
Once you have built your initial model, it is time to validate and iterate it. Go back to your original
stakeholders and subject matter experts that you interviewed. Walk them through every step of the
process model. They are likely to find errors, and that is normal. Take their feedback and improve
the model in response. Then go back to them again, and repeat this until the model is perfect. You
then get your business sponsor to sign off on the model.
Your model is done until the time comes to expand or modify it.
What is a Fact Model?

ANSWER
A Fact Model is a static model which structures business knowledge about core business concepts
and business operations. It is sometimes called a business entity model.
The fact model focuses on the core business concepts (called terms), and the logical connections
between them (called facts). The facts are typically verbs which describe how one term relates to
another. For example, the two terms Person and Car may have a fact connecting them called Owns
(a Person owns a Car). The same two terms may also have a different fact connecting them called
Drives (a Person drives a Car). The facts, which connect the terms, should do so in a way which
reflects the real world since the primary purpose of a fact model is to create a standard vocabulary
by which all stakeholders can communicate unambiguously.
The business knowledge represented in a fact model should be at the most atomic level of business
knowledge, meaning it should not be able to be further deconstructed and it cannot be derived from
other knowledge. By using the standard vocabulary defined by the fact model, these basic building
blocks can be used to develop and communicate more advanced forms of business knowledge,
such as business rules, in a clear and unambiguous way.
Fact models are incredibly useful regardless of whether it is a system solution that is being
considered or a process solution. However, if the solution is a system, the fact model can be used
as an input into the development of the data model in later stages of the SDLC.
What is PEST Analysis?

ANSWER
PEST is an acronym that stands for Political, Economic, Social, and Technological. PEST analysis is
one way that a business can analyze the environment in which it operates.
Political Environment: refers to government laws, regulations, and policies. These are things that
impact the business either directly or indirectly. This may include trade laws, tariffs, labor laws,
taxes, environmental regulations, zoning restrictions, etc. Some of these, if passed recently, may
have a long term affect on the economy as well. While PEST covers the economic environment,
some political environment considerations, such as leadership changes that come from elections,
may not have impacted the economy yet (this is an example of an indirect impact). So the analyst
should watch for how new government regulations may impact the economy longer term and assess
its impact on the business.
Economic Environment: refers to the forces at play within the economy that the business has little
control over. These may include interest rates, inflation rate, exchange rates, increase in Gross
Domestic Product (GDP), the financial and stock markets, the job market, etc. All of these have
impacts on the business from the ability to generate revenue to the cost of borrowing money to the
salaries they will need to pay employees.
Social Environment: refers to the demographics of the environment that the company operates
within. Since demographics are nothing more than characteristics of a human population this could
include a nearly infinite number of groups. Some common demographics that are considered are
gender, race, age, income, disabilities, educational attainment, employment status, and religion.
Ultimately, if the strategic plans of a business affect a particular group, they may react positively or
negatively. A business may face criticism, negative publicity or even protests based on the
decisions it makes. These factors could have an enormous impact on the operations and revenue of
the business.
Technological Environment: refers to the technology that currently exists that the business has
accessible to them. This could include servers, computers, networks, software and software
frameworks, database technologies, wireless capabilities, availability of Software as a Service
(Saas), and more. The rate of technological progress should also be considered, particularly if the
business has plans to develop a system or product that takes advantage of cutting edge technology.
What is RML (Requirements Modeling Language)?
ANSWER
Requirements Modeling Language (RML) is a collection of diagrams used to model software from
the business analysis or product management perspective. Instead of focusing on complex system
design models as is typically done with UML or SysML, RML looks at a project’s goals and
objectives. Of course, many people have adapted the usage of UML diagrams to try and capture
business requirement information more effectively and there's nothing wrong with that. But RML
was established with a focus first and foremost on the business objectives and requirements in order
to compensate for where UML and SysML have fallen short such as product line engineering, goal
conflict resolution and hazard/threat modeling.
Furthermore, requirements engineering for complex systems requires collaboration between inter-
disciplinary teams and domain experts. Many of which might not have software or systems
engineering backgrounds. RML was created with these people in mind and is easily digestible to the
business.
RML models fall into 4 categories:
 Objective Models including

 Business Objectives Model (BOM)
 Objective Chain
 Key Performance Indicator Model (KPIM)
 Feature Tree
 Requirements Mapping Matrix (RMM)
 System Models including

 Ecosystem Map
 System Flow
 User Interface (UI) Flow
 Display Action Response Model
 Decision Tree
 Decision Table
 System Interface Table
 People Models including

 Org Chart
 Process Flow
 Use Case
 Roles and Permissions Matrix
 Data Models including

 Business Data Diagram (BDD)
 Data Flow Diagram (DFD)
 Data Dictionary
 State Diagram
 State Table
 State Diagram
 Report Table
RML as described here is a broadly accepted idea. But several requirements modeling languages
exist. So there is still some variation in the models used throughout the industry. Two of the more
common versions are RML (Requirements Modeling Language) and URML (Unified Requirements
Modeling Language). Both were established to fulfill the same goals and to compensate for the
shortcomings of UML and SysML.
Is it really necessary to document the business vision at the start of a

project?
ANSWER
The business vision serves as a foundation that drives, guides and unifies the project from beginning
to end. It may be captured in a 1-page Vision statement or a formal Vision document, depending on
the size and complexity of the project.
The Vision is articulated by senior or executive management teams. It describes the business
outcomes that the project is expected to achieve, and identifies the strategic and tactical changes
needed in the target-state. It provides necessary direction that enables operational staff to give
requirements that move beyond current-state in the direction that management has chosen. A
common failing in projects without a clearly defined vision is a target-state solution that looks
remarkably similar to the current-state environment.
The Vision also serves to guide the BA over the course of the project. When dealing with detailed
requirements and business rules, it is often easy to ‘get lost in the weeds’ and lose track of strategic
directions. The BA uses the Vision as context to guide requirements elicitation (“what capabilities
would you need in order to shift from your current-state to the envisioned target-state”) and to
validate requirements being captured for alignment to the desired end-state.
What is Enterprise Architecture?

ANSWER
It should first be stated that there is some continued debate around the scope and definition of
Enterprise Architecture. Enterprise Architecture was born out of the world of Information
Technology and comprises Application Architecture, Data Architecture, and Infrastructure
Architecture. This aligns with how many interpret the United States government’s definition of
Enterprise Architecture which is to be an Information Technology function.
However, as more professionals focus on the related topic of Business Architecture -- which covers
the business organizational structure, business capabilities, business value streams or business
processes, business knowledge, and finally the business strategy -- the need to clearly articulate the
relationship between Enterprise Architecture and Business Architecture grows. Based on the more
historical definition of Enterprise Architecture, the two go hand-in-hands but remained mutually
exclusive of each other. Historically, Enterprise Architecture was thought of as the Information
Technology component which supported the Business Architecture. Recently, however, practitioners
and leaders in the field have begun to broaden the definition of Enterprise Architecture to also
include Business Architecture as a fourth sub-component, leaving Enterprise Architecture as the
overarching concept.
Based on this broadening of scope, Enterprise Architecture now covers:
 Business Architecture
 Data Architecture
 Application Architecture
 Infrastructure Architecture
Of course, there are a number of published Enterprise Architecture frameworks available including
The Zachman Framework for Enterprise Architectures, The Open Group Architectural Framework
(TOGAF), The Federal Enterprise Architecture, The Gartner Methodology, and more. Depending on
which framework you reference, the above 4 sub-architectures are sometimes named differently or
divided/combined in a slightly different way. Enterprise Architecture will remain an evolving
discipline for years to come.
What is Cloud Computing and what are the pros and cons?
ANSWER
Cloud computing is the use of internet-based services to store, manage, and process data in order
to provide applications and services to users. Cloud computing can be categorized into three areas:
 Infrastructure-as-a-service (IaaS) – vendors provide the physical data centers and network
hardware. Typically clients will pay based only on the amount of resources they use.
 Platform-as-a-service (PaaS) – a delivery model in which the consumer creates the software
using the tools, libraries, and reconstructed services from the provider while maintaining control
over the configuration and deployment of the software.
 Software-as-a-service (SaaS) – a software delivery model in which the software, and usually the
data, is provided by the vendor and hosted “in the cloud”. Vendors run the software application
for you. The software can be seamlessly and continually updated.
Cloud computing has both pros and cons to consider
The Pros
 Reduced Set Up Costs - Cloud computing minimizes large upfront investment in hardware and
software. Additionally, it decreases the need for IT staff to maintain the hardware and software.
Some staff are often still needed but on a dramatically smaller scale. Cloud computing
distributes the cost of expensive hardware and software across many smaller companies.
 Scalability - Cloud services are readily scalable to meet the needs of the client with clients paying
for resources as they are needed (usually following a tiered pricing structure). With auto- scaling
(elastic) services, clients can often receive real-time scaling with no additional action necessary.
 Lower Barriers to Entry - Cloud computing gives small and mid-size businesses access to the
types of infrastructure and sophisticated technology that previously would have required the deep
pockets of a big corporation.
 Limited Need for Expertise - Cloud computing in most cases limits the need to hire technology or
security experts. Given the relatively new nature of Infrastructure as a Service, some expertise is
still warranted to ensure that servers and nodes stay up and running, but certainly less than what
would have previously be needed. As you move towards Software as a Service almost no
expertise is required.
 Collaboration - Cloud computing offers software and services that can be accessed by any
computer, anywhere, anytime. This improves the collaboration that can be achieved by
distributed teams and organizations in a global workforce.
The Cons
 Lack of Availability - Cloud service and infrastructure can still go down. If it does, your
organization can be left without important information or software for hours.
 Data Ownership and Exchange - If your organization stops using a cloud software or service, can
you retrieve all of the data that you have accumulated over time? Additionally, can you be sure
that the provider of the software or service has properly disposed of your data?
 Privacy and Control - What is the service provider doing with your data? Are they protecting the
data or are they collecting it and using it for other purposes for their gain?
Explain Kurt Lewin’s Model of Organizational Change

ANSWER
If there is one thing that you can be certain of in business today it’s change. Kurt Lewis, a physicist
and social scientist, defined a model for organizational change as far back as 1947. This model is
still taught today in many business schools as part of the change management discipline.
Lewis used an analogy of changing the shape of a block of ice to convey his theory. If you want to
change the shape of a block of ice you must first melt it or break down its existing structure. Once
it’s unfrozen, it becomes liquid and can be changed by guiding it in any direction you desire. Using a
mold, you can cause it to take on a different shape from its original state. Finally, you freeze the
liquid within the mold to crystallize it into its new shape. This is how Kurt Lewis explained his
influential three-stage model of organizational change. Here are some key points to consider when
thinking about three stages of change (Unfreeze, Change, and Freeze).
Unfreeze
Before you can begin changing an organization in any meaningful way you need to overcome the
inertia of the existing way of doing things. This starts by challenging many of the beliefs, attitudes,
and behaviors of people within the organization. As Lewin put it, “Motivation for change must be
generated before change can occur. One must be helped to re-examine many cherished
assumptions about oneself and one’s relations to others.” You are breaking down the status quo.
During the unfreezing process everyone feels that things are becoming off balance. This feeling
becomes a strong motivator for people to seek out a new equilibrium. During this stage, you need to
sell the benefits of the change. The more people that recognize that the change needs to occurs the
more likely it will be successful.
 Determine what needs to change

 Sell the benefits of the change to everyone involved (this includes getting support from upper
management)
 Specifically address any doubts or concerns
Change
Once the organization has gone through the unfreeze stage, effective change can begin within the
organization. People begin to look for new ways to do things and support the new direction. Time
and frequent communication are two key factors for the change to occur. People need to
understand the changes as they occur and feel that they are part of the change. Some take a long
time to recognize the real benefits. This can lead to fear and rumors that need to be handled
quickly.
 Involve people in the process and empower them

 Communicate frequently
 Dispel rumors quickly
Freeze
Once the changes have taken effect, the next stage is to freeze or crystallize the changes within the
organization. Putting the proper processes and the organizational hierarchy in place to manage
them is important to ensure this happens. Since change is always occurring, some might ask why
bother to freeze things. Why not stay in a constant state of change? Constant change, without
freezing things in place at least momentarily, leaves people without a clear sense of direction. It
becomes more and more difficult as time goes on to convince people that something needs
changing if you don’t give the most recent changes time to fully crystallize. Also, taking the time to
celebrate the successful completion of changes within the organization provide everyone with a
feeling of reward and gives them closure.
 Develop processes to anchor the changes into the culture

 Provide clear communications, support and training
 Celebrate the successful completion of changes
What is the 4 +1 View Model as it relates to system modeling?

ANSWER
The 4 + 1 View Model is a predefined set of views for organizing the design and architecture of a
system. It was developed in 1995 by Philippe Kruchten, formerly the Director of Process
Development at Rational Software.
The 4 + 1 View Model gets its name from the 4 primary views and 1 supporting view that are used to
capture and communicate different aspects of the system.
The 4 primary views are:

Logical View: this view describes the functionality of the system in terms of its static structure and
dynamic behavior.
 Development View: this view describes the system from a programmer’s perspective and is
concerned with the organization of physical code, its main modules, and their dependencies.
 Process View: this view focuses on the runtime behavior of the system and the elements of the
system that relate to process performance. It includes aspects important to scalability,
throughput, and process response times to name a few.
 Physical View: this view shows the system from a system engineer's point-of-view. It is
concerned with the deployment of software components across the physical architecture
including computers and devices, as well as communication between these components.
The 1 supporting view is:
 Use Case View: this view describes the functionality of the system from the perspective of
external actors.
Functional Specifications
In which document do you include the Class Diagram (business
requirements, functional requirements, software specification
document)?
ANSWER
use.
characteristics:
How are non-functional requirements defined and managed on agile
projects?
ANSWER
Non-functional requirements (NFRs) are typically defined as backlog constraints on an Agile project,
and are managed as part of both product backlog and scrum backlog. They are revisited as part of
the ‘Definition of Done’ for each iteration or sprint. If the system does not meet any given NFR, that
NFR may spawn new backlog items such as refactors or performance enhancements.
Well-defined NFRs should meet the following criteria:
 Bounded: Each NFR should describe the scope of the system to which it apples (its ‘boundary’).
Many NFRs apply to the entire system (such as extensibility or portability); however others may
be bounded to specific components for feasibility and/or cost-control reasons. Critical functions or
components may have stricter non-functional requirements for availability or performance for
example, while others (such as administrative functions) may have less stringent needs for these
particular NFRs.
 Independent: NFRs should be independent of each other, so they can be evaluated and tested
without consideration or impact on other system attributes.
 Negotiable: Like functional requirements, NFRs return a quantifiable business value in return for
a definable cost. The cost of an NFR should not exceed its expected value, and may need to be
negotiated to align both cost and benefit.
 Testable: If you can’t test it, you can’t deliver it. NFRs should be stated with objective,
measurable and testable criteria just like functional requirements.
Once a system is developed is it reasonable to document changes

with simple updates to screen mockups?
ANSWER
This question implies that the benefit of foregoing the creation of a more complete requirements
specification document is a significant amount of time savings. But what might we be losing in the
process.
Screen mockups alone don’t clearly document requirements. Instead, they reflect a decision made
by the system designed to satisfy a particular requirement. Often when someone views the mockup
or updated system they may think the requirement is obvious when, actually, they have
misinterpreted the true requirement.
For example, imagine that you are updating a business networking site. The product manager (or
systems analyst) makes a freshly altered mockup which shows that the users of the site should
provide their full address as part of their profile screen. What is the requirement here? Perhaps the
rest of the design and development team has assumed that there exists a need for the full address
for mailing information to the user. In reality, this was just the product managers design choice. The
address was needed so that users could search the network by name and if they found multiple
people with the same name the city could be used to accurately identify which person they were
looking for.
This may seem like a minor example, but as system changes become more routine and complex the
problem becomes magnified. For systems with several distinct user groups there are often
competing needs. So a change to meet one requirement can actually break the system such that it
no longer satisfies the requirements of a different user group. Compromises must be made, but
without a detailed understanding of all of the requirements and which users they support an
educated decision cannot be reached. Inevitably, the product manager will begin to forget some of
the details of various user requirements over time. Furthermore, if the product manager leaves the
organization this information is lost forever.
Some common challenges that arise from simply updating mockups are:
1. While updating mockups may seem to save some time in the short term, it often leads to a culture
of taking shortcuts and not performing the appropriate amount of analysis longer term.
2. Time is wasted over the long term while trying to determine the original requirements and needs,
or even reworking changes that were made because a screen was updated for one user group
that conflicts with the needs of another user group.
3. The project team not only needs to remember “What” each group needs, but also understand
“Why” they need it in order to manage conflicting requirements between user groups.
Of course, if you are updating a fairly simple system that will have few changes over time then some
reasonable shortcuts can be taken. But how much time are you really saving? During the initial
development of the application you probably spent a considerable amount of time creating initial
requirements documentation. The lion’s share of the work is done. Making small but thorough
updates to the requirements documents going forward will require much less time. And in most
cases, not properly documenting and managing requirements over the long term proves to be a
more costly decision.
List the steps you would take to bring a product from idea to
deployment and beyond.
ANSWER
There are many ways this question could be answered based on the type of SDLC method being
used and other environmental considerations.
The steps outlined assume the marketing and promotion of the product will be handled by another
group. An iterative/Agile approach has also been assumed and combined with User Centered
Design principles, though other approaches could be used.
1. Market Analysis: Market Analysis is a critical step to perform before deciding to undertake the
development of any product. Research needs to be performed to determine:
i. The size and demographic of the potential market
ii. The needs of the target demographic
iii. The growth of the market; is it growing and at what rate, or is it contracting
iv. Competition within the market; who are the key players
v. Is there a widely excepted cost structure for the product that is being introduced
vi. Based on the cost structure that is to be chosen, what kind of profitability can be expected?
This can be determined by performing a Cost-Benefit Analysis.
Competitor Analysis: For the competitors identified during market analysis:
. Understand the features offered by the competitors product
i. Compare each competitors feature to those feature which are deemed to be most important to
your targeted customer base, and rank each competitor based on the results
ii. Speculate as to the strategic direction each competitor may be taking
iii. Identify the clients of each competitor and determine which demographic segment they fall
into
iv. Understand the cost structure that each competitor uses for their product
v. Identify key weaknesses of competitors that may be able to be exploited, etc
SWOT Analysis: Combining information from the market and competitor analysis, it is often
helpful to perform and document a SWOT analysis to determine internal strengths, weaknesses
and external opportunities, and threats.
Personas: Develop Personas to reflect users of your product by market segment.
Strategic Vision and Feature Set: Determine strategic vision and feature set for product. This is
the start of your Product Backlog (features to be developed).
Prioritize Features: Create and initial priority for the features to be developed
Use Cases/User Stories: (Caveat: Use Cases and User Stories can mean very different things to
different people. There isn’t a single standard used throughout the industry) Create high-level
Use Case descriptions or User Stories for the features that are intended for the first iteration of
development. The objective of the use case description is to define the behavior of the features
without getting in to specifics about how the screens will support it.
Logical Data Model: In parallel with the Use Case descriptions, create a Logical Data Model (to
be further refined throughout the SDLC). The logical data model creates a common terminology
for referencing information that needs to be manipulated by the features of the product. It also
becomes a great starting point for the physical data model and database design.
Persona to Use Case Mapping: Understand which Usage Scenarios will be invoked by each
Persona. This ensures that the appropriate emphasis is given to the segment of the
demographic you are targeting as the highest priority.
Screen Mockups/Storyboards: Create initial Screen Mockups and begin Storyboarding for those
features which are prioritized for the first iteration of development. This will be a very iterative
process. There will be many ways to design the product/application to provide the feature
functionality as defined by the Use Cases. Also, as the team iterates through the screen
designing process it may become clear that missed features will need to be added, or a change
in the feature priorities needs to occur.
Product Backlog: Finalize the priority of features and create the Product Backlog which is the list
of all features that need to be prioritized, tracked, and eventually developed for the product.
Begin the first iteration of feature development
. For-Each Iteration
i. Logical Specifications: Create logical specifications to define the precise screen behavior.
This will include screen mockups, description of on screen behavior, screen transition
behavior and navigation, sounds, details about controls and the information (logical data
model) that each control displays or accepts from the user, etc. The Behavior can be
described textually using Pseudo Code, or when appropriate process flow diagrams can be
used (UML Activity diagrams or similar)
ii. Test Cases: Create test cases reflecting the expected outcome for each usage scenario
iii. Physical Design Specifications: Translate the logical design into physical design. This may
include a physical data model and database schema design, static structure modeling
using techniques such as class diagrams to reflect the physical structure of the code, class
interface design, and behavioral modeling using techniques such as sequence diagrams as
necessary. While the design of the code and database at this level is primarily intended for
the iteration in progress, consideration should be given to the overall code and database
architecture to ensure appropriate scalability for large user populations and large numbers
of concurrent users.
iv. Write Code: Code to the specs
v. Unit Testing: Perform unit testing
vi. System Integration Testing: Perform system integration testing based on the test cases
created prior to coding
vii. Regression Testing: Regression Test the application using test cases from prior iterations
to ensure that new changes didn’t introduce unforeseen bugs.
viii. Deploy Code: Deploy the code and release the product. Depending on the situation this
may be a beta release with a pre-defined set of beta users.
i. Once the iteration is complete, then the next iteration can begin.
Metrics and Monitoring: After a product has been deployed, specific metrics about the product
can be tracked and monitored to see how the users are actually using the product. What do they
use frequently? What do they use infrequently? This is especially relevant for SaaS products.
Though even shrink-wrap software can have built in metrics tracking that is reported back to the
developing organization. This information can be used to further refine features and build the
product out in areas where it is found to be lacking.
Strategy for Scalability: For SaaS products, database/server monitoring should occur to ensure
that concurrent user activity can be supported. Strategies for scalability should be in place well in
advance of ever needing them.
Some of these steps could be combined, pared down, or avoided altogether depending on the
demands of the project and complexity of the product or application. Use the minimum amount of
tools, models, and specifications needed to communicate the necessary information to the coders in
a way that ensures the final product meets the expectations of the customer and is defect free. Once
might refer to this as “just enough documentation” – not too much, but not too little.
However, the decision to eliminate certain steps or deliverables should be a pragmatic one, and
should not be done out of laziness or a lack of understanding of the importance of a particular
deliverable.
How do you avoid requirement conflicts while making changes to an

existing system where no documentation exists?
Companies with small IT departments or analysis teams often lack a well defined analysis process.
It's not uncommon for analysts to be hired onto a team and find that they are being asked to assist
with requirements and new features for a system where no documentation exists. In this case, the
analyst needs to create a minimal amount of documentation retroactively.
Few companies will permit taking the time to completely stop and fully document a system with a
heavy weight documentation process. So the analyst needs to start with a lightweight process for
documenting features and requirements rapidly.
Features tend to be readily apparent in the implementation of a system. However, the underlining
requirements and rationale for the features are not as apparent.
First the analyst can document features and sub-features quickly using a feature tree diagram
(based on the Fishbone Diagram). This helps organize features hierarchically. Most features are
evident by examining the user interface. However, doing a cursory code review can uncover other
less noticeable features as well as business rules associated with many features. When you find
business rules, be sure to document them. Once feature identification is deemed to be complete the
requirements should be documented in list form or in a database so that they can be mapped to
business rules and, more importantly, to the requirements that will be documented.
The next step is to identify the requirements which led to the inclusion of the features in the first
place. This will allow the team to avoid requirement conflicts in the future. Since we've already stated
that time is a luxury it makes sense to use agile techniques to document the requirements rapidly.
User stories are great for such a case. Reach out to the end users of the system and ask them what
they use the system for, how they use it and why they use it in the manner they do. How does the
system create value for them? Construct a quick set of high level User Stories to document the .
what and Why. These are your requirements.
The User Stories don't have to be completely detailed out all at once. Create simple 1-3
sentence User Stories representing each requirement. Along with the user stories, acceptance tests
and business rules should be associated to each, but this can be done on an ongoing basis as more
is learned about the system through future iterations and updates.
Once the features have been identified and the user stories have been created, the analyst can map
the two together reasonably well. The organization now has a reasonable understanding of the
requirements of the system and can avoid conflicting requirements in the future.
What is the difference between a use case alternative flow and an
exception flow?
ANSWER
A use case specification describes the functionality of a system in terms of a sequence of user-
system interactions. The main flow of events describes a single path through the system. It
represents the most common way that the use case plays out successfully and contains the most
common sequence of user-system interactions. Other scenarios or paths through the system are
described in alternative flows and exception flows. So what is the difference between and
alternative flow and an exception flow?
First, it’s worth saying that there’s a number of differing opinions in this area since the Unified
Modeling Language has no standard for Use Case Specifications. Some authors mention only
alternative flows and use them for both optional user paths and error paths. However, among
authors who differentiate between alternative flows and exception flows, agreement has emerged.
An alternate flow describes a scenario other than the basic flow that results in a user completing his
or her goal. It is often considered to be an optional flow. It implies that the user has chosen to take
an alternative path through the system. An exception flow is an unintended path through the system
usually as a result of missing information or system availability issues. Exception flows represent an
undesirable path to the user. However, even though the exception flow has occurred the system
should still react in a way that recovers the flow and provides some useful information to the user.
The primary benefit of differentiating between alternative flows and exception flows is the focus that
exception flows bring to error conditions. By capturing all of the ways that the system can fail or
produce an error, the business analyst can be sure to create a design that mitigates the impact of
the error.
What strategies can the BA and project team use to facilitate

stakeholder sign-off on requirements?
ANSWER
There are several steps that the BA and project team can take beyond just publishing requirements
with a sign-off deadline, in order to ease the process for stakeholders and expedite approvals:
 Make sure the right people are signing-off on requirements. It sounds simple and obvious, but
this can be one of the biggest contributors to challenges in obtaining requirements sign-off,
particularly on complex multi-stakeholder projects.
 Help stakeholders understand the sign-off process. Provide a clear explanation of the
commitment that stakeholders are making to the project by signing off on requirements. Be sure
to communicate the process for identifying and managing subsequent changes after sign-off
(which may be just a reminder of the project’s established change control procedures).
 Help stakeholders interpret the requirements documentation. Where feasible and applicable,
provide supporting or reference material to assist interpretation and understanding of the
requirements. This may include glossaries and data dictionaries, diagrams, etc. It is also very
helpful to maintain a log of all decisions that are made throughout requirements definition, and
publish this decision log with the requirements to avoid revisiting past decisions.
 Make sure stakeholders have enough time to review the requirements during sign-off. Plan ahead
for review and sign-off cycles as much as possible. Remind stakeholders of this commitment 2-3
weeks prior to each review cycle, so they have enough advance notice to plan for the time
needed.
 Foster collaborative ownership on multi-stakeholder projects. If a single document contains

requirements that are shared or jointly owned, individual stakeholders may be reluctant to sign-off
on requirements that they do not individually own. Joint review sessions can be used for
collaborative discussion with the goal of obtaining verbal approval from the group during the
session. Stakeholder questions or concerns can be addressed through the group review, which
will help expedite sign-off from each individual participant.
What strategies can the BA and project team use to facilitate

stakeholder sign-off on requirements?
ANSWER
There are several steps that the BA and project team can take beyond just publishing requirements
with a sign-off deadline, in order to ease the process for stakeholders and expedite approvals:
 Make sure the right people are signing-off on requirements. It sounds simple and obvious, but
this can be one of the biggest contributors to challenges in obtaining requirements sign-off,
particularly on complex multi-stakeholder projects.
 Help stakeholders understand the sign-off process. Provide a clear explanation of the
commitment that stakeholders are making to the project by signing off on requirements. Be sure
to communicate the process for identifying and managing subsequent changes after sign-off
(which may be just a reminder of the project’s established change control procedures).
 Help stakeholders interpret the requirements documentation. Where feasible and applicable,
provide supporting or reference material to assist interpretation and understanding of the
requirements. This may include glossaries and data dictionaries, diagrams, etc. It is also very
helpful to maintain a log of all decisions that are made throughout requirements definition, and
publish this decision log with the requirements to avoid revisiting past decisions.
 Make sure stakeholders have enough time to review the requirements during sign-off. Plan ahead
for review and sign-off cycles as much as possible. Remind stakeholders of this commitment 2-3
weeks prior to each review cycle, so they have enough advance notice to plan for the time
needed.
 Foster collaborative ownership on multi-stakeholder projects. If a single document contains

requirements that are shared or jointly owned, individual stakeholders may be reluctant to sign-off
on requirements that they do not individually own. Joint review sessions can be used for
collaborative discussion with the goal of obtaining verbal approval from the group during the
session. Stakeholder questions or concerns can be addressed through the group review, which
will help expedite sign-off from each individual participant.
Why is requirements traceability important?
ANSWER
Requirements traceability is the ability to follow and audit the life of a requirement, in both a forward
and backward direction; from its origins, through its realization in the design and functional
specifications, to its eventual development and deployment and use, through subsequent rounds of
modification and refinement.
If a requirement is changed or modified, using a requirements traceability matrix the analyst can
identify those areas within the functional specifications that are impacted by the requirement and
make the appropriate modifications. In addition, the analyst can determine if the portion of the
specification being modified traces back to any other requirements. This is important to ensure that
the new modification doesn’t break any existing requirements within the system.
Similarly, sections of the specification can be traced to areas of the physical code to ensure that all
required changes are made during the development process. Test cases can also be traced back to
functional specifications. When functional specifications are changed test cases nearly always need
to be updated to ensure complete and accurate testing can take place.
What are the difference between a Business Requirement Document

(BRD) and a Functional Specification Document (FSD)?
ANSWER
Business Requirement Documents are written to define the requirements of a business process or a
system that needs to support a business process. For purposes of contrasting the Business
Requirement Document (BRD) and the Functional Specification Document (FSD), the description of
the BRD that follows is written in terms of preparing a BRD for a system. The exact scope of a BRD
and FSD vary from company to company. However, the two documents are typically defined as
follows:
The BRD contains the business requirements that are to be met and fulfilled by the system under
development. These requirements specify "what" the system must do in order to fulfill the
requirements of the business. They often take the form of "The system shall..." Each requirement,
or group of similar requirements, is typically accompanied by a business rationale. The business
rationale explains "why" the business requirement is necessary. This is often important later if
analysts or developers have questions regarding the purpose or validity of the requirement. The
rationale can be used to support the need for the business requirement or clarify ambiguous
language by providing a context for the requirement. In addition to a rationale, constraints can be
provided for each requirement along with other supporting reference material.
In contrast, the FSD defines "how" the system will accomplish the requirements by outlining the
functionality and features that will be supported by the system. Ideally, the functionality of the
system will be described in logical terms so that the FSD is technology and platform independent.
This gives the architects and developers more freedom in making development and design decisions
about the physical design of the system. Inevitably, however, some things have to be explained in
physical terms. The User Interface is one such example. Many FSDs include screen mockups or
wireframes for communicating the layout and design of the system screens.
Requirements Analysis (BABOK KA)
document)?
ANSWER
use.
characteristics:
As a BA (business analyst) approaching a new piece of work, who

would you interview and what questions would you ask?
ANSWER
For any new piece of work a BA (business analyst) needs to know
1. Who are the key stakeholders (i.e. those who can kill the project?)
2. What are the key stakeholders specific and measurable measures of success (i.e. their
objectives) and what VALUE for each objective MUST be achieved in order for the project to be
considered a success (e.g. increase sales per order value by 5%)
3. What are the key stakeholders unmeasured measures of success (i.e. their principles that they
would like to see happen but aren't going to measure and so the project cannot be assessed by
them - e.g. an intuitive solution)
4. What are the key stakeholder’s high level requirements (i.e. what capabilities do they expect the
solution to deliver - e.g. the ability to offer add-on sales during the order taking process)
5. What is in scope of the work in terms of processes, organization units, locations, data,
applications, technology?
6. What is the scope of the work in terms of time, money, project resources (people and materials)
7. Who will the stakeholders nominate for determining further high level requirements and detailed
requirements (e.g. subject or domain experts, middle management of operational teams, etc)
How does the Business Analyst role change on an agile project

compared to projects using other software development
methodologies?
ANSWER
The role of the BA should actually change very little between different software developments
methodologies, although the tools and techniques used by the BA can vary according to the needs
and attributes of any given project or development lifecycle.
The core responsibilities of a BA on a software development project include requirements elicitation,

requirements analysis and requirements management – regardless of the project methodology. The
type and format of requirements documentation are just tools, and a good BA has a wide range of
tools at his or her disposal.
Accurate and effective elicitation of requirements from stakeholders is one key part of the BA role on
any software project. The BA is responsible for ensuring that requirements are clearly articulated,
resolving inconsistencies and ambiguities, and synthesizing individual requirements into a unified
solution. An Agile project may utilize specific tools and techniques for collecting and documenting
requirements, but the elicitation role still exists on an Agile project as it does on any other project
type.
Analysis of requirements is a second key part of the BA role on any software project. The BA is
responsible for addressing gaps and conflicts within requirements, identifying and coordinating
interdependencies and relationships between different requirements, and ensuring that requirements
fit seamlessly together to produce the envisioned solution. This analysis role is equally applicable
whether requirements are documented as user stories, use cases or a functional requirements
document.
The third key part of the BA role on a software project is requirements management. The BA is
responsible for ensuring that requirements remain linked to business value and business outcomes,
tracing and overseeing requirements from initial elicitation through to final delivery, and preserving
the integrity of the business solution from project start to finish. This role is necessary whether the
project is Agile, iterative, waterfall or anything in between.
These tasks all require certain expertise, skills and techniques that have been developed, promoted
and refined under the Business Analysis profession. Even if these tasks are assigned to any other
project member from developer to product owner, that person is still fulfilling the Business Analyst
role.
How are non-functional requirements defined and managed on agile

projects?
ANSWER
Non-functional requirements (NFRs) are typically defined as backlog constraints on an agile project,
and are managed as part of both product backlog and scrum backlog. They are revisited as part of
the ‘Definition of Done’ for each iteration or sprint. If the system does not meet any given NFR, that
NFR may spawn new backlog items such as refactors or performance enhancements.
Well-defined NFRs should meet the following criteria:
 Bounded: Each NFR should describe the scope of the system to which it apples (its ‘boundary’).
Many NFRs apply to the entire system (such as extensibility or portability); however others may
be bounded to specific components for feasibility and/or cost-control reasons. Critical functions or
components may have stricter non-functional requirements for availability or performance for
example, while others (such as administrative functions) may have less stringent needs for these
particular NFRs.
 Independent: NFRs should be independent of each other, so they can be evaluated and tested
without consideration or impact on other system attributes.
 Negotiable: Like functional requirements, NFRs return a quantifiable business value in return for
a definable cost. The cost of an NFR should not exceed its expected value, and may need to be
negotiated to align both cost and benefit.
 Testable: If you can’t test it, you can’t deliver it. NFRs should be stated with objective,
measurable and testable criteria just like functional requirements.
What are some steps the Business Analyst can take to avoid vague,
incomplete or ambiguous requirements?
ANSWER
Stakeholders often interpret requirements in a variety of different ways. Whether it's from the natural
ambiguity of conversational language or due to missing information, ambiguous and incomplete
requirements can lead to project delays and budget overruns. But by keeping a few key
considerations in mind the Business Analyst can dramatically improve the quality of product
requirements.
1) Define a Terms Glossary
One of the most impactful steps towards unambiguous requirements is the creation of a glossary of
terms. There are two primary benefits of a glossary. First, while creating the glossary all
stakeholders start to realize that many business terms mean different things to different groups
within the organization. This is the time to settle on the exact meaning of a term, at least for how it is
to be understood within the context of product requirements. Second, once the glossary is created
the business analyst now has a finite and clearly understood set of terms to use when writing
requirements eliminating multiple interpretations. A glossary alone removes much of the ambiguity of
written requirements. However, the benefits of a glossary can be further extended by creating a
Business Entity Diagram which defines terms business concepts (entities) by defining their
attributes, relationship to other entities, and cardinalities.
2) Write Test Cases Against Requirements.
All requirements should be testable and verifiable. If you can't define tests that show the requirement
to be properly implemented then the requirement is likely incomplete or ambiguous.
3) Avoid Non-Testable Words
Non-Testable words require interpretation by the reader and each reader may interpret these words
differently. The types of words also tend to lead to untestable requirement statements. Some
examples of non-testable words are:
 minimize
 maximize
 optimize
 quick
 robust
 user-friendly
 intuitive
 et cetera
 efficient
 flexible
How to you test that something is minimized? Instead, a requirement using this language should
define a specific testable value to show that something has be sufficiently reduced.
4) Create Visual Models
Visual models are ideal for communicating information in an easily digestible manner. Different
models can be used to convey different views of the same information. The structure of visual
models can help reveal gaps in information and product requirements that may otherwise go
unnoticed.
What techniques have you used to elicit business requirements?
ANSWER
There are a number of methods used for eliciting and discovering requirements. These methods
can be categorized into two main categories:
Collaborative Interaction - these methods offer the most access to the customer and result in more
accurate requirements (though they may be more time intensive/expensive):
 Face-to-face Interviews
 Focus Groups
 Requirements Workshop
 Brainstorming and Idea Reduction
 Role Playing
Restricted Interaction - these methods control more strictly the way in which you interact with the
stakeholders:
 Observation and Job Shadowing

 Prototype Walkthroughs
 Questionnaires
 Electronic Interviews
 Legacy Code Analysis (Reverse Engineering)
 Reading
What is the business case for using personas?

ANSWER
Many organizations that lack experience with personas don't fully understand the value of them.
Furthermore, personas can be difficult for the inexperience team member to properly create.
The most common question tends to be, "We are trying to increase business and our customer
base. How does focusing more on 1 or 2 personas align with this goal?"
Intuitively people tend to think that in order to satisfy the needs of a large audience or wide array of
users they need to make the functionality of the product or application as broad as possible. This is
wrong. When you try to design for everyone, you delight no one. You end up with a very mediocre
product. If you focus on delighting your primary persona then those represented by your secondary
persona(s) should also be satisfied due to overlap in needs. A good analogy to remember is this:
widening your target doesn't improve your aim.
So what happens without the use of personas?

 Every time a customer makes a request the design changes because the team is trying to satisfy
the desires of everyone.
 Everyone on the team has a different idea about who they are designing for.
 Team members end up making design decisions based on what they believe the user would
prefer which can vary from team member to team member.
 The team struggles to understand how requirements and features should be prioritize.
 The user that the team is designing for is only vaguely understood leading to lots of blurry edge-
requirements.
 The team spends precious develop time on edge-features that rarely ever get used.
Of course, these problems may not be immediately obvious to management. While you can have
discussions about the benefits and value of personas sometimes it's best to just show them. After
all, you don't need permission to do good work.
Go ahead a make a couple of personas on your own and demonstrate how they help the team make
better decisions. Of course, some personas require a fair amount of research and time to properly
create. But when there is limited time to allocate you can create what some call proto-personas.
These are personas which are based on secondary research and educated guesses by the team
about the archetypal person you are designing for.
What are the essential components of a use case?

ANSWER
1) Use case name: The use case should be labeled so that it immediately describes the purpose of
the use case. Usually, VERB/NOUN is sufficient. For example, “Place Order.”
2) Actors: Identify who the main individuals and systems involved in the use case are going to be.
Any actor that is used in the use case’s flow of events must be named up front.
3) Assumptions/Pre-conditions: Define what the state of the world is prior to the beginning of the
flow of events described in the use case.
4) Post-conditions: Explain what the state of the world will be once the flow of events described in the
use case occurs.
5) Business rules: These are the operating rules that govern or constrain the environment in which
the process flow happens. For example, “placing an order can only happen between 9AM and 5PM” is a
business rule. The use case must obey these rules.
6) Normal process flow: Define the “happy path” for the process flow, step by step and sequentially
numbered. The “happy path” essentially means what the default flow is, without accounting for
exceptions, conditions, or errors. It should lead to the successful conclusion stated in the post-
conditions.
7) Alternate process flows: When there are major decision points or exceptions that create a
different path to the conclusion of the use case, then each of those alternate process flows must be
defined step by step just like you did with the normal process flow. If you numbered the normal process
flow sequentially and the alternate flow begins in a certain step, you can just start the description of the
alternate flow from there.
What are the basic types of actors that can exist in a Use Case
Diagram?
ANSWER
Actors can be primary or secondary actors. Primary actors initiate a use case, while secondary
actors support a use case or receive something of value from the use case. While this answer might
score you some points in the interview, there is another way to classify actors that is important to
know and can show that you understand some of the finer points of use case diagramming.
Actors can be:

1. Human
2. Systems/Software
3. Hardware
4. Timer/Clock
Many analysts miss key actors during the use case diagramming process because they only identify
human actors. Categorizing use case actors in this ways helps the analyst ensure they haven’t
overlooked any critical actors within the use case diagram.
How should the Business Analyst begin the requirements elicitation

process for a new product or solution?
ANSWER
When beginning analysis on a product or solution that is needed to meet a business need, the
Business Analyst needs to obtain a basic understanding of the pain points that the business wants to
address.
At this stage of this process there is only a need to get the equivalent of a business executive’s point
of view. That is, the analyst needs to get a high level understanding of the pain points, framed
through the six basic questions someone needs to ask in order to understand any object: Who,
What, Where, When, How, and Why. Let’s take each of them in turn.
Who
It’s necessary to understand who has the pain point the business wants to address, as well as who
the beneficiary of the product or solution will be. These are often the same people, but may not be.
For example, the company may lose customers because a product doesn’t work properly or doesn’t
have a necessary feature, and a business executive may “feel the pain” by being accountable for
that loss. You want to know about both of these types of people, as well as other stakeholders who
are significantly impacted by the proposed change.
What
It’s also important to know about the data and information that are relevant for the pain point and
proposed solution. At the highest level, this is a question of concepts— “the user,” “the customer,”
“the billing history data”—and their relationships to one another. They’re the kinds of things you
would see in a conceptual data model. You need this information so that you understand all of the
“objects” involved apart from the people, whether objects are inventory, authoritative data, or
whatever is relevant
Where
This question is of lesser importance early on, but becomes more so as you define your
requirements better. Where is the location of any object or person relevant to the pain point or
solution? This may refer to physical locations, computer server or cloud locations, and so on. The
underlying issue here is the network—you want to know what kind of impact the pain point and
proposed solution affect the relevant network and the things connected to it.
When
You need to know the time strictures that the solution is under. When must a solution be delivered,
and what are the reasons for that? Knowing the answer to “when” helps you start thinking about the
feasibility of implementing particular requirements as you gather them.
Why
This is pretty important to know. What is the pain point, anyway? What are the business drivers
behind the requested product or solution? The answer to this question provides the impetus for the
entire project, so it’s necessary to know the answer on Day one.
How
This question is not as useful as you would think at first. When business needs and pain points are
first being expressed, the focus should be on defining what those needs are. Although the business
may have a general idea of the kind of solution or product they want, closer analysis may reveal an
entirely different approach than what was first envisioned. The question of “how” becomes a lot more
useful when you have defined requirements and are conducting business process modeling and re-
engineering. It is also more useful for the systems analyst or architect later down the line who must
actually make decisions about the technologies and approaches to use.
Nevertheless, you should get a basic idea of what the business has in mind in terms of changing its
processes and possible solution options to help begin framing the project. Just don’t let that
framework bind you too tightly later on down the line.
Once you have answered these six basic questions you are in a better position to proceed to full
requirements analysis.
What is a JAD meeting and what is the Business Analyst's role in
one?
ANSWER
A JAD is a Joint Application Development (or Design) meeting. It is an opportunity for stakeholders
with different points of view to come together to understand business requirements and brainstorm
what the best technical approach might be for meeting the customer's needs.
A JAD is a challenging environment because it is a meeting or workshop that brings together people
from a number of different disciplines. They could include business or product owners, systems
analysts, enterprise architects, solution architects, software developers, and managerial staff. Each
will come with their own points of view and may at times resort to lingo specific to their focus area.
The Business Analyst (BA) frequently stands front and center as the facilitator of a JAD and as the
presenter of what the business needs, objectives, and requirements are. The BA may also further
elicit requirements as needed.
As facilitator, the BA's job is to ensure the meeting keeps running smoothly. That requires setting the
agenda, making sure the agenda items are being met, help brainstorm when discussions become
snagged, and bring order when discussion gets heated or defensive. The BA should come prepared
with copies of the agenda and business requirements documents.
If asked to serve as the representative of the business, the BA must be fully informed of what the
business needs are and be prepared to discuss and explain them. That may mean responding to
questions from the technical staff with regards to how the business would like to see something
implemented.
If other business stakeholders are present, the discussion between them and the other JAD
members may cause them to realize that additional business requirements need to be captured. The
BA would elicit and capture those requirements. If technical requirements come to light, the BA may
capture those if they have the necessary expertise, or else rely on a systems analyst to do so at the
meeting.
A JAD is successful, and therefore the Business Analyst is successful, when there is a "meeting of
the minds" among all of the individuals present with agreement on what kind of solution needs to be
developed to fully address business needs, with all requirements put in writing to facilitate
development.
What is the difference between a use case alternative flow and an

exception flow?
ANSWER
A use case specification describes the functionality of a system in terms of a sequence of user-
system interactions. The main flow of events describes a single path through the system. It
represents the most common way that the use case plays out successfully and contains the most
common sequence of user-system interactions. Other scenarios or paths through the system are
described in alternative flows and exception flows. So what is the difference between and
alternative flow and an exception flow?
First, it’s worth saying that there’s a number of differing opinions in this area since the Unified
Modeling Language has no standard for Use Case Specifications. Some authors mention only
alternative flows and use them for both optional user paths and error paths. However, among
authors who differentiate between alternative flows and exception flows, agreement has emerged.
An alternate flow describes a scenario other than the basic flow that results in a user completing his
or her goal. It is often considered to be an optional flow. It implies that the user has chosen to take
an alternative path through the system. An exception flow is an unintended path through the system
usually as a result of missing information or system availability issues. Exception flows represent an
undesirable path to the user. However, even though the exception flow has occurred the system
should still react in a way that recovers the flow and provides some useful information to the user.
The primary benefit of differentiating between alternative flows and exception flows is the focus that
exception flows bring to error conditions. By capturing all of the ways that the system can fail or
produce an error, the business analyst can be sure to create a design that mitigates the impact of
the error.
Why is requirements traceability important on a project?

ANSWER
Tracking and managing requirements traceability offers several valuable benefits to a project:
 Minimize Risk and Manage Costs. Requirements traceability lets you identify and analyze the
upstream and downstream impacts of any requirements change, so those impacts can be
effectively managed and mitigated.
 Manage Scope. Traceability provides an understanding the relationships between requirements

and identifies stakeholders who have a vested interest in each requirement, which supports
better decision-making about project scope and proposed changes throughout the project.
 Improve Quality. Traceability allows individual requirements to be managed within the context of
the full solution, and helps preserve the integrity of the end-state solution throughout each
development cycle or product release. It also helps ensure that all requirements are fully tested
and enables effective integration, system and regression testing.
 Increase Stakeholder Engagement. Requirements are clearly linked to vested stakeholders,

giving greater visibility of the value achieved for each stakeholder group throughout the project
lifecycle.
 Reduce Development Time. The ability to identify and manage groups of related requirements
results in more efficient and effective planning, and streamlines product development.
What is a Communication Diagram?
ANSWER
A UML 2.0 Communication Diagram models the objects or parts of a system, the interactions (or
messages) between them, and the sequence in which these interactions occur. There are a lot of
similarities between communication diagrams and sequence diagrams in terms of the information
they show, but because of how each diagram presents the information, one diagram may be better
at conveying or emphasizing specific information over the other.
Communication diagrams use a free-form arrangement of objects or parts of a system. This can be
compared to how classes and objects are laid out in UML class and object diagrams. Then the
interactions between the objects or parts of the system are show and labeled to indicate the
chronological sequence in which they occur. The free-form arrangement of objects lends itself wekk
to showing the sequenced interactions in a more compact space, allowing the analyst to place
objects that have the highest number of interactions with each other near one another. This is the
advantage of the communication diagram over the sequence diagram. While showing nearly all of
the same information as a sequence diagram, the communication diagram can, at a glance, place a
strong emphasize on which objects are interacting with one another
While communication diagrams are formally intended to show system objects and the interactions
between them, many analysts choose to create them at a higher level of abstraction. Instead of
showing the interactions between objects of a system, larger parts of a system may be represented
such as the interaction between web methods, web services, or entire systems.
By using the communication diagram in this way, it shows some similarities to a system context
diagram. The primary differences between the two are that a system context diagram places a focus
on a single system in context along with which actors and systems outside of the scope of the
system interact with it. Additionally, a system context diagram does not show the sequence of
interactions.
Describe the basic classification of requirements as defined.

ANSWER
The requirements classification schema used by the BABOK (v2.0) places requirements in one of
the following categories.
 Business Requirements
 Stakeholder Requirements
 Solution Requirements
 Functional Requirements
 Non-Functional Requirements
 Transition Requirements
Business Requirements define the goals and objectives of the business at the enterprise level.
These are requirements that apply to the organization as a whole rather than a specific group within
the organization. Business requirements are developed and documented as part of ongoing
enterprise analysis activities. Business Requirements, or Enterprise Requirements as I prefer to call
them, offer everyone within the organization a common understanding of why certain projects are
initiated. They are a compass for the organization providing a clear direction that can be followed.
While all requirements ideally should define something in measurable terms, this is even more
important with business requirements. Therefore, business requirements should outline a
corresponding metric and target that needs to be achieved by the business.
Stakeholder Requirements describe the goals and objectives of a particular group within an
organization. Like Business Requirements, they are intended to provide a higher level direction for
the stakeholder group, but often they are developed while considering the contending goals and
objectives of other areas of the organization that interact with each other. So, the stakeholder
requirements of various groups need to reflect an overall balance across the organization to support
and achieve the Business Requirements in the best possible way. This tighter coupling and
dependency between requirements causes Stakeholder Requirements to change more frequently.
Stakeholder requirements do not define what needs to be supported by a particular solution
(whether the solution is a business process or system solution), rather they span the gap between
Business Requirements and more specific Solution Requirements.
Solution Requirements describe the various characteristics of a solution that must be met. The
solution may be a process solution or a system solution. Solution requirements should be written in
a way that they also support and align with the Stakeholder and Business Requirements. Solution
requirements are defined throughout the requirements analysis process. They can be further
classified into two sub-categories:
Functional Requirements describe the behavior and information that the solution will
manage. In the case of a non-system solution, the behavior typically refers to a workflow and
the information refers to the inputs and outputs of the workflow. Additionally, the
requirements describe how the data will be transformed and by whom. In the case of a
system solution, the functional requirements describe the features and functionality of the
system as well as the information that will be created, edited, updated, and deleted by the
system.
Non-functional Requirements describe the qualities of the process or system. Instead of

describing what the solution must do non-functional requirements describe how well the
solution must do something. Non-functional requirements often describe qualities of a
process or system such as its repeatability, usability, reliability, interoperability, scalability,
extensibility, etc.
Transition Requirements describe any capabilities of the solution that aren’t permanent but instead
exist only to facilitate the transition from the current state to the future state. Once the process or
system has been developed and the transition of users and information from the current solution to
the new solution has occurred, these capabilities will no longer be needed or supported. Transition
requirements cannot be developed until both the current state and the future solution have been
defined.
What is the difference between a Business Requirement Document
(BRD) and a Functional Specification Document (FSD)?
ANSWER
Business Requirement Documents are written to define the requirements of a business process or a
system that needs to support a business process. For purposes of contrasting the Business
Requirement Document (BRD) and the Functional Specification Document (FSD), the description of
the BRD that follows is written in terms of preparing a BRD for a system. The exact scope of a BRD
and FSD vary from company to company. However, the two documents are typically defined as
follows:
The BRD contains the business requirements that are to be met and fulfilled by the system under
development. These requirements specify "what" the system must do in order to fulfill the
requirements of the business. They often take the form of "The system shall..." Each requirement,
or group of similar requirements, is typically accompanied by a business rationale. The business
rationale explains "why" the business requirement is necessary. This is often important later if
analysts or developers have questions regarding the purpose or validity of the requirement. The
rationale can be used to support the need for the business requirement or clarify ambiguous
language by providing a context for the requirement. In addition to a rationale, constraints can be
provided for each requirement along with other supporting reference material.
In contrast, the FSD defines "how" the system will accomplish the requirements by outlining the
functionality and features that will be supported by the system. Ideally, the functionality of the
system will be described in logical terms so that the FSD is technology and platform independent.
This gives the architects and developers more freedom in making development and design decisions
about the physical design of the system. Inevitably, however, some things have to be explained in
physical terms. The User Interface is one such example. Many FSDs include screen mockups or
wireframes for communicating the layout and design of the system screens.
How do you discover and elicit non-functional requirements?

ANSWER
Different organizations have different methods and processes for eliciting and discovering non-
functional requirements. Common ways of discovering non-functional requirements include:
1. Stakeholder goals, values, and concerns - Talk to the stakeholders! What a novel idea! ;-)
The analyst must find out what is important to the stakeholders (including the users), what qualities
are must have in order to achieve stated business and organizational goals. For example: must be
able to create a new transaction in under 2 minutes. Also, find out what are the stakeholders
worried about. For example: Users are afraid that the new system will be too slow (because the
current one is).
2. Legacy system and/or existing platform constraints - the analyst takes a look at constraints
dictated by the environment into which the new system must fit, the existing systems with which it
must integrate, and the technical platform(s) it must use.
3. Competitive analysis of system qualities - additional non-functional requirements can be

discovered by analyzing the qualities of competing systems. For example: how many users can the
competing system support and do we need to do better?
4. Industry and market trends - try to understand the direction the industry or vertical market is
taking and identify key trends. For example: What is the average annual growth of the industry in
number of transactions? Do customers expect faster and faster response times?
5. Standard non-functional requirements templates and categories - in many

organizations business analyst simply uses standard templates and categories in order to focus on
and ask questions about each type of non-functional requirement (could be done using a
questionnaire): usability, scalability, performance, availability, stability, extensibility, etc.
6. Pre-established trigger questions - many teams develop a set of trigger questions to be asked
of the stakeholders and development team. For example:
 Documentation & Training

 What kind of documentation is required and who will be the users of the documentation?
 How quickly should a brand new user be up and running on the system?
 Is there a need for context sensitive help?
 Performance Characteristics
 Are there any speed, throughput, or response time constraints on the system?
 Are there size or capacity constraints on the data to be processed by the system?
 Do performance requirements vary by: time of day, day of the week, type of user, etc.?
 Error Handling and Extreme Conditions
 How should the system respond to input errors?
 Is there a need to track errors via a mechanism such as error logging?
 Are there expectations on reporting errors: per categories, by business channel, etc.?
 External Interfaces & Interoperability
 Is there data coming from (going to) external systems?
 Are there restrictions on the format or medium that must be used for input or output?
 How must the data exchange with external systems function: real-time, hourly, daily, etc.?
 System Modifications
 What parts of the system are likely candidates for later modification?
 What types of modifications are expected?
 How often do you expect the system will need to be modified?
 Security
 What data managed by the system must be secure?
 Who, when, where should be able to access the system?
 Disaster Recovery & Business Continuity
 How often will the system be backed up?
 Who will be responsible for the back up?
 What data must be saved in case of a disaster?
 How quickly after a major disaster must the system be up and running?
 What is the acceptable system downtime per 24-hour period?
What are some of the problems you are faced with when gathering
requirements?
ANSWER
While this is a broad question, it is often used by interviewers to find out whether the candidate has
actually performed requirements elicitation in the past and has experienced its challenges. Once
challenges are mentioned many interviewers proceed to ask what the candidate has done or would
do in order to overcome those problems.
So, here are some of the problems faced by business analysts during the requirements
elicitation/gathering activities:
Contradicting/Conflicting Requirements - These are requirements received from different

stakeholders or from same stakeholder at different times and which cannot all be met at the same
time because their are in conflict. What the BA can do: get all stakeholders in the same room (if
possible), document and publish stakeholder requirements or meeting notes while they are fresh.
Communication Problems - This is a broad category of requirements issues and includes:

miscommunication, language barriers, wrong assumptions, unclearly defined vocabulary or domain
model, variance in vertical domain knowledge, using only one-way communication channels (over
the wall requirements), notation differences (lack of standards), etc. What the BA can
do: continuously improve communication skills, document info gathered and publish for
review/feedback, verify assumptions, create a glossary of terms, use multiple subject matter experts,
etc.
Undocumented Processes - This is the reality in most organizations. The business runs with "word
of mouth" or poorly documented processes and procedures. In these situations, to the high-level
executive it may look like everybody is doing the work the same way when the actual details/steps of
the process vary from end-user to end-user. The business analyst is often forced to reverse
engineer the business processes every time a new projects is started. What the BA can do:
Document existing business processes and the differences among the various users. Present the
documented processes to the stakeholders/high-level executives. If possible and within the scope of
duty, create and maintain an up-to-date library of existing business processes/operating procedures.
Lack of access to end-users - On many projects the stakeholders and IT management "think" they
understand the requirements and what happens in the business and do not enable or allow the
business analyst to have direct access to the end-users. What the BA can do: Present your case to
the project sponsor as to why it is key to observe the users at work and find out how each activity is
actually performed and the types of problems faced by the user in their day-to-day work.
Instability of UI Preferences - Stakeholders and end-users who are new to the requirement
elicitation process or who are faced with new or unprecedented concepts or processes tend to have
a hard time identifying (and feeling good about) their preferences and, therefore, they tend to keep
changing their minds. What the BA can do: use prototypes and other visual tools such as diagrams
to gather, document, and verify requirements.
Abundance of Choice - When stakeholders or end-users are presented with too many choices they
generally have a harder time deciding the option to select. When they do make a decision they are
less satisfied than if those who have to pick from a much smaller list of options. What the BA can do:
provide stakeholders and decision makers with more than option (when possible), however do not
give them more than 3 options to choose from.
Stakeholder Design - This is the case when the stakeholders or end-user have the urge to design
the system (how the system should work) rather than providing the requirements (what the system
should do). The problem with this pattern is that the BA is no longer able to distinguish between
requirements and design decisions. What the BA can do: ask the stakeholders/users what the
system should do and when you get the answer keep asking "Why?". Eventually you should be able
to get to the actual problems faced by the user and you'll be able to understand the "real"
requirements.
Bad Requirements - Requirements are considered "bad" if they are: ambiguous, incomplete, not
verifiable, etc. When stakeholders provide and analysts document bad requirements, they result in
systems which are not completed or not used. What the BA can do: develop a checklist of
characteristics and tests which you can check for each requirement to ensure all the requirements
send for sign-off are all good to go.
These are just some of the problems faced by requirements analysts during the elicitation process.
There certainly are many more.
Elicitation (BABOK KA)
What is a focus group and how do you conduct one effectively?
ANSWER
A focus group is an interactive guided discussion with a carefully selected group of people (usually
demographically diverse) used to obtain feedback about a product, service, or concept. A focus
group can be conducted before a launch and/or afterwards for ongoing feedback. Open-ended
questions are asked to the group and participants are encouraged to respond and interact freely with
other group members. As the facilitator guides the conversation either a scribe will take notes or a
video recording may also be made for further analysis and review at a later time. Focus groups
typically last for one to two hours.
To conduct and effective focus group both the preparation and facilitation are crucial, but much more
of the effort should be focused on the preparation stage.
Preparing for the Focus Group

 Determine Logistics - When and where will the focus group be held. The setting should
encourage conversation and make participants feel comfortable.
 Select the participants - Decide who needs to participate in the focus group in order to achieve its
purpose. Most focus groups have roughly 6 to 12 participants. Fewer participants limit
conversation, and more get unmanageable. Determine how many participants you need and the
key demographics and attributes of the group.
 Define the objectives and list of questions - a one to two hour focus group will likely only cover
four to eight higher level questions. Questions should be open-ended and move from very
general to more specific.
 Develop a script - in addition to your questions you will want to include opening and closing
remarks for the focus group.
 Identify your facilitator(s) (and scribe if a video recording is not being made) - The facilitator
should have a strong knowledge of the project and its goals. They also need to be able to deal
ensure all participants opinions are heard and that no one person dominates the discussion.
Running the Focus Group

 Introduce yourself and any others that will help facilitate the session
 If you are recording the session tell the participants and explain why and how the recording will
be used later.
 Set the tone of the session such that the participants feel comfortable sharing their opinions.
 Follow your script and present your prepared open-ended questions but be sure to allow for some
spontaneity. As the conversion progresses ask follow-up question that tease out specifics.
 Ensure free and open interaction among the participants. Help draw out quieter members and
make sure stronger members don’t dominate the conversation.
 Track your time so that you are able to progress through your prepared questions at a reasonable
pace.
How would you build a Business Process Model?
ANSWER
Building a Business Process Model is a complex task that requires a number of successful steps to
complete.
1) Determine scope
First, you need to figure out the actual scope of the work you are doing. Since business processes
often interact with other processes in a complex fashion, it’s important to draw a line between the
process that is in scope and the associated processes that are out of scope.
Another important item to determine is whether you are documenting the process that exists
(“current state,”) documenting an anticipated future change to the process (“target state,”) or both.
You may also be building an entirely new process from scratch.
2) Gather background information
The first step is to fully understand the process that you will be documenting as a Business Process
Model. You may read available documentation and Standard Operating Procedures. You may also
speak to people who are involved with the process on a day-to-day basis. The goal is to gain a high
level understanding of what the process is about.
3) Conduct interviews
Now that you have a high level understanding of the process, it’s time to dig into the details. This
often requires interviews with the subject matter experts most familiar with the new or existing
process you will be modeling. As you facilitate these interviews you must be able to aggressively
question every step of the process. Make sure you fully understand every decision point, activity,
manual or automated step, data source, message, and event.
As you do this you must define the “happy path” of the process, which is the default path when there
are no exceptions, problems, or conditions. This “happy path” must be clearly expressed in your
model. Once you fully understand the “happy path” you can delve into the necessary exceptions.
4) Begin Modeling
At this point you can start your Business Process Model. Ideally you should use Business Process
Modeling Notation (BPMN) 2.0, which is the current standard.
How you model depends on your organization’s capabilities. Many places use Visio, which is
perfectly adequate. If Visio is not available, then a tool such as PowerPoint can be used although
this makes modeling more difficult as it is not a dedicated platform for that purpose. A step up from
Visio would be a dedicated Business Process Management suite, which has features such as a
model repository and in some cases the ability to generate software code automatically.
5) Validate and iterate
Once you have built your initial model, it is time to validate and iterate it. Go back to your original
stakeholders and subject matter experts that you interviewed. Walk them through every step of the
process model. They are likely to find errors, and that is normal. Take their feedback and improve
the model in response. Then go back to them again, and repeat this until the model is perfect. You
then get your business sponsor to sign off on the model.
Your model is done until the time comes to expand or modify it.
What is a Product Manager?
ANSWER
The question “What is a Product Manager” seems simple enough, but few of us have taken the time
to define it.
The role of the Product Manager resides at the intersection between business, technology and user
experience. The paramount responsibility of a Product Manager is to ensure that the product they
manage (software, service, or other tangible product) creates value for the business. In turn, to
create value for the business the product needs to be of value to customers or to internal business
employees.
True value is based on how well a product satisfies a need or desire. For internal employees this is
often derived from time savings and simplification of processes. But for customers the need or
desire being fulfilled can take many forms. And ultimately the value to the customer translates into
revenue for the business.
The Product Manager must understand the needs of the customer and how specific features of the
product or service will fulfill such needs. This means one of their primary responsibilities is to
manage the product requirements over time and through multiple product iterations (multi-
generational product planning). Another primary responsibility is the prioritization of these
requirements. However, ultimately these features need to drive revenue and it’s the job of the
Product Manager to champion the monetization and pricing strategy that maximizes revenue for the
business given the dynamics of the marketplace. Understanding the market and the products price
elasticity is essential.
Products do not exist in isolation. It’s the role of the Product Manager to oversee market analysis
activity. This includes understanding the size of the potential customer base as well as the
competition that exists and how it affects the amount of revenue that the product can generate.
Market analysis activities need to be ongoing and market data must be revisited as competition
moves in and out of the market. If your product isn’t the only product available to the customer, and
it rarely is, then the pricing and revenue strategy will be impacted by the existence of competition.
This is what economist refer to as cross elasticity of demand.
In summary, the role of the Product Manager stretches across the business touching many different
business functions. It’s both a heavily strategic as well as a tactical role. This requires the Product
Manager to be adept at working with cross-functional teams. A strong understanding of business
management concepts, technology, and user experience is imperative.
What techniques do you use to plan and conduct requirements
elicitation workshops?
ANSWER
Prepare participants for the discussion by distributing supporting material prior to the workshop.
Send out draft documents, straw model diagrams, or even just a list of questions designed to
stimulate thoughts and ideas. Participants will be much more able to articulate their own ideas and
respond to others when they’ve had some time to think about the workshop topics in advance. This
approach is particularly helpful for participants who need time to analyze ideas and organize their
thoughts before speaking out. Without any material in advance, this type of participant often spends
the entire workshop trying to digest the information instead of actively participating.
Communicate the workshop topics and objectives to participants, and then stick to the plan.
Participants become frustrated and disengaged when the discussion is unfocused, or meanders onto
unexpected topics.
Document and publish notes from the workshop discussion, including any decisions that were made.
This helps ensure that everyone has a consistent understanding of the requirements discussed, and
the notes can be a valuable resource in resolving any subsequent churn or debate.
Are use cases the functional requirements or do you think functional

requirements are different from use cases?
ANSWER
It is generally accepted that use cases, specified in narrative form (also known as use case
specifications), depict functional requirements. This is because a use case, via the main and
alternate flows, shows how a user interacts with a system in order to achieve a desired result.
That's exactly the purpose of a "functional requirement" to describe the functions and behaviors that
a system is or should be capable of.
Therefore, if use cases are used and narrated in detail for a project, there is no need for separate
documentation to describe the functional requirements because the totality of all the use cases
represent the set of functional requirements for a given system/project.
What is a Vision Document?
ANSWER
"What is a Vision Document? What are the typical sections in it? Is it different from a Business
Case?"
The Vision
Let's discuss first what is considered the "Vision". In general, the Vision represents the end user's or
customer's ideas and views of the software product to be developed. Think of the vision as the
"idea". In an entrepreneurial environment, the entrepreneur starts with an "idea" which is later
turned into a tangible product, service, etc.
Same is the case with software projects; they all start with an idea or vision related to the types
of needs that might be addressed by a system having certain features.
The Vision Document

Many organizations capture the Vision in a "Vision Document" which generally contains the key
business needs and features of the system from the stakeholder perspective. The Vision Document
is simply a mechanism to put down on paper "the idea".
There are many different types of templates for a Vision Document depending on the methodology,
organization, project size, etc.
The Business Case

Yes, the Business Case is different than the Vision. Whereas the Vision represents the "idea", the
Business Case is the "rationalization" as to why the Vision is a good idea and how the Vision will be
implemented. The Business Case begins the discussion, at the high level, on how the project might
be implemented: cost, resources, timelines, etc.
The Vision Document Template

The Vision Document defined by RUP (Rational Unified Process) includes the following sections:
1. Introduction
 1.1 Purpose
 1.2 Scope
 1.3 Definitions, Acronyms, and Abbreviations
 1.4 References
 1.5 Overview
2. Positioning
 2.1 Business Opportunity
 2.2 Problem Statement
 2.3 Product Position Statement
3. Stakeholder and User Descriptions
 3.1 Market Demographics
 3.2 Stakeholder Summary
 3.3 User Summary
 3.4 User environment
 3.5 Stakeholder Profiles
 3.5.1 <Stakeholder Name>
 3.6 User Profiles
 3.6.1 <User Name>
 3.7 Key Stakeholder or User Needs
 3.8 Alternatives and Competition
 3.8.1 <aCompetitor>
 3.8.2 <anotherCompetitor>
4. Product Overview
 4.1 Product Perspective
 4.2 Summary of Capabilities
 4.3 Assumptions and Dependencies
 4.4 Cost and Pricing
 4.5 Licensing and Installation
5. Product Features
 5.1 <aFeature>
 5.2 <anotherFeature>
6. Constraints
7. Quality Ranges
8. Precedence and Priority
9. Other Product Requirements
 9.1 Applicable Standards
 9.2 System Requirements
 9.3 Performance Requirements
 9.4 Environmental Requirements
10. Documentation Requirements
 10.1 User Manual
 10.2 Online Help
 10.3 Installation Guides, Configuration, and Read Me File
 10.4 Labeling and Packaging
A. Feature Attributes
Data Analysis & Modeling
document)?
ANSWER
use.
characteristics:
What is a Fact Model?

ANSWER
A Fact Model is a static model which structures business knowledge about core business concepts
and business operations. It is sometimes called a business entity model.
The fact model focuses on the core business concepts (called terms), and the logical connections
between them (called facts). The facts are typically verbs which describe how one term relates to
another. For example, the two terms Person and Car may have a fact connecting them called Owns
(a Person owns a Car). The same two terms may also have a different fact connecting them called
Drives (a Person drives a Car). The facts, which connect the terms, should do so in a way which
reflects the real world since the primary purpose of a fact model is to create a standard vocabulary
by which all stakeholders can communicate unambiguously.
The business knowledge represented in a fact model should be at the most atomic level of business
knowledge, meaning it should not be able to be further deconstructed and it cannot be derived from
other knowledge. By using the standard vocabulary defined by the fact model, these basic building
blocks can be used to develop and communicate more advanced forms of business knowledge,
such as business rules, in a clear and unambiguous way.
Fact models are incredibly useful regardless of whether it is a system solution that is being
considered or a process solution. However, if the solution is a system, the fact model can be used
as an input into the development of the data model in later stages of the SDLC.
What is SQL and would a business or systems analyst use it?

ANSWER
SQL is a standard scripting language designed for managing data in relational database
management systems. SQL stands for Structured Query Language. SQL became an ANSI standard
in 1986, and an ISO standard in 1987. Since SQL is a standard, a working knowledge of the SQL
language used on one major RDBMS (Relational Database Management System), such as MySQL
or DB2, can be leveraged for others. However, issues still exist with portability of the actual SQL
code from one RDBMS to another. This is typically attributed to the RDBMS not being fully
compliant with the standard, or the standard has been interpreted differently. Still, the variation of
SQL used doesn’t usually vary too significantly from one RDBMS to another.
It’s helpful for analyst to have a limited theoretical knowledge of the capabilities of SQL. This
includes SQLs ability to create and drop (delete) database table in order to create and modify the
database schema, insert new data or update the existing data within table columns, query the data,
and manage data access.
While much of the capabilities of the SQL language go beyond that which a business or systems
analyst would need to understand in detail, it often helps for analysts to learn the specifics of SQL
querying using SELECT statements. This allows the business analyst to perform a certain amount
of data analysis and testing on their own.
The following is a sample SELECT statement where data is being selected from the “isbn”, “title”,
and “price” columns of the “Book” table:
SELECT isbn, title, price, price * 0.06 AS sales_tax

FROM Book
WHERE price > 100.00
ORDER BY title;
What are OLTP systems?

ANSWER
OLTP or On-Line Transaction Processing systems are a class of systems which contain current,
operational data used to control and run fundamental business tasks. OLTP systems are typically
characterized by their ability to complete many concurrent database transactions and are designed
for optimal database transaction speed. Additions and changes to data are user initiated (rather than
scheduled) and conducted via short, atomic transactions.
Queries of OLTP systems are typically simple and return relatively few records. The structure of
OLTP databases are highly normalized which means tables and fields are organized to minimize
data redundancy and dependency. But this doesn’t lend itself to efficient processing of complex
queries. More complex querying is typically run against historical data stores which are classified as
OLAP systems (On-Line Analytical Processing) or Data Warehouses.
Transaction and data recovery is paramount for OLTP systems since they deal with current business
data used to conduct real-time business operations. Similarly, OLTP systems are often decentralized
to avoid single points of failure. This can also help spread volume over multiple servers to maximum
the volume transaction processing possible and minimize response times.
SDLC, Process, and Methodologies
Agile: User Stories versus Epics, what's the difference?
ANSWER
User Stories and Epics make up the essential building blocks of agile planning and development.
They are closely related and, therefore, the differences are often misunderstood.
User Stories
 A user story is self-contained. It can be fully coded and tested to ensure it meets expectations.
 A user story is a chunk of work that has been agreed upon through collaboration between
developers and stakeholders.
 User stories are the building blocks of your sprint.
 User stories may roll up to create Epics (think larger user stories)
 While user stories that make up an epic are self-contained, their business value often isn't
realized until the entire epic is complete.
There are times when one user story is dependent upon another, but this should be avoided
whenever possible. For example, instead of having user stories 1, 2a, 2b, and 3, where 2a is
dependent upon 2b for completion, if possible 2a and 2b should be combined into a single user story
(if not too large).
Describe the Six Sigma methodologies?

ANSWER
Six Sigma is a process improvement methodology. It is structured into 5 phases which can be
iterated to continually improve key processes and deliver greater efficiencies and success within an
organization. These 5 phases are Define, Measure, Analyze, Improve, and Control expressed as
the acronym DMAIC (pronounced dee-may-ic). Six Sigma, being a process improvement
methodology, views the entire world in terms of processes—processes that achieve goals,
processes that act on data, etc.
Define – The define phase is used to define the problem that has been identified. The term “voice of
the customer” is often used within Six Sigma. The voice of the customer is used to understand
where the problem resides. This could be an external client or an internal client such as business
workers that are involved in a specific business process that is not performing as well as it could.
While defining the problem, clear goals of the project are outlined. The goals should define what will
make the process better or what is “critical to quality”.
Measure – The measure phase takes the defined problem and measures key aspects of the current
state process. Collecting of this data is necessary to ensure that the results of the control phase can
be compared against those of the measure phase and objectively show that the process has been
improved to the degree expected. You may have heard the phrase “you can’t improve what you
can’t measure”.
Analyze – In the analyze phase the data captured in the measure phase is analyzed to understand
cause-and-effect relationships and perform root cause analysis. The equation y = f(x) is very
popular in Six Sigma. It emphasizes that some problem domain “y” is a function of “x” where “x” are
the inputs or factors that drive the outcome “y”. Analyzing the data from the measure stage is
intended to uncover all of the inputs that have a significant impact on the outcome of the process.
Improve – The improve phase is where the current process is redesigned based upon the analysis
that was completed in the analyze phase. By ensuring that the inputs to a process are available at
the right time and in the right condition, the outcome of the process should improve. And really the
process can be just about anything. Consider requirements as an input to the development of an IT
system. If it’s found that the quality of the input (requirements) is subpar, the team can focus on a
better process for gather requirements which will result in an improved project outcome. Once the
new process is designed it should be tested or prototyped before implementing. The results of the
tested process can be measured to ensure that the desired improvements are being realized.
Control – The control phase is an important step in the DMAIC process. It emphasizes the need to
continually monitor the improved process to ensure that any deviations from the targeted outcome
can be corrected. Without the control phase the benefits of many process improvement initiatives
would begin to decrease over time. The control phase can also be used to uncover new areas for
improvement and the DMAIC process begins all over again.
Describe the life cycle of a User Story?

ANSWER
User Stories are used by agile methodologies to capture the functionality that a system or software
should support. For details about what a user story is and how to write one reference What are User
Stories.
At the beginning of a project user stories are identified and developed in a story writing workshop – a
brainstorming session in which the agile team comes up with as many user stories as possible (the
agile team commonly includes some combination of customers, product manager, developers,
testes, etc.). Each story is sized and prioritized for the first time. This prioritized list creates the
Product Backlog (Release Backlog). During the workshop the team selects an iteration length
(usually between 1 and 4 weeks) and also the rate at which they will be able to complete user stories
(call the velocity), both of which become important when determining how to schedule user stories
later in the process.
During the iteration planning process, the user stories contained in the product/release backlog are
segmented into iterations or sprints. The user stories for the first sprint make up the sprint backlog.
Once the first iteration is ready to kickoff, conversations begin for each user story between members
of the agile team. The user stories get updated with details of the conversation, captured in the form
of acceptance tests.
The user stories can be updated at any point as needed up until the iteration coding has been
completed.
If a user story cannot be completed during the iteration for some unforeseen reason, it is returned
back to the product backlog and rescheduled for another iteration.
Many agile methods call for discarding user stories once they have been coded and implemented.
However, agile methods are flexible and adaptive, so the determination of whether to save and
maintain user stories typically varies from company to company.
Which is better: Waterfall or Spiral development?
ANSWER
When asked a question such as this, the interviewer is clearly looking for more than a one word
answer. Pointing out accurate and relevant pros and cons of each method is far more important
than your final opinion. An answer such as the following might be suitable.
The choice of SDLC methodology for a project largely depends on: (1) the type of project, and (2)
the environment or organizational culture within the project takes place. With that said, a Spiral
method is superior for the vast majority of projects today, especially those which include the
development of customer facing products.
When the Spiral method was first introduced, it was intended for use on very large and complex
problem spaces. It incorporated characteristics of the Waterfall method (Requirement Elicitation,
Analysis, Design, Code, Test), but did so in an iterative way. So first, it should be noted that the two
are not exactly mutually exclusive. However, while each iteration of the Spiral method may have
originally been intended to span 6 months to even a year or more (an entire little waterfall of its own)
with the advent of Agile methods in recent years, the iterations of the Spiral method have become
compressed to a much smaller time frame; sometimes as short as 2 weeks, but often just a month or
two.
Any iterative method can provide a number of benefits over its Waterfall counterpart:
 Availability of working software much sooner which allows for more immediate feedback from
application users
 More immediate, and therefore larger, ROI from software features that are developed in short
iterations and released to production immediately
 Less project overhead due to the smaller team sizes that ware typically required for smaller units
of work
 Avoidance of large schedule overruns
 Avoidance of large budget overruns
 And of course, the ability to test if what seemed so good in theory actually works well as
functioning code
This is where the discussion of most analysts typically ends. However, there are also some
downsides to a Spiral method.
It can become easy for an agile team following a Spiral method to fall into the habit of doing sloppy
upfront analysis, since a miss of a requirement or feature can be fixed in a future iteration. While the
Spiral method does mitigate some of the effects of missing important items, this laziness can also
eliminate an important advantage of a Spiral method; capturing additional ROI from the early release
of features.
Finally, and most importantly, any iterative method means that portions of a product/application are
being designed and coded before the entire scope of the design is known. This can lead to a large
amount of UI and code refactoring; refactoring being the term used to describe the redesign and
recoding of portions of the existing system in order to accommodate new features and functionality.
At the very least, this can mean significant re-work that might have been avoided. However, some
early system design and architectural decisions can sometime constrain what is achievable down
the road. So, at its worst, this could mean an eventual redesign and re-write of an entire product or
system.
This doesn’t mean that a Spiral method shouldn’t be used. In most cases, its advantages far
outweigh its disadvantages. But project team members should be aware of the risks such that they
can establish processes and habits early on that will help mitigate these risks.
List the steps you would take to bring a product from idea to
deployment and beyond.
ANSWER
There are many ways this question could be answered based on the type of SDLC method being
used and other environmental considerations.
The steps outlined assume the marketing and promotion of the product will be handled by another
group. An iterative/Agile approach has also been assumed and combined with User Centered
Design principles, though other approaches could be used.
1. Market Analysis: Market Analysis is a critical step to perform before deciding to undertake the
development of any product. Research needs to be performed to determine:
i. The size and demographic of the potential market
ii. The needs of the target demographic
iii. The growth of the market; is it growing and at what rate, or is it contracting
iv. Competition within the market; who are the key players
v. Is there a widely excepted cost structure for the product that is being introduced
vi. Based on the cost structure that is to be chosen, what kind of profitability can be expected?
This can be determined by performing a Cost-Benefit Analysis.
2. Competitor Analysis: For the competitors identified during market analysis:
. Understand the features offered by the competitors product
i. Compare each competitors feature to those feature which are deemed to be most important to
your targeted customer base, and rank each competitor based on the results
ii. Speculate as to the strategic direction each competitor may be taking
iii. Identify the clients of each competitor and determine which demographic segment they fall
into
iv. Understand the cost structure that each competitor uses for their product
v. Identify key weaknesses of competitors that may be able to be exploited, etc
3. SWOT Analysis: Combining information from the market and competitor analysis, it is often
helpful to perform and document a SWOT analysis to determine internal strengths, weaknesses
and external opportunities, and threats.
4. Personas: Develop Personas to reflect users of your product by market segment.
5. Strategic Vision and Feature Set: Determine strategic vision and feature set for product. This is
the start of your Product Backlog (features to be developed).
6. Prioritize Features: Create and initial priority for the features to be developed
7. Use Cases/User Stories: (Caveat: Use Cases and User Stories can mean very different things to
different people. There isn’t a single standard used throughout the industry) Create high-level
Use Case descriptions or User Stories for the features that are intended for the first iteration of
development. The objective of the use case description is to define the behavior of the features
without getting in to specifics about how the screens will support it.
8. Logical Data Model: In parallel with the Use Case descriptions, create a Logical Data Model (to
be further refined throughout the SDLC). The logical data model creates a common terminology
for referencing information that needs to be manipulated by the features of the product. It also
becomes a great starting point for the physical data model and database design.
9. Persona to Use Case Mapping: Understand which Usage Scenarios will be invoked by each
Persona. This ensures that the appropriate emphasis is given to the segment of the
demographic you are targeting as the highest priority.
10. Screen Mockups/Storyboards: Create initial Screen Mockups and begin Storyboarding for those
features which are prioritized for the first iteration of development. This will be a very iterative
process. There will be many ways to design the product/application to provide the feature
functionality as defined by the Use Cases. Also, as the team iterates through the screen
designing process it may become clear that missed features will need to be added, or a change
in the feature priorities needs to occur.
11. Product Backlog: Finalize the priority of features and create the Product Backlog which is the list
of all features that need to be prioritized, tracked, and eventually developed for the product.
12. Begin the first iteration of feature development
. For-Each Iteration
i. Logical Specifications: Create logical specifications to define the precise screen behavior.
This will include screen mockups, description of on screen behavior, screen transition
behavior and navigation, sounds, details about controls and the information (logical data
model) that each control displays or accepts from the user, etc. The Behavior can be
described textually using PseudoCode, or when appropriate process flow diagrams can be
used (UML Activity diagrams or similar)
ii. Test Cases: Create test cases reflecting the expected outcome for each usage scenario
iii. Physical Design Specifications: Translate the logical design into physical design. This may
include a physical data model and database schema design, static structure modeling
using techniques such as class diagrams to reflect the physical structure of the code, class
interface design, and behavioral modeling using techniques such as sequence diagrams as
necessary. While the design of the code and database at this level is primarily intended for
the iteration in progress, consideration should be given to the overall code and database
architecture to ensure appropriate scalability for large user populations and large numbers
of concurrent users.
iv. Write Code: Code to the specs
v. Unit Testing: Perform unit testing
vi. System Integration Testing: Perform system integration testing based on the test cases
created prior to coding
vii. Regression Testing: Regression Test the application using test cases from prior iterations
to ensure that new changes didn’t introduce unforeseen bugs.
viii. Deploy Code: Deploy the code and release the product. Depending on the situation this
may be a beta release with a pre-defined set of beta users.
i. Once the iteration is complete, then the next iteration can begin.
13. Metrics and Monitoring: After a product has been deployed, specific metrics about the product
can be tracked and monitored to see how the users are actually using the product. What do they
use frequently? What do they use infrequently? This is especially relevant for SaaS products.
Though even shrink-wrap software can have built in metrics tracking that is reported back to the
developing organization. This information can be used to further refine features and build the
product out in areas where it is found to be lacking.
14. Strategy for Scalability: For SaaS products, database/server monitoring should occur to ensure
that concurrent user activity can be supported. Strategies for scalability should be in place well in
advance of ever needing them.
Some of these steps could be combined, pared down, or avoided altogether depending on the
demands of the project and complexity of the product or application. Use the minimum amount of
tools, models, and specifications needed to communicate the necessary information to the coders in
a way that ensures the final product meets the expectations of the customer and is defect free. Once
might refer to this as “just enough documentation” – not too much, but not too little.
However, the decision to eliminate certain steps or deliverables should be a pragmatic one, and
should not be done out of laziness or a lack of understanding of the importance of a particular
deliverable.
What is a Daily Scrum Meeting?
ANSWER
The Daily Scrum Meeting, sometimes also called a Daily Standup Meeting, is a brief status meeting
where a team (ideally around 6-9 members) meets and updates one another on the work that has
been completed and what will be completed next. It provides an update to the entire team while
providing a daily refocus for each team member as they deliver their status.
The daily scrum meeting is led by a Scrum Master. The scrum master leads the scrum meetings,
measures progress, identifies obstacles that are slowing or stopping the progress of work, and
makes decisions about how to move forward when necessary. The Scrum Master should be
someone who has been given the authority to make immediate decisions whenever possible.
During each meeting the Scrum Master asks each team member 3 questions:
1. What did you do since the last meeting?

2. Were there any obstacles that impeded your work?
3. What will you do before the next meeting?
The Daily Scrum Meeting is ideally held at the same time and place each day for 15-30 minutes.
Standardizing the time and place of the meeting results in increased efficiency by eliminating
overhead associated with finding rooms to schedule and team members determining where they
should be each day. It also tends to decrease the number of late arrivals. A primary key to the Daily
Scrum Meeting is to keep it short. Any topics unrelated to the 3 questions asked of each team
members should be tabled during the meeting and handled at a later time.
How do you define Agile?

ANSWER
Agile is a general term and conceptual framework used to describe a number of “light-weight”
methodologies, such as Extreme Programming (XP), SCRUM, and Rapid Application Development (RAD),
which exhibit a series of common characteristics. Some of these characteristics include:
 Iterative analysis and development

 Time-boxed iterations of a predefined length
 Delivery of the most critical features and functions first
 Delivery of a complete build with an initial set of limited features within a few months (often 1-2
months)
 Small cross-functional teams usually of 6-9 team members.
 Daily team communication meetings
 Reduced levels of documentation
Most Agile methods begin with a prioritized feature list where features are group together into
deliverable chunks and assigned to a particular iteration in which they will be developed and
delivered. Using small teams and daily communication among all team members the Agile team can
achieve a high level of efficiency.
Agile methods are intended to overcome or circumvent many of the recurring challenges that are
encountered during software development projects. The iterative nature of these methods, along
with the desire to deliver smaller sets of defined features per iteration, help mitigate risk due to
evolving requirements, unclear project stakeholder direction, and unforeseen project complexities
that typically arise during the latter stages of analysis and development. Some of the most salient
advantages of Agile methods include:
 Availability of working software much sooner which allows for more immediate feedback from
application users.
 More immediate, and therefore larger, Return on Investment from software features that are
developed in short iterations and release to production immediately.
 Less project overhead due to smaller team sizes.
 Avoidance of large schedule overruns.
 Avoidance of large budget overruns.
What is the Scrum method?

ANSWER
Scrum is one of several light-weight agile methods that use an iterative and incremental approach
for the development of information systems. The Scrum method brings a small team together to
work on a specified set of features over a period of usually 30-days or so (called a sprint).
Both the term Scrum and sprint are borrowed from the sport Rugby. A scrum is where the two
teams are engaged in a huddle to begin play following a period where play has been stopped. The
fast moving period of play from the point of the scrum until play ends again is called a sprint.
The Scrum method starts each sprint with a kickoff meeting (a period where the entire team comes
together). The kickoff meeting lasts a full day and the features of the system to be developed are
discussed. The outcome of the kickoff meeting is a set of features that will be developed over the
sprint along with estimates of how long the analysis and development of each feature will take.
In order for a feature to be considered completed, it needs to be Analyzed, Designed, Coded,

Tested, Refactored, and Documented. If this life-cycle is not fully accomplished during the sprint,
perhaps due to an initial underestimation of the time required, the feature will be pushed to a later
sprint.
Following the kickoff meeting, and throughout the duration of the sprint, each day is started with a
short meeting lasting approximately 15 minute called a daily scrum meeting (also called a daily
stand-up meeting). The purpose of this meeting is for the team to discuss what they accomplished
the day before, what they will accomplish over the coming day, and to raise any obstacles that they
have encountered that may impede progress.
One aspect of Scrum, that is intended to keep the Scrum team and method very agile, is its size.
Most Scrum teams consist of no more than about 7 people with each falling into 1 of 3 roles.
 Product Owner – identifies the features that will be included in the next sprint and set the priority
of each. This is typically a high-level stakeholder in organizations where a true Product
Manger/Product Owner role doesn’t exist.
 Scrum Master – acts much like the project manager. While the Scrum Master does not micro-
manage the teams deliverables, this person ensures that the sprint is on track and enforces the
key rules that guide Scrum such as; no new features can be added to the sprint once it is kicked
off, and team members cannot be pulled off to work on other side project in the middle of a sprint.
 Team Member – unlike traditional software development methods, in Scrum there is little
separation of duties between team members. Each team member may fill the role of analyst,
designer, coder, tester, and documentation writer.
UML (Unified Modeling Language)
document)?

Business Analyst Interview Question Answers

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Business Analyst Interview Question Answers

Uploaded by

Copyright:

Available Formats

Enterprise Analysis (BABOK KA)

What is Business Capability Mapping and why it is beneficial?

How is the Purpose Alignment Model used to prioritize requirements?

The rated requirements are then organized into four quadrants:

What is Gap Analysis?

Gap analysis can be conducted on:

DMN is made up of 4 elements and 3 requirements as defined by specification published by the

To restate, a policy is:

A business rules is:

Examples of policies for a car rental company:

Example of business rules that may support these policies:

What is Enterprise Architecture, and why is it relevant to a Business

How would you build a Business Process Model?

What is a Fact Model?

What is PEST Analysis?

RML models fall into 4 categories:

 Objective Models including

 System Models including

 People Models including

 Data Models including

Is it really necessary to document the business vision at the start of a

What is Enterprise Architecture?

Explain Kurt Lewin’s Model of Organizational Change

 Determine what needs to change

 Involve people in the process and empower them

 Develop processes to anchor the changes into the culture

What is the 4 +1 View Model as it relates to system modeling?

The 4 primary views are:

Well-defined NFRs should meet the following criteria:

Once a system is developed is it reasonable to document changes

i. The size and demographic of the potential market

ii. The needs of the target demographic

Competitor Analysis: For the competitors identified during market analysis:

. Understand the features offered by the competitors product

ii. Speculate as to the strategic direction each competitor may be taking

v. Identify key weaknesses of competitors that may be able to be exploited, etc

Personas: Develop Personas to reflect users of your product by market segment.

Begin the first iteration of feature development

iv. Write Code: Code to the specs

v. Unit Testing: Perform unit testing

How do you avoid requirement conflicts while making changes to an

what and Why. These are your requirements.

What strategies can the BA and project team use to facilitate

 Foster collaborative ownership on multi-stakeholder projects. If a single document contains

What strategies can the BA and project team use to facilitate

 Foster collaborative ownership on multi-stakeholder projects. If a single document contains

What are the difference between a Business Requirement Document

As a BA (business analyst) approaching a new piece of work, who

How does the Business Analyst role change on an agile project

The core responsibilities of a BA on a software development project include requirements elicitation,

How are non-functional requirements defined and managed on agile

Well-defined NFRs should meet the following criteria:

1) Define a Terms Glossary

2) Write Test Cases Against Requirements.

3) Avoid Non-Testable Words

4) Create Visual Models

 Observation and Job Shadowing

What is the business case for using personas?

So what happens without the use of personas?

What are the essential components of a use case?

Actors can be:

How should the Business Analyst begin the requirements elicitation

What is the difference between a use case alternative flow and an

Why is requirements traceability important on a project?