Draft SRS Document For Great Abyssinia PLC

ERP System Requirement Specification Document for
Great Abyssinia PLC.

2011

CNET SOFTWARE TECHNOLOGIES PLC Page 1

Chapter One
Introduction to the CNET_ERP Software System
CNET was established in 2000 and began operation in January 2001. Prior to the ERP system, the
company developed separate accounting and MIS software for six different organizations. Finally the
experts at CNET realized that the software which was developed had similar functionalities although
their domains were merely different. So, they have decided to develop the ERP system by integrating
the different systems developed earlier. However, due to various financial and time constraints, the
implementation of the existing ERP system didnt follow the accepted software development process.
1. ERP System
The term ERP originally implied systems designed to plan the use of enterprise-wide resources. It
incorporates all basic functions of an organization, regardless of the organization's business.
Merchandize organizations, non-profit organizations, governmental and nongovernmental
organizations, and other large entities utilize ERP systems. ERP's main goal is to integrate data and
processes from all areas of an organization and unify it for easy access and flow of work. It aims to
improve and streamline internal business processes, which typically requires reengineering of current
business processes.
The components of an ERP system are the common components of a Management Information System
(MIS). The boundary of an ERP system is usually smaller than the boundary of the organization that
implements the ERP system. Integration is an extremely important part to ERP. ERP usually
accomplishes integration by creating one single database that employs multiple software subsystems
providing different areas of an organization with various business functions.
In the absence of an ERP system, a large enterprise may find itself with many software applications that
do not communicate to each other and do not effectively interface with one another.
There are many advantages of implementing an EPR system; here are a few of them:
Improved efficiency and productivity levels
Better tracking and forecasting
2011


Lower costs
Improved customer service
reduced data entry resulting in fewer input errors,
Integration of production planning, material planning, and sales processing systems has allowed
for quicker conversion of customer orders into production schedules as well as material orders,
Customer service will be improved due to increased responsiveness resulting from the
integration of sales and production planning systems; total order visibility,
Increased visibility and understanding of future material requirements will provide suppliers
with more notice, thus improving their delivery performance.
While advantages usually outweigh disadvantages for most organizations implementing an ERP system,
here are some of the most common obstacles experienced:
The need to reengineer business processes
Technical support can be shoddy
Systems can be complex to be realized
Resistance in sharing sensitive internal information between departments can reduce the
effectiveness of the software.
Usually many obstacles can be prevented if adequate investment is made and adequate training is
involved, however, success does depend on skills and the experience of the workforce to quickly adapt
to the new system.

2011


1.1 Purpose
The main purpose of this SRS document is to describe the functional and nonfunctional requirements of
Great Abyssinia P.L.C ERP software needs. This software is version 5 of the ERP. From now on it will be
called CNET_ERP v.5 Software. This documentation does not cover all subsystems implemented by CNET
software technologies where as it only focus on the four subsystems that are requested by the Great
Abyssinia P.L.C. The four Subsystems are Sales, Inventory, Accounting and Production.
1.2. Document Convention
This SRS is developed by adapting templates derived from IEEE Standard 830-1998B which is highly
recommended by IEEE to Practice software requirement specification document. The document follows
the following convention while it is being written.
The document is written in Calibri(Body), 12 Text Style
Every Document title is written in Bold letter, Times New Roman, 12 Style
Each and every release specified at this document will be incorporated by the System.
The following ID mechanisms are utilized through out the document
o BR- Business Rule
o FE Feature
o UC Use Case
o CO Design and Implementation Constraint
o UD- User Documentation
o AS Assumption
o DE- Dependency
o UI- User Interface
o HI Hardware Interface
o SI- Software Interface
o CI-Communication Interface
o PE- Performance Requirements
o SA- Safety Requirements
o SE- Security Requirement

2011


1.3. Intended Audience and Reading Suggestions
This document is divided into six chapters in a way that it can briefly state what will be implemented
while the software is developed. The SRS is developed to create a common understanding between all
stakeholders. Chapter one mainly focuses on creating a common understanding about a working
system (Software). The Requirement analyst believes this chapter shall be read by all stake holders. In
this chapter we will have an abstract view of the system so that we can imagine what is developed in the
SRS for the system. Chapter two is developed for technical personals specially developers to understand
what is going to be implemented. Also in this chapter the features, the assumptions and the
functionalities and design constraints of the system will be developed in the system. The consultant
advises the developers and designers to read this part for the well development of the ERP system.
Chapter three is developed for clearly specifying the functional requirements of the system. The
consultant advices the analyst, Designer and developer of the project to read this part to identify a way
of implementing all functionalities in a user friendly manner. Chapter four is developed for creating a
clear understanding about the external interfaces of the system. This chapter is described in a low level
technical language so that all stakeholders understand what kind of external interface needed for
implementing the aspired software. Chapter five is developed for the developer to understand what the
users really need in addition with the functional requirements. Chapter six is a reference chapter that
compromises other requirements that can not be described in the other chapters. Each chapter is
intended to following Stakeholders.
Intended Audience (Stakeholders) Reading Suggestion
System Owner(MGT of Abyssinia) Chapter 1,3,4,5
System Designers Chapter 1-4
System Developers All
Technical People of Abyssinia All

1.4. Project Scope
The scope of this project is limited to the following modules of the CNET_ERP Subsystems. Based on
Great Abyssinia P.L.C business process the following modules of CNET ERP are found mandatory for
facilitating the Enterprise Activities. The enterprise needs the following subsystem modules
1. Sales Subsystem
The sales subsystem will have two major modules. Sales management module (SMM) is responsible to
keep track of information related with sales persons and sales transaction. This module is responsible
for keeping rules related with sales transactions and make sure that the rules are applied properly. For
example, once an invoice is created its content should never be modified. This module is also
responsible for creating sales related vouchers and support all required operations on those vouchers. It
is also responsible for the generation of reports.
2011


2. Inventory Subsystem
This subsystem will have two major modules Supplier Management Module (SMM) and Inventory
Management Module (IMM). SMM is responsible for maintaining supplier information and handles
reports that are related to suppliers or vendors. The module handles the purchase order, GRV, and
suppliers return activities that are related to the supplier. It is also responsible to provide various
reports related to the supplier. IMM is responsible to keep track of information related with
inventory transaction. This module is responsible for keeping rules related to the inventory
transactions and controls the proper implementation of the rules. This module is responsible for
creating inventory related vouchers such as SIV, GRV, Disposal, Store Return, Items Transfer and
Supplier Return and support all required operations on those vouchers.
3. Accounting Subsystem
This subsystem will have three major modules Account Receivable Management Module
(ARMM), Account Payable Management Module (APMM), and Journal Management Module
(JMM) ARMM is responsible for maintaining income related transactions that result for
increasing in the proprietorship asset. It includes the account receivables, which are obtained
mainly from sales revenue collection. It manages the preparation of credit sales invoice, cash
sales invoice and cash receipts. It is also responsible to provide various reports related to the
income transactions. APMM is responsible to keep track of information related with expense
transactions. In addition to the documents it receives mainly from sales and inventory
subsystem, this module prepares its own vouchers such as BPV, and PCPV. It is also responsible
for the generation of various reports.JMM is responsible for posting journal voucher source
documents to the appropriate journals. This module is also used to edit journals, to prepare
journal reports, and to control whether accounting journal principles are respected or not.
4. Production Subsystem
This subsystem is developed for maintaining products, production process and Production
voucher. The system will have a capacity for facilitating a production process from raw material
to finished process.
References Taken:-
1. CNET_ERP System Architecture and Development Guide, November 2007, By Tamirat and
Seamen
2. A Briefing made by Ato Manager and Finance officer of Great Abyssinia P.L.C
3. CNET Staffs that have domain knowledge on the ERP utilization in different enterprises.
4. Literature reviews of different Documents.
2011


Chapter two
Overall Description of the System
2.1. Product Perspective
This software product is developed for facilitating and automating the business process of Great
Abyssinia P.L.C. The System will be deployed in the Main Office, Sululta Branch and Egziharab Branch.
This chapter tries to address the known constraints, assumptions and dependencies of the system. Some
of the sections also show the technical details of static parts of the system. This system provides
accounting and finance management, Sales Management, Warehouse management and Production
Management. The system enables the owner to control all activities done by the marketing, sales,
human resource, finance etc.

CNET ERP Back up Server
Main office Server
Egziaherab ware
house
Sululta
Warehouse
Mobile sales
Management, Marketing, Accountant
Store keeper ,Sales
Production department, Store keeper, Sales
Workstation
Workstation
Workstation

Context Diagram for Great Abyssinia P.L.C CNET_ERP Software System Version 5
2011


2.2. Business Rules
According to the Business Rules Group (1993), "A business rule is a statement that defines or constrains
some aspect of the business. It is intended to assert business structure or to control or influence the
behavior of the business." Whole methodologies have been developed based on the discovery and
documentation of business rules and their implementation in automated business rules systems (Ross
1997; von Halle 2002).
ID Rule Definition Types of rule Source
BR-1 Vouchers are sequentially Numbered Facts International
literatures
BR-2 Vouchers need a time stamp Facts International
Literatures
BR-3 Vouchers need one or more owner Facts International
Literatures
BR-4 Vouchers should be contained in one page Facts International
Literatures and
Abyssinia MGT
BR-5 Vouchers can not be modified after being
Issued
Facts Ministry of Trade
and international
literature
BR-6 Vouchers need a copy distribution
management system
Facts Abyssinia MGT
BR-7 Vouchers Can be void Facts Ministry of trade
BR-8 Vouchers must support multiple print size
and formats
Facts Abyssinia Mgt
BR-9 Vouchers have an execution Procedure. Facts CNET consultants
and international
literature
2011


BR-10 While sales invoice is issued sales journal
Should be generated
Constraint CNET consultants
and international
literature
BR-11 When ever consignment sales is issued the
balance of a stock shall not be affected
Fact International
Literature
BR-12 When ever sales return invoice is issued the
General ledger will be Generated
Constraint International
Literatures
BR-13 The purchase request quantity will be set
according to the following rule:
Quantity_requested +
normal_stock_quantity
(quantity_available_in_stock +
quantity_available_in_consignment +
quantity_ in_ transit)
Remark: The user can modify the default
quantity

Computation International
literature
BR-14 Product doesnt need purchase request and
item doesnt need job request
Fact International
literature and AAU
experts argument
BR-15 A purchase requests must be prepared per
suppliers
Constraint International
literature and AAU
experts argument
BR-16 Purchase request must be Manually
approved
Constraint CNET Staff and
Development team
BR-17 A given closing includes all matured
transactions up to that point and beginning
information

Fact CNET Development
team and
Consultants
argument
Br- 18 Source documents should not be modified
after closing
Constraint And International
2011


Fact literatures
BR-19 Store return should always be approved. Constraint International
literatures
BR-20 Stock transfer does not affect the
companys capital.
fact International
literatures
BR-21 The classes of fixed assets are predefined. It
will refer the ministry of finance asset
definition document
Constraint Ethiopian
government law,
International
literatures
BR-22 Payment Request should always be
approved
Constraint CNET Development
office
BR-23 Payment preparation always needs a
reference document

Fact CNET Development
office
BR-24 There is always a threshold amount that is
set by an organization for the preparation of
check or to pay from the petty cash

Computation International
literatures
BR-25 The debit and credit information that is
inserted should be balanced
Computation CNET development
office

2011


2.3. User Class and Characteristics
User classes are products users that differ, among other ways, in the following respects:
The frequency with which they use the product
Their application domain experience and computer systems expertise
The features they use
The tasks they perform in support of their business processes
Their access privilege or security levels.
The following user classes are identified by CNET requirement development team. The
system shall entertain the user classs requirement in order to be successfully utilized.
User Class Description
System Admin The role of the system admin is to control all the proper functionality of the
software in each and every setting. Most settings and first time maintenance of
the software is implemented by this system admin. An organization can have a
system admin that is trained in CNET training center. But our enterprise gives a
preventive and maintenance administration to all customers of its product by its
system administrators.
1. Configure Accounting subsystem
2. Maintain Beginning Balance
3. Manage setting
4. Maintain Fixed asset
5. Manage incoming Check
6. Prepare payment voucher
7. Prepare bank deposit slip
8. Manage outgoing check
9. Approve payment request
10. Configure Inventory subsystem
11. Prepare store request
12. Generate report
13. Manage Stock transfer
14. Manage Disposal
15. Prepare purchase request
16. Manage Supplier return
17. Prepare GRV
18. Manage stock return
19. Close inventory
20. Prepare sales invoice
21. Define distribution target
22. Configure sales sub system
23. Prepare Performa
24. Prepare consignment note
25. Prepare Sales return invoice
26. Prepare production order
2011


Accountant The role of the accountant is to utilize the accounting subsystem according to his
profession. An accountant can easily understand and utilize why each of the
accounting forms and vouchers are prepared in the system. Each and every task
in the accounting module shall be done by an accountant.
1. Maintain Chart of account
2. Manage Journal
3. Prepare payment request
4. Prepare receipt
5. Manage account Reconciliation
6. Maintain beginning Balance
7. Manage Budget
8. Manage Settings
9. Maintain fixed asset
10. Manage incoming check
11. Prepare payment voucher
12. Prepare Bank Deposit Slip
13. Manage outgoing Check
14. Approve payment Request
15. Close accounting period
Cashier The role of cashier in our system is to pay cashes for those stake holders that are
going to be paid from the Great Abyssinia P.L.C.
1. Prepare Payment Request
2. Prepare receipt
Abyssinia Management The management shall play a role for controlling weather the system is used for
the targeted goal or not. The management also has a responsibility for approving
or rejecting main tasks in the enterprise
1. Approve Payment Request
2. Production order
3. Prepare product release voucher
Store personnel 1. Prepare store request
2. Generate report
3. Manage Stock transfer
4. Manage Disposal
5. Prepare purchase request
6. Manage Supplier return
7. Prepare GRV
8. Manage stock return
9. Close inventory
10. Prepare production order
11. Prepare store transfer voucher
12.
Time 1. Close inventory
Sales person 1. Manage POS sales
2. Prepare Sales invoice
2011


3. Prepare Performa
4. Prepare consignment Note
5. Prepare sales return note

Input Device 1. Manage POS sales
2. Prepare sales invoice
Marketing Department 1. Check availability of product
2. Prepare production request
3. Prepare finished product release voucher
The above table might become vague for you but what is tried to address there is which part of the
stake holder will have connectivity with the system attributes. Each of the user class categories can be
divided into different personnel we illustrate this issue while describing the use cases.
2.3.1 Use case Diagram
A use case describes a sequence of interactions between a system and an external actor. An
actor is a person, another software system, or a hardware device that interacts with the system
to achieve a useful goal (Cockburn 2001). Another name for actor is user role, because actors
are roles that the members of one or more user classes can perform with respect to the system
(Constantine and Lockwood 1999). Use cases shift the perspective of requirements
development to discussing what users need to accomplish. The objective of the use-case
approach is to describe all tasks that users will need to perform with the system. The resulting
set of use cases will encompass all the desired system functionality.
Use-case diagrams provide a high-level visual representation of the user requirements. The
box represents the system boundary. Lines from each actor (stick figure) connect to the use
cases (ovals) with which the actor interacts. Note the resemblance of this use-case diagram
to the context diagram in Figure 1. In the use-case diagram, the box separates some top-level
internals of the systemthe use casesfrom the external actors. The context diagram also
depicts objects that lie outside the system, but it provides no visibility into the system
internals.
We will see each of the subsystems use cases individually. But before that, let us see the flow diagram
(Work flow) of Great Abyssinia P.L.C Production distribution and sales activity.

2011


Production
Request
Purchase Approve
Production order
Active , Batch number,
production, Expiration date
Start
Bill of Quantity
Sales issue Voucher
Work in Process
Working Process, Journal recipt
Product Release
Voucher
Finished Product
Receiving
Voucher(GRV)
Title
Production
z

2011


Title
Distribution
Goods Receiving
Voucher
Cash or Credit
invoice
Store Transfer
Voucher
Sales Post
(I Owe You
Voucher)
Cash receiving
Voucher

2011


Title
Dispersment and Payment
Payment Type
Prepaid Purchase
(PO)
Post Paid
Purchase (CGRM)
Non stock
Payment (PAO)
Prepare
Approve
Bank Advice
Voucher
Pity Cash
Payment Voucher Bank Payment
Voucher
Cash Sales
Cash Recipt

2011


Sales Subsystem Use Case diagram

Sales Person
Manage POS Sales
Input Device
Prepare Sales Invoice
Configure Sales Subsystem
Prepare Consignment Note
System Admin.
Prepare Sales Return Invoice
Sales ERP System for
Abissinia

2011


Ware House Management System Use Case Diagram
Time
Authorized
Personnel
StorePersonnel
CloseInventory
ConfigureInventorySubsystem
PrepareStoreRequest
GenerateReport
ManageStockTransfer
ManageDisposal
PreparePurchaseRequest
ManageSupplierReturn
PrepareGRV
ManageStockReturn
ApproveRequest
SystemAdmin
(fromGlobal Actors)

Warehouse Management System
for Abyssinia

Production Use case Diagram
2011


System Admin(From
Global Class)
Manage store request
Batch Voucher
Marketing Department
representative
Maintain Budget
Packing List
Production Planning
Production
department
Maintain Production
Configure production
Maintain Production Request
"include"
Production Order
Store Keeper
Production Transfer
Managment
Production Process
Production System For Abyssinia

2011


Accounting Use Case Diagram
Accounting system for Abyssinia

2011


Use case Documentation
At this stage of the exploration, the stakeholders should be thinking of essential use cases. Constantine
and Lockwood (1999) define an essential use case, which discuss specific actions the user takes to
interact with the system, as "a simplified, generalized, abstract, technology-free and implementation-
independent description of one task or interaction that embodies the purpose or intentions underlying
the interaction." That is, the focus should be on the goal the user is trying to accomplish and the
system's responsibilities in meeting that goal.
Based on the IEEE 1998b international Use Case description format, for all use cases we develop the
description in the following format.
Use Case ID: UC-1
Use Case Name:
Created By: Last Updated BY:
Date Created: Date last Updated
Actors:
Description:
Preconditions:
Post-conditions:
Normal Course:

Alternative
Courses:

Exceptions:
Includes:
Priority:
Frequency of Use:
Special
Requirements:

Assumptions:

2.3.2.1. Use Case description for sales system of Great Abyssinia P.L.C
2011


No Use Case Description
1. ConfigureSalesSubsystem This use case is used to change the way the sales
subsystem behaves.
2. PrepareSalesInvoice This use case is used to create Sales Invoice
3. PrepareSalesConsingmentNote This use case is used to create Sales Consignment
Note
4. ManagePOSSales This use case is used to make sales at Point of
Sales
5. PrepareSalesReturnInvoice This use case is used to create Sales Return Invoice

2011


Use Case ID: UC-1
Use Case Name: Configure Sales Subsystem
Created By: Fasil Solomon (System Analyst) Last Updated BY: Fasil Solomon
Date Created: Jan 10, 2011 Date last Updated Jan 10, 2011
Actors: System Admin
Description: This use case is used to manage the way the sales subsystem behaves
Preconditions: 1. The user is successfully logged in
2. The ERP Main Window is displayed
Post-conditions: The new sales setting will be saved and a printable report of the new setting will
be displayed.
Normal Course:

1. The user chooses Sales Setting menu item from Setting menu
2. The system displays Sales Settings Form containing tabs for various types of
sales settings such as POS setting, advanced setting , so on
3. The user selects one of the options and presses the required tab
4. The system displays the list of setting items in the selected category with
their previous/default values
5. The user makes the changes and presses the Save button
6. The system displays confirmation message
7. Step 3- 6 may be repeated
8. The user press Ok button
Alternative
Courses:
9.4. 1. The user wants to reset to previous setting
1. The user selects the previous settings options
2. The system saves the existing setting and displays a confirmation message
for the change
3. The user approve the confirmation
4. The system replaces the existing setting with the selected configuration
settings
Exceptions: None
Includes: Login - in the case when the user configures after the installation is completed
Priority: High
Frequency of Use: Ones in three month
Special
Requirements:
1. If invalid configurations are made, the system should display the summary of
the invalid entries and should not move to the other page.
2. In each page the users should be allowed to reset the default setting after
making configurations
3. The Configuration History Bin should contain the previous configuration
history

2011


Use Case ID: UC-2
Use Case Name: Prepare Sales invoice
Created By: Fasil Solomon Last Updated BY: Fasil Solomon
Date Created: Jan 10,2011 Date last Updated Jan 10,2011
Actors: Sales person, System Admin, Input Device
Description: This use case is used to create Sales Invoice for normal sales transaction
Post-conditions: 1. The system will save the new sales invoice and displays a printable
document
2. The system will track and make changes on the quantity of the items
Normal Course:

1. The user chooses Cash Sales or Credit Sales menu item from the
Invoice submenu of the Sales menu
2. The system displays the Sales Invoice Preparation Form having Direct,
Previous Sales, Consignment tabs with an activated Direct tab and
automatically generated sales invoice id
3. The user enters or selects the customer, list of items along with their
quantity and presses Save button
4. The system checks the validity of the data and displays confirmation
message
Alternative
Courses:
Prepare sales invoice from previous documents
1. The user selects one of the previous documents tab
2. The system starts Prepare Voucher From Existing Voucher use case
with the selected document as a parameter
Exceptions: None
Includes: Login
Priority: High
Frequency of Use: Once in a minute
Special
Requirements:
None
Assumptions: All the requested items are available in the database i.e. sales invoice will
not be prepared for an item that is not yet registered

2011


Use Case ID: UC-3
Use Case Name: Manage POS sales
Actors: Sales Person, Input Device
Description: This use case is used to make sales at Point of Sales
Post-conditions: 1. The system will save the new sales invoice and displays a printable document
Normal Course:

1. The user chooses specific POS menu item form POS submenu of the Sales menu or
selects specific POS icon from the POS toolbar
2. The system displays the POS Form for the selected POS type with an automatically
generated sales invoice id
3. The user selects items and specify their quantities
4. The system computes the total price
5. The user selects the sales option (credit/cash) and payment type (check, cash, credit
card, debit card) and press Print button
6. The system checks the validity of the data and saves the invoice
Alternative Courses:
Activating Held Invoices
1. The user presses Show hold button
2. The system displays all previously held invoices
3. The user selects the specific invoice and presses retrieve button
4. The system activates the selected invoice and populates all controls with the selected
invoice information
5. The user makes modifications on the activated invoice and press Print button
Select the item from Touchpad
1. The user selects an item from the pad
2. The system displays the details of the item
3. The user enters the quantity
card, debit card) and press Print button
6. The system checks the validity of the data and save the invoice
Postconditions: The system will display or print sales invoice
Select the item from Master record
1. The user selects the item from the master record
2. The system displays the details of the item
2011


3. The user enters the quantity
card, debit card)
6. The system checks the validity of the data and Print the invoice
Postconditions: The invoice will be printed and transaction is recorded in the database
Hold an invoice
card, debit card) and presses the Hold button
2. The system will put the item in its hold state
Order while in Held state
1. The user selects a specific held invoice and presses add additional order button
2. The system will display the list of orders made to that specific held invoice
3. The user enters additional order to the invoice in the held state and presses save.
4. The system will add the item in the held invoice with the same Reference number and
displays a printable held invoice.
Postconditions: The order is added to the held state

Exceptions:
Includes: Login
Priority: High
Frequency of Use: Ones in a minute
Special Requirements: 1. The sales invoice may be suspended one or more times
2. When selecting an item, the system should automatically generate the necessary
detail information of the specific item with a default quantity of 1
3. Item should be selected using one of the following options:
By typing item id
By typing the description
By using barcode reader
By using touchpad
By using search criteria
By selecting line item
4. This use case generates SJ
5. POS configuration facility should be included in the Sales Settings menu item of the
settings menu and the POS interface should behave differently according to the
settings
6. If a system is running on a POS terminal POS toolbar should be activated with
appropriate POS type
Assumptions:

2011


Use Case ID: UC-4
Use Case Name: Prepare sales Consignment
Actors: Sales Person, System Admin
Description: This use case is used to create Sales Consignment note.
Post-conditions: The system will save the new Sales Consignment note and displays a
printable document.
Normal Course:

1. The user chooses Consignment sales menu item from the Sales Menu
2. The system displays the Consignment Sales Preparation Form along
with the system generated consignment sales id
3. The user enters the detail list of items along with their quantity, and
presses Save button
4. The system checks the validity of the data and displays a confirmation
message
Alternative
Courses:
Prepare Sales Consignment From Previously Prepared Consignment Sales
note
1. The user selects Previous Consignment tabs from the Consignment
Preparation Form
with previous Sales Consignment
Exceptions:
Includes: Login
Priority: High
Frequency of Use: Once in a day
Special
Requirements:

Assumptions: All the requested items are available in the database i.e. consignment
invoice will not be prepared for an item that is not yet registered

2011


Use Case ID: UC-5
Use Case Name: Prepare sales Return Invoice
Actors: Sales Person, System Admin
Description: This use case is used to create Sales Return Invoice
Post-conditions: 1. The system will save the new sales return invoice and displays a
printable document
Normal Course:

1. The user chooses Sales Return menu item from the Sales menu
2. The system displays the Sales Return Invoice Preparation Form having
Direct, Cash Sales and Credit Sales tabs with an activated Cash Sales
tab with an automatically generated sales return invoice id
3. The user selects invoice type and customer
4. The system displays the list of valid sales invoice for the selected
customer
5. The user selects specific sales invoice
6. The system displays list of items sold in that specific sales invoice
7. The user selects items being returned and the corresponding quantities
and enters the reason for sales return and presses Ok button.
8. The system checks the validity of the data and saves the sales return
invoice
Alternative
Courses:
Prepare Sales Return invoice from previous documents
1. The user selects one of the previous documents tab
with the selected document as a parameter
Exceptions: None
Includes: Login
Priority: High
Frequency of Use: Once in three days
Special
Requirements:
Sales return may have reference document
Assumptions:

2011


2.3.2.2. Use Case description for Warehouse management system
No Use Case Name Description
1 Configure Inventory Subsystem
This use case is used to adjust the way the
Inventory subsystem behaves. It configures auto
notifications and other settings
2 Prepare Store Request This use case is used to prepare store request. It
may be triggered by dispensary store or by user.
3 Approve Request This use case is used to approve inventory
vouchers whenever required
4 PreparePurchaseRequest This use case is used to initiate the purchase
process. After a purchase request is approved it
will become purchase order.
6 Close Inventory This use case is used to register inventory balance
at specific time.
7 Prepare GRV This use case is used when an item is proved to be
received into a store
8 Manage Disposal This use case is used to prepare disposal invoice
when an item is consumed or disposed
9 Manage Supplier Return This use case is used to manage returns made to
the supplier
10 Manage Stock Return This use case is used to manage items/products
returned into a store
11 Manage Stock Transfer This use case is used to manage the transfer of
items from one dispensary store to another
dispensary store

2011


Use Case ID: UC-6
Use Case Name: Configure inventory Subsystem
Actors: System Admin.
Description: This use case is used to manage the way the inventory subsystem behaves.
Post-conditions: The new inventory setting will be saved and a printable report of the new
setting will be displayed.
Normal Course:

1. The user chooses Inventory Setting menu item from Setting menu
2. The system displays Inventory Settings Form containing tabs for
various types of inventory settings such as Store settings, Approval
Points setting, Notifications, advanced setting , so on
3. The user selects one of the options and presses the required tab
4. The system displays the list of setting items in the selected category
with their previous/default values
5. The user makes the changes and presses the Save button
6. The system displays confirmation message
7. Step 3- 6 may be repeated
8. The user press Ok button
Alternative
Courses:
The user wants to reset to previous setting
1. The user selects the previous settings options
2. The system saves the existing setting and displays a confirmation
message for the change
3. The user approve the confirmation
4. The system replaces the existing setting with the selected
configuration settings
Exceptions:
Includes: Login - in the case when the user configures after the installation is
completed
Priority: High
Frequency of Use: Once in three months
Special
Requirements:
1. If invalid configurations are made, the system should display the
summary of the invalid entries and should not move to the other page.
2. In each page the users should be allowed to reset the default setting
after making configurations
3. The Configuration History Bin should contain the previous
configuration history
2011


Use Case ID: UC-7
Use Case Name: Prepare Store request
Date Created: Jan 10, 2011 Date last Updated Jan 10,2011
Actors: Store personnel, System Admin
Description: This use case is used to prepare store request. It may be triggered by
dispensary store or by user.
Post-conditions: New store request is registered to the Approval Waiting List and message
will be transferred to the person responsible for approval
Normal Course:

1. The user chooses Store Request menu item from Inventory menu
2. The system displays Store Request Form
3. The user selects or enters items, set their quantity, set the level of
urgency (urgent or top urgent) and press Ok button
4. The system validates the data and displays printable Store Request
Voucher
Alternative
Courses:
Prepare Store Request From other documents
1. The user presses From Previous Voucher button
2. The system executes the Prepare Voucher From Existing Voucher use
case
Exceptions:
Includes: Login, Prepare Voucher From Existing Voucher
Priority: High
Frequency of Use: Once in half a day
Special
Requirements:
The system should automatically generate an id to newly generated store
request vouchers
Assumptions:

2011


Use Case ID: UC-8
Use Case Name: Approve Store Request
Date Created: Jan 10,2011 Date last Updated Jan 10, 2011
Actors: Authorized personnel, System Admin
Description: This use case is used to approve store request
Post-conditions: 1. The document will be approved and passed to the next state.
2. Those Store Requests that are suspended will not be removed from
the Approval Waiting List along with their suspended items only
3. One or more SIVs may be created
4. One or more Purchase Request Vouchers may be created
Normal Course:

1. The user chooses Store Request Approval menu item from the
Inventory Menu or press the Ok button when the approval request
message is displayed
2. The system displays the list of store request documents in the Store
Request Approval Form
3. The user selects a store request from Approval Waiting List
4. The system displays the detail line item
5. While the user selects an item from the line item, the system displays
Availability Information
6. The user chooses either From Stock or From Consignment option
depending on the Availability Information and presses Ok button
7. The system will put available items in the Temporary SIV with
respective requester
8. The system removes the item from the Store Request Vouchers in line
item list
9. The user repeats step 3 8 until exhausting the Approval Waiting List
10. The user press the Approve Button
Alternative
Courses:
3.6.1 The request is for an item and the item is not available in the stock
and it is not in transit with the requested quantity
1. The system chooses Purchase Request option
2. The user presses Ok button
3. The system puts the item to the respective suppliers Temporary
Purchase Request Documents
Exception: If the suppliers Temporary Purchase Request Document is not
yet created the system will create a new Temporary Purchase Request
Document for the supplier
3.6.2 The request is for an item and the item is not available in the stock
2011


with the requested quantity but it is in transit
1. The system selects Suspend Request option
3. The system keeps the Store Request Voucher along with the suspended
item
3.6.1 The request is for a product and the product is not available
1. The system chooses Job Request option
3. The system puts the item in the Job Request Voucher
3.6.1 The item is not registered in the database
1. The system displays a item not registered message and prompt the
user for registration
2. The user confirms the registration
3. The MaintainItem use case from the Global Package will be triggered
4. The system will prepare Temporary Purchase Request Voucher for the
supplier that is registered along with the item.
Post condition: A new item is added to the stock items list.
Exceptions:
Includes: Login, PrepareSIV, MaintainItem, PrepareJobRequest,
PreparePurchaseRequest
Priority: High
Frequency of Use: Once in an hour
Special
Requirements:
1. When the user press the Ok button from the new approval request
message, the system should display Store Request Approval Form with
the list of store request documents that needs approval
2. It should be possible to stop live messaging when the authorized
personnel do not want it.
Assumptions: 1. The person who approves requests is also responsible for the
registration of new items
2. There is always a default supplier for each item

2011


Use Case ID: UC-9
Use Case Name: Prepare purchase request
Description: This use case is used to initiate the purchase process. After a purchase
request is approved it will become purchase order.
Post-conditions: The Purchase Request is saved and the document becomes ready for
manual approval
Normal Course:

1. The user chooses Purchase Request menu item from the Inventory
menu
2. The system displays the Purchase Request Form
3. The user selects items along with their quantity and press the Ok
Button
4. The system saves and/or displays and/or print (with unapproved flag)
the purchase request
Alternative
Courses:
4.3.1 Purchase Request preparation from previous document
1. The user presses From Previous Voucher button
2. The system executes the Prepare Voucher From Existing Voucher use
case with previous purchase request as parameter
4.1.1 Purchase Request preparation when store request is approved
1. The system selects Prepare Purchase Request option and saves the
request in the temporary Purchase Request voucher
Postcondition: The system collects all items to the supplier and save the
purchase request for the next operation
4.1.1 Purchase Request preparation from the system notification
1. The system displays a popup notice for items below the reorder level
2. The user selects auto PR preparation button
3. The system displays the list of a temporary purchase request items
with checkbox categorized by the supplier
4. The user selects some or all items that need purchase request and
press Prepare Purchase Request button
5. The system creates one or more purchase request
Postcondition: The system saves the purchase requests for next
operation
Exceptions:
2011


Includes: Login, Prepare Voucher From Existing Voucher
Priority: High
Special
Requirements:
The system should automatically generate an id for the Purchase Request
voucher
Assumptions: None

Use Case ID: UC-10
Use Case Name: Close inventory
Description: This use case is used to register inventory balance at specific time.
Post-conditions: The stock balance at time of closing is viewed, saved or printed
Normal Course:

1. The user chooses Close Inventory menu item from the Inventory menu
2. The system displays the on-hand, on-consignment, in-process and on-
transit balances and requests the user to close the inventory
3. The user presses the Yes button
4. The system saves and/or print the report
Alternative
Courses:
6.1.1 Automatic closing
1. The prescheduled closing task is fired and the system displays inventory
closing alert message
2. The user presses Yes button
3. The system computes the on-hand, on-consignment, on-transit and on-
request balances, displays a printable summary and saves the result in the
database
Exceptions:
Includes: Login
Priority: High
Frequency of Use: Once in a month
Special
Requirements:

Assumptions:

2011


Use Case ID: UC-11
Use Case Name: Prepare GRV
Description: This use case is used to prepare Goods Receiving Voucher
Post-conditions: The GRV is saved, a printable GRV is displayed and the document moves to the
next state
Normal Course:

1. The user chooses Good Receiving Voucher option from the Inventory menu
2. The system displays the GRV Preparation Form
3. The user selects or enters supplier information and other necessary
information along with all the voucher line items and press Save
4. The system checks the validity of the document then saves and/or displays
and/or print the GRV
Alternative
Courses:
7.3. 1. GRV preparation from previous document
1. The user presses From Previous Voucher tab
2. The system executes the Prepare Voucher From Existing Voucher use case
with Purchase Order and Consignment Note as parameters

Exceptions:
Includes: Login, Prepare Voucher From Existing Voucher, MaintainItem
Priority: High
Special
Requirements:
This use case generates PJ
Assumptions: All GRV line items are already registered by the system.

2011


use Case ID: UC-12
Use Case Name: Manage disposal
Description: This use case is used to prepare disposal invoice when an item is consumed or
disposed
Post-conditions: The Disposal Voucher is saved, a printable (with unapproved flag) Disposal
Voucher is displayed and the document moves to the next state
Normal Course:

1. The user chooses Disposal Voucher menu item from the Inventory menu
2. The system displays the Disposal Preparation Form with automatically
generated disposal id
3. The user enters items to dispose, reason for disposal (expired, damaged,
defective, consumption) and press Ok button
message
Alternative
Courses:
8.3. 1. Disposal Voucher Preparation from previous document
with Direct and Store Return parameters
Exceptions:
Includes: Login
Priority: High
Special
Requirements:
1. This use case generates GJ
2. Disposal Voucher should always be approved
Assumptions:

2011


Use Case ID: UC-13
Use Case Name: Manage Supplier Return
Description: This use case is used to prepare supplier return invoice
Post-conditions: The new Supplier Return Voucher is saved, a printable (with unapproved flag)
Supplier Return Voucher is displayed and the document moves to the next state
Normal Course:

1. The user chooses Supplier Return Voucher option from the Inventory menu
2. The system displays the Supplier return Preparation Form with an
automatically generated Supplier Return Voucher id
3. The user selects supplier, items and their quantity, reason for return
(normal, expired, defective, damaged), remark and presses Ok button
message
Alternative
Courses:
9.3. 1. Prepare Supplier From Previous Voucher
with GRV and Stock Return parameters
Exceptions:
Includes: Login
Priority: High
Frequency of Use: Once in a week
Special
Requirements:

Assumptions:

2011


Use Case ID: UC-14
Use Case Name: Manage Store Return
Description: This use case is used to manage items returned into a store usually by
consumers or dispensary stores
Post-conditions: The new Store Return Voucher is saved, a printable Store Return Voucher is
displayed and the document moves to the next state
Normal Course:

1. The user chooses Store return menu item from the Inventory menu
2. The system displays the Store Return Preparation Form with automatically
generated store return id
3. The user selects or enters items to be returned and their quantity, reason
for return (normal, expired, defective, damage), remark and presses Ok
button
message
Alternative
Courses:
10.3. 1. Prepare Store Return from Previous Document
with sales return, SIV and other store return as parameter

Exceptions:
Includes: Login
Priority: High
Frequency of Use: Once in a week
Special
Requirements:
3.
Assumptions:

2011


Use Case ID: UC-15
Use Case Name: Manage Stock Transfer
Description: This use case is used to manage the transfer of items from one dispensary store
to another dispensary store
Post-conditions: The new Stock Transfer Voucher is saved, a printable (with unapproved flag)
Stock Transfer Voucher is displayed and the document moves to the next state
Normal Course:

1. The user chooses Store Transfer Voucher menu item from the Inventory
menu
2. The system displays the Store Transfer Voucher Form with an automatically
generated store transfer voucher id
3. The user enters or selects the source store, destination store, reason for
transfer and items list with their respective quantities and press Ok button.
message
Alternative
Courses:
11.3. 1. Prepare Item Transfer from Previous Document
with store transfer parameter
Remark: Stock Transfer is commonly prepared from GRV, Sales Return,
Consignment Note, or Store Request
Exceptions:
Includes: Login
Priority: Moderate
Special
Requirements:
4.
Assumptions:

2011


Use Case ID: UC-16
Use Case Name: Prepare Voucher from existing Voucher
Description: This use case is used to prepare a voucher from previously prepared voucher. It
is introduced to minimize the amount of time required to prepare a new
voucher from line items. It is used when the new voucher continent is very
similar to previously prepared voucher.
2. A new voucher is created with its own id
3. The user presses one of the tabs on the new voucher creation form
Post-conditions: The voucher line items grid of the caller will be populated with the selected
voucher line items from the documents
Normal Course:

1. The system displays the list of documents in the selected category along
with the modification controls required for the specific document category
2. The user searches a document from the Documents List pane
3. The system displays all the voucher line items in the Detail Content pane
4. The user can add all the voucher line items in a document together or can
modify and add each item one by one into a voucher line item pane
5. The user press the Ok button
6. The system populates the voucher line item grid of the caller with voucher
line items that are selected on the Document Selection Form
Alternative
Courses:
3.4.1 Searching a document with criteria
1. The user enters search criteria (date, line item, etc) and press Filter button
2. The system displays all the documents that satisfy the criteria in the
Documents List pane.
Exceptions:
Includes: Login
Priority: Moderate
Special
Requirements:
1. The user should also be allowed to add items that are not in any previous
document
2. The user should be allowed to add items from one or more documents
Assumptions: Users will use this use case when they want to prepare a voucher that has
similar content as voucher that is prepared previously.

2011


2.3.2.3. Use Case description for the Accounting System
In the Accounting subsystem sixteen use cases are identified. The following list describes each of the use
cases briefly:
1 ConfigureAccountingSubsystem This use case is used to adjust the way the
accounting subsystem behaves. It configures
accounting methods, posting methods, accounts,
periods, and etc.
2 MaintainChartOfAccont This use case is used to create control accounts,
subsidiary accounts, set default accounts and
maintain beginning balances
3 MaintainBegnningBalance This use case is used set the beginning balance of
each of the accounts
4 ManageBudget This use case is used to set budget for expense
accounts
6 MaintainFixedAsset This use case is used to record a new fixed asset
and/or to modify an existing one
7 PreparePaymentRequest This use case is used to prepare payment request
8 ApprovePaymentRequest This use case is used to approve payment requests
waiting for approval
9 PreparePaymentVoucher This use case is used to prepare payment voucher
(PCPV or BPV) for purchase order, purchased items,
payment order or sales return
10 ManageOutgoingCheck This use case is used to manage the checks
prepared for employee, supplier or any other
payee. It defines number of payments, starting
date, check payment interval.
2011


11 PrepareReceipt This use case is used to prepare receipt when
receiving cash, check or credit card for credit
settlement or deposit
12 PrepareBankDepositSlip This use case is used to prepare deposit slips for
cashes received through cash sales invoice and
receipts
13 ManageIncomingCheck This use case is used to manage checks coming
from into an organization.
14 ManageAccountReconciliation This use case is used to check that the amounts of
liquid assets you show in the checkbook are
identical to the account balance shown on your
bank statement as of the same date.
15 ManageJournal This use case is used to generate, modify or post
any one of the five journals (GJ, DJ, SJ, RJ, and PJ)
16 CloseAccountingPeriod
This use case is used to know the exact balance of
an account at the end of a given period
3.
4. Table 1: Use Cases List in the Accounting Subsystem

se Case ID: UC-17
Use Case Name: Configure Accounting Subsystem
Description: This use case is used to adjust the way the accounting subsystem behaves. It
configures posting methods, accounts, periods, and etc.
Preconditions: 1. Installation of the Accounting subsystem is completed
2. The user wants to configure the Accounting subsystem
Post-conditions: 1. The settings of the system will be changed and the system will display a
printable configuration information
2011


2. The system will keep the previous configuration information in a
Configuration History Bin
Normal Course:

1. The user chooses Accounting Settings menu item from the Settings menu
or the system displays a message that requests the user to configure the
accounting subsystem
2. The system starts the Accounting Configuration Form with brief
description of the configuration tabs and an option to take the system to
previous configuration
3. The user selects any one of the tabs (fixed assets rate, check print setting,
payment setting, period setting, Default Account, Account Integration,
Posting Method, Advanced Setting, and etc)
4. The system displays the list of setting items in the selected category with
their previous/default values
5. The user modifies the default values and presses the Apply button
6. The system will validate the data and display confirmation message
Alternative
Courses:
1.3. 1. The user wants to reset to previous setting
1. The user selects one of the previous settings options from the past three
settings
2. The system saves the existing setting and displays a confirmation message
for the change
3. The user approves the confirmation
4. The system replaces the existing setting with the selected configuration
settings
Exceptions:
Includes: Login - in the case when the user configures after the installation is completed
Priority: High
Frequency of Use: Once in six months
Special
Requirements:
1. In each page the users should be allowed to reset the default setting after
making configurations
2. The Configuration History Bin should contain the last three configuration
history
3. All the setting pages must be separated by tab on the Accounting
Configuration Form
Assumptions: Acceptable default values will be set for each configuration items.

2011


Use Case ID: UC-18
Use Case Name: Maintain Chart of Account
Actors: Accountant
Description: This use case is used to create control accounts, subsidiary accounts
Post-conditions: The chart of account is created and a printable account tree is displayed
Normal Course:

1. The user chooses Chart Of Account menu item from Accounting menu
2. The system displays Chart of Account Form
3. The user selects or enters a control account from/to a tree or a combo
4. The system shows subsidiary accounts( if there are any) of the selected
control account
5. The user creates new accounts or modifies existing accounts and presses
the Save button
message
7. Step 3 - 6 may be repeated until all the entries of the chart of account are
made
Alternative
Courses:
2.3.1 Automatically creating accounts for employees, items, suppliers, and
customer
1. The user checks one or more checkboxes to the left of each of the entities
(employee, item, supplier, and/or customer) along with detail/category
options for which the accounts should be created and presses Generate
Accounts button
2. The system displays the automatically created accounts
3. The user reviews the accounts and presses the Save button
The system displays a confirmation message
Exceptions:
Includes: Login
Priority: High
Frequency of Use: Once in three months
Special
Requirements:

Assumptions:

2011


Use Case ID: UC-19
Use Case Name: Maintain Beginning Balance
Actors: Accountant , System Admin
Description: This use case is used to maintain the beginning balance of each of the accounts
Post-conditions: The beginning balance of each of the accounts will be set and a printable
beginning balance report will be displayed
Normal Course:

1. The user chooses Beginning Balance menu item from Accounting menu
2. The system displays Beginning Balance Form containing all the accounts in
the chart of account
3. The user enters the beginning values and press the Save button
message
Alternative
Courses:

Exceptions: If the user does not set any value for an account the system will take a valued
of 0 as its beginning balance
Includes: Login
Priority: High
Frequency of Use: Once in a year
Special
Requirements:
1. The system should allow the maintenance of beginning balance at any time
The system should determine and enable the appropriate debit or credit
side entry option automatically
Assumptions:

2011


Use Case ID: UC-20
Use Case Name: Maintain Budget
Description: This use case is used to set budget for expense accounts
Post-conditions: The budget amount of each of the expense accounts will be set and a printable
budget report will be displayed
Normal Course:

1. The user chooses Budget menu item from Accounting menu
2. The system displays the Budget Maintenance Form with the list of expense
accounts from the chart of account
3. The user enters the budget values and press Save button
message
Alternative
Courses:

Exceptions:
Includes: Login
Priority: High
Frequency of Use: Once in a year
Special
Requirements:
1. The system should allow the maintenance of budget at any time
2. A facility to view previous budget values for an account must be
implemented
Assumptions:

2011


Use Case ID: UC-21
Use Case Name: Maintain Fixed asset
Description: This use case is used to record a new fixed asset and/or to modify an existing
one
2. The Accounting Main Window is displayed
Post-conditions: The new fixed asset is saved into the fixed assets file
Normal Course:

1. The user chooses Fixed Asset menu item from Maintain menu
2. The system displays Fixed Asset Maintenance Form along with
automatically generated asset id.
3. The user enters/selects asset information such as the location of asset
(where it physically located), asset group(class) information, Account
information such as asset account, account depreciation, depreciation
rate, depreciation expiration account, and selects fixed asset depreciation
methods, and depreciation period information and presses Save button
4. The system validates the data and saves the fixed asset
Alternative
Courses:
6.3.2 Modify the record of existing Fixed Asset
1. The user presses Edit tab from the Fixed Asset Maintenance Form
2. The system displays a combo box for selecting the asset
3. The user selects a specific fixed asset item
4. The system populates the Fixed Asset Maintenance Form with the data of
the selected fixed asset
5. The user performs the required modification and presses the Save button
6. The system validates the data and displays confirmation message
Postconditions: The record of fixed asset is modified
Exceptions: If the user has no modify access privilege, the Edit tab will be
disabled
Exceptions:
Includes: Login
Priority: High
Special
Requirements:
The system should automatically generate an id to newly registered fixed asset

2011


Use Case ID: UC-21
Use Case Name: Prepare Payment Request
Actors: Accountant , Cashier, System Admin
Description: This use case is used to prepare payment request
Post-conditions: 1. The system saves the request, the Payment Request will be added to the
Approval Waiting Queue of the authorized personnel and a printable
payment request document will be displayed
2. An approval request message will be sent to the authorized personnel
Normal Course:

1. The user selects Payment Request menu item from the Accounting menu
2. The system displays the Payment Request Form
3. The user selects or enters the payee, the amount, reason for payment,
task/project and presses Prepare button
4. The system will validate and generate a confirmation message
Alternative
Courses:

Exceptions:
Includes: Login
Priority: High
Special
Requirements:

Assumptions:

2011


Use Case ID: UC-22
Use Case Name: Approve Payment Request
Actors: Authorized Personnel, Accountant
Description: This use case is used to approve payment requests waiting for approval
Post-conditions: The payment request will be changed to payment order and wait for the
preparation of BPV or PCPV preparation and a printable payment order
document will be displayed
Normal Course:

1. The user chooses Payment Approval menu item from the Accounting menu
or presses the Ok button when the approval request message is displayed
2. The system displays the list of payment request documents in the Payment
Approval Form
3. While the user selects an item from Approval Waiting List, the system
displays the request detail (requester, amount, task and reason)
4. The user sets account number and deduction requirement (Add VAT, VAT
included, Apply Withhold, None) and presses Approve button
5. The system will prepare Payment Order and make it ready for the
preparation of BPV or PCPV
6. The user repeats step 3 4 until exhausting the Approval Waiting List
Alternative
Courses:

Exceptions:
Includes: Login, Manage Journal
Priority: High
Special
Requirements:
The user may check budget before approving payment request.
Assumptions:

2011


Use Case ID: UC-23
Use Case Name: Prepare Payment Voucher
Actors: System Admin, Accountant
Description:
3. Reference payment document (PO, GRV, Store Return Voucher, Payment
Order) is already prepared
Post-conditions: The system saves the new payment voucher BPV will be displayed
Normal Course:

1. The user selects the Payment Voucher menu item from the Accounting
menu
2. The system displays the Payment Voucher Preparation Form along with
unsettled GRV, PO, Sales Return, Payment Order tabs that displays the list
of the required reference documents that are prepared same day
3. The user selects specific tab
4. The system displays the list of unsettled documents in the selected
category along with a checkbox to their left and an editable text box
containing the remaining amount to their right
5. The user selects or modifies one of the documents in the reference
documents list
6. The system will filter unpaid or unsettled documents that are going to be
paid for the selected reference document payee
7. The user checks all or some of the documents from the filtered list of
reference documents and modify the amount they carry
8. The system displays the payee, the total amount, and default cash account
that will be affected
9. The user may modify the cash account and presses Prepare button
10. The system prepares BPV
Alternative
Courses:
8.6.1 The user wants to prepare a payment document for several payees on a
single payment document
1. The user uncheck the Per Payee checkbox
2. The system displays all unsettled reference documents
3. The user checks two or more references documents that belong to
different payees
4. The system displays the total amount referenced to the selected payee and
prepares BPV
8.10.1 The user wants to prepare a PCPV
2011


1. user select petty cash account from the cash account and presses the Save
button
The system generates and saves PCPV and displays a printable PCPV
Exceptions: If the user wants to prepare a PCPV or BPV irrespective of the rule set by the
company, the system will provide the facility to the user to do so
Includes: Login, ManageJournal
Priority: High
Special
Requirements:
1. The user can Refresh button if the he/she wants to see all the payment
documents after processing for a single payee
2. The user should be able to see or modify the affected journal while
preparing payment
Assumptions:

2011


Use Case ID: UC-24
Use Case Name: Manage Outgoing Check
Actors: Accountant, System Admin
Description: This use case is used to manage the checks prepared for employee, supplier or
any other payee. It defines number of payments, starting date, check, payment
interval, check no, and due date.
3. The BPV is prepared
Post-conditions: The check schedule along with the amount is saved and become ready for
printing
Normal Course:

1. The user chooses Prepare Check submenu of the Accounting menu and
presses Outgoing Check menu item
2. The system displays accounting document form with BPV tab activated
3. The user enters filter criteria and presses Show button
4. The system displays BPVs that satisfies the filter criteria
5. The user selects a BPV and selects prepare check menu from a contextual
menu
6. The system displays check preparation form
7. The user enters number of payments, starting date, and date interval,
check no information and presses Ok button
8. The system saves the outgoing check information and displays printable
BPV
Alternative
Courses:

Exceptions:
Includes: Login
Priority: High
Special
Requirements:
1. The checks will be printed from Accounting document outgoing check tab
2. Each time the check is prepared the system checks the payment limit per
day
Assumptions:

2011


Use Case ID: UC-25
Use Case Name: Prepare Receipt
Actors: Accountant, Cashier, System Admin
Description: This use case is used to prepare receipt when receiving cash, check or credit card for
credit settlement or advance deposit
Post-conditions: The system saves and displays a printable receipt voucher
Normal Course:

1. The user selects Receipt Voucher menu item from the Accounting menu
2. The system displays Receipt Preparation Form with direct and credit settlement
tabs
3. The user selects the direct tab
4. The system displays direct receipt preparation controls
5. The user selects or enters payer, reason for payment, and cash account that will
be affected and presses Prepare button
6. The system will prepare the receipt
Alternative Courses: 11.5.1. The payment is with check or Credit card
1. The user selects Check option
2. The system triggers the ManageIncomingCheck use case
11.3.1. The Payment is from Credit settlement
1. The user selects the Credit settlement tab
2. The system displays unsettled Credit sales invoice along with a checkbox to their
left and an editable text box containing the remaining amount to their right
3. The user selects or modifies one of the documents in the reference documents
list
4. The system will filter unpaid or unsettled documents that are going to be paid for
the selected reference payer
5. The user checks all or some of the documents from the filtered list of reference
documents and modify the amount they carry
6. The system displays the payer, the total amount, and default cash account that
will be affected
7. The user may modify the cash account and presses Prepare button
8. The system prepares cash receipt
Exceptions:
Includes: Login, ManageIncomingCheck
Priority: High
2011


Special
Requirements:
The journal that is passed is the receipt journal (RJ)
Assumptions: Customers have their own accounts

Use Case ID: UC-26
Use Case Name: Prepare Bank Deposit slip
Description: This use case is used to prepare bank deposit slips for cashes received through
cash sales invoice and receipts
Post-conditions: The system saves and displays a printable deposit slip
Normal Course:

1. The user selects Prepare Deposit Slip menu item from Accounting menu
2. The system displays the Deposit Slip Preparation Form along with the
automatically generated id
3. The user sets filter criteria and presses the Show button
4. The system displays all cash sales invoices and receipts that satisfy the
criteria, in their own panes along with a checkbox to their left
5. The user selects documents (cash sales invoices or receipts) to which the
user wants to prepare the deposit slip
6. The system displays the number of invoices and receipts that are selected
along with the total amount for each of the two categories and the grand
total amount
7. The user selects the account/s that should be affected and presses Prepare
button
Alternative
Courses:
11.7.1. The actual deposit is different from the grand total
1. The user enters the actual deposited amount
2. The system displays the difference and requests in which account to put
the difference
3. The user enters an account to hold the difference and presses Prepare
button
Exceptions:
Includes: Login, Manage Journal
2011


Priority: High
Special
Requirements:
1. A deposit may affect one or more accounts
2. The journal that is passed is the general journal
Assumptions:

Use Case ID: UC-27
Use Case Name: Manage incoming check
Description: This use case is used to register and manage checks that are received
Post-conditions: The check/s information will be saved
Normal Course:

1. The user points to Prepare Check submenu of the Accounting menu and
presses Incoming Check menu item
2. The system displays incoming Check Registration Form
3. The user selects or enters payer, reference, bank, branch, check number,
amount, due date and received date information and presses Save button
4. The system checks the validity of the data and saves put it in a Grid
5. Step 3 and 4 will be repeated until all incoming checks are registered
6. The user presses the Ok button
7. The system displays a confirmation message
Alternative
Courses:

Exceptions:
Includes: Login
Priority: High
Special
Requirements:
When this use case triggered from prepared receipt use case payer, reference
and amount fields will be filled automatically
Assumptions:

2011


Use Case ID: UC-28
Use Case Name: Manage account reconciliation
Description: This use case is used to check that the amounts of liquid assets you show in the
checkbook are identical to the account balance shown on your bank statement
as of a given time.
Post-conditions: 1. The system saves account reconciliation and displays a printable account
reconciliation report
2. The checked accounts will be removed from the Account Reconciliation
Form
Normal Course:

1. The user presses Account Reconciliation menu item from Accounting menu
2. The system displays Account Reconciliation Form
3. The user selects the account that is going to be reconciled, sets start date
and end date and presses the Show button
4. The system displays all issued (outgoing) checks and Bank Deposit Voucher
(BDV) made on the selected account with a check box to their left
5. The user enters beginning statement balance, referring the bank statement
document, will review each of the entries and verify by pressing check
boxes
6. The system displays the summary of Outstanding checks, Deposit In
Transit, GL Balance and Un-reconciled Difference
7. The user presses the Ok button
Alternative
Courses:

Exceptions:
Includes: Login
Priority: High
Special
Requirements:

Assumptions:

2011


Use Case ID: UC-29
Use Case Name: Manage Journal
Description: This use case is used to view, modify or post any one of the five journals (GJ,
DJ, SJ, RJ, and PJ)
Post-conditions: The General Journal entry document is save into the database
Normal Course:

1. The user chooses General Journal menu item from the Accounting Menu
2. The system displays the Journal Form along with the general journal flag,
period, date, machine name, user name, etc
3. The user selects account numbers and enters credit and debit values and
presses Post button
4. The system will check the validity of the new entry, saves the data and
displays a confirmation message
Alternative
Courses:
14.1.1. The user presses View Journal button from any of the journal voucher
preparation form
1. The system displays the Journal Form along with the journal flag, account
number, period, reference, date, machine name, user name, the debit
value, and the credit value
2. The user may modify the journal content and presses Post button
3. The system will check the validity of the new entry, saves the data and
display a confirmation message
Exceptions: If the debit and credit information that is inserted is not balanced, the system
will display an error message and will not save the modification until it is
corrected
Includes: Login
Priority: High
Special
Requirements:
1. The system must be intelligent enough to affect the appropriate accounts
as a journal voucher is created
2. In the case of a journal that is triggered by the View button, the system
should fill every thing that is required for the journal and let the user to
modify the journal
Assumptions:

2011


Use Case ID: UC-30
Use Case Name: Close Accounting Period
Description: This use case is used to save the exact balance accounts at the end of a given
period i.e. it prepares and saves the trial balance for a given period
3. The beginning balance of each of the accounts is properly set
Post-conditions: The account balance of each of the accounts at the given period will be saved
in the database
Normal Course:

1. The user presses Close Period menu item from Accounting menu
2. The system displays Period Closing Form
3. The user sets the period and presses the Close Period button
4. The system will close the period and displays a confirmation message
Alternative
Courses:
4.
Exceptions:
Includes: Login
Priority: High
Special
Requirements:
3.
Assumptions:

2011


4.3.2.1. Use Case description for Production System
In the Production system Ten Use cases are identified. The following list describes each of the use cases
briefly:
1. MaintainProductionRequest This use case is used for making a production
request
2. ConfigureProduction This use case is implemented for configuring
Production
3. ProductionOrder This use case is implemented for Making a
production order
4. BatchVoucher This use case is implemented for making a batch
voucher for products that are manufactured in
batch.
5. MaintainBudget This Use case is implemented for maintaining
budget for all productions.
6. Maintain Production This use case is used for maintaining production
7. Packing List The use case is used for making a packing list for
each and every production
8. ProductionTransfer The Use case is used for making Production
Transfer from the production department to the
respective place
9. ProductionPlanning
10. Production Process

2011


Use Case ID: UC-31
Use Case Name: Maintain Production
Actors: Marketing Department representative, System Admin
Description: The use case is used for maintaining product attributes for production in the
System.

Post-conditions: Production processes such as product family, Lot size, Production operation,
formulation definition, effort requirement) of a product will be saved.
Normal Course:

1. The user press maintain production from the production main menu
2. The system display the maintain production form
3. The user Enter the appropriate data of production to each of the Tabs
available in the form
4. The user press save button
5. The system display Production maintenance is successfully saved
Alternative
Courses:

Exceptions:
Includes: Login
Priority: High
Frequency of Use: Once in three Month
Special
Requirements:
1. The system is intelligent enough to know while the user tried to save a
product that is not maintained in the Database.
Assumptions:

2011


Use Case ID: UC-32
Use Case Name: Manage production request
Actors: Marketing Department Representative, Management, Store keeper
Description: This use case is implemented to manage production request from Marketing
Department.

Post-conditions: A production request form will be prepared and become available for the
authorized management approval
Normal Course:

1. The user presses production request form the production menu.
2. The System displays the production request form.
3. The user fill the production request properly and press the Save button
4. The system Displays the production request is successfully saved
Alternative
Courses:

Exceptions:
Includes: 1. Login
2. Store Request
Priority: High
Frequency of Use: Every other three Days
Special
Requirements:
1. The need of the users shall be found
Assumptions:

2011


Use Case ID: UC-33
Use Case Name: Maintain Production Configuration
Description: This use case is implemented for configuring the production system.
Preconditions: 1. The user successfully Logged in
2. The ERP main window is displayed
Post-conditions: The production subsystem is manually configured in accordance to the
enterprise work organization.
Normal Course:

1. The user press production setting in the setting menu
2. The system display the production setting form
3. The user selects/enters his option in the form and press save button.

Alternative
Courses:

Exceptions:
Includes: Login
Priority: High
Frequency of Use: Once in three month
Special
Requirements:
The user must first know the company Production process and procedure
before setting the production system.
Assumptions:

2011


Use Case ID: UC-34
Use Case Name: Maintaining production order
Actors: Production department, Management, Store keeper
Description: This use case is implemented for maintaining a production order f
Post-conditions: A production order will be prepared and transferred into production
department.
Normal Course:

1. The user presses a production order from the production menu
2. The system display the production order interface
3. The user enter the production order form properly and press save button
4. The system save the data and make the order available for the production
department.
Alternative
Courses:

Exceptions: None
Includes: Login
Priority: High
Special
Requirements:
Production order shall only be produced when it is approved by the
Management
Assumptions:

2011


Use Case ID: UC-35
Use Case Name: Manage batch voucher
Actors: Production Department
Description: This use case is implemented to manage a batch voucher for every production
that happens at one group.
Post-conditions: A batch voucher will be issued for products that are produced at the same
group.
Normal Course:

1. The user Press the bath voucher from the production menu
2. The system display the batch voucher interface
3. The user fill the batch products produced at the batch voucher and press a
save button
4. The system save the voucher in the database and make the voucher ready
to be printed.
Alternative
Courses:
1.
Exceptions:
Includes: Log in
Priority: High
Frequency of Use: Every other three days
Special
Requirements:
A product shall be produced for this voucher to be issued
Assumptions:

2011


Use Case ID: UC-36
Use Case Name: Manage Production process
Description: This use case is implemented for managing a production process in the
enterprise
Post-conditions: This use case is implemented for managing a production process.
Normal Course:

1. The users press the production process from the production Menu.
2. The system display the production registration form
3. The user enter the production process properly in a way that can be
populated in journal and press the save button
4. The system save the production process in the system
Alternative
Courses:
2.
Exceptions: none
Includes: login
Priority: Medium
Special
Requirements:
None
Assumptions:

2011


Use Case ID: UC-38
Use Case Name: Manage Production Transfer
Actors: Production Department, store Keeper
Description: This use case is implemented for holding information about each production
transfer from the production department.
Preconditions: 1. The user successfully logged in
2. The ERP main window displayed
3. There shall be a production that is finished
Post-conditions: A product will be transferred from a production department to specific stock or
mobile sells places.
Normal Course:

1. The user presses production transfer from production menu.
2. The system display the product transfer voucher with its attributes
3. The user fill all the datas properly and press save button
4. The system save the voucher and transfer the product to the specific place
where the store voucher is given
Alternative
Courses:

Exceptions:
Includes: Login
Priority: High
Frequency of Use: Every other three days
Special
Requirements:
1. Store transfer voucher is only given for store keepers of a store or a mobile
sells.
Assumptions:

2011


Use Case ID: UC-39
Use Case Name: Manage Production Planning
Actors: Production Department, system Admin
Description: This use case is implemented for maintaining a production plan in the system.
Preconditions: 1. The user must successfully logged in
2. The ERP window must be displayed
Post-conditions: A production plan will be maintained that can be used for further production
Normal Course:

1. The user presses production planning from production menu
2. The System display a production planning form
3. The user fill the appropriate production plan which is professionally agreed
in each tabs that are maintained in this Tab.
4. The System save the document and will be on until changed.
Alternative
Courses:

Exceptions:
Includes: Login
Priority: High
2011


Use Case ID: UC-40
Use Case Name: Maintain Budget
Description: This use case is implemented for maintaining budget for every production that
is requested by the marketing department.
Preconditions: 3. The user must successfully logged in
4. The ERP window must be displayed
Post-conditions: A production plan will be maintained that can be used for further production
Normal Course:

5. The user presses production planning from production menu
6. The System display a production planning form
7. The user fill the appropriate production plan which is professionally agreed
in each tabs that are maintained in this Tab.
8. The System save the document and will be on until changed.
Alternative
Courses:

Exceptions:
Includes: Login
Priority: High
Frequency of Use: Once in three month
Special
Requirements:

Assumptions:

2011


2.4. Operating Environment
Describe the environment in which the software will operate, including the hardware
platform, the operating systems and versions, and the geographical locations of users,
servers, and databases.
OE-1: The ERP software shall operate in all visual basic.net frame work softwares.
OE-2: The ERP software shall be managed from the global CNET server and an Abyssinia Main
server
OE-3: The ERP software shall permit user access from the corporate Intranet and, if a user is
authorized for outside access through the corporate firewall.
OE-4 The System shall able to be maintained in a licensed Computer where it have still time
but aborted

2.5. Design and implementation constraint
Describe any factors that will restrict the options available to the developers and the rationale for each
constraint. Constraints might include the following:
Specific technologies, tools, programming languages, and databases that must be used or
avoided.
Restrictions because of the product's operating environment, such as the types and versions of
Web browsers that will be used.
Required development conventions or standards. (For instance, if the customer's organization
will be maintaining the software, the organization might specify design notations and coding
standards that a subcontractor must follow.)
Backward compatibility with earlier products.
Limitations imposed by business rules (which are documented elsewhere
Hardware limitations such as timing requirements, memory or processor restrictions, size,
weight, materials, or cost.
Existing user interface conventions to be followed when enhancing an existing product.
Standard data interchange formats such as XML.
Our group find the following constraints for the implementation of an ERP
1. It is to be installed on the existing infrastructure with some modification to accommodate
specific requirement for the new system;
2. All stake holders in Abyssinia shall be given a privilege to utilize the system in their respective
accordance.
3. Each and every modifications made shall be found in the log file.
Underlining the stated factors we found the below mentioned design and implementation constrains
are worth considering.
2011


CO-1: Must be interoperable and easily integrate with the available other systems (IF any)
CO-2: The system's design, code, and maintenance documentation shall conform to the UML
object oriented programming Procedures
CO-3: The system shall use the current corporate standard SQL database engine.
CO-4: All the software shall be able to be displayed in every computer that have V.net and
Sql with easy modification.
CO-5: All codes shall be written in VB.net 2005 having a compatible Database SQL
CO-6: Shall assume two-way authentication for each transaction to avoid unauthorized
transfer of electronic value.
CO-7: Shall have fraud detection and reporting capability sufficient enough to detect fraud.

2.6. User Documentation
User documentation lists the user documentation components that will be delivered along with
the executable software. These could include user manuals, online help, and tutorials. Identify
any required documentation delivery formats, standards, or tools.
The User Documentation for ERP system of Abyssinia is expected to align to IEEE standard 1063:
Software User Documentation Standards. The following User Documentations are considered.
Promotional slides and training materials will be distributed to all stake
holders
User manuals prepared to train different user classes on how to use the
system successfully.
Video and manual tutorials will be distributed to all stakeholders that
access the system.
Setting and synchronization mechanism manual will be prepared
The system shall provide an online hierarchical and cross-linked help
system in HTML that describes and illustrates all system functions
The first time a new user accesses the system and on user demand
thereafter, the system shall provide an online tutorial to allow users to
practice how the user access every microfinance information and their
status . The system shall not allow public to edit or delete files or datas
only allow them to send comment.
2011


2.7. Assumption and dependency
An assumption is a statement that is believed to be true in the absence of proof or definitive
knowledge. As well dependencies are the projects external factors outside its control.
AS-1- Great Abyssinia P.L.C shall make ready a networked LAN Environment in all office
that utilizes the ERP System.
AS-2 Simple Accounting transactions such as Journal will be easily navigated/ populated
out of the System.
AS-3 The system ease the workload in the enterprise employees for counting ,making
journal, checking balance etc.
AS-4 Up to Date information will be retrieved by the stakeholders
AS-5 The System enables the managers to see the competitiveness of their product in
the market. They can compare the market request based on months, week and
days.
AS-6 The ERP system eliminates a time misuse and over production in the enterprise.
AS-7 The new system will improve productivity by reducing traveling time, better
communication, improved customer service/ short response time/ and cost
reduction/ saves time and money/.
DE-1 The ERP system must able to be utilized in a Dial up connection with on way
bandwidth
DE-2 All stakeholders will be trained to use the system with reliable affection.

2011


Chapter Three
System Features
3.1. System features of the Sales Subsystem
3.1.1 Enable the user to prepare a sales order
Description and priority
The system enables the sales person (Mobile sales, Egziaherab warehouse sales, Sululta
branch sales) to prepare a sale order based on the request form any client. This
Feature will be done every other day. Therefore, this Feature in the sales system is
taken as high priority.
3.1.2 Enable users to receive sales pay with different sales invoices.
The system enable a sales person to receive sales payments in two kinds of invoices namely cash and
credit invoices. For every sales that is made every other day there exists either a cash sales or credit
sales payment. Therefore, this Feature is implemented as high priority.
3.1.3 Prepare consignment sales note
Description and Priority
The system enables the sales person (Egziaherab Sales, Sululta sales) to prepare a consignment sales
note for every product given with a consignment. This Feature is implemented as a medium priority.
3.1.4 Prepare consignment return invoice
The system enables the sales person (Egziaherab Sales, Sululta sales) to prepare a consignments sales
return invoice when ever a sale that is made with consignment is returned from the consignee. This
Feature is also a medium priority for the System.
3.1.5 Prepare sales return invoice
The system enables the sales person to prepare a sales return invoice to its client when ever the return
is approved by authorized personnel. This Feature is a high priority for the fact that there exists a chance
for sales return.
2011


3.2. System Features of warehouse subsystem
3.2.1. Perform a store request
The system enables store personnel to prepare a store request when ever a store passes its minimum
limit to hold the product. This Feature is taken as a high priority for the fact the store shall be
guaranteed to request a product which has demand by the market but not found in its limited value at
the store.
3.2.2 Enable to perform store Request approval
The system enable authorized personal, Management to make a store request approval any time when
a request comes from store personnel. This feature implementation is also a high priority.
3.2.3 Enable to prepare a purchase request form
The system enables the store personnel to prepare a purchase request form. This Feature is taken as
high priority for the fact that there always exists a purchase request when ever a product in the ware
house is limited.
3.2.4 Enable to prepare Purchase order
The System also enables the store personnel to prepare a purchase order when ever there exist a need
for a purchase. This Feature is taken as a high priority.
3.2.5 Enable to make a Purchase order approval
The system enables authorized personnel, management to approve a purchase request that is requested
by the Store keeper. This Feature is taken as a high priority.
3.2.6 Enable to prepare a store issue voucher
The system enables a store keeper to prepare a store issue voucher. A store issue voucher will be
prepared when ever a store is requested for any product or raw material.
2011


3.2.7 Enable to prepare a delivery order voucher
The system enable the store keeper to prepare a deliver order voucher to a personnel that takes a
delivery from the store to the specific palace.
3.2.8. Enable to make a store transfer voucher
The system enables the store keeper to prepare a store transfer voucher from the store to another
store. This voucher will not have any effect in the Store. This Feature is also a high priority for the fact
that Abyssinia has more than two warehouses.
3.2.9 Prepare different types of goods receiving vouchers
The system will have the ability to prepare different types of good receiving vouchers namely Cash GRV,
Credit GRV, Dispensary GRV and Consignment GRV. A GRV will be used when a ware house sales a
product. We took this Feature as high priority for the fact that All Abyssinia stores will sale product
when ever necessary.
3.2.10 prepare a supplier return voucher
The system enable the store keeper to prepare a supplier return voucher when the supplier return is
approved by an authorized personnel. This Feature is taken as a medium priority because the frequency
for this Feature existence is low.
3.2.11. Enables to prepare a consignment supplier return
The System enable a store keeper to prepare a consignment supplier return voucher and return the
product to the supplier. This Feature is also taken as a medium priority.
3.2.12. Enable to make a disposal Voucher
The system enables store personnel to make a disposal voucher for those disposed products in the
store. This Feature is a high priority for the fact that a disposed product should be removed quick before
it damage a user.
2011


3.2.13 Enable to make a stock adjustment
The system enables the store personnel to make a stock adjustment any time when ever the stock
adjustment is necessary. This Feature is taken as a medium priority.
3.2.14 Enable to save an inventory count
The System enables the Store personnel to make and save an inventory count. This Feature is taken is a
high priority for the fact that it is necessary to an inventory to Know it balance any time.
3.2.16 Enable to update stock
The system enables the store personnel to update stock when ever an item/Product is moved or
entered to the ware house. This Feature is taken as a high priority.

2011


3.3 Accounting Sub System
3.3.1. Make a payment order

3.3.2 Prepare Bank Payment Voucher
The system enables the accountant to prepare a bank payment voucher. This Feature is taken as a high
priority Feature.
3.3.3 Prepare pity Cash Payment Voucher
The System enables the cashier to prepare a pity cash payment voucher. This Feature is taken as a high
priority Feature.
3.3.4 Prepare incoming and outgoing check
The System enables the cashier to prepare incoming and outgoing check. This Feature is also
implemented as a high priority Feature.
3.3.5 Prepare cash receipt Voucher
The System enables the cashier to prepare a cash receipt voucher when ever cash is received from
another source. This Feature is also implemented as a high priority Feature.
3.3.6 Prepare I owe you voucher
3.3.7 Prepare a bank deposit
The system enables the cashier/ accountant to prepare a bank deposit slip electronically. This Feature is
also implemented as a high priority Feature.
2011


3.3.8 Prepare Bank advice
3.3.9 Prepare General Journal
The system enables an accountant to prepare a general journal electronically from the system in a
parameter he wants the general journal to be displayed. This Feature is a medium priority though it
needs to be implemented soon.
3.3.10 Prepare account reconciliation
The system enables the accountant to check that the amounts of liquid assets you show in the
checkbook are identical to the account balance shown on your bank statement as of a given time. This
Feature is implemented as a medium priority.
3.3.11 Perform period closing
Descriptions and Priority
The system enables the accountant to save the exact balance accounts at the end of a given period i.e. it
prepares and saves the trial balance for a given period. This Feature will be high priority.
3.3.12 Prepare Budget
The system enables the accountant to set the budget amount of each of the expense accounts will be
set and a printable budget report will be displayed. This Feature will be implemented as a high priority.
3.3.13 Prepare chart of account
The System enables the accountant to prepare a chart of account is created and a printable account tree
is displayed. This feature will be implemented as a high priority.
3.3.14 Prepare Beginning Balance
2011


The system enable the accountant to maintain beginning balance of each of the accounts will be set and
a printable beginning balance report will be displayed. This Feature is implemented as a high priority.
3.3.15 Enable to make a fixed asset management
The system enables the accountant to manage the fixed assets that are available in the enterprise. This
feature will be implemented as a high priority.
3.3.16 Enable to Prepare fixed asset maintenance.
The system enables a cashier or an accountant to record a new fixed asset and/or to modify an existing
one. This feature will be implemented as a high priority.

2011


3.4 System Features of the Production Subsystem.
3.4.1. Enable to maintain production
The system enables the production department to maintain a number of production Lists. This feature is
implemented as a high priority for the fact that for any production activity in the system production
maintenance shall be performed.
3.4.2. Prepare a production report form
The System enables the production department representative to prepare a production report form.
This feature is a high priority.
3.4.3. Prepare a production order
The system enables the management to approve and prepare a production order to the production
department representative. This feature is also a high priority.
3.4.4. Make a batch voucher
The system enables the production department to make a batch voucher for productions that are made
in one group.
3.4.5. Enable to maintain a production request
The system enables the marketing department representative to make a production request. This
feature is also implemented as a high priority.
3.4.6. Enable to maintain a packing list
The System enables the production department to maintain a packing list for every production that is
made in the factory. This feature is a medium priority.

2011


3.4.7. Enable to make a production transfer
The system enables the production department representative to make a production transfer from a
production department to the respective warehouse. This feature is high priority.
3.4.8. Enable to make a production planning
The system enables the production department to make a production planning. This feature will be
implemented as a high priority.
3.4.9. Enable to make a production process
The System enables the production department representative to save a production process in the
system so that production of a specific product will be done in that format

2011


Chapter Four
External interface requirement
4. External Interface Requirement
External interface requirements specify hardware, software, or database elements with which a
system or component must interface. This section provides information to ensure that the system
will communicate properly with external components.

4.1. User Interfaces
Describe the logical characteristics of each user interface that the system needs. The Information
sharing system will have easy user friendly interfaces. The interfaces in the system are briefly
described in the following table.
UI-1 The user interface need to be very simple to protect users from making errors by replacing text
boxes with list boxes and check boxes
UI-2 The accounting system user interface shall be used by an accountant professional who
understands each interface requirements.
UI-3 The user interface shall be systematically designed in a way that can be understood by clerk,
secretary, accountant, managers, Admin, Store keepers easily.
UI-4 To facilitate input an output operations Hardware devices such as barcode readers, Printers,
touch screens may be used with the sales subsystem.
4.2 . Hardware interface/Considerations
The hardware requirements of the system is very much dependent on the size of the data that a
given client company has. On the other hand, one of the major goals of the new system is to
develop a system that uses a hardware resource as minimum as possible. The following table shows
the minimum and recommended hardware requirements:
No Hardware Minimum Recommended
1 Processor Pentium III Pentium IV
2 Speed 600MHZ 1GHZ
3 RAM 512MB 1GB
4 Hard disk 10GB 20GB
2011


Table 2: Computer Hardware Requirements for the Accounting subsystem
There are also other requirements such as network interface card and modem. The modem is used for
activating the product and the network interface card is used for backup and interactions with other
parts nodes such as servers.
4.3 Software interface
The software shall be displayed in every computer that has VB.net 2005 and SQL 2000 with easy
modifications.
4.4 Communication interface
CI-1 The ERP system shall have a mechanism for navigating a writing process while the authorized
personnel logged in to the system
CI-2 The ERP system shall send a notification when a message is sent to a specific user class
CI-3 The ERP system shall send a notification when a message is properly delivered to a specific
user class
CI-4 The system shall able to work compatibly with EVDO and CDMA tools

2011


Chapter Five
Other Non functional requirement
This section specifies nonfunctional requirements other than external interface requirements,
which appear in section 3, and constraints, recorded in section 2.5. As well it also specifies the
required system quality factors that are not to the specific relational requirement documented in
the use case model.
3.1. Performance Requirements
Performance requirement states specific performance requirements for various system
operations. It also explain their rationale to guide the developers in making appropriate design
choices. It provides the legible functional requirements features which encompass performance
requirements.
The response time for retrieving cash values, while preparing BPV or PCPV from reference documents,
should not exceed a seconds.
The response time for retrieving customer, sales person, and item/product should not exceed 10
seconds. At the point of sales, the time to retrieve item/product information should not exceed 3
seconds. Parallel processing of sales must be possible.
The response time for retrieving supplier information, and item/product should not exceed 10 seconds.
When checking availability of inventory items, the time to process documents should not exceed 5
seconds.
The response time for retrieving Production order, and Production process should not exceed 5 seconds.
When maintaining production and Budget it should not exceed more than 4mins.
3.2. Safety Requirements
Safety and security are examples of quality attributes, which are more fully addressed in section
5.4. Weve called these two attributes out in separate sections of the SRS.
SA-1 The system shall terminate any operation within 5 seconds after notification if
the online network feels to do the functional requirements and shall try to
reboot and connect accordingly.
SA-2 The Database shall remain open through connection with the provided account,
but if it however crashes in the means of hacking or network it should boot with
a safe mode by attempts given be the system administrator.
SA-3 The system shall check if the resource provided to the Different stakeholders is
amendable and legal to the user classes.
2011


3.3. Security requirement
Specify any requirements regarding security, integrity, or privacy issues that affect access to the
product, use of the product, and protection of data that the product uses or creates. Security
requirements normally originate in business rules, so identify any security or privacy policies or
regulations to which the product must conform.
SE-1: All network transactions that involve financial information or personally
identifiable information shall be encrypted.
SE-2: Different Stakeholders shall be required to log in to the System for all
operations by supplying valid user credentials.

SE-3: The system shall permit only authorized employees to log in according to
the restricted computer system access policy.

SE-4: Stakeholders can only see the defined functional system by using through
their given account.

SE-5: The system shall permit Employees to view only requests related to their
own section or class of business.

Draft SRS Document For Great Abyssinia PLC

Uploaded by

Copyright:

Available Formats

Draft SRS Document For Great Abyssinia PLC

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Draft SRS Document For Great Abyssinia PLC

Uploaded by

Copyright:

Available Formats

ERP System Requirement Specification Document for

Great Abyssinia PLC.

You might also like