Retail Business Management System

BSC (Honours) Computing
Retail Business Management System

(RBMS)
for
Albert Butcher LTD
Design, development and implementation of complete end-to-end cross-platform solution
for small/medium business with HR, accounting, multi-warehouses stock and inventory
management system
By
Valentin Adamescu
Project unit: PJE40

Supervisor: Nadim Bakhshov
April 2019
Abstract
“The advance of technology is based on making it fit in so that you don't really even notice it, so it's part of everyday
life.”
~ Bill Gates
In contemporary society, in a very dynamic market the stock and inventories control are a key factor for any business
in order to maintain continuity and profitability in the operations in an efficient manner. Having an automated way to
overview and manage these operations is a huge advantage compared with manually solutions (e.g. pen and paper) or
semi-automatic (e.g. excel files). However, a business environment is not just stocks and sales but also accounting,
human resources, customers suppliers and many more sections, each one of them with their micro-environment. This
project is about the development of a business management. My goal for this project is to bring all aspects of a
small/medium retail business under one umbrella by developing a generic software with a minimal cost but maximum
efficiency. The system described in this document is a modular system, working as an autonomous homogeneous system
with online/offline capabilities, assuring an intuitive and easy-to-use graphical interface.
System Demo
http://uop.cloud
Note: For login credentials please contact my supervisor Nadim Bakhshov
Word count: 29655
Valentin Adamescu PJE40 - RBMS Page 1 of 105

UP872413 Retail Business Management System
Table of Contents
1. Introduction ................................................................................................................................................ 9
1.1 Overview............................................................................................................................................ 11
1.2 Aim and objectives ............................................................................................................................ 11
1.3 Current practice and problems ......................................................................................................... 12
1.4 Proposed solution.............................................................................................................................. 13
1.5 Tools, facilities and resources........................................................................................................... 14
1.6 Risk assessment ................................................................................................................................. 16
1.7 Legal, ethical, professional and social issues ................................................................................... 16
1.8 Initial remarks regarding the development of this project ................................................................ 17
2. Literature review ...................................................................................................................................... 18
2.1 Available systems .............................................................................................................................. 18
2.2 Programming Language ................................................................................................................... 20
ASP.Net ................................................................................................................................................... 21
PHP .......................................................................................................................................................... 21
Node.js ..................................................................................................................................................... 22
2.3 Database............................................................................................................................................ 22
MySQL .................................................................................................................................................... 23
PostgreSQL .............................................................................................................................................. 23
SQLite ...................................................................................................................................................... 24
MariaDB .................................................................................................................................................. 24
2.4 System architecture ........................................................................................................................... 25
Monolithic architecture ............................................................................................................................ 25
Space-based architecture (SBA) .............................................................................................................. 26
Client-server architecture (CSA) ............................................................................................................. 26
Service-oriented architecture (SOA)........................................................................................................ 26
Object-oriented architecture (OOA) ........................................................................................................ 27
2.5 Design Strategies............................................................................................................................... 27
3. Methodology ............................................................................................................................................ 29
3.1 Waterfall Model................................................................................................................................. 29
3.2 Agile Model ....................................................................................................................................... 29
3.3 Incremental Model ............................................................................................................................ 30
3.4 Rapid application development (RAD) Model .................................................................................. 31
3.5 Spiral Model ...................................................................................................................................... 32
3.6 Methodology decision ....................................................................................................................... 33
4. Project Management ................................................................................................................................ 35
5. Requirements ........................................................................................................................................... 36
5.1 User and business analysis ............................................................................................................... 37

5.2 User requirements ............................................................................................................................. 38
5.3 Functional system requirements........................................................................................................ 40
5.4 Non-functional system requirements ................................................................................................. 44
5.5 Assumption and dependencies........................................................................................................... 45
6. Design ...................................................................................................................................................... 46
6.1 Server architecture strategy .............................................................................................................. 46
6.2 System design .................................................................................................................................... 47
6.3 System UI mockups and high-fidelity prototyping ............................................................................ 52
6.4 Colours, Style and Icons.................................................................................................................... 56
6.5 Database Design ............................................................................................................................... 59
6.6 Development Programming Language and MVC Framework ......................................................... 62
6.7 Assumptions and Constraints ............................................................................................................ 63
7. Implementation & Testing ....................................................................................................................... 64
7.1 Project development environment setup ........................................................................................... 64
7.1 Project development modules............................................................................................................ 66
7.2 Coloured theme implementation ....................................................................................................... 72
7.3 Testing ............................................................................................................................................... 73
8. Evaluation ................................................................................................................................................ 78
8.1 System functionality........................................................................................................................... 78
8.2 Non-Achieved objectives and system flaws ....................................................................................... 79
8.3 Implementation Evidence .................................................................................................................. 80
9. Future Improvements ............................................................................................................................... 88
10. Conclusion ............................................................................................................................................ 89
Bibliography .................................................................................................................................................... 90
Appendix .......................................................................................................................................................... 93

List of Figures
Figure 1 - Albert Butcher business flow (Abstract) [Primary Source] .............................................................. 9
Figure 2 - Albert Butcher designs [Primary Source] ....................................................................................... 10
Figure 3 - Project development risk diagram [Primary Source] ...................................................................... 17
Figure 4 - in Flow Software installation error [Primary Source] ..................................................................... 18
Figure 5 - XERO Software trial account [Primary Source] ............................................................................. 18
Figure 6 - ZOHO Inventory trial account [Primary Source]............................................................................ 19
Figure 7 - User review (Brett, 2017)................................................................................................................ 20
Figure 8 - MVC Concept (Adapted from Reenskaug design) [Primary Source] ............................................. 20
Figure 9 -ASP.Net framework (Hanselman, 2013) ......................................................................................... 21
Figure 10 - Global percentage of server-side programming language (W3Techs, 2018) ............................... 21
Figure 11 - Databases ranking trends over the years (DB-Engines, 2018) ...................................................... 23
Figure 12 - A typical monolithic system [Primary Source] ............................................................................. 25
Figure 13 - Client-server architecture [Primary Source] ................................................................................. 26
Figure 14 - SOA architecture [Primary Source] .............................................................................................. 26
Figure 15 - Top-down vs Bottom-up [Primary Source]................................................................................... 28
Figure 16 - Waterfall Model [Primary Source]................................................................................................ 29
Figure 17 - Agile model [Primary Source] ...................................................................................................... 30
Figure 18 - Incremental Model [Primary Source]............................................................................................ 30
Figure 19 - Rapid application development [Primary Source] ........................................................................ 31
Figure 20 – Spiral model (Nutschan, 2008) ..................................................................................................... 32
Figure 21 - Project Timeline Microsoft Projects [Primary Source] ................................................................. 35
Figure 22 - Project estimated days and duration .............................................................................................. 35
Figure 23 – Client-server architecture (Abstract) [Primary Source] ............................................................... 46
Figure 24 – Conceptual level server architecture [Primary Source] ................................................................ 47
Figure 25 - Use case for Login module [Primary Source] ............................................................................... 49
Figure 26 - Use case for Logout module [Primary Source] ............................................................................. 50
Figure 27 - Use case for Registration process [Primary Source] ..................................................................... 51
Figure 28 - Login screen (LEFT); Registration screen (RIGHT) [Primary Source] ....................................... 52
Figure 29 - General settings screen [Primary Source] ..................................................................................... 52
Figure 30 - Products category list (LEFT); Create a new category (Right) [Primary Source] ........................ 53
Figure 31 - Products list where the user can see the entire available stock (LEFT); Add a new product to
system (RIGHT) [Primary Source] .................................................................................................................. 53
Figure 32 - Adding products to stock. (LEFT); Stock counting (Right) [Primary Source] ............................. 54
Figure 33 Suppliers list (LEFT); Create a new supplier (Right) ..................................................................... 54
Figure 34 - Group roles (LEFT); Group roles permissions matrix (RIGHT) [Primary Source] ..................... 55
Figure 35 – Expenses List (LEFT); Adding a new expense (RIGHT) [Primary Source]................................ 55
Figure 36 - High fidelity prototyping with Axure (Product List) [Primary Source] ....................................... 56
Figure 37 - Current system dashboard (Left); High fidelity prototyping with Axure (Right) [Primary Source]
.......................................................................................................................................................................... 56
Figure 38 - Albert Butcher front shop [Primary Source] ................................................................................. 56
Figure 39 - Most liked colours by men and women (Batagoda, 2017)............................................................ 57
Figure 40 - Theme base colours [Primary Source] .......................................................................................... 57
Figure 41 - General layout of the system – User List (Left); Sale list (Right) [Primary Source] .................... 57
Figure 42 - Font Awesome icons (https://fontawesome.com/icons?d=gallery&m=free) ................................ 58
Figure 43 - Sample of icons used into the projects .......................................................................................... 58
Figure 44 – Icons implementation example [Primary Source] ........................................................................ 58
Figure 45 - RBMS UML processing (Logic flow of the system) [Primary Source] ....................................... 59
Figure 46 - Databased design and creation with dbForge [Primary Source] ................................................... 60
Figure 47 – Final database ERD with PKs and FKs [Primary Source] ........................................................... 61

Figure 48 – Final database including PKs, FK and all attributes [Primary Source] ........................................ 61
Figure 49 - Laravel test code example [Primary Source] ................................................................................ 62
Figure 50 - XAMPP Local Server setup [Primary Source] ............................................................................. 64
Figure 51 - DB import into XAMPP................................................................................................................ 64
Figure 52 - Database creation and testing query [Primary Source] ................................................................. 65
Figure 53 - Laravel installation and connection to the database [Primary Source] ......................................... 65
Figure 54 - Routing with Laravel..................................................................................................................... 66
Figure 55 - Module creation pattern with PHP MVC [Primary Source] ......................................................... 67
Figure 56 - Controller file for Products [Primary Source] ............................................................................... 67
Figure 57 - View file for Products [Primary Source] ...................................................................................... 68
Figure 58 - Model file for Products [Primary Source] ..................................................................................... 68
Figure 59 - Add product function with user authorisation [Primary Source] .................................................. 69
Figure 60 - Final models, controllers and views of the system [Primary Source] ........................................... 69
Figure 61 - Naming convention of files and folders [Primary Source] ........................................................... 70
Figure 62 - Multilanguage Module [Primary Source] ..................................................................................... 71
Figure 63 - Language module HTML & Output [Primary Source] ................................................................. 71
Figure 64 - CSS Files ....................................................................................................................................... 72
Figure 65 - Style integration through HTML & PHP (Left); Front-end user view (Right) ............................. 72
Figure 66 - Setting test unit with Katalon Studio – New Project (Left); Project default setup (Middle); Added
test units for RBMS (Right) [Primary Source] ................................................................................................ 73
Figure 67 - Login test case [Primary Source] .................................................................................................. 74
Figure 68 - Test case for Settings (save and record to the database) [Primary Source] .................................. 75
Figure 69 - Chrome Browser 'Developer Tools' [Primary Source] ................................................................. 75
Figure 70 - Page load performance test (Left); Login View point (Right) [Primary Source] ......................... 76
Figure 71 - Different stages of mobile phone testing [Primary Source] .......................................................... 76
Figure 72 - Client feedback email .................................................................................................................... 77
Figure 73 - Creating the user manual [Primary Source] .................................................................................. 80
Figure 74 - Login, User List, User Role, Role Permissions; Language; Settings [Primary Source] ............... 80
Figure 75 Product list; Product Details; Barcode [Primary Source] ................................................................ 81
Figure 76 - Stock Management; Stock Count; Quantity alert [Primary Source] ............................................. 81
Figure 77 - Add a new customer (Left); Add a new supplier (Right) [Primary Source] ................................. 82
Figure 78 - Customers List (Left); Suppliers List (Right) [Primary Source] .................................................. 82
Figure 79 - VAT Tax & Sale Units.................................................................................................................. 82
Figure 80 - Purchase List (Top); Sale List (Bottom) [Primary Source] .......................................................... 83
Figure 81 – Expenses List (Top); Expenses Categories (Bottom-Left); Add Expense (Bottom-Right)
[Primary Source] .............................................................................................................................................. 83
Figure 82 - Account (Top); Account balance sheet (Middle); Account statement (Bottom) [Primary Source]
.......................................................................................................................................................................... 84
Figure 83 – Employees List (Top); Attendance Recording (Middle); Departments (Bottom) [Primary
Source] ............................................................................................................................................................. 85
Figure 84 - Products report (overview) [Primary Source] ............................................................................... 86
Figure 85 - Monthly sale report [Primary Source]........................................................................................... 86
Figure 86 - Custom dates sales report [Primary Source] ................................................................................. 86
Figure 87 – Custom dates summary report [Primary Source] ......................................................................... 87
Figure 88 - Graphic chart report [Primary Source] .......................................................................................... 87
Figure 89 - Best sale report [Primary Source] ................................................................................................. 87
Figure 90 - Use case for Settings module ........................................................................................................ 94
Figure 91 - Use case for Warehouse module [Primary Source] ...................................................................... 95
Figure 92 - Use case for user Permission Matrix module [Primary Source] ................................................... 96
Figure 93 - Use case for Product Module [Primary Source] ........................................................................... 97
Figure 94 - Use case for Purchase modules (Add to stock) [Primary Source] ................................................ 98
Figure 95 - Use case for Sale module [Primary Source] ................................................................................. 99
Figure 96 - Use case for Expenses module [Primary Source] Note: The diagram represents the entire
Expenses module, were UC is to add an expense to the module ................................................................... 100
Figure 97 - Use case for Accounting module [Primary Source] (Note: The diagram represents the entire
Accounting module, were UC is to add an account to the module ................................................................ 101
Figure 98 - Use case for Stock Counting module [Primary Source] ............................................................. 102

List of tables
Table 1 - Summary of business process [Primary Source] .............................................................................. 13
Table 2 - Programming Language vs Scripting Language [Primary Source].................................................. 20
Table 3 - Node.js files request handling vs PHP/ASP [Primary Source] ........................................................ 22
Table 4 - Comparison summary of databases .................................................................................................. 25
Table 5 - Software design activities (adapted from “Software Engineering: A Methodical Approach”, by E.
C. Foster 2014, p226)....................................................................................................................................... 27
Table 6 - Waterfall model advantages and disadvantages [Primary Source] .................................................. 29
Table 7 - Agile model advantages and disadvantages [Primary Source] ......................................................... 30
Table 8 - Incremental model advantages and disadvantages [Primary Source] .............................................. 31
Table 9 - RAD model advantages and disadvantages [Primary Source] ......................................................... 32
Table 10 - Spiral model advantages and disadvantages [Primary Source] ...................................................... 32

List of appendices
Appendix A - Frameworks comparison table .................................................................................................. 93
Appendix B – Use case (Settings) ................................................................................................................... 94
Appendix C – Use case (Warehouse) .............................................................................................................. 95
Appendix D - Use Case (Permissions)............................................................................................................. 96
Appendix E - Use Case (Products) .................................................................................................................. 97
Appendix F - Use case (Purchase) ................................................................................................................... 98
Appendix G - Use Case (Sale) ......................................................................................................................... 99
Appendix H - Use Case (Expenses) ............................................................................................................... 100
Appendix I - Use Case (Accounting) ............................................................................................................. 101
Appendix J - Use Case (Stock Counting) ...................................................................................................... 102
Appendix K - Server Architecture (Large) [Primary Source] ....................................................................... 103
Appendix L - Test cases root explorer ........................................................................................................... 104
Appendix M - Project Timeline ..................................................................................................................... 105

1. Introduction
This project report tells the story of the development and implementation of a comprehensive retail business
management system for a client. The client is Albert Butcher Ltd.
Albert Butcher is a small/medium size business based in Portsmouth, founded in early 2017, but growing very
fast. Their main activity is divided between selling wholesale fresh meat and meat products (specially pork
and beef) to local supermarkets, hotels & restaurants and retail of meat products along with other general
groceries products (fruits, vegetables, frozen products, alcohol & non-alcohol drinks, canned products, etc.).
The current retail shop is based in Portsmouth but the business has an active plan to extend to Cosham &
Havant sometime in autumn of 2019 with two more groceries shops. For the near future they are hoping to
extend their retail activity to include clothing and digital products. Albert Butcher Ltd currently has 6 staff
members with various cultural and linguistic backgrounds. The business owner acts as general manager. With
the plan in place to open new locations the total number of employees would increase to a possible 15 with an
additional manager and a dedicated accountant.
In the first few months of the business the client used a system made from Microsoft Excel as the stock
inventory management tool and a free software for basic accounting. For a short time, this solution met the
business needs. However, the client did not anticipate the rapid development and success of the business. The
system was not properly equipped to manage the increase of stock related activity. Furthermore, he struggled
with the impact this had on the supply chain.
The current business flow management is based, as stated above, on a combination of spreadsheets (to keep
track of their in/out orders), notes in a physical notebook with conventional pen and paper and a free version
of ZipBooks accounting software (https://zipbooks.com). For the client it has become very difficult to manage
the business and keep track of all sales, suppliers, customers stock inventory and so on. Prior to my
engagement, the client tried a number of methods to simplify the processes but all of them proved to be
inefficient, overcomplicated, very expensive and/or did not have all the features and flexibility that business
required.
A basic representation of the current business workflow can be seen in Figure 1. Further information and
details about their current practice and the problems will be presented in section 1.3 of this document.
Figure 1 - Albert Butcher business flow (Abstract) [Primary Source]

The initial idea of this project was to develop a bespoke inventory and stock management system to satisfy
the company new business needs. However, as the requirements, technical development and design began it
became rapidly clear that further effort and potentially significant long-term gains, I could develop a generic
solution which was customised for this client and therefore reusable and adaptable for other similar clients.
My personal relationship with the business began in 2016. I was asked to
create all branding graphic designs for the business (logo, shop fascia
sign, banners, window decals, price tags, loyalty card, some products
labels, flyers, and more - Figure 2). In the spring of 2018, the business
owner contacted me. He asked me to help him find a solution that would
improve their current business management practices. He told me that
current practices had become overwhelming and prior solution did not
work any longer.
In my initial discussions with the client we discussed the following
features (summary):
• Simple enough to be learned by non-technical users but also

very robust. Figure 2 - Albert Butcher designs [Primary
• Stock management (in/out of the products) Source]
• Individual warehousing (multi-shop support for the new locations they will open)
• Record sales
• Generate invoices
• A contact list for suppliers and regular customers (for wholesale and for retail)
• Not internet dependent
• Romanian language interface
Based on the idea that I should strive to develop a generic model which other companies could use I found
that this initial list could be expanded into the following:
• Low stock alert of a particular product

• Automatic stock counting
• Automatic calculation of total prices (for purchases and sales)
• Record expenses
• Basic accounting (income to business, expenses, staff payment, weekly/monthly/yearly turnover)
• Different reports about business income and expenses, profit loss ratio, available stock, understock
products.
• Cross-platform (can be accessed through tablet/mobile devices)
• Multilanguage system (some employees are not native English speakers)
This took a challenging problem and increased its complexity. The initial idea was transformed so that the
system specification became more sophisticated and required some separation between bespoke customisation
for the current client and the specifications for the generic model. Despite having other university related
deadlines and commitments, I pushed the boundaries and went beyond being a relatively complex but
manageable project. Hence, I believe I managed to create not only a bespoke system for the client but by
integrating additional features into the system, I developed a generic model suitable for any other retail
business.

In the remainder of this chapter I will present an introductory view of the project with the following sections:
1.1 - Overview of the subject and why having such system is essential in a retail business
1.2 - Description of the aims and the objectives of the project
1.3 - Description of the current practice and the problems faced by the client
1.4 - A broad description of the proposed solution
1.5 - A brief description of the tools, frameworks, software and development environment used for this
project
1.6 - An analysis of the risk assessment considered for this project
1.7 - A brief analysis of the potential legal, ethical, professional and social issues that may arise with this
project
1.8 – A brief explanation of the project approach and the decision that led to extent the project and intention
to create a bespoke system for the client but also a generic model.
1.1 Overview
For almost any retail business having a manageable internal control system of their inventories, expenses and
income is one of the most important aspects of business workflow (Ballou, 1997). In order to meet customers’
demands in an efficient way a business must be able to manage the whole supply chain. Having an oversight
of what products are available in the warehouse at any point will help to: ensure stock rotation; lower the
costs; minimise wastage; avoiding of unnecessary stockpiling or the opposite as stockouts; reduce risks of
losing goodwill; better accounting.
These requirements are even more critical to the performance of the business if the business has multiple
locations with different stocks and separated expenses. Even for a small business is difficult to hold an
inventory with a classic pen and paper method, using spreadsheets or taking advantages of free software such
as ABC Inventory (Almyta Systems, n.d) or Odoo Inventory (Odoo, n.d.). For medium to large business these
methods would be totally inefficient. Having multiple locations (e.g. multiple stores or warehouses) is more
difficult to track the changes in inventories and have an accurate overview over the whole stock. Most of the
free solutions are coming with restrictions of usage and/or limited to only one user or covers only some aspects
of the business requirements (e.g. just stock inventory or just accounting). Maintaining the equilibrium
between supply and demand is one of the factors for a successful stock management, but having all tools
required to manage the business into the same system is the key of a successful business.
1.2 Aim and objectives
The objective of this project is to develop and implement a system that will help the business to efficiently
manage their workflow using information technology. The aim of the proposed system is to solve the problems
occurred from current manual system. A secondary aim is for this customised tool to tackle the lack of
efficiency, the mixed-up solutions and the low level of security. This solution will help the business to
maintain the productivity, efficiency and profitability.
▪ Main objective
o To design, develop and integrate a general model software suitable for any small/medium
retail business
▪ Primary objectives:
o To create a bespoke system for the client covering the required aspects of the business

o To simplify user work process by providing high functionality system
o To provide an automated reporting function
o To reduce the administration time
▪ Secondary objective
o To add extra functionality and minimise the costs for the business
o Reduce the use of paper in record keeping
1.3 Current practice and problems
In this section I will discuss in depth the business current practice and problems following the brief
introduction.
One of the main drawbacks of the current practice is the lack of efficiency, mixed up documentation and data
loss. Furthermore, for the business owner it is very difficult to keep track of the sold products at the end of the
day, week or month and calculating the remaining stock is a real challenge. Human errors are very frequent
and searching for a specific product details, past orders or a specific supplier is a time-consuming task.
Frequently, the business ended with an overstock for some products where others were understock.
Another aspect that must be highlighted as a major problem is the low level of security. Without a
computerised system protected by a user name and password in place, all the business customers and suppliers’
details are virtually accessible to any employee. Any staff member could access the details and create a copy
for their personal needs.
For a clearer understanding of the business workflow I have constructed a table that separates the purchase
process, wholesale process and in shop retail process. I have additionally included the aftersales process and
the accounting of the business.
Albert Butcher (AB) LTD business process

1. Purchase Process 2. Wholesale Process 3. In shop retail process
▪ AB estimates what product/s they ▪ AB receives an order request from a ▪ Customer walks-in and purchases
have in stock customer product/s from the shop
▪ Search for a supplier/producer that ▪ Manually verifies if they have the ▪ Customer pays by cash or card
have the specific product required products in stock ▪ The cash sale is registered through a
▪ Regular suppliers can be found noted ▪ If they have, they fulfil the order Casio SE-S3000MB-SR cash register
into an Excel file ▪ If they do not have the required ▪ The card payment is processed through
▪ If they need a supplier that is rarely product/s they initiate a purchase from a POS
used, a search through the physical their own suppliers ▪ Sales Assistant makes a note into a
notebook, excel spreadsheet, past ▪ AB generates the invoice for the notebook of the sold product/s
invoices or personal phone address customer (through ZipBooks software)
book is required ▪ When the order is ready for delivery,
▪ An order is placed to the supplier or they notify the customer
producer over phone (or website) ▪ The order is delivered to the customer
▪ Supplier provides a delivery date, the (sometimes they use own
total cost of the order transportation, sometimes they use a 3rd
▪ The client pays for the order party specialised transport company)
(sometimes the order is paid in ▪ The customer receives the order and the
advance and sometimes after delivery; payment is made (usually the payments
payments are made by cash, are made in bulk (for several orders) at
credit/debit card or cheque) the end of the month by most clients
▪ Products arrive (payment is made if is ▪ Payments are made by cash, bank
not already done) transfer, cheque – very rare by
▪ Products are inserted into Excel file debit/credit card
(product, purchased price and
quantity)
After sale process and accounting management
▪ At the end of the day the sold products are manually deducted from stock (based on invoices, receipts
from cash register and sale assistant notes)

▪ This process is taken again on weekly bases (summing the week in/outs) and then monthly
▪ On weekly basis the income is noted into ZipBooks software
▪ On monthly basis the total purchases, income, expenses (profit/loss) is calculated partially with
ZipBooks software, partially manually
▪ At the end of the financial year they are passing a summary of the accounting calculations to an
accounting company
Table 1 - Summary of business process [Primary Source]
The business deals with two aspects of sale process (wholesale and shop retail). Both sales have different
types of clients, VATs, percentage markup, purchases, expenses and income making extremely difficult for
the client to keep track of stocks, income and expenditure. The process is prone to numerous mistakes and
very time consuming. Furthermore, it leads to inconsistent data, overstocks, accounting inadvertently mistakes
and sometimes delays in orders.
*Note: Between 6 January 2019 until 5 April 2019 Albert Butcher used ZipBooks monthly paid version where
the expenses can be added and automatically deducted from total income, a feature implemented into this
project.
1.4 Proposed solution
Please note that the following proposed solution has come out of extensive conversations and discussions with
the client and my own development with the project idea. These are covered thoroughly in the Requirements
Specifications. Here I briefly want to indicate what the nature of the proposed solution is and highlight some
of the key features. The proposed solution which I have called Retail Business Management System (RBMS)
is intended to be an all-in-one solution that should allow the management of the inventory, purchases & sales
(storing the purchase price and sale price), suppliers, customers, invoices, general accounting and HR
management. RBMS supports multiple stores (warehouses), allowing the business owner to have an overview
over entire stock and make adjustments if necessary, by replenishing the stock (ordering new items) or moving
goods between stores (e.g. if an item is in excess in location A it can be transferred to location B). For RBMS
I am intending to implement a notification system that will inform the user if any of the product/s in any of
the warehouses (shops) is below a pre-set limit. This will prevent understock and implicit overstock.
Furthermore, the RBMS system will allow the user to have access to the customers and suppliers contact
details in one place. This will keep business contact list consistent. In addition, automatically calculating the
profit/loss ratio by taking into account the expenses, employee payments, wasted products (e.g. unsold and/or
expired and including or excluding the VAT tax depending of purchase/sale requirements, will make the
accounting very easy. A variable VAT method adds flexibility to the business because the VAT should be
added to the total order or individually per product. In UK some goods have a standard VAT of 20%, others
5% where most food products have a zero rate (Gov.Uk, 2014). Therefore, the VAT calculation can be
adjusted for each product (or category of products) individually.
The system should allow the comparation between current available physical stock and digital records, with a
stock counting function. The function should allow the manager to inputs the current counted products from
store and the system will automatically calculate the stock difference (if any).
The proposed system should be able to creates several reports including the total revenue, profit/loss (gross
and net), received and sent payments making the accounting very easy.
RBMS should be available as a multilanguage system. This feature will increase end-user experience making
the system more appealing to the users where their native language is not English.

1.5 Tools, facilities and resources
One of the key aims of the project will be to keep the development costs as low as possible. Therefore, all
used software, frameworks, packages and platforms will be free to use (MIT or GNU 3 licence) or supported
by an educational licence (MS Office 2016, Balsamiq and Axure). The only expenditures for this project will
be the purchase of live server domain and several travels to the business location.
Some of the chosen software are based on personal preference (e.g. the code editor, DB development tool)
and they can be substituted with any other suitable software (e.g. Atom). For mockups and prototyping the
chosen tools are tools used by the industry standards and they are covered by an educational licence. The
software used for images manipulation (conversion, cropping, retouching, drawing etc) is one of the most
popular free software, simple to use with a large available documentation. This project does not require
extensive images manipulation and any other software can be used (e.g. Paint). The development environment
is my personal computer setup.
The decision that lead to use of the server environment, framework and packages will be explained in the
related sections.
Below is a brief description of the used software and applications:
• Code Editor: Used for writing and developing the code with full support for all required programming
languages (SQL, HTML, CSS, JS, PHP)
o Visual Studio Code, desktop application v1.31.1 (https://code.visualstudio.com)
• Database Development: Writing the SQL from scratch will be time consuming therefore using a
software with a GUI will accelerate the database creation process.
o Devart dbForge Studio Express (https://www.devart.com) is one of the most comprehensive
database development tools.
o MySQL Workbench - as a backup (https://www.mysql.com/products/workbench).
• Images Editor: Used for editing and manipulation of images, icons and logo creation
o Gimp v2.10.8 (https://www.gimp.org)
• Diagram Design: Used to create system architecture, use case & sequential diagrams included in this
report
o Microsoft Visio 2016
• Mockups & Wireframes: Used for initial mockups and low fidelity prototyping of the user interface
for the client
o Balsamiq (https://balsamiq.com)
• Prototyping: Used for initial high fidelity prototyping with where the user had the real “feel and touch”
experience with the GUI
o Axure (https://www.axure.com)
• Server Environment: Local server used for development necessary in order to run SQL & PHP files
without delay over the internet and for efficient and quick debugging
o XAMPP PHP development environment with Apache Server 2.4.37, PHP v7.3.0 and Maria
DB v10.1
(https://www.apachefriends.org)
• Frameworks: The platforms used for the system development. The frameworks helped to save a lot
of time by eliminating the need of producing repetitive code and allowing to build applications rapidly
o Laravel v4.2 (https://laravel.com)
o Bootstrap v4.3.1 (https://getbootstrap.com)
o Vue.js v2.6.7 (https://vuejs.org)

• Cross Environment: Integrated package into frameworks to allow the system to run on different
devices/platform without the need of creating separate versions
o Cross-Env v5.2.0 (https://www.npmjs.com/package/cross-env)
• Packages, Modules & Libraries: Additional ready-built files (or directories) adding functionality to
the frameworks
o Laravel Mix 5.7 (https://laravel.com/docs/5.7/mix)
o Popper.js (https://popper.js.org)
o Axios v0.18.0 (https://www.npmjs.com/package/axios)
o Lodash v4.17.11 (https://www.npmjs.com/package/lodash)
o Milon Barcode v5.3.6 (https://github.com/milon/barcode)
o jQuery v3.3.1 (https://jquery.com)
• Live server domain: The live server for the system deployment available 24/7. This eliminated the
need of travelling to the client to show the changes
o http://www.uop.cloud
• Testing: Used to automatically test different parameter of each individual module of the system. Free
automation server testing with Continuous Integration and Continuous Delivery for end-to-end testing
solution
o Katalon Studio v6.1.1 (https://www.katalon.com)
• Browser
o Google Chrome v72.0.3626.119
o Mozilla v65.0.2
• Project Management
o Microsoft Project 2016
• Development Environment:
o Windows 10 Pro
o CPU: Intel Core i7-4790K
o Ram: 64GB
o GPU: NVidia GTX 980 Ti
o Dual 27’’ monitors
o Printer
o Internet connection
• Mobile Devices: For visual functionality testing through browser
o iPhone 6; iPhone Xs; iPad Pro 11-inch; Samsung Galaxy S7 Edge; Samsung Galaxy S9;
Google Nexus 7-inch; Amazon Fire HD 10-inch
• Programming Languages:
o HTML
o CSS
o PHP
o SQL
o JS (libraries)
• Other: Notepad++ v7.6.3 (https://notepad-plus-plus.org); Excel 2016
Note: Please note that this paper does not cover any software installation, utilisation or server
configuration.

1.6 Risk assessment
At the initial stage of the project it was very important to enumerate and detail out the risk issues related with
this project. The table below summarises the risks like I saw them at the beginning of the project.
Description Probability Possible Countermeasures
My computer has a NAS (network-attached-storage) drive
Computer failure Low attached with a daily scheduled backup for important files. The
project folders will be added to the backup schedule.
The above solution will be suitable but instead of overwriting the
Loss/corruption of data Medium backups, for the project purpose, this will be kept until I manually
delete them.
The aim of this project is to keep the development costs near to
Technical £0. Therefore, the only software requiring a licence are MS
Software licences Very Low
Office, Balsamiq and Axure which are covered by a student
licence until 2020
The purchased server may have compatibility/configuration issues
Server setup Low with the system. I will contact the host company to find a solution,
otherwise I will purchase a new server.
Consulting technical books, forums, documentation to overcome
Coding/Development
Medium the problem. Otherwise, I will look for a compromise or
issues (lack of knowledge)
workaround solution.
I have scheduled a surgery in August 2019. If something
Illness Medium unexpected triggers this earlier, I will review the project priorities
and act accordingly.
Personal Time management is one of my soft skills. I consider that setup
Time allocation Low timeframes are realistic and achievable. However, if the scheduled
pattern suffers major changes, I will review at the time.
Family commitments Medium Some unpredicted situations may arise. I will review at the time.
Project scope change Low Looking for alternative solutions or starting a new project.
Communication with the Using alternative communication methods with the client (e.g.
Low
Organisational client emails, phone, Facebook messenger, WhatsApp).
If the project is in an advanced stage, continue the project based
Unavailability of the client Very Low
on assumptions, otherwise consider a new project.
My personal IT setup at home contains a variety of hardware.
Unavailable hardware Very Low However, if something unforeseen appears I will purchase the
Resources required hardware.
Research more, subscribe to specialised forums, visit the
Documentation, Books Medium
University’s library
1.7 Legal, ethical, professional and social issues
Very briefly in this section I want to highlight that legal issues which may arise during the course of the project
may be related with data protection and privacy. Therefore, any personal details that may be acquired during
the data gathering or testing phases must be deleted and when is possible to use dummy date for testing phase.
In this project only beneficiary (the client) company will be included and a signed consent form will be
attached to this project.
A critical professional issue is to remain unbiased, to look impartially at the requirements, be honest and
demonstrate integrity through development process. Keeping up with the latest technologies the final artefact
should be an up to date product suitable for business.
Keeping a professional attitude during any conversation with the client or any of his employees will increase
the client confidence and trust.

1.8 Initial remarks regarding the development of this project
.
In this section I will highlight briefly, however more expanded
throughout the document, the fact that this project has 2 levels.
The first level is to provide a bespoke system for the client. The
second level involves developing a generic model that offers
flexibility and it can be adapted to any other retail business.
A bespoke system is tailored for one client which includes his
specific requests and preferences.
In order to develop a new system efficiently, I must take into

account the potential risks that may arise during different stages.
However, client’s business profile is a groceries retail business
profile and many of his requests are requests that can be Figure 3 - Project development risk diagram
generalised and applied to any other retail business. Further [Primary Source]
information about these requests will be presented across this document.
Like Morris stated “many times, a project may start from a simple idea but soon the project has branches, on
branches twigs are growing and without realising the twigs grow leaves” (Morris, 2001). However, I must
be aware that by increasing the project size the risk of failure will increase proportionally.
Nonetheless, I decided to embrace the challenge and increased project complexity but taking into account a
potential risk of not completing the project on time. It was a calculated risk and I was focused to implement
client requests first and enhance features at a later time.

2. Literature review
In this chapter my aim is to present an analysis of the systems/platforms already available on the market,
examining their advantages and disadvantages, to look at the aspects of programming language, databases and
other technical considerations.
2.1 Available systems
One of the first problem encountered researching for similar software was the
fact that most of them, for the demo access were asking too many unnecessary
personal information, to be comfortable with, for marketing purposes. After
several demo requests attempts few software were selected for trial.
• inFlow (https://www.inflowinventory.com)
The executable was successfully downloaded but despite the fact of several
trials the installation on 2 different computers were unsuccessful due to the fact
that application could not connect to the server (Figure 4). Even a minor
downtime of the application functionality can result in financial loses for the
client.
Figure 4 - in Flow Software
• XERO (https://www.xero.com/uk) installation error [Primary Source]
XERO software (Figure 5) had a very well-integrated interface with full accounting and payroll support. The
system was easy to be used with intuitive button labelling and easy to navigate interface. The system
automatically generates invoices, adds suppliers and customers, generates different financial reports along
with profit loss ratio. The software does not have any support for inventory and stock management, suppliers
list or sales. One of the disadvantages was the fact that the system was accessed through a web browser and a
24/7 internet connection was required which would put off the client. The price for the system use was
£27.50/month with an additional cost of £5/month for each extra user added to the system and another
£5/month for any payroll employee added. This will cost the client around £70/month (adding 5 employees
and 3 users). When the client has more users/employees the price will increase in the future.
Figure 5 - XERO Software trial account [Primary Source]

Having a separate accounting software will not be in client interest who desires to limit the number of tools
required for business management.
• ZOHO Inventory (https://www.zoho.com/uk/inventory)

ZOHO Inventory (Figure 6) was the most comprehensive solution tested, with a very well-designed interface
with multi-warehouse stock inventory management and possibility of manual adjustments, sales customers
and suppliers, invoices, sales and many other features. However, the system was somewhat overwhelming
with addons features requiring additional payments and is a complete stock management solution suitable
more for medium/large business. The system does not provide categories and sub categories for the products.
To use the system a 24/7 internet connection is required and the price is about £200/month (for minimum
package) with a limited number of users and warehouses. Any additional user and warehouse will increase
the price. Beside the mandatory continuous internet access, ZOHO Inventory did not have any support for
expenses, accounting or payroll management. The available setup documentation is ambiguous and, as a
Figure 6 - ZOHO Inventory trial account [Primary Source]
technical person, I was confused about used terminology. For a person with less technical abilities will be very
difficult to setup this system. The learning curve of how to use the software is very steep.
On a software review website, a customer with a small company left an extended review of the ZOHO
software (Figure 7) where highlighted the difficulty of use, lack of functionality and the poor customer
support.
There were other several systems tried with more or less features but the price (some of them more than
£2000/month) is a crucial decision factor for the client.

Figure 7 - User review (Brett, 2017)
2.2 Programming Language
In the literature review presented in this section I will examine the issues related to the choice of the variety
of programming languages and look to their strength and weakness.
With over 250 programming and scripting languages available in the world (Diana, 2016), each one of them
with strengths and weaknesses, is never an easy decision to take for what programming/scripting language to
use. Please note that there are some differences between programming and scripting languages but both can
be used to develop full applications, individually or combined.
Table 2 - Programming Language vs Scripting Language [Primary Source]
In order to accelerate the development phase and the project

the programming language should support code reuse and
MVC (Model-View-Controller) framework. The MVC
concept was firstly drawn by Trygve Reenskaugh and Adele
Goldberg in 1978 (Reenskaug, 2007). MVC is a software
design pattern for applications development that separates the
GUI layer from application logic. This is split into 3 Figure 8 - MVC Concept (Adapted from Reenskaug design)
[Primary Source]
components arranged as layers and it organises the code in a
manner to improve maintainability (Figure 8).
• Model – The level responsible with holding data and resources available as the lowest layer
• Controller – Middle level layer that controls the interaction between user view and resources

• View – Top layer that displays to the user data ‘agreed’ by controller
However, some programming languages are obsolete, suitable just for specific tasks. Another decision factor
to narrow down the choices was the fact that some programming languages will take too long to be learnt or
not supporting the MVC frameworks.
For this project 3 programming languages were identified that would fulfil the above criteria. I am considering
the following programming languages to use: ASP.Net, PHP and Node.js.
ASP.Net
Is a server-side, cross-platform free framework developed by

Microsoft in 2002 with the current version of 4.7.1 released in
October 2017 (Microsoft, n.d.) requiring strong knowledge of C#
(C sharp) and F# (F sharp) as programming languages. ASP.Net
does not provide same JavaScript on server and client side, making
coding complicated by having different versions of JS. The general
page structure is very complex, combining C# and HTML. ASP.net
is more suitable for large to medium enterprise applications and less Figure 9 -ASP.Net framework (Hanselman, 2013)
prone to customisations. Portability is another issue for ASP based
applications because the configuration settings are not clearly explained and difficult to understand.
PHP
Is an open-source widely used server-side scripting language implemented on 79% of websites (W3Techs,
2018), that can be embedded into HTML and web frameworks. PHP has a shorter learning curve compared
with ASP or JSP, a significant amount of documentation and a very large community support.
The latest version is 7.2 but v7.3 is scheduled for December 2018.
PHP is usually associated with MySQL database and many hosting

services are optimised for PHP and MySQL but it is fully supporting
the Oracle, Postgres, MS SQL, DB2, SQLite and many more.
A full list of supported databases can be seen at:
https://www.php.net/manual/en/refs.database.php.
However, using PHP with any MVC framework additional time and
effort must be put to learn new syntaxes and concepts. This factor
will increase development time if I am not familiar with that specific Figure 10 - Global percentage of server-side
programming language (W3Techs, 2018)
framework. In a comparative study published by Concordia
University arguably is stated that “it is widely believed by the developers that PHP has a poor quality of
handling errors. PHP lacks debugging tools, which are needed to search for errors and warnings. PHP has a
smaller number of debugging tools when compared to other programming languages” (Alomari, Halimi,
Sivaprasad, & Pandit, n.d.) .

Node.js
Is a JavaScript runtime environment, including all necessary resources to execute a code written in JS as
server-side. Node.js handles files request differently of PHP and ASP (Table 3) eliminating the waiting time
which is a huge advantage. However, if a long calculation is necessary the performance will decrease because
the support for multi-threaded operations are inexistent. Another disadvantage of Node.js is lack of
consistency where changes are often backward-incompatible, making long term maintenance extremely
difficult. Available library system is not so robust compared with other programming languages and scalability
of a project developed with Node.js may be a real challenge for any developer because its immature
environment, asynchronous programming model and not stable API (Malvi, n.d.).
Table 3 - Node.js files request handling vs PHP/ASP [Primary Source]
2.3 Database
In this section my aim is to examine a number of different databases platforms that offers the features and
functions necessary to this project by presenting the selection criteria and a short description of each database
along with advantages and disadvantages. A comparison table will be presented at the end of the section and
conclusion of database analysis will be presented in Design chapter.
In recent times databases are notably surrounding us more than ever and most of the time without noticing.
Making a simple phone call will involve a database connection. Databases are at the core of the most systems
and choosing the right database is a critical step for any system to be developed.
At the time of writing DB-Engines Ranking website lists 340 (DB-Engines, 2018) actively developed and up
to date databases, each one of them with strengths and weaknesses or suitable for different purposes (e.g.
relational, search engine, document, etc.).
However, regardless of vendor the databases must satisfy the following conditions necessary for this project:
✓ Relational/Table database
✓ Free/Open Source
✓ ACID (Atomicity, Consistency, Isolation, Durability) compliance
✓ SQL compliant
✓ Scalable
✓ Support for real-time queries
✓ Support for triggers
✓ Detailed documentation
✓ Strong community support
✓ Support for the programming languages analysed in Programming Language section
Analysing the available pool of databases, the following were identified as suitable for this project:
▪ MySQL (https://www.mysql.com)
▪ PostgreSQL (https://www.postgresql.org)
▪ SQLite (https://www.sqlite.org/index.html)

▪ MariaDB (https://mariadb.org/)
In Figure 11 we can observe databases trends and popularity over the years where Oracle, MySQL and MsSQL
Server are the most popular.
Figure 11 - Databases ranking trends over the years (DB-Engines, 2018)
MySQL
MySQL database had first public release in 1996 (1998 for Windows) and was developed by Allan Larsson
and Michael Widenius (Rieuf, 2016). Sun Microsystems acquired MySQL in 2008 which was later acquired
by Oracle in 2010 and developed since then (Oracle, 2010). MySQL is a very popular choice among
developers and most-used open-source database system in the world with a 38.9% market share (ScaleGrid,
2019). Furthermore, there are many enthusiasts and developers forming a large community to whom I could
ask for support.
Moreover, MySQL is a free, flexible open-source database with support for programming languages such as:
PHP, JAVA, C++, C# Node.js, Ruby and many more. A characteristic specific to MySQL is the scalability
and the accessibility of the applications by mirroring the workload across various nodes.
However, MySQL is not designed to support a very large number of concurrent queries very efficient
(MySQL, 2018).
PostgreSQL
PostgreSQL emerged in 1996 based on another project (Ingres) at the University of California (PostgreSQL,
n.d) and has undergone several major modifications since then.
Similar with MySQL, PostgreSQL is a comprehensive, sophisticated database system with a highly available
documentation and a strong community support. Suitable for single machine workload, web services and data
warehouse and supports various operating systems. The integrated query optimiser can handle complex
queries better than many others databases. However, installation and configuration can be difficult for
beginners and the learning curve may be steep. Furthermore, PostgreSQL has only one storage engine
compared with other databases.
SQLite
SQLite is a self-contained, file-based database with strong performance for low-memory systems. With a
serverless technology, SQLite is the perfect candidate for small, embedded applications (e.g. mobile phones,
electric appliances, automobile industry). With zero-configuration approach SQLite does not come with any
configuration files that need to be managed and entire SQLite database is stored in a single file (SQLite,
n.d.).Being a very lightweight software (around 600KiB) developers made a major compromise by not
integrating any security measure (e.g. authentication, privileges) in SQLite. Security measures can be
integrated additionally with various commercial support packages, each for an annual fee (SQLite,
n.d.).Another disadvantage is the fact that SQLite has a limited concurrency of connections.
MariaDB
MariaDB is a free open-source fork of the MySQL but commercially supported. This fork was created due to
concerns that Oracle will end-up free licence of MySQL (MariaDB, n.d). Sharing many features of MySQL,
MariaDB stands forward as a stable and innovative database.
The storage engines integrated in MariaDB allow users to run SQL and NoSQL in a single database system.
Additionally, MariaDB provides better monitoring through the introduction of microsecond precision and a
better query optimisation. However, increasing control writing queries is more difficult because MariaDB is
case sensitive. As many developers have different naming patterns, it may become frustrating to check all the
time table name or column name. Another disadvantage is the limited number of supported operating systems
and the hosting environment may not support MariaDB.
The table below summarises the analysed databases features based on several criteria that I consider important
for this project:
Criteria MySQL PostgreSQL SQLite MariaDB

Development Open-source Open-source Open-source Open-source
Architecture Client-server Client-server Integrated Client-server
Licence GNU/Commercial MIT Public Domain GNU, LGPL
Clear; Large Confusing; Medium Clear; Small Clear; Large
Documentation
Community Community community Community
None (3rd Party Tools None (3rd Party Tools
GUI Tool MySQL Workbench PgAdmin
available) available)
ACID YES YES Partial YES
Storage Engine Multiple Single 2 Multiple
Data Types SQL Standard SQL Standard + Other SQL Limited SQL Standard
Triggers Yes Yes Partial (per row) YES
Indexes Partial Yes Limited Yes
Text Search YES YES YES YES
Max DB Size Unlimited Unlimited 128TB Unlimited
Max Table Size 64TB 32TB Limited by file size 64TB
Integrated Security YES YES NO YES
YES (Free & YES (Free &
External Libraries YES (Proprietary) NO
Proprietary) Proprietary)

PHP, Ada, C, C#,
C++, Curl, Go,
Supported PHP, Node.js, C, C#, PHP, Embedded C, C, PHP, C++, C, Node.js,
Haskell, Java,
Programming C++, Java, JavaScript, C++, Java, Python, Perl, Python, Ruby,
JavaScript, MATLAB,
Language Python, Perl, Ruby TCL/TK, Perl Swift, Java, JavaScript
Python, R, TCL, Swift,
Ruby
Windows, Linux, Mac
Windows, Linux, Mac Windows, OS X
OS, CentOS, AIX,
OS, OpenBSD, (10.4+), Linux Windows, OSX,
Supported Operating FreeBSD, OpenBSD,
NetBSD, FreeBSD, (MeeGo), NetBSD, Linux, BSD, Unix,
System Net BSD, SGI Iris,
AIX, Solaris, Unix, FreeBSD, Symbian Android
Debian, Android, HP-
UnixWare, Tru64 OS, Android, webOS
UX, Sun Solaris
Portability Medium Low High Medium
Small embedded
Large applications
Small to Large web- applications that do Small to Large web-
Best used for with geospatial data;
based applications not require future based applications
Data warehouse
expansion
Table 4 - Comparison summary of databases
2.4 System architecture
In this section I am intending to present a brief overview of the system architectures that I am considering
suitable for this project. The justification of the chosen architecture will be presented in the Design chapter.
Garlan and Shaw define the system architecture as: “The architecture of a software system defines that system
in terms of computational components and interactions among those components” (Garlan & Shaw, 1994). In
other words, system architecture is the foundation layer of the application or software which determine how
the user interacts with the system (authentication and other security mechanism), how system components
interact with each other and the services that it provides.
One of the criteria to select these architectures is following the programming language analysis. The
architecture should support MVC frameworks. For this project I found that the following system architecture
patterns would be most suitable:
Monolithic architecture
Monolithic architecture is a single-tiered software application where the data

are accessed through a GUI from a single platform (Figure 12). The system is
designed without any modularity and all required components are embedded
into the software. For example, a single Java file is a software developed with a
monolithic architecture. A standalone platform that is installed on a single
system and the user access all functions through a GUI.
What makes iterative development slower is the tendency of the organizations

to have long cycles between releases and the need for re-deployment.
(Richardson, 2018). Figure 12 - A typical monolithic
system [Primary Source]
Monolithic architecture is suitable for small artefacts development. Scaling a
monolithic designed application is very difficult and time consuming, requiring that all interconnected
component needs to be updated.

Space-based architecture (SBA)
Space based architecture, sometimes called cloud architecture, is a linear architecture pattern using the tuple
space paradigm. SBA is implemented by building independent units called processing-units (Dai, Bai, & Xu,
2006). The architecture supports Java, .Net, and C++ programming languages. Most suitable for distributed
systems it has a high degree of scalability by simply adding more processing units. However, the deployment
is depended of a cloud environment and is very expensive to maintain because it involves replications and
mirroring of the system in order to avoid a single point of failure (Engelhardtsen & Gagnes, 2002).
Client-server architecture (CSA)
Client-server architecture is a pattern based on sharing the workloads

between the providers of a resource or service (servers) and service
requesters (client). CSA is usually based on open-source technologies and
does not involve licensing costs. This is an enormous advantage, since it cuts
the cost for payment of an annual licensing. CSA offers numerous other
advantages such as: applicable for homogeneous environment; server and
Figure 13 - Client-server architecture
business logic is physically close therefore, will offer higher performance; [Primary Source]
due to simplicity, applications can be easily developed; hidden database
structure and improved data integrity.
Any system/software built with a client-server model is built regardless of the hardware platform providing
an open computing environment and sharing resources amongst different platforms.
As any other architecture along with advantages CSA has own limitations as well. Performance could begin
to deteriorate as the concurrent users are increasing. Therefore, this will increase the maintenance price
because the hardware requirements of the server must be upgraded. Each service is a single point of failure so
susceptible to denial of service attacks or server failure.
Service-oriented architecture (SOA)
SOA is an architectural pattern that utilizes services as fundamental

elements for developing applications/solutions where application
components provide services to other components via a communications
protocol, typically over a network. The principles of service-orientation
are independent of any product, vendor or technology (Endrei, et al., 2004)
by providing a universal connectivity to existing systems and data.
For the end-user, the process must be organized such that only the service
Figure 14 - SOA architecture [Primary
interface matters, and there must be no dependence upon knowledge of the Source]
service implementation.
SOA is not a just an architecture model for services, it is a relationship of three kinds of participants: the
service provider, the service discovery (service registry), and the service requestor (service client). The
interactions involve the publish, find and bind operations (W3C, 2004) see Figure 16.
However, a research paper describes the SOA model as a challenging pattern to follow (Huhns & Singh,
2005), comparing to the conventional architecture which requires the ability to build on conventional

information technology in a standardized way. This architecture is best used for embedded devices or close
systems (e.g. medical systems).
SOA it may not be an adequate pattern if the system is not offering software functionality as services to
external parties or not using external services or for homogeneous systems like Thomas Erl noted (Erl, 2005).
Object-oriented architecture (OOA)
OOA is an architecture pattern based on the division of responsibilities for an application or system into
individual reusable and self-sufficient objects (Mowbray & Malveau, 2003). One of the main advantages of
OOA is the fact that it is easy to maintain and improves the quality of the system due to program reuse. As a
disadvantage it has difficulty to determine all the necessary classes and objects required for a system. This
architecture pattern is very popular with Java, C++, C# and scripting programming languages.
2.5 Design Strategies
In this section I will briefly discuss the possible design approaches for this project and the justification will be
provided in the Design chapter.
Software design is a creative process that based on a mix of knowledge, intuition and imaginations is perfected
with experience. The term design in software development, is not referred as drawing something but rather as
a parallel activity where conceptual ideas are analysed.
Foster defines software design activity as a critical step for the final artefact where “decisions you take now
will hit you later” (Foster, 2014). Furthermore, Foster divides design activities into 7 categories (see Table 5).
Design Activity Resultant Design Spec Component

System architecture specifications - relates to the subsystems and/or modules making up
Architectural Design
the system, as well as their interrelationships.
System Interface Specifications - For each subsystem (module), its interface with other
Interface Design
modules is designed and documented.
Database (Object Structure) Specification - For each subsystem (module), its interface
Database (Object Structure) Design
with other modules is designed and documented.
Operations Specification - For each subsystem (module), its interface with other modules
Operations Design
is designed and documented.
User Interface Specifications – relates to screen design, menu structure(s), input and
User Interface Design
output design and in some systems, a user interface language.
System Documentation Specifications - includes all forms of product documentation (help
Documentation Design
system, users’ guide, system manuals, etc.)
Message Specifications - important method of software communication with end users is
Message Design
via (error and status) messages.
Security Specification - relates to the various authority constraints that different users of
Security Design
the software product will have.
Table 5 - Software design activities (adapted from “Software Engineering: A Methodical Approach”, by E. C. Foster 2014, p226)
The design activity approach is divided into two categories: top-down or bottom-up. The top-down design was
firstly mentioned by IBM researchers Harlan Mills and Niklaus Wirth and is focused on general functions,
where the developer specifies ‘what, wherefore and how’ of the system (Narang, 2015). This approach
involves extensive planning and research. Bottom-up design is focused on each specific function and sub-

systems. The most primitive operations are specified first, then they combine later into progressively larger
units until the whole problem can be solved.
The main characteristic of the top-down approach is the fact that
enables the structured control of the project where the bottom-up
approach is more suitable when the project details are scattered.
As an analogy we can perceive the design techniques as a

mathematical problem. For example, if we want to create the
prime factorization of a number like 1540. In a top down approach,
we have the number and we are working out the solution, where Figure 15 - Top-down vs Bottom-up [Primary Source]
in bottom-up we have the component parts and we work out a
solution. see Figure 15.

3. Methodology
In this chapter I will analyse a number of key methodologies which initially seems appropriate for this type
of project. A short description of the methodology will be made along with a summary of advantages and
disadvantages of each one of them. At the end of the chapter a conclusion will be drawn and reasoning will
be provided to choose a methodology instead of other.
3.1 Waterfall Model
Waterfall model, first suggested by Dr Winston Royce in 1970, is

probably the most known software development life cycle method
and it has a very linear approach (Royce, 1970), where a new phase
of the projects begins only after the previous phase or step was
totally completed.
However, it must be noted that for the waterfall model phases
defined in Figure 16 may have some other variations such as, steps Figure 16 - Waterfall Model [Primary Source]
for requirements and analysis are defined as separated steps but the
principles are the same. For Waterfall all the requirements must be very clear and well described at the
beginning of the project, being extremely time consuming and possible expensive to fix any errors discovered
at a later stage.
Waterfall method carries an increased risk factor of projects failure if the details and requirements are not well
defined ahead, misunderstandings and miscommunications that occur between the developer and the client,
human errors are not taken in consideration or specifications are often changed. The biggest downfall of the
waterfall model is the fact that it enforces an adherence to a strict development sequence (Bassil, 2012), where
flexibility is nearly inexistent. Additionally, the testing phase cannot be initiated until the design and
development phases are not completed and the client is involved only at milestones. Currently, when almost
any software or application development have an increased degree of complexity, this model is almost a utopic
approach but it still can be used for very small projects where the requirements are well defined and unlikely
to be changed.
The table below summarises the advantages and disadvantages of the waterfall model.
Table 6 - Waterfall model advantages and disadvantages [Primary Source]
3.2 Agile Model
This model has as core principles the flexibility and the continuous improvement. Agile model is more
suitable for self-organizing group of people (teams) working on a project, embracing the changes,
collaborating and allowing modifications almost at any point in the project (Agile Alliance, n.d.). Contrary to
Waterfall model which is based more on a predictive approach, agile uses an adaptive approach. A project
following the agile conceptual framework should follow and apply the 12 principles as they are defined in the
Agile Manifesto (Agile Manifesto, n.d.). Agile is a broad
concept and can be implemented with other methodologies
creating hybrid methods and can include more sub-method
types such as: Scrum, Crystal Clear or Dynamic Systems
Development Model. However, agile methodology is
heavily depending on client interaction and communication
where team members are forming a cluster around the
project with a high degree of synchronisation and
coordination between members. When a member is
replaced, it may be difficult for the new member to be Figure 17 - Agile model [Primary Source]
apprised in detail of the project development due to the lack
of documentation because usually agile teams are prevailing working software over documentation. With agile
methodology each member knows exactly their position and what they need to do. Communication being one
of the key factors of agile methodology, will offer a greater client satisfaction, because the client is involved
at any point into the project and offers project transparency.
Agile model prioritises the most important features and they are implemented first therefore, the risk of full
fail of the project is minimised and allows a partial success of the project (Lee & Xia, 2010). The
implementations (or potential product functionality) are done through short cycles of development process
known as sprints.
In below table I have summarised the advantages and disadvantages of agile methodology.
Table 7 - Agile model advantages and disadvantages [Primary Source]
3.3 Incremental Model
Incremental model is focused on essential features and add

functionality or enhance existing ones when is necessary.
We can see incremental model as a multiple mini-waterfall
linear models where each increment is a stand-alone small
project (or a sub-system) and the core element of the
project is usually the first increment. Adding more
increments and functionalities the core product is updated
accordingly until the project is completed in a flexible
Figure 18 - Incremental Model [Primary Source]
manner by combining linear and parallel process flow.
Usually each increment (partially systems) is working independently to each other but connected to the core
product. To make an analogy we can say that the core product is a tree core and the additional features are the
branches. Removing or modifying a branch will have no impact over core or very minimal, allowing quick
modification/fix.

The incremental model provides an operation product with each increment, where the client evaluates the
increment, provides feedback and may suggest new features or improvements of the existing ones. Following
this approach is easier to identify the error in user requirements since the client provides feedback to each
increment.
This model is the ideal approach for individuals, small/large teams where they can work on various functions
of the project simultaneously. If the core product is well defined and implemented the teams can be extended
overtime in order to add more increments (Pressman, 2010). Despite the final product being defined as
completed when it satisfies all requirements there are still opportunities for further enhancements without
affecting the product functionality.
In below table is presented a summary of advantages and disadvantages of incremental model.
Table 8 - Incremental model advantages and disadvantages [Primary Source]
3.4 Rapid application development (RAD) Model
First formalised by James Martin in his book “Rapid

Application Development” in 1991, RAD is focused on
prototyping and development process to provide quick
results. It is ideal for multi teams (each team between 4 to
8 members) development where each component is
developed in parallel, aiming to present a working model
as soon as possible (Beynon-Davies, Carne, Mackay, &
Tudhope, 1999). The process of gathering user
requirements is generally done through focus groups and
working prototypes are produced from early stages. RAD
is dependent of very sophisticated automation tools in
order to create working modules in the fastest way
Figure 19 - Rapid application development [Primary Source]
possible. The overall development time is reduced
significantly as a result of the reusability of the components but high skilled team members are required.
Similar with agile methodology, RAD is very flexible to changes but the cost is very high, requiring skilled
developers, automatization tools and automated code generation, prioritising the product over documentation.
As a drawback RAD is more prone to low quality end product when the time of development and
implementation is a decisive factor. Rapid application development with automatic tools is more used for the
development of databases, report generators or GUIs rather than complex end-to-end products (Sommerville,
2011).

A summary of rapid application development methodology advantages and disadvantages are presented in
the table below:
Table 9 - RAD model advantages and disadvantages [Primary Source]
3.5 Spiral Model
The idea of a model that combines iterative development

with the linear aspect s of the waterfall model and
prototyping, was first suggested by Barry Boehm in the
document ‘A Spiral Model of Software Development and
Enhancement’ published in 1988 (Boehm, 1988).
Focusing on a risk-driven approach, it is the ideal model
for very large, expensive and complex projects with high-
risk implications, where there are too many unknown
factors, unpredicted requirements or requirements are
likely to change very often. The spiral model can be an
applied as a master to the whole project and for different
iteration can be assigned other models. The development
phase can start very early, even if all requirements are not
Figure 20 – Spiral model (Nutschan, 2008)
clear or incomplete. Compared to other models it may
have an increased overall cost but the risks of project failure are reduced substantially. The management of
the projects was proven to be very difficult requiring additional resources for monitoring and specific expertise
for each spiral (Ray, 2013).
The summary of advanced and disadvantages of spiral model can be seen in the table below.
Table 10 - Spiral model advantages and disadvantages [Primary Source]

3.6 Methodology decision
The waterfall model has numerous sources of available documentation that would help me to implement it.
Unfortunately, waterfall it does not offer enough flexibility for the project I am undertaking and the client will
be involved only towards the final stage of the project. One of the aims is to develop a bespoke solution for
the client and without his continuous feedback, as well as high involvement in all phases, the project may fail.
The waterfall may be suitable for smaller clear projects but for this one I am considering that waterfall is not
the appropriate method.
Agile methodology is probably one of the most used method for software development, involving the user
almost at any stage but it is designed for collaborations where a team works together for the final goal. Agile
methodology involves long cycles and clear development goals. This project being an individual project and
the final development goals still to be determined, using agile methodology will be a drawback rather than an
advantage.
Similar with agile, RAD model is a team work but where several teams work in parallel on the same project,
creating final modules from working prototypes. For an efficient application of RAD expensive and
sophisticated tools and software were required invalidating the aim of this project to keep development costs
to a minimum.
Developing a bespoke and a generic model system for the client it extends the complexity and the risk factor
of the project failure. Using spiral model may be considered as an advantageous model but implementing a
spiral model would actually carry the risk of spiral to go on indefinitely. The time consumed by each build of
the prototypes, analysis or iteration may result in a never-ending project. Therefore, I am considering that
using spiral model would be detrimental to the project.
This project is a system built from scratch with a focus on offering a bespoke system to the client, as well as
a generic model suitable for other businesses. Allowing the client to be involved actively and to preview every
stage of the project is a critical requirement. Furthermore, a model that allows me to break down the entire
project into modules is another constraint.
Taking into account all the above, I am considering that the incremental model is the most suitable model to
be used. This will prevent a cascading effect on the project development when something needed to be
implemented/changed to a specific module. The incremental model allows me to break down the project into
small modules and regularly test them.
Another advantage using the incremental model is the fact that spotting and fixing errors in each stage is easier
than debugging a whole system. However, I am aware that if any of the core functions is modified a correction
is required in all depending modules which will be time consuming, but this is an acceptable trade off. I
consider that the key elements for this project are: frequently delivery of working software, direct
communication with the client and flexible development process.
Furthermore, using incremental model allows and encourages an iterative development (revisit parts of the
system in order to improve them or to add new functionality) an approach suggested by a research conducted
by De Lucia and Qusef (Lucia & Qusef, 2010).
Just to highlight the importance of well planning system and how incremental model can save millions of
pounds if not billions, we can examine Ford Motor system implementation failure in 2004. Ford Motors tried
to implement an Oracle-powered system, a project that costed Ford Motors $400 million (Hines, 2004). The
system aimed to bring 30 archaic systems under one core system but the problem was that the core system
was developed independent of the already in place systems with a minimum compatibility/integration testing.

Probably if the project I am undertaking would be designed, developed and implemented by a team with
different skills, expertise, tools, training and educations a different method should be used.

4. Project Management
In this chapter I am presenting a brief overview of the project management as well as the changes, deviations
and delays of the initial plan. Further information about project encountered difficulties and a personal view
will be presented in Conclusion chapter.
As mentioned in the Introduction chapter, my relationship with the client is a long established one and the
discussions to undertake this project had started before it was accepted as a final year project. This was an
advantage for me because gave me a longer time period to fulfil the requirements without rushing into an
incomplete system or simplifying the project in order to meet university deadlines. The below Gantt chart
shows the timeline of the entire project that includes the university deadlines, additional project tasks
excluding public holidays or half term, as they were not influencing factors.
However, the timeline of the project (Figure 21) suffered few alterations along the way. In general, the
estimations were correct. Although, the development phase was estimated to take initially around 250 days,
the duration changed due to adding more modules and continuously improving the project. These added a
degree of pressure to complete the tasks in time. This was not necessary a bad thing because it helped me to
better understand how to manage the changes and how to provide solutions to a given problem. This fact once
again demonstrates that the chosen methodology was the right one for this project.
Figure 21 - Project Timeline Microsoft Projects [Primary Source]
The extra functionality added to the modules, required constant review of the system. One of the factors I did
not anticipate was the continuous improvement of the modules and this added extra time for development.
Figure 22 shows a breakdown on
tasks with an estimated number of
days per task along with planned start
date and end date. The tasks dates
were for guidance only. In general, the
scheduled pattern was followed but
occasionally the estimated time took
longer than anticipated.
However, the time was recovered by
putting more effort and prioritising
tasks.
Note: It was not possible to take a full
screenshot of the project task allocation.
Please see Appendix M for a larger
screenshot of the project total timeline.
Figure 22 - Project estimated days and duration

5. Requirements
In this chapter my aim is to present user and system requirements that emerged during the analysis.
Additionally, the requirements emerged during the different increments and user feedback are presented as
well. The mandatory requirements are crucial for the business and are the backbone of this project.
I believe that adding more functionality will increase user satisfaction and these features will make this project
viable for any retail business not only a bespoke system for the client.
Section 5.2 from this chapter describes what the applications must and should be able to do through
implementing core functions and features stated by the user and business analysis. Moreover, some functions
were added by taking into account other potential users of the system, without diminishing client requests.
These requests emerged from the discussions with the client, interviews, personal observation of the business
workflow and my personal experience.
User is defined as any person that interacts with the system regardless of user role (e.g. admin, business owner,
manger or staff).
Section 5.3 describes the system requirements where user requirements are translated in technical terms and
specifications.
Specific requirements presented in this chapter are prioritised using the MoSCoW method and they are defined
as follow:
▪ M – Must have (Mandatory requirement – this requirement is essential for the business)
▪ S – Should have (Beneficial requirement – it is not critical for the business but this is beneficial and
will increase efficiency if implemented; requirement that can be applied for a generic model)
▪ C – Could have (Optional requirement – it is not fundamental for the business. Nevertheless, if
implemented, it will increase end user satisfaction; requirement that can be applied for a generic model)
▪ W – Would not have (These requirements would not be implemented in the system but they can be
used as a reference for future development)
Note: In System Requirements section some requirements will be available only for certain users defined by
user role. The below notation will specify this requirement as:
▪ X – Where user role allows

5.1 User and business analysis
For a better understanding of the business logistics and what are the daily activities, I spent an initial 3 working
days into the shop following the business process, taking notes of the orders and the sales workflow. Two user
types emerged from discussions, interviews and personal observation of all involved parties:
• User Type 1 - Non-Technical Users:

o 20-45 year-old
o Some College education
o Sales Assistant / Low & Medium administrative role
o Native English / English at conversational level
o Not clearly understand technical terms
o Basic use of pc/mobile applications
o Lack of understanding technological concepts
o Prone to mistakes of using technological systems
• User Type 2 - Mid-Technical Users:

o 25-40 year-old
o University education
o Managerial role / High administrative
o Native English / Fluent
o Medium use of PC/mobile applications
o Able to do basic troubleshooting of PC and network connection
o Understand some technical terms but need extra clarifications over more complex concepts
This user analysis helped me to understand that the system interface must be simplified as much as possible
because users are prone to mistakes and a very complicated interface will make the project to be doomed to
failure. One of the complaints of the client with regards to similar systems that he had tried before was the
fact that they were too complicated.
For this project no questionnaire was necessary because the client was available almost anytime through direct
phone calls, emails or WhatsApp Messenger. The client was involved 100% into the project answering all my
questions and being flexible and receptive to my suggestions. It was a huge advantage to have direct access to
the client at any point during the project phases because he brought clarification on the issues. Moreover, any
changes or functions he required were handled without confusion.
However, the client was not a very technical person and the used terminology was plain and basic. Fortunately,
this aspect helped me to improve my communication skills and to be able to efficiently communicate and
explain technical aspects of a problem to a non-technical person.
With a total number of nearly 200,000 retail businesses in 2017 and a predicted of UK retail sales growth with
4.3% (Retail Economics, 2017) I seize the opportunity to enhance the system and aim to create a generic
model for retail businesses but without compromising the bespoke system for the client.
However, I was aware that some retail product details would not be compatible (e.g. food products with digital
products) and suggested that the client generalise the system and create additional categories along with sale
units (e.g. Kg, Piece, L). The client was very receptive and embraced the idea. Then I decided that instead of
hardcoding into the system this kind of features, I would enable the user to customise (e.g. manually create
categories, sale units or VAT rate).
Another requirement emerged from our discussions was the possibility of printing out details. The client
mentioned at some point that he will print out data from the browser. Then I suggested that I could integrate
a print function as PDF file and/or to export as a spreadsheet file.

5.2 User requirements
The table below containing user requirements emerged across entire project and was continuously improved.
The mandatory priority requirements were the core initial requirements. The S and C are the requirements
added along the project, following my discussions with the client and his employees.
The requirements made initially by the client are represented with green. Those in blue are my own added
requirements that are beneficial for the client as I believe they will increase the business efficiency (e.g. sale
units, categories) and/or to address issues that the client did not thought about (e.g. forgot password).
Additionally, they are suitable for a generic model.
User requirements are divided into sections, each section representing a module.
5.2.1 User registration (account)
Req. Description Priority
5.2.1.1 User must be allowed to create an account M
5.2.1.2 System should have role permission S
5.2.1.3 User account should be inactive as default S
User account should be activated only by a higher hierarchy account (e.g. admin, manager; see
5.2.1.4 S
{5.2.1.2})
5.2.1.5 User must be able to select own credentials (e.g. username, password) M
5.2.1.6 User should be allowed to register through a Facebook account W
5.2.2 User login (account)
5.2.2.1 User must be allowed to login in a secure way using a username and password combination M
5.2.2.2 System must allow the user to reset the password (in case of forgotten password) M
5.2.3 Products
5.2.3.1 User must be allowed to add products to the database (limitless) M
5.2.3.2 User must be able to add following details: Product Name, Brand, Product Details, Purchased Price,
M
Sale Price
5.2.3.3 User should be able to add a use by date for perishable products C
5.2.3.4 User should be able to add following details: Picture, Sale Unit (e.g. Kg, L, Bottle, Pack), Tax S
5.2.3.5 User must be able to create custom categories for products (e.g. Drinks) M
5.2.3.6 User should be able to create custom sub-categories for products (e.g. Drinks > Fizzy Drinks | Soft
S
Drinks)
5.2.3.7 User should be able to import products from a list (e.g. Excel file) C
5.2.3.8 User should be able to print barcode with price for products C
5.2.3.9 User should be able to print out the entire product list or only selected products S
5.2.3.10 Product should have expiration date S
5.2.4 Purchase Products
5.2.4.1 User should be able to create a purchase list (e.g. selecting N products and the quantity) S
5.2.4.2 Purchased list should contain a date of creation S
5.2.4.3 Purchase list should automatically calculate the total price of the products C
5.2.5 Sale Products
5.2.5.1 User must be able to create a sale and be recorded to the system M
5.2.5.2 User must be able to select products from products list {see 5.2.3} M
5.2.5.3 User must be able to insert customer details M
5.2.5.4 User should be able to add the VAT to the order S
5.2.5.5 System should calculate automatically the total cost C
5.2.5.6 User should be able to add custom notes to the sale S
5.2.5.7 User must be able to have and overview of sales (e.g. a list) M
5.2.5.8 User should be able to print the invoice based on the sale order C
5.2.5.9 System should be able to directly process payments with debit/credit card sales W
5.2.6 Stock Management
5.2.6.1 User should be able to have an overview of the products quantity (see {5.2.3}) M
5.2.6.2 System should automatically add the purchased products to the total stock available into shop S

5.2.6.3 System should automatically deduct the sold products from the total stock available into shop S
5.2.6.4 User should be able to add return for the purchased products and the sold products (see {5.2.4; 5.2.5}) S
5.2.6.5 User should be able to make stock adjustments for the returned products S
5.2.6.6 System should automatically add/deduct the returned products C
5.2.6.7 User should be able to transfer products between shops (warehouses) C
5.2.7 Expenses
5.2.7.1 User should be able to record an expense to the system S
5.2.7.2 User should be able to add the following details: Date, Name, Amount S
5.2.7.3 User should be able to amend (edit) the expenses S
5.2.7.4 User should be able to add custom expenses category (e.g. Rent, Utilities, Transport etc...) C
5.2.7.5 User should be able to export/print the expenses list C
5.2.8 Human resources
5.2.8.1 User must be able to add an employee to the system M
5.2.8.2 User must be able to add following details: Name & Surname, Address, Contact Details M
5.2.8.3 User must be able to record the employee attendance M
5.2.8.4 User should be able to create departments (e.g. Sales, Accounting) S
5.2.9 Accounting
5.2.9.1 User should be able to add accounts (e.g. Purchases Account, Expenses Account, Personal Account
S
etc…)
5.2.9.2 User should be able to add balance to account S
5.2.9.3 User should be able to add a payroll for an employee C
5.2.9.4 System should automatically deduct from designated account any expense (see {5.2.7}) C
5.2.9.5 System should automatically deduct from designated account any purchase (see {5.2.4}) C
5.2.9.6 System should automatically deduct payments from pre-set bank account W
5.1.10 Generating Reports
5.2.10.1 The system should automatically generate daily/monthly sales report M
5.2.10.2 The system should automatically generate daily/monthly purchases report S
5.2.10.3 The system should automatically generate daily/monthly products report (e.g. Total sold, Total profit
S
etc...)
5.2.10.4 The system should automatically generate monthly payments report S
5.2.10.5 The system should automatically generate user activity report (e.g. Employee X sales) S
5.2.10.6 The system should automatically generate client activity report (e.g. Customer X purchases) S
5.2.10.7 The system should automatically generate supplier activity report (e.g. Supplier X purchases) S
5.2.11 People (Users, Customers, Suppliers)
5.2.11.1 System administrator must be able to add other users manually (see {5.2.1}) M
5.2.11.2 System administrator should be able to validate self-registered users (see {5.2.1}) S
5.2.11.3 System administrator must be able to moderate other users M
5.2.11.4 User must be able to add customers (including contact details) M
5.2.11.5 User should be able to group customers (e.g. Walk-in, Restaurants, Hotels etc…) C
5.2.11.6 User must be able to add suppliers (including contact details) M
5.2.12 Miscellaneous
5.2.12.1 System should support multiple shops (warehouses) S
5.2.12.2 System administrator should be able to assign different role permission for the users with different views S
5.2.12.3 System administrator should be able to create another user S
5.2.12.4 User should be able select a system colour theme C
5.2.12.5 User should be able to add custom VAT rate (see {5.2.5}) M
5.2.12.6 User should be able to make exports as PDF or CSV files C
User should be able to adjust views (e.g. select only certain column or adjust number of records per
5.2.12.7 C
page)
5.2.12.8 User should be able to add own logo to the system (not core coded) C
5.2.12.9 System should be in Romanian language C
5.2.12.10 System should be able to print on a thermal printer W
5.2.12.11 System should be able to scan products through mobile POS S
5.2.12.12 System should send automatically emails when a product is low in stock C
5.2.12.13 System should send automatically SMS when a product is low in stock W
5.2.12.14 System Should be accessible through various devices (e.g. mobile phone, tablet, laptop, desktop) S

5.3 Functional system requirements
The system requirements follow the user requirement and defines the system behaviour. These requirements
will define the system functionality and a measurement method if the project was completed or not also its lay
down the path for the design and development phases.
5.3.1 User registration (account)

5.3.1.1 System registration screen must include username, email, phone number, password M
System must verify the distinctive username/email against the existing ones in the database; duplicate M
5.3.1.2
usernames/emails will not be allowed
5.3.1.3 System must validate all required fields before registering user to the database M
5.3.1.4 In case of successful registration user will be recorded to the DB and an information message will be M
returned
5.3.1.5 In case of unsuccessful registration (invalid data) the user will be notified with a message; the error will M
be highlighted (e.g. not unique email)
5.3.1.6 System must validate all required fields before registering user to the database
5.3.1.7 Encryption of the password; No retrieval as plain text M
5.3.1.8 User must be registered as inactive (active=0) M
5.3.2 User login (account)
5.3.2.1 User login page must validate the user credentials (user_name/password = 1) M
5.3.2.2 If the user credentials do not match then the user access must be denied M
On the Login screen a Forgotten Password option must be accessible; Reset password link must be
5.3.2.3 M
emailed
5.3.2.4 If the typed email address is not valid or not exists in the database the user will be notified. M
5.3.2.5 User will reset the password by clicking the link and typing a new password. M
If user decided to quit the reset password process an option to return to login/register page should be
5.3.2.6 M
available
5.3.3 Products
5.3.3.1 New products must be added through a GUI by registered and active user [X] M
5.3.3.2 User [X] must have no limit how many products will be added M
5.3.3.3 The GUI should have option of upload product image. S
The system should restrict the no of images =1 in format PNG, JPG, TIFF, GIFF (maximum picture
5.3.3.4 S
resolution 800x600 px and size of 1Mb/image)
The GUI must contain fields for: Product Name, Product Code, Purchased Price, Sale Price, Product
5.3.3.5 M
Details
5.3.3.6 The GUI should contain fields for: Brand, Tax, Sale Unit (e.g. Kg, L, Pack) C
5.3.3.7 The user [X] should be able to assign that Tax is included or not into the price C
5.3.3.8 System must allow category creation M
5.3.3.9 User [X] must be able to create custom categories and subcategories M
5.3.3.10 User [X] must be able to assign a product to a category (see {5.3.3.7}) M
User [X] should be able to assign alert quantity for a specific product (e.g. when product A < assigned
5.3.3.11 S
value in the warehouse, system will notify the user)
5.3.3.12 Products must be in 3 distinct types (Grocery, Clothing, Digital) M
5.3.3.13 Only Grocery types products should have sale units (see {5.3.3.6}) C
5.3.4 Purchase products
5.3.4.1 User [X] must be able to purchase new products using a GUI M
5.3.4.2 User [X] should be able to assign the purchase to a warehouse S
5.3.4.3 User [X] must have option to select a product from a list (see {5.3.3}) M
5.3.4.4 User [X] should be able to search for products by product code or product name (see {5.3.3.5}) S
5.3.4.5 User [X] must be able to add products to a list M
5.3.4.6 User [X] must be able to add quantity of products to list (e.g. Prod A=5; Prod B=35) M
5.3.4.7 User [X] must be able to add notes to the purchase list M
5.3.4.8 User [X] should be able to assign Tax to individual products (e.g. Prod A=10%, Prod B=0%) S
5.3.4.9 User [X] should be able to assign purchase status (e.g. ordered, pending, received) S
5.3.4.10 System should calculate automatically the total cost based on the Prod Price * Quantity S

5.3.4.11 System should calculate automatically the total cost based on the Prod Price * Quantity * Tax (per
C
product)
5.3.4.12 System must save the created list for future references M
5.3.4.13 System must add new purchased products to the warehouse total (see {5.2.6.2}) M
5.3.4.14 System should allow the user [X] to export the purchase list as PDF or CSV file S
5.3.5 Sale products
5.3.5.1 User [X] must be able to sale products using a GUI M
5.3.5.2 User [X] should be able to create a sale from a specific warehouse (for multi-warehouses) C
5.3.5.3 User [X] must have option to select a product from a list (see {5.3.3}) M
5.3.5.4 User [X] should be able to search for products by product code or product name (see {5.3.3.5}) S
5.3.5.5 User [X] must be able to add products to a list M
5.3.5.6 User [X] must be able to add quantity of products to list (e.g. Prod A=5; Prod B=35) M
5.3.5.7 User [X] must have an option to insert customer details M
5.3.5.8 User [X] should have an option to insert Tax C
5.3.5.9 User [X] must have an option to insert Notes M
5.3.5.10 User [X] should have an option to select sale status (e.g. pending, complete) S
5.3.5.11 User [X] should have an option to select payment status (e.g. paid, due, pending) S
5.3.5.12 User [X] should have an option to insert sale discount (if any e.g. 5%) S
5.3.5.13 System must record the sale M
5.3.5.14 Recorded sale must be available to the user [X] at any time M
5.3.5.15 System must allow the user [X] to update/modify the sale record at any time M
5.3.5.16 System should calculate automatically the total cost based on the Prod Price * Quantity S
System should calculate automatically the total cost of the sale based on the Prod Price * Quantity * Tax
5.3.5.17 S
(per product) – sale discount
System should automatically generate invoice based on the sale details (Customer, Product, Quantity,
5.3.5.18 S
Price/per product, Total cost (see {5.3.5.16}; {5.3.5.17})
5.3.5.19 System must automatically deduct sold products from the total available quantity (see {5.2.6.3})
5.3.5.20 Generated invoice should be stored into the system S
5.3.5.21 User [X] should be able to print invoice (as PDF file) S
5.3.6 Stock management
5.3.6.1 User [X] must be able to see all available products into warehouse using a GUI (list) (see {5.3.4.2}) M
5.3.6.2 User [X] must be able to see all quantity available for a specific product into warehouse (see {5.3.4.6}) M
5.3.6.3 User [X] must be able to adjust manually quantity for a specific product into warehouse (see {5.2.6.4}) M
5.3.6.4 User [X] should be able to transfer products (quantities) between warehouses (for multi-warehouse) S
System must automatically add product quantity to the stock when a product is purchased (see
5.3.6.5 M
{5.2.4.13})
System must automatically deduct product quantity from the stock when a product is purchased (see
5.3.6.6 M
{5.2.5.19})
5.3.6.7 User should be able to select and print/export the stock list (PDF, CSV) S
User [X] should be able to make a stock count to compare the products count from the system
5.3.6.8 C
warehouse with the products from the physical warehouse
5.3.7 Expenses
5.3.7.1 User [X] should be able to insert expenses using a GUI S
5.3.7.2 User [X] should be able to create specific categories for expenses (e.g. rent, utilities, transport) C
5.3.7.3 User [X] should be able to insert a specific expense and assign to a category C
5.3.7.4 The GUI should contain fields for: Date, Expense Name, Amount, Notes S
5.3.7.5 System should save the expenses details S
5.3.7.6 System should allow user [X] to modify expenses insert S
5.3.7.7 System should automatically calculate the total expenses C
5.3.7.8 System should allow user [X] to export/print expenses list (PDF, CSV) C
5.3.8 Human resources
5.3.8.1 User [X] must be able to insert an employee using a GUI M
5.3.8.2 User [X] must be able to create specific department for the users (e.g. sales, management, drivers) S
5.3.8.3 The GUI must contain fields for: Name & Surname, Address, City, Email, Phone M
5.3.8.4 The GUI Should have option of upload product image. C
5.3.8.5 The system should restrict the no of images =1 in format PNG, JPG, TIFF, GIFF (maximum picture
C
5.3.8.6 User [X] should be able to create user name and password for other users (see {5.2.12.3} {5.3.11}) S
5.3.8.7 User [X] should be able to record attendance for other users (e.g. Manager for staff) M

5.3.8.8 User [X] should be able to export/print employee details (PDF, CSV) S
5.3.9 Accounting
5.3.9.1 User [X] should be able to create an account using a GUI (e.g. Expenses Account, Personal Account) S
5.3.9.2 The GUI should contain fields for: Account Number, Account Name, Balance (numeric), Notes S
5.3.9.3 System should save the account details S
5.3.9.4 System should allow user [X] to modify account S
5.3.9.5 User [X] should be able to add payroll (payment for an employee) C
5.3.9.6 System should automatically deduct from designated account any purchase (see {5.2.4}; {5.3.4}) S
5.3.9.7 System should automatically deduct from designated account any expense (see {5.2.7}; {5.3.7}) S
5.3.9.8 System should automatically calculate a balance sheet (dependences {5.3.9.5}, {5.3.9.6}, {5.3.9.7}) S
System should automatically calculate detailed account statement on a defined period (e.g. today, last 30
5.3.9.9 C
days, last year) showing in/out (dependence {5.3.9.8})
5.3.9.10 User [X] should be able to print /export account details (PDF, CSV) S
5.3.10 Generating reports
5.3.10.1 User [X] should be able to access reports through a GUI M
5.3.10.2 User must not be allowed to generate SQL queries M
5.3.10.3 User must have access only at Views of the SQL queries M
User [X] should be able to select date range of the report (custom date range, last 30 days, last year, all
5.3.10.4 S
time)
5.3.10.5 System should automatically generate a summary report (including Purchases, Sales, Expenses) M
System should automatically generate an extended summary report (including {5.3.10.4}) Profit/Loss
ratio (Balance (see{5.3.9}) – Purchase (see{5.3.4}) – Expenses (see{5.3.7}) – Payroll (see{5.3.9.5}) +
5.3.10.6 C
Sale (see{5.3.5})), Payment Received (dependences{5.3.5.16; 5.3.5.17}), Payment Sent
(dependences{5.3.4.10; 5.3.4.11}), Payroll (see{5.3.9.5})
System should automatically generate product quantity alert report for warehouse (dependence
5.3.10.7 S
{5.2.3.11})
5.3.10.8 System should automatically generate daily/monthly sales report C
5.3.10.9 System should automatically generate daily/monthly purchases report C
5.3.10.10 System should automatically generate daily/monthly products report (e.g. Total sold, Total profit etc...) C
5.3.10.11 System should automatically generate monthly payments report C
5.3.10.12 System should automatically generate user activity report (e.g. Employee X sales) C
5.3.10.13 System should automatically generate client activity report (e.g. Customer X purchases) C
5.3.10.14 System should automatically generate supplier activity report (e.g. Supplier X purchases) C
5.3.11 People (Users, Customers, Suppliers)
5.3.11.1 User [X] should be able to access user accounts using a GUI M
5.3.11.2 User [X] should be able to create new users (see {5.2.1}) M
5.3.11.3 User [X] should be able to enable/disable user accounts (see {5.3.1.8}) M
5.3.11.4 User [X] should be able to create user roles (see {5.2.1}; {5.2.1.21}) M
5.3.11.5 User [X] should be able to assign user role M
5.3.11.6 User [X] should be able to update user accounts (email address, name, phone) M
5.3.11.7 User [X] should be able list users
5.3.11.8 No user must not be able to view/retrieve user password M
5.3.11.9 User [X] should be able to create customer M
The GUI must contain fields for customer: Customer Group, Name & Surname (of person of contact),
5.3.11.10 M
Company Name, Email, Phone, Address, Post Code, City
5.3.11.11 User [X] should be able list customers
5.3.11.12 User [X] should be able to create supplier M
The GUI must contain fields for supplier: Name & Surname (of person of contact), Company Name,
5.3.11.13 M
Email, Phone, Address, Post Code, City, VAT Number
5.3.11.14 The GUI should allow photo upload for supplier/logo S
The system should restrict the no of images =1 in format PNG, JPG, TIFF, GIFF (maximum picture
5.3.11.15 S
5.3.11.16 User [X] should be able list suppliers M
5.3.11.17 User [X] should be able to export/print as list users, customers and/or suppliers S
5.3.11.18 User [X] should be able to export/print as individual selection of users, customers and/or suppliers S
5.3.12 Miscellaneous
5.3.12.1 User should be able to add multiple warehouses (shops) S
The GUI should contain menu for Add Warehouse and fields Name (of the WH/Shop), Phone Number,
5.3.12.2 S
Address
5.3.12.3 User [X] must be able to create specific user roles with different permissions (see {5.3.11.4}) M
User [X] should be able to create custom VAT list (e.g. VAT 0%; VAT 5%; VAT 17.5%; VAT 20%)
5.3.12.4 S
(see {5.3.3.7})
User [X] should be able to create a Brand (e.g. Brand X can have Product A, B and C). A brand can be
5.3.12.5 C
assigned to multiple products but a product cannot be assigned to multiple brands
User [X] should be able to add custom purchase/sale units as general category (e.g. Grams, Kilograms,
5.3.12.6 C
Box, Packet) (see 5.3.3.6)
5.3.12.7 Users should be able to adjust any column view (e.g. view/print/export only specific selected column) C
5.3.12.8 User should be able to select the number of records per page (min 10, increments, max all) C
5.3.12.9 User [X] should be able to export/print any current view (PDF, CSV) C
5.3.12.10 User [X] should be able to export/print all reports (PDF, CSV) C
5.3.12.11 System should be able to print custom barcode for any product using EAN-8/13 symbols C
5.3.12.12
5.3.13 Additional System Settings
5.3.12.1 User should be able to select a colour scheme C
5.3.12.2 Colour scheme should be Neutral Grey (#34495E); Dark Red (#EAE4F8); Blue (#3498DB) C
5.3.12.3 User [X] should be able to add email settings for message forwarding S
5.3.12.4 Email settings should take advance of the host emailing for custom email S
5.3.12.5 Email settings should contain Host, Port, Custom email address, Encryption Type S
System should send automatically emails when a specific product is under stock alert low in stock
5.3.12.6 S
(dependence {5.3.3.11})
System should send automatically SMS when a specific product is under stock alert low in stock
5.3.12.7 C/W
(dependence {5.3.3.11}) – to be researched for implementation
User should be able to select a specific language (TBD what languages to be included with English as
5.3.12.8 S
default)

5.4 Non-functional system requirements
This section will define the system general behaviour that was not covered by the functional system
requirements.
5.4.1 Security requirements
5.4.1.1 In order to increase security, only one session per user will be allowed M
5.4.1.2 If the user is not logged in, they must not have access to any part of the system M
Registered user will be allowed to access only the system part set by the user group assigned to that user.
5.4.1.3 M
See [X] notations
5.4.1.4 The passwords must be encrypted and not stored as plain text M
In case of forgotten password, user will be provided with a link, sent to the user registered email, to
5.4.1.5 M
setup a new password rather than sending the password as a plain text.
5.4.1.6 Users are automatically logged out after 5 min of inactivity M
5.4.2 Portability requirements
The system migration on another server must be done with a minimum effort using the phpMyAdmin
5.4.2.1 (or equivalent) for DB export/import and FTP transfer protocol for files and folders using FileZilla M
software (or equivalent).
5.4.2.2 The migration to a new server should not make the system unavailable more than 3 hours S
The system should be available on various platforms (desktop pc, mobile devices) and devices but
5.4.2.3 S
assuring the minimum dependencies (see {5.5})
5.4.2.4 The system should be optimised for mobile devices view (adaptive screen resolution) C
5.4.3 System requirements
Under no circumstances must users be able to access any part of the physical database and/or physical
5.4.3.1 M
coded files
5.4.3.2 All aspects of the system must be accessed through a user interface M
User interface should be easy to use and natural to the end user who should be able to operate the system
5.4.3.3 S
efficiently (no more than 24hours of usage - 3 days x 8 hours)
A minimum of 20 concurrent users must be supported by the system and server without minimising the
5.4.3.4 M
performance
5.4.3.5 The system should be available without internet connection* (see {5.5}) M

5.5 Assumption and dependencies
This section covers the system functionality rules, based on the assumption that the user has the minimum
knowledge of the terms below and basic skills of using a web browser.
• Online Server – For installation a web server is required and must be available 24/7 without any
bandwidth limit and must have a minimum uptime of 99.5%. Online web server is required for remote
access and mobile devices.
• *Offline Server - For installation a local web server is required and must be available for users 24/7.
The offline server can be configured used XAMPP (or equivalent) on any laptop/desktop having Windows
/ Mac / Linux operating system. On localhost the system is available only on that particular server and any
updates are available only on that server. Offline web server is one location/one device access point.
• Web Browser - The system should be compatible across the IE11 (v11.0.110), Firefox (v59.0.1 or
later), Safari (v10.1.2 or later), Chrome (v 65.0.3325.146 or later), Opera (v 51.0.2830.40 or later), Edge
(v43.17763 or later) browsers.
▪ Note: Tablets/ mobile phones browser versions should work on all Android (v5.0 or later) / iOS
(v7.0 or later) devices. Previous versions of the most popular browsers could function but these
would not be tested. Lesser known browsers (e.g. Linx, Lunascape) may be suitable but these are
not guaranteed to work. BlackBerry, custom ROM/FW or OS devices are not tested.
• Internet Connection - 2MB/s connection (minimum). Recommended is 3MB/s for a better user
experience. For offline configuration, no internet connection is required.
• Operating System – All operating systems supporting one of the mentioned web browsers.
• Hardware
▪ Online access: The system should be compatible with any device that have an internet connection
and one of the mentioned web browsers.
▪ Offline access: For installation a minimum 750 MB HDD/SSD space
o 50 GB HDD/SSD space for operation system and database
o CPU - Minimum recommendation Intel Core2Duo 2.2 GHz / AMD Athlon Dual-Core 2.2 GHZ
o 4GB RAM – Minimum recommendation for a Central Server
o Monitor, mouse, keyboard
Note: Using the minimum hardware requirements guarantees that the system will be functional but it will
have overall performance impact (low response time from system).

6. Design
This chapter contains the system design specifications along with the decisions and reasons that led to a
specific design.
The Design chapter is focused on how to deliver the functionality that was specified in the requirements
analysis whilst meeting non-functional requirements by making high-level decisions concerning the overall
structure of the system. System design is the most creative phase of the system development and is the first
step in moving from the problem domain to the solution domain. This section is perhaps the most critical
factor of the system development affecting the implementation and the quality of the final product.
Following the literature review analysis, I found that the appropriate design strategy for this project would be
a combination of the top-bottom and bottom-top. A research paper presented at the 7th Annual Industrial
Engineering Research Conference highlights the advantages of “blending of top-down and bottom-up”
(Terpenny, Nnaji, & Bøhn, 1998) design strategies which allow the development to be customized to a wider
range of application domains.
This strategy helps me to design and develop the functionality required by the client. Furthermore, using the
combined design strategies will simplify the process to develop a generic model. Reviewing the application
at any time will have no impact over the project.
The following sections are included in the remaining of this chapter: server architecture; programming
language; colours and style; system mockups and high-fidelity prototyping; database design; assumptions and
dependencies of this project.
6.1 Server architecture strategy
In this section the chosen architecture pattern is presented and how the
project is structured at the conceptual level.
Note: The word client presented in this section is referred as a client for the
server and not the beneficiary of this project.
Following the literature review for server architectures and analysing the
advantages and disadvantages of different patterns I found that the optimal
solution for this project would be Client-Server architecture (CSA) (Figure
23).
I am considering that the CSA is the most suitable for this project because
the system needs to be accessed from various locations and devices (cross-
platform) Figure 23 – Client-server architecture
(Abstract) [Primary Source]
One of the advantages of CSA is the fact that the application files and the
database are installed on the same location (server). The system is modelled as a cluster of the different objects,
which is interacting with the database through a request handler. Using this architectural pattern, a successfully
communication between objects is a key element. None of the intermediate results, which are created through
the interaction, has to be visible to the Clients. To make an analogy, we can say that the server will act as a
“black-box”, which will return only the final results to the user (Figure 24 – For a bigger size picture please
see Appendix K).

Figure 24 – Conceptual level server architecture [Primary Source]
To ensure a clear communication of the components between Client and Server, the system was divided in
four major sub-systems: Client-side Application, Server-side Application, Server Handler and Database. By
decomposing the processes on the server, followed by user interaction it leads to the integration of an object-
oriented design pattern. The Client application is separated into two subsections, the Client component
(Browser) and Client User Interface (CUI). All user inputs are taken over by the CUI and forwarded to the
server API where most of the processes are handled and the result is returned to the user through User
Interface. All data stored on client device are temporary therefore the impact on the user device is minimum.
The centralised control of the server offers the advantage of quick implementation of any future changes
without any disruption for the Client or just a minimum downtime until the new features are implemented
(usually no more than 1-2 hours).
One of the disadvantages of the Client-Server architecture is the single point of failure. If the server is not
working (e.g. hardware fault, power fault, data corruption, hacking etc.) the entire system is inaccessible.
Following my discussions with the project beneficiary he accepted this trade-off and we have agreed on a
mirroring solution to overcome this issue. However, this solution is still in the preliminary stage and would
be considered once the system is fully developed and approved by the client.
6.2 System design
In this section I am presenting the principal system functions as Unified Modelling Language (UML) use
cases.
Use Cases are an excellent high-level (and implementation independent) starting point for describing
functionality and the relation between system and user (Narang, 2015). For this project I am using the standard
UML use case diagram, consisting of a use case diagram, with success/fail scenarios, triggers and success
measurements for each case. A brief narrative description of the flow events is held alongside the diagram for
each individual use case. The use cases are very effective because they are relatively informal, yet help to
define and capture a problem space in detail. (Foster, 2014).
The actors (admin, user/s) presented in use cases are potential users of the system, performing specific
activities. The scenario presents a theoretical response from the system to the user actions. The use case
presents the main flow of events (when no errors are signalled) and the alternative flow when user performs
abnormal actions not defined into main flow of events. Users notated with [X] are the users defined as where
user role allows defined in Requirements chapter.
Note: In this section only the following use cases are presented because the use cases are taking a
considerable amount of space:
Login (UC1) ● Logout (UC2) ● Registration Process (UC3)
For the complete series of use cases please see Appendix B to J where the following use cases are present:
Settings (UC4) ● Warehouse (UC5) ● Role Permission (UC6) ● Products (UC7) ● Product Purchase (UC8)
● Sale (UC9) ● Expenses (UC10) ● Accounting (UC11) ● Stock (12)

Use case name: Use case number: Primary actor(s):
Login process UC- 1 User(s)
Description: This use case describes the login process into system which is a key function of the system. In this use case, the
actor's goal is to login to the system.
Data: (Input) User name and password
Success Measurement: The actor is successfully redirected to the system dashboard
Trigger: None (Login page is index page)
Pre-condition: The actor must have an active account into the system
[MF] Main flow of events:
1. The use case starts when actor opens the index page of the system (e.g. www.domain.co.uk/; localhost/)
2. System displays Login Page and prompts the actor to input their login credentials (user name/password)
3. Actor inputs the required information (user name/password)
4. Actor clicks login button
5. System background script compares user name/password against the user name/password stored to database
6. System authenticates the actor and starts a session
7. System releases user account
8. System informs the actor of successfully login
9. Actor is redirected to the system dashboard associated with that particular user logged in
[AF] Alternate flow of events:
3a. No user with the input information or wrong information inputted
1. The system informs the actor about fail (credentials do not match any record) and does not allow the actor to login
2. Actor is returned at MF 2 (no change).
Post-condition: Login successful!
Special requirements: Internet connection for online system; None for offline system
Figure 25 - Use case for Login module [Primary Source]

Logout UC- 2 User
Description: This use case is for the logoff from the system.
Data: None
Success Measurement: The actor is successfully logged out from the system
Trigger: Actor clicks the Logout button
Pre-condition: Actor must be logged in to the system
1. The use case starts when actor clicks the UserName button
2. Actor clicks Logout button
3. System ends user session
4. System deletes user session
5. System informs the actor of successfully logging off
6. System redirects the actor to the index
None
Post-condition: User successfully logged out of the system and redirected to the index page
Figure 26 - Use case for Logout module [Primary Source]

Registration process UC- 3 User(s)
Description: This use case describes the registration process into system which is a key function of the system. In this use case,
the actor's goal is to register into the system. The process is composed of two steps: Registration and Activation. Actor is
inactive at the registration.
Data: (Input) User details registered to the database
Success Measurement: The actor is successfully registered into system with inactive account
Trigger: User clicks the Register link on index page
Pre-condition: Actor must not have an active/inactive account with registered email address or another registration in process
1. The use case starts when actor clicks the Register link
2. System displays Registration Form and prompts the actor to input registration details (user name, email, phone number,
select role (the role actor registers for – e.g. staff) password and password confirmation)
3. Actor inputs the required information
4. Actor clicks Register button
5. System background script checks if the password matches in both fields
6. System background script compares user name against the user names in the database (unique required)
7. System background script compares email address against the emails in the database (unique required)
8. System registers the new user to the database assigning pending activation status (inactive).
9. System informs the actor of the successfully account registration to the system and the need of account activation
5a. Password does not match in both fields
1. The system informs the actor about the password mismatch
2. Actor is returned to MF 3
6a. User name already exists in database
1. The system informs the actor about the already existing user name
2. Actor is returned at MF 3
7a. Email address already exists in database
1. The system informs the actor about the already existing email address
2. System displays “login” message
Post-condition: Account registration successful
Figure 27 - Use case for Registration process [Primary Source]

6.3 System UI mockups and high-fidelity prototyping
In this section I am presenting the system user interface mockups. Mockups are simple designs created with
Balsamiq software and shows at a very low level how the UI should look like and what actions could be
effectuated. The mockups were shown and discussed with the client before creating a more advanced
prototype.
The initial mockups changed slightly overtime due to different functionalities and implementations added but
the general layout structure was preserved (e.g. Left side dash board, buttons sizes and functionality etc.).
Many functions were implemented on the go creating dynamic views by coding and re-using blocks of code
rather than creating new designs.
Login and Registration
The LOGIN and REGISTRATION screens (Figure 28) are simple forms that allow user to login and register
into the system and check the credentials against ones stored into the database.
Figure 28 - Login screen (LEFT); Registration screen (RIGHT) [Primary Source]
Settings
SETTINGS screen (Figure 29) where user can change

the system interface, language, theme colour, date
format that is stored into database, business name and
logo.
Figure 29 - General settings screen [Primary Source]

Categories
Before adding a product to the database, a CATEGORY must be created (Figure 30) and a product will belong
to that specific category. A category may have one or more subcategories (e.g. Drinks as main category and
Soft Drinks, Fizzy Drinks Alcoholic Drinks as sub-categories). This feature will allow the user to sort products
on different criteria and there is no restriction on how many categories can be created.
Figure 30 - Products category list (LEFT); Create a new category (Right) [Primary Source]
Products
Once the category is created user can add a variety of products to the database (Figure 31). Must be noted that
adding products to the database would not be counted into the STOCK. A product quantity must be added to
the stock (see Figure 32). This is useful for the client to populate all the products he trades. The products will
be added to the stock every time when stock is changed rather than typing product details every time. A
product may be available in database as a record but can be out of stock. When product becomes available,
the client just adds the quantity of product to the stock.
Figure 31 - Products list where the user can see the entire available stock (LEFT); Add a new product to system (RIGHT) [Primary Source]

Figure 32 - Adding products to stock. (LEFT); Stock counting (Right) [Primary Source]
Customers & Suppliers
The client can find any supplier by consulting the suppliers list (Figure 33). Supplier details (name, company
email, etc.) can be exported as a PDF file or CSV. All suppliers and customers can be searched by name,
company (if available) or email address.
Figure 33 Suppliers list (LEFT); Create a new supplier (Right)

Groups and Role Permission
The system administrator has full control over group roles Figure 34. The admin role cannot be deleted and
can create unlimited additional roles each one of them with own permission. The permissions are granted
after the role is created using a simple matrix where admin just selects / deselects the permissions according
with user role.
Figure 34 - Group roles (LEFT); Group roles permissions matrix (RIGHT) [Primary Source]
Expenses
Expenses module (Figure 35) provides calculation of expenses for each warehouse and additional notes can
be added to bring clarification if required.
Figure 35 – Expenses List (LEFT); Adding a new expense (RIGHT) [Primary Source]

High Fidelity Prototype
Once the initial mockups were
drawn and discussed with the client,
the mock-up was transformed into
high fidelity prototypes using Axure
prototyping software (Figure 36).
One of the Axure feature is the
ability of exporting the design as
HTML/CSS pages and speeding up
the development process.
Figure 36 - High fidelity prototyping with Axure (Product List) [Primary Source]
Figure 37 - Current system dashboard (Left); High fidelity prototyping with Axure (Right) [Primary Source]
Note: The current system contains many other elements into the dashboard (Figure 37). Most of them were
added through reusing the code and creating new views, without having a mock-up in advance. Further
information about views can be found in Implementation chapter.
6.4 Colours, Style and Icons
My aim in this section is to explain why a multicolour theme was selected. A

short description of the used icons and an example how easily can be integrated
it is presented as well.
Colour scheme
The colour base of Albert Butcher LTD is white and a dark-red colour (#A1191C)
therefore the client insisted that the system will be mainly in red colour. Figure 38 - Albert Butcher front
shop [Primary Source]

However, after a careful consideration and reading a study done by CBA organisation where is highlighted
the fact that 3% of UK population are affected by a form of what we know generally as colour blind (Colour
Blind Awareness, 2018), I decided to examine a solution to overcome this issue.
Taking into consideration that the business employs men and women alike and in the future an employee may
have a visual condition, I decided to extend the colour scheme (Figure 40) and to offer alternatives to the
users, rather than only one colour.
The colours are represented as hex code (e.g. #FFFFFF - White) in order to keep same colour regarding the
device screen type.
In order to enhance the end user experience, I am considering to implement a theme colour switch
functionality. User will be able to change from system settings with a simple click. The red colour is the colour
preferred by the client, grey colour (#34495E) is a neutral colour suitable for people affected by colour
blindness, blue (#3498DB) and green (#1ABC9C) colours are the most preferred colour by the man and women
where purple (#65337B) is preferred by 23% women (Batagoda, 2017).
Figure 40 - Theme base colours [Primary Source]
Figure 39 - Most liked colours by men and women (Batagoda,

2017)
General Layout
One of the aims of this project was to keep the layout as simple as possible with enough space between buttons
to be easily pressed on a touch screen device (e.g. a tablet). Using a responsive grid layout increased the
development speed without the need for multiple designs for different devices. Moreover, the layout resembles
a spreadsheet which is a familiar layout for many users. The responsive pages, are automatically adjusted to
the device screen they are accessed from.
Figure 41 - General layout of the system – User List (Left); Sale list (Right) [Primary Source]
All related menu and options are available on left hand side, clearly labelling the menu context and the user
does not need to navigate into endless options to find a specific function.

Icons
All icons used in this project are free, part of the Bootstrap framework and they are powered by Font Awesome
(https://fontawesome.com). There are several advantages of using font icons instead of creating each icon
individually:
✓ Increased performance
✓ Vector format suitable for any screen
resolution
✓ Time saving (they just need to be called
through one HTTP request)
✓ CSS effect support and autoscaling in size
✓ Standard industry icons used by almost any OS
(therefore are easy recognisable by the user)
✓ Easy to integrate into the project and save the
disk space compared with any other PNG, JPG
or GIF format icons
Another advantage of using suggestive icons along
with written labels, is the fact that humans have a
pictographic cognitive memory (McLeod, 2015).
It would be easier to associate an action to a
imagine (icon) rather than a text, therefore even for Figure 42 - Font Awesome icons
non-English speakers associating an icon to a (https://fontawesome.com/icons?d=gallery&m=free)
function will be easier for them.
Figure 43 - Sample of icons used into the projects
To integrate icons into a page just a small line of code it is required
<i class="fa fa-dashboard"></i>
where the icon needs to be placed and dashboard is the name of the icon. An implementation into the page
can be seen in Figure 44.
Figure 44 – Icons implementation example [Primary Source]

6.5 Database Design
In this section I am aiming to bring clarity over database selection process and the logical design.
Following the analysis of databases from section 2.3 for this project I decided to use MySQL Database.
However, at this time being no significant difference between MySQL and MariaDB in terms of design
constraints and SQL syntaxes I can say that the project supports dual database. At this point the system can
be very easy migrated/adapted MariaDB but this compatibility is not guaranteed for future versions of MySQL
and MariaDB.
For this project SQLite was not suitable because, as analyses showed, this database is suitable for low-memory
embedded devices, with no server connection. If I decide at a later point to extend the database this will be a
real issue because SQLite does not have a very good scalability.
Although the PostgreSQL has positive reviews for the queries performance, it is aimed for very complex
queries suitable for data warehouse type databases. For this project I do not consider that this amount of
complexity is necessary. Moreover, PostgreSQL contains a couple of syntaxes I am not familiar with and the
documentation seems confusing.
I will present the logical and physical design of database further in this section. dbForge software allows the
logical design to be exported to physical design producing automatically the required SQL code. Therefore,
the logical and physical design were developed simultaneously.
Before attempting the database design, I created the business logic flow as a unified modelling language
(UML) diagram (Figure 45). Creating the UML diagram, helped me to understand better how to design the
database and how entities are interconnected with each other.
Figure 45 - RBMS UML processing (Logic flow of the system) [Primary Source]

Database was progressively created (Figure 46) and the design was changed several times until the final
version emerged. New tables or attributes were added to the database when a new function was developed.
Figure 46 - Databased design and creation with dbForge [Primary Source]
In Figure 47 and Figure 48 the system logic translated into database logic can be observed. The system was
broken down into separate entities that create the database.
The design and creation of the database was done at the same time due to dbForge powerful feature of being
able to design and create tables/attributes in the same. Furthermore, being able to test the database in real time
was another advantage.
Note: In Figure 48 the visual connections between the tables were removed for a better view of the table attributes, were in Figure
47 the connection between entities are shown along with the primary and foreign keys.

Figure 47 – Final database ERD with PKs and FKs [Primary Source]
Figure 48 – Final database including PKs, FK and all attributes [Primary Source]

6.6 Development Programming Language and MVC Framework
In this section I am presenting the chosen programming language and the MVC framework that I am
considering appropriate for this project.
In my second year I have undertaken the Web Script unit that was based on Node.js and JavaScript. I
personally struggled with Node.js programming language and considering the complexity of the project I
realised that lack of my knowledge may jeopardise this project.
Analysing the ASP.Net programming language, which has a complex page structure and unclear configuration
setting, made me aware of the time constraints for learning a new programming language in depth enough to
address the complex issues of this project.
Therefore, after a careful consideration I decided to use PHP programming language for this project as the
main programming (scripting) language without the need for exploring and learning a new programming
language (such as C# & F#) but rather to deepen the knowledge I already had. In addition of PHP, HTML,
CSS JavaScript libraries are used.
However, even with the knowledge already possessed this project was a very challenging task. A task that
concluded not only with increasing programming skills and learning of new techniques but in addition it
helped with communication and other soft skills.
Once I decided the programming language to choose an MVC framework for this project was another difficult
decision. The MVC model must support the following features:
✓ CRUD operations (Create, Read, Update, and Delete)
✓ Minimal code has maximum impact (support for code reuse)
✓ Rapid learning curve
✓ Scalable framework
✓ Actively developed and maintained by a core team
✓ Strong community support
Following my analysis among numerous frameworks for PHP 3 potential candidates remained:
▪ CodeIgniter (https://codeigniter.com)
▪ CakePHP (https://cakephp.org)
▪ Laravel (https://laravel.com)
The first eliminated was CakePHP because the syntaxes seemed
to be too complex, documentation was not easy to understand
and according to a research article, CakePHP has a very slow
response time (Botwe & Davis, 2015) for GET and POST
compared with other frameworks.
With the two remained frameworks the initial choice was
CodeIgniter due to previous experience to work with.
Unfortunately, the CodeIgniter being managed by a company is
quite slow to catch up with modern technologies (Stauffer,
2017) and features brought by industry. Therefore, the
modularity of Laravel prevailed. Laravel allows division of a
project into small modules where CodeIgniter does not have Figure 49 - Laravel test code example [Primary Source]
this flexibility.
Modular development feature was one of the main factors that led to the decision to use Laravel PHP
framework as backbone of the project, as well as the excitement to learn a new technology. The modular

approach will help with the incremental development method. Another factor supporting my decision of using
Laravel as framework was the integration of continuous testing (Figure 49) compared with CodeIgniter where
this is only partially supported. Of course, there were other factors taken into account to sustain the decision,
such as object-oriented event driven functionality, custom HTTPs routes, a well-established supporting
community along with full integration of Bootstrap and jQuery.
The main sources of research the system development with Laravel, besides Laravel official documentation,
forums and technical websites were 3 books: “Laravel up & Running” by Matt Stauffer, “Laravel 5 Essentials”
by Martin Bean and “Laravel 5.x Cookbook” by Alfred Nutile.
For an additional information and a summarised comparison between frameworks please see Appendix A.
6.7 Assumptions and Constraints
In this section I am briefly highlighting the constraints of this project where the following requirements are
mandatory for system functionality. These requirements are requested by programming language and
framework presented in previous section.
System was developed and tested on a dual system with PHP v7.2.0/MySQL v5.7 and PHP v7.3.0/Maria DB
v10.1. The system should work on any server with PHP v7.0+ and MySQL v5.0.n / MariaDB v10+.
The recommended server to deploy this system on is Apache/Nginx but it can be installed on any server with
PHP/MySQL support.
Assumption: The RBMS user has the basic skills of operating a computer and how to navigate
through web pages.
Installation Constraints: Initial installation of the system must be done by an experienced user with
knowledge about server installation / configuration, upload files to a server using FTP protocol or server
management GUI, MySQL import/export procedure, editing the configuration file where the server settings
details are stored.
Server constraints: PHP version 7.0+, Mod Rewrite Enabled
Mandatory Extensions: OpenSSL; Fileinfo; Mbstring; Tokenizer; Zip Archive; PDO & PDO
MySQL driver; Curl

7. Implementation & Testing
This chapter covers the main steps taken on the development process providing screenshots and instructions
of setting the development environment. Modules development, files structure and the tests results are
presented in this chapter as well.
For this project I have purchased a hosting server (http://uop.cloud) to allow the client to preview the
application anytime. However, for development and continuous testing I used a local server installed on my
personal computer. Using a local server eliminated the network delays and was easier to work with local files.
For the development stage the following tools were necessary: XAMMP; Visual Studio Code; Laravel
framework; Gimp; dbForge; various packs and libraries presented in section 1.5 of this document.
For this phase the main focus was to transform the static HTML pages into dynamic pages integrating the
required PHP code because the system VIEWs (details in section 7.2) were already created in high-fidelity
design phase.
7.1 Project development environment setup
In order to start the development of this project a local server was setup on a Windows based operating system.
The setup process is a straightforward process of downloading the executable available on XAMPP website
and following the install steps. Full instruction of the local server download, setup and possible
troubleshooting can be found at https://www.apachefriends.org/faq_windows.html.
The XAMPP comes with all the necessary tools preinstalled to run the MySQL/Maria DB database, HTML,
PHP, JS and JQ files.
Figure 50 - XAMPP Local Server setup [Primary Source]
The next step was to bring the theoretical design of the database as physical design into the server by directly
importing it from dbForge software. To import into XAMPP server we can choose one, out of two methods:
✓ Setup a direct connection between dbForge and XAMPP, where the DB is directly created.
Instructions available at https://docs.devart.com/studio-for-mysql
✓ Importing into XAMPP as SQL file http://localhost/phpmyadmin > Import.
Figure 51 - DB import into XAMPP

Database has evolved since the early days of the project and more tables were added to work with the new
modules. On each iteration database was populated with dummy data and several queries were executed,
according with the module requirements and business needs, to test the database integrity.
Figure 52 - Database creation and testing query [Primary Source]
Once the database core functions were functional the PHP framework was installed on the server. Full
installation of the Laravel PHP framework can be accessed at https://laravel.com/docs/4.2#install-laravel.
Note: Database functionality can be tested independent of PHP or Laravel
Figure 53 - Laravel installation and connection to the database [Primary Source]

7.1 Project development modules
In this section I am aiming to present technical aspects of creating the connection between modules and
database in order to return results to the user. Creation of different modules will be presented in this section
as well. Due to length and complexity of PHP/HTML/CSS code only fragments of the code will be shown
(some files having over 700 lines of code).
PHP & Laravel
In order to send the request to the controller in Laravel framework a ROUTE must be defined (Figure 54). Each
route is a definition of the path to be followed by any module to interact with core functions or other modules.
Routes are placed in a file in routes folder. These routes files get loaded and generated automatically by
Laravel framework. Each module in the project is an independent piece of software adding functionality to
the whole system. The requests are notated like standard PHP with: GET, POST, PUT, DELETE.
Additionally, the route may be redirected from one module to another using:
Route::redirect('/here', '/there');
Further information and full description of routing are available on Laravel website
(https://laravel.com/docs/5.8/routing).
Note: Laravel terminology may be confusing for a beginner or for someone working for the first time with
this framework. A better description of routing is available from Chris Sevilleja
(https://scotch.io/tutorials/simple-and-easy-laravel-routing)
Figure 54 - Routing with Laravel

Laravel as MVC Framework
Once the connection is done (the route is defined) the user needs to have a visual
interaction through a front-end graphical interface with the system functions and
database. The graphical interface is achieved through a PHP template engine
integrated in Laravel, named Blade. The files need to be placed in
resources/views folder. Consequently, these files are sometimes called VIEW
file/s (or blade).
View files are basic HTML files that allow the user to interact with system
functions in a natural way. The whole process is controlled by a piece of code,
named CONTROLLER. The controller takes user inputs, manipulates the request Figure 55 - Module creation
and it passes the result back to the user through the VIEW. pattern with PHP MVC [Primary
Source]
The MODEL is a piece of code that defines which tables/fields in the database are
accessed by the view and controller. Each module of the system has its own group of view/model/controller.
In essence, the CONTROLLER (Figure 56) is the logical flow of a module; MODEL(Figure 58) is the link and
VIEW (Figure 57) is the visual interface for the user.
Each module may have one or more controllers and one or more associated views. Breaking down a module
into smaller controllers, helped me to debug faster any error associated with a specific function.
Figure 56 - Controller file for Products [Primary Source]

Figure 58 - Model file for Products [Primary Source]
Figure 57 - View file for Products [Primary Source]

Another example of how a controller handles a request we can see in Figure 59. This function returns a VIEW
to the user to add a new product. Firstly, it checks if the logged user has the permission to add a product (line
42,43). If the user has the right permission the controller will return the view PRODUCT.CREATE and the
associated database fields defined by model. Alternatively, the user will be informed that is not allowed to
access the module. In Figure 60 there are presented models, controllers and views of the system.
Figure 59 - Add product function with user authorisation [Primary Source]
Figure 60 - Final models, controllers and views of the system [Primary Source]

File and Folders Structure
I consider that one of the key aspects to creating modular systems is the organisation of files and folders.
Having a chaotic structure and project increasing in functionality, can soon become overwhelming. At a later
stage of development can be really difficult to figure out what is the purpose of a specific file, folder or
function.
Therefore, since the beginning I have been keeping a logical structure for the files, the file name representing
the functionality. For example, for the model all the file names are named on what model they define (e.g.
Sale.php, User.php, Warehouse.php); the controllers file contains the word controller (SettingController.php,
CustomerController.php etc.); view files contain the word blade and grouped in functionality folders
(create_sale_blade.php, profile_blade.php etc.). I am using word blade for views due to the naming convention
suggested by Laravel and the templating engine provided with the framework (Laravel, n.d.).
Figure 61 - Naming convention of files and folders [Primary Source]

Language Module
In this section my aim is to explain how an multilanguage system can be created and overcome any linguistic
barriers that end-user may experience.
The business employees are English/Romanian speakers but most of them understand and speak English at a
very basic level. Therefore, I had been requested to build the system in Romanian. However, I did not consider
that to be a practical solution due to the following:
▪ ‘How the customer will understand the labels, if all the system labels are in Romanian, when an invoice
is printed out?
▪ ‘What if a non-Romanian speaker will be employed? Will the client change the system or force the
new employee to learn a system in a foreign language?’
▪ ‘What if in the future a new law will require that all systems used in UK retail market must be in
English? Will the client change the system or translate everything?’
Hence, I came with a practical solution of a multilanguage system. I already had all technological means
provided by framework. Laravel framework provides the option to place all the text labels of HTML files on
a single file inside the language folder. This technique requires to create a table in database where each
language has an ID. Furthermore, each language has its own file translated from a default language (in this
case English) then the controller changes the system language based on user preferences. For example, if the
user selects X language where language id =2 the controller simply returns the text labels for the X language.
In Figure 62 we see the example of how a multilanguage solution can be relatively simple implemented on
any system based on a PHP framework. The model has a single entry as Language (left); the function defined
in controller (middle) takes user input and returns the associated text (right) for the front-end user.
Figure 62 - Multilanguage Module [Primary Source]
Another advantage of having a multilanguage system with English as default language, is the fact that a non-
English user may improve their English. By using the system frequently in English and being able to revert to
native language anytime if something is unclear, it could help the user.
At this point the system is available in 3 languages (English, Romanian and Turkish) (Figure 63) because
these are the languages I speak fluently. However, it can be translated virtually in any language just by adding
a translated file from English to that language.
Figure 63 - Language module HTML & Output [Primary Source]

7.2 Coloured theme implementation
A similar technique that was applied to multilanguage problem previously presented it was also, applied to a
multi-colour theme. The difference is that the system returns the full CSS file associated with a specific
colour.
The themed styles implemented in this project are all similar as integration and CSS files code, duplicating 5
times and each file with its own colour (Figure 64). A simple function placed in settings controller allows
the user to change a preferred colour scheme.
public function changeTheme($theme)
{
$rbms_general_setting_data = GeneralSetting::latest()->first();
$rbms_general_setting_data->theme = $theme;
$rbms_general_setting_data->save();
}
Figure 64 - CSS Files
Furthermore, each CSS style is coded into view file using basic HTML code and the user is able to select a
colour (Figure 65). The function coded in controller reads the user input and saves the preference into
database.
Figure 65 - Style integration through HTML & PHP (Left); Front-end user view (Right)

7.3 Testing
In this section my aim is to present two methods applied in testing phases. First method is an automatic
integration testing technique where a software automatically tests the system against a set of predefined
parameters. The second method is visual performance testing where the system is manually inspected by
simulating various devices views.
The first method includes automated tests performed at the logical level of the system. This method will test
the code integration and any incompatibilities, error or bugs between modules. The second set of tests were
visual tests carried on the desktop screen and various viewpoint of mobile devices (mobile phone/tablet).
Automatic Integration Testing
Katalon Studio automatic test functionality is an excellent tool for writing and maintaining test scripts. The
carried tests are divided into four types:
▪ Unit Testing – analyses a small piece of code in isolation without being dependent on other function
▪ Integration Testing – built on top of unit testing and combines two or more functions/modules
▪ Functional Testing – follows the integration and tests if the results provide same output as required by
the end-user
▪ Acceptance Testing – this test checks if the output meets the requirements by checking the flow not
the functionality
For each function/module a test script is written defining what a particular function should do. The html/php
code is how the function/module will act. The script validates (or invalidates) what against how. If the test
validates all what parameters then the test will pass, otherwise will fail.
Once the script is completed, the same test would run continuously without rewriting the script. The software
provides useful feedback when a test failed making debugging very easy. A screenshot of the initial setup can
be seen in Figure 66. In Katalon I have created a logical structure of folders where the future test can be
grouped, based on modules and individual unit test of a specific function.
Figure 66 - Setting test unit with Katalon Studio – New Project (Left); Project default setup (Middle); Added test units for RBMS (Right)
[Primary Source]
The script is partially automatically generated by Katalon software and only the testing parameters need to be
specified. The script below is a unit test that checks for user name function.

Figure 67 illustrates a functional test script for the login module. The test failed several times (left picture) but
after the error was fixed following the useful information provided by debug function, the login function
passed the test (right image).
Figure 67 - Login test case [Primary Source]

Another example of test unit can be found in Figure 68 where settings had not been saved into the database
initially but after the code was modified, the settings test passed with some warnings. The warnings flagged
because the test unit was written to use SSL connection but on the development system a non-SSL connection
was used.
Figure 68 - Test case for Settings (save and record to the database) [Primary Source]
Testing unit provides different detailed views of the test result, to be easier to debug a problem or to understand
why a test parameter was highlighted as warning.
However, a passed test does not guarantee a bug-free system, because it is impossible to cover all possible
variants of test parameters. Visual testing and continuous testing of all the functions when a new module was
added is a key factor to reduce possible errors and bugs that may appear. For example, implementing a new
module and not testing against already incremented modules can create issues at a later stage of the project
and it would be extremely difficult to trace the original issue.
For a full view of the test cases please see the test root explorer in Appendix L.
Visual and Performance Testing
In this stage most of the tests were carried through Chrome Browser using the available option of Developer
Tools (Figure 69). This offers a wide range of pre-sets devices and creates viewpoint for each device, along
with different performance testing and simulation of online/offline environment. However, at a later stage
some tests were carried on real physical devices.
Figure 69 - Chrome Browser 'Developer Tools' [Primary Source]

Using the developer tools provided by Google Chrome browser various tests were carried out. These tests
were useful to analyse the page load performance and to check if the device views are responsive to different
screen sizes and/or devices (Figure 70).
Figure 70 - Page load performance test (Left); Login View point (Right) [Primary Source]
In Figure 71 different stages of visual testing are presented, carried with a physical mobile device (iPhone
Xs). These tests required an internet connection and the system was accessed through a live server
(http://uop.cloud).
Figure 71 - Different stages of mobile phone testing [Primary Source]
Setting up a live server was immensely valuable for me and for the client to save time. The client had the login
credentials to the live testing server and after each incrementation he directly tested the application with the
new implemented functions, providing constructive feedbacks sometimes immediately, sometimes no later
than couple of days. One of the feedbacks sent be the client can be observed in Figure 72.

Figure 72 - Client feedback email

8. Evaluation
In this chapter my aim is to assess the project development and critically evaluate the solution by comparing
the user requirements with the implemented features into the system. In section 8.1 a summary of system
functionality is listed. It comprises the bespoke features and those I believe are enhancing the system, as well
as applying to a generic model. A series of screenshots of the most implemented features are ending the chapter
(section 8.3)
I am aware that the system cannot be fully evaluated as a generic model with other business at this time.
However, I strongly believe that the additional implemented features are suitable as generic functionality for
other similar business. Due to the system modularity, if another business has a specific request, I am confident
that a solution can be found.
The system was primarily developed around a grocery shop and I believe when the client will extend his
business activity with clothing and digital products new issues may appear (e.g. a warranty note may need to
be added into product details or manufacturer country).
8.1 System functionality
In this table
Core functionality bespoke for the business
No Description Status
Users account – functionality to register users and securely store the user name and password details into the
1 Complete
database; Password reset function.
Users Role - admin should be able to create, manage, delete other users; admin should be able to assign
2 Complete
different roles to other users.
3 Products – functionality to add a range of products to the system Complete
4 Custom Tax – functionality to add differential VAT rates to each product Complete
5 Expire date of products – functionality to alert the user when a product is about to expire Incomplete
6 Sale of products – functionality to keep track of sold products Complete
7 Invoice – functionality to automatically generate an invoice based on a customer and sold products Complete
8 Scan Sale – functionality to scan a product barcode and be automatically deducted from stock Incomplete
Stock Management – functionality to keep track of in/out products (purchased products from suppliers – sold
9 Complete
products to the customers)
10 Stock Notification – functionality to alert user when a particular product is under-stock in the system Complete
11 Email Notification - functionality to alert user when a particular product is under-stock through email. Incomplete
12 Customers/Suppliers – functionality to have lists with customer/supplier details Complete
13 Expenses – functionality to record into the system different expenses that occurred during a month Complete
14 Reports – functionality of printing out: a daily/monthly list of sales; daily/monthly list of purchases Complete
15 Multi Warehouse – functionality to have separate warehouses (shops) and stocks Complete
16 Cross-platform – functionality for the system to be accessed from a range of devices Complete
17 Online/Offline – functionality for the system to not be dependent on an internet connection Complete
18 Language – system to be available in Romanian language Complete
Additional features that enhance the system and are suitable as a generic model
No Description Status
Enhanced Product Details – product picture upload; automatic product code generator; notes; purchase
1 Complete
price and sale price in different columns;
2 Product Category – customisable categories for products Complete
Product Barcode – automatic barcode generated for print to be stick on a product (this barcode can be used
3 Complete
later on to implement a scan product function)
4 Product Sale Unit – customisable unit sale (e.g. Kg, g, Piece, Pint, Pack etc.) Complete
5 Brands – a customisable list of brands where more than one product can belong to a specific brand Complete
6 Stock Count – functionality to compare digital stock with physical stock Complete

Complete
Manual Stock Adjustment – functionality to manually add/subtract products from a stock (e.g. in case
7 (Partial
that the business returns a product to a supplier or a customer return a product to the business)
Tested)
Automatic Calculations – total of sold products (with/out VAT); shipping cost (if any); product discount
8 Partially
(if any); order discount (if any); grand total (taking in account previous listed costs)
Accounting – multiple accounts setup with an initial balance; expenses are automatically deducted from Complete
9 selected account; purchases are automatically deducted from selected account; sales are automatically (Partial
added to selected account; manual adjustments of any account Tested)
HR – employee list (an employee is not necessary a system user); employee attendance; customisable
10 Complete
departments
Enhanced Reports – customisable summary report with date range selection for purchases, sales, profit/loss
11 Complete
calculations, expenses; graphic charts
12 Customer Groups – customisable groups for customers (e.g. hotels, supermarkets etc.) Complete
13 Enhanced User Roles – full customisable user roles Complete
14 PDF & CSV Export – functionality to export any data as a PDF file or CSV file Complete
15 Multilanguage – English, Romanian, Turkish (possibility to add any other language) Complete
Colour Theme – 5 base colours (including client desired colour and a colour suitable for people with colour
16 Complete
blind visual impairment)
17 Logo Upload – customisable business logo upload suitable for any business Complete
18 System Rename – customisable system name to reflect business name Complete
User Manual - interactive user manual integrated into the system where the user may find information Under
19
regarding system functionality Development
POS System – an interface suitable for touch screen devices (a tablet) where a user to add an in-store sale Early
20
and the system to calculate total price Development
8.2 Non-Achieved objectives and system flaws
In this section my aim is to discuss the system features that have not been implemented until this point and
the system limitations. However, some of these flaws and missing features I will address them in future
updates of the system.
Stock adjustment - One of the system flaws identified by the client during the testing phase was the fact that
there was no possibility to make stock adjustments after a stock-count was carried out. In order to address this
problem, I will be introducing a stock-adjustment module, where the user will be able to edit the current stock
and add/extract the number of products from stock.
Batch integration – Another flaw of the system identified during the development of the project, but due to
lack of knowledge it was not possible to implement until this stage, is an efficient batching system. Some
products sold by the client have different expiration dates. Therefore, the client ensures that the products near
the expiry date are sold first constantly. A batching system should permit the user to assign different expiration
dates to the same product and alert the user when a specific batch is near its expiration date. A temporary
solution of this problem was to add a note field into purchase section where the client types any relevant note
about that specific purchase for his reference.
The batch method will be useful if the same product is purchased from multiple suppliers. It will help the
client to identify which supplier provided a specific product. Moreover, I am considering that a batching
system will be very useful for a business that sells medicines (a pharmacy), where expiration dates are critical.
Automatic email notification – One of the client requests was to be notified when a particular product is in
stock below a pre-set quantity. At the current stage of the project, the client is notified through the dashboard
but the system does not send email notifications to the admin. However, during my discussion with the client,
we considered this is not a crucial factor and it can be reviewed at a later stage.
During the testing phase of the system with other employees in the store, I was asked many times ‘what does
this button do or the other’. In order to address this issue and to clarify different functionalities of the system
to a potential user I am planning to implement an interactive user manual (Figure 73). A second PDF manual

will be provided along with the system, describing step by step, the system functionality and features,
including installation, initial setup and all functions of the system.
Figure 73 - Creating the user manual [Primary Source]
8.3 Implementation Evidence
✓ Registration and Login function; Forgot Password, User List; User Role; Role Permission; Languages;
Customisable Business name; Currency; Logo; Colour Theme
Figure 74 - Login, User List, User Role, Role Permissions; Language; Settings [Primary Source]
✓ Products List; Product Details; Barcode generator
Figure 75 Product list; Product Details; Barcode [Primary Source]
✓ Stock Management; Stock Count; Quantity alert
Figure 76 - Stock Management; Stock Count; Quantity alert [Primary Source]

✓ Customers/Suppliers Management
Figure 78 - Customers List (Left); Suppliers List (Right) [Primary Source]
Figure 77 - Add a new customer (Left); Add a new supplier (Right) [Primary Source]
✓ Customisable VAT function; Customisable sale unit
✓ Sales Report –
Figure 79 - VAT Tax & Sale Units

✓ Purchase list; Sale List; Status Notifications; Accounting Calculations
Figure 80 - Purchase List (Top); Sale List (Bottom) [Primary Source]
✓ Expenses List; Expenses Categories; Adding a new expense
Figure 81 – Expenses List (Top); Expenses Categories (Bottom-Left); Add Expense (Bottom-Right) [Primary Source]

✓ Accounting – Multiple accounts; Summary per account; Detailed account transactions
Figure 82 - Account (Top); Account balance sheet (Middle); Account statement (Bottom) [Primary Source]

✓ HR Management – Employees List; Attendance Recording; Customisable Departments
Figure 83 – Employees List (Top); Attendance Recording (Middle); Departments (Bottom) [Primary Source]

✓ Various reports output – Products report (Overview of products in stock); Monthly sale report;
Custom date range sale report; Custom data summary report; Graphic Chart Report; Best sold
products
Figure 84 - Products report (overview) [Primary Source]
Figure 85 - Monthly sale report [Primary Source]
Figure 86 - Custom dates sales report [Primary Source]

Figure 87 – Custom dates summary report [Primary Source]
Figure 88 - Graphic chart report [Primary Source]
Figure 89 - Best sale report [Primary Source]

9. Future Improvements
In this chapter I would like to discuss potential features and functionality that could complement the system
to be more flexible and suitable for a larger pool of users and/or business.
The client uses the application on testing server and we created a second instance of the application where he
started to add his products to the database. He is planning to use it as the only system for his business
management once all products, customers and suppliers are added to the system. As soon as all the data is
inserted, the client will migrate the system to his own server.
Following my discussion with the client, who was delighted with the system capabilities which covers all his
requirements and many more other features, we found that the system can be further improved:
• An implementation of a POS (point of sale) screen that can be accessed through a touch screen
monitor suitable for direct sale in store (walk-in customers). This feature is in a very early
development phase at the moment of writing
• A solution for separated batches for the same product (e.g. with different expiration dates or different
manufacturer)
• Integration of a barcode scanner, where sold products to be scanned and automatically deducted from
stock, rather than typing them
• Integration of automatically debit/credit card processing on sale through Barclays payment solutions
• A mobile phone message alert when a particular product/s in understock (probably a WhatsApp
plugin integration)
• To increase security a 2-way factor authentication for online server

10. Conclusion
This chapter is my personal review and reflection on the project.
I have found this project really challenging and I have learnt many lessons during the development. The most
significant lesson that any programmer, project manager or software engineer should be aware of, is planning.
Planning ahead is essential as will not save only time and money but also is a decisive factor for the project
success or failure. Needless to say, I was unable to predict 100% all the challenges that the project encountered.
Hence, the communication emerged.
I have been aware since my 2nd year that for the final year an engineering project must be submitted therefore,
I was extremely pleased when Mr Ovidiu D. (the client) approached me and asked if I could help him with a
solution for his business. When he explained me the problems he was facing, I knew that creating a bespoke
system would be the ideal topic for my final year project. It was a real advantage that the client was always
available, answering all my questions at any time (sometimes we were chatting at 2am). I believe that if I had
chosen a conceptual idea without working with real client, I would not have been able to deliver a complex
system.
The Introduction to Software Engineering (INSE) unit I took it in 2nd year at the University of Portsmouth,
was a cornerstone for this project. Many methods, logic approach and ways of handling complex projects are
a result of this unit. Even if I had previous experience with handling small and medium size projects, I always
adopted a sit and do it approach, rather than an exhaustive planning.
The biggest risk I took was choosing an unfamiliar framework for development. This was the first time to
work with Laravel. Previously I opted for CodeIgniter framework, but I was determined to succeed and learn
something new at the same time. Thus, Laravel was the optimal selection. Not only that the project has evolved
beyond its initial purpose, to create a stock management system with few other functionalities, but I believe
that, it has also become a full standalone business management system yet with opportunities for further
enhancements.
My previous coding experience and probably being a mature student have enabled me to approach this project
from a different perspective than probably I would have done in my 20’s. There were a lot of new things to
learn and having some technical skills does not make me a successful developer or programmer. I have learned
that one must have the following soft skills: time management, effective communication, adaptability problem
solving and creative thinking.
Taking on an individual project, I had to wear different hats: as a designer, a coder and a student who learned
a new framework. I had to improve my technical and soft skills. It was challenging to take several crucial
decisions but also to keep up with the project timeline and other university related deadline. I maximized my
time management skills to make sure that all the tasks were getting the proper attention.
Another lesson learned during this project is the value of simplicity. One of my goals was to maintain a high
standard across the entire application and to keep it simple. I strongly believe that extensive over-engineered
systems definitely cause more unnecessary problems than under-engineering systems. Therefore, my focus
was on writing the code in a clean and elegant manner, as well as retaining conventional functions and file
naming.
However, I envisage that simplicity it is not always an option for multiple teams working together on large
projects.

Bibliography
Agile Alliance. (n.d.). Agile 101. Retrieved from AgileAlliance.org: https://www.agilealliance.org/agile101/

Agile Manifesto. (n.d.). Manifesto for Agile Software Development. Retrieved from AgileManifesto.rog:
https://agilemanifesto.org/principles.html
Almyta Systems. (n.d). ABC Inventory Software Features. Retrieved from Almyta Systems.
Alomari, Z., Halimi, O. E., Sivaprasad, K., & Pandit, C. (n.d.). Comparative Studies of Six Programming
Languages. Retrieved from arXiv.org: https://arxiv.org/ftp/arxiv/papers/1504/1504.00693.pdf
Ballou, R. H. (1997). Business logistics: importance and some research opportunities. Gestão & Produção,
117-129.
Bassil, Y. (2012). A Simulation Model for the Waterfall Software Development Life Cycle. International
Journal of Engineering & Technology, 742-749.
Batagoda, M. (2017, Sep 18). Color, psychology and design. Retrieved from UX Planet:
https://uxplanet.org/how-color-can-effect-emotion-ccab0431b1d
Bell, M. (2016). Incremental Software Architecture: A method for saving failing IT implementations.
Hoboken: Wiley.
Bennett, S., McRobb, S., & Farmer, R. (2005). Object-oriented Systems Analysis and Design Using UML.
McGraw Hill Higher Education.
Beynon-Davies, P., Carne, C., Mackay, H., & Tudhope, D. (1999). Rapid application development (RAD):
An empirical review. European Journal of Information Systems, 211-223.
Boehm, B. W. (1988). A Spiral Model of Software Development and Enhancement. Computer, 21(5), 61-72.
doi:10.1109/2.59
Botwe, D. A., & Davis, J. G. (2015). A Comparative Study of Web Development Technologies Using Open
Source and Proprietary Software. International Journal of Computer Science and Mobile Computing,
154-165.
Brett. (2017, Oct). Zoho Inventory Software. Retrieved from Software Advice:
https://www.softwareadvice.com/inventory-management/zoho-inventory-profile/
Colour Blind Awareness. (2018). Types of Colour Blindness. Retrieved from Colour Blind Awarness.org:
http://www.colourblindawareness.org/colour-blindness/types-of-colour-blindness/
Dai, G., Bai, X., & Xu, D. (2006). A Tuple-Space-Based Coordination Architecture for Test Agents in the
MAST Framework. IEEE International Symposium on Service-Oriented System Engineering, 1, 57-
66. doi:10.1109/SOSE.2006.6
DB-Engines. (2018, Nov). DB-Engines Ranking. Retrieved from DB-Engines.com: https://db-
engines.com/en/ranking
DB-Engines. (2018, Dec). DB-Engines Ranking - Trend Popularity. Retrieved from db-engines.com:
https://db-engines.com/en/ranking_trend
Diana, R. (2016, May 13). The Big List of 256 Programming Languages. Retrieved from DZone.com:
https://dzone.com/articles/big-list-256-programming
Endrei, M., Ang, J., Arsanjani, A., Chua, S., Comte, P., Krogdahl, P., . . . Newling, T. (2004). IBM Patterns:
ServiceOriented Architecture and Web Services. International Business Machines Corporation .

Engelhardtsen, F. B., & Gagnes, T. (2002). Using JavaSpaces to create adaptive distributed systems.
Retrieved from Norwegian Informatics Conference: http://www.nik.no/2002/Engelhardtsen.pdf
Erl, T. (2005). Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. New
Jersey: Prentice Hall.
Foster, E. C. (2014). Software Engineering: A Methodical Approach. New York: Apress.
Garlan, D., & Shaw, M. (1994). An Introduction to Software Architecture. Retrieved from Carnegie Mellon
University - School of computer science:
https://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf
Gov.Uk. (2014, Feb 4). VAT rates on different goods and services. Retrieved from gov.uk:
https://www.gov.uk/guidance/rates-of-vat-on-different-goods-and-services
Hanselman, S. (2013, Feb 18). Released: ASP.NET and Web Tools 2012.2 in Context. Retrieved from
Hanselman.com:
https://www.hanselman.com/blog/ReleasedASPNETAndWebTools20122InContext.aspx
Hines, M. (2004, Aug 18). Ford scraps Oracle-based procurement system. Retrieved from CNN.com:
https://www.cnet.com/news/ford-scraps-oracle-based-procurement-system
Huhns, M., & Singh, M. (2005). Service-oriented computing: key concepts and principles. IEEE Internet
Computing , 9(1), 75-81. doi:10.1109/MIC.2005.21
Laravel. (n.d.). Blade Templates. Retrieved from Laravel.com: https://laravel.com/docs/5.8/blade
Laravel. (n.d.). The PHP Framework For Web Artisans. Retrieved from Laravel.com: https://laravel.com/
Lee, G., & Xia, W. (2010). Toward Agile: An Integrated Analysis of Quantitative and Qualitative Field Data
on Software Development Agility. MIS Quarterly, 34(1), 87-114. doi:10.2307/20721416
Lucia, A. D., & Qusef, A. (2010). Requirements Engineering in Agile Software. Journal of Emerging
Technologies in Web Intelligence , 2(3), 212-220. doi:10.4304/jetwi.2.3.212-220
Malvi, K. (n.d.). The Positive and Negative Aspects of Node.js Web App Development. Retrieved from Mind
Inventory: https://www.mindinventory.com/blog/pros-and-cons-of-node-js-web-app-development/
MariaDB. (n.d). About MariaDB. Retrieved from MariaDB.org: https://mariadb.org/about/
McLeod, S. (2015). Cognitive Psychology. Retrieved from Simply Psychology.org:
https://www.simplypsychology.org/cognitive.html
Microsoft. (2019). SQL Server pricing. Retrieved from microsoft.com: https://www.microsoft.com/en-
gb/sql-server/sql-server-2017-pricing
Microsoft. (n.d.). ASP.NET. Retrieved from Microsoft: https://dotnet.microsoft.com/apps/aspnet
Morris, J. (2001). Software Industry Accounting. New York: Wiley.
Mowbray, T. J., & Malveau, R. (2003). Software Architect Bootcamp. Prentice Hall.
MySQL. (2018). MySQL Restrictions and Limitations. Retrieved from MySQL.com:
https://downloads.mysql.com/docs/mysql-reslimits-excerpt-5.5-en.pdf
Narang, R. (2015). Software Engineering: Principles and Practices. New Delhi: researchers Harlan Mills
and Niklaus Wirth.
Nutschan, C. (2008, Aug 27). Spiral model (Boehm, 1988).png. Retrieved from WikimediaCommons.org:
https://commons.wikimedia.org/wiki/File:Spiral_model_(Boehm,_1988).png

Odoo. (n.d.). Modern online warehouse management software. Retrieved from odoo.com:
https://www.odoo.com/page/warehouse
Oracle. (2010). Overview and Frequently Asked Questions. Retrieved from Oracle.com:
https://www.oracle.com/us/assets/038563.pdf
PostgreSQL. (n.d). A Brief History of PostgreSQL. Retrieved from PostgreSQL.org:
https://www.postgresql.org/docs/8.4/history.html
Pressman, R. S. (2010). Software Engineering: A practitioner's approach. New York: McGraw-Hill
Companies Inc.
Ray, L. L. (2013). Security considerations for the spiral development model. International Journal of
Information Management, 33(4), 684-686.
Reenskaug, T. (2007, Feb 12). The original MVC reports. Retrieved from University of Oslo:
https://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf
Retail Economics. (2017). UK Retail stats & Facts. Retrieved from RetailEconomics.co.uk:
https://www.retaileconomics.co.uk/library-retail-stats-and-facts
Richardson, C. (2018). Pattern: Monolithic Architecture. Retrieved from Microservice Architecture:
https://microservices.io/patterns/monolithic.html
Rieuf, E. (2016, Dec 16). History of MySQL. Retrieved from Data Science Central:
https://www.datasciencecentral.com/profiles/blogs/history-of-mysql
Royce, W. W. (1970). Managing the development of large software systems. Retrieved from University of
Southern California: http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
ScaleGrid. (2019, Mar). 2019 Database Trends – SQL vs. NoSQL, Top Databases, Single vs. Multiple
Database Use. Retrieved from ScaleGrid: https://scalegrid.io/blog/2019-database-trends-sql-vs-
nosql-top-databases-single-vs-multiple-database-use/
Sommerville, I. (2011). Software Engineering. Boston: Pearson.
SQLite. (n.d.). Documentation. Retrieved from SQLite.org: https://sqlite.org/docs.html
Stauffer, M. (2017). Laravel Up & Running: A Framework for building modern PHP Apps. Sebastopol:
O'Reilly.
Terpenny, J. P., Nnaji, B. O., & Bøhn, J. H. (1998, May 9-10). Blending Top-Down and Bottom-Up
Approaches in Conceptual Design. Retrieved from SemanticScholar.org:
https://pdfs.semanticscholar.org/d132/f55a11d3bc90eca431a9dd1381cc6b1a4773.pdf
W3C. (2004, Feb 11). Web Services Architecture. Retrieved from W3C Working Group Note:
https://www.w3.org/TR/ws-arch/#service_oriented_model
W3Techs. (2018, Mar 28). Usage of server-side programming languages for websites. Retrieved from
W3Techs Web Technology Surveys:
https://w3techs.com/technologies/overview/programming_language/all

Appendix
CakePHP CodeIgniter Laravel

Pros Cons Pros Cons Pros Cons
• Open source • Complex • Open source • Prove to be • Open source • To implement on
MVC framework documentation MVC framework difficult with MVC framework a large application
• Search engine from initial • Light framework code • Very scalable and a bit complex
friendly URLs understanding • Well organised maintainability powerful framework
• Built in libraries perspective documentation • Not really OOP framework • Complex two-way
• Built in • Not very suitable • Friendly code • Fixed named • Reusable binding process
validations for web syntaxes convention components for routing
• Huge community application-based • Ideally for which limits • More
support projects beginners or flexibility functionality can
• Faster • Mainly works on simple projects • Partial support be implemented
performance on inline templates • Hassle free for PHP7.x using less code
small data sets • No modular migration • Fast response
• Automated server development between servers time on large
configuration • Limited testing • Easy datasets
process units support configuration and • Huge support
• Core • Slow response customisation of from 3rd party
implementation of time for large core files libraries
Object Relational datasets • Plugins support • Two-way data
Mapping • No data binding • Fast VIEWs binding process
process creation for • Large community
• Document- templating support
oriented • Rich sets of • Dynamic HTML
• One-way routing libraries attributes
• No support for • Object-oriented
PHP 7.x • Backtrack of
changes
• Full support of
PHP7.x
Appendix A - Frameworks comparison table

System Settings UC- 4 Admin
Description: This use case is general system settings (system name change, logo, time zone, date format, currency)
Data: (Input) Record general system settings into database
Success Measurement: The settings successfully recorded into the database and applied for all users
Trigger: Actor clicks the Settings > General Settings button from dashboard
1. The use case starts when actor clicks the General Settings button
2. System displays dashboard menu associated with General Settings
3. Actor selects a new logo image (if available)
4. Actor inputs the required information (Site Title* (default RBMS), Currency* (default GPB), Date Format* (default
dd/mm/yyyy), Colour Theme* (default Purple #65337B), Language (default English))
5. Actor click Submit button
6. System background script checks if all mandatory fields are completed
7. System records the new settings to database
8. System applies new general settings to all users
9. System informs the actor of the successfully new settings update
6a. One or more of the mandatory fields are not completed
1. The system informs the actor about the missing information (highlighting the field)
Post-condition: New settings are successfully applied to all users
Figure 90 - Use case for Settings module
Appendix B – Use case (Settings)

Warehouse UC - 5 Admin; User]X]
Description: This use case describes the creation of the warehouse (shop)
Data: (Input) Warehouse data into database
Success Measurement: The warehouse is successfully registered to the database and active
Trigger: Actor clicks the Settings > Warehouse button from dashboard
Pre-condition: Actor must be logged into the system; Actor must have user permission to create a Warehouse; A similar name
warehouse (shop) must not be registered into database
1. The use case starts when actor clicks the Warehouse button
2. System displays dashboard menu associated with warehouse(s)
3. Actor clicks Add Warehouse button
4. Actor inputs required information (Name*, Address*, Phone Number*, Email)
5. Actor clicks Submit button
7. System background script checks if the warehouse name exists into database
8. System records the new created warehouse to database
9. System informs the actor of the successfully Warehouse record to the system
7a. Warehouse name already exists in database
1. The system informs the actor about the already existing warehouse name
Post-condition: Warehouse recorded successful
Figure 91 - Use case for Warehouse module [Primary Source]
Appendix C – Use case (Warehouse)

Role Permission setup UC- 6 Admin; User]X]
Description: This use case describes the creation of role permissions. The process is composed of two steps: Role Creation and
Assign Permissions (for created role)
Data: (Input) Record role permissions (group) into database
Success Measurement: The specific permission is successfully assigned to created role
Trigger: Actor clicks the Settings > Role Permission button from dashboard
Pre-condition: Actor must be logged into the system; Actor must have user permission to create a Roles; A similar role name
must not be registered into database (e.g. Admin)
1. The use case starts when actor clicks the Role Permission button
2. System display dashboard menu associated with Role
3. Actor click Add Role button
4. Actor input required information (Name* (of the role –e.g. ‘Staff’), Description (of the role))
7. System background script checks if the role name exists into database
8. System records the new created role to database
9. System informs the actor of the successfully Role record to the system
10. Actor clicks Action button associated with new created role
11. Actor clicks Change Permission button (by default no permission is selected for new created role)
12. Actor selects the permissions for new created role (group permissions)
14. System records the permissions to associated role
15. System informs the actor of the successfully permission update
7a. Role name already exists in database
1. The system informs the actor about the already existing role name
Post-condition: Role and associated permissions recorded successfully
Figure 92 - Use case for user Permission Matrix module [Primary Source]
Appendix D - Use Case (Permissions)

Products UC- 7 User[X]
Description: This use case is for adding a product to the database.
Data: (Input) Records a product into database
Success Measurement: The product is successfully recorded into the database
Trigger: Actor clicks the Product > Add Product button from dashboard
Pre-condition: Actor must be logged in to the system; Product Category must be available (pre-recorded) into database; Brand
must be available (pre-recorded) into the database if a product is associated with a brand; Unit must be available into database
(pre-recorded); Tax must be available (pre-recoded) into database (default is no Tax)
1. The use case starts when actor clicks the Add Product button
2. System displays dashboard menu associated with Add Product
3. Actor selects a product image (if available)
4. Actor inputs required information (Product Name*, Product Code*, Product Type*, Product Category*, Brand, Purchase
Unit*, Sale Unit*, Purchase Price*, Sale Price*, Tax, Product Descriptive Details)
7. System background script checks if the Product Name exists into database
8. System background script checks if the Product Code exists into database
9. System records the new created product to database
10. System informs the actor of the successfully record to the system
7a. Product Name already exists in database
1. The system informs the actor about the already existing product name
8a. Product Code already exists in database
1. The system informs the actor about the already existing product code
Post-condition: Product is successfully recorded to the database
Figure 93 - Use case for Product Module [Primary Source]
Appendix E - Use Case (Products)

Purchase (Add to stock) UC- 8 User [X]
Description: This use case is to purchase a product to warehouse (add a product to stock)
Data: (Input) Record the purchase
Success Measurement: The purchase is successfully added to the stock of the warehouse
Trigger: Actor clicks the Purchase > Add Purchase button from dashboard
Pre-condition: Actor must be logged in to the system; Warehouse must be available (pre-recorded) into database; Supplier
must be available (pre-recorded) into database; Product must be available (pre-recorded) into database; Tax must be available
(pre-recorded) into database (default ‘No Tax’)
1. The use case starts when actor clicks the Add Purchase button
2. System display dashboard menu associated with Add Purchase
3. Actor select the required Warehouse*
4. Actor select the Supplier (if the purchase is from an pre-recorded supplier)
5. Actor select the Product(s) for purchase (searching by Product Name or Product Code)
6. Actor input the quantity to purchase for each product
7. Actor select the Tax for the order
8. System automatically calculate the Grand Total of the order
9. Actor select purchase status (Ordered | Pending | Received)
12. System records the new purchase to database
13. System add new products to the warehouse stock (if purchase status = received)
14. System informs the actor of the successfully purchase of products
5a. Actor decide to delete a product
1. Actor press the Delete button of that particular product from the purchase list
2. System delete the product from the list
3. Actor return to MF 5
Post-condition: Purchase list added to the database and products added to the warehouse stock if the [MF]-13 is true
Figure 94 - Use case for Purchase modules (Add to stock) [Primary Source]
Appendix F - Use case (Purchase)

Sale UC - 9 Actor: Admin; User [X]
Description: This use case is to create a sale to a customer. This case do not define the walk-in customers but regular customers
(e.g. hotels, restaurants, markets)
Data: (Input) Record the sale
Success Measurement: The sale is successfully added to the database of the warehouse
Trigger: Actor clicks the Sale > Add Sale button from dashboard
Pre-condition: Actor must be logged in to the system; Warehouse must be available (pre-recorded) into database; Customer
must be available (pre-recorded) into database; Product must be available (pre-recorded) into database; Tax must be available
(pre-recorded) into database (default ‘No Tax’)
1. The use case starts when actor clicks the Add Sale button
2. System display dashboard menu associated with Add Sale
3. Actor select the required Warehouse*
4. Actor select the Customer (if the sale is to a pre-recorded customer)
5. Actor select the Product(s) for purchase (searching by Product Name or Product Code)
6. Actor input the quantity to sale for each product
7. System automatically calculate the Total of the order
8. Actor select the sale Tax for the order (default ‘No Tax’)
9. Actor input additional discount (if is any)
10. Actor input shipping cost (if is any)
11. System automatically calculate the Grand Total of the order
12. Actor select sale status (Completed | Pending)
13. Actor select sale payment status (Pending | Due | Partial | Paid)
14. Actor add additional sale notes (if any)
17. System records the new sale to database
18. System deducts the products to the warehouse stock (if sale status = completed)
19. System informs the actor of the successfully sale of product/s
5a. Actor decide to delete a product
1. Actor press the Delete button of that particular product from the sale list
2. System delete the product from the list
Post-condition: Sale list added to the database and products deducted from the warehouse stock if the [MF]-18 is true
Figure 95 - Use case for Sale module [Primary Source]

Appendix G - Use Case (Sale)

Expenses UC - 10 Actor: Admin; User [X]
Description: This use case is to add an expense amount to the database.
Data: (Input) Record the expense
Success Measurement: The expense is successfully added to the database
Trigger: Actor clicks the Expense > Add Expense button from dashboard
Pre-condition: Actor must be logged in to the system; Warehouse must be available (pre-recorded) into database; Category
must be available (pre-recorded)
1. The use case starts when actor clicks the Add Expense button
2. System displays a pop-up menu associated with Add Expense
3. Actor select the required Expense Category*
4. Actor select the Warehouse* where the expense was occurred
5. Actor type the amount of expense
6. Actor additional note (if any)
9. System records the new expense to database
10. System informs the actor of the successfully process
5a. Actor decide to cancel
1. Actor press the close window button
2. System cancel the process
Post-condition: Expense is added to the expenses list
Figure 96 - Use case for Expenses module [Primary Source]

Note: The diagram represents the entire Expenses module, were UC is to add an expense to the module
Appendix H - Use Case (Expenses)

Accounting UC - 11 Actor: Admin; User [X]
Description: This use case is to add an account to the system, with a predefined amount to the database. The system will deduct
any expense/purchase from the account, providing an automatic generated balance sheet
Data: (Input) Record an account
Success Measurement: The account is successfully added to the database
Trigger: Actor clicks the Accounting > Add Account button from dashboard
1. The use case starts when actor clicks the Add Account button
2. System displays a pop-up menu associated with Add Account function
3. Actor type the required account number (as unique identifier)
4. Actor type the required account name (as cognitive identifier)
5. Actor type the amount of initial account balance
6. Actor additional note (if any)
9. System background script checks if account number it does not exists to the database (account no ≠ exists)
10. System background script checks if account name it does not exists to the database (account name ≠ exists)
11. System records the new account to database
9a. Account number exists to the database (account no = exists)
1. The system informs the actor about the matching information (highlighting the field)
10a. Account name exists to the database (account name = exists)
1. The system informs the actor about the matching information (highlighting the field)
Post-condition: Description
Figure 97 - Use case for Accounting module [Primary Source]

(Note: The diagram represents the entire Accounting module, were UC is to add an account to the module
Appendix I - Use Case (Accounting)

Stock counting UC - 12 Actor: Admin; User [X]
Description: This use case is to see if are any differences between the system stock and physically stock
Data: (Input) Record a stock counting
Success Measurement: The stock comparations is successfully and added to the database
Trigger: Actor clicks the Stock > Stock Count button from dashboard
Pre-condition: Actor must be logged in to the system; Warehouse must be available (pre-recorded) into database;
1. The use case starts when actor clicks the Stock Count button
2. System displays the menu associated with Stock Count function
3. Actor select the required Warehouse
4. System return all available products of that specific warehouse, along with the recorded number of items as ‘Expected’
5. Actor type the physically Counted number of each product
6. System background script calculates any difference between system products and physical in warehouse products
7. System background script returns the difference between (Expected - Counted)
8. System background script returns the Cost difference
9. System background script calculates and return in real time the Total Cost difference
10. Actor save the results
11. System records the new Stock Count to database
3a. Mandatory fields are not completed
1. The system waits until the warehouse is selected
Post-condition: Description
Figure 98 - Use case for Stock Counting module [Primary Source]
Appendix J - Use Case (Stock Counting)

Appendix K - Server Architecture (Large) [Primary Source]

Appendix L - Test cases root explorer

Appendix M - Project Timeline


Retail Business Management System

Загружено:

Сведения о документе

Авторское право

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Retail Business Management System

Загружено:

Авторское право:

BSC (Honours) Computing

Retail Business Management System

Project unit: PJE40

Word count: 29655

Valentin Adamescu PJE40 - RBMS Page 1 of 105

Valentin Adamescu PJE40 - RBMS Page 2 of 105

Valentin Adamescu PJE40 - RBMS Page 3 of 105

Valentin Adamescu PJE40 - RBMS Page 4 of 105

Valentin Adamescu PJE40 - RBMS Page 6 of 105

Valentin Adamescu PJE40 - RBMS Page 7 of 105

Valentin Adamescu PJE40 - RBMS Page 8 of 105

Figure 1 - Albert Butcher business flow (Abstract) [Primary Source]

Valentin Adamescu PJE40 - RBMS Page 9 of 105

• Simple enough to be learned by non-technical users but also

• Low stock alert of a particular product

Valentin Adamescu PJE40 - RBMS Page 10 of 105

1.2 Aim and objectives

Valentin Adamescu PJE40 - RBMS Page 11 of 105

1.3 Current practice and problems

Albert Butcher (AB) LTD business process

Valentin Adamescu PJE40 - RBMS Page 12 of 105

1.4 Proposed solution

Valentin Adamescu PJE40 - RBMS Page 13 of 105

Valentin Adamescu PJE40 - RBMS Page 14 of 105

Valentin Adamescu PJE40 - RBMS Page 15 of 105

1.7 Legal, ethical, professional and social issues

Valentin Adamescu PJE40 - RBMS Page 16 of 105

In order to develop a new system efficiently, I must take into

Valentin Adamescu PJE40 - RBMS Page 17 of 105

2.1 Available systems

Figure 5 - XERO Software trial account [Primary Source]

Valentin Adamescu PJE40 - RBMS Page 18 of 105

• ZOHO Inventory (https://www.zoho.com/uk/inventory)

Figure 6 - ZOHO Inventory trial account [Primary Source]

Valentin Adamescu PJE40 - RBMS Page 19 of 105

2.2 Programming Language

Table 2 - Programming Language vs Scripting Language [Primary Source]

In order to accelerate the development phase and the project

Valentin Adamescu PJE40 - RBMS Page 20 of 105

Is a server-side, cross-platform free framework developed by

PHP is usually associated with MySQL database and many hosting

Valentin Adamescu PJE40 - RBMS Page 21 of 105

Table 3 - Node.js files request handling vs PHP/ASP [Primary Source]

Valentin Adamescu PJE40 - RBMS Page 22 of 105

Figure 11 - Databases ranking trends over the years (DB-Engines, 2018)

Criteria MySQL PostgreSQL SQLite MariaDB

Valentin Adamescu PJE40 - RBMS Page 24 of 105

2.4 System architecture

Monolithic architecture is a single-tiered software application where the data

What makes iterative development slower is the tendency of the organizations

Valentin Adamescu PJE40 - RBMS Page 25 of 105

Client-server architecture (CSA)

Client-server architecture is a pattern based on sharing the workloads

Service-oriented architecture (SOA)

SOA is an architectural pattern that utilizes services as fundamental

Valentin Adamescu PJE40 - RBMS Page 26 of 105

Object-oriented architecture (OOA)

2.5 Design Strategies

Design Activity Resultant Design Spec Component

Valentin Adamescu PJE40 - RBMS Page 27 of 105

As an analogy we can perceive the design techniques as a

Valentin Adamescu PJE40 - RBMS Page 28 of 105

3.1 Waterfall Model

Waterfall model, first suggested by Dr Winston Royce in 1970, is

Table 6 - Waterfall model advantages and disadvantages [Primary Source]

3.2 Agile Model

Table 7 - Agile model advantages and disadvantages [Primary Source]