Business Analyst Interview Questions






Why Every Job Seeker Should Have a Personal Website, And What It Should Include

$1.95 Web.com Site Builder

 

IntellegoJobs – Current Job Opportunities, US Employment News, and Job Seeking Tips for the Bookkeeper, CPA, Programmer, Computer Hardware Engineer, Software Engineer, Computer Support Specialist, Systems Analyst, VoIP Engineer, Civil Engineer, Mechanical Engineer, High School Teacher, Middle School Teacher, Pharma Sales Rep, Sales Rep, Pharmacist, Physician Assistant, Physical Therapy Assistant, Registered Nurse, Pilot, and Truck Driver.

Business Analyst Community & Resources | Modern Analyst
RSS feeds for Business Analyst Community & Resources | Modern Analyst

Describe Artificial Intelligence and how it might impact the Business Analysis profession?
Artificial intelligence (AI) is an overarching term used to describe how computers are programmed to exhibit human-like intelligence such as problem solving and learning.  This definition of AI is broad and non-specific which is part of the reason why the scope of AI can sometimes be confusing.  As machines become increasingly capable of performing "intelligent" tasks, those tasks slowly become commonplace and as such are removed from the scope of what is generally accepted as artificial intelligence. This is known as the AI effect.  A more precise definition might be any device that takes in information from it's environment and acts on it to maximize the chance of achieving its goal.  
How might a business analyst use BPMN differently for Business Models than for Executable Models?

The origins of BPMN began in the area of executable models.  That is, it was created to be precisely interpreted by workflow engines or business process management systems in order to automatically orchestrate how information, documents, or other workflow items are directed through a system. The benefit of an executable model is that it can be changed and immediately re-executed to establish a new workflow.  At least, that’s the idea.



Once a system is developed is it reasonable to document changes with simple updates to screen mockups?

This question implies that the benefit of foregoing the creation of a more complete requirements specification document is a significant amount of time savings.  But what might we be losing in the process.

Screen mockups alone don’t clearly document requirements.  Instead, they reflect a decision made by the system designer to satisfy a particular requirement.  Often when someone views the mockup or updated system they may think the requirement is obvious when, actually, they have misinterpreted the true requirement.  


How do you prevent your application from being a confusing suite of features rather than one that meets a user's goals with ease?
Many applications are designed and completed only to result in a confusing suite of features that is difficult for the user to navigate.  So how can an analyst avoid this pitfall.  The answer is Design Thinking, also sometimes referred to as Human Centered Innovation or Human Centered Engineering.
In User Centered Design, should analysts create a separate Personas for every demographic segment?
Personas are used in User Centered Design to represent the audience that you are designing for.  Each persona is a detailed profile of a fictional character which represents a different user segment. They are created in such a way as to bring a strong sense of realism to the users they represent.  This helps create a visceral connection with the personas so that the system designer can really understand the users’ motivations for using the product.  Personas primarily focus on a user’s attitudes and behaviors. 
What are some of the primary usability heuristics that might be used in a discount heuristic evaluation?
What is a discount heuristic evaluation? It’s a method used to analyze the usability of an application or website based on a small, select group of usability principles that are intended to represent the majority of all usability guidelines.  

When talking about and researching usability principles its almost impossible to not encounter the name Jakob Nielsen.  Nielsen has outlined thousands of details usability guidelines over several decades.  However, he has also taken the time to group these and filter them down into a set of broadly applicable heuristics that he feels encompasses most of the usability guidelines you might use to evaluate your application or website.  Here is a list of 10 usability heuristics that Nielsen has outlined for a discount heuristics evaluations (paraphrased for clarity and comprehension).  
Which is better, meeting your managers expectations with consistency or giving up some consistency in order to exceed expectations?
Managers need consistent results that they can rely on.  They also need exceptional performers who can solve the tough problems.  Ideally, a manager wants someone who can do both, but that is a rare find.
What is Failure Mode and Effects Analysis and when should it be used?

Failure Mode and Effects Analysis (FMEA) describes a risk analysis method for identifying and documenting all of the possible ways that a system or process can fail, the likelihood of the failure occurring, and the effects that such a failure would have on customers or the business.  It is often used as part of Six Sigma and other methodologies.



How is the 100-point method used to prioritize requirements?
The 100-point method is a prioritization method that can be used to prioritize items in a group environment. Each person within the group is given 100 points which they can distribute as votes across the available items.  The votes do not need to be distributed equally; rather a weighted distribution can be used to reflect the higher priority that some items warrant.
What are the benefits of Visual Models?
Visual models communicate much larger amounts of information in a comparatively short period of time versus written communication and documentation.  As they say, a picture is worth a thousand words.  The organization, structure, and order of information in visual models can also help an analyst ensure completeness through easier identification of gaps and missing information.
What do you do to increase your value as an analyst?

Most analysis managers and recruiters who are serious about hiring quality business analysts or systems analysts want to know that you are driven and interested in constantly increasing your knowledge and skills.

You want to be able to demonstrate to them that, outside of the employer required activities, you take the initiative to continue learning.


What is The Agile Extension to the BABOK® Guide?
The Agile Extension to the BABOK® Guide was collaboratively developed by the Agile Alliance and IIBA.  It builds on the content of the BABOK® Guide as it was first developed by the IIBA and it further extends it to incorporate Agile Development principles.
What is DevOps and how does it relate to software development?
As the name suggests, DevOps represents a union of two different sub-disciplines – Development and Operations. Most analysts are highly familiar with the Development portion of DevOps.  This is the traditional software development lifecycle used to create or make major changes to software applications.  It includes a vast network of people who assist in developing a product including product managers, business analysts, software developers, quality assurance engineers, and others. From the DevOps perspective, this stage end just prior to software release/deployment.

The Operations portion of DevOps tend to be less familiar to analysts. In years past Development and Operations operated almost entirely in their own silos.  The Ops team is made up of system and network engineers, DBAs, and others that build, manage, and monitor the IT infrastructure required to ensure the software can be properly deployed and supported.  They receive the tested software builds  and manage the release and deployment of the software onto the IT network while monitoring network stability. 

What is Infrastructure as a Service?
Infrastructure as a Service describes a model where organizations outsource hardware requirements such as database storage, networking components, servers, and database/server virtualization to an outside vendor . The organization will often pay on a per-use basis meaning the vendor charges based on actual storage space used in conjunction with data transmission rates.   The vendor provides the equipment and is responsible for its maintenance which typically offers dynamic scalability as the purchasing organization’s hardware requirements increase.  


Which is better: Waterfall or Spiral development?
The choice of SDLC methodology for a project largely depends on: (1) the type of project, and (2) the environment or organizational culture within the project takes place.  With that said, a Spiral method is superior for the vast majority of projects today, especially those which include the development of customer facing products.
What are some steps the Business Analyst can take to avoid vague, incomplete or ambiguous requirements?
Stakeholders often interpret requirements in a variety of different ways. Whether its from the natural ambiguity of conversational language or due to missing information, ambiguous and incomplete requirements can lead to project delays and budget overruns. But by keeping a few key considerations in mind the Business Analyst can dramatically improve the quality of product requirements.
What is a business entity model?

A business entity model is a logical model that documents the entities, or things, that a business or business process uses and interacts with in order to accomplish its business activities and goals. In addition to documenting entities, a business entity model may capture the attributes of an entity, relationships between entities, and cardinality information. Many business entity models are created in the form of a UML class diagram. However, it is important to note that business entity models document the logical structure of a business domain, not the physical structure.


What techniques have you used to elicit business requirements?

There are a number of methods used for eliciting and discovering requirements.  These methods can be categorized into two main categories: Collaborative Interaction and Restricted Interaction.


What is DMN and how is it used to support BPMN?
BPMN is used to define business processes as a sequence of activities. Gateways are used to show branching of different process paths.  For many years, analysts would clumsily model decision logic directly in business process models in an attempt to fully define process branching logic. This made process models messy.

DMN or Decision Modeling Notation was published in 2015 by the Object Management Group.  It's a graphical language for specifying business decisions.  DMNs primary purpose is to give analysts a tool for separating the business decision logic from the business process. 


What are the 5 basic categories of elements in BPMN?
BPMN is a robust notation designed to balance two competing needs.  The notation should be simple enough for all stakeholders to understand, yet robust enough to handle complex orchestration of events to a level of detail which can be made executable.  Not an easy thing to do.  However, by organizing elements into distinct categories, a sizable notation can be more easily understood.
What is the Cone of Uncertainty?
The Cone of Uncertainty is a term often used in project management to describe the phenomenon by which project unknowns decrease over time.  As the project proceeds and more research and development is completed the amount of uncertainty decreases, eventually approaching zero. Project unknowns, or uncertainty, largely correlate to variances in project estimates.  Plotting these variances over time creates a cone or funnel shape (variance percentages shown are only examples, values may vary).
What types of actions can help the business analyst avoid Analysis Paralysis?
Analysis Paralysis is the dreaded black hole of projects. So, how do you recognize that you might be in Analysis Paralysis.  Here are a few symptoms that might clue you in.
How can the acronym INVEST assist the analyst during the development of user stories?

INVEST is an acronym that can help a Product Manager or Developer create quality user stories.  INVEST stands for Independent, Negotiable, Valuable, Estimable, Sized-Appropriately, Testable.  

I - Independent:  The user story should be self-contained if at all possible to avoid dependencies on other user stories.  Since one characteristic of agile methodologies is the ability to be flexible and re-prioritize what’s important, independent user stories allow for flexibility during iteration planning. If you do find that your user stories are dependent upon one another, you may be able to combine smaller user stories together that have a dependency between one another.  Similarly, you can divide larger dependent user stories into smaller stories such that one of the new smaller stories contains and isolates the overlapping portion of the larger stories.

N - Negotiable:  User stories can always be changed or rewritten up until the point of coding.  This further supports the flexibility associated with agile methodologies.   Since requirements often evolve or rise and fall in priority, user stories should be able to adapt with the changing requirements.

V - Valuable:  A user story represents a goal of an end user or purchaser and should deliver functionality that is deemed valuable.  This means that specifics of the technical design are not something that you would document as user stories.  However, some technical requirements have a component which is valuable to a user.  A user might expect pages to load within 2 seconds.  The user story would specify the need for 2 second page load times while the specifics of the physical implementation of this would be left out.

E - Estimable:  You should always be able to estimate the size of a user story.  Sometimes, developers won’t have the experience required to size a particular situation or needed for a user story.  When this occurs the user story can be split into two separate user stories.  The first is a “spike” which is where developers do some quick research to determine the feasibility of something or get a better idea of how long it might take to implement the particular feature.  The spike is always time-boxed, meaning it is limited to a pre-defined amount of time.  The “spike” user story might be named “Research (something) to determine…)”, while the second user story is where the functionality will actually be delivered.  These two user stories should be scheduled into two separate iterations such than the spike can be completed and the feasibility of the second user story assessed before coding begins.  This gives the team time to react if problems arise from the spike.

S - Sized Appropriately:  User stories shouldn’t be too big or too small.  So how do you decide what size is right.  First, any user story that can’t be completed by a developer within a single iteration (or by a developer pair when paired programming is being used) is too big.  The user story should be subdivided into two or more smaller stories.  Similarly, there is no need to make user stories too granular just for the sake of decomposing features.  If features group well together and complement each other then it makes sense to make a single user story.  For instance, “As a job seeker I want to be able to add, delete, and edit a job skill on my electronic resume so that I can maintain an accurate listing of my skills.”  There is no reason to split “add, delete, and edit” into multiple user stories unless one of them creates a significant amount of work that would make the user story too large for the iteration.

T - Testable:  User stories must be testable in order to ensure that development is complete and has been done correctly.  So when are user stories not-testable?  Often, if the analyst isn’t carful, non-functionality requirements are written in a manner which is un-testable.  Consider the example, “pages should always load quickly”.  There are two un-testable components of this statement; “always” and “quickly”.  A testable statement would be “pages should load within 1.5 seconds 97% of the time”.

--
Chris Adams
LinkedIn Profile


What is the different between a business policy and a business rule?

Business Rules and Policies tend to be complicated for analysts to untangle because they are so closely related.  Policies are typically more general assertions or guidance about how an organization is intended to operate, while business rules describe the specific execution of the business policy. 

The BABOK describes a policy as “a non-actionable directive that supports a business goal', and a business rule as 'a specific, actionable, testable directive that is under the control of the business and supports a business policy'

The Business Rules Group goes further in their definition of business rules describing it as an atomic statement that defines or constrains some aspect of the business.  They categorize business rules as one of three sub-classifications; structural assertion, action assertion, or derivation.  The definitions of these get quite detailed and while knowing them, along with understanding things like fact models, may help elaborate one’s understanding of a business rule, at a summary level business rules are best understood by a higher level definition (like the IIBA’s) and a few examples.

Additionally, policies, being more general, typically change less often than business rules which are specific implementations of policies.

To restate, a policy is:

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


A business rules is:

  • Actionable
  • Specific
  • Testable
  • Supports a policy


Examples of policies for a car rental company:

  • Maintenance must be performed in a manner which maximizes the life and value of the car
  • Renters must have valid insurance


Example of business rules that may support these policies:

  • All vehicles are required to have a 58 point inspection after every 3 months of use before re-renting.
  • A car which has accumulated more than 3500 miles must have its oil changed before re-renting.
  • Tires with less than 1/16th inch of tread must be replaced.
  • Renters in the state of Texas must have insurance covering $100,000 of liability or more.
  • Renters in the state of Arizona must have insurance covering $50,000 of liability or more.

Notice that each of the business rules are written as a level which is actionable, specific, and testable.


--
Chris Adams
LinkedIn Profile


What is the business case for using personas?
Many organizations that lack experience with personas don't fully understand the value of them.  Furthermore, personas can be difficult for the inexperience team member to properly create.  

Systems Analyst Jobs
Listed by State – Updated Daily

Alabama Alaska Arizona
Arkansas California Colorado
Connecticut Delaware Florida
Georgia Hawaii Idaho
Illinois Indiana Iowa
Kansas Kentucky Louisiana
Maine Maryland Massachusetts
Michigan Minnesota Mississippi
Missouri Montana Nebraska
Nevada New Hampshire New Jersey
New Mexico New York North Carolina
North Dakota Ohio Oklahoma
Oregon Pennsylvania Rhode Island
South Carolina South Dakota Tennessee
Texas Utah Vermont
Virginia Washington West Virginia
Wisconsin Wyoming

Powered by FirstRSS Plugin

Leave a Reply

Your email address will not be published. Required fields are marked *