Business Analysis Tutorial (DOC) by MouhanadTellawi

VIEWS: 567 PAGES: 70

More Info
									How do you define the term Requirement?

While this may seem like a very simple question, few Business Analysts ever take the time to ask or to
understand ―what is a requirement‖.

Per the BABOK v2.0

―A requirement is:

    1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
    2. A condition or capability that must be met or possessed by a solution or solution component to
         satisfy a contract, standard, specification, or other formally imposed documents.
    3.   A documented representation of a condition or capability as in (1) or (2).‖

Many business analysts may assume that requirements describe condition or capabilities of a system. Or
perhaps they avoid this trap and expand a requirement to encompass a condition or capability of a
business process. However, the BABOK definition has been carefully crafted to ensure that what is
stated does not arbitrarily constrain the true definition of a requirement based on poor assumptions about
the problem domain.

A requirement, may relate to any number of problem domains that vary both by type and by scope, such

        Organizational Structures
        Business Processes
        Business Policies
        Business Rules
        Roles/Stakeholders
        Systems
        Reports and Documents

The possibilities are nearly endless. Additionally, a requirement can be defined at whatever level of detail
or depth is necessary to accurately convey the condition or capability. It can be define at an enterprise
level, a divisional level, a process level, and activity level, a task level, etc.

In the real world requirements may be clearly understood or they may be implied or derived from other
requirements. But, ultimately, when eliciting requirements for a project, a requirement is not truly a
requirement until it is documented. A requirement may be documented as a requirement statement such
as ―The system shall…‖, ―The process shall…‖, ―The Financial Analyst shall…‖, or it can be documented
through any number of representative techniques including models and diagrams.

Requirements are typically classified into a number of categories for easier organization and
maintenance. The BABOK classifies requirements into the following categories.

    1. Business Requirements
    2. Stakeholder Requirements
    3. Solution Requirements
           a. Functional Requirements
           b. Non-Functional Requirements
         Transition Requirements

What are the characteristics of a good requirement?

While different organizations and authors may describe a slightly modified list, the following
characteristics are generally accepted as those defining a good requirement.

Cohesive: The requirement defines a single aspect of the desired business process or system.

Complete: The individual requirement is not missing necessary or relevant information. Additionally, the
entire set of requirements should cover all relevant requirements.

Consistent: The requirement does not contradict another requirement.

Modifiable: Like requirements should be grouped together to allow similar requirements to be modified
together in order to maintain consistency.

Correct: The requirement meets the actual business or system need. An incorrect requirement can still
be implemented resulting in a business process or system that does not meet the business needs.

Observable: The requirement defines an aspect of the system that can be noticed or observed by a
user. This is often referred to as ―Implementation Agnostic‖ as the requirement should not specify
aspects of system architecture, physical design or implementation decisions. These aspects of a system
should be defined separately as constraints.

Feasible: The requirement can be implemented within the constraints of the project including the agreed
upon system architecture or other physical design or implementation decisions.

Unambiguous: The requirement is written objectively such that there is only a single interpretation of the
meaning of the requirement.

Verifiable: It can be shown that the requirement has been met by the final solution via inspection,
demonstration, test, or analysis.

What are the four fundamental methods of requirement verification?

The four fundamental methods of verification are Inspection, Demonstration, Test, and Analysis. The four
methods are somewhat hierarchical in nature, as each verifies requirements of a product or system with
increasing rigor. I will provide a description of each with two brief examples of how each could be used to
verify the requirements for a car and a software application.

Inspection is the nondestructive examination of a product or system using one or more of the five senses
(visual, auditory, olfactory, tactile, taste). It may include simple physical manipulation and measurements.

       Car: visually examine the car to ensure that it has power windows, power adjustable seats, air
        conditioning, a navigation system, a tow package, etc.
       Software Application: visually examine the software for screens that were requested, check for
        the fields needed for data entry; verify that the necessary buttons exist for initiating required
        functionality, etc.

Demonstration is the manipulation of the product or system as it is intended to be used to verify that the
results are as planned or expected.

       Car: use the automatic switches to verify that the windows and seats work as intended, start the
        vehicle and ensure that the air conditioning produces cold air, take the car for a test drive to
        sense the acceleration and cornering as it was described based on the requirements.
       Software Application: enter all required fields on a screen and select the button to return a
        specific report. Ensure that the report is returned with the type of data needed.

Test is the verification of a product or system using a controlled and predefined series of inputs, data, or
stimuli to ensure that the product or system will produce a very specific and predefined output as
specified by the requirements.

       Car: accelerate the car from a complete stop to 60 mph, and verify that it can be done in 5.2
        seconds. Accelerate through a turn under controlled conditions, producing .8G of force, without
        the car loosing traction.
       Software Application: enter the type and model of car, automatic windows, power steering, and all
        other options as stated in the predefined test plan, select the price now button and receive back a
        price quote of precisely $43,690.

Analysis is the verification of a product or system using models, calculations and testing equipment.
Analysis allows someone to make predictive statements about the typical performance of a product or
system based on the confirmed test results of a sample set or by combining the outcome of individual
tests to conclude something new about the product or system. It is often used to predict the breaking
point or failure of a product or system by using nondestructive tests to extrapolate the failure point.

       Car: complete a series of tests which rev the engine at a specific rpm for a set length of time,
        while monitoring engine vibration and temperature, to verify that the expected results are
        achieve. Use this information to model the failure point of the engine, i.e. max rpm sustained
        over a specific period of time.
       Software Application: complete a series of tests in which a specified number of users input the
        characteristics of the car they are attempting to price and initiate the pricing functionality at the
        same time. Measure the response of the system to ensure that the pricing function returns its
        results within the time specified. Analyze the relationship between increasing number of system
        users and the time it takes for pricing to be returned. Record the results to capture system
        degradation. Use this information to predict at what point the system no longer meets the
        maximum allowable time to return pricing as defined by the requirements.

What are non-functional requirements?

Non-functional requirements are characteristics of a system or solution which describe non-
behavioral characteristics or qualities of a system.

Whereas functional requirements describe the behaviors or functions of a system, the non-functional
requirements generally describe those attributes which the system must have but which do not
represent something an actor can do with the system.

Non Functional Requirements have also been called the 'ilities' because they can be expressed like
this: usability, reliability, interoperability, scalability, extensibility, etc. Non-functional requirements
are also commonly referred to as quality of service (QoS) requirements or service-level

In many instances non-functional requirements describe (are attributes of) functional requirements.
For example: if a functional requirement of a system is "the system shall allow the customer to view
current month's statement" a non-functional requirement which describes this need might be "the

system shall generate the current month's statement in 30 milliseconds" or "the system shall store
monthly statements for up to 12 months".

In other instances, non-functional requirements describe constraints on a system such as legal and
regulatory constraints.

A simple test to determine if a requirement is functional or non-functional is to ask yourself if you
can describe the requirement using the action of an actor or user of a system (think use cases and
user stories). If the requirement can be easily described with a use case or user story then it is
probably a functional requirement, otherwise it is most likely a non-functional requirement.

What approach should a business analyst take when gathering requirements from high
level executives versus the end users?

For the most part, the methods and techniques for gathering requirements are the same regardless
of whom the stakeholders are: interviews, focus groups, questionnaires, requirements workshops.

However, there are definite things that the business analyst should consider when gathering
requirements from high-level executives vs. the end users. The business analyst should tailor his
approach and expectations based on the stakeholder type.

Here are some ideas, side by side:

                        High-Level Executives                            End Users
              Generally provide vision and high-level
                                                         Can provide detailed needs and
Requirement guidance on the direction of the project.
                                                         requirements as related to their specific
Types         They address key features and major
                                                         day-to-day jobs.
              problems to be addressed by the software.
                                                         Are more interested in the usability of the
              Are less focused on detailed usability     system as they are the power-users.
Usability     issues but may be interested in general UI They want the system to be easy to use
              and usability guidelines.                  and efficient (ex: minimize keystrokes
                                                         and clicks)
              Are very concerned with the cost and       Less concerned with cost, therefore
              budget of the system therefore will be     might provide all kinds of “nice to have”
              more likely to prioritize requirements and suggestions which may not solve real
              focus on the ones with higher ROI.         business problems.
              Effective method of gathering              Effective method of gathering
              requirements from this group.              requirements from this group.
              Not a good way to gather requirements      A valuable tool when certain statistics
              from executives. The execs may actually need to be collected from a very large
              be the ones approving the questionnaires number of potential end users and
              before sent to end users.                  stakeholders.
              Effective method of gathering              Effective method of gathering
              requirements from this group. It is        requirements from this group.
              desirable to have all the decision-making It is a good idea to have a number of
              stakeholders in the room when identifying workshops one for each user type (ex:
              the requirement rankings and when          advanced users vs. most users vs.

               making key design decisions.                 new/inexperienced user).
               High-level executives are very busy so the
               business analyst must be very well           With this stakeholder group, you might
               prepared before meeting with this group      have the luxury of time and ability to
               of stakeholders. Be prepared to focus on     cycle back later to clarify requirements.
               the most important problems, issues,         Having said that, these users tend to be
               questions, etc. The business analyst         less experienced so the business analyst
               should use this group to ensure that the     must be able to present the information
               direction and goal of the project is clear   in simpler and easier to understand ways.
               and well understood.

What is MoSCoW and how is it beneficial for prioritizing requirements?

MoSCoW is a method used to prioritize functional and non-functional software requirements.
Originally used as part of the Dynamic Systems Development Method, MoSCoW is an acronym which
stands for:

M – Must Have
S – Should Have
C – Could Have
W – Won’t Have but Would Like in the Future

While requirements are often categorized numerically on a 3, 4, or 5 point scale, the MoSCoW
method provides the added benefit of providing a pneumonic that qualitatively describes HOW
requirements should be classified into each level of priority.

Must Have describes requirements that have to be implemented to have a successful system.
There are no workarounds if the functionality is missing. So, if even a single “Must Have”
requirement is not implemented the system is a failure.

Should Have describes requirements that if missing would significantly affect the usability of the
system but for which a workaround exists. It’s not necessarily pretty or ideal but if you leave a
“Should Have” requirement out the user can still manage to use the system, even if their
productivity is reduced.

Could Have describes requirements that if missing do not have a dramatic impact on the usability
of the system. They are nice to haves. They are still desired because they result in moderate
improvement in usability and improve user satisfaction.

Won’t Have but Would Like in the Future describes requirements that are known to be outside
of the current scope of the project. These may be nice to have requirements but could also be very
significant requirements that merely cannot or will not be included in the current release. This
category is used as a parking lot to organize future requirements.

What is a S.M.A.R.T. goal statement or objective statement?

SMART goals or SMART objectives are often used when creating a project charter and defining the high-
level scope of a project. The acronym SMART can be used to validate that your goal statements are well-

formed statements that the entire team can execute. SMART stands for specific, measurable, attainable,
realistic, and time-bound.

S – Specific: Specific goals are needed in order to ensure that the goal is fully understood and fulfilled.
To ensure that your goals are specific, ask yourself if they answer the “W’s”.

       Who is involved
       What needs to be accomplished
       When will the goal be accomplished
       Where...identify a location
       Why does the goal need to happen...what is the need being met

M – Measurable: Document specific criteria that can be used to measure the completion of the goal.
Measurement of a goal results in an increase focus resulting in less wasted time, a greater chance of
success, and a higher likelihood of meeting your deadlines and staying on budget.

A – Attainable: Ensure that you have the tools, methods, and means available to you to attain the goal.
While writing the goal you may find that some of these items are not readily available to you. This is an
indicator that there may be some preparation that you will need to do ahead of time to make the goal

R – Realistic: The goal should not be so high that it cannot be achieved under any circumstances. Be
sure that your goals are realistic. Unrealistic goals result in discouraged teams and failed projects.

T – Time Bound: A goal should always be tied to a completion date. This ties back to the need to have a
measurable goal and to ensure that you are meeting the goal within the timeframe required. If there is
no timeframe, then there is no sense of urgency to accomplish the goal.

How would you control the scope of a project?

Every requirement (be it at high, medium or low level, every process step and control flow, every
entity, attribute and relationship) must be contributing to one or more SMART objectives for a
project. If a new requirement at any level is proposed it must be mapped to the objective(s) it
contributes to. If it does not map it means either an objective is missing (and therefore a significant
amount of analysis is also missing) or the requirement MUST be out of scope as it does not
contribute to project success.

SMART stands for:
Traceable and Time-Bound

What is Joint Application Development (JAD)?

JAD stands for Joint Application Development. JAD is a requirements-definition and software system
design methodology in which stakeholders, subject matter experts (SME), end-users, business analysts,
software architects and developers attend collaborative workshops (called JAD sessions) to work out a
system's details.

The JAD approach, in comparison with more traditional practices, is thought to lead to faster
development times and greater client satisfaction, because the client is involved throughout the
development process

The focal point of the JAD process is the series of JAD sessions that are attended by stakeholders,
executives, SME’s, end-users, business analysts, software architects and developers. It is essential that
the roles, responsibilities, and rules for the JAD sessions are well defined and communicated in advance
to all participants.

Some typical roles found in a JAD session include:

        Facilitator – 1 (only one) - usually a Senior Business Analyst - facilitates discussions,
         enforces rules,
        Scribe – 1 or 2 – sometimes more junior BAs – take meeting notes and clearly
         document all decisions,
        End users – 3 to 5, attend all sessions,
        Technical Experts – 1 or 2, question for clarity and give feedback on technical
        Tie Breaker – Senior manager (executive) - breaks end user ties, usually doesn’t
        Subject Matter Experts,
        Observers – 2 or 3 - junior BAs, testers, etc. - do not speak.

What is Structured English (aka pseudocode)? Please provide an example.

Structured English or pseudocode is a technique used by systems analysts (and sometimes by IT
business analysts) to model and document logic of information processes.

It is a form of English often used in functional or system specifications and it looks a bit like
programming statements but does not have a compiler readable syntax.

Structured English uses a subset of English as follows:

        Action verbs (ex: display, save, delete, etc.)
        Noun phrases (ex: bank account, customer, etc.)
        Set of well defined keywords (IF, FOR EACH, WHILE)
        NO adjectives or adverbs


FOR-EACH Account belonging to the Customer

IF Account is NOT closed THEN

Display account on the screen



What is CRUD?

CRUD stands for:

        Create,
        Read,
        Update,
        Delete.

These are the four basic functions that can be performed when working with data in a persistent

It also refers to operations that a user can perform using a given feature. With the exception of
workflow, most business applications deal exclusively with user interfaces which allow the user to
either create (enter), read (view), update (edit), or delete data.

What is your greatest strength?

This is one of those questions which most interviewers ask. So it is important that you are prepared
to answer this question well.

You might think "What's the big deal? This is a simple question which anybody can answer." Well -
maybe but there are a few things to keep in mind when answering this question. Read on...

The interviewer is trying to discover both actual strength (those that you actually have) and those
that you believe you have but you may not. So be careful how you answer this question.

One way you can answer this question is something like this: "Here are some areas in which I
excel ________, _________, and _______."

Here are some more tips to consider when answering this question:


        tell the truth,
        focus on strengths which address qualifications required for the
         position you are interviewing for,
        provide examples of situations which demonstrate your strength(s),
        consider knowledge-based skills, transferable skills, or personal traits.


        sound boastful (don't over brag),
        use cliché answers such as "I'm a hard worker" - these are too
        be shy!

What is your biggest weakness?

This is one of those questions to which only YOU have the answer.

First of all, don't be afraid of this question. Most employers ask this question to find out your self-
assessment skills and your ability to understand reality.

The way you should answer this question is something like this: "I'm not sure exactly what my
biggest weakness is but one area in which I know I need to continue to improve is ________."

Don't stop there. Most employers also want to make sure that once you know you have a weakness
you are actually doing something about it. So add something like: "I have already been taking
proactive steps to improve in this area including ______, ______, and _____."

As a business analyst, you do not know everything. Trust me. So find an area in which you need to
improve and start working on it.

Here are some more tips to consider when answering this question:


        tell the truth
        admit a weakness that can be fixed
        ask the interviewer to clarify the question


        tell them you have no weaknesses
        confess something big
        just say "I work too hard"

Name a few of the industry standards, methodologies, or best practices used by
business analysts and systems analysts?




Change Management Process


As a BA (business analyst) approaching a new piece of work, who would you interview
and what questions would you ask?

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 stakeholders 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)

What is SWOT Analysis?

SWOT Analysis is a strategic planning technique used to assess the internal and external environment in
which a company operates and competes. Internal environmental factors are classified into strengths
and weaknesses, while external environmental factors are classified into opportunities and threats.

Each is identified as follows:

        Strengths (internal factor): The company‘s resources or capabilities that give it a competitive
         advantage within its market or industry.
        Weaknesses (internal factor): Areas where the company lacks certain resources or capabilities
         that prevent it from taking advantage of available opportunities or make it vulnerable to other
         environmental factors.
        Opportunities (external factor): Industry or market factors that may result in company profit and
        Threats (external factor): Factors that may have a negative impact on the company‘s profit,
         growth, or position within its industry or market.

                    Strengths (Internal)         Weaknesses (Internal)
                                           (Quadrant 2) If particularly
              (Quadrant 1) Focus on
                                           profitable market opportunities
              areas where a company‘s
Opportunities                              exist then the company may
              strengths align with market
(External)                                 want to eliminate weaknesses
              opportunities for rapid
                                           in this area to take advantage
              growth and profitability.
                                           of these opportunities.
Threats          (Quadrant 3) When a       (Quadrant 4) When a
(External)       company‘s strengths align company‘s weaknesses are in

                 with market threats, these    the same area as market
                 strengths can be use to       threats, steps should be taken
                 avoid or mitigate these       to eliminate these
                 market threats.               vulnerabilities immediately.

A company should usually focus their effort on quadrants 1 and 4 first. Quadrant 1 delivers the most
amount of gain for the least amount of effort since it takes advantage of existing strengths of the
company. Quadrant 4 will likely require a lot of effort, but if left unattended, could result in detrimental
outcomes for the company.

What is the difference between a Business Requirement Document (BRD) and a
Functional Specification Document (FSD)?

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.

What is the difference between a Primary and Secondary Actor in Use Case Modeling?

Use Case modeling is used to diagrammatically depict a system and those people or processes that
interact with it. This system can be a business system (a process) or an application system (computer or
web based). To understand the scope of the system under consideration a system boundary is used.
Anything depicted within the system boundary is part of the system under consideration, while anything
outside of it is not. Use cases are then used to define a group of user-system interactions that together
deliver value to the user of the system. These users are called actors.

Primary actors are people, or at times even other systems, that require the assistance of the system
under consideration to achieve their goal. They initiate the use cases of the system (business processes
or application functionality). A use case within the system may have more than one primary actor, since
more than one type of role may initiate the processes or functionality of the system.

The system, and its use cases, often relies on other people, business processes, or applications in order
to obtain a result or specific information required to achieve its goal. These are called Secondary Actors.
A secondary actor is one from which the system requires assistance to complete the use case. A
secondary actor never initiates the use case. It is invoked by the system‘s use cases in order to obtain
information or a result. There may also be many secondary actors of a system.

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

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 popular 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?

First, it’s worth saying that there are a number of 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 flows and error flows. However, of those authors that do differentiate
between alternative flows and exception flows some agreement in definition 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 and 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 problems. Exception flows represent an
undesirable path to the user. However, even though the exception flow has occurred the system will
ideally react in a way that recovers the flow and provide 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 which mitigates the impact of the error.

What are some of the limitations of use cases and use case specifications?

Use cases are a valuable tool available to the business analyst for documenting functional requirements
of a system or business, however they do have limitations.

        Use cases were not created to capture non-functional requirements (e.g performance, platform,
         scalability, reliability of a system). While use case specification templates have been extended by
         some in an ad-hoc fashion to list non-functional requirements, this strays from the intended
         purpose of a use case. Use cases are functional in nature. It is this very organization by function
         that give use cases their many benefits. Arbitrarily listing non-functional requirements in one use
         case specification or another can obfuscate the cohesiveness and benefits of the use case
        The non-sequential nature of a use case diagram is often difficult for some audiences to
         understand. When one use case includes or extends another, the reader of the diagram often
         arrives at the incorrect conclusion that the use case diagram is showing a sequence where the
         first use case is completed before the other begins. Those who are familiar with use case
         diagrams know that an included or extended use case can occur or be initiated at any point within
         the including or extending use case.
        Learning how to write use cases takes time. Many consider it to be more of an art than a
         science. This is because there is no fully defined set of standards for how to write use cases, or
         what should be included within a use cases specification. And while there have been many
         different views espoused by authors, still a great deal of commonality has emerged among them.
         Where this commonality exists there is little disagreement among use case writers and those who

        consume or read use cases. However, in some areas there are still a number of differing
        opinions creating confusion for new use case authors. Because of this, the learning curve for use
        cases and use cases specifications is elongated. Still, over time, use case authors and readers
        develop a more sophisticated understanding of those areas that are more ambiguous and open
        for interpretation, such as the ―extends‖ relationship.
       Use case specifications are not an appropriate tool for describing the user interface of the
        application. Use cases should be left as UI independent as possible. Remember that a use case
        specification it intended to capture the functional requirements of the system, or in other words,
        WHAT the system should do in response to a user action. This is very different than HOW the
        system should do something. Any time an analyst captures requirements, the focus should be on
        the WHAT not the HOW. This gives the system and UI designer the freedom to develop the best
        solution possible. It also makes our use case specifications much more maintainable since a
        change in screen design doesn‘t impact the user-system interaction previously defined.

   What is use case generalization?

In the context of use case modeling the use case generalization refers to the relationship which
can exist between two use cases and which shows that one use case (child) inherits the structure,
behavior, and relationships of another actor (parent). The child use case is also referred to the
more specialized use case while the parent is also referred to as the more abstract use case of the

For those of you familiar with object oriented concepts: use cases in UML are classes and the
generalization is simply the inheritance relationship between two use cases by which one use
case inherits all the properties and relationships of another use case.

You can use the generalization relationship when you find two or more use cases which have
common behavior/logic. In this instance, you can describe the common parts in a separate use case
(the parent) which then is specialized into two or more specialized child use cases.


If you are creating a payment system which allows students of a training provider to pay for courses
both on-line and by phone, there will many things in common between the two scenarios: specifying
personal info, specifying payment info, etc. However, there would also be differences between the
two. So, the best way to accomplish this is to create one use case (the parent) which contains the
common behavior and then create two specialized child use cases which inherit from the parent and
which contain the differences specific to registering on-line vs. by phone.

What type of information should be documented in a use case specification?

While use cases are included in the Object Management Group’s UML® Specification, the
UML specification does not define the form or content that should be included in a use case
specification. For this reason, there is no single standard. Precisely what information
should be included varies based the source you reference. Nevertheless, most
methodologies and authors show a significant degree of agreement regarding the
information that should be included in a use case specification.

The most popular use case specification template is probably the Rational Unified Process
Template. It includes the following information.

       Use Case Name
       Brief Description
       Actors
       Triggers
       Flow of Events
            Basic Flow
            Alternative Flows
       Special Requirements
       Pre-Conditions
       Post-Conditions
       Extension Points

In his book, Writing Effective Use Cases, Alistair Cockburn (2001) shows several
examples of use case specifications, most of which include the following information:

       Context of Use
       Scope
       Level
       Primary Actor
       Stakerholders and Interests

       Preconditions
       Minimal Guarantees
       Success Guarantees
       Trigger
       Main Success Scenario
       Extensions
       Technology and Data Variations list
       Special Requirements

Additionally, Scott Ambler (2004) offers a simplified template in The Object Primer that
includes the following information:

       Name
       Identifier
       Description
       Goal
       Pre-conditions
       Post-conditions
       Basic course of action
       Alternative course of action


Cockburn, Alistair. 2001. Writing Effective Use Cases. Addison-Wesley Professional.

Ambler, Scott W. 2004 The Object Primer: Agile Model-Driven Development with UML
2.0 (Third Edition). Cambridge University Press.

What is difference between an Essential Use Case and a System Use case?

 ―An essential use case is a structured narrative, expressed in
the language of the application domain and of users,
comprising a simplified, generalized, abstract, technology-free
and implementation independent description of one
task or interaction that is complete, meaningful, and well-defined
from the point of view of users in some role or roles
in relation to a system and that embodies the purpose or
intentions underlying the interaction‖ (Constantine and Lockwood (1999).

Said another way, an essential use case describes the interaction between the user and the
system at a high level of abstraction. The goal of an essential use case is to convey the
most important aspects of the user-system interaction by focusing on the user’s intent
(avoiding any reference to an assumed UI design or technological implementation) and on
the observable result of the system (without specifying the internal steps the system takes
to achieve the result). Since an essential use case describes only the most important
information it represents a single success scenario.

In contrast, a system use case describes the interaction between the user and system in a
more detailed way than and essential use case. While still trying to avoid referencing any UI
specific features when possible, usually certain aspects of the technology to be used can be
assumed. For instance, when writing a system use case, it is usually known whether the
user will interact with a telephonic system, an internet application, or a piece of

manufacturing equipment. Similarly, system use cases provide more detailed description of
the steps that the system will perform to fulfill the need of the user. In order to avoid
committing to a specific UI design, this detail should still be expressed in logical
terms. However, it paints a clearer picture of the requirements that the GUI must satisfy.

Portfolios, Programs, and Projects—what’s the difference?

The term portfolio is use to refer to a collection of programs and projects. These programs and projects
are initiated, prioritized, and managed by a company to meet the goals of the business. The term
program is use to refer to a single strategic business initiative and groups one or more related projects
that support the business initiative. So one or many related projects can make up a program and one or
many programs can comprise a portfolio.

As a business analyst, understanding each of these three concepts (portfolio, program, and project) and
how your project fits into the greater program and ultimately portfolio of projects can help you understand
many of the decision made by executives. If you know that your project has a high priority within the
portfolio, your requests for additional resources have a much higher likelihood of being approved
compared to a request from a low priority project. Similarly, if your project has a low priority, resources
could be pulled to support higher priority projects or your project may be cancelled altogether, even if it
was on track and on budget.

Understanding other projects in the portfolio and their relation to your own can also help the business
analyst make better decisions. Instead of making decisions based strictly on a myopic view of your own
project, a good business analyst will consider the pros and cons that each decision may have on other
projects belonging to the same program. In this way, the business analyst is ensuring that they are
delivering the optimum solution for the project and the company as a whole.

Why is requirements traceability important?

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

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 is Cost Benefit Analysis (CBA)?

Cost Benefit Analysis is a technique used to determine if the financial benefit s of a project outweigh the
associated cost of undertaking the project in the first place. For a short term project where the benefit
may be an immediate one-time cash windfall this may be as simple as subtracting the total of all the
project cost from the total of all of the project benefits. If the total is positive, then the project may be
worth completing.

         Project Duration = 2 months
         Project Costs = $50,000
         Immediate Project Benefits = $75,000
         $75,000 - $50,000 = $25,000

However, project costs and benefits rarely result in such a simple example. Project costs and benefits
often occur over time. For this reason, Cost Benefit Analysis should consider all project cost and
benefits in terms of the present value (PV) of money.

To determine the present value of a future cost or benefit we discount the value of the dollars to account
for time. To calculate the Present Value we use the formula PV = FV /[(1 + i)^t].

         PV = Present Value
         FV = Future Value
         i = Discount Rate
         t = time

In our example, if the $50,000 cost was incurred immediately and the $75,000 benefit was realized 3
years in the future, using a 5% discount rate would result in the following:

         PV = $75,000 / [(1 + .05)^3] = $64,787.82
         $64,787.82 - $50,000 = $14,787.82

The net benefit of this project is now clearly less than originally thought.

Taking this a step further, consider the example where we have multiple cashflows (costs and benefits)
over time.

         @ T0, Cost = -$25,000
         @ T1, Cost = -$25,000, Benefit = $15,000
         @T2, Benefit = $30,000
         @T3, Benefit = $30,000

By subtracting the present value of future costs from the present value of future benefits, we can arrive at
the Net Present Value (NPV) of the costs and benefits for each year of the project. The sum of all NPV
calculations will give us the NPV of the entire project.

         NPV = FVben – FVcost / [(1 + i)^t]
         NPV0 = $0 - $25,000 / [(1 + .05)^0] = -$25,000
         NPV1 = $15,000 - $25,000 / [(1 + .05)^1] = -$9,523.81
         NPV2 = $30,000 - $0 / [(1 + .05)^2] = $27,210.88
         NPV3 = $30,000 - $0 / [(1 + .05)^3] = $25,915.13

For a total of $18,602.20 in benefit.

What sort of existing documents should Business Analysts refer to when starting on a
new project?

Few analysts are brought on to a project at the very beginning. For those that are, they will often have a
hand in creating some of the important documents that other analysts should reference when they first

First, get your hands on the project charter. The project charter, while high level, will provide critical
information on the project such as:

        the reasons for undertaking the project, including the high level business goal or
         goals that are to be satisfied by the project and a calculation of Return on
         Investment (ROI),
        objectives and sub-goals of the project as well as major constraints due to current
         business processes or existing technology infrastructure,
        the high level vision and scope of the project outlining the initial direction for the
         solution being developed,
        major risks which need to be avoided while developing the solution,
        the important stakeholders involved which should include not only a project sponsor
         and steering committee members but also the business representatives that will
         have final sign-off on requirements.

Find out as much as you can about the project management processes that are being used to manage
timelines, risks, communications, costs, etc. Ideally, these processes are outlined in a formal document.
If not, be sure to talk to the project manager(s) on your project to fully understand the processes that
should be followed.

The same goes for the analysis process and artifacts being used. Understand the methods that will be
used for eliciting and documenting requirements. How will these requirements be communicated? How
will they be captured and translated into functional specifications? Being an analyst, this is something
that you will be taught at some point on the project, but the sooner you learn the details of the analysis
process and artifacts being used the better off you will be.

If requirements elicitation has already begun, review the existing requirements documentation.
Reviewing requirements will bring you up to speed rapidly. Record any questions you have regarding the
system requirements and get answers to them. If a prototype has been created as a method for
identifying and clarifying requirements, understand the prototype inside and out. Take the time to
understand why each screen was designed a particular way. Was it to support a business requirement,
or was it merely a design decision that could have been handled in a different way.

What strategies might a business analyst consider when planning for a company's

If a company is to ensure its growth, it needs to plan for it. There are a number of growth strategies that
can be used. Deciding which is the right growth strategy for a company depends on it current success
and position within the marketplace in which it operates. Four of these growth strategies are:

        Market Penetration (Existing Products/Existing Markets)
        Market Development (Existing Products/New Market)
        Product Development (New Products/Existing Market)
        Diversification (New Products/New Market)

Market Penetration focuses on getting more out of the current markets serviced by an organization while
offering the same products. New products and new markets can mean additional unknowns which, in

turn, increase risk and chances of failure. For this reason, a company may choose to select a growth
strategy of market penetration. The goal of market penetration is to increase the percentage of market
share that the organization possesses through pricing, marketing, loyalty programs, incentives,
advertising, etc.

Market Development is used to describe the growth strategy of an organization which chooses to
venture into new markets or new customer segments with their existing products. Their existing products
are likely proven which provides a degree of stability, but moving into new markets increases risk. This
may still be viewed by some organizations as a fairly conservative strategy and is often adopted by
companies as they feel their current markets getting squeezed tighter and tighter by competition.
Entrance into new markets often requires skilled marketing professionals to ensure a company receives
the attention it is looking for.

Product Development describes the growth strategy of creating new products for existing markets. An
organization may have the benefit of understanding the intricacies of their market but this can create a
false sense of security. Not all new products carry the same risk. However, for certain types of product,
especially those in fast moving technology markets, projecting the outcome of a new product launch can
be very difficult. To overcome some of this risk organizations should be prepared to continuously adapt
their products after launch to ensure marketplace success.

Diversification is the term given to the strategy of delivering new products to entirely new markets. The
growth strategy accepts the risks of two unknowns; the product and the market. Diversification is high-
risk but, as with many things, high risk often can mean high reward. Organizations with a track record of
innovation will have the greatest success with this strategy. With diversification as a growth strategy,
everything will be new and the company will need to be prepared to quickly eliminate any risks that
manifest themselves.

The four growth strategies described here are based on a simple 2 x 2 matrix called Ansoff‘s Matrix which
considers markets and products along its two axis.

Ansoff’s Matrix

                              Existing Products               New Products
Existing Markets              Market Penetration           Product Development
New Markets                  Market Development                Diversification

What is Benchmarking?

When companies want to improve, they first need to have an accurate means of measuring performance.
Without accurate measurement, determining process improvement is not feasible. Measurement
establishes a baseline against which the organization can determine the degree of improvement that has
been made.

However, improvement alone may not be enough. If an organization doesn‘t know what the standard is it
cannot compare itself against it. For example, if an organization obtains a customer satisfaction rating of
80%, but its competitor receives 90%, they will lose ground in the long run. Benchmarking is the key to
understanding how an organization measures up against others.

Benchmarking is the process of determining how an organization stacks up against industry leaders by
measuring its performance across a series of standard metrics and then comparing the performance
against other best-of-breed organizations within the same industry or service line. Companies may
measure and compare policies, practices, philosophies, and other performance measures.

Benchmarking is usually part of a larger process re-engineering or quality improvement initiative such as
Six Sigma or Total Quality Management.

What is Document Analysis?

Document Analysis is a technique used to gather requirements during the requirements elicitation phase
of a project. It describes the act of reviewing the existing documentation of comparable business
processes or systems in order to extract pieces of information that are relevant to the current project, and
therefore should be consider projects requirements.

Business analysts can elicit requirements in many ways, and eliciting them from stakeholders using
questionnaires, interviews, or facilitating sessions are most common. However document analysis is
particularly valuable when replacing one or more existing systems with a new system that will offer
increased functionality or a better overall user experience. Existing documentation can be scoured for an
understanding of key functions, business rules, business entities, and business entity attributes.
Document analysis may also be necessary when stakeholders are not available to offer insight into
existing business processes or systems.

Some forms of documents that are useful in document analysis may be obvious, while others less so.
Here is a list of potential documents that an analyst should consider reviewing based on their particular
project type.

        Benchmarking studies
        Business plans
        Business process and procedure documentation
        Company memos
        Competing product literature and reviews
        Customer contracts
        Customer suggestions
        Requests for proposals
        System defect reports
        System specifications (of existing systems)
        Training guides
        Vision documents for related projects

What is Gap Analysis?

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

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

        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 a Communication Diagram?

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.

What is a database view and why should the business analyst understand it?

While the business analyst usual works in the logical domain, understanding what a database view is and
the advantages of using them can be helpful when the analyst is tasked with documenting requirements
and creating specifications for reports and user interfaces that present data from database queries.

A database view is a stored query that returns data from one or more database tables. The stored
query, or view, is a virtual table. Once you have defined a view, you can reference it just as you would
any other table in a database. Since the view is the result of a stored query, it does not contain a copy
of the data itself. Instead, it references the data in the underlying base tables.

Views provide a number of advantages:

        A view can provide additional security. By creating a view and creating the
         necessarily privileges, you can ensure that the users are only able to retrieve and
         modify data that is exposed by that view. Users will not be able to see or access
         data in the underlying tables that is not exposed by the view.

        Views can reduce query complexities. By creating and storing complex queries and
         exposing them in the form of a view, the data from the view can be extracted using
         much simpler queries.
        Since a database view is a stored query, not a copy of the actual data, views
         consume very little space.

Some examples of the ways views are used are:

        To combine data from multiple tables into a single virtual table that can be queried
         using basic statements.
        To partition a complex table into multiple virtual tables that are simpler to query. For
         example, if a database table contains sales data from the past 10 years, views can
         be created and represented using tables names such as SalesData2000 or
        To aggregate data and perform calculations. The view (stored query) can request
         the database engine to sum or average data in underlying tables. These sums or
         averages can then be queried more easily.

Describe the basic classification of requirements as defined by the BABOK (v2.0).

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

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-

        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 a Fact Model?

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 are the advantages and disadvantages of using screen mockups in the
requirements gathering process of a system solution?

Screen mockups can support the requirements gathering process when introduced at the right time, but if
introduced too early they can become problematic. Here are a few key points that an analyst should

1) Mockups are nice because they help the business representatives or clients visualize the functionality
of the system. This can be a big advantage to help analysts and stakeholders identify problems early on.
However, if introduced too soon in the process the natural tendency is for the business reps/clients to try
and be screen designers. Instead of stating that the system shall support "x", they beginning saying that
they need a dropdown to capture "y" and a button to do "z". The client is not a UI designer, in fact few
business analysts truly are, so this can lead to a screen design which does not have an appropriate
emphasis on usability. Similarly, specifying the controls needed on a screen detracts from the true
requirements of the system and often results in an inadequate level of discussion around why a system
must support certain functionality.

2) When requirements are captured in screen mockups with no supporting requirements list, it becomes
impossible to know whether an early screen design decision was made because it supports a necessary
requirement or if it was made for some other reason. How can the analyst and developers know whether
they can eliminate or alter the screen feature without losing an important requirement. Questions like, "Do
we really need to have the control on this screen, or can we capture the data at a later point in the
process?" becomes unanswerable without going back to the original stakeholders. And, on complex
projects no one stakeholder may be able to answer the question.

3) Screen mockups alone cannot capture the flow through the system. Often analysts will accompany
screen mockups with a written description of what happens when certain buttons are clicked or when
certain values are entered within a field or dropdown. These descriptions are helpful, but they fall short
of describing the end to end processes that the system must support. Further document such as process
flows or use cases are required, but often overlooked when too much emphasis is place on screen
mockups during the requirements gathering process. While analysts and stakeholders who are involved
in the screen mockup process may have a basic understanding of the processes supported, developers
and testers will not.

Ultimately, the introduction of UI mockups can be very helpful, but this should only occur after an
exhaustive list of features and usage scenarios (what business process flows need to be supported by
the system) have been documented. Only then can the UI mockups be generated without introducing
major pitfalls.

How do you influence people when you don’t have decision making authority?

Few business analysts have the final authority to make critical decisions on projects. That‘s why it‘s so
important for business analysts to polish their influencing skills.

The process used to influence people can be a formal, well thought out presentation, or it can be an
informal conversation. Either way, it never hurts to think through a standard framework by which to
structure your thoughts before attempting to influence someone. The following is a concise 5-step
framework that can be used for both formal and informal communications that involve influencing another
person or audience.

        Define the What, Why, and Who
        Prepare your case
        Deliver your message
        Obtain a commitment
        Agree to a specific action plan

These 5 steps provide a framework to structure and plan your communication to maximize your influence
over a person or audience, but it‘s the details of each step that will determine how influential you will be.

1. Define the What, Why, and Who.

It‘s important for you to have a well define and thoroughly understood objective. What is your goal or
objective? Why are you championing your particular position? Who do you need to influence?
Answering these questions will focus your case.

2. Prepare your case.

Notice that I didn‘t say ―prepare your argument‖. Influencing is very different from coercion or even
selling. While there may be some selling involved, it should be a soft sell of the benefits that you are

Consider how you can customize your case for the person or audience. What does the person or
audience value? What do you have to offer the person or audience? Do you have specific technical
knowledge? Do you have a strong network which could benefit the person or audience?

For more formal communications, while you are preparing your case you should outline a number of
potential options for the action plan that might be used if you get the person or audience to commit.

3. Deliver your message.

When delivering your message be direct in your thoughts and language. You want to come across as
respectful and open to the feedback of the audience, but do so without obscuring the point of your
message. Don‘t hint at what you want, but also don‘t demand.

Use powerful questions to engage your audience. Open-ended questions that lead the audience to
realize the advantages of your case work best.

4. Obtain a commitment.

Whenever possible, it is best to obtain a commitment immediately following the delivery of the message
while the benefits of your case are still fresh in the audience‘s mind. Steer the conversation to help your
audience arrive at the stage where they are comfortable committing.

5. Agree to a specific action plan.

Even with a commitment, you are only truly successful once you‘ve realized your objective. That‘s why
agreeing to an action plan is so important.

        Develop milestones for reaching the final objective
        Identify resources and assign roles and responsibilities
        Develop a method for tracking progress

To re-iterate, if you are planning a formal communication or presentation you will have a lot more time to
spend thinking through the details of this 5-step process. However, even for brief communications within
a short conference call, mentally thinking through these steps for just a few second can help guide your
conversation and increase your degree of influence with your audience.

How would you assess your value as a business analyst?

This question is not intended to determine how much you are looking to make. If an interviewer asks you
a question like this, they are likely looking for answers to a number of other unspoken questions such as:

Do you understand the real value a business analyst brings to an organization?

Do you ever think about the cost associated with employing you as a business analyst?

Do you have the skillset required to be a marketable business analyst?

Are your expectations of the value of a business analyst realistic?

Companies don‘t hire business analysts for fun; they hire them to save money. It‘s that simple. So how
does a business analyst save an organization money? You might mention a few examples such as:

        Make a process more efficient saving the company time and resources (which translates as
        Drive out the real requirements of a system, instead of a half-baked solution, ultimately reducing
         the amount of rework and re-development required to develop a system that delivers the intended
         value (rework means lost money)
        Identify opportunities for increased customer satisfaction leading to greater customer retention
         and greater new customer conversions (more money)

If you have quantifiable examples of work that you have produced in the past and know precisely how
much your work saved a company (not the work of the entire team, but YOUR actual contributions) this
information can be very powerful. This is your true value as an analyst within a similar organization and
role. But few people have the information required to make this kind of assessment. In addition, the
value you bring to an organization is very different from your ―potential value‖. If an organization has you
writing specs for a system, your opportunity to bring value may be much lower than if you are re-
engineering a multi-million dollar business process to eliminate hundreds of thousands or even millions of
dollars of waste.

This line of reasoning leads us to the question ―Do you have the skillset required to be a marketable
business analyst‖? You may have expert knowledge of traditional SDLCs and be able to create complex
analysis diagrams, but if the organizations that are hiring all require you to work in an Agile environment
then what value can you bring them? Even though your potential value for some organizations may be
quite high, your value to others that use a different range of skills may be quite low. This example shows
how your value is dependent upon the industry environment and the tools, competencies, and
methodologies that are popular at that time. It also shows the need to keep your skillset current and then
stress those skills that are most relevant to the interviewing organization.

If you can talk through these concepts with an interviewer, then you will have demonstrated that you don‘t
take you value as a business analyst for granted and that you are the type of person that will maximize
your value within the organization that hires you.

How do you handle stress and pressure?

A nice, brief response to this question may sound like this: I handle stress well. I‘m the type of person
that mitigates stress rather than folding under it. I thrive on challenge and I‘m used to working in a goal
oriented environment with demanding deadlines.

But if you just leave it at that, your answer will sound canned and won‘t be very believable. Expand on
how you feel about stress and specific action you take to deal with it.

Stress and pressure in small quantities can be a motivator and allow us to operate at peak performance.
However, in too large of quantities it causes anxiety, frustration, fatigue, and a host of other bad things
that ultimately are counterproductive to achieving our goals and objectives. So it‘s important to manage
stress and to find the right balance that works for you.

When you do feel stress coming on and rising to levels which are counterproductive, you must first
identify that the stress is there. This can be harder to do than it sounds, since when we are in a stressed
state are brains aren‘t usually in control of the situation. So how can you train yourself to do this?

Stress and pressure typically arise from a number of common root causes. Understanding these causes
ahead of time can help us be able to quickly identify the stress and take appropriate action to manage the
stress and bring it back down to reasonable levels. Here are some of the more common causes of stress
and how you might deal with them.

        1. Too much work/overburdened.

        Feeling overburdened creates stress, but for most people this can be overcome by doing two
        specific things.

        First, create a prioritized to-do list where you track every task along with progress notes detailing
        what has been completed for each task and what remains. The key is to track the information so
        that you don‘t have to remember and so that you don‘t worry over forgetting something
        important. If the list is too long, don‘t stress, that‘s what the second step is for.

        Second, if time required to complete the tasks is too great, talk to your manager immediately.
        Review the tasks with him or her and talk about realistic expectations.

        2. Lacking direction.

        If you feel as if you don‘t understand the direction you need to take on a task, raise it to your
        manager. Ask him or her to explain their vision for the outcome of the task. It could be that your
        manager doesn‘t have a clear vision of what the results should look like, but they probably know
        what requirements or problem the outcome should solve. Explain to your manager that you
        would like to make an attempt at a solid start and then schedule periodic reviews together to
        review the progress that you‘ve made. This gives them the opportunity to provide guidance and
        redirect your efforts if they feel you are going in the wrong direction. Remember that your
        manager probably wouldn‘t have given you a task with such an undefined vision if he or she
        didn‘t have a great deal of confidence in your abilities.

        3. Lacking knowledge or experience.

        Lacking the experience needed to perform a task certainly isn‘t a confidence builder, but it‘s
        important to remember that lack of knowledge or experience isn‘t a weakness. Everybody is
        always learning, and no one person has all of the answers. If it‘s information you lack, the key to
        reducing stress in this situation is taking a structured and well thought out approach to acquiring
        the information you need. If it‘s experience with a specific skill set then it‘s not out of line to
        discuss training options with your manager.

        Ultimately, remembering that nobody is expected to know or have experience with everything is
        key to keeping stress levels in line.

You can‘t completely avoid stressful situations, but one overarching approach that has always worked for
me is approaching every challenging situation more like a strategic, thoughtful game of chess. Identify

the challenges in front of you, evaluate multiple options for proceeding in the most efficient manner
possible, and then act.

What is the Scrum method?

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 30-days (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 huddled 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 30-day 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 30-day
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 30-day 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 30-day 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 30-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 30-day 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.

What is a Context Diagram and what are the benefits of creating one?

The Context Diagram shows the system under consideration as a single high-level process and then
shows the relationship that the system has with other external entities (systems, organizational groups,
external data stores, etc.).

Another name for a Context Diagram is a Context-Level Data-Flow Diagram or a Level-0 Data Flow
Diagram. Since a Context Diagram is a specialized version of Data-Flow Diagram, understanding a bit
about Data-Flow Diagrams can be helpful.

A Data-Flow Diagram (DFD) is a graphical visualization of the movement of data through an information
system. DFDs are one of the three essential components of the structured-systems analysis and design
method (SSADM). A DFD is process centric and depicts 4 main components.

        Processes (circle)
        External Entities (rectangle)
        Data Stores (two horizontal, parallel lines or sometimes and ellipse)
        Data Flows (curved or straight line with arrowhead indicating flow direction)

Each DFD may show a number of processes with data flowing into and out of each process. If there is a
need to show more detail within a particular process, the process is decomposed into a number of smaller
processes in a lower level DFD. In this way, the Content Diagram or Context-Level DFD is labeled a
―Level-0 DFD‖ while the next level of decomposition is labeled a ―Level-1 DFD‖, the next is labeled a
―Level-2 DFD‖, and so on.

Context Diagrams and Data-Flow Diagrams were created for systems analysis and design. But like many
analysis tools they have been leveraged for other purposes. For example, they can also be leveraged to
capture and communicate the interactions and flow of data between business processes. So, they don‘t
have to be restricted to systems analysis.

A sample Context Diagram is shown here.

A Context Diagram (and a DFD for that matter) provides no information about the timing, sequencing, or
synchronization of processes such as which processes occur in sequence or in parallel. Therefore it
should not be confused with a flowchart or process flow which can show these things.

Some of the benefits of a Context Diagram are:

        Shows the scope and boundaries of a system at a glance including the other systems that
         interface with it
        No technical knowledge is assumed or required to understand the diagram
        Easy to draw and amend due to its limited notation
        Easy to expand by adding different levels of DFDs
        Can benefit a wide audience including stakeholders, business analyst, data analysts, developers

What approach should be taken when creating a Context Diagram? Top down? Bottom

A number of factors should be considered when deciding what approach to use (top down or bottom up)
to create a Context Diagram. First let‘s be clear about what each approach means.

The top-down approach: this approach refers to starting directly with the Context Diagram and creating it
from scratch. This is done by placing the system under consideration in the center and then identifying
each of its interactions based on either the analyst‘s current knowledge or by asking others who may
have the knowledge.

The bottom-up approach: this approach refers to starting with a lower level data-flow diagram, identifying
known processes and the data that flows between them, and then following the data trail to uncover other
unknown processes. After the lower-level data-flow diagram is completed, the processes can be rolled
up to the system level.

The top-down approach is a more direct approach and is often the direction many analysts choose to take
(whether right or wrong for their particular situation). It can work well under some circumstances,
particularly if the system under consideration has only a few interactions with external entities or if the
same analysts support the application on an ongoing basis and are very familiar with all of the possible
interactions and dependencies that the system has. But if the system has a very large number of
interactions and dependencies or if the analyst is unfamiliar with the system then this approach can be
difficult. The less informed analyst would need to rely on a very iterative approach where the context
diagram is evolved over time by reviewing it with a number of subject matter experts that understand
pieces of the environment.

The bottom-up approach is a less direct method, but can be exceptionally valuable as an investigative
technique. Starting with a lower-level data flow diagram allows the analyst to document the bits and
pieces of the system that are understood and then follow the data to identify the various system
interactions and dependencies that exist. This tends to be a more natural approach as it uses the power
of the technique to document the entire scope of the system and its surrounding environment. In the top-
down approach it can be difficult to know when the analyst has reached completion since it‘s hard to
know that which you don‘t know. In the bottom-up approach the data-flow diagramming technique itself
drives the analyst to a state of completion.

Describe what is meant by Agile.

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
        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

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 a logical data dictionary and what are the benefits of maintaining one?

A data dictionary, also commonly called a metadata repository, is a centralized repository of data
elements and other metadata about them. This may include the meaning of a piece of data, relationships
to other data, origin, usage, type and length.

While the term metadata repository and data dictionary are often used interchangeably, many
organizations will define separate data dictionaries within a single metadata repository since the data can
be described in a number of forms. The first major differentiation in the way that data can be defined is
logically versus physically.

A logical data dictionary allows an organization to describe data in terms that business representatives
can more easily understand. It focuses on the meaning of the data and its relationships to other data.
Logical data also usually models the real world far more closely that physical data. The business may
have something that they refer to as a Sales Contract. This logical entity is of importance to the
business. The Sales Contract business entity, in order to be completely defined, is made up of or has a
relationship to other data such as Contract Participants, Contract ID, Contract Expiration Date, etc. How
this data is structured in a physical data model or database is of no consequence to the business
representative. At a logical level, the business representative cares about questions such as:

        What is a Sales Contract?
        What are the primary elements of a Sales Contract?
        Do these primary elements have attributes or data of their own?
        How does a Sales Contract relate to other relevant business entities?

Once data has been logically defined, the definition and relationships between various pieces of logical
data rarely need to change.

In contrast, a physical data dictionary allows an organization to describe data in terms of its physical data
structure, type, format, and length. Physical data dictionaries provide programmers of many different
systems with a tool to understand how and where the data is stored and how it must be referenced in
order to consume it. Physically data can be stored in many different ways in an effort to optimize data
integrity and increase the efficiency of data retrieval and data updates.

Since data is often stored in a number of physical ways, more than one physical data dictionary can be
defined. While a standard piece of data may be defined in terms of a common XML Schema structure
that is used by many different systems throughout the organization, it can also be defined in terms of a
physical database structure that is specific to a single system.

Both logical and physical data dictionaries can be mapped together within a central metadata repository
to provide traceability from one data element to another whether it‘s a physical or logical representation of
that data. Once the physical and logical data dictionaries are mapped together the logical data elements
and their descriptions provide a single, easy to understand view of the data used by the business and its

Finally, a logical data dictionary provides the added benefit of constancy since it changes infrequently. As
systems and technologies change, physical data structures do as well. But the logical data dictionary
remains relatively unchanged over time as it reflects relatively unchanging business concepts.

How is the Solution Assessment and Validation knowledge area of the BABOK v2.0

The purpose of the Solution Assessment and Validation knowledge area is to determine how closely a
solution meets the original stakeholder and solution requirements as well as describe the activities that
the business analyst should complete to ensure the successful implementation of solution. These
activities and tasks can be performed by the business analyst regardless of the type of solution being
implemented including a new or revised business process, organizational structure, outsourcing
agreement, software application, etc.

The tasks involved in solution assessment and validation can be performed on a single solution or be
used to compare several solutions for the one which will best satisfy stakeholder and solution
requirements while minimize implementation risk. Additionally, the business analyst will determine which
solution, if any, provides enough business value to justify its implementation.

The tasks involved in the Solution Assessment and Validation knowledge area include:

        Assess Proposed Solution
        Allocate Requirements
        Assess Organizational Readiness
        Define Transition Requirements
        Validate Solution
        Evaluate Solution Performance

How is the Requirements Analysis knowledge area of the BABOK v2.0 defined?

The Requirements Analysis knowledge area describes activities and methods used to analyze stated
requirements and transform them into a potential solution which possesses the capabilities that will fulfill
the stakeholder needs. It includes specifying and modeling both stakeholder requirements (requirements
which describe WHAT capabilities the solution must have in order to meet the needs of various
stakeholder groups) and solution requirements (requirements which describe HOW the solution will meet
the needs of stakeholders ).

Requirements analysis also covers developing domain models of the current state of the organization
which may be used to validate the scope of the solution with stakeholders, identify opportunities for
improvement, or to aid stakeholders in their understanding of the current state during solution review

The tasks involved in the Requirements Analysis knowledge area include:

    1.   Prioritize Requirements
    2.   Organize Requirements
    3.   Specify and Model Requirements
    4.   Define Assumptions and Constraints
    5.   Verify Requirements
    6.   Validate Requirements

What are the similarities and differences between a UML Class Diagram and Object

Class Diagrams and Object Diagrams use almost identical notations. Both represent a static view of a
system, however Object Diagrams represent a snapshot in time, whereas Class Diagrams are not time
dependent and are an abstract view of the types of objects that may exist within a system, the
relationships between them, and how and when one type of object can exist in relationship to another.
Since Object Diagrams represent specific object instances that exist at a single point in time, they are
sometimes called Instance Diagrams.

A few notable differences in the notation and rules used to represent Class and Object Diagrams are:

    1. Class Diagrams represent each class via a rectangle and display up to 3 types of information; the
         class name (not underlined), its attributes, and its operations. The Object Diagram also uses a
         rectangle to represent an object instance, however the object name is underlined and lists the
         name of the object followed by a colon and then the class name which describes its type (e.g.
         Joe: Student, where Joe is the name of the object instance and Student is class). Additionally
         the Object Diagram will list an object's attributes, but it will also list the value of that attribute at
         that point in time (e.g. SSN = 555-55-5555).
    2.   Class Diagrams enforce multiplicity rules between associated classes. For example, a Class
         Diagram may display an association between a Car and Passengers. The Class Diagram would
         show a single rectangle to represent the class car and a single rectangle to represent the class
         passenger, but display multiplicities stating that each car may have 1..4 passengers. An Object
         Diagram being a snapshot in time would show a rectangle for the Car and up to 4 separate
         rectangles, one for each passenger that exists at that movement in time.
    3.   Many of the constraints or association types that exist in a class diagram have no relevance in an
         object diagram. Multiplicities in a class diagram may constrain the number of passengers in a car
         to 4, but this rule would be enforced within the code itself such that a 5th passenger object could
         never be created. Therefore, multiplicities are not shown within an object diagram. Only the
         actual numbers of objects that exist at that moment in time are shown. Similarly, other
         constraints such as "at least one passenger be of type driver" could also be captured and
         displayed in a class diagram but would not be shown in an object diagram since these rules are
         enforced within the actual code.

When performing Cost-Benefit Analysis using discounted cash flows, how do you select
and appropriate discount rate?

Cost-Benefit Analysis (CBA) is a critical activity in the work of a business analyst. While many business
analysts may be brought onto a project well after this activity has occurred, nearly all projects which
require a large amount of resources (time, people, or money) are assessed based on the CBA of the
project. The activity is typically performed by a business analyst, often one specializing in the area of
financial analysis, though any business analyst can learn this straightforward activity.

The most prominent and well known aspect of CBA is Discounted Cash Flow (DCF) analysis which
discounts future cash flows (both negative and positive) using a Discount Rate to arrive at a Net Present
Value (NPV). This is represented by the following equation.

NPV = (FVpos – FVneg) / [(1 + i)^t]


        NPV = Net Present Value
        FVpos = Future Value of a Positive Cash Flow at ―t‖ years
        FVneg = Future Value of a Negative Cash Flow at ―t‖ years
        i = Discount Rate
        t = time (years from present)

Future cash flows are discounted using a Discount Rate (i) that is chosen to accurately reflect several

    1. Time Preference – The theory that a person or institution would rather have money in hand now
         to spend on immediate wants or needs rather than waiting for future cash flows.
    2.   Interest – Accounts for the fact that a person or institution that doesn‘t receive money for several
         years also loses the opportunity to gain interest on the money for that period of time.
    3.   Risk Premium – Reflects the additional return that a person or institution requires on later cash
         flows to account for the risk of future payments not materializing.

While the Discount Rate used for DCF calculations will vary, it becomes clear that the discount rate
should be larger than any single factor above. If the interest that can be attained on the money that is
being tied up is %5 per year, the discount rate should certainly be higher than 5% to account for Time
Preference and the Risk Premium.

How is the Enterprise Analysis knowledge area of the BABOK v2.0 defined?

The Enterprise Analysis knowledge area includes 5 tasks:

    1.   Define Business Need
    2.   Access Capability Gaps
    3.   Determine Solution Approach
    4.   Define Solution Scope
    5.   Define Business Case

The purpose of the Enterprise Analysis knowledge area is to describe the business analysis activities
required to compare the needs of the business against the current capabilities of the business and
identify opportunities for improvement. Then, based on this information, the analyst can determine which
solutions should be selected to resolve the issue. The output of this knowledge area provides helpful
background information for the Requirements Analysis knowledge area as well as the Solution
Assessment and Validation knowledge area. The work done during Enterprise Analysis is also helpful
for long term strategic planning as it paints a picture of the current state and capabilities of the business.

Before any new project is started, analysts and business stakeholders should understand how the project
goals and objectives fit into the overall direction and plan for the enterprise. Without the Enterprise
Analysis activities this wouldn‘t be possible.

What is Stakeholder Analysis and how does it benefit the business analyst?

Stakeholder Analysis is the process of identifying project stakeholders, how their needs may impact the
project, and the contributions that the stakeholders will make to the requirements elicitation process.
Projects typically have a large number of stakeholders from many different areas of the organization.
Based on each stakeholder‘s position and responsibilities, the level of their involvement and their
importance to the project will vary.

Stakeholder Analysis is sometimes called a Stakeholder Involvement Plan or a Stakeholder Elicitation
Plan. Regardless of the name used, Stakeholder Analysis goes beyond identifying project stakeholders.
After all project stakeholders have been identified, it should be determined how involved each stakeholder
should be in the requirements elicitation process. The business analyst should document a number of
factors for each stakeholder including:

        Importance – How important is the stakeholder in the requirements elicitation process? Are they
         required in order to document all of the critical project requirements, or are they nice to have
         adding clarity to processes that may further refine requirements? Answering these questions will
         help ensure that the project will meet its goals and objectives, and that critical requirements aren‘t
        Influence – How influential is the stakeholder to the project? Even if they aren‘t needed for the
         requirements elicitation, are they in a position of authority? Does the stakeholder have the ability
         to dramatically alter the course of the project if they hear about and are unhappy with the current
         direction of the project? Answers to these questions will ensure that the most influential
         stakeholders are updated on a regular basis with the project status.
        Level of Involvement – What level of involvement and how much time will be expected of each
         stakeholder? Do they need to be fully allocated to the project? Do they need to be in every
         requirements elicitation session? Can they be involved in only key requirements elicitation
         sessions? Do they only need to attend a final requirements review session? These questions
         help ensure that the necessary people are made available to the project for the right amount of
        Frequency of Involvement – How often will each stakeholder need to be involved; daily, every
         other day, once per week? This information will help the business analyst plan and schedule the
         necessary meetings accordingly.
        Method of Involvement – What method will be used to involve each stakeholder? Will they
         receive email-based status reports? Will they be involved in requirements gathering sessions?
         Will they be asked to sit in one-on-one requirements interviews? This information will aid in
         development of a communication plan and the appropriate selection of communication

What is Active Listening and how can it benefit the business analyst?

Active Listening is a method used to listen and respond to others in a structured and deliberate way. It
requires a listener to understand and actively evaluate what he or she heard. Actively listening can be
used to achieve a number of goals.

One of the more common goals of actively listening is to ensure that the listener accurately understands
what the speaker has said by replying back to the speaker and paraphrasing what they believe they have
just heard (―So, if I understood you correctly…‖). The speaker can either acknowledge that the listener‘s
understanding was accurate or can quickly identify any misunderstanding that the listener may have.
Actively listening helps the listener avoid incorrect conclusions due to unintentional assumptions that the
listener may have made. It‘s important to note that a listener that employs active listening is not
necessarily agreeing with the speaker.

Another goal of actively listening is for the listener to extract additional information from the speaker.
While listening to the speaker, the listener may notice something in the speaker‘s tone or body language.
By responding to the speaker with phrases such as ―you seem to feel …‖ the speaker has the opportunity
to confirm or correct the listener‘s understanding. This is a non-confrontational approach to asking follow-
up questions which clarify the speaker‘s intent.

Active Listening can be a powerful tool for business analysts during requirements elicitation.
Requirements elicitation often occurs during a period of a project where not everyone has the same
background knowledge and understanding of the project. Because of this, there are typically many
assumptions that are being made by each person as they build a framework in their mind of the project
and its problems and challenges. Actively listening can verify correct assumptions and dismiss false ones
resulting in a clearer and more accurate set of requirements.

How is the Requirements Management and Communication knowledge area of the
BABOK v2.0 defined?

The Requirements Management and Communication knowledge area describes what is involved in
managing and articulating requirements to a wide variety of stakeholders.

Requirement elicitation and understanding business objectives are an evolving if not iterative process.
Requirements management includes understanding the link between business or project objectives and
the specific requirements that comes from them such that any change or clarification in the objectives will
result in a revised set of requirements that reflect the business need. Furthermore, requirements
management is intended to ensure that the knowledge gained about a business, business process, or
system during the analysis phase is available in a useful form for future use.

Requirements communication takes into account that stakeholders vary significantly in their roles and
backgrounds. Due to this fact, which requirements are of importance to each stakeholder group and the
appropriate format and method in which to present these requirements will vary as well. The
Requirements communication part of this knowledge area takes this into consideration and ensures that
all of the stakeholders develop a common understanding of the requirements and solution being
presented with the ultimate goal of reaching a formal agreement on the requirements that the solution will
meet. Determining the appropriate level and format of requirements communication is critical to the
success of the project.

The tasks involved in the Requirements Management and Communication knowledge area include:

    1.   Manage Solution Scope and Requirements
    2.   Manage Requirements Traceability
    3.   Maintain Requirements for Re-use
    4.   Prepare Requirements Package
    5.   Communicate Requirements

What is Six Sigma?

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 Elicitation knowledge area of the BABOK and its key tasks (BABOK v2.0)?

The Elicitation knowledge area structures the activity of eliciting requirements into 4 main tasks. These
tasks are:

    1.   Prepare for Elicitation
    2.   Conduct Elicitation Activity
    3.   Document Elicitation Results
    4.   Confirm Elicitation Results

During Preparation for Elicitation, the business analyst will identify a combination of elicitation techniques
that will be used in the Conduct Elicitation activity. The appropriate techniques are identified based on a
number of factors such as the business domain, business environment, the skill level of the Requirements
Elicitation team, how open various stakeholders may be to different techniques, and the requirements
deliverables that need to be created.

The Elicitation knowledge area also describes commonly used techniques for eliciting requirements,
discusses what techniques are appropriate for a given situation, and provides information for the business
analyst to understand what‘s needed to prepare, execute, and deliver each technique.

Those various requirements elicitation techniques identified by the BABOK are:

    1.   Brainstorming
    2.   Document Analysis
    3.   Focus Groups
    4.   Interface Analysis
    5.   Interviews
    6.   Observation
    7.   Prototyping
    8.   Requirements Workshops
    9.   Survey/Questionnaire

What is the PDCA method and how is its application by the Business Analyst beneficial?

PDCA is a 4-step, iterative method commonly used for Business Process Improvement. PDCA stands for
Plan, Do, Check, Act. It was popularized by Dr. W Edwards Deming in the 1950s during his work in
Japan where he taught top management how to improve product design, quality, testing and sales.

The process is originally attributed to Walter A. Shewhart and was referred to by Deming himself as the
Shewhart Cycle. The Shewhart Cycle steps were listed as Specification, Production, and Inspection.
However, over time, the steps were shortened to the more easily remembered Plan, Do, Check, Act (also
referred to as PDSA—Plan, Do, Study, Act) where the Act step emphasized the need to take action on
the knowledge gained from the prior step.

PDCA (or PDSA) is firmly rooted in the Scientific Method—Hypothesis, Experiment, Evaluation. A
fundamental principle of these methods is iteration. Once the result of a process is confirmed (or
negated) the cycle is repeated and the new knowledge can be acted upon. It is this process of taking
action, measuring the results, and utilizing those results to develop the next course of action that make
the PDCA method and others like it, such as the Six Sigma DMAIC process (Define, Measure, Analyze,
Improve and Control), so powerful and beneficial as a tool for the Business Analyst.

These methods, and others like them, which employ and iterative feedback loop embody two key points:

        Creating a feedback loop based on measurable results
        Making incremental changes and improvements over time

What are the seven business analysis knowledge areas as defined by the BABOK v2.0?

The BABOK Knowledge Areas define categories of related information and tasks that a business analyst
must understand and apply.

Knowledge areas do not necessarily represent, or need to align with, phases of a project. There is no
specific order in which tasks from various knowledge areas must be performed by the business analyst,
as long as the necessary inputs for each task have been completed and are available. The seven
knowledge areas are:

    1.   Business Analysis Planning and Monitoring
    2.   Elicitation
    3.   Enterprise Analysis
    4.   Requirements Analysis

    5. Solution Assessment and Validation
    6. Requirements Management and Communication
    7. Underlying Competencies

How is the Business Analysis Planning and Monitoring (BABOK v2.0) knowledge area

The Business Analysis Planning and Monitoring knowledge area describes the process of how a business
analyst determines which activities will be needed to complete the business analysis effort. The tasks
within this knowledge area govern the business analysis tasks in all of the other knowledge areas. These
tasks include:

    1.   Plan Business Analysis Approach
    2.   Conduct Stakeholder Analysis
    3.   Plan Business Analysis Activities
    4.   Plan Business Analysis Communication
    5.   Plan Requirements Management Process
    6.   Manage Business Analysis Performance

What does the term 'Problem Domain' mean to a business analyst?

In broad terms, the Problem Domain describes the area undergoing analysis. The scope of the problem
domain needs to be identified upfront by the business analyst. The size and scope of the problem
domain can vary greatly depending on the goals of the project being undertaken. The scope may align
with the boundaries of an entire organization or it may be much more granular, aligning with a single
organizational unit, a specific business process, or a particular system.

Even when the scope of the problem domain aligns with the boundaries of a particular group or system it
may also include stakeholders outside of the process or organizational group such as customers,
suppliers, or any other stakeholder which provides an input or accepts an output of a process,
organization, or system.

In short, the Problem Domain is anything and everything that is needed to define the area under analysis,
fully understand the inputs and outputs of its processes, and achieve the goals of the area under analysis,
but nothing more.

What is RuleSpeak?

RuleSpeak is a set of guidelines for expressing business rules using a natural language (such as
English). Rulespeak is not a language or syntax itself but rather a set of guidelines to facilitate the
creation of business rules that are concise, consistent, and less ambiguous. Since the business rules
written following RuleSpeak guidelines use components of natural language that everyone is already
familiar with, it is easy to document the business rules in a business-friendly way while improving the
accuracy of communication between various business channels or the business and IT.

RuleSpeak was first developed in 1996 by Ronald G. Ross. Newer versions have been documented as it
has evolved over time.

In an effort to improve standardization for documenting business rules the Object Management Group
(OMG) released the Semantics for Business Vocabulary and Business Rules (SBVR) in 2007. Three

reference notations were used during the creation of SBVR including RuleSpeak. The latest version of
RuleSpeak is fully consistent with the SBVR standard.

How do you define a role?

A role describes a related set of activities that someone may perform to complete a process. Here are a
few examples of potential roles.

Someone with the role of Business Analyst may:

    1.   Document business processes
    2.   Analyze business processes to identify improvements
    3.   Gather business requirements that need to be supported by an automated system
    4.   Analyze business requirements and model them in a way that makes them more easily digestible,

Someone with the role of Project Manager may:

    1.   Document the tasks and activities required to meet specific project milestones
    2.   Assigned duration and effort to tasks
    3.   Create a project plan to track progress of the team
    4.   Document and escalate risks for the project, etc.

Someone with the role of Supervisor may:

    1.   Ensure that direct reports show up to work on time
    2.   Ensure that direct reports have the tools and resources required to perform their duties
    3.   Evaluate the work of direct reports
    4.   Mentor direct reports and assist them with careering planning
    5.   Make compensation recommendations, etc.

In order to more clearly understand what a role is, we can considered what a role is not, by comparing a
role to something that is commonly mistaken for a role such as a job title.

A job title is typically created and used by an organization to group employees together that have some
similarities in roles and responsibilities. This is typically done for a few reasons. First, it helps others in
the organization quickly recognize some of the activities that employees within the same job title are
responsible for. Second, it groups employees into large buckets to which the company can assign salary
ranges and bonus compensation. In addition, titles usually have a very distinct hierarchy, whereas roles
do not.

So how do job titles and roles relate to each other? The relationship between job titles and roles is many-
to-many. Consider the job title of Business Analysis Manager. A Business Analysis Manager may
perform the role of Supervisor, Project Manager, and Business Analyst, in addition to a number of other
roles. However, just because a Business Analysis Manager performs the role of Business Analyst
doesn‘t mean other job titles can‘t perform that role as well. The role of Business Analyst may
additionally be performed by employees in job titles such as Business Analysis Lead, Business Analyst,
Operations Manager, Process Engineer, etc.

Roles should always group together similar activities. How companies determine job titles is sometimes a
bit more arbitrary since they are used to differentiate employees in so many different ways
(responsibilities, reporting hierarchy, compensation ranges). When an employee is responsible for a
number of unrelated activities, that is a sure sign that they perform multiple roles.

So to recap, a group of related activities define a role. Roles, reporting structures, and other parameters
define a job title. An individual role can be performed by many different job titles.

Explain the difference between strategic and tactical as it relates to a business.

The terms strategic and tactical are typically used in a business environment to refer to the two main
types of planning, thinking, or action that takes place. Plainly stated, strategic refers to "what‖ and ―why"
the business chooses to do something and tactical refers to "how‖ they plan to accomplish it.

Strategic thinking, planning, and actions are rooted in a company‘s ability to understand the environment
they operate within, recognize developing patterns and trends within the industry, anticipate issues that
may arise within the current operating environment, predict outcomes of planned initiatives and how they
might impact the company‘s direction, and develop sound fallback plans to mitigate the risk of a
miscalculation. Strategic planning in particular deals with the mission and purpose of the organization, its
value proposition, i.e., what value it delivers to the customer, as well as the company‘s future direction
and growth.

Tactical refers to how the company or manager plans to get the job done or achieve the particular
strategic objective. Tactical thinking and planning consider the resources available (time, money, people)
along with the risks or challenges that may be encountered, and determines the most efficient way to use
those resources to achieve strategic goals while delivering quality results.

Some often remember the two concepts by using the mnemonic device, ―strategic is doing the right
things—tactical is doing things right‖.

What is Model-Based Management and what benefits can it bring an organization?

Model-Based Management refers to the activity of managing and making informed decision regarding the
future direction of a business, process, or system(s) based on information gleaned and understood from
models that document the current state.

More recently, the term Model-Based Management has been used with increasing regularity to describe
the use of models for strategic business planning. Emphasis has been placed on the importance of
models as it relates to capturing the complex nature of a business‘s structure, operations, systems, and
the economic environment in which it operates.

A model is simply an abstraction of reality. In this context, it is a representation of the current state of the
business and the environment in which it operates. Some models are already popularly used today for
strategic business planning. Consider financial models such as the balance sheet, income statement,
and cashflow statement. Each is an abstraction of the current state of the business. While the
importance of these models and their use in budgeting and financial planning are well know, the use of
models for decision making in all other aspects of a business is less ubiquitous.

Committing to a Model-Based Management approach across an entire organization can yield significant

        Models (if maintained) can always provide a clear representation of the current state of the
         business, mitigating the risk of making decisions based an inaccurate understanding of the
        Models can reflect different viewpoints of the same situation.
        Models can help identify bottlenecks or issues with a business process that would otherwise go
        Models can be used to anticipate outcomes of proposed changes to a business.
        Models can ensure completeness of a solution which is to be implemented.
        Models can increase the consistency and clarity of the communication of business change or
        Models can provide a means of tracking the specific value of a business activity, system, or
         service, by understanding the larger end-to-end process that it supports and the revenue
         produced by that process. This allows executives and manager to determine its true ROI(Return
         on Investment).

How do you resolve an issue involving conflicting requirements from two or more

In order to determine what action should be taken to resolve conflicting requirements, the analyst must
first determine the root cause of the conflict. The causes of conflicting requirements are typically the
same, time and time again. Here are a couple of the more typical causes and how you might deal with

1) One or more of the stakeholders/groups misunderstand the higher level divisional or company goals
which are driving their specific requirement. This leads them to push for a process or system requirement
that is not in line with the true needs of the business.

        Take some time to step back and level set everyone on the overall business case for the project.
         Set up a meeting to discuss the project/business goals. Avoid taking an approach of telling them
         in the meeting what the goals are, but instead ask the conflicting stakeholders/groups to reiterate
         the higher level goals themselves. It will quickly become apparent that not everyone is on the
         same page. Open conversation can then take place to gain consensus around the actual project
         goals. If necessary, the group can go back to a project executive or sponsor for clarification.

2) Both stakeholders/groups understand the higher level divisional or company goals, but each group
supports the company goals in very different ways. Both have legitimate needs which are relevant, but
they fail to realize that one group‘s contributions to the company‘s strategic vision may have less impact
than the other. This creates a difference in the way the needs of each group get prioritized at a company
level. So while one group may have a need which conflicts in some way with the other, one will almost
certainly take precedence.

        This is where a predefined escalation path is necessary. Both groups have a legitimate
         requirement to try and fulfill their own group‘s need. However, one will take higher priority over
         the other. An unbiased mediator with knowledge of the higher level divisional or business goals
         can be engaged to break the stalemate.

3) Both stakeholders/groups have the same goal, but they disagree over the best course of action for
meeting the goal. They may disagree over the best way to revise a business process or the best user
flow through a system.

        For a new business process, consider piloting the process with a select group of people for a
         short period of time. Measure the results from the new process and compare it to the old process
         to determine the level of improvement. Additionally, more than one potential process can be

         piloted, and the result of the two and be compared to determine the best overall process to
         implement. Present the findings of the piloted process to the group.
        For determining the best user flow through a system, create a storyboard of screen mockups or
         even a usable prototype. Schedule walkthroughs of the screens, storyboards, or prototype with
         end users of the new system. As you walk through each screen, as questions such as:
               What do you expect will happen when you click on this button?
               Where do expect the system will take you when you click here?
               What screen do you think will come after this one?

         Using the findings from the walkthroughs the team can gain consensus around the best possible
         system flow or UI design.

         If the conflict is specifically around the design of individual screens, rely on UI best practices and
         usability patterns to develop the screen design. Present information to the stakeholders
         describing why the usability pattern has been proven to work so well. Remind them that UI
         design and usability patterns are documented because they have been proven to work well for
         many other companies and projects, so they have withstood the test of system users over time.

What is Financial Ratio Analysis?

Financial Ratio Analysis is the evaluation and interpretation of a company‘s financial data using standard
financial ratios or accounting ratios to determine a company‘s financial state or condition. A financial ratio
or accounting ratio is a ratio of two values that are taken for a company financial statements (Balance
Sheet, Income Statement, Statement of CashFlows, Statement of Retained Earnings ) There are many
standard financial ratios used that have been identified as critical indicators of the financial performance
of a business. In addition to measuring a business‘ health, they can be used for strategic planning and
decision making. Financial ratios can be grouped into categories based on the financial aspect of the
business that they measure. The categories are:

        Leverage/ Debt Ratios - disclose to what extent debt is used in a company‘s capital structure
         which may indicate the company‘s ability to repay long-term debt.
        Liquidity Ratios – reflect a company‘s short term financial situation and availability of cash.
        Operational Ratios – indicate a company‘s operational efficiency and how well assets are utilized.
        Profitability Ratios - measures the rate of return that a company achieves through the use of its
         assets and control of its expenses.
        Solvency Ratios - measure a firm‘s ability to generate cash flow by converting its non-cash assets
         to cash in order to honor its financial obligations.

Financial ratio analysis is commonly used to compare a company‘s current financial performance to its
past performance, also called trend analysis, or it can be used to compare against other businesses
within the same industry. Comparison to businesses in different industries provides little value since
different industries have different risks which may require different capital requirements.

How do you keep management from reducing your estimated analysis hours in order to
fit their original high level guesstimates?

As seasoned business analysts, we are often asked to provide estimates for how long a particular set of
tasks might take. If you‘re working in an environment that is constantly trying to get more done with less,
then you probably have also experienced the difficult task of having to rationalize your estimates for a
large portion of analysis effort.

Consider the scenario where you provided the following estimates:
80 hrs – Documenting the AS-IS Business Process Flows

150 hrs – Eliciting and Documenting Requirements
100 hrs – Documenting the TO-BE Business and System Process Flows
400 hrs – Writing Functional/Design Specifications
Total 730 hours

Later you find out that while management was developing high level guesstimates for planning purposes
they ball-parked 500 hrs.

This is when the business analyst is now asked questions like…
Will it really take 150 hours to elicit and document requirements? Can you do it in 100 hrs? What about
Writing Functional and Design Specs? Can you do that in 350? Typically, the business analyst responds
with an ―I guess so‖ only to find out later that the work is behind schedule and they needed the full 730
hours, or more!

It can be difficult to defend the need for 400 hrs compared to 350 hrs when estimates are at such a high
level. For this reason, the business analyst should get into the habit of providing more detailed work
breakdown structures and estimates. By breaking each task down into more granular sub-tasks a
number of benefits can be realized.

    1. The level of error resulting from estimates tends to be smaller when more granular tasks are
         estimated. Business analysts have a fairly strong sense of how long a 6 or 8 hour task will take
         to complete. This is far different than estimating a 400 hour task. How do you really know if it will
         take 400 hrs, or 360hrs, or 440 hrs?
    2.   Management almost never questions estimates on very granular tasks. Have you ever heard a
         manager look at a work breakdown structure with 50 or more tasks and say, will this task really
         take 8 hours, or can you do it in 6? There are several reasons for this. First, they have a greater
         level of confidence in your ability to estimate a small task. Second, all they will save is two
         hours. That‘s nothing. By contrast, they see a 400 hour task and think they might be able to say
         40 or 60 hours. Now that‘s something.
    3.   Having a more granular work breakdown structure gets everyone on the same page as to the
         steps involved to complete the work. This may uncover dependencies that the team would not
         have noticed if they were only looking at the high level tasks.

A good rule of thumb is that no single task should be greater than 40 hours when estimating. And if you
know that your management has a habit of pushing back hard on estimates make sure that no single task
is greater than 20 hours, with most being less than 8-12 hours.

What is a Work Breakdown Structure?

The Work Breakdown Structure (WBS) documents the subdivision of tasks and effort required to
complete an objective or project. It is most often depicted as a tree structure where high level tasks break
down into lower level tasks. Low level tasks are typically grouped in various logical ways such as by
system, subsystems, project phase, or a combination of these. Beyond communicating the breakdown of
tasks into smaller more manageable components, the work breakdown structure is used to capture other
related task information such as effort, duration, and responsibility.

While the Work Breakdown Structure typically originates as a planning and sizing document, it continues
to be managed and maintained throughout the duration of the work effort as a control document. Project
managers and team members use the work breakdown structure as a baseline document to ensure that
progress towards the end goal is being completed on time and within budget.

What is a UI Design Pattern and what are its benefits?

UI Design Patterns are an important aspect of application and website usability and user experience.

UI Design Patterns (also commonly referred to as Interaction Design Patterns) document and convey
robust UI design solutions, that have proven to be successful over time, to common usability

Properly applying UI Design Patterns ensures the UI designer that the application or website will be
intuitive and its features and functionality robust.

There are many benefits to using patterns including:

1. Teaching new UI designers, analysts and developers best practices and common approaches to solid
UI design.

2. Speaking about UI design in standard terms that everybody understands.

3. Reducing the time and cost required to design UIs, since it always takes longer to reinvent the wheel.

Using metaphors that have been tested across a number of different contexts.

4. Making it easier for users of a new application or website to understand how the interface should be
used to accomplish their tasks since users have seen the same pattern used many times before.

5. Ensure a consistent user experience across screens within an application and across multiple
applications within a product suite.

What are some guiding principles or tenants of UI design?


Ensure that the system includes the most important features and functions needed to provide value to the
user. A system that is missing high priority functionality is not going to be very valuable. Similarly, a
system that includes too much additional functionality which lacks relevance to the user will obfuscate the
intended flow through the system.


Consistently apply the UI design patterns that your group has agreed upon and adopted ahead of time.
This includes UI actions, product terminology and UI commands. UI design pattern consistency is
important across screens within an application as well as across applications within a suite of products.
Whenever appropriate, the concepts, terms and metaphors used should mirror that of the real world and
present information in a logical order.


Keep the design clean and clutter free eliminating any unnecessary or irrelevant information, features,
controls, or icons. When many options are available for a user to complete their task, keep the most
commonly used options visible and make the other options readily accessible via some other means.
Design the system with the goal of being intuitive enough that an appropriate user of the system can learn
it without instruction or formal training.

Communication and Feedback

The system should provide clear and timely feedback in response to user actions. This reinforces within
the user‘s mind that they have taken the correct step to successfully complete the task. Organize and
sequence the information within a screen in a way that conveys specific meaning to the user. Like
information should be grouped together and the order in which a user encounters information should
reinforce the flow of the process as they currently understand it. Ensure that whatever help information is
provided is concise and focuses specifically on the user‘s task.

Error Prevention and Handling

A system cannot and should not catch all mistakes. It should catch serious errors when possible, but
should not be so restrictive that it does not allow for reasonable variation in data entry or process flow.
Ask the user for confirmation before allowing a potentially destructive action such as permanently deleting
a record. If the user performs an incorrect action, provide clear and descriptive messaging that describes
what they have done wrong and when possible how they can correct it. To relieve anxiety, provide the
user with the ability to discard unwanted changes, or to undo a particularly sensitive action.


Ensure that skilled users can use the system efficiently and that functionality built for inexperienced users
does not slow down skilled users. Provide shortcuts keys and functions for the experienced user and
allow for customization of shortcuts when possible for frequent actions.

Workload Reduction

Automate aspects of the process and system whenever possible. If something can be easily derived by
the application then don‘t make the user spend time doing it. Eliminate mental calculations and
comparisons by showing the results on screen. Ensure that users don‘t need to remember information
from one screen to another. Provide the necessary information on each screen for them to be able to
complete their work.

Designer Judgment

Remember that usability guidelines are just that, guidelines. There are tradeoffs between perfect UI
design, user experience, and system performance. There will always be cases where it makes send to
not follow a particular guideline or principle. Use your judgment. However, try to stray from guidelines as
infrequently as possible and, when doing so, be sure to document the reason why the guideline was not
followed for future reference

What is the Herfindahl Hirschman Index (HHI) and why would you use it?

The Herfindahl Hirschman Index (HHI) is a measurement used to understand the level of competition that
exists within a market or industry, as well as give an indication of how the distribution of market share
occurs across the companies included in the index. Understanding the level of market competition can
be important for strategic planning as well as when trying to establish pricing for a company‘s products or
services. The calculation of the HHI differs from the standard Concentration Ratio in that it squares each
market share value which places a higher importance on those top companies that have a larger market
share. The formula for determining the HHI is as follows:

             2    2        2       2         2
HHI = MS1 + MS2 + MS3 + MS4 …+ MSn

The HHI can have a theoretical value ranging from close to zero to 10,000. If there exists only a single
market participant which has 100% of the market share the HHI would be 10,000. If there were a great
number of market participants with each company having a market share of almost 0% then the HHI
could be close to zero.

        When the HHI value is less than 100, the market is highly competitive.
        When the HHI value is between 100 and 1000, the market is said to be not concentrated.
        When the HHI value is between 1000 and 1800, the market is said to be moderately
        When the HHI value is above 1800, the market is said to be highly concentrated.

These values are used by the Department of Justice when evaluating whether to permit a merger of two

Using the HHI, we can quickly gain insight into the distribution of market share within an industry. The
example below demonstrates the additional information that can be gleaned from the HHI over the
Concentration Ratio.

Example 1

Market                                          8
             1 2 3 4 5 6 7                          9   10 11 12 13 14 15
Share 100 12 12 11 11 10 10 9                   8 6     3    3    2    1     1   1
CR8      83 12 12 11 11 10 10 9                 8
HHI      920 144 144 121 121 100 100 81         64 36 9      9    4    1     1   1

Example 2

Market                                                                  12
              1    2        3    4    5   6    7    8   9    10 11           13 14 15
Share 100 39 23             17 4      3   2    2    2   2    1    1     1    1   1     1
CR8      92   39 23         17 4   3      2    2    2
HHI      2381 1521 529      289 16 9      4    4    4   4    1    1     1    1   1     1

In this example, both industries have 15 companies that make up 100% of the market share. In example
1, the industry has a more evenly distributed market share across the 15 companies, while example 2
shows a heavy concentration of market share among the top three companies.

If a business analyst were only to look at the difference in Concentration Ratios (accounting for the top 8
companies) between the two examples, they would see that the CR8 of example 2 with a value of 92 is
only 11 percent greater than the CR8 of example 1 with a value of 83. However, using the HHI they would
find that the HHI of example 2 at 2381 is 259% greater than the HHI of example 1 at 920.

What is a Concentration Ratio and why would you use it?

Concentration Ratio (CR) is a measurement used to understand the level of competition that exists within
a market or industry in which a company operates. Understanding the level of market competition can
be important for strategic planning as well as when trying to establish pricing for a company‘s products or
services. The Concentration Ratio provides a view of the market and of the price sensitivity that may
exist for the company‘s products or services. A highly competitive market will have much greater price
sensitivity giving a company less pricing power than it might otherwise have in a market which is less
competitive (only a few key players reflecting an oligopoly or monopoly).

The Concentration Ratio is often determined for the top 4, 8, 20, 25, and 50 largest markets participants
by revenue. However, the most prominent Concentration Ratio used to measure market competitiveness
is the CR4 which is determined by measuring the total market share (MS) of the 4 largest market players.
The formula for determining any Concentration Ratio is as follows:

CR‘n‘ = MS1 + MS2 + MS3 + MS4…+ MS‘n‘, where ‗n‘ is typically 4, 8, 20, 25, or 50.

In the case of the CR4 (4 largest companies by revenue), if the total is less than 40% then the market is
said to be competitive. If the CR1 value (single largest company by revenue) is greater than 90 then
effectively a monopoly exists.

One of the cons of using the Concentration Ratio value alone is that it doesn‘t give any indication of how
the distribution of market share occurs across the companies included in the ratio. Are there a few key
players in the lead and everyone else shares a very small percentage? Or is there a fairly even market
shar distribution across all market players? For this reason, some choose to use another value for
determining market concentration called the Herfindahl Hirschman Index (HHI).

Concentration Ratios for US markets and industries can be found at the US census bureau

What is a View as it relates to system modeling?

A view organizes diagrams into logical groups to describe a particular aspect of the system. It is the
abstraction of the system organized is such a way as to give a perspective of a related set of concerns.

The purpose of using views as a business analyst is to enable the analyst to comprehend very complex
systems, and to organize the problem or solution domain around specific areas of expertise. The
audience interested in each view may vary based on their roles and experience. A subject matter expert
from the business will ask different questions and have different concerns than a developer or system
architect. Views help present the information in an easily digestible manner.

The different views that a business process or system should be broken into varies and is the decision of
the analyst and the stakeholders involved in the project.

Some common views used by analysts are:

        The Behavioral View – A view showing the functionality of the system as perceived by external
        The Logical View – A view showing how the functionality of the system is designed in terms of the
         logical static structure and dynamic behavior.
        The Implementation View – A view describing how the physical code is structured, its main
         modules, and their dependencies.
        Deployment View – A view showing the physical deployment of the system such as computers,
         servers, switches, routers, etc.

        Organization View – A view depicting organizational elements, their structure, and their
         relationships. This may include people (an org chart), agreements, contracts, policies and
         organizational interactions.
        Requirements view – A view describing the requirements, goals, and objectives that the system
         shall support.

Not all of these views would necessarily be used together. They belong to multiple standardized view

Some standard view models or frameworks exist which dictate how systems should be organized into
standards views. Some examples are:

        4 + 1 View Model
        Department of Defense Architecture Framework (DoDAF)
        Reference Model for Open Distributed Processing (RM-ODP)
        Zachman Framework

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

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

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.

Describe Convergent and Divergent Thinking as a Problem Solving Technique

Divergent and Convergent thinking when used together can help an analyst arrive at better and more
creative solutions than he or she otherwise might have. Divergent thinking is the process of breaking a
topic down and generating many ideas that branch out from the original concept while Convergent
thinking is the process of focusing on a fewer set of ideas and evaluating them based on selection

Divergent and Convergent thinking can be used together in a three step process:

    1. Brainstorming
    2. Reducing and Categorizing
    3. Ranking and Selecting

The first step, brainstorming, is a divergent thinking process and is most effective when a couple of
guidelines are followed. When using divergent thinking to generate a list of potential solutions, remember
the following:

    1. The more ideas that are generated the better
    2. Generate new ideas by building on previous ones
    3. There is no such thing as bad ideas (even off-the-wall ideas can help generate other more viable
    4. Don‘t evaluate ideas during the divergent thinking process

Once a list of potential ideas has been generated, the second step of reducing and categorizing can take
place (a convergent thinking process). During this step the most impractical ideas will now be eliminated
and the remaining ideas can be grouped together into different categories based on their similarities.

Finally, the remaining list of ideas can be ranked based on the pros and cons of each (another
convergent thinking process) and a final solution selected.

Consider the following example of using Divergent and Convergent thinking for problem solving.

A manufacturer of jumbo hard pretzels always experiences a certain amount of broken product on their
manufacturing lines. They have initiated projects in the past to reduce the amount of breakage from 7%
to 4% measured by weight. However, is would not be cost effective to try and reduce breakage further
via other projects. Each week all of the pieces of broken pieces are collected and discarded. What other
options might the company have to reduce or eliminate their losses due to broken product?

Step 1: Brainstorm

        Sell the broken product to a dog food company as a filler ingredient for dog food
        Sell the broken product to a mulching company to be used as mulch
        Sell the broken product to a shipping company as packaging filler
        Sell the broken product to a bird food manufacturer
        Season the broken product and market and sell it as a new product of its own
        Give the broken product to a food shelter and take it as a tax write off
        Develop a product that affixes the pieces together to form a bio-degradable ―clay pigeon‖ for
         skeet shooting

Step 2: Reducing and Categorizing

         Category: Sell to another company

        Sell the broken product to a dog food company as a filler ingredient for dog food
        Sell the broken product to a mulching company to be used as mulch (impractical)
        Sell the broken product to a shipping company as packaging filler (impractical)
        Sell the broken product to a bird food manufacturer

         Category: Develop another product internally

        Season the broken product and market and sell it as a new product of its own
        Develop a product that affixes the pieces together to form a bio-degradable ―clay pigeon‖ for
         skeet shooting

         Category: Tax write off

        Give the broken product to a food shelter and take it as a tax write off

Step 3: Ranking and Selecting

    1. Season the broken product and market and sell it as a new product of its own (Selected for
         maximum revenue)
    2. Give the broken product to a food shelter and take it as a tax write off
    3. Develop a product that affixes the pieces together to form a bio-degradable ―clay pigeon‖ for
         skeet shooting
    4. Sell the broken product to a dog food company as a filler ingredient for dog food
    5. Sell the broken product to a bird food manufacturer

Quality Assurance versus Quality Control

Quality Assurance is about Process. It describes the proactive method of establishing a process that is
capable of producing a product or deliverable that is error or defect free. Expanding on this further, we
can see that:

    1. Quality Assurance means time is spent upfront planning and designing a process that can
         repeatedly produce a high quality product or deliverable.
    2.   Quality Assurance provides confidence that if the process is properly followed, there is a high
         likelihood that the final product or deliverable will meet specifications. In other words, it reduces
         and prevents defects or errors in the final product or deliverable.
    3.   Quality Assurance is about establishing a sound and capable process.

Quality Control is about Products or Deliverables. It describes checking a final product or deliverable to
ensure that it is defect or error free and meets specifications.

    1. Quality Control occurs after the process is completed.
    2. Quality Control is about verifying that the product or deliverable meets specifications. It detects
         errors and defects in the final product before the product reaches the customer.
    3. Quality Control focuses on the end product or deliverable.

To summarize, Quality Assurance is focused on the process, is proactive, and prevents defects; while
Quality Control is focused on the product or deliverable, is reactive, and detects defects after the fact.

How might you reduce the occurrence of errors within a manual and highly repetitive

Business Analysts often analyze processes with the goal of improving them. Introducing the
right change to a process can bring about increased efficiencies and eliminate costly delays
or problems, and understanding how to eliminate errors is a critical skill for business

Manual and repetitive processes are prone to increased rates of errors or defects. The
human factor inevitably leads to a drop in attention levels over time. Introducing a few
quality checks throughout or after the process can help.

For example, let’s assume that a worker has the task of copying 100 articles from one
repository to another, but during the process of copying the articles all formatting is lost
and needs to be reapplied. How can the business analyst ensure that the worker completes
the job with a relatively low error rate?

Introducing intermediate measurements into the process can help. Consider the type of
formatting that needs to be done for each article. The worker may need to:

        Add paragraph breaks
        Add bold, italics, or underline to words
        Re-introduce any images into the article
        Turn text into a hyperlink, etc.

So to ensure that the job is done correctly, the business analyst could introduce the
following checks into the process. After each article is copied and reformatted the worker

        Count the number of paragraphs in each article and make sure they are the same
        Count the number of bold words in each article and make sure they are the same,
         and repeat the process for italicized and underlined words
        Count the number of hyperlinks in each article and make sure they are the same
        Test each hyperlink to ensure it goes to the right webpage

If the worker performs each of these checks, the business analyst can be fairly assured that
the process has been completed error free.

What is the difference between a use case specification and a use case realization ?

A Use Case Specification is a textual description of the functionality provided by the system. It captures
actor-system interaction. That is, it specifies how a user interacts with a system and how the system
responds to the user actions. It is often phrased in the form of a dialog between the actor and the system.
The use case specification is represented in the use case diagram by an oval, and is what most people
think of when they hear the term use case.

A Use Case Realization describes how a use case, which is logically defined by the use case
specification, is physically implemented within a design model in terms of collaborating objects. It
organizes the design model artifacts related to the use case. It often comprises multiple design artifacts
such as a class diagram, object diagram, sequence diagram, etc. that describe how the physical design
will implement the use case specification.

The purpose of use case realization is to separate the concerns of the system stakeholders, which are
typically captured by the use case model and system requirements, from the concerns of the system
designers. In doing so, the designers can choose to implement the use case specification without
affecting the use case specification.

What is the difference between a Business Analyst and a Technical Writer?

The role of a Business Analyst is a broad and encompassing role with many different
specializations. Business Analysts may specialize in the areas of Business Process Analysis,
Systems Analysis, Requirements Engineer, Data Analyst, Functional Architect, Product
Manager, Usability/User Experience Analyst, and at times Technical Writer. However, while
a Business Analyst may perform the role of a technical writer at times the profession of
technical writer can stand on its own.

A technical writer’s role is a collaborative and interactive one. Their primary deliverables

       Technical manuals that describe the specific features of a product or application
       Producing online step-by-step tutorials with illustrative graphics and images to aid
        the reader
       Producing web-based training and other forms of training materials

To produce these deliverables the technical writer must acquire a detailed knowledge and
understanding of the product or application for which they are producing the
deliverable. This requires them to work with analysts and developers of the system, end
users of the systems, and often to test certain features of the system themselves.

Given the skills required to perform this role, the most common academic backgrounds for
this profession are English, technical communication, science or engineering, computer
science and journalism according to the Society for Technical Communication.

What are some of the challenges you face in your role as a Business Analyst?

1. The Business Analyst must always maintain a reasonable balance between technology
constraints and business needs. Often due to technological constraints the technology team
argues for a particular solution that avoids certain technology pitfalls while maximizing
performance and maintainability. While these are important concerns that should be
addressed, the business analyst must always remember that technology exists to support
and facilitate the business need. So business needs must carry a higher weight when
determine acceptable trade-offs between business and technology. This can be summarized
as ―technology is important but business in essential‖.

2. The Business Analyst must always ensure that his or her personal assumptions about
how a process works do not interfere with their ability to listen and accurately document the
requirements of the business. While challenging, a few techniques can be used to
accomplish this. The easiest to implement is the ―3 Whys‖. While documenting a business
process, anytime a subject matter expert explains a step of the process ask why that step
occurs—what is the necessity or benefit of the action. By asking why no less than 3 times
the analyst ensures that they arrive at the root cause or need of the step. This helps
identify the true requirements. This technique also overcomes the challenge of a business
analyst’s personal assumptions of the process obscuring the true process and requirements
since they are asking the ―3 whys‖ even if they believe they know the answer to the

3. The Business Analyst must ensure that the written specifications clearly represent what
the developers must code. Often any written description of business logic to be
implemented end up being ambiguous, specifically it can be interpreted in several ways. To
avoid this, the business analyst can use a more structured approach than simply writing the
specifications in common everyday English. Structured English or Pseudocode is one

approach. These are relatively synonymous terms that refer to logical control structures
that are applied to everyday English. An example of this would be:

IF condition written in plain English THEN
     Action written in plain English
ELSE condition is not true then
     Action written in plain English

While all of the conditions and actions to be taken are written in English, the logical control
structures provide a consistent and unambiguous way of understanding the intent of the
information being conveyed.

What is a fishbone diagram?

A fishbone diagram is a problem-analysis tool that derives it’s name from it’s shape which resembles the
skeleton of a fish. Developed by Dr. Kaoru Ishikawa, a Japanese quality control statistician, the fishbone
diagram is a systematic way of looking at an effect and identifying and capturing the causes that
contribute and result in that particular effect. For this reason, it is sometimes referred to as a cause and
effect diagram.

The fishbone diagram is useful in:

    1. Identifying the possible root causes of a particular problem
    2. Identifying the most likely cause of a particular problem
    3. Identifying areas that may be good candidates for data collection/measurement and

To develop a fishbone diagram:

    1. Draw a horizontal line for the spine of the fish and list the main issue/effect at the
        head of the fish
    2. Draw 4-6 vertical lines extending above and below the spine of the fish. Each should
        start at the spine of the fish and slant away from the head of the fish. These ―major
        bones‖ are used to define the categories of causes that are to be identified. These
        categories can be whatever you think would work best, but are typically standardized
        from company to company or team to team. The categories are used to provide a
        framework for the brainstorming and documenting of causes. Some of the common
        categories are listed here. The point is you can use whatever categories you team
        feels is best.
             Methods, Machines, Materials, Manpower, Mother Nature, Measurements (the
                6 M’s, often used for the manufacturing industry)
             Place, Procedure, People, Policies (the 4 P’s, often used for the service
             Surroundings, Suppliers, Systems, Skills (the 4 S’s)
        Brainstorm on the causes that result in the effect that you are analyzing. For each
cause identified, determine which category it falls within and draw a ―minor bone‖ or a line
from the ―major bone‖ of the category. Document the cause on the ―minor bone‖.
        For each cause, ask yourself why the cause occurs. Typically a cause is itself and
effect of another cause. By drilling down farther and farther you can eventually arrive at the
root causes of the effect you are analyzing.
        Identify which causes appear under multiple categories. These are often you most
likely cause of a recurring issue and deserve the most attention .

What is a SIPOC Diagram?

The SIPOC diagram is a tool that is used to outline the scope of a process improvement initiative (often
as part of a Six Sigma improvement project). The tool captures all of the relevant elements of the process
under consideration. When used as part of the Six Sigma methodology, it is typically implemented as part
of the Measure phase of the DMAIC process. The diagrams name is an acronym for the elements that
need to be identified and documented.

S – Suppliers: Who supplies the inputs to the process under consideration
I – Inputs: What are the inputs to the process
P – Process: What are the steps of the process that is being improved upon
O – Outputs: What are the outputs of the process
C – Customers: Who are the customers or beneficiaries of the outputs of the process

One common variation of the SIPOC diagram is to append R (Requirements) to the end of the diagram
for additional detail. This is a fairly natural extension of this diagram since the team has identified the
customers of the process and can naturally begin to identify the needs of each customer.

To create the SIPOC diagram complete the following steps:

1) List the 5 categories in order (Suppliers, Inputs, Process, Outputs, Customers) across the top of a
piece of paper or whiteboard. If you choose to include requirements as a sixth category then you will list
it last on the far right of the paper or whiteboard.

2) Begin with the Process column. List and number the highest level steps of the process under the
process column header. Keep it to 4-7 high level steps if at all possible. If you would prefer, you can
reference a diagram for the high level process and insert the diagram at the bottom of the page.

3) Review each step of the process to identify and document the outputs of the process under the
Outputs column.

4) Document the customers that will receive or benefit from each output under the Customers column.

5) Next, identify the inputs that the process requires to properly produce the outputs. Capture these
under the Inputs column.

6) Document the suppliers of each input under the Suppliers column.

7) If you chose to include a sixth column for requirements, identify and document the high level
requirements that each customer has for the process under consideration. Think about why the process
exists. What customer need is it intended to fulfill.

What are the features and qualities that should be expected of a software modeling

There are a number of features that should be supported by modern software modeling tools:

Diagram Creation: A tool needs to be able to support the easy and intuitive creation of diagrams. It
should also be robust enough to be able to enforce at least a minimal level of diagram semantics and
rules so that it can inform the user of inaccuracies or discourage the incorrect use of model
elements. Models and diagrams should support multiple levels of abstraction while maintaining the link
between common or supporting elements between diagrams.

Repository: A tool should support a repository that stores all of the information about a model in a
single location. This common storage of model information and meta-data allows the user to make
changes to a model element in one diagram and have the changes propagate to other diagrams where
the model element appears. Ideally the repository will support multiple software development
environments so that as code is migrated from a development environment to a test environment, etc.,
the repository can support a version of the model for each environment and allow for migration of the
model in parallel with the software development process.

Linked Navigation: A tool should provide the ability to follow a common model element from one
diagram to another within the model, as well as drill down through multiple levels of model abstraction by
linking model elements at higher levels of abstraction to supporting elements at lower levels of

Multi-User Support: A tool should support the ability for multiple users to work on a single model
simultaneously through appropriate notification and object locking mechanisms.

Code from Model: Advanced tools will be able to create code, in a number of common languages, from
a validated model.

Model from Code: Advanced tools will be able to accept code as an input, in a number of common
languages, and output a model that can be used as a basis for further refinement.

Integration with Other Tools: Some tools will support integration with other software development
tools such as tools that support coding, configuration and version control, testing tools, user interface
tools, requirement specification/documentation tools, and project management tools.

Interchange Mechanisms: A tool should support the ability to interchange models (both
importing models and exporting models) between modeling tools using a standard
interchange language such as XMI.

Which project participants benefit from Use Cases?

The full benefit of use cases are not always understood by all. Use cases provide more
benefit than simply capturing functional requirements of the system, and therefore benefit
more project participants than just the commonly understood project stakeholders. Here are
some of the beneficiaries of use cases.

Project Stakeholders: For project stakeholders, use case models and use cases specify
the functionality and interaction that a user will have with the system. It is written in a
simple to understand form so that it can be understood by even the most diagram adverse
individuals. By reviewing and gaining signoff from the project stakeholders, use cases help
analysts validate that the system will meet the functional requirements expected by the
stakeholders and will as a contract of what will be delivered.

Developers: Use case models provide a high level overview of the system functionality to
the developers. The use cases and use case scenarios add the detail required for a clear
understanding of system functionality and provide a solid foundation for the developers to
continue with detailed design. By completing the detailed design with the use case model as
a guide, the system design remains user-centric ensuring that the final system delivers on
the requirements and needs of the stakeholders.

Analysis, Development, and QA Managers: Use case models are an excellent tool for
estimating the level of effort required to complete analysis, development, and testing of the
application. The use case model divides the system into logical pieces that can be assigned
a complexity value and then each use case can be estimated and aggregated to create a
final effort estimation.

Project Managers: Use case models are a great tool for project mangers to plan and track
the progress of work. Use case models become especially useful in iterative development
environments where iterations are planned around the successful implementation of use
cases. Use cases are often used in this way because it is easy for stakeholders to see the
value of each use case, and therefore the value of each iteration of the application that has
been implemented.

Integration and System Testers: Use cases and use case scenarios directly translate into
test cases and test scenarios that are used to validate and verify the successful
implementation of the system requirements.

Anyone Requiring System Knowledge: Any time someone needs to know what a system does, one
of the best places to start is the use case model. By reviewing the use case model, anyone can gain a
quick understanding of the functionality of the system. Once they find the use cases that reflect the
functionality that pertains to them, they can then look at the details of each use case and gain an
immediate understanding of the functionality supported.

How do you identify your list of use case actors?

An actor is someone or something that interacts with the system by sending or receiving
messages or information to and from the system. Primary actors initiate the interaction with
the system. Secondary actors do not initiate the interaction with the system but participate
in one or more use cases of the system, often providing information back to the system.

Use case actors can be identified by asking a number of questions:

        Who will use the system to support their daily work?
        Who will maintain, administer, or configure the system?
        Who will use the output, information, or reports from the system?
        What systems or services will require information for the system?
        What systems or services will provide information to the system?

What is a Daily Scrum Meeting?

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.

What are User Stories?

Extreme Programming (XP), one of many Agile methods, introduced the practice of User Stories. They
are short descriptions of functionality the system should provide. The initial descriptions are often
created or written by the users or customers of the system. The user stories are used during the
iterative planning and development cycles to determine a unit of work and estimate how long it will take.
Most practitioners strive to make a user stories fit into a 1-3 week span of development

User stories do not end at a 2-3 line description of functionality. Each user story consists of three parts:

        The Card: Named for the standard index cards on which a user story is often
         captured. The cards are used for planning the work that will be completed during
         each iteration of development.
        The Conversations: Discussions about each user story are had with the
         users/customers of the system to flesh out details. The conversations are captured
         and documented as part of the user story.
        The Confirmation: Test scenarios that capture details about the user story that can
         be used to verify that the user story has been successfully implemented.

Using these three parts, the goal of the user story is to provide enough detail that a developer can
understand what needs to be done while providing a means to verify that they have achieved the goal.
User stories are often equated to a single use case scenario, such as the main use case scenario or an
alternative path. The “Card” portion of the use case scenario is written in a manner similar to a brief
description of a use case.

What is a Burndown Chart?

A Burndown Chart is a tool used by multiple software engineering methods to track the progress of work
completed. It compares the amount of work remaining (typically measured along the vertical axis)
against time (measured along the horizontal axis). The amount of work remaining can be measured in
whatever way works best for the project, i.e., work-hours, work-days, story points, or any other work
unit. Similarly the time axis can be measured using a variety of units, the most common being days or
iterations. The burndown chart gives a quick view of the amount of work that is completed over time.

When applied to Agile methods such as Scrum, this tool can be used to track progress at the Sprint level
(a specific iteration of development) or at the release level (multiple iterations that deliver the total
functionality for a product release). After the amount of work completed has been measured over several
units of time, the burndown chart can be used to forecast the completion of an overall release or project.

Tell me about a time when you were faced with a requirement/enhancement that was
not feasible. How did you handle the situation?

Even if you know that a requirement is not feasible, be sure not to simply dismiss it away. Your
responsibility as an analyst is to maintain a strong working relationship with the business
representatives. Approach this situation in a way that makes it clear that the decision isn’t a personal
one, but that it’s based on a well informed position with associated costs.

Clarify the requirement. Remember, often when a “requirement” is elicited it is really stated in the form
of a solution. So take the time to verify the true requirement.

Identify why the requirement isn’t feasible. If the new requirement and the previous requirements
cannot be accommodated at the same time regardless of the technical implementation, then present this

information to the business. Do your best to explain the technical limitations using non-technical
language that the business can understand.

Most often however, the implementation of a new requirement isn’t feasible due to the prohibitive cost
that would be involved in making the technical changes required to support it. Estimate the associated
cost and present this information to the business. This is helpful for a few reasons. First, you may have
assumed that the cost outweighed the need for the requirement, but the business may feel differently
depending on the business goal driving the requirement. Second, if the business agrees the cost of
implementing the new requirement is just too prohibitive, then you as the analyst have made your case
while making the business feel empowered and involved in the decision making process.

What is an Activity Diagram and what is its purpose?

An Activity Diagram is a behavioral diagram that shows the flow or sequence of activities through a
system. The terms activity diagram and process flow are often used interchangeably. However, the term
activity diagram is typically more restrictive as it refers to one of thirteen standard Unified Model
Language (UML) diagrams. Activity Diagrams are one of the most commonly used diagrams since its
notation and origin are based on the widely known flowchart notation.

If you were to group software requirements into levels, how might you group them?

The Business Analysis Body of Knowledge® (BABOK®) defines the following levels of requirements:

        ―Business Requirements are higher-level statements of the goals, objectives, or
         needs of the enterprise. They describe things such as the reasons why a project is
         initiated, the things that the project will achieve, and the metrics which will be used
         to measure success.
        Stakeholder Requirements are statements of the needs of a particular stakeholder or
         class of stakeholders. They describe the needs that a given stakeholder has and how
         the stakeholder will interact with the solution. Stakeholder Requirements serve as a
         bridge between Business Requirements and the various classes of Solution
        Solution Requirements define the characteristics of a solution that meets the
         Business Requirements and Stakeholder Requirements. They are frequently divided,
         particularly when the requirements describe a software solution, into:
               Functional Requirements describe the behavior and information that the
                 solution will manage. They describe capabilities the system will be able to
                 perform in terms of behaviors or operations – a specific system action or
               Non-Functional Requirements capture conditions that do not directly relate to
                 the behavior of functionality of the solution, but rather describe
                 environmental conditions under which the solution must remain effective or
                 qualities that the system must have. They are also known as quality or
                 supplementary requirements.
        Implementation Requirementsdescribe capabilities that the solution must have in
         order to facilitate transition from the current state of the enterprise to the desire
         future state, but that will not be needed once the transition is complete‖ (Business
         Analysis Body of Knowledge® 2008).

BABOK and Business Analysis Body of Knowledge are registered trademarks owned by the
International Institute of Business Analysis.

According to Ian Sommerville (1997) the software requirements types are:

        User requirements: are written for customer in natural language and
         simplified diagrams which describe system features and services.
        System requirements: are written as a contract between client and the
         contractor, and it is a structured document setting out detailed
         descriptions of the system services.
        Software specification: A detailed software description which can serve
         as a basis for a design or implementation and are written for

According to Karl E. Wiegers (2003) the software requirements levels or types are:

        Business requirements: are written to represent the high level objectives and goal of
         the organization or stakeholders who want to build the system.
        User requirements: describe the user goal which the user desires from the new
        Functional requirements: specify the software functionality that the developers must
         build into the product to enable users to accomplish their tasks.

According to Suzanne Robertson and James Robertson (2006) the software requirements
level or types are:

        High-level requirements: are written to specify the business the product is intended
         to support
        Business requirements: are written in a technologically neutral manner they specify
         what the product is to do for the work, not which technology is used to do it.
        Product's technological requirements: are written by designer who adds those
         requirements needed to make the product work in its technological environment.

According to the Rational Unified Process the software requirements level or types are:

        Stakeholder requests: are written in User language to capture all user requests.
        Features: are written to capture all feature of the system under development.
        Use cases: are written to capture functional requirements.
        Supplementary requirements: are written to capture Non-functional requirements
         (Leffingwell 1999).


Business Analysis Body of Knowledge (version 2.0). 2008. International Institute of Business
Analysis. pp 8-9.

Leffingwell, Dean & Don Widrig. 1999. Managing Software Requirements (First Edition). Addison

Robertson, James and Suzanne Robertson. 2006. Mastering the Requirements Process
(Second Edition). Addison-Wesley Professional.

Sawyer, Pete and Ian Sommerville. 1997. Requirements Engineering: A Good Practice Guide (First
Edition). Wiley.

Wiegers, Karl. 2003. Software Requirements (Second Edition). Microsoft Press

What are some of the formats used for writing use cases?

To ensure that we understand what is meant by the term format, consider the following. Most
authors and practitioners do not clearly differentiate between style and level of detail when defining
use case writing formats. Style refers to the structure of the use case or how the use case
information is presented. Level of detail refers to the state that a use case is in as it evolves from
nothing more than a use case name to a fully described or fully dressed use case. Most authors and
practitioners generically use the term format to describe some combination of these two concepts.

Alistair Cockburn (2001) defines the following types of use case writing formats in his book Writing
Effective Use Cases:

       Brief - A use case brief is typically one paragraph which summarizes
        the main success scenario and at times the main failures. It is written
        during early requirements analysis and only takes a few minutes to
       Casual - A casual use case consists of multiple paragraphs which cover
        the main success scenario and alternative success and failure
        scenarios. It is written in a narrative form without the use of
        numbered steps.
       Fully Dressed - A fully dressed use case describes the main success
        scenario, alternative scenarios, and failure scenarios in full detail. They
        typically use numbered steps to aid readability of alternative scenarios
        that branch from the main scenario and to clearly convey where a
        scenario that returns back to the main flow would continue.

Kurt Bittner and Ian Spence (2003) differentiate a bit further between style and level of detail. They
describe a Use Case Authoring Life Cycle as having 6 states (which describe the level of detail
provided). The 6 states are:

       Discovered – The initial identification of the use case. At this state it is
        just a named use case.
       Briefly Described – A single paragraph description. It is usually
        between 2 to 6 sentences in length.
       Bulleted Outline – This outline will typically cover the main success
        scenario in 5-10 steps and is focused on the users intent. The outline
        will also cover the high level steps of the most important alternative
        flows and exception flows.
       Essential Outline – This outline state is also focused on the user’s
        intent but begins to clearly show the interaction between the user and

         system. It does not go into detail about how the system internally
         accomplishes the goal.
        Detailed Description – The detailed description expands on the bulleted
         outline, describing steps in greater detail using full descriptive
         sentences. At this state, it is determined whether to write the use case
         in a narrative or conversational style.
        Fully Described –This is the final state and has a complete flow of
         events including the main success scenario, all alternative scenarios,
         and exception scenarios. The terminology used is usually defined in a
         supporting glossary. All preconditions and post-conditions have been
         identified. A fully described use case is Testable, Understandable,
         Unambiguous, Correct, Complete, and Attainable.

In addition, for the Detailed Description and Fully Described Use Cases, Bittner and Spence (2003)
identify two popular writing styles that are used:

        Conversational Form – The conversational form is written in a two
         column format. All user steps are in one column and the system
         response is documented next to the user step in the second column.
         The conversational form is often called the Dialog Form. It emphasizes
         user-system interaction and works best for use cases where only one
         actor is interacting with the system.
        Narrative Form – The narrative form is written in a single column
         format. Each step consists of a sentence or two and the use case is
         more of a narrative description or story. This style works better for use
         cases that describe the interaction between a system and multiple


Bittner, Kurt and Ian Spence. 2003. Use Case Modeling. Addison-Wesley Professional. pp 152-
Cockburn, Alistair. 2001. Writing Effective Use Cases. Addison-Wesley Professional. pp 37, 119-

What is a Vision Document?

"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

Are there scenarios where the developers will produce something different from your
requirements spec, and how would you handle this?

Yes, there are instances when the developers will produce something different than what the
requirements or functional specification documents contain. Here are some of the instances/causes
of such differences:

   1. The specifications are ambiguous or incomplete and they can be easily
      interpreted in multiple ways. In this case, the developer may have
      simply misinterpreted the ambiguous requirement in a different way
      than what was intended.
   2. The developer simply ignored the specification and/or just read it
      quickly and then developed the system from memory.
   3. The development team encountered technical limitations and the
      system cannot be developed exactly the way they were specified.

In general, the best way to handle this is to have a clear process in place to manage differences
between the specification and the developed product. This would require a strong QA team and QA
process. Here are some more detailed which address the three items above:

   1. First and foremost, ensure that the business analysis team has
      documented guidelines for creating requirements and functional
      specifications as well as processes in place for peer and management
      review of analysis artifacts to ensure they are accurate and
      unambiguous. In addition, since the QA team is responsible for
      creating test cases and scenarios based on the requirements and
      functional specifications, they should look for, find, and document as
      spec defects (bugs) those areas of the analysis artifacts which are
      ambiguous or are missing information. These defect reports can be
      used by the analysis manager to identify areas of improvement and
      also to provide performance feedback to the individual business
      systems analyst.
   2. Create a process in the development team for each developer to be
      accountable for his/her deliverables and produce code which is defect
      free. In addition, the QA team should be able to find these
      discrepancies and create defect reports (bugs) for the development
      team to fix.
   3. A process should be in place to deal with instances when the
      requirements cannot be implemented as outlined in the functional
      specifications. Have the development team review the functional
      specs and provide feedback before the coding starts. The
      development team should be a key stakeholder and reviewer of the
      analysis artifacts. The feedback can then be incorporated back into
      the analysis artifacts and, hopefully, resulting in the alignment of the
      specifications and developed product.

   What are some of the problems you are faced with when gathering requirements?

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"

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.

What is BPMN?

BPMN stands for Business Process Modeling Notation. BPMN is an industry standard that provides
businesses with the capability of visualizing and communicating their internal business processes
and their external business to business processes in a standard manner. Beyond the obvious use of
modeling business processes, BPMN has been created with the key goal of creating a bridge
between the business process modeling notation (BPMN) and IT-oriented execution languages that
will implement the modeled business processes within a business process management system. This
is done by maintaining and supporting a strict internal model that maps the rich set of graphical
objects and object attributes of BPMN to executable languages such as the Business Process
Execution Language for Webs Services (BPEL4WS) or Business Process Modeling Language (BPML)
to support immediate execution of modeled buiness processes.

Who uses the output produced by a business analyst?

-Business Management and Executives: The business analyst may create a model of current
business processes to identify areas where Business Process Improvement or Business Process Re-
Engineering might make sense.

-Business Workers: The business analyst may create a model of current business processes to
convey to business workers how their role fits into the larger business process and the other groups
that are dependent upon them for information.

-System Users of a New System: The business analyst may gather requirements and define use
cases that describe the functionality of a new system that the system users must read, understand,
and approve.

-Systems Analyst: The business analyst may gather requirements, define use cases, create process
flows, etc., to document system requirements from which systems analysts can write functional

Name and describe the different categories of UML diagrams.

There are 3 categories of UML diagrams:

Structure Diagrams: These diagrams highlight what things must be in the system being modeled.
Ex. Class diagram, Component Diagram, Composite structure diagram, deployment diagram, Object
Diagram and package diagram.

Behavior Diagrams: These diagrams highlight what must happen in the system being modeled.
Ex. Activity Diagram, State Diagram and use case diagram
Interaction Diagram: These diagrams are a subset of Behavior diagrams and highlights the flow of control
and data among the things in the system being modeled.
Ex. Communication Diagram, Interaction overview diagram,sequence diagram and timing diagrams.

What are the most relevant UML diagrams for Business Analysts?

While opinions may vary based on the role of the Business Analyst from organization to
organization, the following UML diagrams are probably the most predominantly used by Business

-Class Diagram

-Use Case Diagram

-Activity Diagram

-Sequence Diagram


To top