a 2009

SOFTWARE
REQUIREMENTS
SPECIFICATION
District Health Information Software v2
(DHIS2)
This Document explains the Software Requirements Specifications of the
District Health Information Software v2 (DHIS2) which is a routine data based
health information system which allows for data capture, aggregation,
analysis, and reporting of data.
DHIS2 is intended to be used as a Health Management Information System
(HMIS) application.

The University of Oslo,

Society for Health Information Systems Programme, India,
HISP Vietnam,
HISP Ethiopia,
06/08/2009
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

CONTENTS
Contents................................................................................................................................................................ 2
Table of Figures.................................................................................................................................................. 5
Introduction........................................................................................................................................................ 6
Purpose.................................................................................................................................................................................. 6

Aim of the Document................................................................................................................................................... 6

AIM of the SOFTWARE................................................................................................................................................ 6

Intended Audience............................................................................................................................................................ 7
Definitions, Acronyms and Abbreviations............................................................................................................... 7
Problem Statement........................................................................................................................................... 8
Methodology........................................................................................................................................................ 8
Undertaken Tasks............................................................................................................................................................. 8
Overall Description........................................................................................................................................... 9
Product Perspective......................................................................................................................................................... 9
Product Features............................................................................................................................................................... 9
User Characteristics....................................................................................................................................................... 10
User Requirements......................................................................................................................................... 12
1. The user should be able to LOGIN TO THE SYSTEM WITH DIFFERENT PRIVILEGES...........12
2. The user should be able to LOGOFF FROM THE SYSTEM....................................................................12
3. The user should be able to LOGIN AS ADMINISTRATOR & MANAGE USERS.............................12
3.1 The user should be able to MANAGE USER ROLES.............................................................................12
3.2 The user should be able to CHANGE OWN PASSWORD...................................................................12
4. The user should be able to CHANGE SYSTEM SETTINGS.....................................................................13
5. The user should be able to CHANGE USER SETTINGS...........................................................................13
6. The user should be able to CREATE AND MANAGE ORGANIZATION UNITS..............................13
6.1 The user should be able to MOVE ORGANIZATION UNIT HIERARCHY...................................13
7. The user should be able to MANAGE DATA ELEMENTS AND INDICATORS................................13
7.1 The user should be able to CREATE, DELETE OR EDIT DATAELEMENTS..............................13

Page 2
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

7.2 The user should be able to TRANSLATE DATAELEMENTS............................................................14

7.3 The user should be able to GET AN OVERVIEW OF DATAELEMENTS......................................14
7.4 The user should be able to CREATE, EDIT or DELETE DATA ELEMENT GROUPS..............14
7.5 The user should be able to TRANSLATE DATA ELEMENT GROUPS..........................................14
7.6 The user should be able to GET AN OVERVIEW OF DATAELEMENT GROUP........................14
7.7 The user should be able to CREATE, DELETE OR EDIT INDICATORS.......................................14
7.8 The user should be able to TRANSLATE INDICATORS.....................................................................14
7.9 The user should be able to GET AN OVERVIEW OF INDICATORS...............................................15
7.10 The user should be able to CREATE, EDIT or DELETE INDICATOR TYPE..............................15
7.11 The user should be able to TRANSLATE INDICATOR TYPE..........................................................15
7.12 The user should be able to GET AN OVERVIEW OF INDICATOR TYPE....................................15
7.13 The user should be able to CREATE, EDIT or DELETE INDICATOR GROUPS.......................15
7.14 The user should be able to TRANSLATE INDICATOR GROUP......................................................15
7.15 The user should be able to GET AN OVERVIEW OF INDICATOR GROUP................................15
8. The user should be able to MANAGE DATASETS...................................................................................... 15
8.1 The user should be able to CREATE, DELETE OR EDIT DATASETS...........................................16
8.2 The user should be able to ASSIGN DATASET TO ORGANIZATION UNITS............................16
8.3 The user should be able to CREATE DATA ENTRY FORMS FOR DATASETS.........................16
8.4 The user should be able to TRANSLATE NAMES OF DATASETS.................................................16
8.5 The user should be able to GET AN OVERVIEW OF ALL DATASETS..........................................16
9. The user should be able to LOCK DATASETS FROM DATAENTRY..................................................16
10. The user should be able to BROWSE DATA ENTRY BY PERIOD.................................................16
11. The user should be able to DO SIMPLE DATA INTEGRITY CHECKS..........................................17
12. The user should be able to SEE DATA STATISTICS............................................................................17
13. The user should be able to DO DATA ENTRY........................................................................................ 17
13.1 The user should be able to ADD MINIMUM & MAXIMUM VALUES to data elements.......17
13.2 The user should be able to RUN VALIDATION RULES ON DATA ENTRY................................17
13.3 The user should be able to COMPLETE AND UNDO THE DATASET...........................................17
14. The user should be able to DO DATA QUALITY CHECKS................................................................18
14.1 The user should be able to CREATE, EDIT OR DELETE VALIDATION RULES.......................18

Page 3
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

14.2 The user should be able to GET OVERVIEW of VALIDATION RULES........................................18

14.3 The user should be able to CREATE, EDIT OR DELETE VALIDATION GROUPS...................18
14.4 The user should be able to GET OVERVIEW OF VALIDATION GROUPS..................................18
14.5 The user should be able to RUN VALIDATION RULES......................................................................18
15. The user should be able to DO GRAPHICAL ANALYSIS OF DATA...............................................19
15.1 The user should be able to DO GRAPHICAL ANALYSIS FOR ANNUAL DATA........................19
16. The user should be able to DO TABULAR ANALYSIS OF DATA....................................................19
17. The user should be able to VIEW THE DATA STATUS......................................................................19
18. The user should be able to TAKE BACKUP OF DATA........................................................................19
19. The user should be able to VIEW DATA ON A MAP AS A GEOGRAPHIC INFORMATION SYSTEM
19
20. The user should be able to VIEW HELP ON THE APPLICATION..................................................20
21. The user should be able to SEE APPLICATION INFORMATION...................................................20
System Requirements.................................................................................................................................... 36
System Functional Requiremnets............................................................................................................................ 36

1. The system shall BE BUILT AS A COMBINATION OF MODULES............................................36

2. The system shall NOT DISPLAY PAGES WITHOUT VALID USER CREDENTIALS............36

3. The system shall CREATE/EDIT USER WITH VALID DETAILS...............................................37

Nonfunctional Requirements..................................................................................................................................... 38

1. Product Requirements............................................................................................................................. 38

2. Organization Requirements................................................................................................................... 40
External Interface Requirements............................................................................................................... 40
User Interfaces................................................................................................................................................................. 40
Hardware Interfaces...................................................................................................................................................... 40
Software Interfaces........................................................................................................................................................ 40
System Architecture....................................................................................................................................... 41
References......................................................................................................................................................... 42

TABLE OF FIGURES

Page 4
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Figure 1- PRIMARY USE-CASE OF DHIS2 MODULES........................................................................................................... 22

Figure 2- USE-CASE of USER MANAGEMENT MODULE..................................................................................................... 23

Figure 3- USE-CASE of ROLE MANAGEMENT MODULE..................................................................................................... 23

Figure 4- USE-CASE of SETTINGS MODULE............................................................................................................................ 24

Figure 5- USE-CASE of ORGANIZATION UNIT MANAGEMENT MODULE....................................................................25

Figure 6- USE-CASE of ORGANIZATION UNIT GROUP MANAGEMENT MODULE....................................................25

Figure 7- USE-CASE ORGANIZATION UNIT GROUPSET MANAGEMENT MODULE.................................................26

Figure 8- USE-CASE of ORGANIZATION UNIT HIERARCHY MANAGEMENT MODULE..........................................26

Figure 9- USE-CASE of DATASET MANAGEMENT MODULE............................................................................................. 27

Figure 10- USE-CASE of DATA ELEMENT MANAGEMENT MODULE............................................................................28

Figure 11- USE-CASE of DATA ELEMENT GROUP MANAGEMENT MODULE............................................................28

Figure 12- USE-CASE of INDICATOR MANAGEMENT MODULE......................................................................................29

Figure 13- USE-CASE of INDICATOR TYPE MANAGEMENT MODULE..........................................................................30

Figure 14- USE-CASE of INDICATOR GROUP MANAGEMENT.......................................................................................... 31

Figure 15- USE-CASE of DATA ADMINISTRATION MODULE........................................................................................... 31

Figure 16- USE-CASE of DATA ENTRY MODULE................................................................................................................... 32

Figure 17- USE-CASE of DATABASE MANAGEMENT MODULE.......................................................................................32

Figure 18- USE-CASE OF VALIDATION RULE MANAGEMENT MODULE.....................................................................33

Figure 19- USE-CASE of VALIDATION RULE GROUP MANAGEMENT MODULE.......................................................33

Figure 20- USE-CASE of RUNNING VALIDATION RULES................................................................................................... 34

Figure 21- USE-CASE of DATA ANALYSIS................................................................................................................................ 34

Figure 22- USE-CASE of IMPORT/EXPORT MODULE.......................................................................................................... 35

Figure 23- System Architecture................................................................................................................................................... 41

INTRODUCTION

Page 5
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

PURPOSE

AIM OF THE DOCUMENT

This Software Requirements Specification (SRS) for DHIS2 is a document that aims and focuses to
describe the main structure of the system, how its components interact with one another, and the list of
requirements met by the system on a simple and thorough scale. Relationships between entities of the
system and functional use-cases are often modeled or illustrated in various parts of the document. In
other words, the SRS should completely describe the external behavior of the application. It also explains
and describes nonfunctional requirements, design constraints and other factors necessary to provide a
complete, broad and comprehensive description of the requirements for DHIS2.

AIM OF THE SOFTWARE

DHIS2 is targeted at the distributed collection and analysis of routine data, specifically for primary
health care, but potentially any kind of data. Henceforth, the aim of the software is easy data collection,
data mart creation, data warehouse management, analysis of data and reporting information for action.
Public health researchers, health ministries and the health staff are in need of easy to use Health
Management Information System (HMIS) software. DHIS2 tries to meet these needs and the SRS explains
different use-cases and processes through which it meets the requirements.

DHIS2 aims to be a tool for collection, validation, analysis, and presentation of aggregate statistical data,
tailored (but not limited) to integrated health information management activities. It is a generic tool
rather than a pre-configured database application, with an open meta-data model and a flexible user
interface that allows the user to design the contents of a specific information system without the need for
programming

INTENDED AUDIENCE

The SRS document is intended for anyone who wants to have a holistic understanding of the system and
tries to give a clear idea to decision makers on what requirements the software tries to meet. The SRS is
Page 6
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

also useful for design and development of the application and is considered as a constitution document
that has to be followed for any further development of the software. Ministries of health can understand
use of the application by reading this document. External testers can perform functional testing by
understanding expected results of the application.

DEFINITIONS, ACRONYMS AND ABBREVIATIONS

 HMIS : Health Management Information System

 DHIS : District Health Information Software

 FOSS : Free and Open-Source Software

 GUI : Graphical User Interface

 ORG UNIT: Organization Unit of Data Capture

 VPN : Virtual Private Network

PROBLEM STATEMENT

To design and develop a web-based, free and open-source system for data collection, validation, analysis,
and presentation of aggregate statistical data. This system should allow distributed data collection and
distributed dissemination of data, meeting the requirements of a health management information system.

Page 7
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

METHODOLOGY

The system is developed on the principles of Xtreme Programming (XP) which includes simplicity,
communication, feedback and courage. Simple design and continuous refactoring through feedback is the
process followed for development and implementation of the system. The “bazaar” model of distributed
development has been adopted with developers spread across countries like Norway, India, Ethiopia and
Vietnam.

UNDERTAKEN TASKS

 Gathering information

 Identify and classify the system and user requirements

 SRS creation

o Successfully identifying system requirements and documenting them in this SRS

 System Design

o Decide upon the FOSS frameworks to be used for the system

o Design a flexible data model that can be customized to implementation needs

o Design a common portal framework to be used by all modules

 System Implementation

o Implementing the different components and subsystems of the project

 Unit Testing

o Testing each subsystem independently

 System Integration

o Integration of different subsystems to form the whole system.

 System Testing

o Testing the system as a whole

 Test Specification

o Submission a full report of the known bugs and errata of the system.

Page 8
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

OVERALL DESCRIPTION

PRODUCT PERSPECTIVE

DHIS2 is the next version to the popular District Health Information System 1.3. DHIS2 is web-based and
uses open-source frameworks. The system runs on a Java Servlet Container and is accessed through a web
browser. It is platform independent (runs on Windows, Linux, OSX etc.) and browser independent (runs
on Mozilla Firefox, Internet Explorer, Opera etc.). DHIS2 can use any database management system (runs
on MySQL, PostgreSQL, Oracle etc.) and can run on a number of Java Servers (runs on Apache Tomcat,
Jetty, Glassfish etc.)

Using DHIS2 does not imply any licensing fees. DHIS2 is released under the BSD license. Though some
parts of DHIS2 are also under the GNU Public License v3

PRODUCT FEATURES

Based on the requirements DHIS2 intends of provide the following features:

 Easy and distributed data collection

 Easy management of collected data
 Flexible data model for collecting all kinds of data
 Scalable access to data by creating a data warehouse
 Abstraction of data and datasets based on hierarchy of organization units
 Powerful user management for system security and data management
 Intuitive reporting for managers and decision makers using graphs, charts and maps
 Generates reports in different formats that can be exported to other applications
 Validation rules for improving data quality
 Import / Export data to other applications

USER CHARACTERISTICS

Since the system is to be used for data collection as well as decision making, it should cater to the needs of
a wide audience of users. The users range from grass-root health workers, data entry operators, health
officers, state health ministries, public health researchers and national policy formulators. Thus, DHIS2
needs to be powerful, yet simple to use as a HMIS.

Page 9
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Page 10
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Data
Data Collection
Analysis

Data
Reporting

User Requirements
USER REQUIREMENTS

Page 11
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

1. THE USER SHOULD BE ABLE TO LOGIN TO THE SYSTEM WITH DIFFERENT

PRIVILEGES

Rationale: Since data entry, validation, analysis and reporting are all specific to the user and their
privileges; each user should have their own login credentials which allow access to only certain parts of
the system. Each user should be able to change their login credentials.

2. THE USER SHOULD BE ABLE TO LOGOFF FROM THE SYSTEM

Rationale: Since all activities of the system are associated to a user, after the user has finished using the
system, they should be allowed to logoff from the system. To again use the system, the user has to login.

3. THE USER SHOULD BE ABLE TO LOGIN AS ADMINISTRATOR & MANAGE USERS

Rationale: The administrator user of the system should be able to set-up the system by creating and
managing users of the system. The admin user should be able to search existing users and change their
details like username, password, first name, last name, phone and email.

3.1 THE USER SHOULD BE ABLE TO MANAGE USER ROLES

Rationale: The admin user should also be able to create new user roles and assign these roles to different
users. The user roles can be used to allow viewing of datasets, reports and different authorities to use the
system.

3.2 THE USER SHOULD BE ABLE TO CHANGE OWN PASSWORD

Rationale: Each user of the system should be able to change their own password. Admin users should not
be able to look-up this password, but still should be allowed to change the password for any user of the
system.

4. THE USER SHOULD BE ABLE TO CHANGE SYSTEM SETTINGS

Page 12
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Rationale: Users with roles that can setup the system should be able to change the settings of the system.
The user should also be able to change important systems settings like Application Title, Logo and Start
page.

5. THE USER SHOULD BE ABLE TO CHANGE USER SETTINGS

Rationale: User should be able to change the GUI Language, Database Language and change the style (look
and feel) of the system.

6. THE USER SHOULD BE ABLE TO CREATE AND MANAGE ORGANIZATION UNITS

Rationale: Every data value should be captured or accessed only through an organization unit. The
organization unit is representative of the location, area or unit of data capture. The user should be able to
create new organization units, associate them as a hierarchy and identify different levels of organization
units. The user should also be able to move organization units as and when required.

6.1 THE USER SHOULD BE ABLE TO MOVE ORGANIZATION UNIT HIERARCHY

Rationale: The user should also be able to move organization units as and when required and along with
the data should also be moved to the new organization unit hierarchy.

7. THE USER SHOULD BE ABLE TO MANAGE DATA ELEMENTS AND INDICATORS

Rationale: Data elements and indicators are the basic models of data collection and analysis in the system.
Data elements act as data capturing units while indicators act as analysis units.

7.1 THE USER SHOULD BE ABLE TO CREATE, DELETE OR EDIT DATAELEMENTS

Rationale: The user should be able to create or edit data elements by giving name, codes, data type and
aggregation operator. The data type should be Number, Text or YES/NO while the aggregation operator
should be SUM or AVERAGE. The data type is representative of the type of data being stored and will be
used to show the user-interface to the user. The aggregation operator will be useful to aggregate values
over a given period or across different org units.

7.2 THE USER SHOULD BE ABLE TO TRANSLATE DATAELEMENTS

Page 13
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Rationale: The user should be able to create new locales and give names to data elements.

7.3 THE USER SHOULD BE ABLE TO GET AN OVERVIEW OF DATAELEMENTS

Rationale: The user should be able to see name, description, type and aggregation operator.

7.4 THE USER SHOULD BE ABLE TO CREATE, EDIT OR DELETE DATA ELEMENT
GROUPS

Rationale: Data Element Groups are different from datasets. Data elements can be put together in a group
and these may be used in different datasets. Data element groups can also be used to segregate data
elements that are used for a common purpose. Thus, the user should be able to create, edit or delete data
element groups by adding data elements to the groups.

7.5 THE USER SHOULD BE ABLE TO TRANSLATE DATA ELEMENT GROUPS

Rationale: The user should be able to create new locales and give names to data element groups based on
their locale.

7.6 THE USER SHOULD BE ABLE TO GET AN OVERVIEW OF DATAELEMENT GROUP

Rationale: The user should be able to see name and number of data elements in a data element group.

7.7 THE USER SHOULD BE ABLE TO CREATE, DELETE OR EDIT INDICATORS

Rationale: The user should be able to create or edit indicators by giving name, codes, whether annualized
and type of indicator. As indicators are generally formulas, the user should be able to edit numerator and
denominator of the indicators and while setting these should be able to define formulas from data
elements.

7.8 THE USER SHOULD BE ABLE TO TRANSLATE INDICATORS

Rationale: The user should be able to create new locales and give names to indicators based on their
locale.

7.9 THE USER SHOULD BE ABLE TO GET AN OVERVIEW OF INDICATORS

Page 14
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Rationale: The user should be able to see name, description, whether annualized, indicator type,
numerator description and denominator description for each indicator as an overview.

7.10 THE USER SHOULD BE ABLE TO CREATE, EDIT OR DELETE INDICATOR TYPE

Rationale: Indicator types are useful for creating indicators and how they are calculated. The user should
be able to give name and factor while creating Indicator Type.

7.11 THE USER SHOULD BE ABLE TO TRANSLATE INDICATOR TYPE

Rationale: The user should be able to create new locales and give names to indicator type for their locale.

7.12 THE USER SHOULD BE ABLE TO GET AN OVERVIEW OF INDICATOR TYPE

Rationale: The user should be able to see name and factor for any indicator type as an overview.

7.13 THE USER SHOULD BE ABLE TO CREATE, EDIT OR DELETE INDICATOR

GROUPS

Rationale: Indicators used for common analysis can be put into a group for easy management. User
should be able to create, edit or delete indicator groups by adding or removing indicators from a group.

7.14 THE USER SHOULD BE ABLE TO TRANSLATE INDICATOR GROUP

Rationale: The user should be able to create new locales and translate indicator groups for their locale.

7.15 THE USER SHOULD BE ABLE TO GET AN OVERVIEW OF INDICATOR GROUP

Rationale: The user should be able to see name and number of indicators for any indicator group.

8. THE USER SHOULD BE ABLE TO MANAGE DATASETS

Rationale: Data elements form the basic unit of data. Groups of data elements are known as datasets.
Users should be able to manage datasets.

8.1 THE USER SHOULD BE ABLE TO CREATE, DELETE OR EDIT DATASETS

Page 15
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Rationale: Users should be able to create, delete or edit datasets at any time. Users should be able to give
names to datasets, assign codes to datasets, add/remove necessary data elements and store the capture
frequency of the dataset.

8.2 THE USER SHOULD BE ABLE TO ASSIGN DATASET TO ORGANIZATION UNITS

Rationale: Users should be able to assign created datasets to organization units so that only assigned data
can be captured. Not all data is captured from each organization unit and helps in easy data management.

8.3 THE USER SHOULD BE ABLE TO CREATE DATA ENTRY FORMS FOR DATASETS

Rationale: Datasets are representative of forms in the system. The user should be able to create the data
entry screens for capturing data in the datasets.

8.4 THE USER SHOULD BE ABLE TO TRANSLATE NAMES OF DATASETS

Rationale: The user should be able to create new locales and give names to datasets based on their locale.

8.5 THE USER SHOULD BE ABLE TO GET AN OVERVIEW OF ALL DATASETS

Rationale: The user should be able to see name, number of elements and frequency of capturing of
datasets

9. THE USER SHOULD BE ABLE TO LOCK DATASETS FROM DATAENTRY

Rationale: The user should be able to lock datasets so that further data entry is not possible. Data locking
is useful for finalizing data by making the data values from a dataset for a given period (monthly, weekly
etc.) uneditable.

10. THE USER SHOULD BE ABLE TO BROWSE DATA ENTRY BY PERIOD

Rationale: The user should be able to see how much data was entered in a given period for a selected
dataset or organization unit. The user should be able to select Period Type, the start date and end date and
the dataset or organization and browse the data.

11. THE USER SHOULD BE ABLE TO DO SIMPLE DATA INTEGRITY CHECKS

Page 16
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Rationale: The user should be able to do simple data integrity checks and look through which of them are
causing violations

12. THE USER SHOULD BE ABLE TO SEE DATA STATISTICS

Rationale: The user should be able to see number of data elements, data element groups, indicator types,
indicators, indicator groups, datasets, data dictionary, organization units, validation rules, periods and
data values.

13. THE USER SHOULD BE ABLE TO DO DATA ENTRY

Rationale: The user should be able to select organization unit, dataset and the period which allows to data
entry on the dataset. There should be on-the-fly saving of data values so that data values are not lost due
to the intermittent loss of power and internet infrastructure. Whatever data is entered should be saved
and retrievable next time.

13.1 THE USER SHOULD BE ABLE TO ADD MINIMUM & MAXIMUM VALUES TO
DATA ELEMENTS

Rationale: The user should be able to set minimum and maximum values to a data element and during
data entry the user should conform to these rules of minimum and maximum. The user should also be able
to see the history of data values that have been entered for the data element.

13.2 THE USER SHOULD BE ABLE TO RUN VALIDATION RULES ON DATA ENTRY

Rationale: While the user is doing data entry, the user should be able to run the already existing
validation rules on the dataset.

13.3 THE USER SHOULD BE ABLE TO COMPLETE AND UNDO THE DATASET

Rationale: The user should be able to specify that they have finished data entry on a given dataset. The
user should also be able to revert back to say that the data entry is not complete.

14. THE USER SHOULD BE ABLE TO DO DATA QUALITY CHECKS

Page 17
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Rationale: The user should be able to do quality checks on correctness, completeness, consistency and
timeliness. Other than running validation rules during data entry, user should be able to define and run
validation rules on all data that has been collected.

14.1 THE USER SHOULD BE ABLE TO CREATE, EDIT OR DELETE VALIDATION

RULES

Rationale: The user should be able create or edit validation rules by giving name of validation rules,
description and operator for validation rules. The user should be able to define the left-hand side and
right-hand side of the formula for validation rules.

14.2 THE USER SHOULD BE ABLE TO GET OVERVIEW OF VALIDATION RULES

Rationale: The user should be able to see name, description, left-side description, right-side description
and operator for each validation rule.

14.3 THE USER SHOULD BE ABLE TO CREATE, EDIT OR DELETE VALIDATION

GROUPS

Rationale: The user should be able to see add or remove validation rules and create a group of validation
rules

14.4 THE USER SHOULD BE ABLE TO GET OVERVIEW OF VALIDATION GROUPS

Rationale: The user should be able to see name, description and number of elements in validation group

14.5 THE USER SHOULD BE ABLE TO RUN VALIDATION RULES

Rationale: The user should be able to run validation rules by selecting the start date and end date,
validation rule group and the organization unit. The user should be able to see the results of the validation
check and be able to identify which data elements are failing the validations.

15. THE USER SHOULD BE ABLE TO DO GRAPHICAL ANALYSIS OF DATA

Page 18
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Rationale: The user should be able to view graphical representation of the data collected. The user should
be able to analyze data on indicator and data elements and view it for organization units over a selected
period. The user should be able to see charts or summary of the results. The user should also be able to
export the data into excel sheets or print out the graphs and charts.

15.1 THE USER SHOULD BE ABLE TO DO GRAPHICAL ANALYSIS FOR ANNUAL DATA

Rationale: The user should be able to create graphs and charts by selecting indicators or data elements
over a period of year/years for a selected organization unit.

16. THE USER SHOULD BE ABLE TO DO TABULAR ANALYSIS OF DATA

Rationale: The user should be able to view at data in the form of tables for any selected indicator or data
element for a given period or organization unit

17. THE USER SHOULD BE ABLE TO VIEW THE DATA STATUS

Rationale: The user should be able to look at the number of data elements that are being collected from an
organization unit for a given period. Data status should be seen as the percentage of data elements that
have been filled to the total number of elements in the dataset.

18. THE USER SHOULD BE ABLE TO TAKE BACKUP OF DATA

Rationale: The user should be able to take backup of the data from the user-interface. The user should be
able to click on a button and download the backup of data from the server. The user should be able to
view the files in a file explorer

19. THE USER SHOULD BE ABLE TO VIEW DATA ON A MAP AS A GEOGRAPHIC

INFORMATION SYSTEM

Rationale: The user should be able to view collected data represented on a map. Each organization unit
can be associated as an area on the map and the user should be able to view data values/ indicators on the
map.

20. THE USER SHOULD BE ABLE TO VIEW HELP ON THE APPLICATION

Rationale: The user should be able to receive online help in the application
Page 19
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

21. THE USER SHOULD BE ABLE TO SEE APPLICATION INFORMATION

Rationale: The user should be able to look at the application information like current user, version,
browser agent, configuration directory, environment variables, database names and database user from
the about screen of the system

Page 20
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Use-Case Diagram

Use Case

FIGURE 1- PRIMARY USE-CASE OF DHIS2

MODULES

Page 21
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

FIGURE 2- USE-CASE OF USER MANAGEMENT MODULE

FIGURE 3- USE-CASE OF ROLE MANAGEMENT

MODULE

FIGURE 4- USE-CASE OF SETTINGS MODULE

Page 22
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Page 23
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

FIGURE 5- USE-CASE OF ORGANIZATION UNIT MANAGEMENT MODULE

FIGURE 6- USE-CASE OF ORGANIZATION

UNIT GROUP MANAGEMENT MODULE

FIGURE 7- USE-CASE ORGANIZATION UNIT

GROUPSET MANAGEMENT MODULE

Page 24
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

FIGURE 8- USE-CASE OF ORGANIZATION UNIT

HIERARCHY MANAGEMENT MODULE

FIGURE 9- USE-CASE OF DATASET MANAGEMENT MODULE

Page 25
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

FIGURE 10- USE-CASE OF

DATA ELEMENT
MANAGEMENT MODULE

Page 26
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

FIGURE 11- USE-CASE OF DATA ELEMENT GROUP MANAGEMENT MODULE

FIGURE 12- USE-CASE OF INDICATOR MANAGEMENT MODULE

Page 27
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

FIGURE 13- USE-CASE OF INDICATOR TYPE MANAGEMENT MODULE

Page 28
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

FIGURE 14- USE-CASE

OF INDICATOR GROUP
MANAGEMENT

FIGURE 15- USE-CASE OF DATA

ADMINISTRATION MODULE

Page 29
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

FIGURE 16- USE-CASE OF DATA ENTRY MODULE

FIGURE 17- USE-CASE OF DATABASE

MANAGEMENT MODULE

Page 30
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

FIGURE 18- USE-CASE OF VALIDATION RULE MANAGEMENT MODULE

FIGURE
19- USE-CASE OF VALIDATION RULE GROUP MANAGEMENT MODULE

Page 31
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

FIGURE 20- USE-CASE OF RUNNING VALIDATION RULES

FIGURE 21- USE-CASE OF DATA ANALYSIS

Page 32
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

FIGURE 22- USE-CASE OF IMPORT/EXPORT MODULE

Page 33
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

SYSTEM REQUIREMENTS

SYSTEM FUNCTIONAL REQUIREMNETS

1. THE SYSTEM SHALL BE BUILT AS A COMBINATION OF MODULES

Description: The system shall be built by using a combination of modules that can be assembled to create
a common portal based on user’s functional requirements

Inputs: The implementer chooses the modules that are to be part of the DHIS2 Portal.

Source: Maven.

Outputs: A web application that can deployed into the Servlet Container.

Destination: N/A

Action: Run ‘mvn clean install’ on the source root folder

Requires: The implementer modifies the pom.xml configuration file.

Pre-Condition: The source code is present for required modules. Maven and JDK are correctly configured.
All the necessary libraries are present or internet connection is present to automatically download the
libraries from central maven repositories.

Post-Condition: The implementer will find the dhis2.war file in the target folder, as well as built jar files
for all the compiled modules.

Side Effects: N/A.

2. THE SYSTEM SHALL NOT DISPLAY PAGES WITHOUT VALID USER CREDENTIALS

Description: The system will not display pages only without valid username and password for the system.

Inputs: Username and password entered into login screen for an existing user

Source: The User

Outputs: Displays the page

Destination: The start page configured in the system settings.

Action: The system will always load the login page, if the user opens a page without logging into the
system. The web page location is filtered to check valid login from the user before showing the page.

Requires: Valid username and password.

Pre-Condition: The user should exist in the system

Page 34
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

Post-Condition: N/A

Side Effects: The startup page is always loaded after login even if the user is shown the login screen from
a different page

3. THE SYSTEM SHALL CREATE/EDIT USER WITH VALID DETAILS

Description: The system requires some basic details like username, password, surname, first name to
create/edit a user.

Inputs: Username, 2 Matching passwords, Surname and First name

Source: The User

Outputs: A new user is created

Destination: A list of users is shown

Action: The system shall create the new user and show the list of users after the user has entered the
correct details and saved

Requires: N/A

Pre-Condition: N/A.

Post-Condition: N/A.

Side Effects: The project GUI is updated and the files tree view is displayed in the files explorer.

NONFUNCTIONAL REQUIREMENTS

1. PRODUCT REQUIREMENTS
Page 35
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

1.1 PERFORMANCE REQUIREMENTS

 Speed

The system will be accessed from the lowest levels of health hierarchy to the highest levels. Thus, the
system is designed to be fast and scalable across different types of internet connections. Large-sized
graphics are avoided, so that the system can work fast in low bandwidth conditions. The system is
designed to be scalable and allows data entry and data analysis from multiple levels of health system
hierarchy.

 Space

The system should allocate memory efficiently, so as not to cause degradation in the performance and
speed. The system can be hosted on a single server or across 2 servers i.e. application server and database
server to manage load and share space between the servers.

The product should consume the minimal amount of memory from the user’s computer. Since only the
browser is used on the client computer, the space and processor requirements are bare minimum.

1.2 RELIABILITY REQUIREMENTS

According to the IEEE, reliability is defined as “the probability that software will not cause the failure of a
system for a specified time under specified conditions”. The system is designed to work reliably under full
load. The system can reliably generate reports, graphs, charts, maps when under full load of data entry.

The system should work at all times since data entry may be done from anywhere at any time. The system
should deal with denial of service (DOS) and distributed denial of service (DDOS) attacks which are
common for large systems on the internet. The system should also work reliably for clients within VPN
and wireless networks.

1.3 USABILITY REQUIREMENTS

The application should be user-friendly and easy to use. Like explained in the User Characteristics, the
software users come from different backgrounds and needs to be easy for everyone to use. Both data entry
and data analysis should be easy to use. The system should have good readability and accessibility
controls. The system should be available in local language and all components of the system should be
internationalized. The system controls should be intuitive and user need not go through a lot of training to
use the application.

The system should be customizable to meet the user needs. Thus, it can bring in the current formats and
reports into the system, making it easier for users to understand.

Page 36
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

1.4 INTER-OPERABILITY
DHIS2 should be inter-operable with other types of health information systems. Being open-source, there
are more chances of the system being inter-operable with other products. The system should support a
wide variety of information exchange formats like DXF, IXF, SDMX etc.

1.5 CORRECTNESS
The system should behave as expected. User and functional requirements should be met. The system
should support synchronization between offline and online versions of the application and should result
in correct update of data. Reports that are to be sent to other application should be correctly generated
and state of data stored in the system should not automatically change over time.

2. ORGANIZATION REQUIREMENTS

2.1 IMPLEMENTATION REQUIREMENTS

The implementation requirements come from a variety of sources - from grass-root users to ministries of
health. Because of the lack of internet availability at all health facilities, the system should also be able to
work in offline mode and the system should be able to synchronize data between such offline and online

Page 37
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

systems. Data Elements, Datasets, Organizational hierarchies, Indicators, Validation rules and what
modules to use are all customizable to the needs of the implementation.

2.2 DELIVERY REQUIREMENTS

The system is incrementally developed through the use of modules. Each module is to be delivered at a
different time and depends on the implementation need. But the timeframe of delivery of a module may
range from 1-6 months. The initial portal architecture will be developed in a period of 6-12 months.

EXTERNAL INTERFACE REQUIREMENTS

USER INTERFACES

Since DHIS2 is a web application, it can be viewed through a web browser. Mozilla Firefox is the
recommended browser for using DHIS2. JavaScript and Cookies must be enabled in the browser for the
system to work properly. Only CSS2 complaint browsers would be able to display the system correctly.
The user is advised to use a minimum screen resolution of 1024x768 for correct view of the user interface.

For GIS functionality, the user interface requires a SVG renderer. This can be browser native like in Firefox
3 or through a plug-in like Adobe SVG Viewer for Internet Explorer.

HARDWARE INTERFACES

The system is hardware independent and does not require any special hardware.

SOFTWARE INTERFACES

The system makes use of Java and Java-based web frameworks like Struts, Spring, Hibernate, Webwork
and their APIs. The system also uses JavaScript, Velocity, SVG for the user interfaces.

Page 38
 District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

SYSTEM ARCHITECTURE

FIGURE 23- SYSTEM ARCHITECTURE

A detailed system architecture description can be found in the Technical Architecture document that is
part of the source code.

Available Modules

DHIS2 plans to have the following web modules available and new modules are developed on need:

1. Dashboard-Integration Module
2. Linelisting Module
3. Data entry Module
4. Datamart Module
5. GIS Module
6. Import/Export Module
7. Indian Dashboard Module
8. JForum Integration Module
9. Data Admin Maintenance Module

Page 39
District Health Information Software v2 [SOFTWARE REQUIREMENTS SPECIFICATION]

10. Data Dictionary Maintenance Module

11. Dataset Maintenance Module
12. Organization Unit Maintenance Module
13. Settings Maintenance Module
14. User Maintenance Module
15. NRHM Reports Module
16. OpenHealth Integration Module
17. Reporting Module
18. Validation Rule Module

REFERENCES

1. The Struggle for District-Based Health Information Systems in South Africa, Braa &
Hedberg
2. Modularization and Demodularization: Levels of a Java Web Application for Open Health,
Torgeir Lorange Østby
3. Technical Architecture, DHIS2
4. DHIS2 Wiki - http://208.76.222.114/confluence/display/DHIS2/Home
5. DHIS2 User Manual

Page 40