SCSJ

2253 Requirements Engineering & Software

Modelling

Assignment 3:
Software Requirements Specification

Plantation Management System

Version 1.0

15th May, 2016

Faculty of Computing

Prepared by:

Team 3 (404 Group Not Found)

SRS-Template-v1.1-ForSCSJ2203-SE@UTM-BySS-20March2016
Revision Page
1. Overview
In this Software Requirements Specification document version 1.0, it is written primarily
for the stakeholders of the Palm Plantation Management System and describes in technical
terms the details of the functionality of the product which is Palm Plantation Management
System. This document contains several information of the system; Overall description and
specific requirements.
In overall description, it gives an overview of the overall perspective and requirements of
the system. It describes the informal requirements and is used to establish a context for the
technical requirements specification. While in specific requirements section, it will show and
describe the details of the requirements that a stakeholder needs to know, which comprise
the domain model.

2. Target Audience
1. Palm Plantation Company

2. Dr. Noraini Ibrahim

3. Stakeholders involved

3. Project Team Members

No. Members Module

1. Pang Cheng Hao Delivery Order

2. Fatin Nabillah binit Sihan Invoice and User Management

3. Obad Mohamed Taha Hamad Sales Memo

4. Nur Aqilah Puteri binti Mohamed Husin Weighting Ticket

ii

SRS-Template-v1.1-ForSCSJ2203-SE@UTM-BySS-20March2016
4. Version Control History
Version Primary Author(s) Description of Date
Version Completed

1.0 Pang Cheng Hao Software 15th May, 2016

Requirements
Fatin Nabillah binit Sihan
Specification
Obad Mohamed Taha Hamad

Nur Aqilah Puteri binti Mohamed Husin

Note:
This Software Requirements Specification (SRS) template is based on IEEE Std 830-1998, organized by modules
according to system features (Appendix A.5 of the IEEE Std, 830-1998, Section 5) and customized to meet the
need of SCSJ2203 course at Faculty of Computing, UTM. Compiled and checked by Shahida Sulaiman, PhD on
20 March 2016. Examples of models are from Satzinger (2011).

iii

SRS-Template-v1.1-ForSCSJ2203-SE@UTM-BySS-20March2016
Table of Contents
Revision Page ......................................................................................................................................... ii
1. Overview .................................................................................................................................... ii
2. Target Audience ......................................................................................................................... ii
3. Project Team Members ............................................................................................................. ii
4. Version Control History ............................................................................................................ iii
1. Introduction .................................................................................................................................... 1
1.1 Purpose .................................................................................................................................. 1
1.2 Scope ...................................................................................................................................... 1
1.3 Definitions, Acronyms and Abbreviation .............................................................................. 3
1.4 References .............................................................................................................................. 4
1.5 Overview ................................................................................................................................ 4
2. Overall Description ......................................................................................................................... 5
2.1 Product Perspective ............................................................................................................... 7
2.1.1 System Interfaces ........................................................................................................... 8
2.1.2 User Interfaces ............................................................................................................... 8
2.1.3 Hardware Interfaces ...................................................................................................... 8
2.1.4 Software Interfaces ........................................................................................................ 8
2.1.5 Communication Interfaces ............................................................................................ 9
2.1.6 Memory .......................................................................................................................... 9
2.1.7 Operations ..................................................................................................................... 9
2.1.8 Site Adaptation Requirements ...................................................................................... 9
2.2 Product Functions ................................................................................................................ 10
2.3 User Characteristics ............................................................................................................. 11
2.4 Constraints ........................................................................................................................... 11
2.5 Assumption and Dependencies ........................................................................................... 11
2.6 Apportioning of Requirements ............................................................................................ 12
3. Specific Requirements .................................................................................................................. 13
3.1 External Interface Requirements ........................................................................................ 13
3.1.1 User Interfaces ............................................................................................................. 13
3.1.2 Hardware Interfaces .................................................................................................... 18
3.1.3 Software Interfaces ...................................................................................................... 18
3.1.4 Communication Interfaces .......................................................................................... 18
iv

 3.2 System Features ................................................................................................................... 19
3.2.1 Module of Delivery Order ............................................................................................ 19
3.2.2 Module of Invoice ........................................................................................................ 32
3.2.3 Module of Sales Memo ................................................................................................ 41
3.2.4 Module of Weighting Ticket ........................................................................................ 50
3.2.5 Module of User Management ..................................................................................... 59
3.3 Performance Requirements ................................................................................................ 65
3.3.1 Response time .............................................................................................................. 65
3.3.2 System dependability .................................................................................................. 65
3.3.3 Safety ........................................................................................................................... 65
3.3.4 Speed ............................................................................................................................ 65
3.3.5 Throughput .................................................................................................................. 65
3.3.6 Utilization ..................................................................................................................... 65
3.4 Design Constraints ............................................................................................................... 67
3.4.1 Hard drive space .......................................................................................................... 67
3.5 Software System Attributes ................................................................................................ 67
3.5.1 Reliability ..................................................................................................................... 67
3.5.2 Availability ................................................................................................................... 67
3.5.3 Security ......................................................................................................................... 67
3.5.4 Extensibility .................................................................................................................. 68
3.5.5 Portability ..................................................................................................................... 68
3.5.6 Usability ....................................................................................................................... 68
3.6 Other Requirements ............................................................................................................ 69
3.6.1 Portability ..................................................................................................................... 69
3.6.2 Inter-operability ........................................................................................................... 69
3.6.3 Operability ................................................................................................................... 69
3.6.4 Reusability .................................................................................................................... 69

Table of Figures
Figure 1: Use case diagram of Plantation Management System ............................................................ 6
Figure 2: Use case diagram of Plantation Management System ............................................................ 7
Figure 3: Domain model of Plantation Management System .............................................................. 13
Figure 4: Login page ............................................................................................................................. 14
Figure 5: Response to the exception of error log in ............................................................................. 14
Figure 6: Sale memo menu interface ................................................................................................... 15
Figure 7: Sales memo menu options .................................................................................................... 15
Figure 8: Create sale memo .................................................................................................................. 16
Figure 9: Sort sale memo ...................................................................................................................... 16
Figure 10: List of sales memo that have been sorted by date (latest to oldest) .................................. 17
Figure 11: Update sale memo .............................................................................................................. 17
Figure 12: DO module .......................................................................................................................... 19
Figure 13: System sequence diagram for issue delivery order ............................................................. 22
Figure 14: Activity diagram for issue delivery order ............................................................................. 23
Figure 15: System sequence diagram for view transportation details ................................................. 26
Figure 16: Activity diagram for view transportation details ................................................................. 27
Figure 17: System sequence diagram for manage DO ......................................................................... 30
Figure 18: Activity diagram for manage DO ......................................................................................... 31
Figure 19: Invoice module .................................................................................................................... 32
Figure 20: System sequence diagram for issue invoice ........................................................................ 35
Figure 21: Activity diagram for issue invoice ........................................................................................ 36
Figure 22: System sequence diagram for manage invoice ................................................................... 39
Figure 23: Activity diagram for manage invoice ................................................................................... 40
Figure 24: Sales memo module ............................................................................................................ 41
Figure 25: System sequence diagram for create sales memo .............................................................. 44
Figure 26: Activity diagram for create sales memo .............................................................................. 45
Figure 27: System sequence diagram for view sales memo ................................................................. 48
Figure 28: Activity diagram for view sales memo ................................................................................. 49
Figure 29: System sequence diagram for create weighting ticket ....................................................... 53
Figure 30: Activity diagram for create weighting ticket ....................................................................... 54
Figure 31: System sequence diagram for view weighting ticket .......................................................... 57
Figure 32: Activity diagram for view weighting ticket .......................................................................... 58
Figure 33: System sequence diagram for manage user ....................................................................... 63
Figure 34: Activity diagram for manage user ....................................................................................... 64

vi

Table of Tables
Table 1: Use case description for UC-001 ............................................................................................. 21
Table 2: Use case description for UC-002 ............................................................................................. 25
Table 3: Use case description for UC-009 ............................................................................................. 29
Table 4: Use case description for UC-005 ............................................................................................. 34
Table 5: Use case description for UC-010 ............................................................................................. 38
Table 6: Use case description for UC-003 ............................................................................................. 43
Table 7: Use case description for UC-004 ............................................................................................. 47
Table 8: Use case description for UC-006 ............................................................................................. 52
Table 9: Use case description for UC-007 ............................................................................................ 57
Table 10: Use case description for UC-008 ........................................................................................... 62

vii

1. Introduction
1.1 Purpose

The purpose of this document is to present a detailed description of the Palm Plantation
Management System. It will explain the purpose and features of the system, the interfaces
of the system, what the system will do, the constraints under which it must operate and
how the system will react to external stimuli. This document is intended for both the
stakeholders and the developers of the system.

1.2 Scope

The software product is an automated and integrated system which allows everyone who
is related in crop selling process to use it such as marketing department and plantation OC.
Other than that, the system can also generate quick variety of documents with specific
templates such as report, invoice and sales memo and then save it in database for future
reference. Next, the system provides backup and recovery facilities that will protect all data
and records from loss.

Hence, by using this system, the management level of the company can easily keep track
of the products flow and record number of data needed such as weightage, distance travel
and ticket. Generating documents according to templates ensure the consistency for the
format of documents, doing it online means people who have access to the system can
access the documents instantaneously as soon as it is uploaded. This is because of the
versatility of databases that powering all sorts of projects management including quick
information dissemination and sharing system.

The system shall beneficial many parties especially the organization itself in a number of
ways, as follow:

Ensure maximum profitability to both the farmers and to the factory because
correct data and information is collected from the sheds automatically.
Improvement on the efficiency of the office clerks during the weighing exercise by
use of digital scales and grading process by the grader.
Strategic managing system to the person in charge information shall be generated
by the software that is relevant and integrated with the rest of data to the needs of
the organization.
Shorten the time taken for report to be generated and validated- because of the
versatility of databases that powering all sorts of projects management including
quick information dissemination.
Optimize operating costs- by providing an effective way to manage the crop selling
process.
Track and record number of data needed as reference- such as weightage, number
of fruits, distance travel, time travel, price during ticketing and etc.
Sharing of data and multiuser system- the system allows data sharing among others
who have access to the system and many users to access the same database at the
same time.
Backup and recovery facilities- provide system that will protect all data and records
from loss.
Generate quick sales memo, invoice and ledger.

1.3 Definitions, Acronyms and Abbreviation

Acronym Definition
SRS Software Requirement System

PP Pusat Pengumpulan. PP is a space in some estate. Small

estate will send their fruits to PP in a bigger estate.
PTS Pusat Timbang Setempat

DO Delivery Order. It contains record of fruits weightage,

distance travelled, departure time and arrival time.
OC Office Clerk

PIC Person In Charge

Depo Store/Warehouse

Project Refers to state that belong to the company

Marketing A department in the company that manage the process of

purchasing and selling of fruits.
Grade Level of fruits based on size and colour. If the grade is too
poor (too low to be accepted), the fruits may be rejected or
accepted at low price by PTS.
Weighing ticket A ticket generated by an external hardware.

Stakeholder Any person who is directly or indirectly involve and have

interest in this project.

1.4 References

Noraini (2016). User Requirements Definition Document Template. Retrieved date, 9th April
2016 from http://elearning.utm.my/15162

Hakim L. (2016). Bengkel Elisitasi Keperluan Bersama Pemegang Teguh 2016. Retrieved date,
22nd March 2016 from http://elearning.utm.my/15162

Devterch(2013). Plantation Management System. Retrieved date, 10th April 2016 from
http://devterch.com/products/plantation-management-system/

Shahliza & Shahida (2016). SRS-Template-v1.1-ForSCSJ2203-SEUTM-BySS-20March2016.
Retrieved date, 5th May 2016 from http://elearning.utm.my/15162

1.5 Overview

The next chapter, the Overall Description section, of this document gives an
overview of the functionality of the product. It describes the informal requirements and is
used to establish a context for the technical requirements specification in the next chapter.
The third chapter, Requirements Specification section, this document is written
primarily for both the stakeholders involved and developers. It describes in technical terms
the details of the functionality of the product.
Both sections of the document describe the same system--Palm Plantation
Management System-- in its entirety, but are intended for different audiences and thus use
different language.

2. Overall Description
This section will show the interactions of the system with other context and its basic
functionality. Besides, this section will show the constraints and assumptions. The Plantation
Management System is system that is specially designed for Plantation Company to improve
efficiency of their crop selling process as well as optimize the operating costs. The system shall
allow plantation staff to store several of documents such as DO, weighing ticket, invoice and
etc. in the system database instead of storing it manually. Besides, the system shall allow
plantation staff to keep track on the selling process of the harvest from the plantation to the
factory.

The Plantation Office Clerk and Marketing Office Clerk shall be able to manage delivery
orders, issues delivery orders, view transportation details, creates sales memos and view sales
memos. Whereas, the PTS Office Clerk shall be able to manage invoices, create invoices, create
weighing tickets and view weighing tickets. The Factory Office Clerk shall be able to create
weighing tickets and view weighing tickets, for, the system administrator, he or she shall be
able to manage the system users.

Figure 1: Use case diagram of Plantation Management System

2.1 Product Perspective

This Plantation Management System requires external system GPS which feeds the input into
the system for certain functions. Besides, this system relies on the input of the users. Whereas
for database management, this system needs to interact with database management software
(MySQL).

Figure 2: Use case diagram of Plantation Management System

2.1.1 System Interfaces

The File Management shall contains five modules that serves specific functions to full fill the
systems goals. The modules are Delivery Order, Invoice, Sales Memo, and User
Management. The plantation and marketing office clerk can access two modules which are
the Delivery Order Module and Sales Memo Module. For Weighing Ticket Module and
Invoice Module shall be able to access by the PTS office clerk. Whereas, the Factory OC shall
be able to access the Weighing Ticket Module. Lastly the administrator shall be able to
access User Management Module.


2.1.2 User Interfaces
Since the system is used by different users, the category of user interface (UI) is depend on
the functions the user is authorized to perform. When the user access to the system, The
system provides some united interface such as login and home page for all the users.
Through this home page interface, all basic users functions is shown but can be accessed
after login and based on user access authorization. This system is very user friendly which
the new users of the system only require short briefing from the experience users before
operating it.

2.1.3 Hardware Interfaces
Just like any other system, this system requires basic computer that consists of CPU,
monitor, keyboard and mouse for input and output. Printer is needed for print functions
too. Besides, for crops shipping, the system is connected with GPS device in every
organization transportation vehicles to get the transportation details.

2.1.4 Software Interfaces
The system is a standalone system that does not use external system. But the system will
require database management software like MySQL to manage the process of storing the
system data, and web server software that organizes the distribution of users in the local
network.

2.1.5 Communication Interfaces
The system communication interface is completely depend on server software to ensure
correct send and retrieve data from the database. Other than that is an online protocols to
connect between GPS and the system.

2.1.6 Memory
The program will need at least 50Mb HDD space and minimum 512Mb ram in order to run
at optimum performance.

2.1.7 Operations
a. The users of the system must first login into the system before operates the system
for security purpose.
b. The system should only be available and active during working hours set by the
executive.
c. The system shall be able to create backup for data daily.
d. The system shall be able to recover files from backup.

2.1.8 Site Adaptation Requirements

The software does not require any modifications for site adaptation. The system works on
basic computer that is connected to the organizations local area network

2.2 Product Functions

This Plantation Management System aims to make the creation, view, update and deletion
of the data in the system easier. Below are the major functions of this system.

a. Issue Delivery Order: The Plantation and Marketing Office Clerk may use this part to
issue DO by create DO. This function also allow save and print delivery order in the system
database.
b. Manage Delivery Order: The Plantation and Marketing Office Clerk may use this part
to edit and delete the created DO in the system database.
c. View Transportation Details: The Plantation and Marketing Office Clerk may use this
part to view the transportation details of the organization. Besides, the plantation and
marketing office clerk also can sort the transportation details according to date, vehicle
number plate and currently active vehicle.
d. Create Sales Memo: The Plantation and Marketing Office Clerk may use this part to
create Sales Memo.
e. View Sales memo: The Plantation and Marketing Office Clerk may use this part to
view the created Sales Memo in the system database.
f. Manage Invoice: The PTS and Factory Office Clerk may use this part to edit or delete
the created invoice in the system database.
g. Issue Invoice: The PTS Office Clerk may use this part to issue invoice by creating
Invoice. This function also allow PTS Clerk to print the invoice and save the invoice in the
system database.
h. Create Weighing Ticket: The PTS and Factory Office Clerk may use this part to create
weighing ticket and save it in the system database.
i. View Weighing Ticket: The PTS and Factory Office Clerk may use this part to view the
weighing ticket created in the system database.
j. Manage User: The administrator may use this part to manage the user by register,
update and delete user from the system database.

10

2.3 User Characteristics

This Plantation Management System is designed to be very user friendly. Users of this
system will not require special training before operate this system but just a short briefing
by the experienced users regarding the detailed functionalities. However, all the users must
acquire basic computer knowledge and knowing English or Malay as the system is in these
two languages. For this project, it is assumed that the system is designed using English.

2.4 Constraints
These are the few constraints of the Plantation Management System holds for proper
functionalities.
a. The Sales Memo can only be created, view and edit but sales memo are restricted
for deletion.
b. The System is designed in one screen where user can only execute one task at a
time.
c. For creating DO, Invoice, weighing ticket and sales memo, user still have to input the
data manually due to scanning functions are not available yet.
d. The system must connected to local area network of the organization before
operating.
e. The transportation vehicles of the organization must have GPS installed and working
for tracking purposes.

2.5 Assumption and Dependencies

a. The users of the system is assumed to have their own unique ID and password for login
purposes.
b. The backup ability shall be available for Plantation Management System to avoid data
lost. If the organization does not have backup storage, assumption is made that the local
server will not have downtime and data lost.
c. Assuming all the users for this system have basic computer knowledge and knows how
to operate the system smoothly

11

2.6 Apportioning of Requirements

For the Plantation Management System, several functions are omitted. These functions
might be implemented in the future.
a. The scanner may include in the future for faster and accurate data input especially
on the standardized document like weighing ticket.
b. The backup server may include in the future by storing the same data in the in
backup server.
c. The help function may be included in the future to help the users to understand the
system.

12

3. Specific Requirements

Figure 3: Domain model of Plantation Management System

3.1 External Interface Requirements

3.1.1 User Interfaces
The system is a standalone system that does not use external system. But the system will
require database management software like MySQL to manage the process of storing the
system data, and web server software that organizes the distribution of users in the local
network.

13

Figure 4: Login page

Figure 5: Response to the exception of error log in

Because plantation OC and marketing OC are accessing to the same modules Sale memo
and DO, the system will display the same page if either of them access. Sale memo page will
provide two options either create or view sale memo. Clicking on create memo page
prompts the user to the indicate whether he/she is from PTS or factory (Figure 6). The two
main options the user needs to deal with the sale memo is to choose whether cteate a new
one or view existing sale memo(Figure 7). As result of click on create, the system

14

automatically generates sale memo ID, source, date and time. In addition, the system
provides a form with several bars to be filled up and click on save icon to save the new sale
memo information in the system database (Figure 8).

PMS

Sale memo

PTS Factory

Figure 6: Sale memo menu interface

PMS

Sale memo

Create View

Figure 7: Sales memo menu options

15

PMS Create Sale Memo

Sale memo ID: 2016514

Source : Factory
Date : 14-5-2016
Time : 11:12 A.M

Fill up provided fields

Number of fruit
Weight KG
Grade
Total price RM Save

Figure 8: Create sale memo

In case user choice was view in order to check or update certain sale memo, the system will
help the user to sort existed sale memo base on the ID or save date (Figure 9).Sort by date
will display up down latest saves sales memo list with option of view or update each one
(Figure 10).

PMS View Sale Memo

Sort sale memo

ID Date

Figure 9: Sort sale memo

16

PMS Sort by Date

ID Source Date Option

2016414 Factory 14-5-2016 View Update

2014512 PTS 13-5-2015 View Update

Figure 10: List of sales memo that have been sorted by date (latest to oldest)

Updating sale memo allow user to change the information which are already filled up during
creating and save it again (Figure 11).

PMS Update Sale Memo

Sale memo ID: 2016514

Source : Factory
Date : 14-5-2016
Time : 11:12 A.M

Fill up provided fields

Number of fruit 2100

Weight 700 KG
Grade Good
Good
Total price RM Save

Figure 11: Update sale memo

17

3.1.2 Hardware Interfaces

Built up GPS device in every organization transportation vehicles record the transportation
details. Those information recorded base on the vehicle plate number of truck carrying the
crops. All the recorded information will be save in the system database and can be retrieve
later marketing OC.

The information gathered by the GPS are as following:

Source
Travelled path
Destination
Duration of the trip


3.1.3 Software Interfaces
The system requires DBMS software handle the database. For this system, MySQL is used.
Below is the details of the MySQL.

MySQL Database Management Software

Mnemonic: MySQL
Version Number: 5.7.12
Source: MySQL AB
Reference link: https://dev.mysql.com/doc/refman/5.7/en/

3.1.4 Communication Interfaces
The communication between the different parts of the system is important since they
depend on each other. However, in what way the communication is achieved is not
important for the system and is therefore handled by web server and DBMS software.

18

3.2 System Features

3.2.1 Module of Delivery Order

Figure 12: DO module

19

3.2.1.1 UC-001: Issue Delivery Order

History Log: 1.0 Create initial use case

2.0 Fixed exception flow
Fixed normal flow
3.0 Fixed normal flow, alternative flow and exception
Fixed pre-conditions
Added requirements
Version: 3.0
Use Case ID: UC-001
User Case Name: Issue Delivery Order
Created by: Pang Cheng Hao Last Updated By: Pang Cheng Hao
Date Created: 9 April 2016 Last Revision Date: 15May 2016
Actors: Marketing OC, Plantation OC
Description: This use case describes how the Marketing OC and Plantation OC issues DO to
the lorry drivers.
Pre-conditions: 1. The Marketing and Plantation OC must first login into the Plantation
Management System.
2. The Marketing and Plantation OC must acquire palm fruits weight
estimation from plantation worker.
3. The Marketing and Plantation OC must make sure the delivery vehicle
(Lorry) must have active GPS device which is attached to the system.
4. The Marketing and Plantation OC clicks on Issue Delivery Order.
Normal Flow: 1. The system shall display DO form.
2. The system auto generates date for this delivery order.
3. The system auto generates a delivery order ID for this delivery order.
4. The Marketing and Plantation OC enters recipient address.
5. The Marketing and Plantation OC enters palm fruits estimated fruits
6. The Marketing and Plantation OC enters vehicle number plate of the
delivery vehicle.
7. The Marketing and Plantation OC clicks Save button. (See A.1)
8. The system shall be able to save the delivery order in the database. (See
E.1)
9. The Marketing and plantation OC clicks Print.
20
10. The system should print the delivery order. (See E.2)



Alternative Flow: A.1 The Marketing and plantation OC cancels delivery order.

1. The Marketing and Plantation OC clicks Cancel

2. The system shall return to main menu.
Exception: E.1 The system fails to save.
1. The system shall be able to display System Fail to Save Delivery Order
2. Return to normal flow step 8. (See NF 1.0)

E.2 The system fails to print delivery order.
1. The system shall be able display Error in printing process. Please check
printer.
2. Return to normal flow step 10. (See NF 1.0)
Post Condition: The delivery order is created and saved in the system database.
Related ID Requirement Priority
Requirement: FR UC-001-01 The system shall be able to display the DO form. Basic

FR UC-001-02 The system shall be able to allow Marketing and Basic
Plantation OC to enter details into the DO form
FR UC-001-03 The system shall allow Marketing and Plantation Excitement
OC to print the created DO
FR UC-001-04 The Marketing and Plantation OC should be able Basic
to cancel the DO
QR UC-001- The system shall be able to prompt error Performance
05 message when system fails to save DO and
system fails to print delivery order
CR UC-001-06 The Marketing and Plantation OC shall be able to Performance
print the DO after the DO has been successfully
saved in system database

Table 1: Use case description for UC-001

21

Figure 13: System sequence diagram for issue delivery order

22

Figure 14: Activity diagram for issue delivery order

23

3.2.1.2 UC-002: View Transportation Details

History Log: 1.0 Create initial use case
2.0 Fixed alternative flow
Fixed exception flow
Fixed normal flow
3.0 Fixed normal flow, alternative flow and exception
Fixed pre-conditions
Added related requirements
Version: 3.0
Use Case ID: UC-002
User Case Name: View Transportation Details
Created By: Pang Cheng Hao Last Updated By: Pang Cheng Hao
Date Created: 8 April 2016 Last Revision Date: 14 May 2016
Actors: Marketing OC, Plantation OC
Description: This use case describes how the Marketing OC and Plantation OC view transportation
details.
Pre-conditions: 1. The Marketing and Plantation OC must first login into the plantation management
system
2. The user clicks View Transportation Details in the menu.
Normal Flow: 1. The system shall display the list of transportation details. (See E.1)
2. The user can sort the list by date, vehicle number plate, current active vehicle and
vehicle current location. (See A.1, A.2, A.3)
3. The system shall display the sorted list of the transportation details.
4. The system ends use case.
Alternative Flow: A.1 Sort According to date.
1. The Marketing and Plantation OC clicks dropdown list of Sort and click to Date.
2. The system sort the transportation details according to last updated list.
3. Return to normal flow 4. (See NF 1.0)

A.2 Sort According to vehicle number plate.
1. The Marketing and Plantation OC clicks dropdown list of Sort and click to No.
Plate.
2. The system sort the transportation details according to vehicle number plate.
3. Return to normal flow 4. (See NF 1.0)

24

A.3 Sort According to currently active vehicle.
4. The Marketing and Plantation OC clicks dropdown list of Sort and click to
Active.
5. The system sort the transportation details according to current active vehicles
(delivering fruits).
6. Return to normal flow 4. (See NF 1.0)
Exception: E.1 No transportation details in database.
1. The system displays No transportation record found!
2. Return to normal flow step 1. (See NF 1.0)
Post Condition: The transportation details are successfully displayed on the screen.
Related ID Requirement Priority
Requirement: FR UC-002-01 The system shall be able to display the list of Basic
transportation details in the system database
CR UC-002-01 The system shall prompt Marketing or Plantation OC Performance
error message when no transportation is found in the
system database

Table 2: Use case description for UC-002

25

Figure 15: System sequence diagram for view transportation details

26

Figure 16: Activity diagram for view transportation details

27

3.2.1.3 UC-009: Manage Delivery Order

History Log: 1.0 Create initial use case
2.0 Fixed pre-conditions
Fixed normal flow
Added related requirements
Version: 2.0
Use Case ID: UC-009
Use Case Name: Manage Delivery Order
Created By: Pang Cheng Hao Last Updated By: Pang Cheng Hao
Date Created: 28 April 2016 Last Revision Date: 14 May 2016
Actors: Marketing OC, Plantation OC
Description: This use case describes how the Plantation OC and Marketing OC manage DO.
Pre-conditions: 1. The Marketing and Plantation OC must first login into the plantation management
system
2. The Marketing or Plantation OC clicks on Manage DO button.
Normal Flow: 1. The system displays DO list. (See E.1)
2. The Marketing or Plantation OC select desired DO.
3. The system displays the DO.
4. The system displays 2 option buttons Edit and Delete.
5. The Marketing or Plantation OC clicks on option button. (See A.1, A.2)
Alternative Flow: A.1 Edit DO
1. The Marketing or Plantation OC clicks Edit button.
2. The system permits Marketing or Plantation OC to edit.
3. The Marketing or Plantation OC edits DO content.
4. The Marketing or Plantation OC clicks Save button.
5. The system saves edited DO into system database.
6. The Marketing or Plantation OC clicks Print button.
7. The system clicks Print button. (See E.2)
8. Return to normal flow step 3. (See NF 1.0)

A.2 Delete DO
1. The Marketing or Plantation OC clicks Delete button.
2. The system displays delete confirmation window with 2 buttons Confirm and

28

Delete.
3. If the Marketing or Plantation OC clicks Cancel,
3.1. Return to normal flow step 3. (See NF 1.0)
4. If the Marketing or Plantation OC clicks Confirm,
4.1. The system deletes the DO from system database.
4.2. Return to normal flow step 3. (See NF 1.0)
Exception: E.1 No DO found in system database
1. The system displays No DO found in system database message.
2. Return to normal flow step 3. (See NF 1.0)
E.2 Fail to print DO
1. The system displays Fail to print DO! Please check printer. Message.
2. Return to normal flow step 3. (See NF 1.0)
Post-conditions: The Marketing OC or Plantation OC successfully managed the DO.
Related ID Requirement Priority
Requirement: FR UC-003-01 The system shall be able to display the list of created DO Basic
in the system database
FR UC-003-02 The system shall be able to display the created DO in the Basic
system database
FR UC-003-03 The system shall be able to allow Marketing and Basic
Plantation OC to enter details into the DO form
FR UC-003-04 The system shall allow Marketing and Plantation OC to Excitement
print the created DO
FR UC-003-05 The Marketing and Plantation OC should be able to delete Basic
the created DO from the system database
QR UC-003- The system shall be able to display error message when Performance
01 no DO found in system database and fail to print DO
CR UC-003-01 The system shall prompt confirmation for DO deletion Performance
before delete the DO
CR UC-003-01 The Marketing and Plantation OC shall be able to print the Performance
DO after the DO has been successfully saved in system
database

Table 3: Use case description for UC-009

29

Figure 17: System sequence diagram for manage DO

30

Figure 18: Activity diagram for manage DO

31

3.2.2 Module of Invoice

Figure 19: Invoice module

32

3.2.2.1 UC-005: Issue Invoice

History Log: 1.0 Create initial use case
2.0 Fixed alternate flow
Fixed exception flow
Fixed normal flow
3.0 Fixed pre-conditions
Fixed normal flow
Added related requirements
Version: 3.0
Use Case ID : UC-005
Use Case Name : Issue Invoice
Description: This use case describes how the Pusat Pengumpulan OC and Pusat Timbang
Setempat OC issue invoice.
Created By: Fatin Nabillah bt Sihan Last Updated By: Pang Cheng Hao
Date Created: 11 April 2016 Last Revision Date: 15 May 2016
Actors : Pusat Pengumpulan(PP), Pusat Timbang Setempat(PTS) OC.
Description : This use case describes how the PP and PTS creates invoice.
Pre-conditions : 1. The PP and PTS OC must first login into the plantation management system.
2. The PP and PTS OC must receive weighing ticket.
3. The PP and PTS OC clicks Invoice button.
Normal Flow : 1. The PP and PTS OC enters the buyers company name.
2. The PP and PTS OC enters the price, weight and grades based on weighing
ticket.
3. The system auto generates date and time for the invoice.
4. The PP and PTS OC clicks Save button. (See A.1)
5. The system saves the invoice in system database.
6. The PP and PTS OC clicks Print button.
7. The system prints the invoice (See E.1)

Alternative Flow : A.1 The PP and PTS OC cancel invoice

1. The PP and PTS OC clicks Cancel button.
2. Return to normal flow step 1. (NF 1.0)
Exception : E.1 The system fails to print.

33

1. The system display Error in printing process. Please check printer.

2. Return to normal flow step 7. (See NF 1.0)
Post-conditions : The PP and PTS OC successfully created invoice and save into database.
Related ID Requirement Priority
requirement: FR UC-005-01 The system shall be able to create an Basic
invoice
FR UC-005-02 The system shall be able to display the Basic
Invoice form.
FR UC-005-03 The system shall be able to allow PP Basic
and PTS OC to enter details into the
Invoice form
FR UC-005-04 The system shall allow PP and PTS OC Excitement
to print the created Invoice
FR UC-005-05 The PP and PTS OC should be able to Basic
cancel the Invoice
QR UC-005-06 The system shall be able to prompt Performance
error message when system fails to
print the Invoice.
CR UC-005-07 The PP and PTS OC shall be able to print Performance
the Invoice after the it has been
successfully saved in system database
Table 4: Use case description for UC-005

34

Figure 20: System sequence diagram for issue invoice

35

Figure 21: Activity diagram for issue invoice

36

3.2.2.2 UC-010: Manage Invoice

History Log: 1.0 Create initial use case
2.0 Added related requirements
Version: 2.0
Use Case ID: UC-010
Use Case Name: Manage Invoice
Created By: Pang Cheng Hao Last Updated By: Nur Aqilah Puteri
Date Created: 28 April 2016 Last Revision Date: 14 May 2016
Actors: PTS OC
Description: This use case describes how the PTS OC manage Invoice.
Pre-conditions: 1. The PTS OC must first login into the plantation management system.
2. The PTS OC clicks Manage Invoice button.
Normal Flow: 1. The system displays invoice list. (See E.1)
2. The PTS OC select desired Invoice.
3. The system displays the Invoice.
4. The system displays 2 option buttons Edit and Delete.
5. The PTS OC clicks on option button. (See A.1, A.2)
Alternative Flow: A.1 Edit Invoice
9. The PTS OC clicks Edit button.
10. The system permits PTS OC to edit.
11. The PTS OC edits DO content.
12. The PTS OC clicks Save button.
13. The system saves edited DO into system database.
14. The PTS OC clicks Print button.
15. The system clicks Print button. (See E.2)
16. Return to normal flow step 3. (See NF 1.0)

A.2 Delete Invoice
5. The PTS OC clicks Delete button.
6. The system displays delete confirmation window with 2 buttons Confirm and
Delete.
7. If the PTS OC clicks Cancel,
7.1. Return to normal flow step 3. (See NF 1.0)

37

8. If the PTS OC clicks Confirm,

8.1. The system deletes the DO from system database.
8.2. Return to normal flow step 3. (See NF 1.0)
Exception: E.1 No Invoice found in system database
3. The system displays No Invoice found in system database message.
4. Return to normal flow step 3. (See NF 1.0)

E.2 Fail to print Invoice
3. The system displays Fail to print Invoice! Please check printer. Message.
4. Return to normal flow step 3. (See NF 1.0)
Post-conditions: The PTS OC successfully managed the Invoice.
Related ID Requirement Priority
requirement: FR UC-010-01 The system shall be able to display the Basic
manage invoice
FR UC-010-02 The system shall be able to allow PTS Basic
OC to enter details into the invoice
form as to edit the invoice information
FR UC-010-03 The system shall allow PTS OC to print Excitement
the updated Invoice
FR UC-010-04 The PTS OC should be able to cancel Basic
the edit and delete process.
QR UC-010-05 The system shall be able to prompt Performance
error message when the system fails to
print invoice
CR UC-010-06 PTS OC shall be able to print the invoice Performance
after the invoice has been successfully
saved in system database
Table 5: Use case description for UC-010

38

Figure 22: System sequence diagram for manage invoice

39

Figure 23: Activity diagram for manage invoice

40

3.2.3 Module of Sales Memo

Figure 24: Sales memo module

41

3.2.3.1 UC-003: Create Sales Memo

History Log: 1.0 Create initial use case
2.0 Fixed exception flow
Fixed normal flow
Fixed pre-conditions
3.0
Fixed normal flow
Added related requirements
Version: 3.0
Use Case ID: UC-003
User Case Creates Sales Memo
Name:
Created By: Abbad Last Updated By: Pang Cheng Hao
Date Created: 9 April 2016 Last Revision Date: 14 May 2016
Actors: Marketing OC, Plantation OC
Description: This use case describes how the Marketing OC and Plantation OC create sales memo
Pre-conditions: 1. The Marketing and Plantation OC must first login into the plantation management
system
2. The Marketing and Plantation OC must make sure the delivery vehicle (Lorry) must
have active GPS device which is attached to the system.
3. The Marketing and Plantation OC must receive weighing ticket from PTS or Factory
4. The Marketing and Plantation OC clicks Create Sales Memo in the menu.
Normal Flow: 1. The system displays From PTS and From Factory option button.
2. The Marketing and Plantation OC choose either from PTS or Factory. (See A.1, A.2)
3. The system auto generates sales memo ID for this sales memo.
4. The Marketing and Plantation OC enter sales memo details.
5. The Marketing and Plantation OC clicks Save. (See E.2)
6. The system saves the sales memo in the database (See E.1)
Alternative A.1 The Marketing and Plantation OC select from PTS
Flow: 1. The Marketing and Plantation OC clicks From PTS button.
2. The system displays from PTS sales memo form.
3. Return to normal flow step 4. (NF 1.0)

A.2 The Marketing and Plantation OC select from Factory
1. The Marketing and Plantation OC clicks From Factory button.

42

2. The system displays from Factory sales memo form.

2. Return to normal flow step 4. (NF 1.0)
Exception: E.1 The system unable to save
1. The system displays System Unable to Save Sales Memo.
2. Return to main menu.

E.2 The Marketing and Plantation OC cancel sales memo
1. The Marketing and Plantation OC clicks Cancel button.
2. Return to main menu.
Post Condition: The sales memo is successfully save into system database
Related ID Requirement Priority
Requirements FR UC-003-01 The system shall allow the user to choose Basic
either from PTS or factory
FR UC-003-02 When a user click on create sale memo, the Basic
system shall generates ID immediately for this
new sale memo

FR UC-003-03 The system shall allow the user to cancel the Basic
new sale memo creation
QR UC-003-04 The system shall enable the user to enter sales Basic
memo details
CR UC-003-05 The system shall proceed save process if one of Performance
the sale memo information is not filled up.

Table 6: Use case description for UC-003

43

Figure 25: System sequence diagram for create sales memo

44

Figure 26: Activity diagram for create sales memo

45

3.2.3.2 UC-004: View Sales Memo

History Log: 1.0 Create initial use case

2.0 Fixed alternate flow
3.0 Fixed exception flow
Fixed normal flow
4.0 Fixed pre-conditions
Fixed normal flow
Added related requirements
Version: 4.0
Use Case ID: UC-004
User Case View Sales Memo
Name:
Created By: Abbad Last Updated By: Nur Aqilah Puteri
Date Created: 9 April 2016 Last Revision Date: 14 May 2016
Actors: Marketing OC, Plantation OC
Description: This use case describes how the Marketing OC and Plantation OC view Sales Memo
Pre- 1. The Marketing and Plantation OC must first login into the plantation management
conditions: system
2. The Marketing and Plantation OC clicks View Sales Memo in the menu.
Normal Flow: 1. The system displays list of sales memo. (See E.1).
2. The system displays ID and Date sorting options buttons.
3. The Marketing and Plantation OC selects sort type. (See A.1, A.2)
4. The system displays sorted list.
5. The Marketing and Plantation OC selects sales memo.
6. The system displays the selected sales memo.
Alternative A.1 Sort by sales memo ID
Flow: 1. The user clicks drop-down-list Sort and click by ID.
2. Return to step 5. (See NF 1.0)
A.2 Sort by sales memo by date
1. The user clicks drop-down-list Sort and click by Date.
2. Return to normal flow step 5. (See NF 1.0)
Exception: E.1 No sales memo is found
1. The system displays No Sales Memo Found in System.
46
2. Return to normal flow step 1 (See NF 1.0)



Post The list of sales memo is successfully displayed.

Condition:
Related ID Requirement Priority
Requirements FR UC-004-01 The system shall be able to list all existed sales basic
memo.
FR UC-004-02 The system shall allow the user to sort the basic
existed sales memo.
FR UC-004-03 The system shall allow the user to update sale basic
memo
QR UC-004-04 If no sale memo found, the system shall return performance
to sale memo sorting page
CR UC-004-05 The system shall not enable the user to update performance
sales memo ID, date and source.


Table 7: Use case description for UC-004

47

Figure 27: System sequence diagram for view sales memo

48

Figure 28: Activity diagram for view sales memo

49

3.2.4 Module of Weighting Ticket

Figure 14: Weighting ticket module

50

3.2.4.1 UC-006: Create Weighting Ticket

History Log: 1.0 Create initial use case
2.0 Fixed alternative flow
Fixed exception flow
Fixed normal flow
3.0 Fixed pre-conditions
Fixed normal flow
Added related requirements
Version: 3.0
Use Case ID : UC-006
Use Case Name : Create Weighting Ticket
Created By: Nur Aqilah Puteri Last Updated By: Nur Aqilah Puteri
Date Created: 11 April 2016 Last Revision Date: 14 May 2016
Actors : PTS OC, Factory OC
Description : This use case describes how the PTS OC and Factory OC creates weighing ticket.
Pre-conditions : 1. The PTS OC and Factory OC must first login into the plantation management system.
2. The PTS or Factory OC clicks Create Weighting Ticket button.
Normal Flow : 1. The system displays weighing ticket form.
2. The PTS or Factory OC fills in the grades of the fruits.
3. The PTS or Factory OC fills in the number of the fruits.
4. The PTS or Factory OC fills in the weights of the fruits.
5. The PTS or Factory OC fills in the name of the person whom weights the fruits.
6. The PTS or Factory OC fills in the name of the person whom grades the fruits.
7. The system auto generates unique ID for the weighing ticket.
8. The system auto generates date and time for weighting ticket
9. The system asks PTS or Factory OC confirmation of the details to proceed. (see A2)
10. The PTS or Factory OC confirms the system.
11. The system saves weighting ticket into system database.
12. The PTS or Factory OC clicks Prints button.
13. The system prints Weighing Ticket.
Alternative Flow : A.1 User fail to log in into the system
1. The system shall display a Wrong combination of password and username.
Please try again message.

51

2. The use case resume at Normal Flow 2. (NF 1.0)

A.2 User not confirms the details
1. If PTS or Factory OC want to edit the details
PTS and Factory OC edit the details then the use case resumes at Normal
Flow 10.
Else if PTS or Factory OC want to clear all
PTS or Factory OC clicks Clear all button then the use case resumes at
Normal Flow 4.
Else
PTS or Factory OC log out from the system and the use case ends.
Exception : E.1 No response from the system
1. The system will display a Network unavailable. Please try again later message.
2. Return to main menu.
Post-conditions : Printed weighting ticket with the details of grade of the fruits, number of the fruits,
weight of the fruits, and name of person whom weight and grade the fruits.
Related ID Requirement Priority
Requirement: FR UC-006-01 The system shall be able to provide user which is grader Basic
with the ability to enter the weighting ticket details;
weight, number and grade of fruits, grader name and
name of person who weights the fruits.
FR UC-006-02 The system shall be able to notify the electronic Basic
weighting machine to weight the fruits.
FR UC-006-03 After grading and weighting are done, the system shall Excitement
be able to notify the electronic machine to print the
weighting ticket.
FR UC-006-04 The system shall be able save the weighting ticket data Basic
into a database for an ease future reference.
QR UC-006-05 The system shall be able to display the accurate weight Performance
of the fruits in less than 2 seconds.
CR UC-006-06 The system shall not be able to proceed save process if Performance
one of the weighting ticket information is not filled up.
Table 8: Use case description for UC-006

52

Figure 29: System sequence diagram for create weighting ticket

53

Figure 30: Activity diagram for create weighting ticket

54

3.2.4.2 UC-007: View Weighting Ticket

History Log: 1.0 Create initial use case
2.0 Fixed alternative flow
Fixed exception flow
Fixed normal flow
3.0 Fixed pre-conditions
Fixed normal flow
Added related requirements
Version: 3.0
Use Case ID : UC-007
Use Case View Weighting Ticket
Name :
Created By: Nur Aqilah Puteri Last Updated By: Nur Aqilah Puteri
Date Created: 11 April 2016 Last Revision Date: 14May 2016
Actors : PTS OC, Factory OC
Description : This use case describes how to view the weighting ticket.
Pre-conditions The PTS OC and Factory OC must first login into the plantation management system.
:
Normal Flow : 1. The PTS OC or Factory OC clicks Weighing Ticket button. (See E.1)
2. The system displays weighing ticket main menu.
3. The PTS OC or Factory OC clicks View button.
4. The system displays list of weighing ticket. (See A.1)
5. The PTS OC or Factory OC clicks View By dropdown list button.
6. The system displays viewing types.
7. The PTS OC or Factory OC selects viewing types. (See A.2, A.3, A.3)
8. The PTS PC or Factory OC select desired weighing ticket.
9. The system displays weighing ticket.
Alternative A.1 Weighting ticket not found
Flow : 1. The system shall display a Weighting ticket not found. Please try again message.
2. The use case resume at Normal Flow 6.
A.2 View all
1. The system sorts the weighing ticket list from latest to oldest.
2. The system displays the sort weighing ticket list.

55

3. Return to normal flow step 8 (See NF 1.0)

A.3 View by date
1. The PTS OC or Factory OC enter date.
2. The system displays the weighing ticket according to the entered date.
3. Return to normal flow step 8 (See NF 1.0)

A.4 View by unique id
1. The PTS OC or Factory OC enters desired the unique ID.
2. The system displays the weighing ticket according to the entered unique ID. (See
E.3)
3. Return to normal flow step 8 (See NF 1.0)
Exception : E.1 No response from the system
1. The system will display a Network unavailable. Please try again later message.
2. Return to main menu.
E.2 User fail to log in into the system
1. The system shall display a Wrong combination of password and username.
Please try again message.
2. The use case returns to main menu.

E.3 Weighing ticket with entered unique ID not found
1. The system displays The unique ID entered is not found! Please try again.
2. Return to alternate flow 4 step 1 (See A.4)
Post- Weighting ticket with the details of grade of the fruits, number of the fruits, weight of the
conditions : fruits, and name of person whom weight and grade the fruits will be displayed by the
system.
Related ID Requirement Priority
requirement: FR UC-007-01 The system shall be able to sort the weighting ticket data Basic
by its unique id or date to ease the grader to get the
details of the weighting ticket.
FR UC-007-02 The system shall be able to display the list of created Basic
Weighting Ticket in the system database
FR UC-007-03 The system shall be able to display the created DO in the Basic
system database

56

QR UC-007-04 The system shall be able to display error message when Performance
no Weighting Ticket found in system database
CR UC-007-05 The system should have a good network in order to Basic
proceed the process of viewing weighting ticket.
Table 9: Use case description for UC-007

Figure 31: System sequence diagram for view weighting ticket

57

Figure 32: Activity diagram for view weighting ticket

58

3.2.5 Module of User Management

Figure 15: User management module

59

3.2.5.1 UC-008: Manage User

History Log: 1.0 Create initial use case
2.0 Fixed pre-conditions
Fixed normal flow
Added related requirements
Version: 2.0
Use Case ID : UC-008
Use Case Manage User
Name :
Created By: Fatin Nabillah Last Updated By: Nur Aqilah Puteri
bt Sihan
Date Created: 11 April 2016 Last Revision Date: 14 May 2016
Actors : System Administrator
Description : This use case describes how the system administrator create, read, update and
delete the user account information.
Pre-conditions 1. The system administrator must log-in before using the Plantation
: Management System.
2. The System Administrator clicks Manage User button.
Normal Flow : 1. The system displays Manage User main menu.
2. The System Administrator choose from Register , Deleteand Update
buttons. (See A.1, A.2, A.3)
Alternative A.1 Register new account
Flow : 1. The system administrator clicks Register button.
2. The system administrator enters new user username.
3. The system administrator enters new account IC number as password.
4. The system Administrator sets the permission level of the worker, either
system administrator or staff.
5. The system administrator clicks Save button.
6. The system saves the new user into system database.
7. Return to normal flow step 2. (See NF 1.0)

A.2 Update existing user account
1. The system administrator clicks Update button.

60

2. The system displays all the accounts in the system database. (See E.2)
3. The system administrator selects desired account.
4. The system displays the account details of selected user account.
5. The system administrator updates the user account details.
6. The system administrator clicks Save button.
7. The system saves the account details changes.
8. Return to normal flow step 2. (See NF 1.0)

A.3 Delete existing user account
1. The system administrator clicks Delete button.
2. The system displays all the accounts in the system database.
3. The system administrator selects desired account.
4. The system displays the account details of selected user account.
5. The system administrator clicks Confirm to Delete button.
6. The system delete account from the system database.
7. Return to normal flow step 2. (See NF 1.0)
Exception : E.1 No response from the system
1. The system displays Network unavailable. Please try again later
message.
2. Return to main menu.

E.2 No account found in system database
1. The system displays No user account found in system database!
2. Return to normal flow step 2. (NF 1.0)
Post- The new account created successfully, the account details is updated
conditions : successfully, the account deleted successfully or account details has been
successfully viewed.
Related ID Requirement Priority
requirement: FR UC-008-01 The system shall be able Basic
to provide admin with the ability to
update, delete and register account
QR UC-008-02 The system shall be able to display the Performance
users account database in a good
sort(based on the alphabet A-Z)

61

Table 10: Use case description for UC-008

62

Figure 33: System sequence diagram for manage user

63

Figure 34: Activity diagram for manage user

64

3.3 Performance Requirements

3.3.1 Response time
The response time of the system should be no more than 2 seconds 90% of the time. In case
of opening windows forms, the popping of error messages and saving the settings or
sessions, the delay must be below 2 seconds. While, in case of opening databases, there
should be no delays and the operation must be performed in less than 2 seconds for
creating, searching, managing, and viewing > 95% of the files.

3.3.2 System dependability
If the software loses the connection to the Internet, the user should be informed by the
system with a Data could not be retrieved as there is an error occur in data connection.
message. Else if the system gets some strange input, the system shall be able to display an
error message to the user.

3.3.3 Safety
Information transmission should be securely transmitted to the server without any changes
in information.

3.3.4 Speed
The system must process any request made by user--OC and Admin-- such as searching,
creating, managing and viewing the information in less than 2 seconds.

3.3.5 Throughput
The system shall be able to process hundreds of information in database per minute.

3.3.6 Utilization
The system shall be able to use maximum computer processing resources when at peak for
an efficient data process.

65

66

3.4 Design Constraints

3.4.1 Hard drive space
The system should need no more than 20 MB space.

3.5 Software System Attributes

3.5.1 Reliability
The reliability that the system gives the right result on a search must be more than 98%.

3.5.2 Availability
The system should available more than 98% of the time (not considering network failing).

3.5.2.1 Internet connection
The system should be connected to the Internet in order to communicate with the
database.

3.5.3 Security
The system should provide secured communication with the server. 100% of the exchange
of information between client and server in the communication of a login session should be
encrypted.

3.5.3.1 Security of the accounts
The system should be notified about login failure and prevent a clerk from logging in to
the system if that clerk tries to login with a non-existing account.

3.5.3.2 Security of the clerk accounts
The system should provide locking period for half an hour, and during that period the
login function is disabled. A clerk and IP address should not be able to login to the
system for a certain time period after three times of failed login attempts.

67

3.5.3.3 Security of creating new account for user of the system

The system should asked the user to choose a different username if the user wants to
create an account and the desired username is already occupied.

3.5.4 Extensibility
The system should be easy to extend. The code of the system should be written in a way
that it favors implementation of new functions easily in the future.

3.5.5 Portability
The system should be portable with operating system such as Linux, Windows 95 up to the
latest version and Mac OS.

3.5.6 Usability
The system should be easy to handle and navigates in the most expected way with no
delays.

68

3.6 Other Requirements

3.6.1 Portability
The system shall be easily installed at new branch of client without incurring additional cost
of implementation.

3.6.2 Inter-operability
The interfaces should be completely understood by the clerk, and can operate with other
products or systems, present or future, without implementation or any restrictions in
access.

3.6.3 Operability
The system should keep an equipment in a safe and reliable functioning condition,
according to predefined operational requirements.

3.6.3.1 Search feature
The system should provide search feature in order for user--OC and admin-- to find sales
info, memo and invoice easily.

3.6.4 Reusability
The system can use existing on-the-shelf software during development process.

69