Business Analyst

Hitesh Puri
Software Development Life Cycle (SDLC)

• SDLC is a process used for software

development.
• It consists of a plan describing how to develop,
replace and maintain or enhance software.
• The life cycle defines a methodology for
improving the quality of software and the
overall development process.
Step 1 - Requirement gathering & Analysis
• Requirement gathering, analysis and planning is done by the stakeholders like
Project Manager, Business Analyst, Technical Leads of the team with inputs
from the customer, the sales department and subject matter experts.
• There are many ways to gather requirements like structured and unstructured
interviews, surveys, workshops, document analysis, observations etc.
• This information is then used to plan the basic project approach and to
conduct product feasibility.
• Quality assurance and identification of the risks associated with the project is
also done in the planning stage. The outcome is to define the various technical
approaches that can be followed to implement the project successfully with
minimum risks.
• Business Requirement Document is prepared which gives the high level view of
the requirement and what client wants to achieve with it.
 Step 2 - Defining Requirements
• After requirement analysis is done the next
step is to clearly define and document the
product requirements and get them approved
from the customer and project manager.
• Software Requirement Specification document
which consists of all the product requirements
to be designed and developed during the
project life cycle.
 Step 3 - Designing the Product Architecture
• SRS document refers product architecture. Based on the requirements
specified, usually more than one design approach for the product
architecture is proposed and documented in a DDS - Design Document
Specification.
• DDS is reviewed by all the important stakeholders and based on
various parameters as risk assessment, product robustness, design
modularity, budget and time constraints, the best design approach is
selected for the product.
• A design approach clearly defines all the architectural modules of the
product along with its communication and data flow representation
with the external and third party modules (if any). The internal design
of all the modules of the proposed architecture should be clearly
defined with the minutest of the details in DDS.
Step 4 - Building or Developing the Product

• At this point actual development starts and the

product is built. The programming code is generated
as per DDS during this stage. If the design is
performed in a detailed and organized manner, code
generation can be accomplished without much
hassle.
• Developers must follow the coding standards defined
by their organization.
• Developer perform Unit testing to test the
acceptance criteria of the requirements.
 Step 5 - Testing the Product
• This stage is usually a subset of all the stages,
the testing activities are mostly involved in all
the stages of SDLC. However, this stage refers
to the testing only stage of the product where
product defects are reported, tracked, fixed and
retested, until the product reaches the quality
standards defined in the SRS.
• System Integration testing, regression testing is
done to check the quality of system developed.
 Step 6 - Deployment in the Market and
Maintenance
• Once the product is tested and ready to be deployed it is
released formally to client. Sometimes product
deployment happens in stages as per the business strategy
of that organization. The product may first be released in a
limited segment and tested in the real business
environment (UAT- User acceptance testing).
• Then based on the feedback, the product may be released
as it is or with suggested enhancements in the targeting
market segment. After the product is released in the
market, its maintenance is done for the existing customer
base.
 SDLC - Waterfall
• Phases in Waterfall model are −
– Requirement Gathering and analysis − All possible requirements of the system are
captured in this phase and documented in a requirement specification document.
– System Design − The requirement specifications are translated to the system design (High
Level and Low Level documents are prepared). This system design helps in specifying
hardware and system requirements and helps in defining the overall system architecture.
– Implementation − The system is developed in small programs called units, which are
integrated in the next phase. Each unit is developed and tested for its functionality, which
is referred to as Unit Testing.
– Integration and Testing − All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system is
tested for any faults and failures. This is called System Integration Testing.
– Deployment of system − Once the functional and non-functional testing is done; the
product is deployed in the client environment. User Acceptance Testing is done in this
phase.
– Maintenance − Fixes of issues, patches releases are part of maintenance.
 Artifacts
Artifact Prepared By Sign Off
Statement of Work (SOW) Project Manager (PM) Client
BRD BA+PM Client + PM
SRS Technical Architect Tech Arch + DBA + PM
FRD Business Analyst (BA) Client + PM
Process Mapping Business Analyst (BA) Project Manager (PM)
Product Backlog Product Owner Client + PM
User Stories Business Analyst Client + Product Owner + PM
Test Cases (SIT,UAT) BA + Testers BA + PM
RTM Business Analyst (BA) PM+BA
HLD Technical Architect Tech Arch + DBA + PM
LLD Tech Lead Technical Arch
 Agile
• Agile Development is an umbrella term for
several iterative and incremental software
development methodologies like
– Extreme Programming (XP)
– Scrum
– Feature-Driven Development (FDD).
 Scrum
• Scrum is an Agile framework for executing
complex projects.
• The big advantage is to get constant feedback
in from client and deliver quality at the end of
every sprint.
• It is easy to incorporate the adhoc
requirement from the client.
 How Scrum works
– A product owner creates a prioritized list of requirements called a product backlog.
– During sprint planning, the scrum team pulls a small chunk from the top of that list
which is considered as sprint backlog, and decides how to implement those pieces.
– The team has a certain amount of time called sprint (usually two to four weeks) to
complete its work. But it meets each day for 15 mins to assess its progress called
daily scrum meeting.
– Along the way, the Scrum Master keeps the team focused on its goal.
– At the end of the sprint, the work should be potentially shippable: ready to hand to
a customer. The completeness of product is decided by Product Owner in the Demo
meeting. If he thinks that requirements are still not met then he can reject the
output.
– The sprint ends with a sprint review and retrospective meeting.
– As the next sprint begins, the team chooses another chunk of the product backlog
and begins working again.
 Roles in Scrum

• Product owner – He knows that the requirement and list

them in priority after discussing with client. He maintains
that priority list as Product Backlog. At the end of sprint,
he decides if the product is ready to deliver or not.
• Scrum master – He takes care of compliance followed by
the scrum team in the execution of the project. He
protects the team from external noises.
• Development team – This includes Developers, Tester, BA
etc.
 Scrum Artifacts
• Product backlog
• Sprint backlog
– User Stories with Acceptance criteria
• Product increment
• Other artifacts
– Sprint burn-down chart
– Release burn-up chart
– Definition of done (DoD)
– Velocity
 Tools Used
• Jira – For maintaining user stories, Issue
logging, velocity and burn down charts
• Visio – For flow charts
• Balsamiq Mockup – For wireframes
• MS Excel – For use cases, flow charts,
wireframes, data analysis
• MS Word – User Guide, FRD
Thank you