1, introduction

1.1 purpose

The purpose of this software design document is to describe the architecture and
system design of the FDRE vital events registration system. This document is intended
for the developers, testers, and maintainers of the system, as well as the stakeholders
and users who need to understand the system’s functionality and features.

The FDRE vital events registration system is a web-based application that aims to
automate the process of registering, viewing, certifying, and reporting vital events such
as births, deaths, marriages, and divorces in Ethiopia. The system will replace the current
manual system that is prone to errors, delays, and inefficiencies. The system will provide
a central database that can be accessed by different offices at various levels (Keble,
zone, region, etc.) and allow data to be transmitted securely and efficiently. The system
will also enable statistical analysis of the vital events data and generate reports for
various purposes.

1.2 Design Goals

The design goals of the FDRE vital events registration system are derived from the non-
functional requirements specified in the SRS document. The design goals describe the
qualities of the system that developers should optimize. The design goals are:

 Performance Criteria: The system should have high response time, throughput,
and memory efficiency. The system should be able to handle multiple requests from
different offices simultaneously and provide timely feedback to the users. The system
should also minimize the memory usage and storage space required for the vital events
data.
 Dependability Criteria: The system should be robust, reliable, available, fault-tolerant,
and secure. The system should be able to handle errors and exceptions gracefully and
recover from failures quickly. The system should also ensure the availability of the
service and the data at all times. The system should also protect the data from
unauthorized access, modification, or deletion.
 End User Criteria: The system should be usable and useful for the end users. The system
should provide a user-friendly interface that is easy to navigate and understand. The
system should also provide the functionality and features that meet the user’s needs
and expectations. The system should also support the user’s tasks and goals related to
the vital events registration process.
 Maintenance Criteria: The system should be extensible, modifiable, portable,
and adaptable. The system should be able to accommodate changes and
enhancements in the future without affecting the existing functionality and
performance. The system should also be easy to modify and update as per the user’s
feedback and requirements. The system should also be portable and adaptable to
different platforms and environments.>

1.3 Scope

The scope of the software is to develop a web-based application that automates the
process of registering, viewing, certifying, and reporting vital events such as births,
deaths, marriages, and divorces in Ethiopia. The software will replace the current manual
system that is prone to errors, delays, and inefficiencies. The software will provide a
central database that can be accessed by different offices at various levels (Keble, zone,
region, etc.) and allow data to be transmitted securely and efficiently. The software will
also enable statistical analysis of the vital events data and generate reports for various
purposes.

The goals of the project are to improve the quality, accuracy, and timeliness of the vital
events data, to enhance the service delivery and customer satisfaction, and to support
the decision making and policy formulation related to the vital events. The objectives of
the project are to design and implement a user-friendly, reliable, and secure web-based
application that meets the functional and non-functional requirements specified in the
SRS document. The benefits of the project are to reduce the cost, time, and resources
required for the vital events registration process, to increase the data availability and
accessibility, and to provide valuable insights and information for the stakeholders and
users.

1.4 Overview

The rest of this document is organized as follows:

 Section 2 provides a system overview, where the general description and scope of the
software are summarized.
 Section 3 deals with the system architecture, where the proposed system architecture
and the design rationale are explained.
 Section 4 presents the data design, where the entity relationship diagram, the data
dictionary, and the persistence modeling of the system are described.
 Section 5 provides the component design, where the logical, interaction, state dynamic,
and dependency modeling of the system are illustrated using UML diagrams.
 Section 6 provides the human interface design, where the overview of the user interface,
the screen images, and the screen objects and actions of the system are presented.>

2 System Overview

The automated vital event registration system is designed to streamline and automate the process of
registering vital events such as births, deaths, marriages, divorces, and adoptions. It aims to replace the
existing manual paper-based system with a more efficient and reliable software solution. The system is
web-based, allowing users to access it through web browsers on client machines.

The major components/modules to be modeled as subsystems in the automated vital event registration
system include:

Registration Subsystem: This subsystem handles the registration process for different vital events, such
as births, deaths, marriages, divorces, and adoptions. It provides the necessary forms and interfaces for
users to input the required information and securely submit the registration details.

Database Subsystem: The database subsystem is responsible for storing and managing the registered
vital event data. It maintains a centralized database that stores information about births, deaths,
marriages, divorces, and adoptions. This subsystem ensures data integrity, security, and efficient
retrieval of information.

Reporting Subsystem: The reporting subsystem generates statistical reports based on the registered vital
event data. It provides various statistical analysis tools and functionalities to extract meaningful insights
and trends from the data. These reports can be used for policy-making, planning, and decision-making
purposes.

The system interacts with various external components, including:

Server Machines: The server machines host the web-based system and handle its processing and storage
requirements. They store the application logic, handle user authentication and authorization, and
interact with the database subsystem to retrieve and store data.

External Systems/Components: The automated vital event registration system may interact with
external systems or components, such as government databases, identification systems, or payment
gateways for any necessary integrations or data exchange.

Overall, the automated vital event registration system aims to provide a user-friendly and efficient
platform for registering vital events, maintaining accurate and secure data, generating statistical reports,
and facilitating decision-making processes for government agencies and other stakeholders involved in
vital event management.

3 System Architecture

The system architecture section provides a detailed overview of the architectural design of the
automated vital event registration system. It aims to guide the reader in understanding the underlying
structure, components, and interactions within the system. By examining the system architecture,
readers will gain insights into how different modules and subsystems are organized and how they
collaborate to fulfill the system's functionalities.

The system architecture plays a crucial role in ensuring the system's scalability, maintainability, and
performance. It serves as the foundation for the development and deployment of the system, providing
a blueprint for software engineers and developers to implement and integrate the various components
effectively. Additionally, a well-designed system architecture enables future enhancements,
modifications, and integration with external systems.
In this section, we will delve into the architectural principles, patterns, and technologies employed in the
automated vital event registration system. We will explore the relationships between the registration
subsystem, database subsystem, reporting subsystem, and other key components. Furthermore, we will
discuss the interaction between client machines, server machines, and external systems/components.

Understanding the system architecture is essential for stakeholders involved in system design,
development, and maintenance. It provides a comprehensive view of how the system operates and how
its components work together to achieve the desired outcomes. By comprehending the system
architecture, stakeholders can make informed decisions, identify potential bottlenecks or scalability
challenges, and ensure the system is aligned with the intended goals and requirements.

3.1 Proposed System Architecture

The proposed system architecture of the automated vital event registration system follows a modular
program structure, where responsibilities are partitioned into distinct subsystems. These subsystems
collaborate to achieve the complete functionality of the system. Here is an overview of the major
subsystems and their assigned roles or responsibilities:

Registration Subsystem: This subsystem is responsible for handling the registration process for vital
events. It provides user interfaces for capturing and validating vital event information, such as births,
deaths, marriages, divorces, and adoptions. The Registration Subsystem ensures the accuracy and
completeness of the entered data before storing it in the database.

Database Subsystem: The Database Subsystem serves as the central repository for storing and managing
registered vital event data. It is responsible for securely storing the collected data, ensuring data
integrity, and providing efficient storage and retrieval mechanisms. This subsystem interacts with the
Registration Subsystem to store the registered event data and provides data access to other subsystems
as needed.

Reporting Subsystem: The Reporting Subsystem generates statistical reports based on the registered
vital event data. It performs data analysis, generates visual representations, and provides insights into
trends, patterns, and demographic information. This subsystem utilizes the data stored in the Database
Subsystem to generate meaningful reports that can be used for decision-making and policy-planning
purposes.

The proposed system architecture can be represented diagrammatically as follows:

gherkin

Copy

+------------------------+

| Registration Subsystem |

+------------------------+

+------------------------+

| Database Subsystem |

+------------------------+

+------------------------+

| Reporting Subsystem |

+------------------------+

In this diagram, the Registration Subsystem interacts with the Database Subsystem to store registered
event data. The Reporting Subsystem retrieves data from the Database Subsystem to generate statistical
reports.
The modular program structure and the division of responsibilities into subsystems allow for a clear
separation of concerns and promote maintainability and reusability. Each subsystem focuses on a
specific aspect of the system's functionality, enabling easier development, testing, and maintenance. It
also facilitates scalability, as individual subsystems can be scaled independently to accommodate
increasing demands.

or

3.1 Proposed System Architecture < The proposed system architecture for the FDRE vital
events registration system is based on the three-tier architecture model, which
consists of three layers: presentation, business, and data. The three-tier architecture
model allows for better modularity, scalability, security, and maintainability of the
system.

The presentation layer is responsible for providing the user interface and interaction
with the system. It consists of web pages that are rendered by a web browser and
communicate with the business layer using HTTP requests and responses. The
presentation layer also implements the access control and authentication mechanisms
for the system.

The business layer is responsible for implementing the business logic and functionality
of the system. It consists of web services that are hosted by a web server and process
the requests from the presentation layer. The business layer also communicates with the
data layer to access and manipulate the vital events data.

The data layer is responsible for storing and managing the vital events data. It consists
of a relational database that is hosted by a database server and provides the persistence
modeling for the system. The data layer also ensures the integrity and consistency of the
data.

3.2 Design Rationale

The selected architecture described in Section 3.1, which consists of the Registration Subsystem,
Database Subsystem, and Reporting Subsystem, was chosen based on several critical factors and trade-
offs. The design rationale for selecting this architecture is as follows:

Modularity and Separation of Concerns: The chosen architecture follows a modular design, where
responsibilities are divided into distinct subsystems. This approach promotes modularity, making it
easier to develop, test, and maintain each subsystem independently. It also allows for better separation
of concerns, enabling focused development efforts on specific functionalities.

Scalability and Performance: The proposed architecture supports scalability by allowing individual
subsystems to be scaled independently. For example, if the reporting functionality experiences
increased demand, the Reporting Subsystem can be scaled horizontally or vertically without affecting
the other subsystems. This scalability ensures efficient system performance and responsiveness.

Data Integrity and Security: The Database Subsystem serves as a centralized repository for storing and
managing registered vital event data. This approach ensures data integrity, as all data is stored in a
single reliable source. It also facilitates data security measures, such as access controls, encryption, and
backups, to protect sensitive information.

Flexibility and Extensibility: The selected architecture provides flexibility and extensibility for future
enhancements and integration with external systems. Each subsystem can be easily extended or
modified without impacting the entire system. For example, if new types of vital events need to be
registered in the future, the Registration Subsystem can be extended to accommodate these changes
with minimal disruption.

During the design process, alternative architectures were considered, but not chosen for specific
reasons:

Monolithic Architecture: A monolithic architecture, where all functionalities are tightly coupled into a
single application, was considered but not chosen. This architecture could have simplified development
in the initial stages but would have limited scalability and hindered future modifications or
enhancements. The modular approach provides better flexibility and scalability.

Microservices Architecture: A microservices architecture, where functionalities are divided into separate
services that communicate through APIs, was also considered. While microservices offer benefits such as
independent development and scalability, the complexity and overhead associated with managing
multiple services were deemed unnecessary for the current scope of the automated vital event
registration system.
 By selecting the proposed architecture, we strike a balance between modularity, scalability, data
integrity, and flexibility. It allows for efficient development, maintenance, and future enhancements of
the system while ensuring reliable performance and data security.

Or

The rationale for selecting the three-tier architecture model for the FDRE vital events
registration system is based on the following critical issues and trade-offs that were
considered:

 Modularity: The three-tier architecture model allows for a clear separation of concerns
and responsibilities among the presentation, business, and data layers. This enhances
the modularity of the system, as each layer can be developed, tested, and maintained
independently. It also facilitates reusability, as each layer can be reused for different
purposes or applications.
 Scalability: The three-tier architecture model enables scalability of the system, as each
layer can be scaled independently to accommodate increasing demands. For example,
the presentation layer can be scaled by adding more web servers, the business layer can
be scaled by adding more web services, and the data layer can be scaled by adding
more database servers or partitions. This improves the performance and availability of
the system, as it can handle more concurrent requests and data volume.
 Security: The three-tier architecture model enhances the security of the system, as each
layer can implement its own security mechanisms and policies. For example, the
presentation layer can implement access control and authentication mechanisms to
prevent unauthorized access to the system, the business layer can implement encryption
and decryption mechanisms to protect the data in transit, and the data layer can
implement backup and recovery mechanisms to protect the data at rest. This reduces
the risk of data breaches and losses, as well as ensures the confidentiality, integrity, and
availability of the data.
 Maintainability: The three-tier architecture model improves the maintainability of the
system, as each layer can be modified and updated without affecting the other layers.
For example, the presentation layer can be modified to change the user interface or the
interaction style, the business layer can be modified to change the business logic or the
functionality, and the data layer can be modified to change the data model or the
storage format. This reduces the complexity and cost of the system maintenance, as well
as enables easier adaptation to changing requirements and feedback.

Other architectures that were considered but not chosen for the system are:
 Two-tier architecture model: This model consists of two layers: presentation and data.
The presentation layer directly communicates with the data layer, without any
intermediate layer. This model was not chosen because it has several drawbacks, such as
low modularity, low scalability, low security, and low maintainability. For example, the
presentation layer would have to implement both the user interface and the business
logic, which would increase the complexity and coupling of the system. The data layer
would also have to handle both the data storage and the data processing, which would
decrease the performance and efficiency of the system. Moreover, the security and
maintenance of the system would be compromised, as any changes or errors in one
layer would affect the other layer.
 N-tier architecture model: This model consists of more than three layers, where each
layer performs a specific function or task. The n-tier architecture model can be seen as
an extension of the three-tier architecture model, where additional layers are added to
provide more functionality or features. This model was not chosen because it has some
disadvantages, such as high complexity, high overhead, and high latency. For example,
the n-tier architecture model would require more components and connections, which
would increase the complexity and cost of the system development and deployment.
The n-tier architecture model would also introduce more overhead and latency, as each
layer would have to communicate with multiple layers, which would decrease the
performance and responsiveness of the system.