SDD Sample POESSA

Pension Registration Management
System
Software Design Description (SDD)
Private Organization’s Employee’s Social
Security Agency
Phase –I
Version: 1.0
Document Id: project id (063-05-05) - PRMS-028
Information Network Security Agency (INSA)
Secured Information System Development Directorate
SEPTEMBER 2013G.C
Software Design Description for POESSA-PRMS Project 2
Based on IEEE Std1016TM-1998 document format
Template Code: SDD - TEMP – 028, Ver. 1.0 July 2013
Copyright © 2013 Information Network Security Agency (INSA)
No part of this publication may be reproduced in any form, in an electronic retrieval system or
otherwise, without the prior written permission of the publisher.
Note: Make sure this is the latest version while using this template
Template Revision History

Software Quality Assurance Team
Date Name Reason For Changes Version

07/08/2013 EleniYisehak First Release 1.0
DemissMammo
Document Revision History

Date Name Reason For Changes Version
18/09/2013 Asia kedir First Draft Draft
Seble Nida
ZelalemAlemayehu
24/09/2013 Asia kedir First round document review according to Draft
Seble Nida the standard by quality assurance team
30/09/2013 Asia kedir Second round document review according Draft

Seble Nida to the standard by quality assurance team
30/09/2013 Final Version 1.0
Information Network Security Agency (INSA) (063-05-05) - PRMS-028

TABLE OF CONTENTS
TEMPLATE REVISION HISTORY............................................................................................................................. 2
DOCUMENT REVISION HISTORY.......................................................................................................................... 2
LIST OF TABLES......................................................................................................................................... 5
LIST OF FIGURES....................................................................................................................................... 6
EXECUTIVE SUMMARY............................................................................................................................. 7
1 INTRODUCTION................................................................................................................................. 8
1.1 PURPOSE.......................................................................................................................................................8
1.2 SCOPE........................................................................................................................................................ 8
1.3 DEFINITIONS AND ACRONYMS.................................................................................................................9
1.4 REFERENCE MATERIAL..............................................................................................................................9
2 SYSTEM OVERVIEW........................................................................................................................ 10
3 SYSTEM ARCHITECTURE............................................................................................................... 12
3.1 ARCHITECTURAL DESIGN........................................................................................................................12

3.2 DESIGN RATIONALE................................................................................................................................13
4 DECOMPOSITION DESCRIPTION.............................................................................................. 15
4.1 SUBSYSTEM DECOMPOSITION................................................................................................................15

4.1.1 Registration Subsystem............................................................................................................15
4.1.2 Reporting subsystem.................................................................................................................17
4.1.3 User Management and Authentication subsystem.........................................................18
4.2 DATA DECOMPOSITION...........................................................................................................................20
4.2.1 Data Description..........................................................................................................................20
4.2.2 Employer Data Entity.................................................................................................................20
4.2.3 Employee Data Entity................................................................................................................20
4.2.4 Employee spouse Data Entity.................................................................................................20
4.2.5 Employee Child Data Entity.....................................................................................................21
4.2.6 Employee Parent Data Entity..................................................................................................21
4.2.7 Employee Service Data Entity................................................................................................21
4.2.8 Address Data Entity....................................................................................................................21
5 DEPENDENCY DESCRIPTION...................................................................................................... 22
5.1.1 Subsystem/Process Dependencies.......................................................................................22

5.1.2 Data Dependencies.....................................................................................................................23
5.1.3 Other Dependencies...................................................................................................................24
6 INTERFACE DESCRIPTION.......................................................................................................... 25
6.1 SUBSYSTEM INTERFACES........................................................................................................................25

6.1.1 Overview of User Interface......................................................................................................25
6.1.2 Registration Subsystem............................................................................................................26

6.1.3 Reporting subsystem.................................................................................................................31

6.1.4 User Management and Authentication subsystem.........................................................31
7 DETAILED DESIGN.......................................................................................................................... 34
7.1 SUBSYSTEM DETAILED DESIGN...............................................................................................................34

7.1.1 Registration Subsystem Detail Design................................................................................34
7.1.2 Reporting Subsystem Detail Design.....................................................................................44
7.1.3 User Management and Authentication Subsystem Detail Design............................45
7.2 DATA DETAILED DESIGN........................................................................................................................47
7.2.1 Employer Data Entity Detail Design.....................................................................................47
7.2.2 Employee Data Entity Detail Design....................................................................................48
7.2.3 Employee SpouseData Entity Detail Design.....................................................................49
7.2.4 Employee Child Data Entity Detail Design.........................................................................50
7.2.5 Employee Parent Data Entity Detail Design......................................................................50
7.2.6 Employee Service Data Entity Detail Design....................................................................51
7.2.7 Address Data Entity Detail Design........................................................................................52
7.2.8 Data Dictionary............................................................................................................................52
8 DESIGN SECURITY.......................................................................................................................... 61
8.1 SECURITY DESCRIPTION.........................................................................................................................61

8.2 IDENTIFY ASSETS....................................................................................................................................61
8.3 CREATE AN ARCHITECTURE OVERVIEW.................................................................................................61
8.4 DECOMPOSE THE APPLICATION..............................................................................................................62
8.5 THREATS AND COUNTERMEASURES DEVELOPMENT..............................................................................63
8.6 DATABASE SECURITY..............................................................................................................................64
8.6.1 Description.....................................................................................................................................64
8.6.2 Local User Management............................................................................................................65
8.6.3 Database Logging........................................................................................................................65
8.6.4 Database Link Privileges...........................................................................................................65
8.7 DETAILED SECURITY DESIGN..................................................................................................................65

LIST OF TABLES
Table 1: Registration sub-system feature detail description..............................................16
Table 2: Reporting sub system feature description...............................................................18
Table 3: User Management and Authentication subsystem feature description.........19
Table 4: Attribute description of registration sub system...................................................38
Table 5: Method description of registration sub system......................................................44
Table 6: Attribute description of registration sub system...................................................44
Table 7: Method description of reporting sub system...........................................................45
Table 8: Attribute description of user management and authentication subsystem. 46
Table 9: Method description of user management and authentication sub system...47
Table 10: Data dictionary of PRMS...............................................................................................62
Table 11: Threats and Countermeasures development table.............................................66

LIST OF FIGURES
Figure 1: Overall deployment architecture of PRMS..............................................................11
Figure 2: System architecture of PRMS......................................................................................13
Figure 3: Class diagram of registration sub-system..............................................................17
Figure 4: The class diagram of reporting sub-system...........................................................18
Figure 5: The class diagram of user Management and Authentication sub system...20
Figure 6: DFD diagram of PRMS....................................................................................................23
Figure 7: E-R diagram of PRMS.....................................................................................................24
Figure 8: Home page interface diagram....................................................................................25
Figure 9: Handle Employer Registration user interface........................................................26
Figure 10: Handle Employee Registration user interface.....................................................27
Figure 11: Handle Employee Spouse Registration user interface.....................................27
Figure 12: Handle Employee’s Child Registration user interface......................................28
Figure 13: Handle Employee’s Parents Registration user interface.................................29
Figure 14: Handle Employee Service Registration user interface.....................................29
Figure 15: Registration Search Result user interface............................................................30
Figure 16: Handle Reporting user interface..............................................................................31
Figure 17: Login user interface......................................................................................................32
Figure 18: User management user interface............................................................................32
Figure 19: Role and Resource management user interface................................................33
Figure 20: Employer data entity detail description................................................................48
Figure 21: Employee data entity detail description...............................................................49
Figure 22: Employee Spouse data entity detail description................................................50
Figure 23: Employee Child data entity detail description....................................................50
Figure 24: Employee Parent data entity detail description.................................................51
Figure 25: Employee Service data entity detail description................................................51
Figure 26: Address data entity detail description..................................................................52
Figure 27: Architecture overview of security............................................................................64
Figure 28: Detail design security Deployment diagram.......................................................68

Executive Summary
This software Design Description is representation or model of the software system to be

created by partitioning the system into design entities and describe the important properties and
relationships among those entities. POESSA’s PRMS SDD mainly consists of introduction of
the system, system overview, system architecture, subsystem and data decomposition, user
interface design, Data Dependencies using Data Flow Diagram & Entity relationship
diagrams, subsystem and data detail design & Design Security features. Even with this in
mind, some portions of the outline have been tailored to the needs of POESSA-PRMS project
stakeholders. We have chosen to present the user interface design in our design with an
open mind to accept major input and modification from the user.

1 Introduction
1.1 Purpose
The purpose of Pension Registration Management System (PRMS from now onwards) is to
automate pension registration business processes of POESSA. This purpose is attained
through a detailed study of the existing system and a proposed solution as specified in the
SRS. To meet the proposed system in the SRS this Software Design Description (SDD) will
provide a detailed design perspective from the software structure, software components,
interface, and data point of view. The SDD will give insight on how the system will provide a
mechanism for storing, retrieving and exchanging basic data and information from different
teams or processes. Moreover, this SDD describes the architecture and system design of
PRMS.
1.2 Scope
The SDD manages the system in to components which all together make up the whole
Pension Registration Management System in POESSA which is currently operating
manually. The system design document will include the following scope functionalities:
 Register, searching, sorting and updating employer data

 Register, searching, sorting and updating employee’s data
 Register, searching, sorting and updating employee’s spouse data
 Register, searching, sorting and updating employee’s child data
 Register, searching, sorting and updating employee’s parent data
 Register, searching, sorting and updating employee’s service data
 Manage user account
 Maintain lookup and settings
 Manage resource, and
 Display and Print reports

1.3 Definitions and Acronyms
The following definition and acronyms are considered in this document:
SDD Software Design Description (SDD)is a document used to

specify system architecture and application design in a
software related project.
Software Architecture It is the set of structures needed to reason about the software
system, which comprise the software elements, the relations
between them, and the properties of both elements and
relations.[
IEEE Institute of Electrical and Electronics Engineers
POESSA Private Organization’s Employee’s Social Security Agency.
SRS Software Requirement Specification
PRMS Pension Registration Management System
IIS Internet Information service, which is web server to deploy

web application.
1.4 Reference Material
In the development process of this document the following resources are referenced:
 [IEEE] The applicable IEEE standards are published in “IEEE Standards

Collection,” 2001 edition.
 SOFTWARE DESIGN DESCRIPTION (SDD) GUIDELINES; CS 480 / CS 481
 SOFTWARE DESIGN DESCRIPTION (SDD) Recommended Practice.
 Software Requirement Specification (SRS) document for POESSA PRMS

2 System Overview
PRMS is developed for the Federal Republic of Ethiopia Private Organization’s Employee’s
Social Security Agency. It manages pension registration service given at the agency. The
main functionalities of this system include employer registration, employee registration,
employee’s spouse registration, employee’s child registration, employee’s parent
registration and employee service registration. The system also provides user authentication
and user managementfacilities.
The PRMS system will be deployed based on a web services model. This will involve
establishing a web presence for the operational system that may be accessed by various
users. PRMS’s deployment diagram is depicted in the figure 1.
All functions are accessed via the government VLAN using a web browser for regional office
user or use direct access to head office users that use POESSA LAN. All functions are
accessed via the web pages. In addition to the core registration functionality the system
also provides:
1. Online Help: Help manual attached to system and available to users to access it
whenever needed.
2. Themes: user can change the Themes of the application according to his/her need.
Generally, User requests will be received by the web server application through IIS and the
request is parsed to determine the next step. The web server application will process
requests for dynamic HTML pages immediately. Hence, requests for IIS server will be
forwarded onto the application web server for dispatch to the appropriate service. Web
server will access the PRMS database residing on a separate machine. The web server
application returns formatted HTML pages to the web browser.

Figure 1: Overall deployment architecture of PRMS

3 System Architecture
3.1 Architectural Design
Pension Registration Management System (PRMS) is set of registration, reporting and

security subsystems working together to achieve Pension Registration Management System
in the core process. It enables potential users to interact with the system in the core
process.
To show the overall PRMS architecture, the software design is organized in to layered
system Architecture. The following layers are identified in the software architecture. These
are:
Presentation layer: it is a layer responsible for creating and displaying the user interface
and handling user interaction. This layer contains the user interface logic and process to
provide data to the user and provide a friendly working environment. Standard Telerik UI
components will be used to build the UI’s of all application in a uniform manner. Hence, the
layouts and UI components used for all applications will be similar.
Business layer: this layer is the core of every application which incorporates the main
functional units of the applications. Specific business rules are implemented at this layer in
that the extent and size of this layer greatly varies from application to application. These
layers also receive information, validate business rules associated with it and transfer it to
data access layer.
Data Access Layer: - this layer is used to provide a common interface between the
database and the application. It sends actual updates to the database by invoking an
appropriate stored procedure and populating its relevant parameters as well as generates
and returns Result Sets upon retrieval to the LINQ to SQL objects. This is a general pattern
among all applications to be developed. As a general rule we recommend that stored
procedures be used for both retrieval and update purposes. This is advantageous to utilize a
uniform data access layer among all applications as well as hide direct access to database
tables by applications.

Figure 2: System architecture of PRMS
3.2 Design Rationale
Architecture: The rationale behind for selecting of layered system architecture is related
with the following issues:
 Less code per layer

 Reduce complexity
 Easier to maintain code
 Easier to add new functionality to the system
 Allows reuse of code across the application

Design Goals:
 Usability: PRMS will provide intuitive web-based interfaces to users with varying
levels of access to PRMS data and system resources.
 Localization: The system should have a multilingual support for English and
Amharic, with regard to user interface and database back end.
 User friendly: Since users of the system have little knowledge about software
application, it has to be user friendly and easily accessible.
 Fault tolerance: The system has to close gracefully in case of fault.
 Modifiability: The system has to be easily modifiable and needs to be readable.
 Security: The System must ensure complete protection of data from unauthorized
access. All remote accesses are subject to user identification and password control.
 Response time: the system should respond in real time.
 Extensibility: the system should be modular in order to facilitate future changes.
Design Trade-offs:
User Friendliness VS Performance: developing an application with highly user

friendliness, such as selecting required employee ID from combo box, would make the
response time slow, therefore we decide to change the design of interface according to the
main limited band width resource, which enforce as reduce the user friendliness merit of
the system by making user enter the employee ID by him/herself.

4 Decomposition Description
According to the system architecture described in section 3.1, there are three subsystems in
PRMS. These subsystems are decomposed according to their functionality they contribute to
the whole system. Hence, the subsystems include: registration, reporting and security sub
system.
4.1 Subsystem Decomposition

4.1.1 Registration Subsystem
4.1.1.1 Registration Feature
This feature helps to register employers, employees, employee’s spouse, employee’s

child/children, employee’s parents and also employee service. It also allows editing or
modifying registered information and updating it based on the change whenever there is
such a need.
Use Case Name Use Case Description Responsible Class Responsible Method/s
Handle Employer Perform employer  EmployerUI  saveEmployer
Registration details registration; it  EmployerBLogic  updateEmployer
also helps editing and  Employer  searchEmployer
updating changes that  displayEmployer
will be made later.  selectEmployer
Handle Employee Perform employee  EmployeeUI  saveEmployee
Registration details registration; it  EmployeeBLogic  updateEmployee
also helps editing and  Employee  searchEmployee
updating changes that  displayEmployee
will be made later.  selectEmployee
Handle Employee Perform employee  EmployeeSuposeUI  saveEmployeeSupose
Spouse Spouse details  EmployeeSuposeBLogic  updateEmployeeSupose
Registration registration; it also  EmployeeSupose  searchEmployeeSupose
helps editing and  displayEmployeeSupose
updating changes that  selectEmployeeSupose
will be made later.
Handle Perform employee’s  EmployeeChildUI  saveEmployeeChild
Employee’s Child child/children details  EmployeeChildBLogic  updateEmployeeChild
Registration registration which is  EmployeeChild  searchEmployeeChild

according to the aging  displayEmployeeChild

rule; it also helps  selectEmployeeChild
editing and updating
changes that will be
made later.
Handle Perform employee’s  EmployeeParentUI  saveEmployeeParent
Employee’s parents’ details  EmployeeParentBLogic  updateEmployeeParent
Parent registration; it also  EmployeeParent  searchEmployeeParent
Registration helps editing and  displayEmployeeParent
updating changes that  selectEmployeeParent
will be made later.
Handle Employee Perform employee’s  EmployeeServiceUI  saveEmployeeService
Service Service details  EmployeeServiceBLogic  updateEmployeeService
Registration registration which is  EmployeeService  searchEmployeeService
according to the  displayEmployeeService
company he/she is/has  selectEmployeeService
been working; it also
helps editing and
updating changes that
will be made later.
Table 1: Registration sub-system feature detail description
4.1.1.2 Class Diagram
The class diagram of PRMS registration sub system consists of Employer, Employee,
Employee Spouse, Employee Child, Employee Parent, Employee Service and Address classes
elaborated in the figure blow.

Figure 3: Class diagram of registration sub-system
4.1.2 Reporting subsystem
4.1.2.1 Reporting Feature
This feature helps to generate different reports that are expected from the tasks performed
under the above feature and very useful to the agency; the reports can be viewed on the
screen as softcopy and can also be printed to get their hardcopy.
Use Case Name Use Case Description Responsible Class Responsible

Method/s
Handle reporting Helps to view different reports  ReportUI  SelectReport
which can be seen on the  ReportBusinessLogic  displayReport
screen as a softcopy or print it  Report  generateReport
as a hardcopy. It is a generic
use case which can apply for

all types of reports

incorporated into the system.
Table 2: Reporting sub system feature description
The class diagram of PRMS reporting sub system consist of only reporting class elaborated
in the figure below.
Figure 4: The class diagram of reporting sub-system
4.1.3 User Management and Authentication subsystem
4.1.3.1 User Management and Authentication Feature
This feature helps to create user account, set role and permission to user, manage
resources, maintain look up settings and authenticate users . It also allows editing or
modifying user and look up information, and updating it based on the change whenever
there is such a need.
Use Case Name Use Case Description Responsible Class Responsible

Method/s
Maintain user Covers the process of  AccountUI  createAccount
Account managing user such as  AccountBusinessLogic  updateAccount
creating user account (user  Account  deleteAccount
name and password).  displayAccount
Maintain User Create user role and  RoleUI  createrole

role and permission; it also helps  RoleBusinessLogic  updateRole

permission editing and updating  Role  deleteRole
changes that will be made  displayRole
later.
Manage Assign resources to the  ResourceUI  assignResource
resources appropriate user; it also  ResourcebusinessLogic  updateResource
helps editing and updating  Resourse  deleteResource
changes that will be made  displayResource
later.
Login Used to log in users in to the  LoginUI  validateLogin
system according to their  LoginBusinessLogic  displayLoginInfo
specific privilege.  Login
Maintain look up Add new look up information  LookUpUI  SaveLookup
settings that will be displayed under  LookUpBusinessLogic  displayLookUP
different combo/list boxes;  LookUp
it also helps editing and
updating changes that will
be made later.
Table 3: User Management and Authentication subsystem feature description

Figure 5: The class diagram of user Management and Authentication sub system
4.2 Data Decomposition

4.2.1 Data Description
PRMS databases are a group of files that are stored in database server’s secondary storage;
to make such file appropriate for the programmer, a group of data structure that are
needed to make the various transactions available like tables and stored procedures. These
are:
4.2.2 Employer Data Entity

This data entity mainly describes the information of the employer to be manipulated, that is
register, searching, sorting and updating employer data are carried out through it.
4.2.3 Employee Data Entity

In this data entity the information of the employee will be manipulated, that is insertion and
updating of employee data are carried out through it.
4.2.4 Employee spouse Data Entity

In this data entity the information of the employee spouse will be manipulated, that is
insertion and updating of employee spouse data are carried out through it.
4.2.5 Employee Child Data Entity

In this data entity the information of the employee child will be manipulated, that is
insertion and updating of employee child data are carried out through it.

4.2.6 Employee Parent Data Entity

In this data entity the information of the employee parent will be manipulated, that is
insertion and updating of employee parent data are carried out through it.
4.2.7 Employee Service Data Entity

In this data entity the information of the employee service will be manipulated, that is
insertion and updating of employee child data are carried out through it.
4.2.8 Address Data Entity

In this data entity the information of the employer address will be manipulated, that is
insertion and updating of employee address data are carried out through it.
5 Dependency Description

In PRMS there are seven entities these are: employer, employee, employee spouse,
employee child, employee parents, employee service, and employer address. In this system
employer is related with employee and address, and employee is related with its employer,
spouse, child, parent, service and address entities.
5.1.1 Subsystem/Process Dependencies
When discussing high level architecture of PRMS in section 3.1, the business layer contains
both registration and reporting sub system which depend up on the user management and
authentication sub system, this indicate that both registration and reporting sub system will
be handled after user management and authentication sub system since users
authentication is a must.

5.1.2 Data Dependencies
5.1.2.1 Data Flow Diagram
Figure 6: DFD diagram of PRMS

5.1.2.2 Entity Relationships
Figure 7: E-R diagram of PRMS
5.1.3 Other Dependencies
 Client PC should have a browser, preferably Mozilla Firefox.

 System is deployed on windows server 2008.
 End-users should be well aware of the registration process and computer literate.
 There must be POESSA owned minimum 2 MB VLAN to allow manage data centrally
and to process data securely.
 The MS Access database which is currently used will be migrated or imported to the
new system’s Oracle database.

6 Interface Description
6.1 Subsystem Interfaces
6.1.1 Overview of User Interface
Home page: This is the page the user sees after logging in. It is designed in a way that
makes it easy to navigate to any of other pages. This page is open to modification as we
move on.
Figure 8: Home page interface diagram

6.1.2 Registration Subsystem
This sub system allows registration and updating of employer, employee, employee spouse,
employee child, employee parent, employee service and employer/employee address
handled.
6.1.2.1 Screen Images
Handle Employer Registration:
Figure 9: Handle Employer Registration user interface

Handle Employee Registration:
Figure 10: Handle Employee Registration user interface
Handle Employee Spouse Registration:
Figure 11: Handle Employee Spouse Registration user interface

Handle Employee’s Child Registration:
Figure 12: Handle Employee’s Child Registration user interface
Handle Employee’s Parents Registration:
Figure 13: Handle Employee’s Parents Registration user interface

Handle Employee Service Registration:
Figure 14: Handle Employee Service Registration user interface
Registration Search Result:

Figure 15: Registration Search Result user interface

6.1.3 Reporting subsystem
It is a sub system which allows to display and print registration report handled by
appropriately selecting report type (required report), period (whether it is monthly,
quarterly, semi annually or yearly) and date (report starting date).
Handle reporting:
Figure 16: Handle Reporting user interface
6.1.4 User Management and Authentication subsystem
It is a sub system the login, useraccount creation and updating, role giving and
updating, resourceassignment and deletion, and look up and setting management.
Login:

Figure 17: Login user interface
User management:
Figure 18: User management user interface

Role and Resource management:
Figure 19: Role and Resource management user interface

7 Detailed Design
7.1 Subsystem Detailed Design
7.1.1 Registration Subsystem Detail Design
Detail ClassAttributes:
Class Attribute Name Data type Description
employer_Id String Represent each employer uniquely
TIN_Number Integer Represent Taxpayer Identity Number
folder_Number Integer Represent the file folder of

employer.
Employer name String Represent name of employer.
types_Of_Activity_Engaged String Represents the type of activity an

employer engaged.
number_Of_Permanent_Em Integer Represent the number of permanent

plolyee employee in specified employer.
date_Of_Establishment String Representthe establishment date of

the organization.
organization_Representativ String Represents the name of

e_Person representative of the organization.
choice_Of_Employee_Invol String Represents the choice of employee

ved_In_Provident_Fund whether it need provident fund or
not.
number_Of_Employee_Agre Integer Represents the number of employee

e_In_Provident_Fund agrees to choose provident fund.
representative_of_Orgnizati String Represents name of representative

on of the organization.
date_Of_Registration String Represents the date employer

register.
name_Of_Registration_Offic String Represents the name of registration

er officer carry out registration.

employee_Id String Represents the temporary

identification number of employee.
TIN_Number Integer Represent taxpayer identity number

of the employee
folder_Number Integer Represent the folder number that

contains employee information.
employer_TIN_Number Integer Represent the employer taxpayer

identity number
employee_Name String Represent the name of employee

Employee
name_Of_Employer String Represent the name of employer
sex Character Represent the sex(F or M) of

employee
mother_Name String Represent the name the mother
date_Of_Birth String Representdate of birth of an

employee
date_Of_Recruitment String Represent that represent date of

recruitment of an employee
gross_Salary String Represent gross salary of an

employee
citizenship String Represent citizenship of an

employee
date_Of_Registration String Represent registration date of an

employee
name_Of_Registration_Offic String Represent name of registration

er officer who register an employee
spouse_Id String Represent identification number of

spouse of an employee
Spouse
Name String Represent the name of spouse of an
employee
date_Of_Birth String Represent date of birth of spouse of

an employee

date_Of_Registration String Represent registration date of

spouse of an employee

er officer who register spouse of an
employee
children_Id String Represent identification number of

child of an employee
Name String Represent the name of child of an

Child employee
date_Of_Birth String Represent date of birth of child of an

employee
Sex Character Represent the sex(F or M) of child of

an employee
mother_Name String Represent mother name of child of

an employee
date_Of_Registration String Represent registration date of child

of an employee

er officer who register child of an
employee
parent_Id String Represent identification number of

parent of an employee
Name String Represent the name of parent of an

employee
Parent date_Of_Birth String Represent date of birth of parent of

an employee
monthly_Income Currency Represent monthly income of parent

of an employee.
way_Parents_Support String Represent the way an employee

support his/her parents
date_Of_Registration String Represent registration date of parent

of an employee


er officer who register parent of an
employee
service_Id String Representidentification number of

service of an employee
Service
employee_TIN_Number Integer Represent the employer taxpayer
identity number
name_Of_Employer String Represent the name of employer
date_Of_Registration String Represent starting date of an

employee in a specific organization
Leaving_date String Represent leaving date of an

employee from a specific
organization
monthly_Salary Currency Represent the currently updated

monthly salary of an employee
reason_For_Withdrawal String Represent reason for withdrawal of

an employee from specific employer

er officer who register service of an
employee
Address address_Id String Represent identification number
region String Represent region
sub_City String Represent sub city
city String Represent city
Woreda String Represent Woreda
Keble String Represent Kebele
house_Number String Represent house number
telephone_number String Represent telephone number
Po.Box String Representpost office box code
fax String Represent fax number
email_Address String Represent email-address

website String Represent website
Table 4: Attribute description of registration sub system
Detail ClassMethods:
Class Method Parameters Return Description

value
saveEmpl  employer_Id Save given
oyer()  TIN_Number Boolean information of
Employer  folder_Number value employer
 name
 types_Of_Activity_Engaged
 number_Of_Permanent_Emplolyee
 date_Of_Establishment
 organization_Representative_Perso
n
 choice_Of_Employee_Involved_In_
Provident_Fund
 number_Of_Employee_Agree_In_P
rovident_Fund
 representative_of_Orgnization
 date_Of_Registration
 name_Of_Registration_Officer
UpdateEm The same as parameters in save() Boolean update given
ployer() method value information of
employer
SearchEm  employer_Id Table of Search required

ployer() parameter employer

s of save information
method
DisplayE Has no parameter void Bind employer
mployer() dataset
information to
grid and
display it.
SelectEm Has no parameter  employer Select required
ployer() _Id employer and
return its ID
Employee SaveEmpl  employee_Id Boolean Save given
oyee()  TIN_Number value information of
 folder_Number employee
 employer_TIN_Number
 employee_Name
 name_Of_Employer
 sex
 mother_Name
 date_Of_Birth
 date_Of_Recruitment
 gross_Salary
 citizenship
ployee() method value information of
employee
SearchEm  employee_Id Table of Search required
ployee() parameter employee
s of save information
method
DisplayE Has no parameter void Bind employee
mployee() dataset
information to
grid and
display it.

ployee() _Id employee and

return its ID
SaveEmpl  spouse_Id Boolean Save given
oyeeSpou  Name value information of
Spouse se()  date_Of_Birth employee
 date_Of_Registration spouse
ployeeSpo method value information of
use() employee
spouse
ployeeSpo parameter employee’s
use() s of save spouse
method
mployeeS spouse dataset
pouse() information to
grid and
display it.
ployee _Id employee
Spouse () spouse and
return its ID
SaveEmpl  children_Id Boolean Save given
oyee  name value information of
Child Child()  date_Of_Birth employee’s
 sex child
 mother_Name
ployee method value information of
Child() employee’s
child
ployee parameter employee’s
Child() s of save child

method
mployee child dataset
Child () information to
grid and
display it.
ployee _Id employee’s
Child () child and return
its ID
SaveEmpl  parent_Id Boolean Save given
oyeePare  name value information of
Parent nt()  date_Of_Birth employee
 monthly_Income parent
 way_Parents_Support
ployeePar method value information of
ent() employee
parent
ployeePar parameter employee’s
ent() s of save parent
method
DisplayE Has no parameter void Bind
mployeeP employee’s
arent() parent dataset
information to
grid and
display it.
ployeePar _Id employee’s
ent() parent and
return its ID
Service SaveEmpl  children_Id Boolean Save given
oyeeServi  name value information of
ce()  date_Of_Birth employee

 sex service
 mother_Name
ployeeSer method value information of
vice() employee
service
ployeeSer parameter employee’s
vice() s of save service
method
DisplayE Has no parameter void Bind
mployeeS employee’s
ervice() service dataset
information to
grid and
display it.
ployeeSer _Id employee’sserv
vice() iceand return
its ID
Save  address_Id Boolean Save given
Address Address  region value information of
()  sub_City employer/empl
 city oyeeaddress
 Woreda
 Keble
 house_Number
 telephone_number
 Po.Box
 fax
 email_Address
 website
Update The same as parameters in save() Boolean update given
Address method value information of
() employer/

employee
address
Search  employee_Id Table of Search required
Address parameter employee
() s of save service
method
Display Has no parameter void Bind employer/
Address employee
() address dataset
information to
grid and
display it.
Select Has no parameter  employer Select required
Address _Id employer/
() employee
address and
return its ID
Table 5: Method description of registration sub system
7.1.2 Reporting Subsystem Detail Design
Detail ClassAttributes:

Reporting report_Name String Represent the name of
report that will be
selected
report_Type String Represent the type of
report (daily, monthly
etc.) displayed
date String Represent starting
date of report
Table 6: Attribute description of registration sub system

Detail ClassMethods:
Class Method Parameters Return value Description

Reporting SelectReport()  report_Name void Select information
 report_Type required to view
 date report.
GenerateReport() No parameter Data set Filter appropriate

information from
database
DisplayReport() No parameter void View report in
appropriate
format
Table 7: Method description of reporting sub system
7.1.3 User Management and Authentication Subsystem Detail Design
Detail ClassAttribute:

Role role_ID String Represent identification number
of role.
role_name String Represent name of role.
role_type String Represent type of role
Resource recourse_name String Represent resource name
recourse_path String Represent the folder path of
the resource.
Lookup lookup_ID String Represent identification number
of lookup.
lookup_name String Represent lookup name.
lookup_info String Represent lookup information
stored for use.
Account account_ID String Represent identification number
for user account.
user_Name String Represent user name of user
account.
password String Represent user password for
user account.
email_Address String Represent email address of

user of the account.

branch_ID String Represent branch identification
number that the account is
created.
Login user_Name String Represent user name used to
enter the system.
password String Represent password that
combine to above username to
enter the system.
Table 8: Attribute description of user management and authentication subsystem
Detail ClassMethod:
Class Method Parameters Return value Description

Role assignRole()  account_ID Boolean value It assign specific
 role_ID role to an account.
unassignedRole()  account_ID Boolean value It delete specific
 role_ID role to an account.
Resource addResource()  resource_name void It add a given
 resource_path resource/page to
application
removeResource()  recourse_name void It remove a given
 recourse_path resource/page
from application
Lookup addLookup()  lookup_ID Boolean value It adds lookup
 lookup_info information to
specific lookup
group
updateLookup()  lookup_ID Boolean value It updates lookup
 lookup_info information of
specific lookup
group
Account createAccount()  account_ID Boolean value It creates new user
 user_Name account for new
 password user.
 email_Address
 branch_ID
updateAccount()  account_ID Boolean value It updates already

 user_Name existing user

 password account.
 email_Address
 branch_ID
Login validateLogin()  user_Name Boolean value It validates the
 password user name and
password is
correct.
displayLoginInfo() No parameter void It display the
password and user
name mismatch
message.
Table 9: Method description of user management and authentication sub system
7.2 Data Detailed Design

7.2.1 Employer Data Entity Detail Design
Employer Entity is an entity that contains employer information as expressed in section

7.2.1 Employee entity detail design.
It has:
 Many to many relationships with employee entity
 One to many relationships with address entity.

Figure 20:Employer data entity detail description
7.2.2 Employee Data Entity Detail Design
Employee entity is an entity that containsemployee information as expressed in section

7.2.2 Employee entity detail design.
It has:
 Many to many relationship with employer
 One to one relationship with employee parents
 One to many with employee spouse
 One to many with employee children
 One tomany with employee service and
 One to one with address entity

Figure 21: Employee data entity detail description
7.2.3 Employee SpouseData Entity Detail Design
Employee spouse entity is an entity that containsemployee spouse information as expressed

in section 7.2.3 employee spouse entity detail design.
It has:
 One to many relationships with employee entity

Figure 22: Employee Spouse data entity detail description
7.2.4 Employee Child Data Entity Detail Design
Employee child entity is an entity that containsemployee child information as expressed in

section 7.2.4 employee child entity detail design.
It has:
Figure 23: Employee Child data entity detail description
7.2.5 Employee Parent Data Entity Detail Design
Employee parent entityis an entity that containsemployee spouse information as expressed

in section 7.2.5 Employee parent entity detail design.
It has:
 One to one relationship with employee entity

Figure 24: Employee Parent data entity detail description
7.2.6 Employee Service Data Entity Detail Design
Employee service entity is an entity that contains employee service information as

expressed in section 7.2.6 Employee Service entity detail design.
It has:
Figure 25: Employee Service data entity detail description

7.2.7 Address Data Entity Detail Design
Address entity is an entity that contains employer/employee address information as

expressed in section 7.2.7 Address entity detail design.
It has:
 One to many relationships with employer
 One to one relationship with employee entity.
Figure 26: Addressdata entity detail description
7.2.8 Data Dictionary
Table/Entity Data Member/Field Description Data Type Mandatory? Unique?

Name Name
Employer employer_id -is an attribute that varchar(50) YES YES
uniquely identify a given
employer.
TIN_number -is a unique number which integer(50) YES YES
is given to employer.
employer_folder_nu -number given to each integer(20) YES NO
mber folder of the employer.
name -is the name of the varchar(10 YES NO
organization. 0)
types_of_activity_en -is the type of work the varchar(70) YES NO

gaged organization engaged.

number_of_permane -is the number of integer(20) YES NO
nt_emplolyee employee which are
permanent.
date_of_establishme -is the attribute that shows varchar(10) NO NO
nt when the organization has
been established.
organization_represe -is the responsible person varchar(50) YES NO
ntative_person who is to finishes all of the
process given by POESSA.
previouse_provident -is the previous provident integer(10) NO NO
_fund fund of the employee.
choice_of_employee -is the choice of the varchar(10) NO NO
_involved_in_provid employee to involve in
ent_fund provident fund.
number_of_employe -is the number of integer(10) NO NO
e_agree_in_provide employee agree in
nt_fund provident fund.
date_of_registration -is the date where varchar(10) YES NO
organization start
registration in to the
system.
created_by -is a person (registration varchar(50) YES NO
officer) who is responsible
to input information of the
organization to the
system.
updated_by -is the registration officer varchar(10) NO NO
who is responsible to
update information of the
organization to the system
whenever if organization
announce new information
to POESSA.
created_date - is the date which is used varchar(10) YES NO
by registration officer to
record the documents
bring by organization to
the system.

updated_date -is the date to update varchar(10) NO NO

information of the
organization to the
system.
Employee employee_id -is the Identification varchar(50) YES YES
number which uniquely
identify employee.
TIN_number -is a number which is integer(50) YES YES
given to employee.
employee_folder_nu -is giving numbers to each integer(20) YES NO
mber folder of the employee.
organization_TIN_nu -is a unique number which integer(30) YES YES
mber is given to employer
first_name -is the first name of the integer(10) YES NO
employee.
middle_name Is the middle name of the integer(10) YES NO
employee
last_name -Is the last name of the integer(10) YES NO
employee
name_of_organizatio -Is the name of the varchar(10 YES NO
n organization 0)
sex -is the gender of the char(1) YES NO
employee.
mother_name -Is the mother name of varchar(50) YES YES
the employee
mother_middle_nam -is the middle name of the varchar(50) YES YES
e employee mother.
date_of_birth -is the date of birth of the varchar(10) YES NO
employee.
date_of_recruitment -is the time when did varchar(10) YES NO
employee recruit in
organization.
gross_salary -Is the full salary of the float(10) YES NO
employee
citizenship -is the country where varchar(20) YES NO
employee gets citizenship.
date_of_registration -is the date where varchar(10) NO NO
employee start registration
in to the system.


organization to the
system.
to POESSA.
the system.
information of the
organization to the
system.
Service Service_id -is a number that varchar(50) YES YES
uniquelyidentify service of
the employee.
employee_TIN_num -is a number which is integer(50) YES YES

ber given to employee.
name_of_organizatio -Is the name of the varchar(10 YES NO
n organization 0)
starting_date -is the date that shows the varchar(10) YES NO
employee start service.
montly_salary -Is the salary of the float(10) YES NO
employee.
reason_for_withdra -is the reason why varchar(20 NO NO
wal employee out from where 0)
he/she worked.
end_of_registration -is the time when varchar(10) NO NO
employee finished get
service in POESSA.


organization to the
system.
to POESSA.
the system.
information of the
organization to the
system.
Spouse spouse_id -is a number that uniquely varchar(50) YES YES
identify spouse of the
employee.
spouse_first_name -is the first name of the varchar(50) YES NO

employee spouse.
spouse_middle_nam -Is the middle name of the varchar(50) YES NO
e employee spouse
spouse_last_name -Is the last name of the varchar(50) YES NO
employee spouse
date_of_birth - is the date of birth of the varchar(10) YES NO
employee spouse.
organization to the
system.


to POESSA.
the system.
information of the
organization to the
system.
Children children_id -is a number that uniquely varchar(50) YES NO
identify children of the
employee.
child_first_name -is the first name of the varchar(50) YES NO

employee child.
child_middle_name -Is the middle name of the varchar(50) YES NO
employee child.
child_last_name -Is the last name of the varchar(50) YES NO
employee child.
employee child.
sex -is the gender of the char(1) YES NO
employee.
mother_name -is the name of the varchar(50) YES YES
employee children mother
name.
organization to the
system.

to POESSA.
the system.
information of the
organization to the
system.
Parent parent_id -is a number that uniquely varchar(50) YES YES
identify parents the
employee.
parent_first_name -is the first name of the varchar(50) YES NO
employee parents.
parent_middle_nam -Is the middle name of the varchar(50) YES NO
e employee parents.
parent_last_name -Is the last name of the varchar(50) YES NO
employee parents
employee parents.
monthly_income -is the salary earned by float(10) YES NO
the employee parents.
way_parents_suppor -is the condition parents varchar(50) NO NO
t get income.
organization to the
system.
to POESSA.


the system.
information of the
organization to the
system.
Address address_id - is a number that varchar(10) YES YES
uniquely identify address
of both the employee and
the employer.
region -is the region of both (the varchar(30) YES NO
employee and employer).
sub_city -is the sub_city of both varchar(30) NO NO
(the employee and
employer).
city -is the city of both (the varchar(30) YES NO
woreda -is wereda where located varchar(10) YES NO
both (the employee and
employer).
keble - is the keble both (the integer(10) YES NO
house_number - is the house_number of varchar(20) NO NO
employer).
telphone_number -is the telephone number varchar(20) YES NO
of both (the employee and
employer).
pobox -is the pobox number of varchar(20) NO NO
employer).
fax -is the fax of both (the integer(10) NO NO
email_address -is the email_address of varchar(50) NO NO
employer).
website -is the website of the varchar(50) NO NO

employer.
Table 10: Data dictionary of PRMS

8 Design Security
8.1 Security Description
The computer-related system has both theoretical and real weaknesses. The purpose of
computer security is to devise ways to prevent the weaknesses from being exploited.
Computer security rests on confidentiality, integrity and availability. Confidentiality is the
concealment of information or resources. Integrity refers to the trust worthiness of data or
resources. And, Availability refers to the ability to use the information or resource desired.
Hence in PRMS the main objective of security is ensuring data confidentiality, integrity and
availability.
8.2 Identify Assets
The assets we want to protect are:

1. Database
2. Web pages
3. Lookups and
4. User access role
Database: - we protect our database security from direct user access by using separate
database from the application using layered architecture and by creating username &
password to login in to the database.
Web pages: - we protect our web pages from removing or editing from the system by
giving specific role to one responsible person.
Lookups: we prevent data entry error by providing previously known and static information
by making the userto select from combo box. If there is a need to update such information
the user updates information to the database.
User access role: - we protect the confidentiality of data by controlling the role of the
user.

8.3 Create an Architecture Overview
To overcome the potential vulnerabilities of PRMS,its architecture isdesignedas layered

approachas shownin the figure below. There is no direct access to business logic and data
access layer and PRMS data base. Beyond its use as security wall this architecture has
various uses that are related to its simplicity for development. Its detail design is discussed
in section 8.7 below.
Figure 27: Architecture overview of security
8.4 Decompose the Application

User account Creation: Any user of the PRMS must have an account to access the
system, therefore the user account is created at this package. First, user’s first name, father
name and address registered; then a unique username and password with a combination of
small letter, capital letter and special characters (such as: @, #, &, etc.) with length of
more than 8 character is given to already registered user.
User Role and Permission Creation: It is impossible to give user name and password for
registered user without setting its role and permission. Thus such activity is handled in this
package.
Resource management: The main resource in our application is web page. Without
managing it we can’t control the overall gear of the PRMS. So the management of such
resource is handled in this package.
Login: It is the door of the PRMS, user who has an account and assigned specific role and
permission is authenticatedat this package.
Lookup and setting: all information predetermine for the user are entered the system
through lookup page that is access by administrator only. And also, setting related to the
PRMS is handled is this package.
In PRMS system there is a boundary between each layer, and data access and PRMS
database. Thus, each layer is communicated to another layer is through object and attribute
parameter passing. However, the data access and PRMS database are communicate through
object called LINQ TO SQL that is link to password protected oracle database. Since the
database is password protected the system handle communications by string connection
with in “web.config” page that validate password and user name of the database.
8.5 Threats and Countermeasures development
Threat to the
system/misuse
Asset name Use case case Counter measure

 Needs database security, audit

logging and database access control
protections.
 Password and username protected
Database All use case MUC-001 database.
 Resource management role assigned
only to administrator.
 The system is strong password
Web pages All use case MUC-001 protected.
 Lookup management role assigned
only to administrator.
 Tracking/auditing user activity
Lookup and  The system is strong password
Lookups settings MUC-001 protected.
 Role management role assigned only
to administrator.
User access  The system is strong password
role MUC-001 protected.
Table 11: Threats and Countermeasures development table
8.6 Database Security

8.6.1 Description
Database security is protecting data at the heart of many secure systems, and many users
(people, programs, or systems) rely on a database management system (DBMS) to manage
the protection.Following is a list of requirements for database security in PRMS system.
•Physical database integrity: The data of a database are immune to physical problems,
such as power failures, and someone can reconstruct the database if it is destroyed through
a catastrophe. It is responsibility of POESSA to mitigate it.
•Logical database integrity: The structure of the database is preserved. With logical
integrity database, a modification to the value of one field does not affect other fields, for
example.
 Element integrity: The data contained in each element are accurate.

 Auditability: It is possible to track who or what has accessed (or modified) the
elements inthe database.
 Access control: A user is allowed to access only authorized data, and different
users can berestricted to different modes of access (such as read or write).
 Userauthentication: Every user is positively identified, both for the audit trail and
forpermission to access certain data.
 Availability: Users can access the database in general and all the data for which
they areauthorized.
8.6.2 Local User Management
At the registration time detail information of the user are registered and stored in the data
base. As soon as the user logs in to the system, his/her detail information is executed and
stored in the session,and when data uploaded from the database only the data associated
with the user registered information are brought to manipulate. That is, data that is not
related to the user is not visible to user, or user can’t see or manipulate data that are not
under his/her branch.
8.6.3 Database Logging
Database logging information any other related information of the database are kept alive at
the installation directory of the oracle database server. These files open only by using
Oracle 11g database management server. Hence, only user who has the authority or have
user name and password can access; and some files are built-in by oracle and not editable
by any user.
8.6.4 Database Link Privileges
As we discuss in SRS section 3.3 we divide user classes and characteristics in to

administrator, power users and client users. Hence administrator has all insertion and
updatingof information but security reason deletion is not allowed for anyone in PRMS. In
case of power user, limited amount updating and insertion of role is given according to
POESSA IT regulation and some of security features such as assigning of resource are
hidden from him. However, for client user only insertion and editing of data for limited time
(practically 30 min) is allowed and almost all security features are hidden from him/her.

8.7 Detailed security design
It is detail design of security architecture in section 8.3.Each layer contains user creation,
user role and permission, resource management, and lookup and settings package; and
each package is divided in to layer. As shown in the figure below user creation, user role
and permission, resource management, and lookup and settings depend on login package,
which implies, without login user cannot use other services.
Figure 28: Detail design security Deployment diagram

SDD Sample POESSA

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SDD Sample POESSA

Uploaded by

Copyright:

Available Formats

Pension Registration Management

Information Network Security Agency (INSA)

Secured Information System Development Directorate

Based on IEEE Std1016TM-1998 document format

Template Code: SDD - TEMP – 028, Ver. 1.0 July 2013

Copyright © 2013 Information Network Security Agency (INSA)

Template Revision History

Date Name Reason For Changes Version

Document Revision History

30/09/2013 Asia kedir Second round document review according Draft

30/09/2013 Final Version 1.0

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

DOCUMENT REVISION HISTORY.......................................................................................................................... 2

3.1 ARCHITECTURAL DESIGN........................................................................................................................12

4.1 SUBSYSTEM DECOMPOSITION................................................................................................................15

5.1.1 Subsystem/Process Dependencies.......................................................................................22

6.1 SUBSYSTEM INTERFACES........................................................................................................................25

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

6.1.3 Reporting subsystem.................................................................................................................31

7.1 SUBSYSTEM DETAILED DESIGN...............................................................................................................34

8.1 SECURITY DESCRIPTION.........................................................................................................................61

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

This software Design Description is representation or model of the software system to be

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

 Register, searching, sorting and updating employer data

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

1.3 Definitions and Acronyms

The following definition and acronyms are considered in this document:

SDD Software Design Description (SDD)is a document used to

IEEE Institute of Electrical and Electronics Engineers

POESSA Private Organization’s Employee’s Social Security Agency.

SRS Software Requirement Specification

PRMS Pension Registration Management System

IIS Internet Information service, which is web server to deploy

1.4 Reference Material

 [IEEE] The applicable IEEE standards are published in “IEEE Standards

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

Figure 1: Overall deployment architecture of PRMS

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

Pension Registration Management System (PRMS) is set of registration, reporting and

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

Figure 2: System architecture of PRMS

3.2 Design Rationale

 Less code per layer

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

User Friendliness VS Performance: developing an application with highly user

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

4.1 Subsystem Decomposition

4.1.1.1 Registration Feature

This feature helps to register employers, employees, employee’s spouse, employee’s

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

according to the aging  displayEmployeeChild

Table 1: Registration sub-system feature detail description

4.1.1.2 Class Diagram

Information Network Security Agency (INSA) (063-05-05) - PRMS-028

Figure 3: Class diagram of registration sub-system

4.1.2 Reporting subsystem

4.1.2.1 Reporting Feature

Use Case Name Use Case Description Responsible Class Responsible

Information Network Security Agency (INSA) (063-05-05) - PRMS-028