Business analysis session 2 industry abbreviations definitions

Session 2. Industry Abbreviations DefinitionsRAM N SANGWAN

WWW.RNSANGWAN.COM

YOUTUBE CHANNEL : HTTP://YOUTUBE.COM/USER/THESKILLPEDIA

TO LEARN OR TEACH JOIN WWW.THESKILLPEDIA.COM

Agenda

• High Level Business Requirements

• Business Processes

• Business Requirement Document (BRD)

• Functional Requirement Document (FRD)

• Software Development Life Cycle (SDLC)

• Joint Application Development Session (JAD)

• User Acceptance Testing (UAT)

• The Defect Discovery Process

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

2

High Level Business Requirementsw

ww

.rnsa

ng

wa

n.c

om

. Yo

utu

be

ch

an

ne

l "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

3

Business Processes

• Many businesses have a process in place to assist with project

management and implementation.

• Opportunity for improvement involves making reasonable

estimates of how big a project is and how much it is going to cost.

• Business requirements are the critical activities of an enterprise that

must be performed to meet the organizational objective(s).

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

4

Business Requirements Document

• A typical BRD expresses the requirements of the business customers

and stakeholders of a new project.

• It summarizes the business reasons for undertaking the project,

answers the question

"What problems do the Business customers want to solve?"

Or

"What job does the business customer want to accomplish?"

and describes the constraints on any proposed solution from a

business perspective.

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

e c

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

5

Objectives of the BRD

• To gain agreement with stakeholders

• To provide a foundation to communicate to a technology

service provider what the solution needs to do to satisfy the

customer’s and business’ needs

• To provide input into the next phase for the project

• To describe what, not how the customer/business needs will be

met by the solution

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

6

Functional requirements

Functional requirements describe system services or functions. E.g.

• Compute sales tax on a purchase

• Update the database on the server ...

• Statements of services the system should provide, how the

system should react to particular inputs and how the system

should behave in particular situations.

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

7

Functional requirement Document

• Functional requirement Documents are very detailed and outline

exactly what needs to be delivered and would typically be read by

business analysts, developers, project manager and testers:

• Requirement 1:

"The system shall be able to register a product using the following fields:

Name (20 characters long), Details (2000 characters long), Price (currency),

Category (pick list)."

• Requirement 2:

"The system shall support that up to 5 pictures can be listed per product."

So it means that a business requirement (“The portal should list our

products”) will be broken in to one or more detailed functional

requirements.

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

8

More Examples of functional requirements

• The user shall be able to search either all of the initial set of

databases or select a subset from it.

• The system shall provide appropriate viewers for the user to read

documents in the document store.

• Every order shall be allocated a unique identifier (ORDER_ID)

which the user shall be able to copy to the account’s

permanent storage area.

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

9

Qualities of functional requirements

• Correct

• Modifiable

• Feasible

• Complete

• Necessary

• Verifiable

• Prioritized

• Consistent

• Unambiguous

• Traceable

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

10

SDLC-Software Development Life Cycle

• The Software Development Life Cycle (SDLC), or System

Development Life Cycle is the entire process of formal, logical

steps taken to develop a software product.

• It is a framework that describes the activities performed at each

stage of a software development project.

• The concept generally refers to computer or information

systems.

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

11

Phases of SDLC

• The phases of SDLC can vary somewhat but generally include

the following:

1. Problem Definition.

2. Program Design.

3. Coding.

4. Debugging.

5. Testing.

6. Documentation.

7. Maintenance.

8. Extension and Redesign

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

12

Joint Application Development

• JAD, is a process originally developed for designing a computer-

based system.

• It brings together business area people (end users) and IT

(Information Technology) professionals in a highly focused

workshop.

• The advantages of JAD include a dramatic shortening of the

time it takes to complete a project.

• It also improves the quality of the final product by focusing on

the up-front portion of the development lifecycle, thus reducing

the likelihood of errors that are expensive to correct later on.

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

13

More on JAD

• JAD centers around a structured workshop session.

• Participants get together in a room to discuss the problem/project.

• Everyone hears what the rest of the group has to say.

• JAD can eliminate many of the problems with traditional meetings.

• Meetings are not well regarded as a productive forum.

• JAD turns meetings into workshops.

• They are less frequent

• More structured, and productive

• An agenda provides the structure

• The facilitator directs the process

• Visual aids clarify concepts being discussed and the group dynamics, withconstant feedback, stimulates creativity

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

14

JAD Purpose and Philosophy:

• JAD Purpose:

• to define the project, design a solution, and monitor the project until it reaches completion.

• JAD Philosophy:

The JAD process is based on four simple ideas:

1. People who actually do a job have the best understanding of that job.

2. People who are trained in information technology have the best understanding of

the possibilities of that technology.

3. Information systems and business processes rarely exist in isolation -- they surpass

the confines of any single system or office and effect work in related departments.

People working in these related areas have valuable insight on the role of a system

within a larger community.

4. The best information systems are designed when all of these groups work togetheron a project as equal partners.

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

15

User Acceptance Testing (UAT)

Also known as…Acceptance Testing …

… UAT ….

… Alpha / Beta Testing…

A process of verifying that a solution works for the user.

It’s a form of testing to verify the system can support day-to-day

business and user scenarios to validate rules, various workflows, data

correctness, and overall fit for use and ensure the system is sufficient

and correct for business usage

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

16

The Goal of User Acceptance Testing

Given business requirements, we build systems that implement them

• UAT Tests are derived from these requirements

• UAT confirms we have confidence that the system satisfies the requirements

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

17

The Defect Discovery Process

• Developers create systems

based on requirements

• Errors often occur in the

development process

• UAT Testers create tests to verify

the system’s behavior is

consistent with the requirements

• Testing is performed to detect

defects and confirm usability of

the system

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

ec

ha

nn

el "y

ou

tub

e.c

om

/use

r/The

SkillP

ed

ia"

18

How the Customer

Explained it

How the Project Leader

understood it

How the Analyst

Designed it

How the Programmer

Wrote it

How the Business

Consultant Described it

How the Project was

Documented

What Operations

InstalledHow the Customer was

Billed

How it was Supported What the Customer

Really Needed

ww

w.rn

san

gw

an

.co

m. Y

ou

tub

e c

ha

nn

el

"yo

utu

be

.co

m/u

ser/Th

eSkillP

ed

ia"

19

ThankyouWWW.RNSANGWAN.COM