Our system is totally dependent on customer so the agile process was not followed in our organization

however a tat was there. Like for every process its 2 week.

Never say that you don’t know just say that you don’t follow as per the training given by the
organization. Every organization is having different format to work up on.

Business Analyst is a role but the analysis is a task.

Business is a process where an analyst is required to follow certain steps. N other words will follow
certain steps and deliver the data in the form of requirement document.

Primary function of an analyst is to review the current state of organizational process and their day to
day activities.

Organization structure plays a very big role towards the success rate of the project as depending upon
the form of an organization.

Requirement: It is a condition or capability which is needed by the stake holder to solve a problem or
achieve objective in any organization.

Types of Requirement

Business Requirements

Stakeholder Requirements

Solution Requirements

Transition Requirements

Functional requirements

Non functional requirements

Requirements could be direct requirement or indirect requirements

Direct requirements means what are the direct requirements you are looking for.

Indirect requirements – it is inherited by the direct requirements

Stake holder requirements- specific to the specific to the stake holder

Solution requirements –it is somewhat the characterstic of the solution

Which make business requirements and stakeholder requirements.

Solution should be in line to business requirements and stakeholder requirements.

Functional requirements is nothing but the behavioral and the information that the solution will
manage.

Solution can have different functionality that can be broken down.

Non functional requirement eg. Training before the interface is made to live. This is a part o fnon
functional requirement.

Transitional Requirement it is considered as the capability that the solution must have in order to
facilitate transition from the current state to a desired future state.

Analyst responsibility- BA is accountable for inspecting business conditions and states ,classigying and
evealuating possibilities for refining business systems, outlining requirements and ensuring the actual
use of information systems in satisfying the necessities of the buinesss.

Business analyst is also involved n performing the analysis fo the servies which are offered or received
by the organizations. The analyst is also responsible for the elicitation process.

What is Analysis?

Business analysis is an iterative process which require several verification and validation until the
requirements provided by the stakeholders are not being approved.

Business analysis involves:

1.) Understanding how organizations function to accomplish their purposes.

2.) Defining the capabilities an organization requires to provide products and services to external
stakeholders.
3.) Defining organizational goals and how those goals connect to specific obejectives
4.) Defining how the various organizational units and stakeholders within and outside of that
organization interact.
5.) Some important attrivutes of a good business model are that they are unambiguous, complete,
consistent, traceable and agnostic.

Analysis attributes
a.) Unambiguous means- if there is a thing that can be interpreted in more than one way.
Your requirement is having dual meaning . It will be resulting into inconsistent behavior and
the developer could have understood in a different way.
Probably you are asking about an apple and you get an orange. That Is what ambiguous
mean
 b.) Complete stands for – The model must specify the business rule. Process information
required to build a system. It has to be complete set which have the business rule as well as
the process impacted by that as well the information which is going to be used. It should
have everything which is common across application. Means it is having a lot of information
which is required or may be required by the development. We have explain from the
requirement side not the solution from the architectural point of view.
c.) Consistent means – it means it should be consistent with both fixes and the enterprise
requirement. In addition it must be kept up to date and the requirement evolve during the
project implementation. It should include all the variable factor which is going to be
changing. But if it is a single process used by multiple processes. You need to make sure
that you capture all the scenario to make the requirement as the consistent requirement.
d.) Traceable Means - It should be tracked back to the beginning point. Suppose if something
is wrong one can track back and find out why the system is wrong.
e.) Agnostic means –

Analyst is the author of the requirement where as stakeholder is the owener of the requirement.

It is the responsibility of the stakeholder how good they provide the requirement. However it is the
responsibility of the stakeholder how good they capture the requirement.

A Business analyst is the one who conveys the requirement from the stakeholder and pass it on to the
IT.

BA documents and Deliverables

1.) Business Use Case

2.) Business Process Flows

3.) Project Charter

4.) Context Diagram

5.) Business Requirements Document ( Refer Sample BRD Template Requirement Tracebility Matrix
RTM)

6.) System Requirements Specification(SRS)

7.) Testing Guidelines and Techniques

8.) Other vendors Deliverables

It is totally dependent upon the organization that the deleverables are different.

Whenever there is a meeting. The minutes should be sent to the stake holder.

What do BA do ?
They ask questions!!!

These are the above things that should be in the business analyst because you are upfront to the client.
Because we are interacting with the client.

Suppose the client is having less time and the developer said they need at least two weeks to do the
desired change. But the client has not that much time. They want it to be completed in a specific time
frame then you will negotiate with the development manager and discuss the things inorder to expedite
the process and try to negotiate if that can be done in that specific time frame.

The biggest task of the business analyst is the communication between the stakeholder and the team.

It is necessary because you the single point of contact for the whole project.

He should work the necessary steps so that the project is not in danger. Even if he has to arrange a
meeting between the IT and the stakeholder.

A experience business analyst advances by listening the SME- subject matter expert and the enduser.

It means no matter what capacity you are working with what role you are performing. You are able to
accomplish the business objective. That is your role is.

Business composition and architecture for BA – Business analysis, as a discipline, has a heavy overlap
with requirements analysis, but focus on identifying requirements in the context of helping
organizations to achieve strategic goals.
You must be having a better knowledge about the architechture and the composition the better will be
for you.

Question:- Business Analyst – Tell me something about yourself.

Some of them want to know about your recent work experience, some of them want to know about
your projects or your daily duties or accomplishments.

Telling about yourself is about telling story to impress someone. So this is the opportunity to express
your confidence or your boldness. Make your own scripts get inspired by your previous experience.
Practice in front of the mirror.

Your script contains past present and future.

They want to know your strengths or weakness.

It could be anything like business analysis skills, project management skills or technique required to
gather requirements or commitments.

eg. One of my skills is to retain good relationships between stakeholders and technical teams which
helps me being a aggressive business technical analyst.

Or you can say one of your skills is to perform gap analysis. Gap analysis helps me to identify the current
and the future aspects of the project to ensure we are not missing any requirements to scope of the
project whereas impact analysis ensures the capture requirement are not creating any impact or risk to
any other related project.

Or you can say you are very good in agile methodology. You are very good good in conducting scrum
sessions to ensure my team has no road blocks.

Weakness- I consider my self as a arrogant meeting facilitator where I don’t hesitate to assign the
assignments to the individuals and emphasize on lot of delivering on time.
Most recruiter wants to know what responsibilities you performed on your current job or domain skills
like finance or healthcare or techniques which you used or implemented as an ability or knowledge.

As a job seeker if they are looking for waterfall methodology,” I would say in one fo my recent
healthcare project we used waterfall methodology and my major responsibility is to gather business
requirements and functional requirements for implementing enrollment or authorization submodules
for claim management system .
If the job offer is on agile methodology in my recent one of my project we used agile methodology my
major responsibility includes gathering requirements, creating the use cases or engaging the product
owners or the subject matter expert with requirements by performing the stakeholder analysis. I used
appropriate tools and technique like workshops, feasibility studies or jad sessions to develop and
validate product backlogs and requirements from all aspects of the project.

They may also want to know something from your past so you may also need to cover some points from
your previous projects too so this is I would say when I used to work at ITsource Technologies was
responsible to interacting with internal and external clients to extract business wants and business
needs and transfer all gathered information in to user stories where I proved myself as a good
communicator. I have been highly appreciated with my project owner for providing good package of
recomdation which help them to make certain decisions or tell them your work culture or your
relationship with your project manager or stakeholders.

Definitely they want to know your confidence say I am very good strong in retaining good relationships
between stakeholders and technical team which helps me being a good business analyst.

Be ready your script and make it short and sweet. You should know where to start and where to end.
Don’t tell everything in a single shot. Keep a backup plan store your answers summarize your big picture
in the form of experience, strengths or daily duties or accomplishments or challenges you faced be
concise and passionate about your self.

Research the company and know more about the project and the role you are going to play.

Most of the interviews don’t even listen what you say they look how you are presenting yourselfsand
communication skills that is more important.

Healthcare Business Analyst –BA is responsible for a range of activites in full system development life
cycle which improves the operational efficiency and success of the project.

Healthcare is managed by the CMS and protected by the HIPAA law Health insurance portability and
accountability act. It is a law to protect medical records and other personal information while processing
the claims.

CMS ( centre of medicare and Medicaid services) It is a federal agency with in the US which runs the
medicare and the Medicaid plans.

There should be some knowledge about commercial plans for example HMO, PPO, FPO.
As a BA we are responsible to gather the requirements to build this plan. Capture from stakeholders or
SME via a number of meetings.
One of the high priority projects is for any healthcare client is claim adjudiction process or claim
management system. You should know how claims go processed.

Read difference between 4010 and 5010 or ICD 9 and ICD 10 to define the requirements as per the CMS
requirements.

Providers are participating providers or non- participating provider.

PCPS, Specialists, Hospitals, Homehealths, Nursing etc.

In-Network or out-of- network providers

Co-pays, deductible, coinsurance, Out-of-pocket.

Bill types , diagnosis codes, procedure codes or place of services, revenue codes or place of service or
type of bills.

EDI transactions: out of many 837, 834, 278, 270, 999

Medical knowledge, Medical Billing and Medical Terminology which will help in identifying the business
needs from the stakeholders and the subject matter experts. You need to develop the roadmaps with
HIPAA regulations to improve the efficiency and effective ness of Data Processing, Storage, Security and
Privacy.

What is scrum?

It is a subset of agile methodology. It is a framework that means it provides an opportunity to work as

for the project needs with cross functional teams to reach the project goals mostly it is used for
implementing complex projects with the help of iterative or incremental approach the number of phases
with in the scrum ok lets begin with the understanding of the product backlog or the product owner

According to the scrum you have to create the list of requirements or user stories and prioritize them
and this list is known as product backlog the product owner is responsible for managing the product
backlog and he has absolute authority over the product backlog and he is one who decides what
requirements should be added in the product backlog.

What is sprint and sprint backlog?

It is nothing but a set period of times for example 2 weeks during which assigned work has to be
completed by the team and should be ready for product owner to review. In scrum the product
development happens in sprint. In the beginning of the sprint the developer and the agree upon the
requirements from the product backlogs which they will complete during the sprint. This subset of
requirements transferrend from product backlogs becomes the sprint backlog so depending upon the
complexity of the project duration of the project keep changing. It could be one month, one week or
even one week springs next daily scrum meetings
Daily scrum is a meeting to discuss who is working on what and whether any blocking issue have been
discovered.

Daily Scrum- What you have done since yesterday?

What do you plan to do today?

Any obstacle on your way?

Ans for example I schedule the meeting with the development team with the walk through of the
rrequirements finally nothing is blocking my task.

User Stories:

Requirements in the products or in the parts or in the spring backlogs are often reffered to as user
stories . These are created by the product owners and should represent some business leads
development team needs to think about how user story should be implemented. The development team
takes the story from the spin backlog and break the user stories in to tasks. During the daily scrum the
developers should be refereeing to a task. A story make take week to complete but the task is which
developer can complete with in or less than a day.

Scrumboard- Scrumboard is a board contains a list of stories for the current sprint and the task
associated with each story and the status of each task. Everyone in the team can see what everyone is
working on so developer keep updating its status such as what to do what is in progress and what is
completed.

Burndown charts – to represent the team progress over time.

Scrum Master Role- The role of scrum master is that the team is following the process of scrum. The
scrum master is responsible that there is a daily scrum and everybody answers the 3 question. Scrum
master is responsible to resolve the issue which come across during the scrum.

In scrum The product owner, the developer and the scrum master

Question :What are Business Analyst Daily task?

Elcitate, analyze, communicate, document, and validating the requirements.

Collect the problems from the users. Solve the problem with the help of SMEs , by keeping stakeholder
expectations.
Key responsibilities :- Understand the project, Identify the scope, goals of the project, investigate the
project, Decision makers, stakeholders, Issues and goals, Illustrations( flow diagrams or swimlanes),
track, manage and resolve conflicts.

Type of meetings

1.) Workshops, 2.) Brainstorming sessions 3.) Focus groups 4.) JadSessions 5.) Walkthroughs

Type of requirements
1.) BRD 2.) FRD 3.) Technical requirement(TRD)

Agenda items, stake holders, decision makers and SMEs , not going off track, keep on meeting on track,
meeting minutes, actions items, assign the tasks,

Stake Holder Analysis

How do they impact on the projects ?

What are their contributions?

What is the level of involvments?

How do we need to communicate with them?

Some of the stake holders are very important as they own some requirements or departments.
Stakeholders can be identified by your project managers or project co-owners .Don’t hesitate to ask
them or to extract this information from project charter or the business cases. Project manager is
the one who has selected the stakeholders for the project or he is the one who has been selected by
the stakeholders. Either way project manager should know who are the stake holder for the project
but the project manager may not know their level of engangement or level of involvement or who
are the respective subject matter experts. Once you start interacting with the stake holders. You will
be able to categorize who is responsible for based on their contribution and involvement.

SMEs are like wikepedia. You ask one question they will give many answers. So you must be able to
pick the right answer based on your scope. Scope is like a boundry for us if you cross the boundry
the project will get angry of us. Because it totally impacts the budgets, schedules and even the
resources.

So if you are smart enough you will raise any question to any stakeholders or even the subject
matter experts you have to provide an overview of the project to SME or even stakeholder just to
remind them. So they give you response based on your scope. Based on your requirements and this
helps to keep them in control.One of our agenda is to communicate with the key players to analyze
what they need to gather everything together from stakeholders and subject matter experts.
 Present recommondations are in the form of a package and get the approval from the stakeholders
which is commonly know as a requirements documents.

One is communicating with people with many designation. Never be afraid of the person whom you
are inviewing or discussing. Make sure you capture those requirements and verify them. Identify the
stake holders, identify the level of contribution or involvement create a relationship and build a trust
among the stake holders. The best thing about a business analyst is the ability to influence the
decisions and outcomes in a project.

Question:- What is JAD?

AnsJoint application Development –Meeting with the technical team. It is verycommon when they
are implementing agile methodology. When business need some technical input from the technical
expertise JAD session is required. When Technical expertize need business input JAD session is
required. When the technical and the business team collaborate to make certain decisions. That is
nothing but the JAD sessions.The purpose of JAD session is to collect the requirements from the
business technical or the testing team to solve technical issue and to develop the technical
solutions. So lets discuss how to get ready for JAD sessions. Each JAD sessions

1.) Must have detailed agenda items and well-defined objectives.

2.) Invite the key stakeholders and technical expertize
3.) Take meeting minutes and notes
4.) Ask Questions
5.) Assigning the action items to someone during the JAD session.
6.) During the JAD session your question or agenda may drive the meetings but you maynot expect
instant answers. But the question you raise make certain decisions which may require the
expertize from the various departments or teams may require to participate during these
discussions. The importance of JAD sessions is to come up with the decisions. Your main motive
should be to allow them to make some decisions. If we out of the meeting with no decisions
made means someone or something is missing if the solution to the problem is not concluded in
one sitting series of JAD sessions is required. As a JAD facilitator you are responsible for
collecting discussions and decisions made but don’t forget to set goals for next meetings and
task assignments. Outcome of the JAD sessions will a lot of discussions. It includes the key player
from the business or even the technical teams to visualize the goal of the projects understand
the problem come up with a opportunity or requirements with a aim of joint discussions to
make decisions joint and make the solutions technically. Most of the Jad session happens during
the development phase but it will also happen during the requirements phase. But you should
be a very good listener giving opportunity to others during this meeting and give your input
when the time comes.

Agile there is not a lot of docuementation but in waterfall there is a lot of documentation.
In agile format. We work on the iterations. Means before moving the fully live a prototype is shown.
That is working .it is done generally in 2 weeks or 1 month where as taking a example for waterfall for
one year

In Agile there is release planning like hey we have completed the first month this is first iteration this is
the different features and functionalities. Do you want to release, do you think its doable or do you
think its not doable. Do you think are we approaching too fast.Just discuss high level functionalities.
Agile Terms

1.) Spring planning

2.) Sprint backlog
3.) User story
4.) Scrum Meeting

Meeting in agile

1.) Release planning

2.) Sprint Planning
3.) Gromming Sessions
4.) Sprint Demo
5.) Retrospective meeting

Sprint Planning –In sprint meeting not you discuss the meeting but also note down the user
stories. For each user stories there are different tasks. It is called as sprint backlog.

Grooming session- when you actually finalize what are the different tasks involved. How much
time it will take. It means you actually starts cleaning up

User stories example – as an account holder I can test messages to check the connecitivity.

Sprint demo as a ba you demonstratre the actual working prototype.

Retrospective meeting in this we will this is what we do right and this is what we do wrong.
There is a possibility that the product owner is not happy with it.
Sometimes thing cannot be done at that time period so you decided that it can be taken care
after that But if don’t have documented it how you will do it after 6 months.

Agile description – Role, feature and benefit.

Product backlog – it includes all the user stories.

Release backlog- it is a collection of multiple sprints.
Sprint backlog-it contains the user stories particular sprint.
 Prioritization- which is most necessary user story that is taken care at the first.

Difference between BRD and

FRD......
 Published on August 8, 2015

Rudhra CSM ProductM

 FollowFollow
Senior Business Analyst @ RealPage Inc. 20 articles
 107
Like

 21
Comment

 9
 Write an article

Difference between BRD and FRD....from a Layman understanding...atiom

BRD- Business Requirement Document or BRS Document- Business

Requirement Specification Document both are same. The
Business/Client/other Stakeholders provide a requirement. One requirement
can be small or big. But, has to be break wherever it requires and taken as
multiple requirements.

FRD- Functional Requirement Document or FRS Document- Functional

Requirement Specification Document both are same. The Process to reach
the expectancy of the BRD is an FRD. How we develop the expected
requirement? What are the features? Functionalities? Tools or Systems used
and interdependencies? How they react when start working together when
this Functionality takes place? Assumptions?Limitation?any other supporting
Process Flows/Maps/Wiring Diagrams etc..

Best Example:

BRD- Need a Motorcycle which should make work me and i should make it

work to reach my destination.

FRD-

How does Motorcycle looks?

What parts are included to assemble it?

Step by Step process as how it can be assemble it?

How it can be used?

Its Performance- Speed, Accuracy?

Used Case, Process Flows etc for each activity interlinking dependencies. Ex:
When U drive the Motorcycle, How the Engine Works, Handle Turns,
Braking, Seating, Chain System, Light etc..

Assumptions & Limitations?

Now, the above BRD can be considered as Single Requirement or broken

into multiple requirements? I believe yes- it has to be broke into multiple
requirements. If yes, then=>
 BRD=> Need a Frame which can fit the Handle, Seat, Carriage, Pedal, Chain
System, Stand=> Center/Side Stand etc..

FRD=> About the Frame=> How the Frame to be?Features=>

Functionalities=> Performance=>Assumptions=>Limitations.

Hope this will make u understand as a lay man. U can corelate to any
Software or Hardware Process.....

Documentation is the most important aspect for any BA.

The documentation is useful to depict the requirements and the detailed discussion
about new features and change request if any. There are many different types of
documents that a BA prepares. Some of the important ones are listed below -

 Business Requirement Document (BRD)

 User Stories
 Use Case Specification Document
 Functional Requirement Document (FRD)
 Requirements Traceability Matrix (RTM)
 Market Requirements Document (MRD)
 Product Requirements Document (PRD)

Apart from these there are several other documents that is created by Business Analyst.
It helps in understanding the business process and business events. A business events
is a trigger that gives birth to the requirement. These requirements are then fulfilled by
opting for IT solution.
Diagrammatically the documents can be pictured as a simple sheets of papers which
contains some useful matter.
Let’s take a look at the similarities and striking differences between BRD and FRD.
 Business Requirement Document

 BRD highlights "Business Requirements" - i.e., high-level business goals of the

organization developing the product or solution with the help of IT.
 In other words it describes at very high level the functional specifications of the software
 A formal document illustrating the requirement provided by the client
 The requirements could be collected either by verbal or written or both
 Created by a Business Analyst (usually) who interacts with the client
 Entire work is executed under the supervision of the Project Manager
 It is derived from the client interaction and requirements

The BRD is important since it is the foundation for all subsequent project deliverable,
describing what inputs and outputs are associated with each process function. It
describes what the system would look like from a business perspective. Following are
the most common objectives of BRD -

 To arrive at a consensus with stakeholders

 To provide input into the next phase of the project
 To explain how customer/business needs will be met with the solution
 Holistic approach to business needs with the help of strategy that will provide some
value to the customer

Basically, stakeholder’s requirements can be small or big. Thus it needs to be break

wherever it requires and should be taken as multiple requirements.

Format Of BRD -
There are many formats or templates that the organization follows. However, it depends
upon the practices that is carried in the organization. For a product based company the
BRD format is different as compared to service based firms. Standard format which is
followed in most organizations are shown below. It is important to note that for clear
understanding of the document we should include list of acronyms used.
The BRD template contains -

 document revision
 approvals
 RACI chart
 introduction
 business goals
 business objectives
 business rules
 background
 project objective
 project scope
 in-scope functionality
 out-scope functionality
 assumptions
 constraints
 risks
 business process overview (modelling diagrams for instance, Use Case and Activity
Diagram)
 legacy systems
 proposed recommendations
 business requirements
 appendices
 list of acronyms
 glossary of terms
 related documents

Now let’s try to dig more in FRD..

Functional Requirement Document

 FRD highlights "Functional Requirements" i.e., functionality of the software in detail

 Depending on the product, FRD document can be between 10 to 100 pages
 It too describes at a high level the functional and technical specification of the software
 Usually created by Business Analyst under the supervision of technical expert, for
instance System Architect
 In a small and medium sized organizations a BA take care of this
 Few companies did not create FRD, instead they used BRD as it is detailed enough to
be used as FRD as well
 FRD is derived from the BRD

Advertisement

Actually, the process to reach the expectancy of the BRD is an FRD itself. Here an
analyst after discussing with stakeholders and project manager ponder on questions like
-

 How we develop the expected requirement(s)?

 What are the features and functionalities?
 What are the tools and/or systems used and their dependencies?
 How will the customer reacts when they start using the solution?
 Any assumptions or constraints?

Most common objectives of FRD -

 Depict each process flows for each activity interlinking dependencies

 Holistic view for each and every requirements, steps to built
 Estimating detailed risks for each new change request
 Highlight the consequences if the project health is weak to avoid scope creep

The FRD should document the operations and activities that a system must be able to
perform.

Format Of FRD -
Likewise BRD, FRD has a somewhat different format focusing more on risks and
interfaces. Although there is no such standard format that a Business Analyst should
opt for. Companies belonging to different domains use their own template. For instance,
you would find many points would be repeating as in BRD.
But there should be no confusion for BA to prepare this document.
The FRD template contains -
 Introduction - It should contain Purpose, Scope, Background, References, Assumptions
and constraints, document overview
 Methodology
 Functional Requirements
 Modelling Illustrations - Context, User Requirements, Data Flow Diagrams, Logical Data
Model/Data Dictionary, Functional Requirements
 Other Requirements - Interface Requirements, Hardware/Software Requirements,
 Glossary

Now the use of BRD or FRD in organizations depends on the organization policies,
practices followed by the project team and stakeholders. As in my organization all
projects are being hoped from Waterfall to Agile. If the stakeholders is positive with the
documents then BA will design the same. But if there is a need for the continual delivery
of working product then documentation will not be preferred.
However, documentation will remain a valid artefact of any project in distant future.
Usability Testing continues to be one of the most important factors of new product
design. After the creation of a product, it is very important to verify that when the
product goes through human interaction, that it is achieving their objective or goal.

It is often very important to test the usability of a product among people of different
ages, genders and demographics. True, you want to create a product true to the original
design and have it be as it was intended, but that would be a moot point if, in fact, the
product could not be used as intended due to a design flaw. This is the main goal and
purpose behind usability testing.

Also, usability testing allows designers to improve upon their design. If someone is
interacting with a product in a way that is unanticipated, but could contribute to the
improvement of the product, putting that through usability testing is a great way to
discover these little changes or improvements. It’s also a great way to see what does
not work and eliminate potential problems.

There are several ways that you can conduct usability testing. The main two are
privately observed tests, and focus groups. Privately observed usability tests often
involve the tester being either left alone with the product and observed or recorded, or
having someone observe their interaction. In either case, the users actions and motions
are logged and they are often encouraged to speak what they are thinking so that the
observer can capture their total reaction to the product.

Focus groups usually involve a group of people discussing the product or responding to
questions asked after they have interacted with the product. Both methods of usability
testing are successful for different reasons, and it is important to select the right one for
the product in question.

In many cases, it is good for a product to go through more than one round of testing and
revision before it is released to make sure that it is both usable, and that the concepts
and ideas of the designer have been properly recognized and translated.

So if you have a brilliant idea, be sure to really test it before you finish it up. The same
can be said for websites too. It’s important to recognize that proper Usability testing is
the best way to guarantee the intent of the finished product.

What is  Requirements Traceability Matrix (RTM) in Software Testing: Step-by-step guide

to creating Traceability Matrix with examples and sample template
Today’s tutorial is about an important QC tool, that is either over-simplified (read overlooked) or
over-emphasized – i.e Traceability Matrix (TM). 
Most often, the making, reviewing or sharing of a Traceability Matrix is not one of the primary
QA process deliverables – so it is not majorly concentrated on, thus causing the under-emphasis.
On the contrary, some clients expect a TM to reveal earth-shattering facets about their product
(under test) and are disappointed.

“When used right, a Traceability Matrix can be your GPS for your QA journey”.
As is a general practice at STH, we will see the “What” and “How” aspects about a TM in this
article.

What You Will Learn: [show]

What is the Requirement Traceability Matrix?

In Requirement Traceability Matrix or RTM, we set up a process of documenting the links
between the user requirements proposed by the client to the system being built. In short, it’s a
high-level document to map and trace user requirements with test cases to ensure that for each
and every requirement adequate level of testing is being achieved.

The process to review all the test cases that are defined for any requirement is called
Traceability. Traceability enables to determine which requirements spawned the most number of
defects during the testing process.

The focus of any testing engagement is and should be maximum test coverage. By coverage, it
simply means that we need to test everything there is to be tested. The aim of any testing project
should be 100% test coverage.

Requirements Traceability Matrix establishes a way to make sure we place checks on the
coverage aspect. It helps in creating a snapshot to identify coverage gaps. In short, it can also be
referred to as a metrics which determines the number of Test cases Run, Passed, Failed or
Blocked etc. for every requirement.

Why is Requirement Traceability required?

Requirement Traceability Matrix helps to link the requirements, test cases, and defects
accurately. The whole of the application is tested by having requirement traceability (End to End
testing of an application is achieved).
Requirement Traceability assures good ‘Quality’ of the application as all the features are
tested. Quality control can be achieved as software gets tested for unforeseen scenarios with
minimal defects and all functional and non-functional requirements being satisfied.
Requirement Traceability Matrix aids for software application getting tested in the stipulated
time duration, the scope of the project is well determined and its implementation is achieved as
per the customer requirements and needs and cost of the project is well controlled.

Defect Leakages are prevented as a whole of the application is tested for its requirements.
Types of Traceability Matrix
Forward Traceability:
In ‘Forward Traceability’ Requirements to the Test cases. It ensures that the project progresses
as per the desired direction and that every requirement is tested thoroughly.

Backward Traceability:
The Test Cases are mapped with the Requirements in ‘Backward Traceability’. Its main purpose
is to ensure that the current product being developed is on the right track. It also helps to
determine that no extra unspecified functionalities are added and thus the scope of the project is
affected.

Bi-Directional Traceability:
(Forward + Backward): A Good Traceability matrix has references from test cases to
requirements and vice versa (requirements to test cases). This is referred to as ‘Bi-Directional’
Traceability. It ensures that all the Test cases can be traced to requirements and each and every
requirement specified has accurate and valid Test cases for them.
Examples of RTM
#1) Business Requirement:
BR1: Writing emails option should be available.
Test Scenario(technical specification) for BR1

TS1: Compose mail option is provided.

Test Cases:
Test Case 1 (TS1.TC1): Compose mail option is enabled and works successfully.
Test Case 2 (TS1.TC2): Compose mail option is disabled.
#2) Defects:
After executing the test cases if any defects are found that too can be listed and mapped with the
business requirements, test scenarios and test cases.

Example: If TS1.TC1 fails i.e. Compose mail option though enabled does not work properly
then a defect can be logged. Suppose the defect ID auto-generated or manually assigned number
is D01, then this can be mapped with BR1, TS1, and TS1.TC1 numbers.
Thus all requirements can be represented in a table format.
Business Requirement # Test Scenario # Test Case # Defects #

BR1 TS1 TS1.TC1 D01

TS1.TC2

BR2 TS2 TS2.TC1 D02

TS2,TC2 D03
TS2.TC3

BR3 TS3 TS1.TC1 NIL

TS2.TC1
TS3.TC1
TS3.TC2

Test coverage and Requirement Traceability

What is Test coverage?
Test coverage states which requirements of the customers are to be verified when the testing
phase starts. Test coverage is a term that determines whether the test cases are written and
executed ensure to test the software application completely, in such a way that minimal or NIL
defects are reported.

How to achieve Test Coverage?

The maximum Test Coverage can be achieved by establishing good ‘Requirement Traceability’.
  Mapping all internal defects to the test cases designed
 Mapping all the customer reported defects (CRD) to individual test cases for future regression
test suite
Types of Requirement Specifications
#1) Business Requirements:
The actual customers’ requirements are listed down in a document known as Business
Requirements Document (BRS). This BRS is minutely derived high-level requirement list,
after a brief interaction with the client.
It is usually prepared by ‘Business Analysts’ or the project ‘Architect’ (depending upon
organization or project structure). The ‘Software Requirement Specifications’ (SRS) document is
derived from BRS.

#2) Software Requirements Specification Document (SRS):

It is a detailed document which contains all the meticulous details of all functional and non-
functional requirements. This SRS is the baseline for designing and developing the software
application.

#3) Project Requirement Documents (PRD):

The PRD is a reference document for all the team members in a project to tell them exactly what
a product should do. It can be divided into the sections like Purpose of the product, Product
Features, Release Criteria and Budgeting & Schedule of the project.

#4) Use Case Document:

It is the document that helps in designing and implementing the software as per the business
needs. It maps the interactions between an actor and an event with a role that needs to be
performed to achieve a goal. It is a detailed step-by-step description of how a task needs to be
performed.

Example:
Actor: Customer
Role: Download Game
Game download is successful.

Use Cases may also be a part included in the SRS document as per organizations work process.

#5) Defect Verification Document:

It is documented containing all the details related to defects. The team can maintain a ‘Defect
Verification’ document for fixing and retesting of the defects. The testers can refer ‘Defect
Verification’ document, when they want to verify if the defects are fixed or not, retest defects on
different OS, device, different system configuration etc.

The ‘Defect Verification’ document is handy and important when there are a dedicated defect
fixing and verification phase.
#6) User Stories:
The user story is a primarily used in ‘Agile’ development to describe a software feature from an
end-user perspective. User stories define the types of users and in what way and why they want a
certain feature. The requirement is simplified by creating user stories.

Currently, all of the software industries are moving towards the use of User Stories and Agile
Development and corresponding software tools for recording the requirements.

Challenges for Requirement collection

1) The requirements collected must be detailed, unambiguous, accurate and well specified. But
there is NO appropriate measure for calculating these details, unambiguousness, accuracy and
well-defined specifications that are needed for the requirement collection.
2) The interpretation of the ‘Business Analyst’ or ‘Product Owner’ whoever provides the
requirements information is critical. Similarly, the team who receives the information has to raise
appropriate clarifications in order to understand the expectations of the stakeholder’s.
The understanding must be in sync with both the business needs and the actual efforts required
for application implementation.
3) The information should also be derived as per the point of view of the end user.
4) Stakeholders’ state conflicting or contradicting requirements at different times.
5) End-user point-of-view is not considered due to multiple reasons and further stakeholders
think they “completely” understand what is required for a product, which generally is not the
case.
6) Resources lack skills for application developed.
7) Frequent ‘Scope’ changes of application or priority change for modules.
8) Missed, implicit or undocumented requirements.
9) Inconsistent or vague requirements determined by the customers.
10) The conclusion of all the factors stated above is that the ‘Success’ or ‘Failure’ of a project
depends considerably on a requirement.
How Requirement Traceability Can Help
#1) Where is a requirement implemented?
Example:
Requirement: Implement ‘Compose mail’ Functionality in a mail application.
Implementation: Where on the main page the ‘Compose mail’ button should be placed and
accessed.
#2) Is a requirement necessary?
Example:
Requirement: Implement ‘Compose mail’ Functionality in a mail application to certain users
only.
Implementation: As per user access rights if the email inbox is ‘Read-only’ then in this case
‘Compose mail’ button won’t be required.
#3) How do I interpret a requirement?
Example:
Requirement: ‘Compose mail’ Functionality in a mail application with fonts and attachments.
Implementation: When ‘Compose mail’ is clicked what all features should be provided?
 Text Body to write emails and edit in different font types and also bold, italics, underline them
 Types of attachments (Images, documents, other emails etc.)
 Size of attachments(Maximum size allowed)
Thus the requirements get broken down to sub-requirements.

#4) What design decisions affect the implementation of a requirement?

Example:
Requirement: All elements ‘Inbox’, ‘Sent mail’, ‘Drafts’, ‘Spam’ , ‘Trash’ , etc. should be
clearly visible.
Implementation: The elements to be visible should be displayed in ‘Tree’ format or ‘Tab’
format.
#5) Are all requirements allocated?
Example:
Requirement: ‘Trash’ mail option is provided.
Implementation: If the ‘Trash’ mail option has been provided, then the ‘Delete’ mails option
(requirement) must be implemented initially and should be working accurately. If the ‘Delete’
mail option is working properly, then only the deleted emails will be collected in ‘Trash’ and
implementing the ‘Trash’ mail option(requirement) will make sense(will be useful).
Advantages of RTM and Test Coverage
1) The build developed and tested has the required functionality which meets the ‘customers’/
‘users’ needs and expectations. The customer must get what he wants. To surprise the customer
with an application that does not do what it’s expected to do is not a satisfying experience for
anyone.
2) The end product (software application) developed and delivered to the customer must
encompass only the functionality that’s needed and expected. Extra features provided in the
software application may seem attractive initially until there is an overhead of time, money, and
effort to develop it.
The extra feature may also become a source of defects, which can cause problems for a customer
after installation.

3) Developer’s initial task gets defined clearly as they work first on implementing the
requirements, which are of high- priority, as per the customer requirement. If customer’s high–
priority requirements are clearly specified, then those code components can be developed and
implemented on first priority.
Thus it is ensured that the chances of the end-product being shipped to the customer is as per the
topmost requirements and is on schedule.

4) Testers verify first the most important functionality implement by developers. As the
verification (testing) of the priority software component is done first it helps to determine when
and if the first versions of the system are ready to be released.
5) Accurate test plans, test cases are written and executed which verify that all of the application
requirements are implemented correctly. Test cases mapping with the requirements helps to
ensure that no major defects are missed. It further helps in implementing a quality product as per
the customer expectations.
6) In case there is ‘change request’ from the client, all of the application components that are
affected by the change request get modified and nothing gets overlooked. This further enhances
in evaluating, the impact a change request does to the software application.
7) A seemingly simple change request might implicate modifications that need to be done to
several parts of the application. It’s better to derive a conclusion on how much efforts will be
required before agreeing to make the change.
Challenges in Test Coverage
#1) Good Communication channel:
If there are any changes which are suggested by the stakeholders, the same needs to be
communicated to the development and testing teams in the earlier phases of development.
Without this on time development, testing of application and capturing /fixing of defects cannot
be ensured.
#2) Prioritizing the Test Scenarios is important:
Identifying which are high-priority, complex, and important test scenarios is a difficult task.
Trying to test all of the test scenarios is almost an unachievable task. The goal of testing the
scenarios must be very clear from the business and end-user point of view.
#3) Process Implementation:
Testing process must be clearly defined considering the factors like technical infrastructure and
implementations, team skills, past experiences, organizational structures and processes followed,
project estimations related to cost, time and resources and location of the team as per the time
zones.

A uniform processes implementation considering the mentioned factors ensures every individual
concerned with the project is on the same page. This helps in a smooth flow of for all the
processes related to application development.

#4) Availability of Resources:

Resources are of two types, skilled-domain specific testers and the testing tools used by the
testers. If the testers have proper knowledge of the domain they can write and implement
effective test scenarios and scripts. To implement these scenarios and scripts the testers should
be well equipped with appropriate ‘Testing Tools’.

Good implementation and on time delivery of the application to the customer can be ensured by
the only skilled tester and appropriate testing tools.

#5) Effective Test Strategy implementation:

‘Test strategy’ in itself is a big and a separate topic of discussion. But here for ‘Test Coverage’
an effective test strategy implementation ensures that the ‘Quality’ of the application
is good and it is maintained over the period of time everywhere.
An effective ‘Test Strategy’ plays a major role in planning ahead for all kinds of critical
challenges, which further helps in developing a better application.

How to Create a Requirements Traceability Matrix

To being with we need to know exactly what is it that needs to be tracked or traced.

Testers start writing their test scenarios/objectives and eventually the test cases based on some
input documents – Business requirements document, Functional Specifications document and
Technical design document (optional).
Let’s suppose, the following is our Business requirements document (BRD): (Download this
sample BRD in excel format)
(Click any image to enlarge)
The below is our Functional Specifications document (FSD) based on the interpretation of the
Business requirements document (BRD) and the adaptation of it to computer applications.
Ideally, all the aspects of FSD need to be addressed in the BRD. But for simplicity’s sake, I have
only used the points 1 and 2.

Sample FSD from Above BRD: (Download this sample FSD in excel format)
Note: the BRD and FSD are not documented by QA teams. We are mere, the consumers of the
documents along with the other projects teams.
Based on the above two input documents, as the QA team, we came up with the below list of
high-level scenarios for us to test.

Sample Test Scenarios from the Above BRD and FSD: (Download this sample test
Scenarios file)
Once we arrive here, now would be a good time to start creating the requirements traceability
matrix.

I personally prefer a very simple excel sheet with columns for each document that we wish to
track. Since the business requirements and functional requirements are not numbered uniquely
we are going to use the section numbers in the document to track. (You can choose to track
based on line numbers or bulleted-point numbers etc. depending on what makes the most sense
for your case in particular.)

Here is how a simple Traceability Matrix would look for our example:

The above document establishes a trace between, the BRD to FSD and eventually to the test
scenarios. By creating a document like this, we can make sure every aspect of the initial
requirements has been taken into consideration by the testing team for creating their test suites.

You can leave it this way. However, in order to make it more readable, I prefer including the
section names. This will enhance understanding when this document is shared with the client or
any other teams.

The outcome is as below:

Again, the choice to use the former format or the later is yours.

This is the preliminary version of your TM but generally, does not serve its purpose when you
stop here. Maximum benefits can be reaped from it when you extrapolate it all the way to
defects.
Let’s see how.
For each test scenario that you came up with, you are going to have at least 1 or more test cases.
So, include another column when you get there and write the test case IDs as shown below:

At this stage, the Traceability Matrix can be used to find gaps. For example, in the
above Traceability Matrix, you see that there are no test cases written for FSD section 1.2.

As a general rule, any empty spaces in the Traceability Matrix are potential areas for
investigation. So a gap like this can mean one of the two things:
1. The test team has somehow missed considering the “Existing user” functionality.
2. The “Existing user” functionality has been deferred to later or removed from the application’s
functionality requirements. In this case, the TM shows an inconsistency in the FSD or BRD –
which means that an update on FSD and/or BRD documents should be done.
If it is scenario 1, it will indicate the places where the test team needs to work some more to
ensure 100% coverage.

In scenarios 2, TM not just shows gaps it points to incorrect documentation that needs immediate
correction.
Let us now expand the TM to include test case execution status and defects.

The below version of the Traceability Matrix is generally prepared during or after test
execution:

Download requirements traceability matrix template:

=> Traceability Matrix Template in Excel Format
Important Points to Note
The following are the important points to note about this version of the Traceability Matrix:

1) The execution status is also displayed.  During execution, it gives a consolidated snapshot of
how work is progressing.
2) Defects: When this column is used to establish the backward traceability we can tell that the
“New user” functionality is the most flawed. Instead of reporting that so and so test cases failed,
TM provides a transparency back to the business requirement that has most defects thus
showcasing the Quality in terms of what the client desires.
3) As a further step, you can color code the defect ID to represent their states. For example,
defect ID in red can mean it is still Open, in a green can mean it is closed. When this is done, the
TM works as a health check report displaying the status of the defects corresponding to a certain
BRD or FSD functionality is being open or closed.
4) If there is a technical design document or use cases or any other artifacts that you would like
to track you can always expand the above-created document to suit your needs by adding
additional columns.
To sum up, RTM helps in:
1. Ensuring 100% test coverage
2. Showing requirement/document inconsistencies
3. Displaying the overall defect/execution status with a focus on business requirements.
 4. If a certain business and/or functional requirement were to change, a TM helps estimate or
analyze the impact on the QA team’s work in terms of revisiting/reworking on the test cases.
Additionally,
1. A Traceability Matrix is not a manual testing specific tool, it can be used for automation projects
as well. For an automation project, the test case ID can indicate the automation test script
name.
2. It is also not a tool that can be used just by the QAs. The development team can use the same to
map BRD/FSD requirements to blocks/units/conditions of code created to make sure all the
requirements are developed.
3. Test management tools like HP ALM come with the inbuilt traceability feature.
An important point to note is that the way you maintain and update your Traceability Matrix
determines the effectiveness of its use. If not updated often or updated incorrectly the tool is a
burden instead of being a help and creates the impression that the tool by itself is not worthy of
using.
Conclusion
Requirement Traceability Matrix is the means to map and trace all of the client’s requirements
with the test cases and discovered defects. It is a single document which serves the main
purpose that no test cases are missed and thus every functionality of the application is covered
and tested.
Good ‘Test Coverage’ which is planned ahead of time prevents repetitive tasks in testing phases
and Defect leakages. A high defect count indicates that testing is done well and thus ‘Quality’ of
the application is going up. Similarly, a very low defect count indicates testing is not done up to
the mark and this hampers the ‘Quality’ of the application in a negative way.

If the Test coverage is done thoroughly then a low defect count can be justified and this defect
count can be considered as supporting statistics and not a primary one. Quality of an application
is termed as ‘Good’ or ‘Satisfying’ when the test coverage is maximized and defect count is
minimized.

About the Author: STH team member Urmila P. is an experienced QA Professional with high-

quality testing and issue tracking skills.
Have you created a Requirement Traceability Matrix in your projects? How similar or
different is it from what we have created in this article? Please share your experiences,
comments, thoughts, and feedback on this article through your comments.
 Share148

The Business Analysis Process: 8 Steps to Being an

Effective Business Analyst
In: BA Roles and Responsibilities, Plan Your Business Analysis Approach By: Laura Brandenburg

Tweet
Share
Pin
Being assigned to a new project is an exciting time as a business analyst, but it
can also be nerve-wracking. You might be wondering what exactly is expected of
you, what deliverables you should be creating, and how to guarantee success on
your project.

In this article, you’ll learn about the 8-step business analysis process that you
can apply whether you are in an agile environment or a traditional one,
whether you are purchasing off-the-shelf software or building custom code,
whether you are responsible for a multi-million dollar project or a one-week
project.

Depending on the size and complexity of your project, you can go through these
steps quickly or slowly, but to get to a successful outcome you must go through
them.

(We cover each of the 8 steps in even more detail in our BA Essentials Master
Class – in fact, each step gets an entire lesson in this virtual, self-study course.)

First, take a look at this process flow below which shows how the 8 steps fit
together and how you might iterate through them on a typical business analyst
project.
Now let’s look at each of the 8 steps in more detail.

Step 1 – Get Oriented

Often as business analysts we are expected to dive in to a project and start
contributing as quickly as possible to make a positive impact. Sometimes the
project is already underway. Other times there are vague notions about what the
project is or why it exists. We face a lot of ambiguity as business analysts and it’s
our job to clarify the scope, requirements, and business objectives as quickly as
possible.
 But that doesn’t mean that it makes sense to get ourselves knee-deep into the
detailed requirements right away. Doing so very likely means a quick start in the
wrong direction.

Taking some time, whether that’s a few hours, few days, or at the very most a
few weeks, to get oriented will ensure you are not only moving quickly, but
also able to be an effective and confident contributor on the project.

Your key responsibilities in this step include:

 Clarifying your role as the business analyst so that you are sure to create
deliverables that meet stakeholder needs.
 Determining the primary stakeholders to engage in defining the project’s
business objectives and scope, as well as any subject matter experts to be
consulted early in the project.
 Understanding the project history so that you don’t inadvertently repeat work
that’s already been done or rehash previously made decisions.
 Understanding the existing systems and business processes so you have a
reasonably clear picture of the current state that needs to change.
This is where you learn how to learn what you don’t know you don’t know, so to
speak. This step gets you the information you need to be successful and
effective in the context of this particular project.

Step 2 – Discover the Primary Business Objectives

It’s very common for business analysts and project managers to jump right in to
defining the scope of the project. However, this can lead to unnecessary
headaches. Uncovering and getting agreement on the business needs early
in a project and before scope is defined is the quickest path forward to a
successful project.

Your key responsibilities in this step include:

 Discovering expectations from your primary stakeholders – essentially

discovering the “why” behind the project. (Our BA Essentials Master Class
covers 7 different business analysis techniques that can be used as part of this
discovery.)
 Reconciling conflicting expectations so that the business community begins the
project with a shared understanding of the business objectives and are not
unique to one person’s perspective.
 Ensuring the business objectives are clear and actionable to provide the project
team with momentum and context while defining scope and, later on, the detailed
requirements.
Discovering the primary business objectives sets the stage for defining scope,
ensuring that you don’t end up with a solution that solves the wrong problem or,
even worse, with a solution that no one can even determine is successful or not.

Step 3 – Define Scope

A clear and complete statement of scope provides your project team the go-
forward concept to realize the business needs. Scope makes the business
needs tangible in such a way that multiple project team participants can
envision their contribution to the project and the implementation. 

Your key responsibilities in this step include:

 Defining a solution approach to determine the nature and extent of technology

and business process changes to be made as part of implementing the solution
to the primary business objectives.
 Drafting a scope statement and reviewing it with your key business and
technology stakeholders until they are prepared to sign-off or buy-in to the
document.
 Confirming the business case to ensure that it still makes sense for your
organization to invest in the project.
Scope is not an implementation plan, but it is a touchstone guiding all of the
subsequent steps of the business analysis process and tasks by other project
participants.

Step 4 – Formulate Your Business Analysis Plan

Your business analysis plan will bring clarity to the business analysis process
that will be used to successfully define the detailed requirements for this project.
Your business analysis plan is going to answer many questions for you and your
project team.

Your key responsibilities in this step include:

 Choosing the most appropriate types of business analysis deliverables, given the
project scope, project methodology, and other key aspects of the project context.
 Defining the specific list of business analysis deliverables that will completely
cover the scope of the project and identifying the stakeholders who will be part of
the creation and validation of each deliverable.
 Identifying the timelines for completing the business analysis deliverables.
In the absence of defining a credible and realistic plan, a set of
expectations may be defined for you, and often those expectations are
unrealistic as they do not fully appreciate everything that goes into defining
detailed requirements.

Step 5 – Define the Detailed Requirements

Detailed requirements provide your implementation team with the information
they need to implement the solution. They make scope implementable.

Without clear, concise, and actionable detailed requirements,

implementation teams often flounder and fail to connect the dots in such a
way that delivers on the original business case for the project.  

Your key responsibilities in this step include:

 Eliciting the information necessary to understand what the business community

wants from a specific feature or process change.
 Analyzing the information you’ve discovered and using it to create a first draft of
one or more business analysis deliverables containing the detailed requirements
for the project.
 Reviewing and validating each deliverable with appropriate business and
technology stakeholders and asking questions to fill in any gaps.
Effective business analysts consciously sequence your deliverables to be as
effective as possible in driving the momentum of the project forward. Paying
attention to the project’s critical path, reducing ambiguity and complexity, and
generating quick wins are all factors to consider when sequencing your
deliverables.

Step 6 – Support the Technical Implementation

On a typical project employing a business analyst, a significant part of the
solution involves a technical implementation team building, customizing, and/or
deploying software. During the technical implementation, there are many
worthwhile support tasks for you to engage in that will help drive the success of
the project and ensure the business objectives are met.
 Your key responsibilities in this step include:

 Reviewing the solution design to ensure it fulfills all of the requirements and
looking for opportunities to meet additional business needs without increasing the
technical scope of the project.
 Updating and/or repackaging requirements documentation to make it useful for
the technology design and implementation process.
 Engaging with quality assurance professionals to ensure they understand the
business context for the technical requirements. This responsibility may include
reviewing test plans and/or test cases to ensure they represent a clear
understanding of the functional requirements.
 Making yourself available to answer questions and help resolve any issues that
surface during the technical design, technical implementation, or testing phases
of the project.
 Managing requirements changes to ensure that everyone is working from up-to-
date documentation and that appropriate stakeholders are involved in all
decisions about change.
 When appropriate, leading user acceptance testing efforts completed by the
business community to ensure that the software implementation meets the needs
of business end users.
All of these efforts help the implementation team fulfill the intended benefits
of the project and ensure the investment made realizes a positive return.

Step 7 – Help the Business Implement the Solution

Your technology team can deliver a beautiful shiny new solution that theoretically
meets the business objectives, but if your business users don’t use it as
intended and go back to business-as-usual, your project won’t have
delivered on the original objectives. Business analysts are increasingly getting
involved in this final phase of the project to support the business.

Your key responsibilities in this step may include:

 Analyzing and developing interim and future state business process

documentation that articulates exactly what changes need to be made to the
business process.
 Training end users to ensure they understand all process and procedural
changes or collaborating with training staff so they can create appropriate
training materials and deliver the training.
 Collaborating with business users to update other organizational assets impacted
by the business process and technology changes.
 This step is all about ensuring all members of the business community are
prepared to embrace the changes that have been specified as part of the project.

Step 8 – Assess Value Created by the Solution

A lot happens throughout the course of a project. Business outcomes are
discussed. Details are worked through. Problems, big and small, are solved.
Relationships are built. Change is managed. Technology is implemented.
Business users are trained to change the way they work.

In this flurry of activity and a focus on delivery, it’s easy to lose track of the big
picture. Why are we making all these changes and what value do they deliver for
the organization? And even more importantly, are we still on track? Meaning, is
the solution we’re delivering actually delivering the value we originally
anticipated?

Nothing creates more positive momentum within an organization than a

track record of successful projects. But if we don’t stop and assess the value
created by the solution, how do we know if we are actually operating from a track
record of success?

Your key responsibilities in this step may include:

 Evaluating the actual progress made against the business objectives for the
project to show the extent to which the original objectives have been fulfilled.
 Communicating the results to the project sponsor, and if appropriate, to the
project team and all members of the organization.
 Suggesting follow-up projects and initiatives to fully realize the intended business
objectives of the project or to solve new problems that are discovered while
evaluating the impact of this project.
After completing this step, it’s likely you’ll uncover more opportunities to improve
the business which will lead you to additional projects. And so the cycle begins
again!

"Business analysis is the set of tasks and techniques used to work as a liaison
among stakeholders in order to understand the structure, policies, and
operations of an organization, and to recommend solutions that enable the
organization to achieve its goals."
- BABOK V2, page 3.
 In order to achieve the objective of enabling the organization to achieve its goals, the
business analyst engages in Requirements Elicitation. The following is extracted from
the BABOK:
"The definition of elicitation is:

1. to draw forth or bring out (something latent or potential)

2. to call forth or draw out (as information or a response)

These definitions highlight the need to actively engage the stakeholders in defining
requirements."
- BABOK V2 (page 53)
The implication is that requirements come from subject matter experts (SMEs) and that
the BA must extract them or draw them forth. But where did the SMEs get the
requirements? Did they make them up? Do they represent their personal preferences?
If the answer is yes to either, then requirements become virtually untouchable
statements that can only be verified by the person who verbalized them. If the answer is
yes, then a requirement can change at the whim of its originator.
Requirements are not and should not represent personal preferences that can't be
independently verified. Requirements must be owned by the organization. But what do
they represent? Let's again turn to the BABOK.
"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)."

- BABOK V2 (pages 4-5)

The difficulty with these definitions is that they portray requirements as already existing
prior to the start of the BA's work. The BA's challenge, then, is to somehow pry or draw
out the requirement from its source-the stakeholder, the contract, the standard, or other
imposed document. They imply that requirements are the output of some other process
but somehow they were never properly recorded. So, in rides the BA to record them. If
that were truly the case, then requirements would be captured correctly the first time, for
the most part, because the stakeholders already know them. Requirements would be
unlikely to change.
 We know that this is not consistent with reality. Requirements are often wrong,
irrelevant, or incomplete, and not because they were misunderstood. They were wrong
from the start. In addition, requirements statements tend to change frequently and
continuously. Why would that be? A reasonable conclusion is that the requirements that
we are trying to elicit (draw out) don't actually exist yet. It is the process of drawing them
out that is making people think about them-possibly for the first time. That's why they
change so often. In other words, people are designing their process on the fly and in an
unstructured and unreliable manner.

r how hard individuals work, they cannot overcome a flawed process design, much less the burden of no design at al
ammer, The Agenda.

So what should requirements be? As per the definition, they represent a condition
required to solve a problem or achieve a solution. Or they are constraints imposed from
the outside. If a requirement is something needed to solve a problem, then we need to
have developed the solution to the problem. In other words, we need to have gone
through proper design.
This leads to an alternative way to view a requirement-as an output of process design.
True Requirements can only be produced if and while a process is properly designed.
That means that in order for a business analyst to achieve the intent of business
analysis-recommend solutions that enable the organization to achieve its goals-the BA
must engage the Requirements Team in designing the business process. Design is the
activity. It must be carried out overtly and systematically and not as a side-effect of
elicitation. Requirements are the output. They must be overtly documented in the form
of a business blueprint.

ents should not be drawn forth. They should be hammered out as part of a structured process of design activity.

Process Design Is The Future For Business Analysis

When the going gets tough, the middleman is the first to go. The BA, today, plays too
much of a middleperson role. The future BA will be a process design master that leads
SMEs and other stakeholders in process design. The endgame is a better process, not
just requirements. And a better process requires a structured approach to process
design.
The future business analyst will lead a structured design process that produces
a process blueprint which contains structured requirements. The blueprint will represent
organization needs that can be independently verified for correctness and
completeness. The blueprint will separate out any personal preferences from process
needs.
 The separation of personal preferences is important because these account for many of
the unnecessary conflicts that arise in requirements statements. Of course, in order to
achieve this a few role changes are required.
The business analyst will no longer be a go-between. Instead she will lead a cross-
functional team in the all important activity of designing the business. Today, the BA is
master of few things. A BA knows project management but not as well as a project
manager. The BA understands technology but not as well as the developer. The BA
knows the target business domain but not as well as the subject matter experts. Today
the BA is a jack of too many trades and a master of no particular one. This presents a
clear and present danger for the BA. In the future, the BA will be the master in process
design.
The process owner role needs to disappear. Firstly, few organizations have successfully
implemented such a role. Think of ownership and what it implies. An owner can do what
he likes to what he owns. That implies that a process owner can do whatever he likes to
his process. But value delivering processes are cross-functional with functional owners.
That leads to conflict. It leads to processes with two sets of owners, one for the cross-
functional process, and one for each functional component. However, it is the
organization that should own the business process. Process owners need to be
replaced by process governors. A governor manages within a given framework. This
makes more sense. The organization owns the process and defines the performance
framework for it. The process governor manages that process within the given
framework. He is not completely free to do whatever he wants. He must manage within
boundaries.
Subject Matter Experts are not the customer. The customer does not change based on
perspective. The external customer is the customer. A business process should be
designed to deliver value to the external customer. The SMEs are participants of the
business process. When the SME or other internal stakeholder becomes a customer,
the risk is that their personal needs hijack the true needs. So SMEs,, developers, and
other stakeholders become key process participants. Like the process governor, internal
participants need to act in accordance with the process blueprint. That ensures that
everyone is aligned to the process blueprint which represents the intent of the process.

se is a business process blueprint?

ho are aligned around a common goal but lack the discipline of a well-designed process will go nowhere ... likewise t
process has no chance of survival when people aren't aligned around the process and its goals."
ammer, The Agenda.

Conclusion
Design is the defining discipline of this decade. Structured Process Design is the new
discipline whose mastery will set the business analyst apart. Process design will
produce, as an output, the business process blueprint, which will contain structured
requirements. These will be the foundation for developing strong and useful software
applications. Process Masteryis the key future capability that will distinguish
the business analyst from other roles.
Elicitation is a middleperson activity that will disappear and no one will mourn its
passing. Incorrect, incomplete, irrelevant, and conflicting requirements will be
dramatically reduced. Requirements will be independently verified and first pass quality
will rise. More projects will be a business success and they will deliver more stakeholder
value.
Roles will change to make accountability clear. Teamwork will need to rise. The BA will
be the design team leader with SMEs, developers, and other stakeholders as team
members. The process blueprint will become a persistent, reusable organization
resource for managing process performance rather than a temporary throw-away
project resource.
A focus away from elicitation to design will yield benefits for everyone. It will increase
productivity and more importantly it will increase value delivered to the organization. Of
course, the shift has to be driven by someone. If you like your current job as a
requirements order taker, then you don't need to take any action. But if you prefer the
more proactive role of Process Design Master, then you should take the initiative in
driving the future, if you haven't already done so.

Question :- What is Requirement Elicitation? What techniques are used in

the process?
Answer:- Introduction to Elicitation, Why Elictation, Method of Elictation.

Topic - Business Analysis Analytical Techniques

Answer:- Objective – you will learn what is the starting point of your
analysis.
What are the factors to consider during analysis?
When to use what technique?

PESTLE- Political, sociological, Economic, Technological, Legal,

Environmental
MOST- Mission, Objectives, Strategies, Tactics
SWOT-Strength, Weaknesses, Opportunities, Threats