CHAPTER THREE

SYSTEM ANALYSIS AND METHODOLOGY

3.1. INTRODUCTION

The chapter entails the system analysis and methodology section of the project. The system to be

developed will be outlined and explained alongside the process model (flowchart, ERD, context

model and use case) that will be used in designing and implementing an Electronic workflow (e-

workflow) for official document. The design and development tools that will be used will also be

explained in detail as well as the requirements for the system.

3.2. FEASIBILITY REPORT

Efforts are been made among global companies and institutions to move away from the

traditional way of transferring documents from one office to another for approval, into a

paperless environment where documents and files are been transferred and approved virtually

through the use of different software technologies.

This project is based on a virtual working environment where users work with electronic

documents and forms distributed via an e-workflow or e-distribution. Organizations usually have

a number of internal processes for tasks take for example a university environment which have

schools and departments, each departments usually have tasks to fulfill like the approval of

students course forms, approval of official documents and so on. Approval process is a type of

workflow, which can be described as any sequence of work from the start to completion that

users can create to ensure work is approved the same way every time, it standardizes an

organization’s internal process and also saves time by creating a reliable, repetitive system.
The approval of work has certain procedures the users will follow. Automated approval process

and workflows guides users through the process that ensure the flow of document is smooth,

completed and approved the same way every time. This process saves time, maximize efficiency

and standardize processes. It also improves transparency, work ethic and compliance within an

organization.

3.3 DESCRIPTION OF THE PROPOSED SYSTEM

The proposed system would provide a platform for organizations and their departments to make

use of electronic workflow or an automated approval system for electronic signatures in the

approval of official document. This system also ensures documents are submitted, routed,

reviewed, approved, tracked and also collaboration on different document types to make

approval decisions. The approval process begins with someone submitting something, it could be

a document or invoice etc. the system would have a submission portal where users submit their

work the portal could have a receipt option where users track their activity. This process would

also need to assign approvers either a person or a set of people who would have the final say, it

would define who would approve the work at different level. The system would allow users to

allocate who has the authority to edit, reject, or approve submissions i.e. it would have an editor

and administrator permissions. The system would allow users to have an option of setting

deadlines on any official document or project to keep the workflows moving and prevent the

accumulation of work. The system would have automatic alerts and notifications about the status

of submission, this would help in speeding up workflow. Automatic alerts may be approval or

rejection notifications, update requests (when the approver requests for a change or correction in

the original document) also a simple status update alerting users that the document is proceeding

to the next step in the process. Submissions have to go through multiple rounds of edits before
approval, so automatic alerts and notifications would ensure that the workflow is accomplished

swiftly and everyone involved in the process is aware of the current status. The system would

have a record log to uphold transparency and ensure consistency, this means user history (to

know who made changes, what and when). The system would have email templates for

notifications, also an edit requests where the submitter would receive a notification when the

submission has been temporarily rejected and would require changes before approval. Once a

workflow starts all participants would receive notifications and users can also set a period of

time each participants have for approval also the status of the workflows can be monitored by the

users participating in the workflow, to ensure that all workflows are progressing.

3.4 DESIGN MODEL

A software development model outlines the processes involved in the design, development and

deployment of software product. There are variety of process models that can be adopted for any

software development project. For electronic workflow for official document the agile process

model would be adopted, it is a combination of iterative and incremental process models with

focus on process adaptability, easy measure and monitor of progress of work and customer

satisfaction by rapid delivery of working software products. Before the desired system is released

a working system is built, and many successive iterations are implemented and delivered to the

clients. Requirements of Software are first separated into time boxes (small time frames) to

deliver specific features for a release.

The activities to be used for this model are:

1) Planning

2) Requirements gathering and analysis

 3) System Design

4) Implementation

5) Testing.

The agile process model will prove to be very useful for the following reasons:

1) High success rate

2) This model is progressively flexible and adaptive

3) Risk of requirement change are reduced and less costly

4) In this model little or no planning is required

5) Easy to manage and monitor progress

6) Functionality can be developed rapidly and demonstrated

7) Delivers early partial working solutions.

3.5 DESIGN AND DEVELOPMENT TOOLS

Electronic workflow for official document will be developed as a web application based

platform. To ensure the software is well designed and developed, the following tools and

applications will be employed:

React JS: React JS a front-end Javascript framework/library would be used for building the user

interface of the application.

PHP 7.3: PHP which stands for hypertext preprocessor would be used to connect the webpage to

the database.
Cascading Style Sheet (CSS): Cascading Style Sheet also known as CSS is a scripting language

that is employed in front-end web application development to add beauty and style to a bland

web page.

Browser: Browser would be used to check the user interface of the webpage and its

responsiveness

Webserver: Apache HTTP (Hypertext transfer protocol) server will be used to accept requests

from clients for this system.

Database: MySQL which stands for structured query language would be used as the database for

the system. It is used for data warehousing and e-commerce applications.

3.6. REQUIREMENTS SPECIFICATION AND ANALYSIS

The requirement analysis phase is an integral part in the development of the application. This

stage analyses the various functionalities that are used to achieve the project goals and

objectives.

3.6.1. User Requirements

The user requirements for the document management software are outlined below:
1) Users shall signup/login to the system before workflow starts

2) Users shall create the type of document they want approved

3) Users shall have the option of either using a template, creating a document from scratch

or to upload their own document

4) Users shall be able to submit the document to one or more participants for approval

5) Users shall be able to submit more than one document for approval

6) Users shall be able to review documents during the workflow

 7) Users shall be able to track the activity once the workflow starts i.e. users would know

when the document as reached a participant

8) Users shall be able to edit, reject and approve submissions

9) Users and participants shall be able to reject documents for edit and correction during the

workflow

10) Users shall be able to set deadlines on any official document or project

11) Users shall receive automatic alert and notifications about the status of the workflow

12) Users shall be able to see a record of when document where initiated, edited/corrected or

reviewed, approved and submitted

13) Users shall have an email templates for notifications

14) Users participating in a workflow shall receive notifications when a workflow starts

15) Users shall set a time limit each participants have for approval in a workflow

16) Users participating in a workflow shall be able to monitor the status of the workflow.

3.6.2 System Requirement

The system requirements of the application are split into functional and non-functional. Both the

functional and non-functional requirements are outlined below.

Functional Requirements

Functional requirements are identified through the analysis of the data collected from the survey.

Functional requirements are the functionality and features that the system must have or be able to

satisfy the project objectives.

1) The steps taken for approval would be clear, defined and repeatable steps i.e. users

should be able to follow the steps easily and repeat an infinite number of times
 2) The system would allow users to able to edit, reject and approve submissions

3) The system would allow users and participants to reject documents for edit and correction

during the workflow

4) The system would be able to identify who has the authority in a workflow

5) The system would be able to save the record of when documents are been corrected,

initiated, approved and submitted

6) The system would be able to send alerts and notifications to each participants in a

workflow

7) The system would have an edit feature in order for an edit during the workflow

8) The system would allow participants to chat with one another during the workflow.

Non-Functional Requirements

Non-Functional requirements are identified through the analysis of the data collected from the

survey. Non-functional requirements define the manner or characteristic the system must have

such as: security, performance, scalability, usability, maintainability, reliability, configurability,

and availability and design constraints. It may also outline specifications that are outside the

scope of this study, differentiating functionalities that may wrongly be perceived within scope of

work.

1) The system must be reliable

2) The system must be efficient, with easy access and fast response

3) The system must be secure

4) The system must be transparent and consistent

5) The system must be interactive

6) The functions of the system must be easily accessed by users

 7) The system should be compatible with different platforms.

3.7 PROCESS FLOWCHART

Flowchart is a diagrammatical expression that shows the process of a particular system (Chen,

Shi, Feng, Zhao, & Luo, 2015). Figure 3.1 show the flowchart diagram for the system.

Figure 3.1 Process flowchart of the system

3.8. USE CASE DIAGRAM

A use case diagram is a representation of a set of actions (use cases) that the system can perform

in participation with an external factor (user/interacting systems). The use case diagram helps

map crucial actors in the application to their parallel functions. Figure show the use case

diagrams for the system.

Preconditions

1) There is an active network connection to the Database.

2) Sensitive information is accessed by only registered users.

Use Case Diagrams

The use case diagram are pictorial representation of the possible activities that can be performed

on this system. The figure below show activities and how the users interact with the developed

system:
uc Actors

Electronic Workflow for Official Document

Notification:
Participating in a
Initiate Workflow
w orkflow

Notification:
Submit documents
Documents Aw aiting
for approv al
Approv al

Receiv e
Notications of
Rej ects
Rej ected Actor 1
Documents
Initiator Documents

Rev iew
Documents Approv es
Documents
Receiv e
Notifications of
Approv ed
Documents
Notification:
Participating in a
w orkflow

Notification:
Documents Aw aiting
Approv al
Actor 2

Approv es
Documents

Figure 3.2 Use case Diagram of a workflow management system

3.9 SYSTEM DESIGN

The design of this system is going to be carried out using the requirements analyzed previously

in order to produce a description of the systems internal structure that will serve as the basis to

implement the system (Bass et al 2013). This will result in the systems architecture, showing

how the system will be decomposed and organized into components alongside the interface of

those components. The model design of this system, will form a blue print for the

implementation that will be put together to achieve the project objectives and best performance

for the final product. This system design consists of activities that fit between software

requirements analysis and software construction.

The various outputs for this design are functional specification, detailed design, user interface

specification, data model, prototype implementation plan.

3.9.1 Architectural Design

The system is a web-based application to be hosted on a web server that communicates to a

database server. The user on a web interface makes a web request which is received by the

webserver. The web server processes the request and interacts with the database server using

SQL embedded in PHP scripts. The response is a web page data sent on the web interface for

the user.

Figure 3.3: The Architectural Design for the workflow management system
3.9.2 Context Model

This model of the system is used to show an abstraction of the system with an external

perspective of the system and its environment. These boundaries could be defined to satisfy both

technical and non-technical factors like social and organizational concerns. After the boundaries

have being ascertained, the analysis carried out would seek to determine the definition of that

context modeled and the dependencies that the system has on its environment.

3.9.3 Data Flow Model: This is a representation of the system of this project, by way of

diagrams to show the exchange of information within the system. It is a diagram that gives an

overview of the system described here without going into much detail, which can be later

elaborated. (Wikipedia 2018).

Figure 3.4 Context flow diagram

 Figure 3.5 Logical flow diagram

3.9.4 Structural Model: A structural model will display the system of this project in terms of

components and their relationships. For example, the system of this project is modelled by

architectural design to illustrate the systems responds to events based on the system

environment and the interaction between other components both externally and internally.

(Sommerville 2011, p.119).

Figure 3.6: The Structural diagram for the workflow management system
3.9.5 Entity Relations (Database)

This section describes the objects and their relations that constitute the components and functionalities of

this system. These objects can be perceived as entities, which could be used to model a class relationship

between objects in an Object-Oriented Environment (i.e. OOP) or used to model a database. The entity

relation adopted is used to model a database schema. The database developed for this system is named

STACK. Not all dimensions are directly connected to the fact table (Gavin 2006).

Figure 3.7: Entity Relationship Diagram

The Roles ID table stores the value of path that is drawn from the first user and it contains the

role name and number and it is stores the sequence of users in which the process moves to.

The TaskID table stores the task id name and the name of the initiator and all data’s are saved as

XML
Show tasks stores the values that shows the user, status of the workflow and if the user can

access it or not.

The User ID contains users that have access to any specific workflow process.

3.9.6 Class Diagram

A class diagram is used to show the relationships between the entities involved in the system

together with their attributes and indicate the number of occurrences an entity can exist for a

single occurrence of a related entity (Ele, et al, 2017). The class diagram of the system is shown

below.

Figure 3.8 The Class Diagram of workflow the management system