Electronic form srs

Addis Ababa Institute of Technology
Center of Information Technology and
Scientific Computing
Department of IT/SW Eng.
Electronic Form
Software Requirements Specification
PREPARED BY:
Bereket G/Dingle ATR/2460/07
Nathenael Tarekegn ATR/7617/07
Kaleb Wondwossen ATR/3931/07
Bereket Abera ATR/4250/07
ADVISORS:
Nathnael Argaw
Date: Dec 19, 2018

Electronic Form 2018
CENTER OF INFORMATION TECHNOLOGY AND SCIENTIFIC COMPUTING Page 1
Revision History
Date Description Author Comments
Document Approval
The following Software Requirements Specification has been accepted and approved by the
following:
Signature Printed Name Title Date

Table of Content
Document Approval
List of Tables
List of figures
Definitions, Acronyms, and Abbreviations
DECLARATION
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Overview
2. General Description
2.1 Product Perspective
2.2 Product Functions
2.3 User Characteristics
2.4 General Constraints
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.2 Hardware Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2 Functional Requirements
3.2.1 Functional Requirement #1 Enable Creation of Multiple Level of Authorization
3.2.2 Functional Requirement #2 Enable Creation of Organizational Catalog
3.2.3 Functional Requirement #3 Assign Each Authorized User a Unique Digital
Signature
3.2.4 Functional Requirement #4 Enable Super User to Create a Form
3.2.5 Functional Requirement #5 Enable Form Initiation
3.2.6 Functional Requirement #6 Track and Locate Forms
3.3 Use Cases
3.3.1 Actors
3.3.2 Defined Use Cases
3.3.3 Use Case Diagram
3.3.4 Use Case Definitions
3.4 Non-Functional Requirements

3.4.1 Performance
3.4.2 Reliability
3.4.3 Availability
3.4.4 Security
3.4.5 Maintainability
3.4.6 Portability
3.4.7 Responsiveness
3.5 Inverse Requirements
3.6 Design Constraints
3.7 Logical Database Requirements
3.8 Other Requirements
4. Change Management Process
References
A. Appendices
A.1 Appendix 1
A.2 Appendix 2

List of Tables

List of figures
Use case Diagram

Definitions, Acronyms, and Abbreviations
API :- Application Program Interface
Circulation :- movement of a form from an office to an office for signature

DECLARATION
We declare that this written submission represents our ideas in our own words and
where others’ ideas or words have been included. We have adequately cited and
referenced the original sources. We also declare that we have adhered to all principles
of academic honesty and integrity and have not misrepresented or fabricated or falsified
any idea/data/fact/source in our submission. We understand that any violation of the
above will be cause for disciplinary action by the Institute and can also evoke penal
action from the sources which have thus not been properly cited or from whom proper
permission has not been taken when needed.
Date: 19-12-2018

1. Introduction
1.1 Purpose
The purpose of this document is to give a detailed description of all the functionalities,
requirements and specifications of the E-form system. It will illustrate the purpose,
interface, user characteristics, product feature and perspective, system constraints and
interaction with other applications. This SRS is designed and written for stakeholders
such as developers involved in this project and anybody that wants to understand the
project. This document will also provide a basis for validation and verification.
1.2 Scope
The E-form system automates the form and document based office to office process and
document signing. It will increase productivity and support multiple work completion
with in little time provided in most secure way.
Since the E-form system is solely for forms and documents which transits between offices
for signature and validation, forms type of like the below are out of scope :-
● Forms and documents which resides in a single office bureau
● Forms used for finical use ( digital signature are not allowed for finical transactions
in our country )
● Documents or forms to or from another company
1.3 Overview
This document has four sections.
1. Introduction: - This section states the high-level overview of this paper, the
purpose of the SRS and scope of the system.
2. General Description: - This section describes factors that can affect the product
as well as it requirements but will not state any specific requirements. It is useful
to establish a context for the technical requirements specification in the next
chapter.
3. Specific Requirements: - This part of this document describes technical details of
the functionality of the product in detailed manner so as to enable designers to
design a system to satisfy those requirements and testers to test the system.
4. Change management process: - This part explains the process that will be used
to update the SRS, as needed when project scope or requirements change.

2. General Description
2.1 Product Perspective
E-form is standalone system but will have interaction with other system in a specific
company. Such as HR, Library, Registrar … and other resources related system. The
system will be generic and pluggable to any kind of environment or company.
The team has carefully searched if there are any other existing solutions for the problem
we are trying to address. We found an online application called Docu-Sign and also
Adobe products also give the feature of document signing. This application perfect
solution in addressing the document signing but they are specific to their domain. Also
they are not suitable for multiple signing. Moreover our domain which the E-form system
solves is more wider and near to the problem which we are facing in our country
companies.
2.2 Product Functions
The system has three main modules
1. Forms and Documents
- The system enables to create forms and assign responsible users to fill and sign
on the form.
-The system enables to track forms.
2. Security
-The system should enable users to digitally sign.
-The system should ensure protection from identity theft and data breaches of
classified documents and forms.
-The system should enable users to check if a form or a document is digitally
signed and who has signed.
3. Transit of forms
-Forms should be able to transit between offices.
2.3 User Characteristics
There are three type of users; super admin, office authorized users, students/end Users.
The admin user can create new forms. Authorized office users will have digital signature

on the system and can sign over the forms and documents. Finally students will be able to
initiate any kind of form in the system. Office users can also initiate a form.
2.4 General Constraints
One of the constraints is intranet connection specifically when forms are forwarded and
moved between offices.
Another constraint due to companies regulatory policies is that digital signature are not
allowed for financial transactions.
2.5 Assumptions and Dependencies
For this proposed system, we assume that
● There will be an API provided for all other system which the E-form system will
have interaction.
● Users to have basic knowledge on how to interact with computer in order to use
the system properly.
3. Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
The system is going to have a web and mobile interface. Form creation and related tasks
are going to be performed on the web platform. The mobile platform on the other hand
will manage on the go activities like tracking a form, signing a form and the like. This
activity can also be performed from the web platform. Teachers, students and admins will
be using this platform.

3.1.2 Hardware Interfaces
The system is going to have a mobile application and a web portal in either of those cases,
there will not be any specific hardware interface requirement. So the system, in its
current scope, doesn’t have any hardware requirements.
3.1.3 Software Interfaces
Database Server:-
Web Server:-
Operating System:- We will be using open source Linux system.
3.1.4 Communications Interfaces
To interconnect all the components, we use TCP/IP based network authentication in
order to avoid an unauthorized user access.
3.2 Functional Requirements
➔ The system shall have different levels of authorization, eg. super admin, admin,
staff, student, anonymous.
➔ The system shall have a catalog describing the main offices and the structure of the
organization.
➔ The system shall have a robust security module for securing a form on transit.
➔ The system shall have a robust security module for storing a form on the back end
server.

➔ The system shall have an integrity evaluation mechanism for checking the owner
of a signature.
➔ The system shall enable users to have their own digital signature.
➔ The system shall enable the super user to create a generic form.
➔ The system shall enable the super user to add different nodes to a form where the
nodes are inline with the system catalog.
➔ The system shall enable form initiation from different users depending on the
form initiated.
➔ The system shall track active forms and locate where they currently are.
3.2.1 Functional Requirement #1 Enable Creation of Multiple Level of
Authorization
➔ The system shall have an interface to create different level of authorization
➔ The system shall receive a username, a password and an authorization level.
➔ An Authorization level, although it depends on the organization, is one of the
following: Super Admin, Admin, Staff, Student or Anonymous. For the Anonymous
case there shall not be any user creation but it must be assigned a unique
temporary identification number.
➔ Finally a user with a specific level of authorization will be created which will
function throughout the system with the indicated level of clearance.
3.2.2 Functional Requirement #2 Enable Creation of Organizational Catalog
➔ At the start of application initiation, the system shall be able to create an
organizational catalog.
➔ The system shall receive office structures and organizational level authorization
frames together with other structures that the company may have.
➔ The organizational catalog is created from the above infrastructure information.
This catalog is used to determine higher level application processes and also it
provides the base for the back end form creation.
3.2.3 Functional Requirement #3 Assign Each Authorized User a Unique Digital
Signature
➔ Each user required to sign on some kind of form shall have a unique digital
signature.

➔ The system shall generate a unique digital signature up on user creation in
accordance with the system catalog information.
➔ The system shall check weather a certain user is required to have a digital
signature from the organizational structure found inside the system catalog and
assign it one automatically.
3.2.4 Functional Requirement #4 Enable User to Create a Form
➔ Inside the system, different forms are created to perform a variety of tasks. And
this forms are created by the super user.
➔ The system shall accept form layout (this includes detailed information about the
form) and create the form depending on those information.
➔ Automatically, the system shall figure the office paths that the form should pass
through from the system catalog and relate it to the form.
3.2.5 Functional Requirement #5 Enable Form Initiation
➔ Forms might be initiated from any of the users defined in the system catalog. Also
these depends upon the type of the form and the user role.
➔ The system should enable users to initiate a form either from the web platform or
the mobile platform.
➔ In accordance with the system catalog a certain user may or may not have the
ability to initiate a certain form.
3.2.6 Functional Requirement #6 Track and Locate Forms
➔ Forms are transferred from one office(node) to another to be signed or verified
➔ At any point in time, the system shall identify where a form had last been signed,
which offices has signed the form and which hasn’t.
➔ Notifications will be sent to the office upon the form’s arrival.
➔ The location of each form will be available for all stakeholders of the form

3.3 Use Cases
3.3.1. Actors
The main actors in this system are those who directly influence the workflow of the
system. These are:
 Super Admin – a person with the highest access level in the system. This user
registers the offices and their respective staffs in to the system and assigns
them with access levels and roles.
 Office Admins – These actors have authorization levels in their offices to
create and sign documents.
 End Users – These are people that initiate the form circulation for signing, like
applicants or students.
 The System – This is the system itself. Since the project involves automation
and security modules, the system will be considered as an actor that directly
interact with the workflow.
3.3.2. Defined Use Cases
The following use cases are goal-oriented according to what the project aims to
accomplish in the target area. As one functional requirement can be captured through
many use cases, the above requirements are divided and simplified as these use cases.
1. Register Users
2. Create Form
3. Send Form
4. Sign Form
5. Track Form
6. Check Form Authenticity
7. Send Notification
8. Assign Role
9. Change Signing order
10. Generate Signature
11. Discard Form

3.3.3. Use Case Diagram
Super
Admin
Office
Admin
System
Register Users
Assign Role
Create Form
Change Signing Order
Generate
Signature
Send Notification
Track Form
Check Form
Authenticity
Use case Diagram
Electronic Form
Electronic Form | Use case Diagram
Sign Form
Discard Form
End
User
Send Form
<<extends>>
<<extends>>

3.3.4 Use Case Description
Use Case 01: Register Users
Use case name: Register users
Goal: Add users into the system
Primary Actors: Super Admin
Pre-condition: The actor has to have a super admin level of authorization.
Main success scenario:
1. Admin logs in as a super admin.
2. The system displays the super admin panel.
3. Admin clicks on the “Add User” Button.
4. The system displays the panel for registering users.
5. Admin types the name and Id of the person that is to be registered.
6. Admin, then, selects a level of authorization for the person from a drop down list
and clicks “Assign”.
7. System accepts and displays a confirmation message of registration.
Failure Scenario at 5:
5a. There is no user with the provided identification.
1. System displays Error message.
2. User types a correct Id of the person.
3. System resumes at step 6.
Use Case 02: Assign Role
Use case Name: Assign role
Goal: Assign or change a person under an office with a certain role.
Primary Actor: Super Admin
Pre-condition: User has to be Super admin.
Description: Head of an office is replaced by another person, thus that role has to be
assigned to this new head of office.
1. User logs in as Super admin.
2. User clicks the “Assign Users” button.
3. The system displays a panel.
4. User types in the Id of the person to be assigned.
5. User, then, selects the office which the person will be assigned under.
6. User selects the Role which the person plays in that office administration.
7. System display confirmation message of the update.
Failure Scenario at 5:
2a. There is no user with the provided identification.
1. System displays Error message.
2. User types a correct Id of the person.
3. System resumes at step 6.

Use Case 03: Create Form
Use case name: Create Form
Goal: Design a form that will be used by end users.
Primary Actor: Office Administrator
Pre-condition: User has to have an access level or role of office admin.
1. User logs in as Office Admin.
2. System log user in and displays admin panel.
3. Admin clicks the “Create Form” button.
4. System displays templates and tools that will be used to design the form.
5. Admin designs the form and clicks “Next”.
6. System displays offices for assigning signature order.
7. Admin determines the signing order and clicks “Save Form”.
8. System creates a digital ID for the form and saves the form.
Use Case 04: Change Signing Order
Use case name: Change signing order
Goal: Change the signing order of a form during circulation
Primary Actor: Office Administrator
Pre-condition: User has to have an access level or role of office admin. Form must
have already been created.
1. User logs in as office admin.
2. System logs the user in and displays the admin panel.
3. Admin clicks on the “Forms” button.
4. System displays created forms.
5. Admin selects a form for editing.
6. Admin, then, changes the signing order of the form and clicks “Save Changes”.
7. System displays confirmation message.
Use Case 05: Discard Form
Use case name: Discard form
Goal: Make a form unavailable for usage
Primary Actors: Super admin and Office Admin
Pre-condition: User has to be a super admin or office admin
1. User logs in as super admin or office admin.
2. System logs the user in and displays admin panel.
3. Admin clicks the “Forms” button.
4. System displays created forms.
5. Admin selects a form and clicks “Delete”.

6. System deletes the form completely and show a confirmation message.
Variation at step 5:
5a. Admin chooses to make the form temporarily unavailable
(Some forms are only used during a certain period of time)
5a.1. Admin clicks the “Disable Form” button
5a.2. System makes the form unavailable and displays confirmation message.
Use Case 06: Sign Form
Use case name: Sign Form
Goal: Sign a form
Primary Actors: Office Administrators
Pre-condition: User has to be an office admin and the form is created to be signed by
that office administrator.
1. User logs in as super admin or office admin.
2. System logs the user in and displays admin panel.
3. User clicks the notification icon.
4. System displays new notification.
5. User clicks a form to be signed.
6. System displays the form.
7. User reads the form content and clicks the “Sign” button.
8. System embeds the digital signature of the user and displays a confirmation
message.
Variation at step 7:
7a. User chooses to reject the form.
7a.1. User clicks the “Reject” button.
7a.2. System accepts and sends notification to the form initiator.
Use Case 07: Send Form
Use case name: send form
Goal: Get a digital copy of a form and request signature
Primary Actors: End users and Office administrator
Pre-condition: The required form must be available.
1. User logs in to the system and clicks the “Forms” button.
2. System displays list of forms.
3. User selects a form and clicks “Get Copy”.
4. System instantiates a copy of a form and displays it.
5. Users fill in necessary information on the form and hits “Send”.
6. System sends the form and request signature from assigned offices
Failure scenario at 3:
3a. The form has been made temporarily unavailable.
3a.1. System displays error message.
3a.1. User goes onto other tasks.

3.4 Non-Functional Requirements
3.4.1 Performance
95% of the system’s response to form creation and related things will be less than 2 sec,
but to fully process the transaction of the document and to address all stuffs it will take
up to 9 sec with reliable connection.
3.4.2 Reliability
Data and documents should not be corrupted or destroyed in the case of connection
failure and system crash.
3.4.3 Availability
The system will work 24/7 as much as internet connection is available and server is not
down
3.4.4 Security
Data should be secure against malicious deformations. The security includes
authentication, authorization, data encryption and data privacy. Authentication of users
is done using their id and digital signature.
3.4.5 Maintainability
The system should be having high maintainability in terms of correctness, adding new
functionalities and should be highly adaptive.
3.4.6 Portability
The system is portable since its platform is web based and mobile it works on any device
that support android and any device that supports web browser.
3.4.7 Responsiveness
The Web system is responsive to different kind of devices (Computer, Tablet, and Mobile
Devices) to make it portable.
The Mobile App is suitable for Android platform of all versions for as to make it
operational across different android versions (lower versions).

3.5 Inverse Requirements
The system has to fulfill all functional and non-functional requirements that are
explicitly articulated above. But there are some actions that the system will not deal with.
Some of these are:
❖ The system will not allow user to create forms
❖ In some scenarios the system will not allow users to initiate the process( eg.
clearance )
3.6 Design Constraints
The major design constraint is changing the policy change (i.e. the working bureaucracy
of government offices and interfacing with external systems.
3.7 Logical Database Requirements
Logical database required for the system to store different nodes, storing users’ metadata
that uses us for the transaction.
3.8 Other Requirements
Catchall section for any additional requirements:
Training-related Requirements
The following users will be trained.
● Staff :
will be trained how to utilize the system for sending and tracking forms,
requesting different services online.
● Admin:
there will be a training for super admin how to create forms, assign user
and how to manage all transactions. He/she will have a deep training
session because they have to know all available potential of the system to
utilize and benefit from the system.
The Admin can be Naive person or programmer which has never used the system before.
So in any case they both need to be informed and have a detail knowledge about the
system in depth. Because the Admin can do functions beyond other users, Detail
knowledge for Admin is must.

Packaging Requirements
The system functions online. This is not a desktop application (.exe). So we are going to
put it in a folder and deploy on the local server with IP Address. But for mobile
application its (.apk) and the user can install it on a smartphone.
Legal Requirements
Copyright laws and license agreements are claimed under the ownership of AAIT-ITSC.
4. Change Management Process
Since we are using a iterative waterfall model, we will add new detailed information
and more specifications for further requirements that we find in the next versions of this
product iteratively.

References
Previous year SRS documents
 Web Based health consulting and Disease diagnosing assistance system
 Traffic Surveillance system
 Crag System use case guide http://www.cragsystems.co.uk/use_case_tutorial/

A. Appendices
A.1 Appendix 1
As described, the system mainly focuses the security and tracking of form while in transit.
Thus, most what the system does under the hood is not discussed in the requirement and
use case section of the SRS.
A.2 Appendix 2
Some signature require data that has to be provided by the organization which is out of the scope
of the project. Thus, it has to be kept in mind that the project will have a middleware module that
manages request and interaction with the outside environment.

Electronic form srs

More Related Content

What's hot

Similar to Electronic form srs

Recently uploaded

Electronic form srs