Web Application For Data Processing of Municipality Portal (Laravel Framework)

Municipality Data Portal – Timor Leste
Software Requirements Specification

Municipality Open Data Portal Timor Leste - Software Requirements Specification
Contents
REVISION HISTORY..................................................................................................................................................................3
CHAPTER I: INTRODUCTION................................................................................................................................................4
1. PURPOSE OF THE SYSTEM...................................................................................................................................................... 4
2. DOCUMENT CONVENTION..................................................................................................................................................... 4
3. INTENDED AUDIENCE AND READING SUGGESTIONS................................................................................................. 4
4. SYSTEM SCOPE.........................................................................................................................................................................................................................................4
4.1 System Applications and Modules...................................................................................................................................... 6
4.2 Out of Scope................................................................................................................................................................................. 7
4.3 System Data Structure............................................................................................................................................................ 8
4.4 Geographical Coverage Entities....................................................................................................................................... 10
5. SYSTEM SECURITY..............................................................................................................................................................................................................................10
6. REFERENCES..........................................................................................................................................................................................................................................11
CHAPTER II: OVERALL DESCRIPTION.............................................................................................................................12
1. SYSTEM PERSPECTIVE.......................................................................................................................................................... 12
2. SYSTEM FUNCTIONS..........................................................................................................................................................................................................................12
Data Manager.......................................................................................................................................................................................... 12
3. OPERATING ENVIRONMENT............................................................................................................................................... 15
4. DESIGN AND IMPLEMENTATION CONSTRAINTS....................................................................................................... 16
5. USER DOCUMENTATION....................................................................................................................................................... 16
6. ASSUMPTIONS AND DEPENDENCIES.............................................................................................................................. 16
7. EXTERNAL INTERFACE REQUIREMENTS...................................................................................................................... 16
CHAPTER III: SYSTEM FEATURES....................................................................................................................................17
1. DATA MANAGER..................................................................................................................................................................................................................................17
1.1 Login..................................................................................................................................................................................................... 18
1.2 Data Summary.................................................................................................................................................................................. 18
1.3 Data Template.................................................................................................................................................................................. 18
1.4 Data Entry / Edit............................................................................................................................................................................. 25
1.5 Correlation......................................................................................................................................................................................... 29
1.6 Language Translation................................................................................................................................................................... 29
1.7 Municipality Profile........................................................................................................................................................................ 31
OTHER NONFUNCTIONAL REQUIREMENTS......................................................................................................................................................................................33
Performance Requirements................................................................................................................................................................ 33
Safety Requirements.............................................................................................................................................................................. 33
Security Requirements.......................................................................................................................................................................... 34
Software Quality Attributes................................................................................................................................................................ 34
Business Rules........................................................................................................................................................................................... 34
OTHER REQUIREMENTS................................................................................................................................................................................................................................34
ANNEXURE A: ENTITY-RELATION DIAGRAM (ERD)..................................................................................................35
ANNEXURE B: STATE TRANSITION DIAGRAM.............................................................................................................36
DATA MANAGER..................................................................................................................................................................................................36
ANNEXURE C: DATA DICTIONARY....................................................................................................................................37
ANNEXURE D: DATA FLOW DIAGRAMS (DFD).............................................................................................................46
1|Page
ANNEXURE E: SYSTEM ARCHITECTURE.........................................................................................................................50
ANNEXURE F: SOFTWARE ARCHITECTURE..................................................................................................................51
ANNEXURE G: SYSTEM FLOW CHARTS...........................................................................................................................52
ANNEXURE H: SYSTEM SCREENS......................................................................................................................................58
DATA MANAGER................................................................................................................................................................................................................................................58
2|Page
Revision History
Name Date Reason For Changes Version
ITM 15 March 2021 The First Draft is created on this date V1.0
Chapter I: Introduction
1. Purpose of the system
The purpose of the system is to collect raw data from different departments of the country and after filtration it will be
available on the municipal portal. The data is collected from seven different departments of the central government. Each
department has their own type of data that they are providing to the ministry of state administration (MEA).
The system contains all the important data about
● Agriculture

● Arts and council
● Education

● Gender
● Infrastructure

● Population
● Projects funds and investment
● Social economy
2. Document Convention
This project will be managed using effective frameworks and proven methodologies such as Laravel and Angular,
to drive this project to success. This first documentation is the key to the process of software development.
3. Intended Audience and Reading Suggestions

This document will be a ready reference for the design and development team to understand the system
architecture and scope of the project. The document contains the system scope, overview, and features with
system design. The project team can understand the systems architecture by following the Data Flow Diagrams, ER
Diagram, System and Software Architecture and System Flow charts provided in this document under Annexures.
The development team will follow the wire frames for User Interface design and development, the details of each
module is mentioned in this document to guide the logic development.
4. System Scope
UNDP Timor-Leste is supporting the Ministry of State Administration (MEA) to develop the open data portal. The
data portal will combine data from different Timor-Leste government agencies into one central database and
viewing platform. All the general information about the specific government departments is available in this portal.
The key deliverables of the system will be:
 Develop a web application to suitably store all the respected data.
 The web application should be easily navigated work over popular web browsers.
 The application should have scalable features that will allow extension of functionality and, in particular,
to allow the incorporation of new sections to upload information form users in the future.
 The web application design should be interactive, appealing, easy-to-use and responsive.
 The web application should be able to store and publish data on various development sectors and indicators.
 The development should use open-source technology to store, manage and disseminate data.
 The database administration should be developed to allow managing of application data and content.
 The web application should support multi-languages and should be available in English, Portuguese and
Tetum languages.
Following is the summary of the features of the system:
 Import and collate development indicators national and sub-national data from various data sources, time
periods and geographic areas.
 Store and manage development indicators based on data from various authenticated sources.
 Upload and update data using industry-standard format like Comma Separated Value (CSV).
 Manage geographical area and their respective maps at national and sub-national levels.
 Design and develop the specific web application to add data in the portal to the Municipal Website.
 Create the specific modules, which data needs to be added or updated.
 Design and develop the relevant fields to store data.
 Create the specific database on the web server (INGINX) in which the data is stored and retrieved.
 Link the front-end webpages to the backend design in which the data is shown to the public.
 Update the data.
 Develop user-friendly and easy to use interface
4.1 System Applications and Modules

The Data Manager application will be developed as a web-based application that will be accessed by the system
administrator with a pre-defined login and password. Below are the details of the modules of application.
1. Data Manager
a. Data summary
b. Data template
 Manage area
 Manage indicator
 Manage metadata
 Manage default chart
 Refresh data
c. Data entry/edit
d. Correlation
e. Language translation
f. Municipality profile
4.2 System Data Structure
The system will be developed to manage the socio-economic indicators based data. The data structure will comprise of
the following elements:
Indicator: A series of the observations with harmonized characteristics representing a standard behavior. Example Child
and adolescent underweight.
Metadata: Detailed explanation of the series following the global standard for data definition. Example Definition.
Method of Computation.
Unit: Measurement scale of the observation values. Example Percent, Number.
Subgroup/Element: Disaggregated group to represent further dimensions of the observation. Example Sex, Age.
Indicator-Unit-Subgroup Combination: Besides defining the disaggregation for each indicator it will also be used to
define the target group of an indicator. Example – Child and adolescent underweight– Percent – Female.
Sector: Termed as Indicator Classification that groups similar indicators for organized storage and reporting. Example
Diets and Nutrition.
Data Value: Reported and store data against a combination of Indicator – Unit – Subgroup (IUS). Example 24 reported
against Child and adolescent underweight– Percent – Female.
Area: Geographical or administrative boundaries to represent the data values for each IUS combination. Example
Region, Country, State, District.
Time Period: reported the time period of the data values for each IUS combination. Example 2017, 2016-2017. The time
period will represent the day, week, month, quarter, year and year range.
Source: data source of the reported data values for each IUS combination. Example Census, Health Statistics. The source
type will represent magazines, scientific journals, or publications from reporting organizations.
Below is the data structure diagram of the underlying database:
4.3 Geographical Coverage Entities
The system will be developed to store and manage data at various geographical levels or administrative
boundaries. The geographical level will be termed as Area in this system. Data Manager application will have
features to manage areas and their geo-spatial maps. These features are explained in detail in the following
chapter. The system will be capable to manage the area at all levels including but not limited to:
 Country
 Municipality
 Suco
As explained in the data structure section the data values for each Indicator combination will be entered against
each of the above-defined area levels. Example: The system will have provision to enter Population size – Percent –
Female at country, municipality and suco levels for various time periods and data sources. This will help in data
analysis and comparison of various performance indicators at all geographical levels.
5. System Security
This system will be developed to ensure that all vulnerabilities of the web application will be identified and
corrective measures are taken. The web application environment including the scripting language, webserver
software, and the operating system are mentioned in this document. Configuration and coding will be done in the
application to manage the identified vulnerabilities. Manual testing will be conducted on the application to ensure
that no known vulnerabilities exist in the system. Below are some of the known vulnerabilities that will be handled
in the application:
 Displaying the passwords between client and server in clear text.
 Session hijacking.
 Cross-site request forgery (csrf) attack to load a page containing malicious request.
 Upload malicious (.exe) file.
 Brute force attack.
 Not maintaining audit trails.
 Runtime/server error.
 View the authenticated page from the cache of the browser.
 Server version discloser in header response.

6. References
Best practices in developing information management systems including standardizing and harmonizing of socio-
economic indicators and their related dimensions will be used to develop this system. The system will be designed
and developed to meet the objectives of the terms of references of the project. It will cater to the needs of the
stakeholders who are looking for a one stop-shop solution to collating the data into a centralized database system
with features to strengthen data dissemination and effective data presentation.
Chapter II: Overall Description
1.System Perspective
The Municipality Data Portal is the result of great efforts made by the Ministry of State Administration (MAE) to
strengthen local development in Timor-Leste. Based on a set of development indicators, this Portal enables data
exploring and comparing across all municipalities of Timor-Leste through an interactive and data-friendly format.
The Municipality data portal is a web based application software which will be deployed in the cloud. The portal
will comprise of Data Manager. The system will have responsive web design to support display on various screen
sizes including that of computers, tablets and mobile devices.
Our mission is to build the web application in which the raw data from the specific government departments are
collected, Filtered and then available to the municipality website for the public.
2.System Functions
This section will provide detailed functionalities of the two applications:
Data Manager
 These will be the web pages and will be hosted on a web server along with the user interface application.
 The web pages will have user access control. A system administrator login and password will be required to
access the system.
 This application will be accessed through a web browser and requires an internet connection.
 Administrator manage and collect all the data from the different departments and then submit it to the
portal.
 Data change and control operations are managed by administrator.
 After submission, Data goes for verification process and then it will be available on the municipality portal.
 It will allow to develop and manage a data template that will include area and indicator list.
 Metadata for the indicators will be managed in the data template.
 There will be modules to store and manage the socio-economic indicators and its related elements.
 Data will be Imported on aggregated and calculated indicators from various data sources.
 Modules will be available for the chart settings of the advance data analytics graphical presentations.
 There will be a translation module to allow to translate the area, indicators and metadata strings from English
to Portuguese and Tentum language.
 Municipality profiles including their geographical and project details will be managed in this application.
Below is the system chart of the Data Manager Portal:
User Roles
While the User Interface webpages will have no access permissions restrictions and will be open to public use, The
Data Manager will have access restriction and will be accessed by login as system administrator.
System Administrator
This is the default user with super administration rights that will have access to the complete tool including
importing master list of area and their geo-spatial maps, indicators and their dimensions, data for those indicators.
The system administrator will be also able to manage language and municipality profiles.
3.Operating Environment
The system will be a web-based online application. It will be developed to run over the internet. The application
will be deployed on a web server with the following recommended specifications:
Processor: 8 vCPU
Internal Memory: 32 GB RAM
Hard Disk Space: 500 MB SSD
Internet Connection: 1 Gbps
The system will be developed in the following environment:
Operating System: Ubuntu v16.04 LTS
Front-end Language: JavaScript, HTML v5, CSS v3
Visualization Library: d3.js v5, Highcharts
Front-end Framework: NGINX
Back end Language: PHP v7.1
Back-end Framework: Laravel v5.4
Database System: MySQL v5.7
Server Type: Apache v2
Data will be imported from various source available in the Comma Separated Values (CSV) format.
4.Design and Implementation Constraints
The open data portal application will help you to track and monitor its sectors and indicators. This system will be
developed to host the data at all geographical levels and for multiple time periods. Data will be imported from the
selected identified and authorized sources.
5.User Documentation
Detailed user manuals will be developed for application. These user manuals will explain the step-by-step approach
to explain the functionality and usage of the system. There will be a database administrator manual to help storing
and managing the underlying database.
6.Assumptions and Dependencies

The system will allow import data from the data sources in CSV format. The list of key performance indicators will
be suggested by the Advisory Group. The frequency of data updates will be based on as and when the data is
available to be imported into the system by the administrator. The municipality profiles will be managed by the
system administrator whereas the area, indicator and metadata strings need to be translation from English to
Portuguese and Tentum languages. Options to translate of user interface strings, manage the documents for
download and information on services to citizens needs to be developed in the system.
7.External Interface Requirements

User Interfaces
The user interface for the software shall be compatible to the common used internet browsers including Google
Chrome, Mozilla Firefox, Internet Explorer and Apple Safari. The user interface will be easy to navigate through all
the screens with no or less training. The interface will have a menu-driven and ease to navigate options to access
the application features.
Hardware Interfaces
The system will be deployed on commonly available web servers and cloud-based services. Internet connectivity is
required to run the system.
Software Interfaces
The system will be developed using open-source technologies that would allow easy extensibility and scalable
communication Interfaces. The system will use the HTTP protocol for communication over the internet.
Chapter III: System Features
The module will be developed to manage the data from across departments. The data will be managed by the data
manager. The frontend application will serve as a user interface to access the underlying database in various visual
forms to allow searching, tracking, monitoring, and presenting data of departments.
The data will be imported from templates created in CSV formatted files. The user interface application will allow
to navigate through the various datasets on municipality profiles and projects, documents to download, services to
citizen and data catalog of socio-economic indicators data. It will allow searching, selecting and presenting data
using charts, maps and advanced visualization to facilitate data analytics.
Following are the details functional requirements for the application:
1. Data Manager
The system needs the underlying database so that it can successfully implement the requirements mentioned for
the frontend application. The data manager will help to develop and manage a data template to facilitate creating
the underlying database. The application will have the following modules:
a. Login
b. Data summary
c. Data template
 Manage area
 Manage indicator
 Manage metadata
 Manage default chart
 Refresh data
d. Data entry/edit
e. Correlation
f. Language translation
The following section lists the detailed requirement specifications of each module:
1.1 Login
Description and Priority
The login module will provide a login facility for the system. Users will log in to the system using the assigned email
ID or user name along with the password for authentication. Users will have to enter the captcha to login.
Functional Requirements
The following will be the functional requirements of this module:
REQ-1: System administrator will be able to login to the system by using their email ID and password.
REQ-2: In case of invalid login, details appropriate messages will be displayed.
REQ-3: The logout option will be provided after successfully logging into the system to exit the system.
1.2 Data Summary

This module will be the landing page of the data manager application. It will provide the database summary
information by reporting the counts of the key dimensions of the underlying database.
REQ-1: This will be the landing page of the data manager application.
REQ-2: The database summary page will display the count of seven major database dimensions – the Indicator, IUS
combination, indicator metadata, indicator default chart type, Area, Source and Data Values.
REQ-3: Each count will also show the last updated day and date under each database dimension widget.
1.3 Data Template

1.3.1 Manage Area
The administrator of the system will be having access to this module. This module would allow you to manage the
administrative boundaries against which the data will be entered. You will be able to delete and edit the available
areas, sorting the area list and adding a new area in the database and also to manage the geographical areas.
REQ-1: The area name and area code will be seen in a grid view with pagination options.
REQ-2: There will be an option to search, sort and navigate the available area list.
REQ-4: Option will be available to delete an existing area. When you select to delete all data of the selected area it will be
deleted after taking the confirmation from the user.
REQ-5: There will be an option to add a new area into the database. Users will be able to select the parent area, area name
and area code from the available list.
This module will have the following options:
 Export Area
 Import Area
 Add Area
 Edit Area
 Delete one or selected Areas
Export Area
This module will have the following options to:
 Download Area Empty Template
 Download Area Template with Data (when data is available).
This Area template format is available in this document in Annexure H: Data Templates.
REQ-1: The administrator will be able to download an empty template in CSV (Comma Separated Value) formatted
file.
REQ-2: The template will have the following columns: Area ID, Area Name, Area Level, Area ParentID, Area Group.
Import Data
 Browse area filled template

 Import area into the database
The administrator after entering the data into the template can import the area into the database.
REQ-1: The administrator will be able to browse and upload data in CSV (Comma Separated Value) formatted file.
REQ-2: The format will be the standard format used generally in census datasets. This format assigns multiples of
three Alpha-numeric characters based on the area level. For example
 TLS is the Area ID for Timor Leste which is referred to as Level 1.
 TLS001 is the Area ID for Ainaro which is referred to as Level 2.
 TLS001002 is the Area ID for Hato-Builico which is referred to as Level 3.
REQ-3: The following validation is checked before adding department .

 They should not be blank
 They should not be duplicate
 They should not contain any special character
REQ-4: The GeoJSON file containing the GIS data along with Area ID will be imported at the backend of the system.
REQ-5: The Area Level denotes the geographical level. For example, Level 1 is generally national level, Level 2 is assigned to
municipality level and Level 3 area assigned to suco level.
REQ-7: Area Parent ID refers to the Area ID of the parent. For example, the parent ID of Dilli will be the Area ID of Timor
Leste.
REQ-8: The Area Group column will contain the Area IDs of all the areas that fall in a group. For example, Timor Leste falls
in Asia and in Pacific Asia.
REQ-9: The Area Parent ID and Area Group are optional Columns and will be used based on the requirements of the
project.
1.3.2 Manage Indicator
The administrator has an option to manage indicators using this module. The IUS combinations will be deleted and edited.
There will be option to sort the indicator list and add a new indicator-unit-subgroup (IUS) combination into the database.
This module will help you to create the indicator structure including indicators (I), their unit(U) of measurement and their
disaggregation subgroups(S).
REQ-1: The IUS combinations and their related dimensions will be seen in a grid view with pagination options.
REQ-2: There will be an option to search, sort and navigate the IUS list.
REQ-3: Show/Hide button will allow you to view the setting of the status of the indicator that is shown or hidden in the
user interface application.
REQ-4: Option will be available to delete an existing IUS combination. When you will select the option to delete all data of
the selected IUS combination then it will be deleted after taking the confirmation from the user.
REQ-5: There will be an option to add a new IUS combination. Users will be able to select the Indicator, Unit, and Subgroup
from the available list and also set related dimensions – High Is Good, Default Subgroup, Sector, and Subsector. This
module will have the following options:
 Export Indicator
 Import Indicator
 Add Indicator-Unit-Subgroup (IUS)
 Edit Indicator
 Delete one or selected Indicators
Export Indicator
 Download empty indicator master template
 Download indicator template with data (when data is available)
This Indicator template format is available in this document in Annexure H: Data Templates.
REQ-1: This module will have an option to download an empty IUS template in CSV format.
REQ-2: There will be an option to download the complete IUS list available in the database in CSV format (once the
indicators will be imported in the database).
Import Indicator
 Browse IUS template
 Import IUS into the database

The administrator after entering the IUS data into the template can import the list into the database.
REQ-1: After the indicator details as per the format requirement are entered in the template the user will browse and
upload the template to be imported in the database.
REQ-2: Once the template is uploaded there will be an option to import it into the database.
REQ-3: The last upload summary will provide the details of the import process.
1.3.3 Manage Metadata
The administrator has an option to manage metadata of the indicators using this module. Each IU combination will have a
metadata associated to it. There will be option to delete, edit, sort and add the metadata into the database.
REQ-1: The indicators and their metadata will be seen in a grid view with pagination options.
REQ-2: There will be an option to search, sort and navigate the metadata list.
REQ-3: Option will be available to delete the existing metadata. When you will select the delete option then all data of the
selected metadata will be deleted, after taking the confirmation from the user.
REQ-5: There will be an option to add new metadata. Users will be able to select the Indicator and Unit from the available
list and then enter metadata like MTI, MT2, etc.
 Export Metadata
 Import Metadata
 Add Metadata
 Edit Indicator
 Delete one or selected metadata
Export Metadata
 Download empty metadata master template
 Download metadata template with data (when data is available)
This metadata template format is available in this document in Annexure H: Data Templates.
REQ-1: This module will have an option to download an empty metadata master template in CSV format.
REQ-2: There will be an option to download the complete metadata list available in the database in CSV format (once the
metadata will be imported in the database).
Import Metadata
 Browse metadata filled template
 Import metadata into the database
The administrator after entering the metadata into the template can import the list into the database.
REQ-1: After the metadata details as per the format requirement are entered in the template the user will browse and
upload the template so that it can be imported in the database. Following are the metadata structure:
Indicator Name assigned to an indicator
Unit Measurement unit of indicator
MT1 Indicator Definition
MT2 Method of Computation
MT3 Overview
MT4 Comments and Limitations
MT5 Data Collection for Global Monitoring
MT6 Obtaining Data
MT7 Data Availability
MT8 Treatment of Missing Values
MT9 Regional and Global Estimates
The nine columns name like MT1, MT2 will be the metadata tags provided to enter the metadata details.
All metadata tags are optional and can be left blank when not applicable.
REQ-5: The last uploaded summary will provide the details of the import process.
1.3.4 Manage Default Chart
This module will help you to set default chart type and time periods to represent the graph in the user interface. The
administrator has the option to manage the default chart through deleting and editing the available chart type, sorting the
default chart type list and adding a new default chart in the database.
REQ-1: The default chart type list will be seen in a grid view with pagination options.
REQ-2: There will be an option to search, sort and navigate the chart type list.
REQ-3: Option will be available to delete existing default chart types. When selected to delete all data of the selected
default chart type will be deleted after taking the confirmation from the user.
 Export Default Chart
 Import Default Chart
 Add Default Chart
 Edit Default Chart
 Delete one or selected default charts
Export Default Chart

 Download empty default chart master template
 Download default chart template with data (when data is available)
This default chart template format is available in this document in Annexure H: Data Templates.
REQ-1: This module will have an option to download an empty default master template in CSV format.
REQ-2: There will be an option to download the complete chart settings available in the database in CSV format (once the
chart template will be imported in the database).
Import Default Chart

 Browse default charts filled template

 Import default charts into the database
The administrator after entering the default chart types into the template can import the list into the database.
REQ-1: After the chart settings as per the format, requirements are entered in the template the user will browse and
upload the template to be imported in the database.
1.3.5 Refresh Data
REQ-1: This module will have options to clear the server cache (used to store the frequent query results to speed the data
processing).
REQ-2: It will allow caching the various data elements including the Data, Area, and Indicator.
1.4 Data Entry / Edit

This module will allow us to view and manage data in the database.
1.4.1 Manage Data
This module will give you an option to edit the entered data. Data Value and its related Time Period and Source will be
available for editing. The user will be able to delete the existing record and add new data against an existing IUS
combination. Data will be entered by generating a data entry grid. The user will generate this grid by selecting the required
IUS combination, Area, Time Period and Source. When generating the data entry grid there will be an option to add a new
time period and source.
REQ-1: System administrator will be able to access this module.
REQ-2: There will be an option to set the data grid by setting to view rows per page.
REQ-3: The user will have the option to sort the data grid by columns and search the required indicator.
REQ-4: There will be an option to delete the existing record.
REQ-5: The user will be able to edit the Time Period, Source and Data Value of an existing record.
REQ-6: There will be an option to generate a data entry grid by select the existing IUS combination, Area, Time Period and
Source. The user will be able to add a new time period and source while generating the data grid.
REQ-7: All data entered or edited in this module will be pending for approval before it gets published and appears in the
user interface application. This module will have the following options:
 Export Data
 Import Data
 Add/Edit Data
 Delete all or selected available data
Export Data
 Download empty data template
 Download template with data (when data is available)
This data template format is available in this document in Annexure H: Data Templates.
REQ-1: This module will have the option to download an empty data template in CSV format.
REQ-2: There will be an option to download the complete data available in the database in CSV format (once the data filled
template will be imported in the database).
Import Data
This module will help to import the data against the indicator structure that will be imported in the previous modules. This
data template format is available in this document in Annexure H: Data Templates.
 Browse data- filled template
 Import data into the database
The administrator after entering the data into the template can import the list into the database.
REQ-1: After the data as per the format, requirements is entered in the template the user will browse and upload the
template to be imported in the database.
REQ-4: The data template will be checked for duplicate and invalid entries while the import process. Below are the checks
 Rows will not be imported if the following cells are left blank:
 AreaID
 TimePeriod
 Source
 Indicator
 Unit
 Subgroup
 DataValue
 AreaID should exist in the database.
 In case a duplicate row will be found it will overwrite the old data value with the new data value when all the cells except
data value will match.
 Time period will be only imported if entered in one of the following formats:
 YYYY
 YYYY.MM
 YYYY.MM.DD
 YYYY-YYYY
 YYYY.MM-YYYY.MM
 YYYY.MM.DD-YYYY.MM.DD
Add/Edit Data
REQ-1: This will show the available data elements like an indicator, area, time period and source.
REQ-2: With the help of these data elements the user will create the data grid to enter data.
REQ-3: There will be an option to view the selected data elements.
REQ-4: “i” button will be available along with each indicator which will allow viewing the metadata of that indicator.
REQ-5: The administrator will be able to select single or multiple IUS (Indicator – Unit – Subgroup) combination, Areas,
Time Periods and Source to enter data.
REQ-6: There will be an option to enter a new time period and source in the available list.
REQ-7: There will be an option to switch on/off the selected elements.
REQ-1: Users with database administrators and data entry roles will be able to upload the data.
REQ-2: This module will have the option to download an empty data template in CSV format.
REQ-3: There will be an option to download the complete data available in the database in CSV format (once the data will
be imported in the database).
REQ-4: After the data as per the format requirement are entered in the template the user will browse and upload the
template to be imported in the database.
Create Departments
The developer of the system has to create the modules of seven different departments.
REQ-1: Each department has different kind of data according to their data types and values.
REQ-2: Each module has different kind of functionalities and fields related to the department.
REQ-3: Administrator has to choose the specific department. After that the relevant module and its specific fields
will be available on the screen.
Create Fields
The developer of the system has to create the specific fields related to the departments. Each department has their own
relevant fields. All the data from the specific fields are collected and saved on the database.
REQ-1: Each field has their own data type. The data is only entered to its related data types.
REQ-2: The administrator has to enter manually all the data and then the data will be saved to their related field
database.
Create Database
Developer has to create database according to the relevant fields of departments, so that data from all the fields will be
saved to their databases.
REQ-1: Each field has to be linked with their database, So that all the data entered will be saved and secure.
REQ-2: If the administrator changed or update the relevant data of the field, Then the data in the database will also
be changed at the current time.
Online Server
Developer has to save database to the online server so that the data will be available online and can be changed and
access from anywhere in the world by using internet. It is also more fast and safer than the local database.
REQ-1: The online server is linked with the municipal portal to access data.
REQ-2: The Nginx server is used as an online server for its speed and reliability.
1.4 Correlation
This module will show the Linear regression charts. Linear regression is a linear approach to modeling the
relationship between a scalar response (or dependent indicator) and one or more explanatory
variables (or independent indicators).
REQ-1: System administrators will be able to access this module.
REQ-2: There will be an option to set the data grid by setting to view rows per page.
REQ-3: The user will have the option to sort the data grid by columns and search the required indicator.
REQ-4: There will be an option to delete all or selected records.
REQ-5: The user will be able to update the indicators both on the X and Y-axis.
REQ-6: Show/Hide button will allow setting the status of the indicator to be shown or hidden in the user interface
application.
1.5 Language Translation

The administrator of the system will have access to this module. This module will allow translating the strings used
in the website into the other two languages – Portuguese or Tetum.
REQ-1: There will be an option to select the language from the dropdown list.
REQ-2: The data elements which will be translated are: indicator, unit, subgroup, sector, subsector, area, source,
footnote, metadata, and subgroup dimension .
REQ-3: There will be an option to select these data elements from the dropdown list.
REQ-4: The administrator will be able to download the translation template in CSV (Comma Separated Value)
formatted file after selecting the data element.
REQ-5: After the translation details as per the format requirement are entered in the template the user will browse
and import the template into the database.
1.6 Municipality Profile
The administrator of the system will have access to this module
REQ-1: The profile page will contain the municipality flags which will navigate to each municipality profile.
REQ-2: There will be an option to edit the complete details available in the profile of any municipality in all the three
languages: English, Portuguese and Tetum.
REQ-3: Each profile will comprise of the following information which will be edited:
 A picture and name of the selected municipality
 Population size, Surface area, spoken Languages, Capital name
 Administrative structure of the municipality
 Details of the municipality by topics – Geography, Toponymy, History, Climate, Points of interest.
1.7Municipality Profile
The administrator of the system will have access to this module
REQ-1: The profile page will contain the municipality flags which will navigate to each municipality profile.
REQ-2: There will be an option to edit the complete details available in the profile of any municipality in all the three
languages: English, Portuguese and Tetum.
REQ-3: Each profile will comprise of the following information which will be edited:
 A picture and name of the selected municipality
 Population size, Surface area, spoken Languages, Capital name
 Administrative structure of the municipality
 Details of the municipality by topics – Geography, Toponymy, History, Climate, Points of interest.
Other Non-functional Requirements
Performance Requirements
The system will be interactive and allow data entry and updates when the data will be made available. So in every
action-response of the system, there will be no immediate delays. In case of opening the applications and
modules, displaying of error and confirmation messages there will be delay much below 5 seconds. In case
retrieving data from the database there will be a short span delay based on the number of records to be retrieved
in one go. Loader will be implemented to make the user aware of any delays in the processes.
Safety Requirements
Information transmission will be securely transmitted to the server without any changes in information.
Security Requirements
The main security concern is for users account where all users will be created and managed by system
administrator. Pre-defined users will be created wherever required to avoid hacking. Also, the backup policy shall
be adopted by the system administrator outside the system to schedule the backup to mitigate any kind of data
loss.
Software Quality Attributes

If the internet service gets disrupted while sending information to the server, the last saved changes to the
database will be available which can be updated by the user, to avoid any discrepancies. The system will be easy
to handle and navigate in the most expected way with no delays. In that case, the system program reacts
accordingly and transverses quickly between its states.
Business Rules
The following rules are implied in the system:
 The dashboard will be developed by suggested framework and its indicators.

 Login role will identify the access to the data manager application and its modules.
 Back-end database structure will be created and linked to the user interface application to use the data.
 Best practices of web technologies will be used to design the user screens of both the user interface and
the data manager applications.
Other Requirements
This system will be designed to be adopted by similar operating clients that may have socio-economic indicators
based data for tracking, monitoring and reporting development programs and frameworks. The open-source
technology used to develop the system will be helpful in customizing, scaling and extending the functionalities to
cater to similar requirements.
Annexure A: Entity-Relation Diagram (ERD)
Annexure B: State-Transition Diagram (STD)
Data Manager
Annexure C: Data Dictionary
Area
Columns:
Id int(11)
Continent varchar(20)
Country varchar(20)
level_one varchar(50)
level_two varchar(50)
area_name varchar(50)
area_name_ar varchar(100)
area_name_tm varchar(200)
area_name_pt varchar(200)
area_code varchar(15)
original_area_code varchar(50)
parent_id varchar(15)
area_level tinyint(2)
area_group varchar(255)
Status tinyint(1)
sdmx_area_code varchar(200)
created_at timestamp
updated_at timestamp
deleted_at timestamp
Area_data
Columns:
Id int(11)
area_id int(11)
ius_id int(11)
ius_parent_id int(11)
time_period varchar(50)
sector_id int(11)
goal_id int(11)
Footnotes varchar(500)
footnotes_tm varchar(200)
footnotes_pt text
Sector varchar(255)
Subsector varchar(255)
Value varchar(50)
Source text
source_tm varchar(200)
source_pt varchar(200)
Status tinyint(1)
sdmx_source_code varchar(200)
sdmx_time_period_code varchar(200)
Area_maps
Columns:
Id int(11)
Level tinyint(2)
file_name varchar(255)
start_date date
end_date date
Status tinyint(1)
Audits
Columns:
Id int(10)
user_type varchar(255)
user_id bigint(20)
Event varchar(255)
auditable_id int(10) UN
auditable_type varchar(255)
old_values text
new_values text
url text
ip_address varchar(45)
user_agent varchar(255)
Tags varchar(255)
Corelation_mapping
Columns:
Id int(11)
y_axis int(11)
Status tinyint(4)
Corelation_mapping_child
Columns:
Id int(11)
corelation_mapping_id int(11)
x_axis int(11)
Database_information
Columns:
Id int(11)
database_summary text
database_summary_tm text
database_summary_pt text
Name varchar(255)
Institution varchar(255)
Email varchar(50)
Status tinyint(4)
Default_viz
Columns:
Id int(11)
ius_parent_id int(11)
chart_type varchar(200)
time_period varchar(200)
Default_viz_subgroup
Columns:
Id int(11)
default_viz_id int(11)
ius_id int(11)
Diet_log
Columns:
Id int(11)
Filename varchar(255)
error_filename varchar(255)
Type tinyint(1)
total_records int(11)
no_of_records_imported int(11)
no_of_records_updated int(11)
no_of_error int(11)
no_of_ius_imported int(11)
user_id int(11)
import_error text
Status tinyint(1)
IUS
Columns:
Id int(11)
Indicator varchar(500)
indicator_alias varchar(500)
Unit varchar(255)
Subgroup varchar(255)
indicator_ar varchar(500)
unit_ar varchar(100)
subgroup_ar varchar(100)
indicator_tm varchar(200)
unit_tm varchar(200)
subgroup_tm varchar(200)
indicator_pt varchar(200)
unit_pt varchar(200)
subgroup_pt varchar(200)
parent_id int(11)
default_subgroup tinyint(1)
subgroup_dimension_id int(11)
subgroup_order tinyint(4)
high_is_good tinyint(2)
Status tinyint(1)
sdmx_indicator_code varchar(200)
sdmx_unit_code varchar(200)
sdmx_subgroup_code varchar(200)
IUS_classification
Columns:
Id int(11)
level1 text
level2 text
level1_ar text
level2_ar text
level1_tm varchar(200)
level2_tm varchar(200)
level1_pt text
level2_pt text
Type tinyint(2)
parent_id int(11)
Status tinyint(1)
IUS_grouping
Columns:
Id int(11)
ius_classification_id int(11)
ius_id int(11)
Logos
Columns:
Id int(11)
logo_home_page varchar(255)
logo_inner_page varchar(255)
logo_favicon varchar(255)
logo_login_page varchar(255)
Status tinyint(1)
Meta_data
Columns:
Id int(11)
iu_id int(11)
Meta_data_translation
Columns:
Id int(11)
meta_data_id int(11)
Locale char(4)
Unit varchar(255)
mt1 text
mt2 text
mt3 text
mt4 text
mt5 text
mt6 text
mt7 text
mt8 text
mt9 text
Meta_data_translation
Columns:
Id int(11)
meta_data_id int(11)
Locale char(4)
Unit varchar(255)
mt1 text
mt2 text
mt3 text
mt4 text
mt5 text
mt6 text
mt7 text
mt8 text
mt9 text
updated_at Timestamp
Municipality_image
Columns:
Id int(11)
municipality_id int(11)
image_url varchar(1000)
image_name varchar(255)
image_name_tm varchar(255)
image_name_pt varchar(255)
Description varchar(1000)
description_tm varchar(1000)
description_pt varchar(1000)
Oauth_access_tokens
Columns:
Id varchar(100)
user_id int(11)
client_id int(11)
Name varchar(255)
Scopes text
Revoked tinyint(1)
expires_at datetime
Oauth_auth_codes
Columns:
Id varchar(100)
user_id int(11)
client_id int(11)
Scopes text
Revoked tinyint(1)
expires_at datetime
Oauth_clients
Columns:
Id int(10)
user_id int(11)
Name varchar(255)
Secret varchar(100)
Redirect text
personal_access_client tinyint(1)
password_client tinyint(1)
Revoked tinyint(1)
Oauth_personal_access_clients
Columns:
Id int(10)
client_id int(11)
Oauth_refresh_tokens
Columns:
Id varchar(100)
access_token_id varchar(100)
Revoked tinyint(1)
expires_at datetime
Sector
Columns:
Id int(11)
Name varchar(255)
Description text
Status int(11)
Share_data
Columns:
Id int(11)
chart_type varchar(50)
chart_title varchar(255)
Xaxis varchar(1000)
data1 text
data2 varchar(5000)
visualization_data text
Source text
swap_status tinyint(1)
Subgroup_dimension
Columns:
Id int(11)
Name varchar(255)
name_tm varchar(200)
name_pt varchar(200)
sdmx_dimension_code varchar(200)
Uploaded_file_info
Columns:
Id int(11)
user_id int(11)
Status tinyint(1)
source_count int(11)
ius_count int(11)
Type tinyint(4)
Uploaded_translation_file
Columns:
Id int(11)
user_id int(11)
Status tinyint(1)
Type tinyint(4)
created_at Timestamp
Users
Columns:
Id int(10)
Name varchar(255)
Email varchar(255)
Password varchar(255)
Role int(1)
Associate int(2)
email_verify tinyint(1)
remember_token varchar(100)
email_verify_token varchar(100)
Status tinyint(1)
created_at Timestamp
Annexure D: Data Flow Diagrams (DFD)
Level 0
Level 1
Level 2 – Data Manager
Annexure E: System Architecture
Annexure F: Software Architecture
Annexure G: System Flow Charts
Data Manager
Manage Area
Manage Indicator
Manage Metadata
Manage Default Chart
Data Entry / Edit
Annexure H: System Screens
Data Manager
Figure 2.1 – Data Manager – Login
Figure 2.2 – Data Manager – Data Summary

Figure 2.3 – Data Manager – Manage Area
Figure 2.4 – Data Manager – Manage Indicator

Figure 2.5 – Data Manager – Manage Metadata
Figure 2.6 – Data Manager – Manage Default Chart

Figure 2.7 – Data Manager – Manage Data
Figure 2.6 – Data Manager – Add/Edit Data

Figure 2.7 – Data Manager – Correlation
Figure 2.8 – Data Manager – Language Translation
90 | P a g e
Figure 2.9 – Data Manager – Municipality Profile
Figure 2.10 – Data Manager – Municipality Profile

---- End of the document ----

Web Application For Data Processing of Municipality Portal (Laravel Framework)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Application For Data Processing of Municipality Portal (Laravel Framework)

Uploaded by

Copyright:

Available Formats

Municipality Data Portal – Timor Leste

Software Requirements Specification

● Projects funds and investment

3. Intended Audience and Reading Suggestions

 Develop a web application to suitably store all the respected data.

 Create the specific modules, which data needs to be added or updated.

 Design and develop the relevant fields to store data.

 Update the data.

 Develop user-friendly and easy to use interface

4.1 System Applications and Modules

 Manage default chart

Unit: Measurement scale of the observation values. Example Percent, Number.

 Displaying the passwords between client and server in clear text.

 Upload malicious (.exe) file.

 Brute force attack.

 Not maintaining audit trails.

 View the authenticated page from the cache of the browser.

 Server version discloser in header response.

 Data change and control operations are managed by administrator.

 Metadata for the indicators will be managed in the data template.

Internal Memory: 32 GB RAM

Hard Disk Space: 500 MB SSD

Internet Connection: 1 Gbps

The system will be developed in the following environment:

Operating System: Ubuntu v16.04 LTS

Front-end Language: JavaScript, HTML v5, CSS v3

Visualization Library: d3.js v5, Highcharts

Front-end Framework: NGINX

Back end Language: PHP v7.1

Back-end Framework: Laravel v5.4

Database System: MySQL v5.7

Server Type: Apache v2

6.Assumptions and Dependencies

7.External Interface Requirements

Following are the details functional requirements for the application:

 Manage default chart

REQ-2: In case of invalid login, details appropriate messages will be displayed.

1.2 Data Summary

1.3 Data Template

This module will have the following options:

 Delete one or selected Areas

 Download Area Empty Template

 Download Area Template with Data (when data is available).

 Browse area filled template

REQ-3: The following validation is checked before adding department .

1.3.2 Manage Indicator

Description and Priority

 Add Indicator-Unit-Subgroup (IUS)

 Delete one or selected Indicators

This module will have the following options to:

 Download empty indicator master template

 Download indicator template with data (when data is available)

This module will have the following options to:

 Browse IUS template

 Import IUS into the database

1.3.3 Manage Metadata

Description and Priority

This module will have the following options:

 Delete one or selected metadata

 Download empty metadata master template

 Download metadata template with data (when data is available)

This module will have the following options to:

 Browse metadata filled template