1

Business Analysis

2

What happens…

3

Example

The year is 1980

How were cash withdrawals made ?

How were cash deposits made ?

4

The Ideal Scenario

Business Need/

Business Problem

Vision Document/

Business Case

Business Requirement

Document -> RFPProposal

Functional analysis & Design - > SRS

Technical analysis & Design

Development

Testing

Production

5

Vision Document/Business CaseVision document is a guideline document that describes the overall vision / plan for

the project / system

It identifies alternatives and risks associated with the project and presents a

budget for the detailed planning phase for the stakeholders to approve.

Business Case justifies the need for the project or task.

Whenever resources such as money or effort are spent, they should be in support

of a specific business need.

The problem of manually handling documents within the bank

affects bank employees

the impact of which is inability to track & find information at the right time, wastage of storage area for past records

a successful solution would be

to implement an electronic document management and scanning solution, to maintain e-records of all mandatory documents as per bank regulations. Information can be easily tracked and is readily accessible to all concerned authorities

What is a Business Requirements Document?What it is

An overview of the business problem(s) that needs to be solved

A guideline for detailed requirement gathering

A document defining the business need for a project; possibly with

a business case

A document identifying the stakeholders/users benefiting from the

project

A snapshot of the dependencies on other applications in the

environment

What it is not

BRD is not a base for the technical team to code – an SRS deals

with that level of detail

BRD does not delve into all minute functional details like data

elements, layouts etc

7

Objectives of a BRD

To lay out the project objectives

To clearly set & define expectations with the

stakeholders in terms of the end-state

To define the in-scope and out-of-scope areas

for the solution/project

To provide a guideline for the project managers

in order to plan for the project development

lifecycle and goals

To define the acceptance criteria for the

stakeholders

8

When do we create a BRD?

A BRD will typically be created when:

• Project is in its initial stages

• Client is in the process of defining the scope of the project/solution

• There is a lack of properly articulated requirements from the client

• Solution is not clearly identified, and possible options need to be proposed

9

What does a BRD contain?

• Table of Contents*

• Purpose & Scope of the document

• Intended Audience

• Project Background & Rationale

• Problem Description

• Stakeholder Needs

• Scope & Features

• Out of scope

• Assumptions & Dependencies

• Key functional requirements

• Key non-functional requirements

• Any other relevant details

* Add / remove sections as per project situation

10

Example

60% of the errors that show up during a system's life have their origin in the requirements gathering &

specification stage (Davis, 1990; Schach, 1992)

ABC Bank has approached Unistanz to create an ATM software

11

Requirements Gathering

2 Fix system boundaries Understand the overall process.

Understand where the intended system fits in with respect to the

overall process how does the system integrate with the business

processes, how it fits into the larger picture

3 Identify the customer End users of application – directly / indirectly impacted by the system

• Users – who directly use the system to perform their work

• Management – who authorize, request, budget and approve

• Customers – who receive output from the system e.g. employees

get paychecks from payroll system

• Internal customers / admin – who maintain the system

4Interview / discuss

with usersDiscuss requirements in detail with users, and share information with

all required stakeholders

1Background work

Obtain theoretical business knowledge – you can’t design an

accounting system if you don’t know basics of accounting

Study existing systems & environment and documentation

5 Prioritize requirements Classify as high, medium, and low priority, giving the business

customers and project team the information they need to ensure that

the most important requirements are incorporated

12

Requirements Gathering

6 Document

requirementsTry to make use of requirement elicitation tools like process flows,

transition process diagrams, prototypes (if applicable)

7 Discuss with relevant

stakeholders, signoff

Discuss the documented requirements with the relevant stakeholders

and obtain concurrence. Ensure that the document is read properly

by all parties and sign off is obtained.

8 Requirements

ManagementPost sign off, any amendments to the requirements during the project

lifecycle should be discussed with the project team and flagged off to

the manager. If identified as a change request, the CR should be

raised with supporting reasons, and appended to the original BRD.

Key elements of requirements:

Users - the ‘who’, Activities – the ‘how’, artifacts – the ’what’, workflows – the ‘when’

What is a Software Requirement Specification Document?

What it is

An SRS is basically an organization's understanding (in

writing) of a customer or potential client's system

requirements and dependencies at a particular point in

time (usually) prior to any actual design or development

work.

It documents the functional & non functional requirements

14

Objectives of a SRS

An SRS is the customer's assurance that the development organization

understands the issues or problems to be solved and the software behavior

necessary to address those problems.

To identify the solution component parts - It decomposes the problem into

component parts. The simple act of writing down software requirements in a well-

designed format organizes information, places borders around the problem,

solidifies ideas, and helps break down the problem into its component parts in an

orderly fashion.

To serve as input for design specification - the SRS serves as the parent

document to subsequent documents, such as the software design specification,

test cases etc.

To serve as a product validation check

15

Benefits of creating a SRS?

So, what does a great SRS provide to an

organization/client:

• Establish the basis for agreement between the customers

and the suppliers on what the software product is to do.

• To revalidate cost and efforts

• Provide a base for validation and verification

• Serve as a basis for enhancement

16

What does a SRS contain?

Topics to be covered in Table of Contents*

• Brief Introduction

• Interfaces

• Functional Capabilities/ Use Cases

• Data Structures/Elements

• Mock-Up Screens

• Performance Levels

• Reliability

• Security/Privacy

• Quality

• Constraints and Limitations

* Add / remove sections as per project situation

17

Process of creating a SRS

2 Complete an "overview" What is the overall process

Where does the proposed solution fit in in the overall scheme of things

A section detailing the application and system. This is a high level

summary only of the application and system environment, users and any

known constraints, assumptions or dependencies.

3Detail out the functional

specs & summarize the

operational requirements

Details regarding modules, functionalities & features are included verbatim

or in the form of use cases

Will more disk space or server be needed to handle the application? When

is the application available or unavailable?

4 Internal and external

interfaces List all the hardware, software and communication interfaces

1Contemplate

Whether this is a build or buy product. Do due diligence of consideration in

this document.

5 Data Elements List all of the known data and features (functional) requirements

Process of documenting the SRS

18

Process of documenting the SRS

6 Non-functional

RequirementsList any non-functional or performance requirements, security

requirements or any outstanding quality attributes.

7 Refer Business Rules Reiterate the business rules from the Business Requirements

documentation

8 Additional DocumentsList any additional documentation (user manual) or training requirements

19

Characteristics of a great SRS

Correct – Of course you want the specification to be correct. The discipline is keeping

the specification up to date when you find things that are not correct.

Unambiguous – ONLY ONE INTERPRETATION. As you find ambiguities…fix them

Complete - All that is needed by software designers to create software.

Consistent - If you call an input "Start and Stop" in one place, don't call it "Start/Stop"

in another.

Ranked for importance and/or stability - Very often a new system has requirements

that are really marketing wish lists. Some may not be achievable. It is useful provide this

information in the SRS.

20

Characteristics of a great SRS

Verifiable - Don't put in requirements like - "It should provide the user a fast

response." Another of my favorites is - "The system should never crash."

Instead, provide a quantitative requirement like: "Every key stroke should

provide a user response within 100 milliseconds.”

Modifiable - Having the same requirement in more than one place may not be

wrong - but tends to make the document not maintainable.

Traceable - Often, this is not important in a non-politicized environment.

However, in most organizations, it is sometimes useful to connect the

requirements in the SRS to a higher level document. Why do we need this

requirement?

21

Guidelines for Creating Effective SRS

•Forge strong relationships with the client

•Generate confidence in the client that you know your stuff

•Speak Up

•Try one-on-one meetings

•Do workshops

•Identify escalation points, where your concerns can be voice

•Ask yourself – Can I work in his shoes if he takes a day off

•Define your outputs and inputs. For every output, do I have the required input ?

•The person to write the specification should have good communication skills

Guidelines for Creating Effective SRS

•Uphold documentation standards – keep sentences short and concise. Don’t ramble. Why use words when pictorials or tables can do the job.

•Have separate individuals write the specifications (not the individual who will write the code).

•Tables and charts are easier to maintain and can communicate the same requirements.

•Take your time with complicated requirements. Vagueness and incompleteness in those areas will come back to bite you later.

•Conversely, watch out for over-documenting those functions that are well understood by many people

•Keep the SRS up to date as you make changes

Guidelines for Creating Effective SRS

• Approximately 20-25% of the project time should be allocated to requirements definition

• Keep 5% of the project time for updating the requirements after the design has begun

• Test the requirements document by using it as the basis for writing the test plan

24

Some issues faced and how to combat

Customers don’t (really) know what they want

Spend sufficient time in the beginning on understanding objectives, deliverables and scope

Highlight the objectives, benefits, risks & assumptions to the customer

Get your customer to think by proposing options!!

• Inconsistency within a single process by multiple users

e.g. Different manual ways of handling the same process by different users

– Discuss process in detail with all parties and document the processes

– Discuss the process discrepancies in a common forum and try to bring consensus

– If inconsistencies still exist, flag off to the manager

– Try to identify SPOC responsible for requirements

• Insufficient input from stakeholders

• E.g. ‘I want a mutual fund portal’

– Possible reasons: Customer may not be aware of requirements, may not be expressive, not interested

– Highlight & reiterate (if required) the relevance of the proposed solution and timelines

– Requires good follow-up and probing skills to obtain the correct level of detail.

– Approach the client through proper channels

25

Some issues faced and how to combat

Conflicting interests – IT v/s business

e.g. IT does not want to implement an important business process since it will require additional funding & effort

Get all the concerned stakeholders in the same room and discuss the issues till consensus is arrived at

Try and identify a SPOC responsible for all requirements; however do validate requirements by all once identified

• Beware of false requirements

e.g. ‘I never use this report. Get rid of it’

– Carefully identify valid business requirement v/s statements of scope, risk, approach, or simply opinion.

– Validate requirements from all stakeholders and don’t base opinion on any single person.

• Users don’t participate in reviews

– Make sure that the document is shared with all parties involved

– Try and personally meet individuals, whose opinion is important, but have not sent a review. Don’t wait for emails all day.

– If a verbal review is obtained, document and mail it across to all, to avoid confusions later

26

Example

60% of the errors that show up during a system's life have their origin in the requirements gathering &

specification stage (Davis, 1990; Schach, 1992)

ABC Bank has approached Unistanz to create an ATM software

27

Value Add

28

Thank you