ANSWERS TO BUSINESS ANALYST QUESTIONS

1) …………………

2) (1) A Business analyst should be a good communicator.

(2) A BA should be a subject matter expert in his requisite domain.

(3) A BA should be a successful negotiator as at times when the resources are

not in fine picture or development is not getting anywhere, a panic
environment is never the inevitable result. BA should be able to make the
client understand the hurdles and suggest some feasible and appropriate
solutions/business improvement practices to the client

3): The Project Manager is responsible for ensuring that the product is
delivered to the customer on time and within budget.

The Business Analyst is responsible for ensuring that the product is built
according to the requirements and is built correctly.

SME A Subject Matter Expert (SME) is a person who is an expert in a

particular area. In software engineering environments, the term is used to
describe professionals with expertise in the field of application but without
technical project knowledge.

4) A use case is used to describe what a system does. A use case is a methodology
used in system analysis to identify, clarify, and organize system
requirements. The use case is made up of a set of possible sequences of
interactions between systems and users in a particular environment and
related to a particular goal. It consists of a group of elements (for example,
classes and interfaces) that can be used together in a way that will have an
effect larger than the sum of the separate elements combined. The use case
 should contain all system activities that have significance to the users. A use
case can be thought of as a collection of possible scenarios related to a
particular goal, indeed, the use case and goal are sometimes considered to be
synonymous.

A use case (or set of use cases) has these characteristics:

• Organizes functional requirements

• Models the goals of system/actor (user) interactions
• Records paths (called scenarios) from trigger events to goals
• Describes one main flow of events (also called a basic course of action),
and possibly other ones, called exceptional flows of events (also called
alternate courses of action)
• Is multi-level, so that one use case can use the functionality of another
one.

Use cases can be employed during several stages of software development,

such as planning system requirements, validating design, testing software,
and creating an outline for online help and user manuals.

5): Actor is something or someone that exists outside the system. Actors are
things outside the system but interact with it. They may receive or deliver
information to the system or do both. An actor is not the person that
interacts with the system but the role that he or she plays. An actor is
someone or something outside the system that either acts on the system – a
primary actor – or is acted on by the system – a secondary actor. An actor
may be a person, a device, another system or sub-system, or time. Actors
represent the different roles that something outside has in its relationship
with the system whose functional requirements are being specified. An
individual in the real world can be represented by several actors if they have
several different roles and goals in regards to a system. These interact with
system and do some action on that.
 6). Business use cases focus on business operations. They represent specific
workflows in the business that achieves business goals. Business processes
may involve both manual and automated processes and may take place over
an extended period of time.

System use cases focus on the software system to be designed. How do actors
interact with the software system? The flow of events that we write in a
system use-case specification should be sufficiently detailed to be used as the
starting point for writing system test scripts.

Business use cases are often written in a white-box form. They describe the
interactions between people and departments in the organization being
modeled. Business use cases are used to describe how the organization works
today in the "as is" business model. What new roles and departments do we
need to create to provide more value or eliminate business problems? What
roles and departments need to disappear?

System use cases are almost always written in a black-box form. They
describe how actors external to the software system interact with the system
being designed. System use cases elaborate the system requirements. The
purpose of the system use-case model is to document requirements from a
stake holder’s perspective, not to design how to satisfy the requirements.

7): Few minutes ………..

8): Exception flow is the activity in case of the exception thrown. They are the
flow of events which will happen in case of the error.
Alternate flows are the alternative actions that can be performed. For
 example in the login page the alternative flow will be checking the existence
of the user name entered.

9): An include relationship is to be used when it must be possible to reuse the

extracted behavior in different use cases—that is, when the extracted
behavior has to be independent of where it is used. Moreover, the base use
case is not complete without the extracted behavior; it is therefore dependent
on the existence of the included use case.

The argument for the extend relationship is the opposite: The base use case is
complete without the extension use case; it must therefore be defined
independently of the existence of the extension use case. Moreover, the
extension use case describes an addition to another use case; it is therefore
dependent on that use case (the base use case).

10): Logical relationship link between actors. A specialized actor can relate
himself with any use case related with the base use case. Then it can be
related with other use cases that are not related with the base use case.
Generalization is a relationship between two use cases or two actors. Where
A is a generalization of B, it means A describes more general behavior and B
a more specific version of that behavior. Example of use case generalization :
An example of this would be "make payment" generalizing "make payment
by check", "make payment by credit card", "make payment by gift
certificate" etc... Each of these specializations accomplishes the actions of
"make payment".

11): Functional requirements may be calculations, technical details, data

manipulation and processing and other specific functionality that show
how a use case is to be fulfilled. These are mostly generated after a use case
is built. Use cases are useful in capturing and communicating functional
requirements, and as such they play a primary role in product definition.
Example of functional requirement:
 From ATM use case is: "get cash", "get balance”. The functional
requirements describe the system's functionality like:
The system should grant access to the user after he provides username and
password; the system should provide access to the following pre-defined
reports. Often they are listed under different project specific groups like
user access, reporting, user interface, etc.

Examples of non functional requirements are Usability, reliability,

interoperability, Scalability, Security, cost etc. Examples of non-functional
requirements include legal and regulatory requirements, application
standards, and quality attributes of the system that relates directly to that
particular use case

12): Functional Requirements are documented in the Software Requirement

Specification document / Use Case Document. Non Functional
requirements are listed in the SRS document.

13): Use Cases are another way to document functional requirements

supplemented with a Non functional document.

14): Use cases should be written from the user point of view. How should the
system function when using it? So "behind the scenes" specifics like what
is stored in the data base or how the system will validate the information,
are not included.. That would go in technical specifications. The people
signing off on use cases are typically business users and the people using
the use cases are typically software developers.

15): I often work through issues of policies, procedures and processes with my
customers, and it was interesting to hear the comments on the relationship
between policies and rules. If the policies are well-written, the rules pretty
much write themselves, and by spending more time on the policy behind
 the rules, you end up with a better set of rules. Business rules are
requirements that represent constraints on behaviors, rather than
behaviors themselves. Examples:
All transactions are in U.S. Dollars.
Valid operator’s license is required in order to rent a car.
Late-fee is assessed for enrollment after the second week of the semester

16): Describe the main interactions with the system. Focus on the priority use
cases and on the basic course. These priority use cases are sequences of
events and interactions that contain fundamental information about the
system functions. Consider each primary function of the system to:
• Document decisions made about the actions and sequence, with a
granularity (detailed, high level) depending on the nature of the action
(e.g., complexity) and stage of life cycle,
• provide an effective communication vehicle for requirements,
• serve as a set of instructions for the implementation.

Focus on the main interactions in the system. Start with an external user's
interactions with the system (e.g., for a bank, start with deposit cash,
withdraw cash). Create a narrative that describes what happens as the
system responds to the event.

17): Step by step bulleted list.

18): Actors are characterized not by the identity of the user or other, but rather
by the role played by the actor. One person can be several different actors
in different roles.
One actor can be played (at different times) by several different persons.
An entire committee could be one actor. An actor need not be a living
thing; it could be another subsystem. Actors are not part of the system in
question; they supply input to and receive output from, to the system. In
 other words, actors collectively define the environment of the system.
Actors may represent roles played by human users, external hardware, or
other subjects. Note that an actor does not necessarily represent a specific
physical entity but merely a particular facet (i.e., “role”) of some entity that
is relevant to the specification of its associated use cases. Thus, a single
physical instance may play the role of several different actors and,
conversely, a given actor may be played by multiple different instances.

19): The best way to find use cases is to consider what each actor requires of the
system. For each actor, human or not, ask:

• What are the goals that the actor will attempt to accomplish with the
system?
• What are the primary tasks that the actor wants the system to perform?
• Will the actor create, store, change, remove, or read data in the system?
• Will the actor need to inform the system about sudden external changes?
• Does the actor need to be informed about certain occurrences, such as
unavailability of a network resource, in the system?
• Will the actor perform a system startup or shutdown?

Understanding how the target organization works and how this

information system might be incorporated into existing operations gives
an idea of system's surroundings. That information may reveal other use
case candidates.

Give a unique name and brief description that clearly describes the goals
for each use case. If the candidate use case does not have goals, ask
yourself why it exists, and then either identify a goal or eliminate the use
case. The relationship between actors and use cases should be captured,
or documented. There are several ways to do this. If you are using a use-
case model on the project, you can create use-case diagrams to show
how actors and use cases relate to each other.
20): On an average 4 – 9 steps are sufficient for a good use case.

21): Identify system boundaries.

 Identify actors.
 Recall: an actor is an entity playing a particular role with respect to
the system.
 Identify use cases themselves.
 Every use case has at least one actor.
 A specific actor initiates the use case.
 The same actor may participate in multiple use cases, as initiator in
some and not in others and create the description including flow of
events.
 Identify clarifying scenarios where helpful.
 Provide additional information.
 Write in the active voice.
 Pair responses with the events that invoke them.
 Identify domain objects that clearly are part of the application context
(such as “catalog”,” inventory”, “fleet” (of automobiles).

22): Evaluating the use-case model with respect to some frame of reference,
such as business needs, business domain, and so on. However, use cases will
never really be complete until well after the project is over because the
author’s and end users' understanding -- of the system will be refined and
will evolve over time. The need is required to focus on whether each use
case is sufficiently detailed for development to proceed. The following need
to be taken into consideration for a complete use case:
• Use-case specifications. The basic flow and the alternative flows are clear
and are understandable by the development and test teams, and have
received approval from the end users.
• Business use-case specifications. The specifications are very clear on when
the use case is invoked within the business process. Also, the team has
verified that the outcomes are of value to the steps in the business process.
In other words, the team has verified the flow of events in the use case
against the business processes.
• Business entities. All the business entities that will be manipulated by the
use case have been detailed, and their attributes and sub categorization
have been defined. Subclasses are often used to evaluate the completeness
of the flow of events and the business rules. For example, booking would
be an entity for booking for a hotel room, but there are different types of
bookings: advance; immediate; priority; and so on. These different types
should be treated in alternate flows of events, and the business rules must
also consider them, by computing room charges under different booking
types, for example.
• Business rules. The business rules required to support the use case are
clear. For example, if there is a use case to make a room booking, there
must also be computation rules to determine the room charges.
• User experience storyboard. The screens required for user interactions
defined by the use case are identified, including fields and navigation
paths.
• Supplementary specifications. It is clear how supplementary
specifications affect the use-case flow of events. For example, if the use
case requires user identification, it must be clear when the identification
is requested and what authorization is required. For an audit trail, it has
to be clear what needs to be tracked and under what conditions.
23): Use case: Use case is prepared by BA in the Functional Requirement
Specification (FRS) which is nothing but steps which are given by the
customer.

Test Case: It is prepared by the Test Engineer based on the use cases from
FRS to check the functionality of an application thoroughly.

24): Not sure about this answer…..

25): All stakeholders in a project-developers, end users, software managers,

customer managers are the audience in use cases.

26) ……………..

27): The question should be open ended for chances exist for obtaining some
information or possibility which a person would have never thought. The
question should not give an idea about the supposed answer. (Not sure of
this).

28): BA writes a Use Case. Project Manager and a BA review it.

29): With the following check list (Though am not sure of the answer)

Is the use case a standalone, discrete task?

Is the goal, or measurable value, of the use case clear?
Is it clear which actor(s) benefit from the use case?
Is the use case written at the essential level, rather than as a specific
scenario?
Is the use case free of design and implementation details?
Are all anticipated alternative courses documented?
Are all known exception conditions documented?
Are there any common action sequences that could be split into separate
use cases?
 Is the dialog sequence for each course clearly written, unambiguous, and
complete?
Is every actor and step in the use case pertinent to performing that task?
Is each course defined in the use case feasible?
Is each course defined in the use case verifiable?
Do the pre- and post-conditions properly frame the use case?

30): One of the things that I try to do always while facilitating use case sessions is
that I make sure all the participants get the right definition of consensus. I
would never say that "everyone must agree on everything" as it would
lead to long discussions rather I say "there is nothing in this that we can't
live with" so that way I have a better chance of getting things done
quickly. As a facilitator my mission has always been is to get the group
through the agenda to the desired results in as an effective and productive
of a manner as possible. I have always made a point in the capacity of a
leader of the meeting to exert subtle yet firm control over its course.
Normally the comments I get from each one present in the JAD sessions is
that I am very much apt at getting the group through the entire schedule
on time. I was commented in being an attentive listener and a good
“Catalyst” who is always neutral, avoids making judgmental comments
and very much capable of directing the discussions in a direction which
allows the participants to discover the appropriate answers for themselves

31): Business use-case model, Business entities and domain model , Business
rules, User experience model and story boards , Supplementary
specifications . (Not sure)

32: The first stage of requirements gathering that I normally do is to design and
establish a rough scope of the project, a process often called simply scoping.
Occasionally it’s done as a part of the budgeting process. The objective is to
 provide a general framework for how much activity will be necessary to
create the solution without delving into the specific algorithms, formulas, and
techniques which must be used. Techniques that I normally use to gather and
document requirements include UML, process flows, use cases, interview
skills, workshop facilitation, and investigation of current state (existing
systems and/or processes). This is done to be able to analyze, assemble and
evaluate data and to be able to make appropriate and well reasoned
recommendations and decisions to support business stakeholders and the
project team.
Gathering the requirement allows avoiding ambiguity regarding the
functionality and objectives of certain requirements, incomplete information
and misunderstanding of the needs of the users and conflicting goals by
different teams. Avoiding unstable requirements or new requirements being
added during the development phase also are a part of this.

33)…

34)…

35): First week in this case is always advisable to do a diligent amount of work
on expectations, existing process, and time lines with the constraints
surrounding. Depending on the project timelines, complexity and volume of
the project I would present the recommendations for tools to be used and
the estimated budget allocation required and also document the
comparison of productivity and flexibility with and without tools used. This
should help and motivate the project sponsors to take a call on going for
tools.

36): Check the organizational hierarchy at the client side; it happens many
times, without permission from the department head, end user doesn’t
entertain any analyst. Trying talking to them in a friendly way and making
them realize that whatever they are doing is worth. This is all your
 personal traits how you get along with them and make them speak. Initially
you'll find them difficult to deal with, praise them for what they are doing,
and make them feel that they are doing very important activity. This will
definitely help you in sharing good relationship with clients

37): At a project's beginning, the use case must be a complete description of the
system's behavior, yet must remain simple enough for customers to grasp. It
must also describe the problem domain, the systems requirements, and
customer expectations correctly and completely. During the design and
analysis phases, the use case requirements model becomes the basis for the
identification of analysis and design classes and subsystems. These are
created through a process of allocating behaviors to the objects derived from
the use case model. During the implementation phase, developers use the
design classes and subsystems as the basis for developing the system's code,
data, and computational interactions. Finally, during the testing phases, the
use case requirements model forms the basis for test cases verifying that the
system solution meets the original business needs.

38): Yes, it comes under the category of Data Maintenance use case. Writing one
per entity is repetitive. Normally it is easier to write such use cases
generically so that they can be applied to multiple entities.

39): Yes (not sure of this answer)

40): No, Use cases should be written from the user point of view. How should
the system function when using it? So don't include "behind the scenes"
specifics like what is stored in the data base or how the system will validate
the information. That would go in tech specs. The people signing off on use
cases are typically business users and the people using the use cases are
typically software developers.
41): No, I was working as a Business Analyst.

42): The use cases aren’t written clearly that the customer can understand them.
 The system boundary is undefined or inconsistent.
 The use cases are written from the system’s (not the actors’) point of
view.
 The use cases are written from the system’s (not the actors’) point of
view.
 The actor names are inconsistent across use cases.
 The use cases don’t correctly separate actors based on functional
entitlement.
 The use-case specifications are too long or confusing.
 Writing Functional Requirements instead of usage scenario text.
 Avoiding explicit names for your Boundary Objects.
 Writing using a perspective other than the user's, or in passive voice.
 Describing only user interactions; ignoring system responses.
 Omitting text for alternative courses of action.
 Focusing on something besides what's "inside" a given use case, such
as how you get there (precondition) or what happens afterward (post
condition).
 Spending a month trying to decide whether to use "uses" or "extends

43: PROS: Use cases provide some very clear benefits to the Analysis Phase.
 One important benefit of use case driven analysis is that it helps
manage complexity, since it focuses on one specific usage aspect
at a time.
 Use cases start from the very simple viewpoint that a system is
built first and foremost for its users.
  Another benefit of use cases is that they provide basic
groundwork for the requirements document, user manual and
test cases.
 Use cases also encourage designers to envision outcomes before
attempting to specify outcomes, and thereby they help to make
requirements more proactive in system development.

CONS: There are some drawbacks and risks associated with use cases.
 Use cases eschew description of user motivations and experiences,
and do not address usefulness and usability.
 Although quality issues are often crucial to the success of a
software system, there is no systematic way to handle
nonfunctional requirements with use cases.
 Another drawback exists when trying to document interactions
between requirements. Use cases look at each requirement
separately and do not document the interaction between the
requirements.
 Many developers often avoid use cases because of the time
required to prepare a complete set for an application.
 Depending on the size of the system in question, it can take a
significant amount of time to complete a set of use cases.
 Others scorn the “boredom” of use cases, with their unnamed
actors and dry, generalized events.
 Finally use cases are criticized for not capturing all the off the wall
mishaps and events that can occur.

44): A use case describes a task the user must be able to perform with a
software product. Use cases shift requirements discussions from the
traditional focus on features and functionality to the perspective of what
the user will do with the product. This change in perspective is more
 important than whether you draw elaborate use case models. The use case
approach helps you avoid missing essential functional requirements or
implementing cool functionality that no one uses because it isn't directly
related to specific tasks. They can also help you identify exception
conditions the system must handle, which sometimes are overlooked in the
focus on expected system behaviors. I have found use cases valuable for
deriving conceptual system test cases very early in the development
process. The test cases almost immediately revealed errors in my functional
requirements and analysis models. User representatives can generally
describe their business processes and itemize the tasks a new application
must let them perform. Skillful facilitation keeps elicitation workshops
focused on user tasks, rather than drifting into discussions of functional
requirements or detailed user interface design.

45):

46):

47):

48): Use should be readable and should be written in clear cut steps and not in
one go. The writer should know when to stop as one needs to know what is
sufficient to write a use case as use case is about describing what a system
does and not how a system works. There shouldn’t be any mismatched
goals and description. Too long sentences and complex sentences don’t
make good use case. Lack of an actor, misuse of tenses and verbs also
contribute to a bad use case.

For example in the following use case there are unnecessary details in the
first part:

"Promote to Distribution" use case:

1. The use case starts when a user clicks on the "Promote to Distribution"
button to bring up the Promotion screen.
2. The user selects a state from the state drop-down combo-box.
3. The system finds all eligible magazine issues for wholesalers in the selected
state and displays them in a list below the state combo-box.
4. The user selects the magazine issues to promote by using CTRL + click to
select multiple rows in the list.
5. The user clicks on the Promote button on the bottom of the screen.
6. The system promotes the selected issues and displays a dialog box showing a
useful message that the magazine issues have been promoted.

Here is a better alternative:

1. The user signals to the system to start the "Promote to Distribution" use-case.
2. The system displays filtering criteria to the user (states of the US and
provinces in Canada)
3. The user selects one or more choices from the filtering criteria (one or more
states / provinces) and signals the system to promote all eligible magazine
issues for all wholesalers matching the filtering criteria.
4. The system validates the user's selections.
5. The system promotes all eligible magazines for wholesalers matching the
filtering criteria.
6. The system displays to the user the results of the promotion (success or failure
for promotion of each magazine issue and reason for failure).

OR:

Wrong:

1. Administrator fills in his user name

2. Administrator fills in his telephone number
3. Administrator fills in his email

Correct:

Administrator fills in his user name, telephone number and

email