Oromia Planning and Development

Commission

Requirement Analysis Document

Consultancy, Development, Training, and Commission of

Oromia Regional Integrated Development Information

Management System (ORIDMS)

Addis Ababa Institute of Technology

November 2022

Functional Requirements, Business Models and System Models

 DOCUMENT IDENTIFICATION SHEET

DOCUMENT DESCRIPTION

Document Title
REQUIREMENT ANALYSIS DOCUMENT

Subject
Requirement Analysis Document – Consultancy, Development, Training and Commission of
Oromia Regional Integrated Development Information Management System (ORIDIMS)
Abstract
Functional Requirement, Business Model and System Models
Keywords
Indicator Management, Statistical Data Management, Planning Monitoring and Reporting, Spatial Data
Management, Document Management
1.0 draft
Version 1.1 draft
1.2 Final
Consultant
Verification Acceptance
Inspection

Project Description
Under the ORIDIMS this draft RAD document contains the Functional Requirements, Non-
Functional, and Business Requirements of the System.

Project Title
Consultancy, Development, Training and Commission of Oromia Regional Integrated Development
Information Management System (ORIDIMS)

Client
Oromia Planning and Development Commission
Consultant
Addis Ababa Institute of Technology
 LIST OF DISTRIBUTION

Name Organization Date

 REVISION SHEET

Version Date Description of Revision

1.0 August 28/ 2022 Initial

Update Includes:

• Kick of meeting feedback

1.1 Draft Oct 22/2022 • Organization of the document
• Existing System
• Hardware requirement
• Workflows

Update Includes:
1.2 Dec 3/2022
• Ministry of Planning and Development
• Comments from stakeholder included
 DOCUMENT INFORMATION

Document Id ORIDMS_PI_02

Document Owner AAiT

Issue Date 22/10/2022

Last Saved Date 22/10/2022

File Name Requirement Analysis Document -V1.1

 TABLE OF CONTENTS

Document identification Sheet 2

List of Distribution 3
Revision Sheet 4
Document Information 5
Table of Contents 6
List of Figures 9
1 Introduction 10
1.1 Purpose of this Doucument 10
1.2 Format of the requirements 10
1.3 Scope of the System 11
1.4 Structure of the Document 11
1.5 Acronyms, and abbreviations 14
1.6 Legislation/Laws related to ORIDIMS 14

2 Existing Systems 15
2.1 Introduction 15
2.2 Manual Systems 15
2.3 SYSTEMS COMMISSIONED/Decommissioned 15
2.3.1 DEVINFO 15
2.3.2 SRDPO 17
2.3.3 IMS 19
2.3.4 EDUCATION 21
2.3.5 HEALTH 26
2.3.6 Investment 29
2.3.7 DIGITAL MONITORING AND REPORTING SYSTEMS (dmrs) 32
2.3.8 Other 34

3 System requirements 35
3.1 General Requirements to the ORIDIMS 35
3.1.1 Unified Common Interface 35
3.1.2 Language Support 36
3.1.3 Local date support 36
3.1.4 Local time support 37
3.1.5 security of transactions 37
3.1.6 Consistency and reliability 38
3.1.7 Automated Process Management 38
3.1.8 Easy Process Configuration 39
3.1.9 Document Management 40
3.1.10 Office and sector 40
3.1.11 Import/export 41
3.1.12 Dashboard 41
3.1.13 interactive data visualizations 42
3.1.14 Print 42
3.2 FUNCTIONAL Requirements 43
3.2.1 User and system administration 43
3.2.1.1 Access Control 43
3.2.1.2 User Authentication 43
3.2.1.3 Password complexity 44
3.2.1.4 Number of Login attempts 45
3.2.1.5 user management 45
3.2.1.6 Groups 46
3.2.1.7 Access control list (ACL) 47
3.2.1.8 List of on-line users 47
3.2.1.9 Automatic logout 48
3.2.1.10 Chanage password At First Login 48
3.2.2 Indicator management 49
3.2.2.1 Indicator Definition 49
3.2.2.2 INDICator Dimensions 49
3.2.2.3 INDICator Dimensions Target 50
3.2.2.4 INDICator INPUT 50
3.2.2.5 Dashboard 51
3.2.3 Planning Monitoring and Reporting management 51
3.2.3.1 Plan Definition 51
3.2.3.2 Predefined Plan 52
3.2.3.3 Custom Plan 52
3.2.3.4 Predefined REport 53
3.2.3.5 Custom Report 54
3.2.3.6 Aggregated Plan 54
3.2.3.7 Aggregated Report 55
3.2.3.8 DE-Aggregated Plan 56
3.2.3.9 de-Aggregated Report 56
3.2.3.10 Dashboard 57
3.2.3.11 Notification 57
3.2.4 Statistical data management 58
3.2.4.1 Statistical Data Definion 58
3.2.4.2 statistical data entry 58
3.2.4.3 Content Search 60
3.2.4.4 Data Update 60
3.2.4.5 Data DELETE 61
3.2.4.6 Data validation and verfication 61
3.2.4.7 Data Analytics 62
3.2.4.8 Dashboard 62
3.2.4.9 Statistical abstract 63
3.2.4.10 custom Report 63
3.2.4.11 Population data 64
3.2.5 Document management 64
3.2.5.1 Browse folder 64
3.2.5.2 View document 65
3.2.5.3 UPload document 66
3.2.5.4 download document 66
3.2.5.5 Delete document 67
3.2.6 Spatial data management 67
3.2.6.1 spatial and non-spatial data 67
3.2.6.2 spatial data transformation 68
3.2.6.3 spatial data entry 68
3.2.6.4 spatial data Analaysis 69
 3.2.6.5 spatial data Import 69
3.2.6.6 spatial data export 70
3.2.6.7 Spatial Unit Group 70

4 Workflow 72
4.1 Security And User Management 72
4.2 Forms Data Flow 73
4.3 Planning, Monitoring and Report Management Systems 75
4.4 Document Data Flow 76

5 Server Requirements 77
 LIST OF FIGURES

Figure 1- Indicator Management (DevInfo) 16

Figure 2 - Data Entry (DevInfo) 16
Figure 3 - Data Exchange (DevInfo) 17
Figure 4 - Home Page (SRDPO) 18
Figure 5 - Indicator Management (SRDPO) 18
Figure 6 - Data Management (SRDPO) 19
Figure 7 - Reporting (SRDPO) 19
Figure 8 - Main Page (IMIS) 20
Figure 9 - Indicator Management (IMIS) 20
1 INTRODUCTION

1.1 PURPOSE OF THIS DOUCUMENT

This Requirements Analysis Document contains the outcomes of AAiT's requirements elicitation
and analysis activities (RAD). The proposed system is described in this document in terms of
functional and non-functional requirements. This RAD is written in the language of the
customer's domain of business/expertise.

The intended audience includes the customer, the end users, the project management, the system
analysts, the system designers, and the developers who will be implementing the system.

The first part of the document, including functional and non-functional requirements, is written
during requirements elicitation. The formalization of the specification in terms of high-level
object models is written during analysis.

1.2 FORMAT OF THE REQUIREMENTS

Each requirement is structured in a subtitle with the following common components:

Requirement Id <ID if the requirement>

Importance <Mandatory>, <Optional>, < Desired>
Description Here is included description of the requirement including as much
detail as possible in the format of a [shall]/[should] list
User Story The requirement expressed in a User Story format. i.e.
As a/an [actor], I want [action] so that [achievement]

Source <Legislation>, <ISO or other standard>, <International experience>,

<other>
Acceptance A list of acceptance criteria to evaluate compliance of the system with
Criteria the requirement. This list can and will be expended for the RFP and
will serve as one source for the test plan.
1.3 SCOPE OF THE SYSTEM

Project scope is used to define what major system functions, modules, and interfaces will be
included in the implementation effort of the project.

It is important to define both what will be included in scope and a basis for making future project
decision and clearly ensures a common understanding amongst all project stakeholders.

The project scope includes discovery, build, testing and training of the Oromia Regional
Integrated Development Information Systems that consists of the components mentioned below:
• Statistical Data Management System
• Spatial Data management System
• Planning, Monitoring and Report Management Systems
• Indicators Management Systems
• Document Management Systems
• Security and User Management Systems

1.4 STRUCTURE OF THE DOCUMENT

This document is composed of different sections, each grouping requirements in a logical and
modular way. The components of the document are:

Introduction: This section lists the general aspects of the RAD organization (including this
subtitle)

Existing System: A brief description of their systems in place (manual and computerized) in
order to understand the current system and workflow of the various modules that includes the
components Statistical Data Management System, Spatial Data management System, Planning,
Monitoring and Report Management Systems, Indicators Management Systems, Document
Management Systems, Security and User Management Systems.

System Requirements: In this section are listed the requirements to the ORIDIMS and organized
with the following sections:
General Requirements to the ORIDIMS: The requirements listed here are a high-level
description of the expected functionalities. Most of these requirements are elaborated on in
detail in the following sections but listed here to get a general picture of the entire system.

Functional Requirements (FR) – General Functionality: As in the previous section, this

title list general functional requirements, which are required across the entire system and
can be applied to more than one specific module.

FR - User and Security Management: Describes the functionality expected from the system
in regards to the administration of the system users, including security measures and
organization of the user privileges.

FR – Indicator Management: Describes the functionality expected from the indicator

management to handle the various indicators of the Oromia region and ORIDIMS system.

FR – Planning Monitoring Reporting Management: Describes the functionality of the

planning, monitoring, and reporting that relate to the Oromia Strategic plan.

FR – Statistical Data Management: Describe the functionality expected from the system to
handle the Oromia statistical data.

FR – Spatial Data Management: includes general functions expected from the system in
regards to the handling of the spatial information and lists the minimum tools expected to
be incorporated into the system to handle the spatial units and other spatial information
that will be stored and associated with the ORIDIMS.

FR – Document Management System: This section provides the guidelines and minimum
functionality expected from the system to handle digital documentation. Also specifies the
characteristics of the document management system that is expected the ORIDIMS will
incorporate.

FR – Reporting requirements: This section contains the minimum expected functionality

from the ORIDIMS to handle the reports. The section doesn’t list the specific reports, as
they need to be defined and elaborated during the development and implementation phase.
However, the requirements list the capabilities expected to accomplish the task.
 FR – System Configuration: The system should be configuration easy, and the expected
functionality on this matter is listed here.

FR –UI General: This section list the general and standard guidelines to the user interface.
The requirements on this section provide a basic and general description of the system
behaviour at the presentation layer to the end user.

FR – Web Portal: is expected the ORIDIMS to have a web portal to interact with the end
customers. These sections describe the minimum expected behaviour of the mentioned
portal to support the interaction of the system with the general public.

Workflows and Descriptions: The sections detail the processes supported by the system. The
business processes described here should be taken as a starting point for the configuration of the
system, and is expected this procedure to be dynamic and easy to configure to reflect the
necessary changes to the defined activities at the registration offices.

Detail of transactions: The section describes in more detail the minimum supported transactions,
the inputs, and expected outputs as possible variations to the standard behaviour.

Hardware Requirements: The various components of the ORIDIMS are expected to consume
various hardware resources. This section list the minimum required specifications to guarantee a
good performance of the system.

Network Requirements: The volume of data expected to be interchanged between the different
administration units requires the support of specific hardware requirements. The list described
here addresses the infrastructure required to support the described operations.

Security Requirements: The requirements listed here depict the minimum security measures the
system will support to ensure the quality and trustiness of the data
1.5 ACRONYMS, AND ABBREVIATIONS

AAiT Addis Ababa Institute of Technology

DMS Document Management System
IMIS Integrated Management Information System
KPI Key Performance Indicator
OPDC Oromia Planning and Development Commission
ORIDIMS Oromia Regional Integrated Development Information Management System
PMRM Planning, Monitoring, Reporting Management
SDM Statistical Data Management
SUM Security and User Management
SRDPO Strengthening Regional Development Planning in Oromia

1.6 LEGISLATION/LAWS RELATED TO ORIDIMS

No Name

1/1995 Proclamation of the Constitution of Federal Democratic Republic of Ethiopia

242/2014 Proclamation of the Establishment of Oromia Planning and Development

Commission
2 EXISTING SYSTEMS

2.1 INTRODUCTION

This section of the document describes the existing manual and/or digital systems that have been
commissioned/decommissioned. This will help us to understand the existing business process
well and to identify the new business requirements. It will also describe the bottleneck and
limitations of the previous workflow in order to enhance the proposed system.

2.2 MANUAL SYSTEMS

Currently, most of the business processes are running manually except few that includes ……

2.3 SYSTEMS COMMISSIONED/DECOMMISSIONED

The following systems were in place and decommission for various reasons.

2.3.1 DEVINFO

DevInfo is a database system for data entry, monitoring, organizing, storing, and presenting data
in a uniform way to facilitate data sharing at the regional level across government departments.
The system is primarily a desktop application available in two flavors: DevInfo Data Admin and
DevInfo User Application. The data admin is used by the system administrators to create a
template/format. It has functionalities where the administrator can define indicators and
associated information about those indicators, Areas and upload shape files. The data admin
flavor is also used for data entry. It has UIs for Template definition, import/export, reporting,
API like data exchange, mapping, language support, and Standard definition.

The User Application is mainly used for generating data that is already entered through Data
Admin. It has features that produce tables, graphs, and maps for inclusion in reports,
presentations, and advocacy materials. The main defect of this system is that it can’t support a
new area or an existing area is modified. In addition, it has no feature for user management and
data auditing. The system is no longer being used.
Here are some examples of screenshots from DevInfo:
Figure 1- Indicator Management (DevInfo)

Figure 2 - Data Entry (DevInfo)

 Figure 3 - Data Exchange (DevInfo)

2.3.2 SRDPO

SRDPO (Strengthening Regional Development Planning in Oromia) is a web-based regional geo-

database system to support the Oromia region Finance Bureau in elaborating socio-economic
data. It has features for indicator management, spatial data management, and Statistical data
management which can be used for planning, reporting, monitoring, and evaluation. Since it was
developed to be used for the finance bureau of the region, after OPDC was structured be an
independent office, it failed to be inline with the mandate of the OPDC. Apart from that, this
system is flexible to support changes in the areas of the region, such as kebeles, woredas, and
zones.
Some of the looks and feels of the SRDPO are presented as follows:
 Figure 4 - Home Page (SRDPO)

Figure 5 - Indicator Management (SRDPO)

 Figure 6 - Data Management (SRDPO)

Figure 7 - Reporting (SRDPO)

2.3.3 IMS

Integrated Management Information System (IMIS) is a web-based information management

system developed to be used for offices across Oromia region. It is a system developed with the
vision of centralizing the working of all offices/bureaus. The system provides a link for each
office captioned with its name. Each office has a distinct login credential, and they use the system
independently. The system has such features as user/role management, indicator management,
metadata management, spatial data management, and template development. The system looks
like this:
 Figure 8 - Main Page (IMIS)

Figure 9 - Indicator Management (IMIS)

2.3.4 EDUCATION

StatEduc2
The Oromia Education Bureau uses StatEduc2 for the entry and processing of statistics data. It
collects and modifies statistics data for all five areas of education: kindergarten (pre-primary),
primary, secondary, alternative basic education (ABE), and integrated functional adult literary
education. The WAMP stack is used for the development and deployment of this web-based
system. For the woreda and zonal offices, each user has a separate copy of the system installed
independently on their PC. The system contains two user groups for managing users: admin and
data entry. Data entry formats must be defined, created, and modified by the admin group. The
data entry groups' job is to enter statistical data and produce reports, and they share a common
username and password. The system had roughly twenty-six (26) forms defined for each format
at the time of this visit. The team realized how much the bureau's operation depends on this
system. This system generates every report that is transmitted to higher officials and the OPDC
in MS-Excel format. The system lacks an API or other built-in mechanism for connecting with
other programs.

There will be a significant delay in getting data using this system because every system user down
from the woreda level up to the zonal level is dependent on one another to complete their task,
meaning that the woreda must compile data from each school in the woreda and send it to zone,
and the zone office must in turn compile and merge all data from each of its woreda before it is
sent to the region. With this approach, there is no way for the bureau to obtain current, live data.
This is why the bureau is implementing a new central system called Data Management
Information System (DMIS) beginning of the current fiscal year.

OREB School Information Management Platform (O-SIMP)

This new system is implemented as of the current budget year. It is a bureau-hosted centralized
system. The woreda and zonal branches of the bureau have access to it through WoredaNet, and
each user has a defined roles and access rights that are centrally managed. The bureau is able to
gather real-time statistical data of students from across the region.
The implementation of the O-SMIP solution is to collect and manage data as well as generating
real-time reports focused on

• Students Profile and Tracking System

• Teachers Profile and Professional Development
• Schools Profile and Management
• Incident Reporting and Response
• School Feeding Program
• CTEs Profile and Professional Development
• Book Tracking and Management System
• Boarding School Data and Information
• Broadcasting Services Information Management
• Need Assessment (Students, Teachers, Schools and others)

As the system is new to the bureau, the team is unable to obtain much information regarding how
the system works, how reports are generated, whether there is API features built into the system,
its user management and the likes.

Figure 10 - O-SIMP Dashboard

 Figure 11 - O-SIMP Transcription Form

Figure 12 - O-SIMP Report Charts

IIMS (Investment Information Management System)

A web-based system called IIMS is utilized to manage the workflow at the Oromia Investment
Bureau (OIB). The OSTA (Oromia Science and Technology Agency) used MVC architecture when
designing and developing the system. It features about eleven (11) modules that help the bureau's
workflow. There are further modules for user management and system auditing. This technology
is used by every tailored office of the bureau throughout the region, starting at the woreda level,
to complete almost all of their daily tasks. The system also creates reports in a variety of formats,
and MS-Excel files are the primary method of report interchange between the bureau and OPDC.
Even if the team is unable to receive confirmation from OIB specialists as to whether the system
has an API extension for interoperability and information exchange, it is anticipated that
obtaining related information will be simple given that the system was developed locally.

Figure 13 - Investor Registration Form

 Figure 14 - Project Detail Interface

Figure 15 - Investment Status Report Visualizer

2.3.5 HEALTH

DHIS2
DHIS2 is a software platform for collecting, analysing, visualizing and sharing data used at the
Oromia Health Bureau (OHB). As opposed to other systems being analysed, this system is not
solely owned by the OHB. It is rather hosted at the federal Ministry of Health (MoH) and the
ministry administers the system. All regional health bureaus use this system. The system
supports both aggregate and individual-level data including features for monitoring and
following up with individual people or entities over time and online and offline data entry via
the DHIS2 web portal, mobile Android app, SMS, or direct import. The team realized that the
system is a matured system and the internal working of the OHB is highly relies on the system
for data collection, validation, verification and report generation.

Even though OHB lacks knowledge of the backend and interoperability of the system with other
systems, we are able to learn from the system’s documentation that the system has excellent
capabilities for system integration and interoperability and features its own format for meta-data
and data exchange called DXF 2 as well as the ADX standard. The vast REST-based Web API of
the system makes it simple to integrate with other information systems and third-party clients
like Android apps and Web portals. Even scheduled integration jobs can be created to import or
synchronize data from various sources on a regular basis. However, so far, OHB has been sending
reports to the OPDC using MS-Excel forms.
 Figure 16 - DHIS2 Data Entry Form

Figure 17 - DHIS2 Custom Data Form

 Figure 18 - DHIS2 Data Visualizer

eCHIS (Electronic Community Health Information System)

Although DHIS2 is used to record the majority of data at the OHB, a different system called eCHIS
is also employed to record information about households. It is the system used to utilize
technology and data to improve health service delivery, starting at the community level. It is the
digitized version of the paper based CHIS, one of the backbones of the much successful region’s
health extension program. The application is a suite of mobile applications with a web based
monitoring portal. It captures electronic data on the Health Extension Program (HEP) and other
community-level services, as well as utilizes this data to improve HEP performance, community
health outcomes, and also as serve a job aid to Health Extension Workers (HEW). Other
advantages of eCHIS are enabling easy reporting and analytics, facilitating electronic household
and population registry, supporting service delivery and tracking, easy client identification and
facilitating communication with the Health center.

At the medical center, data entry is mainly done. However, woreda and zonal officials have the
option of providing their own administration-related data. Health service officials, who are
mostly IT experts, enter the data related to the health services. The system has four main modules:
Digital family folder, Reproductive maternal newborn and child health (RMNCH), Disease
prevention and control (DPC) and Logistic supply and management.
 Figure 18 - eCHIS Dashboard

2.3.6 INVESTMENT

IIMS (Investment Information Management System)

A web-based system called IIMS is utilized to manage the workflow at the Oromia Investment
Bureau (OIB). The OSTA (Oromia Science and Technology Agency) used MVC architecture when
designing and developing the system. It features about eleven (11) modules that help the bureau's
workflow. There are further modules for user management and system auditing. This technology
is used by every tailored office of the bureau throughout the region, starting at the woreda level,
to complete almost all of their daily tasks. The system also creates reports in a variety of formats,
and MS-Excel files are the primary method of report interchange between the bureau and OPDC.
Even if the team is unable to receive confirmation from OIB specialists as to whether the system
has an API extension for interoperability and information exchange, it is anticipated that
obtaining related information will be simple given that the system was developed locally.
Figure 19 - Investor Registration Form
 Figure 20 - Project Detail Interface

Figure 21 - Investment Status Report Visualizer

2.3.7 DIGITAL MONITORING AND REPORTING SYSTEMS (DMRS)

DMRS is a system used at the Ministry of Planning and Development (MoPD) for monitoring the
planning, performance evaluation and reporting activities of the minister offices. All minister
offices have access to the system by which they can define their plan, execute their performance.
The system is organized into four main modules: Result Matrix, Evaluation and Grading,
Reporting and Sustainable Development Goal (SDG). Main services provided by the system are:
• KPI definition, measurement and evaluation using color coding scheme
• Sector definition that combine minister offices according to their mandate area
• Template definition for each ministerial office to help them develop consistent reporting
system
• Independent user access for each ministerial offices
• Data visualization tools for view performance results
• Chatting service with minister offices to provide technical support with regard to system
usage
• Report aggregation and disaggregation
• Make public feature to extract aggregated summary/abstract report that reflects the
actual scenario of the country

With the help of the system MoPD is able to collect consistent reports within the deadline. This
on the other hand enabled the ministry to generate country level aggregated report. The system
doesn’t have feature to allocate budgets which they have considered it in their future plan. In
addition they have also a plan to make the system AI powered integrated with data science,
business intelligence to achieve their motto of One plan, One report, One budget. Ensuring data
quality is the main problem they find it hard to achieve so far.
 Figure: DMRS Dashboard

Figure: Minister Office Page

Figure: Result Framework Definition

 Figure: KPI Definition Page

2.3.8 OTHER

As part of the document and system analysis, one of the external systems being observed is the
system being used by the Oromia Vital Registration Agency. The system is named as Oromia
Civil Registration and Vital Statistics (OCRVS). It is a web-based system developed with Code
Egniter and MySQL DB. The system supports the business logic of the agency from registration
up to certificate issuance. The system has role and user management features. Many of the
administrative activities roles are given to users at the regional level, and the data entry roles are
given to users at the kebele level.

OPDC provides information such as newly established kebeles, woredas, and zones to this
agency. The agency in return, provides information such as birth information, and population
data included in the vital registration. This system doesn’t have an API notion. It, however, has
an import/export feature for data exchange.
3 SYSTEM REQUIREMENTS

The system requirements detailed below are characteristics expected from the ORIDIMS that
intend to cover the different modules, activities, processes, and business rules to be implemented
for the support and computerization of the ORIDIMS system.

Given the agile nature of the system development, is expected to have adjustments during the
development phase, it is also expected to have components that are easy to configure and
customize. The description below is the starting point but is expected to have modifications and
adjustments on the iterative reviews until the end of the development cycle so that we can
guarantee usability and support to the ORIDIMS activities at the regional and the lower
administration level.

3.1 GENERAL REQUIREMENTS TO THE ORIDIMS

3.1.1 UNIFIED COMMON INTERFACE

Requirement GEN-1
Id
Importance Mandatory
Description The ORIDIMS shall be developed or customised as integrated software
with common interface for the ORIDIMS components.

User Story As an user, I want to use the system modules with a unified common
interface so that I can use the system with a homogeneous GUI and
handle similar new functions without additional training
Source International Best Practices
Acceptance • The system look and feel is the same in each module and
Criteria contains homogeneous UI items.
• Once logged in to the system is possible to access to all features
(with possible exception to the scanning module) without need
to log in again
3.1.2 LANGUAGE SUPPORT

Requirement GEN-02
Id
Importance Mandatory
Description The ORIDIMS shall support an interface in Oromiffa, Amharic, and
English languages.
The help in context, help files and documentation should be produced
also in the languages supported by the system.
User Story As an user, I want to use the system in my native language so that I can
work more efficient without the need of learn a foreign language to do
my work
Source TOR
Acceptance
Criteria

3.1.3 LOCAL DATE SUPPORT

Requirement GEN-03
Id
Importance Mandatory
Description The ORIDIMS shall support the Julian and Gregorian Calendar
performing the automatic conversion between both and including the
ability to report in both systems.
User Story As an user, I want to use the local date format and allow the system to
handle the conversion so that I don't need to worry about entering the
date twice in the transactions
Source Best Practice
Acceptance • The user input the date in an international format and the
Criteria system converts it automatically to local date format.
 • The user input the date in a local format and the system converts
it automatically to International date format

3.1.4 LOCAL TIME SUPPORT

Requirement GEN-04
Id
Importance Mandatory
Description The ORIDIMS shall allow the user to enter the time in a local or
international format and convert it automatically to the other in order to
support both Ethiopian and International time systems
User Story As an user, I want to use the local time format and allow the system
handle the conversions so that I don't need to worry about enter the time
twice in the transactions
Source Best Practice
Acceptance • The user input the time in an international format and the system
Criteria converts it automatically to local time format.
• The user input the time in a local format and the system converts
it automatically to International time format

3.1.5 SECURITY OF TRANSACTIONS

Requirement GEN-05
Id
Importance Mandatory
Description The ORIDIMS shall maintain the security of all transactions, efficiency,
and quality of data, accuracy, consistency, and transparency of regional
data.
 User Story As a customer, I want to have my data physically and digitally secured
within the appropriate registration body so that I don't need to
physically secure it by myself
Source Main purpose of the project / International best practices
Acceptance • Documents from the system can only be produced automatically
Criteria with minimum intervention of the user and pulling out the
information from the data storage.
• Documents produced by the system contain a signature
mechanism with information that helps in the validation of the
data being produced by the system.

3.1.6 CONSISTENCY AND RELIABILITY

Requirement GEN-06
Id
Importance Mandatory
Description The ORIDIMS shall have validation and data quality control procedures
to ensure the consistency and reliability of information, avoid the data
duplications and minimise errors
User Story As an user, I want to have validation by the system on the entered data
so that I can be sure on the consistency and no duplication of the
information
Source International best practices
Acceptance
Criteria

3.1.7 AUTOMATED PROCESS MANAGEMENT

Requirement GEN-07
Id
Importance Mandatory
 Description The ORIDIMS shall contain a Workflow Management (WFM) integrated
all levels that can provide a capability of the assignment of the tasks,
cases and documents to individual authenticated users and when
necessary, group of users
User Story As an user, I want to work with tasks that are assigned to me on the
processes and on which I have ownership so that the entire process
sequence will be organised and ensure that just authorised personnel
can work on each individual task
Source International best practices
Acceptance
Criteria

3.1.8 EASY PROCESS CONFIGURATION

Requirement GEN-08
Id
Importance Mandatory
Description The WFM shall have a user-friendly graphical interface and allow easy
modification of the workflow according to the established procedure

User Story As a system administrator I want to have a user-friendly GUI to manage

the processes so that I can edit permissions and modify processes and
tasks later, to adapt the changes in the environment
Source International best practices
Acceptance
Criteria
3.1.9 DOCUMENT MANAGEMENT

Requirement GEN-09
Id
Importance Mandatory
Description The ORIDIMS shall integrate a Document Management System (DMS)
engine and Spatial Data Management to ensure efficient functioning of
the system
User Story As a user, I want the system to control the access and storage of the
digital documents so that the information can just be accessible with
privileges to avoid direct access to the digital information through the
operating system
Source International best practices
Acceptance
Criteria

3.1.10 OFFICE AND SECTOR

Requirement GEN-10
Id
Importance Mandatory
Description The system shall create sectors and offices at various administration
hierarchy of the region

User Story As a system user, I want to create sectors and offices at all
administration levels (such as region bureau, zone, city, woreda, kebele)

Source TOR
Acceptance • If the user wants to create a new office, an office with its roles,
Criteria capabilities, and functions will be created.
• Additional role can also be assigned for the office
3.1.11 IMPORT/EXPORT

Requirement GEN-11
Id
Importance Desirable
Description The user shall be able to import and export any allowable data to the
system

User Story As a user, I want to import and export data into and from the system by
uploading and downloading the spreadsheet.

Source International best practices

Acceptance • The system can be able to show a template for import
Criteria • The system can display the imported data without any
discrepancy
• The system can provide a validation for the import data by
checking the allowable data for each field
• The user can be able to download the required data with export
functionality.

3.1.12 DASHBOARD

Requirement GEN-12
Id
Importance Desirable
Description The user shall be able to create dashboards that provide a single-screen
snapshot view of various components

User Story As a system user, I want create dashboard that provide a single-screen
snapshot view of various KPIs, business analytics metrics, and critical
data points, placed in the form of panel.
Source International best practices
Acceptance • Once the user has logged onto the system, the system shall
Criteria display the user customized dashboard.
 • Only those eligible users which have create dashboard allowed
to create

3.1.13 INTERACTIVE DATA VISUALIZATIONS

Requirement GEN-13
Id
Importance Desirable
Description The system provides charts, graphs, and visualization with interactions
such as scaling, linking, tooltip, mouse, and touch events.

User Story As a system user, I want to view charts, graphs, and visualization with
interactions such as scaling, linking, tooltip, mouse, and touch events.

Source International best practices

Acceptance • Once the user has logged onto the system, the system shall
Criteria display visualization tools that allow the user to view charts and
graphs.

3.1.14 PRINT

Requirement GEN-14
Id
Importance Desirable
Description The ORIDIMS shall have a tool to print contents/maps.

User Story As a user, I want to print contents/maps so that I can facilitate the
various activities.

Source International best practices

Acceptance
Criteria
3.2 FUNCTIONAL REQUIREMENTS

3.2.1 USER AND SYSTEM ADMINISTRATION

3.2.1.1 ACCESS CONTROL

Requirement FUSA-01
Id
Importance Mandatory
Description The ORIDIMS shall provide a mechanism to define and control the
access to the system and any data or information in the system.

The control should include, but not limited to:

• Restriction to access specific type of information

• Different Authorisation Levels
• Timeouts
• User profiles
• Password Complexity
User Story As a product owner, I want the system contain an access control
mechanism so that I can be sure that the information is accessed with
defined limits.
Source International Best practices, ISO 27002
Acceptance • The system provides access to the allowed portions for the user.
Criteria • The system handle user profiles
• Is possible to define authorization levels within the system

3.2.1.2 USER AUTHENTICATION

Requirement FUSA-02
Id
Importance Mandatory
 Description The ORIDIMS system shall enforce the individual authentication of all
users, networks and applications to access the system.

User Story As a product owner, I want all users and application to be individually
authenticated in the system so that I can keep track of the access to the
information within the system.
Source International Best Practices, ISO/IEC 27002
Acceptance • A user cannot access to the system without being authenticated
Criteria • The authentication details should be validated by the system
• An Application can not consume services from the system
without being authenticated

3.2.1.3 PASSWORD COMPLEXITY

Requirement FUSA-03
Id
Importance Mandatory
Description The ORIDIMS shall enforce the use of lengthy and complex passwords
or passphrases, consisting of a mix of letters, numerals, and special
characters that would be difficult to guess.
User Story As a system Administrator, I want to all users have complex password
so that the security of the information not be compromised because an
easy to guess or simple password.
Source ISO/IEC 27002
Acceptance • A user cannot create or change a password if doesn't comply
Criteria with the complexity required
• Passwords need to contain a set of predefined minimum
characters configured in the system but not less than 8
characters.
• A user cannot enter a password if doesn't contain a mix of
numeric, alphanumeric and special characters.
3.2.1.4 NUMBER OF LOGIN ATTEMPTS

Requirement FUSA-04
Id
Importance Mandatory
Description After a predefined number of unsuccessful login attempts the ORIDIMS
shall lock the account and generate security log entries and security
alerts.
User Story As a system administrator, I want to limit the number of failed attempts
that a system user can do so that I can reduce the risk of brute force
hacking in my system.
Source ISO/IEC 27002
Acceptance • A user cannot access to the system after exceed the predefined
Criteria number of unsuccessful attempts
• Security logs are generated for each unsuccessful attempt to log
in to the system

3.2.1.5 USER MANAGEMENT

Requirement FUSA-05
Id
Importance Mandatory
Description The ORIDIMS shall allow the management of system users including the
capability to create, edit and archive each of them individually. The
Management include the ability of assign initial passwords, lock and
unlock users leaving traces in the log about the activities performed.
The User details to be included should include, but not limited, to:
• Username
• Password
• Full Name (first, father and grandfather name) (mandatory)
• Complete personal Address (mandatory)
• Telephone number
• Region (mandatory)
 • City (mandatory)
• Zone (mandatory)
• Woreda (mandatory)
• Office (mandatory)
• Email address (mandatory)

User Story As a system administrator, I want to manage the users within the system
so that I can create, edit, archive them using the tools provided in the
application.
Source International experience, Security Requirements
Acceptance • A user can be created in to the system and once assigned
Criteria necessary privileges, to access in to the system with the necessary
authentication
• All user details can be edited with the exception of the username.
• A password can be changed if complies with the password
complexity requirement.
• All actions performed at the user administration shall create a
log
• A user can be archived (disabled) from the system

3.2.1.6 GROUPS

Requirement FUSA-06
Id
Importance Mandatory
Description The ORIDIMS shall support the notion of Groups; each group can be
composed of users or other groups.
User Story As a System Administrator, I want to be able to create groups in to the
system so that I can assign privileges to groups instead of individuals.
Source Security Standards, International Experience
Acceptance • A user can be assigned to one or more groups
Criteria • A group can be assigned to another group.
• A group can be composed by users and groups
3.2.1.7 ACCESS CONTROL LIST (ACL)

Requirement FUSA-07
Id
Importance Mandatory
Description The ORIDIMS shall manage Access Control Entries (ACE) associated a
single authority (users or groups) to a single permission group or
permission, and state whether the permission is to be allowed or denied.
The ACE's shall be grouped into an Access Control List that handles all
ACE and the global permissions.
User Story As a product owner, I want to have Access Control List (ACL) in to the
system so that I can manage permission to groups and users with Access
Control Entries (ACE) for each object in the application.
Source Security Standard
Acceptance • An object in to the system cannot be accessed if the user or group
Criteria is not included in the ACE associated to the object.
• An object defined with an ACE can be accessed by users or
groups (authorities) that are listed in the parent ACL

3.2.1.8 LIST OF ON-LINE USERS

Requirement FUSA-08
Id
Importance Mandatory
Description The ORIDIMS shall have the functionality to display to an authorised
authority the list of connected users. The information displayed must
contain a predefined set of attributes of each user.
User Story As a system administrator, I want to be able to see the users logged in to
the system and the IP address or computer name so that I can control
any abnormal connection to the system.
Source Best practices
 Acceptance • If a user is logged in to the system needs to be listed in the on-
Criteria line list produced by the administrator.
• If a user log out of the system, the list should be automatically
updated to remove the user from it.

3.2.1.9 AUTOMATIC LOGOUT

Requirement FUSA-09
Id
Importance Mandatory
Description The ORIDIMS shall logout users if the account is inactive for some
predefined amount of time to prevent the use of the active session if the
user left the computer unattended.
User Story As a system administrator, I want the system automatic logout a user
after predefined time of inactivity so that can help to prevent the access
of an unauthorised person if the computer left unattended.
Source ISO/IEC 27002
Acceptance A user cannot perform any action in the system if is inactive more than
Criteria the predefined time.

3.2.1.10 CHANAGE PASSWORD AT FIRST LOGIN

Requirement FUSA-10
Id
Importance Mandatory
Description The ORIDIMS shall force new users to change the password when login
first time enforcing the necessary complexity as described before.

User Story As a system user, I want the system prompt me to change my password
the first time I log in so that I can define my own secret password and
enforce the security of my account.
Source ISO/IEC 27002
 Acceptance A user cannot perform any action in the system if the password is not
Criteria changed after first time log in.

3.2.2 INDICATOR MANAGEMENT

3.2.2.1 INDICATOR DEFINITION

Requirement FIM-01
Id
Importance Mandatory
Description The ORIDIMS shall create indicators and sub-indicator group for
different sectors.

User Story As a user, I want the system to define any type of indicator for targeted
sector.

Source TOR
Acceptance • The user will be able to define indicator properties such as
Criteria Government Focus, Continuous, Graduated
• The user can label KPI out of the indicators
• If the indicator is created successfully, it show the list of indicator
with their corresponding sectors.
• If there is a sub-indicator, the indicator should be listed in the
parent indicator

3.2.2.2 INDICATOR DIMENSIONS

Requirement FIM-02
Id
Importance Mandatory
Description The ORIDIMS shall create dimensions or sub indicator and its values
with the unit of measurements.
 User Story As a user, I want the system to define dimensions for the indicators with
its value and unit.

Source TOR
Acceptance • The indicator dimensions should be associated with the indicator
Criteria • The dimension must have a name and unit of measurement
• The indicator dimension must be unique

3.2.2.3 INDICATOR DIMENSIONS TARGET

Requirement FIM-03
Id
Importance Mandatory
Description The ORIDIMS shall set a base and target value for the indicator
dimensions for specific period.

User Story As a user, I want to set a target and base value for each indicator
dimensions.

Source TOR
Acceptance • The user can define target and base value for each indicator
Criteria dimensions

3.2.2.4 INDICATOR INPUT

Requirement FIM-04
Id
Importance Mandatory
Description The ORIDIMS shall provide an interface to enter data for the defined
indicators.

User Story As a user, I want to enter data for any indicators defined for a specific
period.
 Source TOR
Acceptance • The user can enter data for the existing list of indicators.
Criteria

3.2.2.5 DASHBOARD

Requirement FIM-05
Id
Importance Mandatory
Description The ORIDIMS shall provide (role-based) dashboard to for each indicator
to see overall performance of the region

User Story As a user, I want to see the status of the submission and the submitted
data and also the overall performance of the region

Source ISO/IEC 27002

Acceptance • The user can be able to see the indicator
Criteria • The user can be able to see the overall performance of the
indicator

3.2.3 PLANNING MONITORING AND REPORTING MANAGEMENT

3.2.3.1 PLAN DEFINITION

Requirement FPMRM-01
Id
Importance Mandatory
Description The ORIDIMS shall create components of the plan (goals, aims,
activities) including with their KPI.

User Story As a Planner, I want the system to create goals, aims, and activities
along with their viable KPI and Unit of Measurement

Source TOR
 Acceptance • The planner can define the goal
Criteria • The planner can define the aims under the goal
• The planner can define the activities under the aim
• The planner can define the KPI for each activities
• The planner can set one or more units for each KPI

3.2.3.2 PREDEFINED PLAN

Requirement FPMRM-02
Id
Importance Mandatory
Description The ORIDIMS shall create annual and quarter plans based on the pre-
defined KPI.
User Story As a user, I want the system to create annual and quarterly plans by
setting my targets for the predefined Goals, Aims, and Activities

Source TOR
Acceptance • The system will be able to create RBM based planning scheme.
Criteria • The system will provide an interface to enter long range plans of
5 year and 10 year plans
• If the target is set for each activity, then it will create a plan
(annual and quarterly plan) (mandatory) for the corresponding
sector/office.
• The system can provide the KPI and Unit of Measurement
• The system will be able to accept major activities, projects,
programs for planning
• The user can assess different plan containing major indicators
• The system shall allow to prepare M&E plan of action monthly,
quarterly, semi-annually and annually

3.2.3.3 CUSTOM PLAN

Requirement FPMRM-03
Id
 Importance Mandatory
Description The ORIDIMS shall create annual and quarter plans Custom Plan.

User Story As a user, I want the system to create Custom annual and quarterly
plans by setting my targets for the custom Goals, Aims, and Activities

Source TOR
Acceptance • The User can be able to create custom goals, aims and activities
Criteria that can be appended to the annual and quarterly plan
• The user can assess different custom plan containing major
indicators
• The system shall allow to prepare M&E plan of action monthly,
quarterly, semi-annually and annually

3.2.3.4 PREDEFINED REPORT

Requirement FPMRM-04
Id
Importance Mandatory
Description The ORIDIMS shall create annual and quarter performance report based
on the annual plan.
User Story As a user, I want the system to create annual and quarterly Performance
Report by entering the value

Source TOR
Acceptance • The system should provide the planned activities along with the
Criteria planned target
• The system should validate the performance value and reject if
the value is not on the allowable limit
• The user can be able to generate reports associated with plan
• The system shall align the performance with the plan to draw the
achievement
• The system provide an interface to select performance of KPIs
using tabular and visual representations.
 • The user will be able to see the progress report in charts and
graphs
• The user shall generate performance report monthly, quarterly,
semi-annually and annually in word, excel and pdf formats.

3.2.3.5 CUSTOM REPORT

Requirement FPMRM-05
Id
Importance Mandatory
Description The ORIDIMS shall create annual and quarterly performance reports
based on the planned activities.

User Story As a user, I want the system to create annual and quarterly reports on
custom activities and/or Goals executed by my office

Source TOR
Acceptance • The system should provide custom interface to to enter the
Criteria performance
• If the activities is executed and is not listed in the annual or
quarterly plan then the system provides a place to enter the
executed performance value.
• The system shall allow monitoring and evaluating Office’s KPI
based on pre-defined criteria.
• The user can generate project performance report. This will help
OPDC to endorse project proposals before it reaches regional
finance bureau.

3.2.3.6 AGGREGATED PLAN

Requirement FPMRM-06
Id
Importance Mandatory
 Description The ORIDIMS shall aggregate annual and quarterly plans based on the
predefined parameters (such as office similarity, activity similarity,
office hierarchy, child offices)
User Story As a user/as a manager, I want the system to aggregate the annual and
quarterly plans based on the predefined parameters

Source ToR
Acceptance • The user can aggregate the plan with selected similar categories
Criteria • The user can aggregate plan target value (sum, ratio, percent…)
and data type with similar KPI

3.2.3.7 AGGREGATED REPORT

Requirement FPMRM-07
Id
Importance Mandatory
Description The ORIDIMS shall aggregate annual and quarterly performance report
based on the predefined parameters (such as office similarity, activity
similarity, office hierarchy, child offices)
User Story As a user/as a manager, I want the system to aggregate the annual and
quarterly performance report based on the predefined parameters

Source ToR
Acceptance • The user can aggregate the performance report with selected
Criteria similar categories and its child
• The user can aggregate performance value (sum, ratio,
percent…) and data type with similar KPI
• The user can generate final reports aggregated from different
sectors in a format easily communicated and uploaded to
website
3.2.3.8 DE-AGGREGATED PLAN

Requirement FPMRM-08
Id
Importance Mandatory
Description The ORIDIMS shall de-aggregate annual and quarterly plans if update is
required in the child office

User Story As a user/as a manager, I want the system to de-aggregate the annual
and quarterly plans if correction is needed or require update

Source ToR, International Best Practice

Acceptance • The user can de-aggregate the plan and
Criteria • It notifies the child office about the de-aggregation
• The user can de-aggregate plan target value

3.2.3.9 DE-AGGREGATED REPORT

Requirement FPMRM-09
Id
Importance Mandatory
Description The ORIDIMS shall de-aggregate annual and quarterly performance
report if update is required in the child office

User Story As a user/as a manager, I want the system to de-aggregate the annual
and quarterly performance report if correction is needed or require
update
Source ToR, International Best Practice
Acceptance • The user can de-aggregate the performance report and
Criteria • It notifies the child office about the de-aggregation
• The user can de-aggregate plan target value
3.2.3.10 DASHBOARD

Requirement FPMRM-10
Id
Importance Mandatory
Description The ORIDIMS shall provide (role-based) dashboard to slice and dice the
different reports, to show the status of the report, to see the submitted
the plan/performance report, to see overall performance of the region
User Story As a user, I want to see the status of the submission and the submitted
data and also the overall performance of the region

Source International Experience

Acceptance • The user can be able to see the submission status
Criteria • The user can be able to see the overall performance of the region
• The user can be able to see who submit the plan/report

3.2.3.11 NOTIFICATION

Requirement FPMRM-11
Id
Importance Mandatory
Description The ORIDIMS shall provide a notification for the tasks to be completed,
reported, and scheduled.
User Story As a user, I want to have a notification for scheduled tasks, things that I
need to complete, a new update pushed from my superior or
subordinate upon completion of tasks and/or reminder
Source International Experience
Acceptance • The user can be able to see notification sent from their superior
Criteria or subordinate
• The user can be able to see notification sent from the system
triggered by the time
3.2.4 STATISTICAL DATA MANAGEMENT

3.2.4.1 STATISTICAL DATA DEFINION

Requirement FSTDM-01
Id
Importance Mandatory
Description The ORIDIMS shall provide an interface to specify data definition and
determine what statistical information to be collected, and set a
timeframe for data collection
User Story As a user, I want to be able to create a data definition every year so that I
can define statistical data collection requirements for all sectors under
two main case teams (Economic Case Team and Social Case Team)
Source TOR
Acceptance • The user able to choose from two case teams
Criteria • The system will have an interface to define the statistical data
collection format.
• The user can be able to set the statistical data definition
• If the definition is successfully generated, it will display a list of
the data items for the selected sector.
• The definition is based on sector and only displayed for the
specific sector
• The definition includes a time frame for data collection

3.2.4.2 STATISTICAL DATA ENTRY

Requirement FSTDM-02
Id
Importance Mandatory
Description The ORIDIMS shall allow users at all Oromia administrative levels to
enter and store regional socioeconomic data to create a centrally
managed database that can be accessible to all the concerned bodies
(planners, monitoring and evaluation practitioners, researchers etc.)
 The statistical data to be recorded includes, but is not limited to
• Land, Climate and Population Data
• Social Sector Data
• Education
• Health
• Labour and Social Affairs
• Economic Sector Data
• Agriculture
• Electricity
• Industry
• Minerals
• Investment
• Rural Development
• Urban Development

NB: The statistical data entry format to be used will be the one prepared
by MoPD for the sectors. OPDC will prepare format for sectors not
included in the MoPD.

User Story As a system user, I want the system to allow users at all Oromia regional
offices to enter and store statistical data so that I can have a centrally
managed and remotely accessible database of statistical data
Source TOR
Acceptance • The user can enter data for the existing list of statistical data
Criteria types at the zonal level.
• The system provide statistical data entry through import using a
predefined import template
• The user sees only office specific data entry form (data entry is
allowed a the zone level even from different sectors)
• The form will be displayed if it is in the allowable time period
• If the sector doesn’t have branch office at the zone the statistical
data for the respective sector will be entered by the regional
OPDC.
3.2.4.3 CONTENT SEARCH

Requirement FSTDM-03
Id
Importance Mandatory
Description The ORIDIMS have the capability to perform a content search in
documents/data that are stored in the database in a readable format.

User Story As a system user, I would like to be able to search documents in the
system by content so that I can narrow my results if I know specific
details about the document I am looking for.
Source International Experience
Acceptance • On search of a specific document, I can narrow my search with
Criteria details that I know are written in the document that I am looking
for.

3.2.4.4 DATA UPDATE

Requirement FSTDM-04
Id
Importance Mandatory
Description The ORIDIMS shall allow the statistical data to alter/update the data in
order to store the latest and up-to-date regional statistical data with a
proper privilege
User Story As a user, I would like to be able to edit documents in the system to
make the content up-to-date and modify the data in case of errors.

Source International Experience

Acceptance • If modification is required, the system should allow to update
Criteria the data
• Modification of data only be allowed to privileged user
3.2.4.5 DATA DELETE

Requirement FSTDM-05
Id
Importance Mandatory
Description The ORIDIMS shall allow to remove/delete unnecessary or erroneous
content in order to store the latest and up-to-date regional statistical data
with a proper privilege
User Story As a user, I would like to be able to remove/delete contents from the
system to make the content up-to-date and modify the data in case of
errors.
Source International Experience
Acceptance • If deletion is required, the system should allow removing the
Criteria data
• Deletion/Modification of data only be allowed to privileged user

3.2.4.6 DATA VALIDATION AND VERFICATION

Requirement FSTDM-06
Id
Importance Mandatory
Description The ORIDIMS shall provide the capability to inspect, audit, validate,
and verify data entered into the system to store reliable and consistent
regional statistical data, avoid data duplication, and minimize errors
User Story As a user, I want the system to perform data validation and verification
on the entered data so that I can have reliable, consistent and up-to-date
socioeconomic data and ensure no duplication of data
Source International Experience
Acceptance • The system validates the statistical data entered by the users
Criteria • The system rejects and provide notification in case of invalid
data
• The system provides a successful message for the valid data
3.2.4.7 DATA ANALYTICS

Requirement FSTDM-07
Id
Importance Mandatory
Description The ORIDIMS shall provide the capability to analyse statistical data and
produce information related to all Oromia district and administrative
towns for further actions (such as proper budget allocation)
User Story As a user, I want to analyze the data stored in the system and retrieve
information so that I perform informed decisions (such as allocating the
proper budget for all districts and administrative towns under Oromia
regional state)
Source ToR, International Experience
Acceptance • The system can retrieve relevant information for analytics
Criteria • It provides an interface to set parameters for further action

3.2.4.8 DASHBOARD

Requirement FSTDM-08
Id
Importance Mandatory
Description The ORIDIMS shall provide the capability to view the main statistical
abstract in the dashboard

User Story As a user, I want to see the status of the data submission and the
submitted data

Source International Experience

Acceptance • The main reports related to the statistical data displayed
Criteria
3.2.4.9 STATISTICAL ABSTRACT

Requirement FSTDM-09
Id
Importance Mandatory
Description The ORIDIMS shall provide the capability to analyse data, and prepare
and manage annual statistical abstract based on the as the data entry

User Story As a user, I want to analyse the data stored in the system and prepare a
statistical abstract, based on the predefined format, generated from
different socioeconomic-related reports to make an informed decision.
Source International Experience
Acceptance • A user inputs data, data format, and report type, and the system
Criteria can automatically generate annual statistical abstract
• The report should be presented in a printable format

3.2.4.10 CUSTOM REPORT

Requirement FSTDM-10
Id
Importance Mandatory
Description The ORIDIMS shall provide the capability to analyse data, and prepare
and manage custom reports

User Story
As a user, I want to analyse the data stored in the system and prepare
custom reports based on the data. I also want to print the custom report
by monthly, quarterly, annually and time series (consecutive year).

Source ToR, International Experience

Acceptance • A user inputs data, data format, and report type, and the system
Criteria can automatically generate the report
• User can select the file type with which he/she can generate the
report by (pdf, excel, csv,...)
• The report generated also include graphs, maps.
 • A user can download and print the report

3.2.4.11 POPULATION DATA

Requirement FSTDM-11
Id
Importance Mandatory
Description The ORIDIMS provides the region population data analysis and helps to
pinpoint issues and sectors requirements, set goals and objectives,
consider alternative strategies, allot resources for the plan's
implementation, and assess how well the plan will accomplish its
objectives.
User Story As a user, I would like the system provides the capability to generate
population projection and interpolation and intercensal of data for
different sectors. This will be done only at the regional level.
Source ToR, International Experience
Acceptance • The system shall allow to generate population projection.
Criteria • The user can be able to access sectors population data
• The user can be able to access system population data analysis
functionalities
• The user can be able to generates population projection and
interpolation of the data from the system

3.2.5 DOCUMENT MANAGEMENT

3.2.5.1 BROWSE FOLDER

Requirement FDM-01
Id
 Importance Mandatory
Description The ORIDIMS shall provide the user to be able to view the contents of a
folder through a directory view. Properties about a document system
property such as the created date and created by can also be found from
this view. Document metadata is also found in this screen and can be
viewed here. Documents are arranged inside folders and sub-folders.
User Story As a system user, I want to choose what folder I would like to view.
Once I access the folder, the system will list the files and folders within
that folder.
Source ToR, International Experience
Acceptance • Once a user logged to the system, he will access the repositories
Criteria screen and a menu item
• The system allows the user to access organized folders and files
in a hierarchical manner

3.2.5.2 VIEW DOCUMENT

Requirement FDM-02
Id
Importance Mandatory
Description The user shall be able to view the contents of a document through a
document viewer screen.

User Story As a system user, I want to access the document from the folder and
directory where it has been stored. Once on the screen, I want to click
on the document, I would like to view and opens it. If I have the right
permission, the document view screen shall be able to open the
document/file.
Source ToR, International Experience
Acceptance • A user cannot access to the document without being
Criteria authenticated or the document is visible for public access
• A user can access publicly visible document without needs to
login to the system
 • Whenever a user clicks on the open document it will view and
opens it

3.2.5.3 UPLOAD DOCUMENT

Requirement FDM-03
Id
Importance Mandatory
Description The user shall be able to create a new document and add it into a folder.

User Story As a system user, I want to drag an existing image, pdf or .doc file from
the computer and add it onto the folder/directory screen on the DMS,
and the file is created and stored in the DMS database where it is
available for other users.
Source ToR, International Experience
Acceptance • Once the user has logged onto the system, will access the folder
Criteria and directory where he would like to store the document.
• The file is then created and stored in the DMS database where it
is available for other users.
• The user/author can add security attributes to the document to
control who is able to view it.

3.2.5.4 DOWNLOAD DOCUMENT

Requirement FDM-04
Id
Importance Mandatory
Description The user shall be able to download documents to a local folder from the
document management system.
User Story As a system user, I want to download a document from the system to
my local user.

Source ToR, International Experience

 Acceptance • Once the user has logged onto the system, will access the
Criteria document.
• Properties about the document shall be available from the folder
screen where a user can download document. This will create a
copy of the document onto the users local folder.

3.2.5.5 DELETE DOCUMENT

Requirement FDM-05
Id
Importance Mandatory
Description The user shall be able to delete an existing document from a folder.

User Story As a system user, I want to delete an uploaded document from the DMS
system.

Source ToR, International Experience

Acceptance • Once the user has logged onto the system, will access the
Criteria document.
• Only those eligible users which have delete permission are
allowed to delete the document.
• The system logged the delete operation and delete the files.

3.2.6 SPATIAL DATA MANAGEMENT

3.2.6.1 SPATIAL AND NON-SPATIAL DATA

Requirement FSDM-01
Id
Importance Mandatory
Description The ORIDIMS shall allow linking non-spatial attribute data with spatial
data.
User Story As a user, I want the system to provide the capability to map non-spatial
attributes with spatial data so that I can put spatial data into more
context
 Source ToR, International Experience
Acceptance • The user can be able to associate non-spatial data with spatial
Criteria data such as infrastructure distribution across a woreda.

3.2.6.2 SPATIAL DATA TRANSFORMATION

Requirement FSDM-02
Id
Importance Mandatory
Description The ORIDIMS shall provide the capability to perform data
transformation to convert and use data in a different coordinate system,
such as a geographic coordinate system or a geocentric coordinate
system, without any data loss.
User Story As a user, I want to be able to transform data in different coordinate
systems so that I can avoid difficulties and inaccuracies in analysing and
mapping mismatched data.
Source ToR, International Experience
Acceptance • It will allow the user to use a spatial data with preferred
Criteria reference system,
• the system can convert the reference system based on the user
preference

3.2.6.3 SPATIAL DATA ENTRY

Requirement FSDM-03
Id
Importance Mandatory
Description The ORIDIMS shall provide the capability to perform data
transformation to convert and use data in a different coordinate system,
such as a geographic coordinate system or a geocentric coordinate
system, without any data loss.
 User Story As a user, I want the system to accept spatial data such as natural
resource, land use, land cover, agriculture, infrastructure, education,
health, trade, industry, services and tourism
Source ToR, International Experience
Acceptance • It will allow the user to use a spatial data with preferred
Criteria reference system,
• the system can convert the reference system based on the user
preference

3.2.6.4 SPATIAL DATA ANALAYSIS

Requirement FSDM-04
Id
Importance Mandatory
Description The ORIDIMS shall allow data layer integration to GIS software in order
to perform spatial analysis such as attribute query and spatial query to
explore inhabitants and related socioeconomic phenomena
User Story As a user, I want to be able to integrate GIS software with the system so
that I can explore and analyse spatial data efficiently using the tools
provided by GIS software.
Source ToR
Acceptance • User able to query the system and the system will able to
Criteria generate the result. Eg. Area of Adama town will automatically
calculated by the system.

3.2.6.5 SPATIAL DATA IMPORT

Requirement FSDM-05
Id
Importance Mandatory
Description
The ORIDIMS shall provide the capability to import geographically
referenced data from different sources, including open source data in
different formats like JPEG, PRJ, TIF, SHP, GIF, SVG, PDF, DBF, PNG and
DWG and store it in the system.
 User Story As a user, I want to upload data from external sources with different
data formats so that I can easily exchange data with different other
format.
Source ToR, International Practice
Acceptance • A user inputs the data file from external sources, and the system
Criteria automatically converts the existing format and uploads the data
into the system without any data loss

3.2.6.6 SPATIAL DATA EXPORT

Requirement FSDM-06
Id
Importance Mandatory
Description The ORIDIMS shall provide the capability to export geographically
referenced data in different formats like JPEG, PRJ, TIF, SHP, GIF, SVG,
PDF, DBF, PNG and DWG.
User Story As a user, I want to extract data stored in the system in a different
format so that I can easily exchange data with other systems.

Source ToR, International Practice

Acceptance • A user inputs the required data format, and the system
Criteria automatically converts the existing format and extracts the data
with the required format without data loss
• The system exports Spatial Data in the above mentioned formats.

3.2.6.7 SPATIAL UNIT GROUP

Requirement FSDM-07
Id
Importance Mandatory
Description The ORIDIMS shall support group of Spatial Units into a Spatial unit
Groups and so set of Spatial Unit Groups into a Bigger Spatial Unit
Group to create Administrative Boundaries.

The Groups to be formed are:

 • Kebele
• Wereda
• City
• Zone
• Region
• Country
User Story As user, I want to group spatial units by proximity so that I can form
Administrative Units.

Source ToR

Acceptance • A boundary is imported as Section not exceeding the predefined

Criteria number of an administrative unit.
• User able to select different administrative divisions (Ethiopia,
Oromiya, Zone, Administrative Town, District, Kebele)
4 WORKFLOW

The following flows illustrate the primary data flows in the system. They have been simplified to
focus on the data. Additional flows will include:

User request will be for web pages containing form, document or analytics views

• The web Application Framework will authenticate the user through the Security
subsystem
• Authenticated users with appropriate capabilities will have a session established
• The Web Application subsystem will work with the appropriate subsystem to get the
form, document, dashboard or report ready to receive data
• The user’s data access rights will be checked by the Database subsystem
• The web page will be populated with authorized data and returned to the user by the
Web Application Framework with the appropriate frame including logos and additional
navigation menus.

4.1 SECURITY AND USER MANAGEMENT

Figure 22: Security and User Management

In this flow, examples of user authentication and session management are displayed. A User (1) inserts a
URL for the Data Portal Application web page into their web browser. This page might be a homepage, a
login page, a dashboard, or any other suitable page. The technology enables users to bookmark and
directly browse to any legitimate page.

Since the user has not yet logged in, the Web Application Framework does not have a session for this user;
thus, it (2) collaborates with the Security subsystem to execute the login protocol. This will be a basic user
login in the simplest situation, but the protocol also handles expired passwords, password updates, and
forgotten passwords.

The Security subsystem (4) makes a database connection for this user as part of the login procedure. This
connection is utilized for all data access during the current session, ensuring that the user only sees data
to which they have access permissions. The Web Application Framework manages (4) the database
connection as part of the session.

The request is now (5) verified against the Security subsystem to ensure that the user has the necessary
permissions to perform the page action. If the action is validated, the request is subsequently delivered
to the relevant subsystem for execution (6). Using SQL queries, the subsystems (7) interface directly with
the Relational Database subsystem to access metadata, documents, and data.

The user is provided with the completed web page (8). The user (9) navigates to more pages

4.2 FORMS DATA FLOW

Figure 23: Forms Data Flow

In this flow (1) a user at an SOE completes a monthly update and (3) submits the correct and
complete form. (4) The form data is sent to the Data Collection subsystem where (5) it is stored in
staging tables in the relational Database subsystem.

A user at OPDC (6) browses submitted data. (7) The data is requested from the Data Collection
subsystem and is collected from (8a) the staging tables if the data is new or (8b) the warehouse
tables if this is older data. (9) &amp; (10) the data is returned to the form to be viewed. The ETL
subsystem runs when to schedule to (11) extract data from the staging tables (12) transform the
data if required and (13) Load the data into the Data Warehouse tables ready for the dashboards,
reports and analytics required by OPDC.
4.3 PLANNING, MONITORING AND REPORT MANAGEMENT SYSTEMS

Figure 24: PMRS Workflow

In this workflow, an OPDC user must define goals and aims with the corresponding KPIs and create a plan.
The user must monitor the submitted plans' status and create and view reports. The user (1) accesses the
PMRM menu page and opens the planning page, and the user (2) defines goals, aims, activities and KPIs
with the corresponding units. (3) The PMRM subsystem verifies the input data and then (4) saves the plan
definition.

An OPDC user requests access to these predefined goals, aims and activities at step (5), which triggers the
PMRM subsystem to (6) query the defined goals, aims and KPIs and provide a list to the user. The user (7)
picks each goal and activity and sets the target, and the PMRM subsystem (8) stores the new plan in the
database.

An OPDC user accesses the PMRM menu page and opens monitoring page to send a request to access the
submitted plans at step (9), which triggers the PMRM subsystem to (10) query the plans submitted by the
user and provide a list of plans to the user. The user (11) picks each plan, views its status, or modifies it if
necessary. The user (12) accesses the reporting page and creates and submits the report based on the
planned goals and activities. (13) The PMRM subsystem generates and displays the report by verifying its
format.

4.4 DOCUMENT DATA FLOW

Figure 25: Document Workflow

In this workflow, an OPDC user must upload a document. The user (1) accesses the folder of documents.
(2) The Document Management Subsystem accesses the Relational Database subsystem's Document M
etadata tables to get the folder's contents, and (3) shows the list of accessible documents to the user. Th
e user (4) uploads the new document and sets the document's access level. The Document Management
subsystem (5) verifies the document's type, size, and folder's size, and then (6) saves the document. Op
erations 5 and 6 are a single relational transaction, ensuring consistency even if one operation fails.A OP
DC user requests access to this new document at step (7). The user accesses the folder, which triggers th
e Document Management subsystem to (8) query the folder's contents and provide a list to the user. Th
e user (9) picks a document to see, and the Document Management subsystem (10) obtains and (11) dis
plays the selected document.
5 SERVER REQUIREMENTS

Category Minimum Specifications

Brand Known Brand

Processor Multicore

Minimum of 2 processors

Memory Minimum of 16 GB FBD PC2-5300 Fully Buffered DIMMs (DDR2-667)

Up to 64 GB of memory, supported by (8) slots of PC2-5300 Fully

Storage Controller RAID Controller with 512MB battery-backed write cache with support for
RAID 0/1/5/6

Internal Drive Minimum of 500GB Hot Pluggable HDD and at least 3 hard disk
Support
8 small form factor (SFF) hot-plug drive bays

Slimline DVD-RW

Slots Four available PCI-Express slots, optional mixed PCI-X / PCI Express
configurations available

USB ports USB Ports: 6

Interface Redundant Gigabit Ethernet port

HBA card for backup purpose

Redundancy Hot plug Redundant Power Supply

 Hot plug Redundant Fans

Management Integrated Remote Console with KVM over IP performance over shared
network access

Integrated power monitoring and server level, policy based power

management

Convenient slide-out Systems Insight Display for quick and easy front view
server diagnostics

ROM Based Setup Utility

Form Factor 4U Rack form factor (7")

OS Based on the CRPRS requirement

Warranty Three-years plus three years post warranty

ALL REQUIRED ACCESSORIES, network cables, and LICENSES SHOULD ALSO BE INCLUDED