BA Role

 Elicit requirements using interviews, document analysis, requirements workshops,

surveys, site visits, business process descriptions, use cases, scenarios, business
analysis, task and workflow analysis.

 Critically evaluate information gathered from multiple sources, reconcile

conflicts, decompose high-level information into details, abstract up from low-
level information to a general understanding, and distinguish user requests from
the underlying true needs.

 Proactively communicate and collaborate with external and internal customers to

analyze information needs and functional requirements and deliver the following
artifacts as needed: (Functional requirements (Business Requirements Document),
iii. Use Cases, GUI, Screen and Interface designs)

 Utilize your experience in using enterprise-wide requirements definition and

management systems and methodologies required.

 Successfully engage in multiple initiatives simultaneously

 Work independently with users to define concepts and under direction of project
managers

 Drive and challenge business units on their assumptions of how they will
successfully execute their plans

 Strong analytical and product management skills required, including a thorough

understanding of how to interpret customer business needs and translate them into
application and operational requirements.

 Excellent verbal and written communication skills and the ability to interact
professionally with a diverse group, executives, managers, and subject matter
experts.

 Serves as the conduit between the customer community (internal and external
customers) and the software development team through which requirements flow.

 Develop requirements specifications according to standard templates, using

natural language.

 Collaborate with developers and subject matter experts to establish the technical
vision and analyze tradeoffs between usability and performance needs.

 Be the liaison between the business units, technology teams an

Read more: http://practicalanalyst.com/2007/02/14/business-analyst-job-
description/#ixzz1K2Ndn2lQ

Business Analyst as an IT Role

Today, the BA role seems to be joined at the hip with IT. My notion of why this is, is that IT sees
the most immediate and conspicuous value-add. IT really feels the pain when business need is
not communicated clearly. Numerous studies show that requirement inaccuracies that are
corrected early on in the project can cost a mere fraction of what it costs in time and budget to
correct them later [1, 2, 3].

Sure, business folk hate the bugs, delays and budget bumps, but they typically aren’t missing
their tee times while IT delivery folks crank out 16 hour days and weekends to make up for
misunderstanding what the business didn’t articulate very clearly in the first place. Business
analysts provide IT with a clearer understanding of what the business needs, and can alleviate a
great deal of that pain.

Through thorough elicitation and solid documentation, good BA can help the business trust their
“techie” siblings to understand the business need and implement the right use of technology to
meet it.

Business Analyst as a Business Role

What happens when business folks get a bit too comfortable in their solutions hats? The most
trying projects are those where the business plays the role of solutions architect, and the BA
plays the role of “waiter”.

Too often IT is forced to implement a predetermined technology solution that is just not the best
choice. Despite the best of intentions, business folks have a tendency to mistake symptoms for
causes, and to want to prescribe solutions instead of simply stating needs and objectives. These
projects can be the most disastrous.

In cases like this, the BA role is virtually reduced to that of a waiter sent to take orders and carry
them back to the IT kitchen. This, aside from being frustrating, nullifies much of the value that a
BA can provide to the business. What the business may not realize is that they don’t need a
waiter; they need a trusted advisor.

Business stakeholders sometimes fail to realize (in part due to the BA or Project Management
Organization’s failure to articulate) that the great value of a BA is not just in the ability to crank
out documents translating business-speak to tech-speak, but to help business stakeholders
through the processes of identifying and prioritizing true (not necessarily perceived) business
need, identifying SMART objectives for a solution, and helping them arrive at the right solution
– which, notably, may or may not be IT-related.
I think one of our biggest sells as business analysts is to the business ownership. The higher up
the corporate food-chain a BA can find a listening ear, the better. BA’s should primarily be
experts on the business environment, and secondarily the IT environment (which is still very
important inasmuch as it is a vehicle through which many of today’s business process solutions
are addressed). This is not to say that the BA “knows best”, but that the BA will ensure that the
proper processes for discovery, prioritization, and decision-making are followed, giving the
business the best possible opportunity to succeed.

Read more: http://practicalanalyst.com/2007/07/23/finding-a-home-for-business-

analysts/#ixzz1K2OXzidhThe Rise of the Business Analyst — Again

Articles

When I got into the IT business years ago, I thought the business analyst was the most pivotal
person in the whole profession. That was the person who was the bridge between business and
technology, the one who could see and understand both sides and whose goal was to apply
technology to support business initiatives that would help the company grow revenue or shrink
operating costs.

Over the last 20 years, we lost sight of that, as the technology focus began to shift away from IT
and toward the business users. The PC dethroned the mainframe and minicomputer. Local-area
networks enabled whole companies to run on PCs and servers. The chips powering PCs got more
and more powerful, allowing the software to get more full-featured.

Then the Internet hit the big time, and for the past 10 years, we’ve been exploring the many
things you can do when you combine people and computers in real-time networks via the Web.
But by now, the newness has worn off, and we are back to thinking about that old concern of
how to use this stuff to make money. That’s where the business analyst comes in once more.

A lot of IT functions have been outsourced, including data center operations, programming and
the help desk. The one function that doesn’t seem to lend itself to outsourcing is business
analysis. To effectively look out for their best interests, companies have to analyze their specific
challenges and find unique responses to them. If they play the “me too” game of simply doing
what everyone else is doing, they will reap no real competitive advantage. Sure, a company can
bring in consultants to help and to train its analysts, but it cannot get consistently good results if
it outsources the whole analysis function. Why? Because an analyst needs to really understand
the company he is working with, and the best way to do that is to live there and be part of it.

I often hear that companies have not developed their business analysis capabilities because they
believe that analysts use soft skills that anyone can exercise without much training. I beg to
differ.

I was once asked to start up and run a group of business analysts for a company that already had
a 100-person IT department. As part of that job, I had to define the specific skills my analysts
should have and then put in place a training and career advancement program that would develop
those skills. This gave me cause to think carefully about the skills that analysts need and how to
develop them.

Here’s what I found:

 Business analysts must be able to facilitate joint application-design sessions that involve groups
composed of both business and technical people. They need to actively include everyone in the
sessions and encourage people to contribute their ideas.

 They need to do process mapping. This is often a very good way to focus the conversations of a
group in a design session and provide a big-picture context in which to place people’s ideas.

 They need to apply data modeling to organize the data flowing through the business processes
they are designing. By this I mean logical data modeling (not the creation of physical data
models in fourth normal form).

Once analysts have facilitated group design sessions, created process flow diagrams and
organized the relevant data into a logical data model, they must pull this all together and create
the user interface for the system that will drive the activities in the process flow and handle the
data in the data model. This is where analysis turns into synthesis, and where the design of any
new system emerges. And as ifall that weren’t enough, good analysts must also be skilled at
system testing, user training and even project management.

Soft skills? These are some of the hardest skills to master in the whole IT profession. And
companies need good business analysts now more than ever if they are going to thrive in our
fast-changing global economy.

Six Sigma and the Business Analyst

Articles

I began my career at Cap Gemini Ernst & Young where doing business analysis and
implementing large scale systems was my job. At that time, I just thought everyone intrinsically
knew you had to understand the business and all the requirements before you begin designing a
system (whether custom built or off the shelf). When I got out in the real world that”s when I
realized corporate America had not yet fully embraced the idea of conducting business analysis
internally and the profession itself was actually in its infancy. I was ever so grateful for the
appearance of the International Institute of Business Analysis (IIBA) in the 2003 / 2004
timeframe to start to bring a level of legitimacy to a profession that was deeply needed in IT
shops across the country.

In some ways, I feel I have grown along side the profession. Very early in my career the IIBA
did not exist, then mid-way in my career it came to fruition, and now as they continue to drive
new, and different conversations about the role of business analysis in the modern corporation; I
find myself in the same position – attempting to provide leadership in an ever evolving and still
much needed field.
I give you this background to give you context to my ah-ha moment as I sat in yellow belt
training. To me, it is a rigorous and well tested process for conducting business analysis whether
the solution is technology or not.

As we walked through the methodology it sounded curiously familiar to the Enterprise Analysis
chapter in the Business Analysis Body of Knowledge (BA BOK). The interesting part is that
regardless of what you call the activities, every organization should be doing them and have
people proficient in doing them.

The six sigma continuous improvement methodology follows the DMAIC approach which
involves:

 Define

 Measure

 Analyze

 Improve

 Control

Define simply has to do with defining the problem. As business analysts” we can use problem
statements to define this, we also typically scope a project from a business perspective where you
may create a context level dataflow diagram. The purpose of this activity is to simply understand
the problem and put some boundaries around what you are trying to solve.

The Measure activity is what really intrigued me and seems to be the area we have been missing
in the business analysis world. Many times we present information based on hunches or previous
experience whereas with measure, you focus on the facts. This is an extremely powerful aspect
of the six sigma methodology. It says, ‘you think there is a problem, but let”s find out if there
really is”. In other words, what may at first seem like a problem may not be the problem at all
but you can only determine that through gathering metrics. The six sigma methodology
recommends things like the time series plot and pareto charts. If you are not familiar with these
types of artifacts, I recommend taking a class or at a minimum, googling to get more
information.

Analyze again provides power and I think this is an area we are still struggling with as business
analysts. In this field, there continues to be this behavior where a solution is decided before true
analysis is even done. As an example, on a project I was on, the leadership team insisted the
problem was the technology supporting a specific business area. Essentially, they said the
technology was no good. After doing a root cause analysis, it was determined the real issues had
to do with amount of time it took to make a request and receive a response from the IT team. The
technology itself was not the problem, the process around it was.
Improve has to do with offering up solutions. Again, it is important to look at all possible
solutions to a particular problem. From the example above, one the solutions was to improve the
process and response time for the business from the IT team. Although it may not be widely
supported in your organization, I still challenge you to look at a problem from all the angles and
provide objective solutions (even if the solution has already been dictated to you). At the very
least, you may uncover some additional requirements through your detailed analysis. There are
several benefits you will reap from this approach. As you begin to provide valuable information
to your leadership, you will become the go-to person. Leadership typically wants a well rounded
picture before they make decisions. You can help provide a view of all the possible solutions. In
addition, you will be adding to your repertoire of skills and improve your own marketability
(which is important in this world of ever increasing lay offs).

Control has to do with monitoring a project all the way through its lifecycle and evaluating the
results at the end. This is yet another opportunity for business analysts to take it to the next level.
In the last 10 years of my career, we continually fall down in this space. We don”t do a good job
of measuring whether we were successful or not. When we don”t do a good job of measuring
success, every project begins to look like a failure. If you look at the statistics, there are still a
high number of IT projects seen as failures. What are we doing wrong? There are several pieces
to the problem (which I will save for another article) but one piece most definitely is not
establishing critical success factors up front (another six sigma trick) and then measuring against
those at the end of the project.

In conclusion, whether you are a business analyst, business architect, customer engagement
manager, client engagement manager, enterprise business analyst, system analyst, project
manager, or any other title we can come up with and whether you are a six sigma shop, a BA
BOK shop, PMI BOK shop, a Lean shop, or an Agile shop – I hope you are doing these
activities. We should all be doing these activities to make our projects more successful.

Building a Requirements Foundation through Customer

Interviews
Articles

“Our customer doesn’t know what he wants,” complained Sandy. “I try to get him to talk about
the product and tell me what he wants, but it’s like pulling teeth.”

Whether you are building a brand new product or working on evolving an existing product,
understanding customer business needs is the foundation of a marketable product. But few of us
are experts in interviewing techniques, and few customers talk about their tasks, needs, and
context in neat, concise statements about product requirements.

Building the right product starts with asking the right questions. The right questions are those
that help us get beneath the surface and understand the customer’s world, work, and concerns.

First Things First

Before you plunk yourself down in front of the customer and start asking questions, articulate
your objective. What do you hope to accomplish by interviewing the customer? Do you want to
explore broad options, understand a specific business processes, or learn all you can about how a
customer uses a particular feature? Articulating a research objective sets the stage for a
successful interview. A wandering, unfocused interaction will yield paltry results and frustrate
the customer.

Once you’ve defined your objective, brainstorm a list of all the questions you might ask related
to the topic. Then organize the questions into themes and arrange them to flow from general to
specific and familiar to unfamiliar. The process of preparing questions helps to identify key topic
areas to cover. Following a set list of questions isn’t the point: successful interviewers invest
time in designing and testing questions—but then use them as a guide, not a script.

As you prepare for an interview, consider different types of questions. Each type will serve a
purpose and elicit a different response.

Context-free Questions

Context-free questions are useful in the early stages of a project, when you are beginning to
explore. Context-free questions help you decide which avenues to investigate and provide global
information about the problem and potential solutions. Because these questions don’t imply any
particular context, they are useful for any design project.

Here are some product-related, context-free questions:

· What problem does this product solve?

· What problems might this product create?

· What environment is the product likely to encounter?[1]

Context-free questions generate a deeper understanding of the product and project.

Meta questions—questions about the questions—are a special sort of context-free question. Meta
questions, such as “Do my questions seem relevant?” or “Is there anything else I should be
asking?” are likely to surface areas where the customer assumes that you already know.

Open-ended Questions

Open-ended questions invite the customer to expand on the topic.

Use What questions to learn about events and considerations.

· What happens next?

· What factors are involved?

How questions ask about the way things happen.

· How do you use the product to__________?

· How do people decide which option to select?

Could questions ask the customer to imagine or express a wish.

· Could you conceive of an example when you’d use the product this way?

· Could you see a way to use the product to solve this problem?

Closed Questions

A closed question is one that naturally leads to a one-word answer, usually Yes or No. Questions
that start with Can, Do, Are, or Is are usually closed questions.

Q: Do you have any problems with the wonder widget?

A: No.

Closed questions are useful for confirming specific information, but are deadly as an interview
staple. You want to delve beneath the surface, and closed questions won’t help you with that.

If you do happen to slip into a closed question, follow with a probing question to uncover more
information:

Q: Can you recreate the problem?

A: No.

Q: What steps have you taken to try to recreate the problem?

Multiple-choice questions offer a limited set of options and help to establish relative priority:

· Which would you prefer, A, B, or C?

· If you had to choose one, which would you choose, X, Y, or Z?

Like closed questions, multiple-choice questions have their place, but shouldn’t make up the
bulk of an interview.

Past, Present, Future

Ask questions about past use to understand problems and weaknesses in the product or feature.
Use present-time questions to learn about how the customer currently uses the product or how he
currently performs his job. And ask questions about the future to learn about trends and
anticipate future needs.

Past: When has the product failed to perform as you expected?

Present: How are you using the product now?

Future: How do you see your workflow changing in the next several years?

Tell Me More

Don’t stop at the first answer. Follow an opened-ended question with a probe to gain further
insight. A good interviewer will elicit a second, third, and even a fourth response. When you
want to learn more, use questions like these:

· What else?

· Can you show me?

· Can you give me an example?

· How did that happen?

· What happens next?

· What’s behind that?

· Are there any other reasons?

Be sure to probe for more information when you hear emotion or judgment:

“I hate the way the floo feature operates!”

“The product does a poor job.”

Dig deeper to identify unmet needs or weaknesses in the product.

Vague statements like “The product must be easy to use” call for probing to learn what “easy to
use” really means to the customer.

Questions That Aren’t Really Questions

Some questions don’t elicit the customer’s opinion, but confirm the interviewer’s opinion
instead. Biased questions suggest a “right” answer: “My investigation shows that automating the
floo process will provide the biggest savings. What advantages do you see in that?” Leading
questions make one response more likely than another. Biased and leading questions tend to feel
manipulative, and a customer will tune out if he feels the interviewer is leading or putting words
in his mouth. Compound questions make it difficult for the customer to respond at all, as in this
example:

“Do you think it’s okay to have a question with two topics—unless there are more than that, or if
the topic is complex—and is it better to stick to short questions, except in the case where a
longer question is better, or is it a judgment call, except in a special case?”

Ask one question at a time, and give the customer time to answer. Rushing in with another
question can give the impression that you don’t really care to hear what the customer has to say.

Ask Why Without Asking “Why?”

Curious children ask “Why?” endlessly. They want to know the answers to everything, even
things that are unknowable.

We want to know why customers do the things they do so we can understand the tasks they
perform and the business needs behind the tasks. But an endless stream of “Why?” questions can
wear on anyone’s patience. Worse, “Why?” can sound blaming, or feel like the interviewer is
demanding a cogent explanation for something that’s unknowable.

Avoid putting the customer on the defensive by using How or What questions to dig beneath the
surface.

· How did this come to be?

· What was the thinking behind that decision?

Or simply ask “Can you help me understand this?”

Putting It All Together

Before you rush off to try out your interviewing skills, practice. Start with a colleague, and then
try your interview with an internal customer proxy or subject-matter expert.

Most people find that maintaining rapport and tracking the interview takes all their attention. To
help with this, consider working with a partner who can take verbatim notes during the
interview. At the end of every interview, perform a short interview retrospective to identify what
worked well and what you might want to do differently in future interviews.

Most customers appreciate the opportunity to talk about their work and participate in shaping the
products they use. Prepare for your customer interview carefully and hone your interview skills
through practice. Invest in learning your customers’ wants and needs so you can deliver the right
products.
Business analyst interview questions

You never know what you will be asked on a job interview. The following sample of interview questions
for business analyst will help you prepare. You need to be able to answer all questions truthfully and
professionally. Here are the business analyst interview questions:

Q. Can you tell me why are you considering leaving your present job?
A. Regardless of the reason, do not bad mouth your current employer. Negativism will always
hurt you. Good answers include: “There is no room for growth at my current employer. I am
looking for a company with long term growth opportunities”. “Due to a company restructuring,
my entire department is relocating to Florida. I was give the option of moving, but do not wish to
relocate”. “My current company is not doing well, and has been laying off employees. There is
no job security there, and more layoffs are expected”.

Q. How do you handle stress and pressure?

A. “I find that I work better under pressure, and I enjoy working in an environment that is
challenging.” “I am the type of person that diffuses stress. I am used to working in a demanding
environment with deadlines, and enjoy the challenges.”

Q. We have met several business analyst’s. Why are you the one we should hire?
A. Give definite examples of your skills and accomplishments. Be positive, and emphasize how
your background matches the job description. Mention any software packages and spreadsheet
software you are familiar with. Also let them know if you have advanced knowledge of any of
the software.

Q. What do you know about our company?

A. This question is used to see if you have prepared for the interview. Candidates that have
researched the company are more appealing. Companies like prepared, organized candidates.

Q. What are your greatest strengths?

A. Be positive and honest. “My greatest strength is maximizing the efficiency of my staff. I have
successfully lead numerous teams on difficult projects. I have an excellent ability to identify and
maximize each of my staffs strengths.” Give examples.

Q. Tell me about your greatest weakness?

A. It is very important to give a strength that compensates for your weakness. Make your
weakness into a positive. “I consider myself a 'big picture' person. I sometimes skip the small
details. For this reason, I always have someone on my team that is very detail oriented.” Another
good answer: “Sometimes, I get so excited and caught up in my work that I forget that my family
life should be my number one priority.”

Q. What are your goals for the future?

A. “My long term goals are to find a company where I can grow, continue to learn, take on
increasing responsibilities, and be a positive contributor”.
Hopefully these typical business analyst interview questions will help you. It is important to
customize the answers for your specific background and experience.

Now that we have gone over the interview questions for business analyst, you need to be aware
of important resources that can make your job search easier and more thorough.

1. What is the career path for a Business Analyst?

A Business Analyst in the IT field has many varied directions among which to choose a career
path. The most direct would lead to a Lead Business Analyst position and then Project Manager
whereby the incumbent manages projects through the entire lifecycle from inception to post-
implementation including the management of business analysts system analysts quality assurance
analysts and most likely development project managers or team leads. That path would then lead
to Program Management perhaps PMO management or Product Manager and on to
Directorship.In addition a good Business Analyst may find they are heading toward a Customer
Relationship Manager position whereby they become the primary IT interface to a given
Business Unit (BU). This role most often leads to a position within the BU as a Manager of
Applications or a Process Management role. Process Management opens many jobs including
process re-engineering quality program development and large scale or enterprise process
management programs such as ITIL or Six Sigma initiatives. These roles will continue to
proliferate as companies realize the benefits of having a SME in process and quality.And still
many Business Analysts find their understanding of business process entirely portable into
purely system related positions in the business side that are only peripherally related to IT. These
of course may lead to quantitative roles manager roles or operational roles such as supply chain
logistics etc.Of central importance to a successful Business Analyst is the interest in speaking to
people. Face to face verbal communication is paramount to support other tools such as surveys
and diagrams. Incumbents must be interested in understanding not only the pieces that comprise
a system but the people that comprise it and the realities that embrace the system. Briefly the
Business Analyst must understand and not judge the what should be and the what is .

1. How would you transform business requirements to functional requirements?

while preparing Business requirements documents you mention why you need to built a system,
i.e. problem statement. What you need to do while creating functional requirements is you have
to specify is, solution of the problem. Specify thoroughly business problem and explain solution
for the same.

Business requirement documents does not necessarily contains solution part, functional
requirement may contain it how end user wants the system to perform. Don't forget to add non-
functional requirements same doc.
Following is the instance of Business Requirement, Functional Requirement and Non-Functional
Requirement.

Business Requirements :- sales order is made against customers purchase order. Sales order is
given for approval to upper authority

Functional requirement:- Sales order shall be made with reference from Purchase order and it
should be approved from upper authority.

Non-Functional Requirement:- Sales order should be in proper format (Specify format) and six
copy of sales order should be printed from printer in 1 minute.

1. How do you resolve issues?

I would rather focus on issues and the facts related. Origin of issue, severity of the issue,
implications and possibles solutions to solve the issue. Try not to focus on the person who
brought up the issue.

Another important part is how to avoid similar issues in future.

1. What analysis and modeling techniques do you use to translate business objectives into
system requirements?

 Create project-initiation diagrams including business use cases, activity diagrams, workflow
diagrams, flowcharts

 Determine project scope and derive context diagrams and project use cases from the business
diagrams

 Detail the use cases by using activity diagrams or other techniques

 Create high level analysis dataflow diagrams, domain class diagrams, and entity-relationship
diagrams from the use cases or other high level diagrams

 Recognize and understand the various design models, including the other relevant types of UML
diagrams, detailed design entity-relationship diagrams, and decomposed dataflow diagrams
  Determine when to use which modeling technique, following them through a project life cycle,
and understand which diagrams are derived from others

 Understand the basic concepts of normalization and decomposition so can converse intelligently
on the topic and review diagrams that have been normalized or decomposed

6. Mention some of the tools commonly used by business analyst?

There might be various tools that you as a business analyst would be using depending upon the
work environment.
The primary tools are:
MS-Office (Especially Word)
MS-Visio (for visualizing the concepts, creating diagrams)

But a lot of bigger organizations have been using Rational Software. Rational software licensing
is expensive so you might not find it being used everywhere.
Rational Requisite Pro (for Requirement Management)
Rational ClearCase/ClearQuest (For change management)

I have also found that some places like using MS-SharePoint, telelogic DOORS and other tools
for document collaboration. I would say, keep a working knowledge of MS SharePoint, at least.

Sometimes you might end up being a BA com QA. As such, it is nice to have a working
knowledge of creating Test cases, using Load Runner, QTP etc.

Except for these tools if you have knowledge of RDBMS, Oracle, SQL, different operating
systems, some OOP, it is always a plus.

7. Explain equivalence class?

Equivalence class a mathematical concept is a subset of given set induced by an equivalence

relation on that given set. (If the given set is empty then the equivalence relation is empty and
there are no equivalence classes; otherwise the equivalence relation and its concomitant
equivalence classes are all non-empty.) Elements of an equivalence class are said to be
equivalent under the equivalence relation to all the other elements of the same equivalence class.
For each equivalence relation there is a collection of equivalence classes. Any two different
equivalence classes are disjoint and the union over all of the equivalence classes is the given set.
Equivalence classes and their corresponding equivalence relation are defined in set theory a vital
foundation for mathematics and those fields that use mathematics. More details can be found in a
study of equivalence relation.

1. What are the problems solved by business analysis?

As a BA the most critical part is in gathering requirements (we should understand them very well
from a Business User /stake holder point of view!!!)

Reason: There might be a chance for the whole project to go in the wrong path due to wrong
understanding of the Business users/ Stake holders' needs and the gathered requirements created
for the work following that step… i.e. going from A to C instead of going from A to B.

Notes: (Business Users: are the individuals who work in organizations in different departments
like Logistics accounting finance Inventory) in the company who wanted the software in Place
for them to work on to help the Customers.

Stake Holders: Someone who is related to the Project? 2 types of People are involved:

Direct Stake holders: business end users customers developers tech team.
Indirect stake holders: management etc.
The Project Manager responsibility (usually) identifies the stakeholders determine their needs
and expectations and more important must manage and take their help for the project success.
(You should Understand them well to provide them with right service for the right success of the
project)...

SME's: are the Subject Matter Experts who know about that project and have in-depth
knowledge about that software application used and that particular business domain knowledge
like Finance (terms and permutations etc.) Accounting (Business Planning Ledger maintaining
Forecasting) Mortgage (Local banking rules Knowledge about compliancy of applications forms/
applications that needs the authorizations of the local Government bodies or counties
Underwriting conditions (How flexible the Loan lending organizations at the individuals credit
check or History)

So The SME's help the Project Manager or BA to help them understand about the necessities or
needs of the Business Users or Stake holders like/interests- (How the Project help save time for
the transactions or? how much secure/security is needed the application wise or profitable over
long run) and SME's explain How the Stakeholders or Business Users want the application to be
or appear to be for the Customers or Business Users).

Read more: http://www.articlesbase.com/interviews-articles/business-analyst-interview-questions-

with-answers-3483479.html#ixzz1K8fMVdhf
Under Creative Commons License: Attribution