Fundamental Business

Terminologies and Introduction

to SQL

1/
Business Requirement Document (BRD)

●
A business requirements document describes the business solution
for a project (i.e., what a new or updated product should do),
including the user’s needs and expectations, the purpose behind this
solution, and any high-level constraints that could impact a successful
deployment.
●
Essentially, a BRD acts as the guideline for stakeholders to make
decisions regarding project priorities, design, and structure to ensure
the project remains aligned with the overall goals of the business.
●
The BRD sets the standards for determining when a project has
reached a successful completion.

2/
Anatomy of a great BRD
●
Most businesses follow a template for all their project requirements documentation. This is
helpful for keeping documentation standard across the organization.
●
The structure may vary but a basic BRD will include the following sections and components:
Project overview (including vision, objectives, and context)


Success factors


Project scope


Stakeholder identification


Business requirements


Scope of the solution



Project constraints (such as schedule and budget)



Quality control measures



3/
Tips for writing the perfect BRD
Practice effective requirements elicitation
●

Use clear language without jargon

●

Research past projects

●

Validate the documentation

●

Include visuals
●

4/
Tips for writing the perfect BRD
●
Practice effective requirements elicitation
Even if you write an impressive BRD, it won’t be effective if you haven’t identified
and documented all the requirements necessary. To ensure your BRD is complete
and cohesive, you’ll need to apply proper elicitation methods which are:
Brainstorming

Document analysis

Interface analysis

Focus groups

Prototyping

Requirements workshops

Interviews

Observation

Surveys

5/
●
Use clear language without jargon
Requirements documents are often long and text-heavy. To prevent confusion or misinterpretations, use
clear language without jargon. Keep in mind that multiple stakeholders will be using this document, and
not all of them will be technically-minded. By keeping your language clear, you can ensure everyone can
understand it.

●
Research past projects
A great way to jump-start your documentation process is to research similar projects your organization
has completed in the past.

●
Validate the documentation
Once you’ve finished writing the requirements document, have a subject matter expert and the project
stakeholders review it. This is the time for everyone to validate the information and offer feedback or
corrections.

●
Include visuals
Although BRDs tend to be text-heavy in nature, visuals play an important role in presenting and
clarifying information and making the document more user-friendly. Break up walls of text with data
visualizations such as process flows and scope models.

6/
Function Requirement Document (FRD)

●
The functional requirements document (FRD) is a formal document detailing the requirements required
to achieve business needs. The document serves the purpose of a contract so that the client can agree what
they deem acceptable for the capabilities of the product. The functional requirements document is a core
document for product development.
●
The FRD is independent of the solution. It doesn’t provide information on how the product will be
developed, how it will work, or what it should be, but rather what the product should do. As such, the
functional requirements commonly come in the form of requirements statements. The functional
requirements document commonly includes a list of requirements statements organised by the feature
with identified priorities.
●
It makes sure that the team working on the project fully understands the requirements and is
concentrating their efforts to develop a solution that will satisfy business needs. However, the functional
requirements document doesn’t force the teams to commit to specific designs nor does it impose the
solution. Instead, it allows them to determine in which way they will develop the project so it answers the
requirements.

7/
Benefit of a Functional Requirements Document (FRD)

●
It provides a single reliable source of requirements for the stakeholders. FRD helps clear out all misunderstandings
and keeps the development teams as well as those on the business side of operation all on the same page and working
towards the common objective. It ensures that there’s transparency, consensus, and agreement among all the
stakeholders.
●
It reduces the cost and shortens the overall duration of the project. Clearly defined functional requirements ensure that
the teams have a shared understanding and a written record of what they’re required to do, eliminating the need for
frequent meetings.
●
It makes the project more predictable. With well-documented and detailed functional requirements teams can more
accurately estimate the time needed for the development and potential budget.
●
It helps timely identification of potential issues. When the functional requirements are thoroughly captured during the
discovery phase, it’s easier to identify the error on time and fix them. Problems discovered during the phase of gathering
the functional requirements are the easiest and cheapest to correct. In addition, documenting functional requirements
and analysing them is helpful for identifying the missing requirements. Furthermore, the functional requirements
documentation is useful as a reference for checking whether the product provides all the functionalities required by the
client.

8/
What are the Sections of a Functional Requirements Document (FRD)

●
The functional requirements document outlines the functions required to satisfy business
needs, but the format of the document itself may vary depending on the product. While
there’s no standard format, there are some common core elements that appear in almost every
FRD which are as follows:
●
Project description – the brief overview of the project contains information on the background of the
project or conditions that created the need for the product. It also details the intended purpose of the
project by describing the business objectives. Commonly, this section also lists the assumptions and
constraints of the project.
●
Points of contact – the list of all the key participants in the project along with their roles, names, and
titles.
●
Document references – this section lists and names all the documents used as sources while creating the
FRD. These may include white paper analysis, meeting summaries, and any other document contribution
to the functional requirements document.

9/
Data Dictionary

●
A data dictionary is a collection of descriptions of data objects or terms, definitions,
and properties in a data asset. Data dictionaries provide information about the data.
●
Data dictionaries are an essential communications tool for data modeling, curation,
governance, and analytics, especially when dealing with datasets that have been
collected, compiled, categorized, used, and reused by different internal and external
data Consumers across the organization.
●
Data dictionaries provide valuable definitions for the data as well as help data
Consumers understand any data asset before delving into the details within that
asset. In order for data to be trusted and appropriately used, it must be understood
and supported by clear definitions.

10 /
Components of Data Dictionary
●
A data dictionary consists of several data components, which contains multiple
levels: data asset, entity,attribute, and value domain. Each level includes different
components, but each component should be defined with the following properties:

11 /
Data Mapping Document
●
Data mapping is the process of matching fields from multiple datasets into a
schema, or centralized database. Data mapping is required to migrate data, ingest,
and process data and manage data. Ultimately the goal of data mapping is to
homogenize multiple data sets into a single one.
●
Data mapping means that different data sets, with varying ways of defining similar
points, can be combined in a way that makes it accurate and usable at the end
destination.
●
Data mapping is a standard business practice. However, as the amounts of data and
the complexity of systems that use the data has increased, the process of data
mapping has become more complicated and requires automated and powerful tools.
___ Will Discuss this further in detail

12 /
 Introduction to Structured Query Language (SQL)
●
Structured Query Language (SQL) is a database language designed for managing data held
in a relational database management system. SQL was initially developed by IBM in the early
1970s (Date 1986). The initial version, called SEQUEL (Structured English Query
Language), was designed to manipulate and retrieve data stored in IBM’s quasi-relational
database management system.
●
Many of the currently available relational DBMSs, such as Oracle Database, Microsoft SQL
Server (shown in Figure 15.1), MySQL, IBM DB2, IBM Informix and Microsoft Access, use
SQL.
●
In a DBMS, the SQL database language is used to:
●
Create the database and table structures
●
Perform basic data management chores (add, delete and modify)
●
Perform complex queries to transform raw data into useful information

13 /
Pros of SQL
●
Powerful Language: SQL Queries can be used to retrieve large amounts of records
from a database quickly and efficiently.
●
SQL joins two or more tables and show it as one table to user.
●
Easy to learn: It is easy to use because it is like the structured English language so
it does not need any coding.
●
Portability: SQL can be used in the programs in servers, laptops, PCs, and even
some of the mobile phones.
●
Multiple data views: With the SQL language, each user can have different view
from each other.
●
Client/Server language: SQL is used for linking end computers and databases.
Thus, providing client server architecture.

14 /
Cons of SQL
Difficulty in Interfacing: Interfacing an SQL database is
●

more complex than adding a few lines of code.

●
Tables dependency: When create a view based on
underlying tables of a database. Whenever we change the
structure of those tables that view associated with, we have
to change the view as well.

15 /
Types of SQL Statements
The lists in the following sections provide a functional summary of
SQL statements and are divided into these categories:
●
Data Definition Language (DDL) Statements
–Data definition language (DDL) statements let you to perform these tasks:
●
Create, alter, and drop schema objects
●
Grant and revoke privileges and roles
●
Analyze information on a table, index, or cluster
●
Establish auditing options
●
Add comments to the data dictionary

●
Data Manipulation Language (DML) Statements
●
DELETE, INSERT, MERGE, SELECT, UPDATE

16 /
●
Transaction Control Statements
●
COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION
●
Session Control Statements
●
PL/SQL does not support session control statements. The session control
statements are:
ALTER SESSION
SET ROLE

●
System Control Statement
●
The single system control statement, ALTER SYSTEM, dynamically manages the properties of an
Oracle Database instance. This statement does not implicitly commit the current transaction and is not
supported in PL/SQL.

●
Embedded SQL Statements
●
Embedded SQL statements place DDL, DML, and transaction control statements within a procedural
language program. Embedded SQL is supported by the Oracle precompilers

17 /