SRS for Data

Dictionary

1.0. Introduction
Data Dictionary is the major component in the structured analysis model of the
system. A data dictionary in Software Engineering means a file or a set of files
that includes a database’s metadata (hold records about other objects in the
database), like data ownership, relationships of the data to another object, and
some other data.
1.1. Purpose

Data dictionaries are used to provide detailed information about the

contents of a ddatasetor database, such as the names of measured variables, their

data types or formats, and text descriptions. A data dictionary provides a

concise guide to understanding and using the data. Ideally, all Ag Data

Commons (ADC) records for datasets and databases should include or point to a

data dictionary. It is preferred that these data dictionaries be machine readable,

in csv format.

Data dictionaries are used to provide detailed information about the

contents of a dataset or database, such as the names of measured variables, their

data types or formats, and text descriptions. A data dictionary provides a

concise guide to understanding and using the data. Ideally, all Ag Data

Commons (ADC) records for datasets and databases should include or point to a
data dictionary. It is preferred that these data dictionaries be machine readable,

in csv format.

1.2 Scope of the project

It provides the common language for the understanding of terms, definitions,

and data models. It further comprises central data catalogues (functional and

technical), anchors data roles and responsibilities, and stores (or at least

references) data quality rules. As the single source of truth, it is the central tool

to steer all company-wide data management activities and metadata.

Commercial data dictionary tools are currently available from multiple vendors

but must be customized to the processes and data requirements of the individual

organization.

2.1 Product Perspective:

In the attempt of creating a structure similar to a data dictionary that stores

information relating to all functional requirements in an SRS, a simple

technique has been used which makes use of some fixes. These fixes are used

for the sole purpose of identifying the data that could contain the possible

inputs, outputs, etc. corresponding to the identified requirement.

2.2 Product features:

 It helps in designing test cases and designing the software.
  It is very important for creating an order list from a subset of the items
list.
 It is very important for creating an order list from a complete items list.
 The data dictionary is also important to find the specific data item
object from the list.
2.3 Implementation:
1. Gather terms from different departments
The first step data teams need to take is to collect the different terms that all
departments are using to define key business definitions. Today, this collection
could be done in a spreadsheet with a list of the business concepts. One
approach teams take is to look at a sample of the most used reports and
dashboards by teams to get an understanding of the main metrics used across
departments. Once you have your list of terms, you can begin grouping them by
the functional unit. Another suggestion is to categorize the similar dimensions
that are repeated throughout the tables (product_id, country, year, etc.) This is
helpful because it some columns could have names that are difficult to
understand. Making a list of these definitions can help data teams standardize
some of these confusing terms.
2. Give the terms a definition

Data teams should try to define the terms collected based on the information
that they can collect on the terms. To do this, the data team should pull any
existing definitions from outdated documentation. Most teams keep this
documentation in google sheets or confluence, which can make finding the
definitions a tricky part of the process. Another way to find the definitions is by
looking through annual reports, or from actual code such as SQL queries or
Excel. Names of terms should always be written out and unabbreviated to make
sure that they are universally understandable.

3. Find alignment

In this step, it's important to look for similarities or dependencies in definitions

across teams and resolve conflicts. Multiple teams may have similar definitions.
For those teams and terms, bring them into the same meeting to align the teams
towards one definition. When you're setting up the meeting, clarify the outcome
of the meeting to get one standard definition that works for both teams.
4.Get support and sign off

Once these meetings conclude and teams are on the same page, have the team
leads sign off on the new definition. The team leads should be in alignment with
the definitions and feel like the data team worked collaboratively with them to
come to this definition. 

5. Centralize the document 

After you receive sign-off from team leads, publish the data dictionary as a
document that can be accessed by all employees. The definitions should be
understood by anyone in the company, not just the data team.

6. Upkeep the data dictionary

Although the key metrics should be stable, they may need to change over time.
One instance that might require key metrics to change is when a new revenue
stream is introduced or when the pricing of an existing revenue line changes.
These changes traditionally come from the business team and might require the
data team to implement the changes into the data dictionary.

2.4.1 Software Requirements

Operating system - windows 8 and onwards
Application software – Mysql
Programming language : - Python

2.4.2 Hardware Requirements

I3 processor or higher
4gb RAM
10gb Hard disk

3.1 Functional Requirements

The data dictionary, in general, includes information about the following:
Name of the data item is self-explanatory.
Aliases include other names by which this data item is called DEO for Data
Entry Operator and DR for Deputy Registrar.
Description/purpose is a textual description of what the data item is used for or
why it exists.
Related data items capture relationships between data items
Range of values records all possible values, e.g. total marks must be positive
and between 0 to 100.
Data structure Forms: Data flows capture the name of processes that generate or
receive the data items. If the data item is primitive, then data structure form
captures the physical structures of the data item. If the data is itself a data
aggregate, then data structure form capture the composition of the data items in
terms of other data items.
3.2 Non Functional Requirement
Usability

 Assist in avoiding data inconsistencies across a project

 Help define conventions that are to be used across a project
 Provide consistency in the collection and use of data across multiple
members of a research team
 Make data easier to analyse
 Enforce the use of Data Standards
 Using Data Standards as part of a well-crafted Data Dictionary can
help increase the usability of your research data, and will ensure that
data will be recognizable and usable beyond the immediate research
team.
Reliability
Data dictionaries provide for formalising and controlling the naming of entities,
attributes and their relationships within databases, for example by inclusion of:
•Data entities such as elements, tables, rows and keys.
•System entities such as programs and modules.
•External entities such as description of people, documents and devices.
•Identification attributes such as naming along with synonyms or aliases.
•Representation attributes such as data type or number of characters in an
element.

4.0 Other Non-functional Requirements:

Compatibility;
Compatible pc with required software to use the data dictionary.