Final Srs

SOFTWARE
REQUIREMENTS
SPECIFICATION
NATIONAL ROADS AUTHORITY RDM2
Submitted in partial fulfillment of the requirements for the award of a
Bachelor of Science degree.
August 2008
Amos Beni (BSc/4/04)

Hannah Sakala (BSc/41/04)
Leo Maluwa (BSc/22/04)
Kanthungo Kapachika (BSc/ME/62/05) 0
TM
Epiphan
NRA Road Data Manager (RDM2 ) B. Chiunjira (BSc/13/04)
University of Malawi
Chancellor College
Mathematical Sciences Department
Computer Science Section
SOFTWARE REQUIREMENTS SPECIFICATION DOCUMENT
Submitted in partial fulfilment of the requirement for the award of Bachelor of Science
Degree for the students indicated below
TEAM MEMBERS: Kanthungo Kapachika (Bsc/Me/62/05)

Leo Maluwa (Bsc/22/04)
Epiphan Chiunjira (Bsc/13/04)
Amos Ben (Bsc/04/04)
Hannah Sakala (Bsc/41/04)
COURSE CODE: COM 412
COURSE NAME: Information Systems Project
CLIENT: National Roads Authority of Malawi
SUPERVISOR: Mr. Gregory Kunyenje
DATE: August 2008
1
NRA Road Data Manager (RDM2TM)
TABLE OF CONTENTS
1. INTRODUCTION .................................................................................................................................... 3
1.1 PROBLEMS WITH THE CURRENT SYSTEM ............................................................................................... 4
1.2 THE PROPOSED SYSTEM ........................................................................................................................ 5
1.3 PROBLEM DEFINITION ........................................................................................................................... 5
2. SYSTEM MODELS FOR PROPOSED SYSTEMS.............................................................................. 6
2.1 CONTEXT LEVEL DFD .......................................................................................................................... 6
2.2 OVERVIEW DFD ................................................................................................................................... 7
2.3 LEVEL 2 DFD: AUTHENTICATE PROCESS ............................................................................................. 8
2.4 LEVEL 2 DFD: MANAGE-USER PROCESS .............................................................................................. 9
2.5 LEVEL 2 DFD: MANAGE-BRIDGE-DATA PROCESS ............................................................................. 10
2.6 LEVEL 2 DFD: MANAGE-ROAD-DATA PROCESS ................................................................................ 11
2.7 LEVEL 2 DFD: GENERATE-REPORT PROCESS ..................................................................................... 12
3. DATA DICTIONARY............................................................................................................................ 13
4.0 FUNCTIONAL REQUIREMENTS.................................................................................................... 14
4.1 USER MANAGEMENT ........................................................................................................................... 14
4.2 ROAD DATA MANAGEMENT ................................................................................................................ 15
4.3 REPORT REQUIREMENTS ..................................................................................................................... 16
5.0 NON-FUNCTIONAL REQUIREMENTS ......................................................................................... 17
5.1 HARDWARE REQUIREMENTS............................................................................................................... 17
5.2 EFFICIENCY ........................................................................................................................................ 17
5.3 RELIABILITY ....................................................................................................................................... 17
5.4 USABILITY REQUIREMENTS ................................................................................................................ 17
5.4.1 LEARNABILITY................................................................................................................................. 17
5.4.2 EXCEPTIONAL HANDLING ................................................................................................................ 17
5.4.3 MULTIPLE VIEWS ............................................................................................................................ 18
5.5 SOFTWARE TOOLS .............................................................................................................................. 18
5.6 DELIVERY ........................................................................................................................................... 18
6.0 SYSTEM LIMITATIONS ................................................................................................................... 19
6.1 USER’S COMPUTER LITERACY ............................................................................................................ 19
6.2 APPLICABILITY ................................................................................................................................... 19
6.3 ACCESS ............................................................................................................................................... 19
6.4 HARDWARE ........................................................................................................................................ 19
7.0 SYSTEM EVOLUTION ...................................................................................................................... 20
8.0 INDIVIDUAL CONTRIBUTIONS..................................................................................................... 20
9.0 APPENDIX ........................................................................................................................................... 21
9.1 GLOSSARY .......................................................................................................................................... 21
9.2 LIST OF ABBREVIATIONS .................................................................................................................... 23
10. BIBLIOGRAPHY................................................................................................................................. 24
2
1. INTRODUCTION
The Malawi National Roads Authority (NRA) conducts a series of surveys to collect
information related to the road network. The information includes ordnance, inventory,
surface condition, road roughness, traffic, and pavement layer details. The collected data
is used in assessing the condition of roads and bridges across the country. Such
assessment helps NRA devise proper road development and maintenance strategies and
programs.
The National Roads Authority requires a comprehensive information system to manage
the collected data and provide easy access to it. The system therefore needs to keep, an
updated inventory of its road asset as well as information about the current condition of
that inventory. All this is supposed to be part of a larger system called the Pavement
Management System (PMS). The PMS has two main components: a customized central
database called Road Data Manager (RDM), and the Highway Development and
Management tool, HDM-4, a road investment decision support tool that provides the
means to investigate possible future impacts of alternative road development and
preservation strategies.
This project shall perform an upgrade of the Road Data Manager (RDM) software to
provide networked services. The current RDM system was required to manage the road
network inventory, its condition, traffic levels and construction / maintenance works. The
system was also used for data entry, validation, and processing required enabling
interrogation of the data stored and for producing reports on the data. The other
requirement of the system was to provide the production of road network sections to be
exported to the Highway Development and Management tool, HDM-4. In this light it is
clear that RDM2 will be very useful for the core business of NRA.
The interaction between the system and the two subsystems is illustrated in Figure 1.
3
Figure 1: PAVEMENT MANAGEMENT SYSTEM
1.1 Problems with the current system
The current RDM system operates in a standalone environment where it is housed on a

single desktop machine. When data has been collected through road surveys it is entered
into the RDM by data entry technicians working concurrently on different databases.
Then the databases are merged into one master database containing all the survey
information. Since the merging of the databases is done periodically, errors are
introduced in the data in several ways:
i. Data for road sections surveyed more than once may introduce
inconsistent duplicate databases
ii. Field errors are compounded as their resolution is sometimes (necessarily)

carried over to later stages in the process
4
iii. Because technicians are effectively working on different databases, it is
sometimes difficult to trace the source of an error
iv. When road inventory changes (for example due to a reconstruction or a

change in the accuracy of the survey process), the changes are difficult to
amend in the database once data entry has started
v. The database is transferable across computers making it extremely

difficult to implement any meaningful security measures for the data.
vi. The system is very inefficient as many manual data cleaning tasks have to
be performed on data already in the database
1.2 The Proposed system
The system under development, RDM2TM shall address these problems by inclusion of a
centralized database housed on a dedicated server machine, in a network environment,
into which users working concurrently on remote client computers shall be able to upload
the data. The resulting application shall produce a hybrid client-server application with
server modules for handling business logic and client modules that allow the rightful
users to easily access, evaluate, and manipulate information for road management and
engineering purposes, according to the rights assigned to them by the supervisor of the
RDM2TM system.
1.3 Problem definition
The system under development, RDM2TM, shall provide a client-server application for
handling road network data and making it available via the web.
5
2. SYSTEM MODELS FOR PROPOSED SYSTEMS
2.1 Context Level DFD
HDM USER-DETAIL
SUPERVISOR
HDM-REPORT
RDM-REPORT
RDM
USER-DETAIL RDM-REPORT
USER-DETAIL
RDM-REPORT
ROAD-DETAIL
LIMITED USER BRIDGE-DETAIL DATA TECHNICIAN
KEY
PROCESS
EXTERNAL ENTITY
DATA FLOW
6
2.2 Overview DFD
DATA TECHNICIAN SUPERVISOR
RDM2-DATABASE
LIMITED USER
2.
1.
SUPERVISOR MANAGE
AUTHENTICATE
USERS
USER DETAIL USER DETAIL
INVALID USER
VALID-USER
ROAD-DETAIL
4.
BRIDGE-DETAIL MANAGE
ROAD DATA
RDM2-BACKUP-
3. DATABASE
MANAGE
ROAD-DETAIL
BRIDGE DATA
BRIDGE-DETAIL RDM2-
DATABASE
RDM2-
KEY DATABASE
REPORT
PROCESS 5.
GENERATE REPORT
REPORT
EXTERNAL ENTITY
DATA FLOW
DATA STORE
7
2.3 Level 2 DFD: Authenticate Process
USERNAME
1.1 USERNAME
GET USERNAME
PASSWORD
AND PASSWORD
1.2
VALIDATE
USERNAME AND
PASSWORD PASSWORD
INVALID
USER
RDM2
DATABASE
VALID
USER
SUPERVISOR
1.3 DATA TECHNICIAN

ASSIGN-USER-
LEVEL
LIMITED USER
KEY
PROCESS
EXTERNAL ENTITY
DATA FLOW
DATA STORE
8
2.4 Level 2 DFD: Manage-User Process
USER-DETAIL
USER-DETAIL 2.1
ADD NEW USER
2.2
CHANGE USER
LEVEL
RDM2
DATABASE
USER-DETAIL
2.3
DELETE USER
KEY
PROCESS
EXTERNAL ENTITY
DATA FLOW
DATA STORE
9
2.5 Level 2 DFD: Manage-Bridge-Data Process
BRIDGE-DETAIL
3.2
BRIDGE-DETAIL 3.1 MODIFY-BRIDGE-
ADD-BRIDGE- DETAIL
DETAIL
RDM2
DATABASE
RDM2
DATABASE
BRIDGE-DETAIL 3,3
DELETE-BRIDGE-
DETAIL
KEY
PROCESS
EXTERNAL ENTITY
DATA FLOW
DATA STORE
10
2.6 Level 2 DFD: Manage-Road-Data Process
ROAD-DETAIL
4.2
ROAD-DETAIL 4.1 MODIFY-ROAD-
ADD ROAD- DETAIL
DETAIL
RDM2-DATABASE
RDM2-DATABASE
ROAD-DETAIL 4,3
DELETE-ROAD-
DETAIL
KEY
PROCESS
EXTERNAL ENTITY
DATA FLOW
DATA STORE
11
2.7 Level 2 DFD: Generate-Report Process
RATING
PREVIEW
REPORT
5.1
CALCULATE
BRIDGE
CONDITION 5.3
RATING CREATE-PREVIEW-
REPORT
RDM-DATA
RDM-DATA
RDM2
RATING
DATABASE
RATING
RDM-DATA RDM2
DATABASE
RDM-DATA
5.4
CREATE HDM 5.2
REPORT CALCULATE-
OVERALL -ROAD
CONDITION-RATING
RATING
HDM REPORT
KEY
PROCESS
EXTERNAL ENTITY
DATA FLOW
DATA STORE
12
3. DATA DICTIONARY
 BRIDGE − INVENTORY 
BRIDGE-DETAIL =  BRIDGE − CONDITION − DETAIL
 
DATA-TECHNICIAN = VALID-PASSWORD + VALID-

USERNAME + USER-LEVEL 2
LIMITED-USER = VALID-PASSWORD + VALID-

USERNAME + USER-LEVEL 3
 PAVEMENT − LAYER − DETAILS 

USER − DETAIL 
 
RDM2-DATA =  ROAD − NETWORK − DETAIL 
 
 ROAD − ROUGHNESS − DETAIL 
TRAFFIC − COUNTS 
 
 BRIDGE − CONDITION − DETAIL
 BRIDGE − INVENTORY 
 
INVALID USER = aliases: none
RDM-REPORT = RDM2-DATA + DATE
RATING = aliases:  ROAD − CONDITION − RATING  =

 BRIDGE − CONDITION − RATING 
INVENTORY-CONDITION-SCORE-
REPORT
 PAVEMENT − LAYER − DETAILS 

USER − DETAIL 
 
REPORT =  ROAD − NETWORK − DETAIL  + DATE
 
 ROAD − ROUGHNESS − DETAIL 
TRAFFIC − COUNTS 
 
 BRIDGE − CONDITION − DETAIL
 BRIDGE − INVENTORY 
 
 ROAD − INVENTORY 
ROAD DETAIL =  ROAD − CONDITION − DETAIL
 
SUPERVISOR = VALID-PASSWORD + VALID-USERNAME

+ USER-LEVEL 1
USER-DETAIL = USERNAME + PASSWORD + USERLEVEL
VALID-USER = VALID-PASSWORD + VALID-USERNAME +

VALID-USER-LEVEL
13
4.0 FUNCTIONAL REQUIREMENTS
4.1 User management
Name UR-1: Authenticate

Description The system shall authenticate the users and based on the
identity of the user it shall set the set of allowable
operations the particular user can perform
Priority Very high
Rationale Very sensitive operations on the system should not be
left to anyone to perform. Each user should be given a
local view of the system.
Input Username and password
Basic course of events 1. User indicates he/she wants to use the system
2. System asks for username and password
3. User enters the username and password
4. System validates the username and password and
sets the local view for the user.
Name UR-2: Add new user

Description The RDM system shall be able to register new users and
set their access level to the system.
Priority High
Rationale The RDM system should be able to add new users to the
system or else it may be unusable.
Input Username, initial password, user level.
Basic course of events 1. System administrator (supervisor) indicates that
there is need to add a new user.
2. The system responds by requesting the inputs
indicated above
3. The supervisor enters the set of input.
4. The software adds the new user and sets his/her
access level.
Name UR-3: Delete user from the system

Description The RDM system shall be able to delete new users from
the system.
Priority High
Input Username.
Basic course of events 1. Supervisor indicates that he/she wants to delete a
user from the system
indicated above
3. Supervisor enters the set of input
4. System deletes a user from the system
14
Name UR-4: Change user level
Description The RDM system shall be able to change the user level
of a particular user
Priority High
Rationale User who change job responsibilities need to have new
levels of system access.
Input Username, new user level.
Basic course of events 1. Supervisor indicates that he/she wants to change
the level of a user.
indicated above
3. Supervisor enters the set of input
4. System changes the level of the user.
4.2 Road data management
Name UR-5: Add bridge/road details

Description RDM shall be able to add the details of a road/bridge
collected from road surveys.
Priority High
Rationale The basic purpose of the system is to manage road data.
Without adding bridge data.
Input Data collected from road surveys.
Basic course of events 1. User indicates that he/she wants to add
bridge/road details.
indicated above
3. User enters the set of input
4. System checks that the input comes from
appropriate domains and adds it to database.
Name UR-6: Delete bridge/road details

Description The system shall be able to delete bridge/road details
from its database.
Priority High
Rationale Data with errors or that which is unnecessary will have
to be deleted from the system database.
Basic course of events 1. User indicates that he/she wants to delete
indicated above
3. User enters the set of inputs
4. System checks that the input is available in the
database and deletes it.
15
Name UR-7: Modify road/bridge details
Description The system shall be able to modify the details that are
already in the database.
Priority High.
Rationale Details for a particular road/bridge will have to be
modified after a new road survey comes up with new
details for that road.
Basic course of events 1. User indicates that he/she wants to modify
indicated above
3. User enters the set of input
4. System checks that the input is available in the
database and modifies it.
4.3 Report Requirements
Name UR-8: Generate report

Description The system shall be able to generate reports of particular
details in the database.
Priority High
Rationale Facts in the database will be of no use if it will not be
put in reports.
Input Report format, data to be included in the report.
Basic course of events. 1. User indicates that he/she wants to generate/view
a report.
indicated above
3. User enters the set of inputs
4. System generates the appropriate report.
16
5.0 NON-FUNCTIONAL REQUIREMENTS
5.1 Hardware Requirements
The following are the minimum hardware specifications:

HARDWARE MINIMUM RECOMMENDED
Server Machines (2) 1 GB RAM 4GB RAM
30MB Storage Space 120GB
3.6GHz Processor 4.8GHz Processor
User 128MB RAM 512 MB RAM
32 bit file System 32 bit file System
1024*728 pixels
700MB Processor 1.7MB Processor
Printers Inkjet type Laser printers

UPS 600VA 1KVA
The availability of the above hardware requirements will achieve the following non-
functional requirements
5.2 Efficiency
The system will be able to run efficiently on a 32-bit machine with at least 1 GB RAM
The system will allow users to use accelerators such as short cuts and also command line.
5.3 Reliability
One of the two server machines will be used for back up. As such, it will be possible to
maintain important data at all times in case of system crushes.
In the event of power failures as it has become the order of the day in most parts of the
country, the sourced UPS will make the system available at all times.
5.4 Usability Requirements
5.4.1 Learnability
The interface will be designed to help the new users learn how to use the system with
ease. This is to be achieved through a well designed GUI interface.
There will be a user manual accompanying the help facility that is to be provided
5.4.2 Exceptional Handling
The System will be developed with the capability of exception handling in the face of
errors. Instead of the system shutting down when an error occurs, the system will be able
to attempt handling it.
17
5.4.3 Multiple Views
The system shall also allow for multiple views and Concurrency Control
Concurrency control
5.5 Software Tools
The system will be developed in a windows platform.
• MySQL will be an instrument for database development
• The system will be tested
5.6 Delivery
The system is expected to be ready for delivery by the end of January 2009.
18
6.0 SYSTEM LIMITATIONS
This section discusses the limitations the system will have in order for it to operate
properly.
6.1 User’s Computer Literacy
Moderate and expert users will generally use this system. The system demands its users
to have good knowledge of windows applications, Internet browser (internet explorer or
Netscape navigator), and Database applications. System learnability for novice users has
also been put into reasonable consideration.
6.2 Applicability
The system will be designed for Road and Bridge Data management for the Malawi
National Roads Authority. The system therefore holds many technical terms applied in
civil engineering, which are relevant to the users’ field of application. It should be noted
therefore that this is not a generic system and will only include functionalities deemed as
necessary for Road and Bridge Data management by the NRA.
6.3 Access
Access to this system will be limited to authorised members of NRA. The system will be
accessed from any place where the Internet is accessible.
6.4 Hardware
RDM 2 will have the following hardware specifications for proper running of the
program
Hardware Minimum Spec Recommended Spec

Server Machine 3.6 GHz 4.8GHz Processor
1GB RAM 4GB RAM
40GB Hard Disk Space 120GB
1024*728 pixels 1024*728 pixels
User Machine 128MB RAM 512 MB RAM
32 bit file system 32 bit file system
1024*728 pixels 1024*728 pixels
19
7.0 SYSTEM EVOLUTION
As more roads and bridges are being constructed through out the country, the database
size of the RDM is most likely to expand. Hardware evolution in terms of Server storage
capacity continues to improve. Future projections for the RDM are that it will hold a
bigger database and will support more other external systems like the HDM.
As more departments at the NRA are getting automated, it is most likely that RDM may
later get integrated with other administrative systems for the organisation to create one
information management system.
8.0 INDIVIDUAL CONTRIBUTIONS

This section outlines contributions made by team members towards production of this
document
Team Member Contribution
Epiphan B. Chiunjira Introduction

Table of Contents
Hannah Sakala System Model
Kanthungo Kapachika System Evolution
Appendix
Amos Ben Non-Functional Requirements
Leo Maluwa Functional Requirements
Cover Pages
20
9.0 APPENDIX
9.1 Glossary
Adaptability
Capability of system to adopt new concepts
Client
The Purchasers of the System
.
Inventory
Inventory is a collection of information for each sub-link within a link. This
inventory data includes pavement construction and geometry details, details of
road assets such as bridges, culverts and road signs, as well as information about
social and economic activity along the road.
Ordnance
The ordnance survey defines the zone and district in which a link is located and
the road designation number
Pavement Layer Details

On the paved road network, Dynamic Cone Penetrometer (DCP) tests are carried
out at 2 km intervals. The results of these tests provide details on the thickness
and strength of each pavement layer, which are then used to evaluate the
structural number (strength) of the pavement, which is then used in the HDM-4
analysis. The results of each test are applied to the two adjoining sub-links at
each test point.
Project Team
The System Development Group
Road Network
The geographical area of Malawi is divided into Regions, Zones and Districts.
These attributes along with a road designation number define the road network.
The Current network managed by NRA comprises approximately 15,500 km of
road of which 4000 km are paved, primarily surface dressings, and the remaining
21
11,500 km are unpaved, primarily earth roads. All roads are sub-divided into
links, where a link is a length of road between two significant landmarks, such as
major junctions. The links have been uniquely numbered and are identified by
their start and end point descriptions and GPS coordinates. Whilst roads can span
several districts and zones, the start and end points of links are generally restricted
to be within a single district. Each link has been divided into one or more sub-
links, which are lined sequentially from the start of the link. The last sub-link can
have any length between 1 m and 999 m.
Road Network Surveys

A mechanism used By NRA to collect data related to Road and Bridge networks
Roughness
The roughness of each sub-link is measured using a vehicle mounted bump
integrator. Measurements are conducted at a constant speed of 30, 50 or 70 km/h
depending on the ride quality of the surface and traffic conditions. The vehicles
that are used to measure roughness are calibrated against the Merlin to enable the
roughness readings from the vehicle mounted bump integrator to be converted
into the standard International Roughness Index (IRI) units.
Surface Condition
Separate road surface condition surveys are carried out for paved and unpaved
roads annually. The condition of each sub-link on each link is recorded. On
paved roads the condition of the surfacing is recorded in terms of rutting,
cracking, ravelling, potholes, patching, bleeding and edge failures. On unpaved
roads the condition is recorded in terms of carriageway shape and gravel
thickness. These condition parameters are recorded as Good, Fair, Poor or Bad.
For both types of road, the condition of the drainage is also recorded in a similar
manner.
Traffic Counts
22
These are traffic levels counted at different locations in both paved and unpaved
roads
Web Based System

System Accessible On The Internet
9.2 List of Abbreviations
API Application Programmers Interface
GIS Geographical Information System
HDM Highway Development and Management
IDE Integrated Development Environment
NRA National Roads Authority of Malawi
N/A Not Applicable
PMS Pavement Management System
RDM Road Data Manager
SMS Short Message Service
23
10. BIBLIOGRAPHY
1. Elmasri, Ramez and Navathe, Shamkant (1994), Fundamentals of Database
Systems, 2nd Ed., Addison Wesley.
2. Kendall, P.A. (1992), Introduction to Systems Analysis and Design: A structured

Approach, 2nd Ed, Northern Illinois University, W.M.C. Brown Publishers
3. Schach, S.R (1993), Software Engineering, 2nd Ed, Aksen Associates Incorporated
Publisher.
4. Sommerville, Ian. (1985), Software Engineering, 3rd Ed, Addison Wesley.
5. Greg Morosiuk and Henry Kerali (2001), The Highway Development and
ManagementTool - HDMV-4. IKRAMUs Seminar on Asphalt Pavement
Technology (ISAPT), Kuala Lumpur, October 2001.
www document retrieved on 26 August 2008 from:
http://www.transportlinks.org/transport_links/filearea/publications/1_760
_PA3759_2001.pdf
24

Final Srs

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Final Srs

Caricato da

Copyright:

Formati disponibili

SOFTWARE

Amos Beni (BSc/4/04)

SOFTWARE REQUIREMENTS SPECIFICATION DOCUMENT

TEAM MEMBERS: Kanthungo Kapachika (Bsc/Me/62/05)

COURSE CODE: COM 412

COURSE NAME: Information Systems Project

CLIENT: National Roads Authority of Malawi

SUPERVISOR: Mr. Gregory Kunyenje

DATE: August 2008

1.1 Problems with the current system

The current RDM system operates in a standalone environment where it is housed on a

ii. Field errors are compounded as their resolution is sometimes (necessarily)

iv. When road inventory changes (for example due to a reconstruction or a

v. The database is transferable across computers making it extremely

1.2 The Proposed system

1.3 Problem definition

LIMITED USER BRIDGE-DETAIL DATA TECHNICIAN

DATA TECHNICIAN SUPERVISOR

1.3 DATA TECHNICIAN

DATA-TECHNICIAN = VALID-PASSWORD + VALID-

LIMITED-USER = VALID-PASSWORD + VALID-

 PAVEMENT − LAYER − DETAILS 

INVALID USER = aliases: none

RDM-REPORT = RDM2-DATA + DATE

RATING = aliases:  ROAD − CONDITION − RATING  =

 PAVEMENT − LAYER − DETAILS 

SUPERVISOR = VALID-PASSWORD + VALID-USERNAME

USER-DETAIL = USERNAME + PASSWORD + USERLEVEL

VALID-USER = VALID-PASSWORD + VALID-USERNAME +

Name UR-1: Authenticate

Name UR-2: Add new user

Name UR-3: Delete user from the system

4.2 Road data management

Name UR-5: Add bridge/road details

Name UR-6: Delete bridge/road details

4.3 Report Requirements

Name UR-8: Generate report

5.1 Hardware Requirements

The following are the minimum hardware specifications:

Printers Inkjet type Laser printers

5.4 Usability Requirements

5.4.2 Exceptional Handling

5.5 Software Tools

The system will be developed in a windows platform.

• MySQL will be an instrument for database development

• The system will be tested

6.1 User’s Computer Literacy

Hardware Minimum Spec Recommended Spec

8.0 INDIVIDUAL CONTRIBUTIONS

Team Member Contribution

Epiphan B. Chiunjira Introduction

Pavement Layer Details

Road Network Surveys

Web Based System

9.2 List of Abbreviations

API Application Programmers Interface

GIS Geographical Information System

HDM Highway Development and Management

IDE Integrated Development Environment

NRA National Roads Authority of Malawi

N/A Not Applicable

PMS Pavement Management System