CHAPTER 4:DESIGN PHASE

4.1 Introduction
One wouldn’t attempt to build a house without a blueprint. Pressman (2011) define design as
an expressive engineering depiction of a software to be built. This phase entails themain
matters of concern when it comes to software design which are; data, interfaces, architecture
and components. These design activities are then used to produce the procurement system
that meets the stated specifications, satisfying the functional requirements specified in the
analysis phase. The objectives specified in the first chapter should be satisfied by the
outcomes of this stage.
The system designer carries out the following activities in design:
 Architectural design
 Database design
 Interface design
 Program design
 Physical design
 Test design
In designing the new system, the designer has kept the following in mind, so as to come up
with a quality system; user friendly interfaces, security, confidentiality, effectiveness, system
reliability, maintainability and report generation.
 User friendly interfaces – the interface should help provide easy to follow
instructions and should not give suppliers a hard time in using it.
 Security – there should be restriction to unauthorized users, procedures and policies
should be put in place for recovery and dealing with faults, breaches of security, and
system failures by using a database
 Confidentiality – only those users with passwords should access the system and
hence will protect the confidentiality of information. Each user will be entitled to
viewing specific information which fall under his job specifications.
 Report generation – presentation of reports is very essential as they are part of the
outputs and facilitate decision making.
 Effectiveness- A well-engineered system should be easy to work with and its use
must bring benefits and/or reduction of costs. The users should be able to find their
way round the system comfortably (Eppinger, 2000).
 Reliability- The ability of a system to consistently perform its intended function on
without failure. A well-designed system should be reliable and be able to solve
problems faced in the existing manual system (Eppinger,2000).
 Maintainability- maintainability deals with two aspects; serviceability (ease of
conducting scheduled inspections and servicing) and reparability (ease of restoring
 service after a failure). The proposed system must be easy to maintain and it should
give room for improvement and evolution(Eppinger,2000).
4.2.3 System Inputs
 Supplier’s details – these are the details of all the suppliers who will be on online
procurement system.
 Order details- details of products that needs to be purchased.
 Quotations – details of product prices
4.2.4 Processes and Procedures
Options available to suppliers;
 View quotation requests sent by the Kwekwe Polytechnic’.
 View emails on updates of goods to be delivered.
 Upload quotations to Kwekwe Polytechnic’
 Upload a Declined Request for quotation and give a reason to Kwekwe Polytechnic’
 View current scorecards which measures the performance with respect on-time
deliveries, price and product availability.
Options that will be available for Kwekwe Polytechnic’ procurement department (buyer);
 Download and print suppliers’ quotation
 View goods in stock
 Viewing and evaluating suppliers’ scorecards to select the best supplier
 View emails sent by suppliers
 Sending a request for quotation to a supplier
Options that will be available to Kwekwe Polytechnic’ management
 View reports for purchase requests(approved ,held and declined)
The System Administrator options are as follows
 Responsible for updating the website
 Adding, deleting and editing suppliers
 Run Backups of the database
 Maintenance of the web site
 Update changes in the system database
4.2.5 System outputs
 Reports of purchases made
 Online suppliers scorecards

METHOD EXPLANATION
Logical Database Design This comprises of the use of logical data
models to model the proposed system, such
as the Entity Relationship models and the
data dictionaries.
Program Design Involves the design of classes, functions and
modules of the proposed system and outlines
how queries are designed.
Physical database Design Involves logical data and process models
produced using the Entity Relationship
model in the logical design phase is
conveyed into anoperational database.
Physical Architecture Design Provides a description of the practicaland
technical platform on which the new system
will run by defining the logical and physical
layout of the system that is, the
specifications of hardware, data, software,
procedures and the users involved
Software Architecture Design Describes how the software components of
the proposed system are going to interact
and integrate to form the whole system
Interface Design This deals with the Human-Computer
Interface, the design of the user sees and
communicates with the system.
Table 4.1: Description of System Design Process Activities
4.2 Description of the Proposed System
The proposed system is to be a procurement system integrated with a web interface which
will enable suppliers and Kwekwe Polytechnic’ to exchange quotations and order requisitions
online rather than using telephone or emails.
 4.2.1 Context diagram of the proposed system
Delivery Quotations
Procurement officer
Procurement
Stock availability Reports manager

Scorecards

Order requisition select supplier

Stock requisition
Procurement System
Delivery
Quotations payments Requisitions
Invoices and receipts

Order requisition Invoices and receipts

Supplier Accountant
Quotation request
Payments
Fig 4.2 Context diagram of the proposed system
Key
Entity

System

Interaction with system

 Registration details Supplier details
Register
Supplier supplier Supplier profiles
Request
Stock request Stock query
Query
Procurement stock Availability details Stocks
officer Availability details

Quotation Supplier details

Quotation request
Request for quotation details Quotations
and receive
Requested quotations quotation

Scorecards Quotation
Procurement
manager
Select
supplier and Scorecards details Scorecards
request order
Selected supplier details Order details

Order request

Order details Orders

Inspect
Order delivery and Supplier score

rate supplier Order

Inspected delivery details

Payment Payments
Accountant Make
Payment details
payment
Payment

Fig 4.3 Data flow diagram of the proposed system

Key
Entity

Process
Data flow

Data store
4.2.3 System Inputs
 Supplier’s details – these are the details of all the suppliers who will be on online
procurement system.
 Order details- details of products that needs to be purchased.
 Quotations – details of product prices
4.2.4 Processes and Procedures
Options available to suppliers;
 View quotation requests sent by the Kwekwe Polytechnic’.
 View emails on updates of goods to be delivered.
 Upload quotations to Kwekwe Polytechnic’
 Upload a Declined Request for quotation and give a reason to Kwekwe Polytechnic’
 View current scorecards which measures the performance with respect on-time
deliveries, price and product availability.
Options that will be available for Kwekwe Polytechnic’ procurement department (buyer);
 Download and print suppliers’ quotation
 View goods in stock
 Viewing and evaluating suppliers’ scorecards to select the best supplier
 View emails sent by suppliers
 Sending a request for quotation to a supplier
Options that will be available to Kwekwe Polytechnic’ management
 View reports for purchase requests(approved ,held and declined)
The System Administrator options are as follows
 Responsible for updating the website
 Adding, deleting and editing suppliers
 Run Backups of the database
 Maintenance of the web site
 Update changes in the system database

4.2.5 System outputs

 Reports of purchases made
 Online suppliers scorecards
4.3 Architectural design
Sommerville (2014) asserts that the architectural design of a system defines the technical
environment that includes the hardware, software, procedures and users. This minimises
holdups in the system caused by software, hardware and architectural factors. There is need
for regular backups of data and information in cases of system failure or crushing system so
that information will not be lost.

The first decision to make on architectural design is to determine whether the system will be
a stand-alone or a Client-server Architecture. Server based architecture builds the processing
operations of the system into the server (Main Computer) and relegates all the other
computers in a typical network infrastructure to clients (those computers hiring the services
of the server).
On the stand-alone, net workless model, all events of starting service requests and deploying
the services are bestowed in a single computer that operates alone. The client computers do
not have any links; therefore, do not communicate with each other. This kind of architecture
is not suitable for the Kwekwe Polytechnic’ procurement system for it does not initiate
supplier integration.
Since the client server architecture has a higher control and security, higher room for future
growth as well as initiating supplier integration than the stand alone model, the designer has
chosen to use the client server architecture, despite its high set up costs.

The architectural design of the system will be comprised of the following:

 Client Machines – in these, reside graphical interfaced application written for the
windows platform. These computers communicate with the database server requesting
information for transaction processing.
 Networking Cables – provide communication links in the Local Area Network and
the Wide Area Network.
 Printers – facilitate the printing of reports needed by the management.
 Server – Running on Apache Server all the information requirements for the firm are
going to be located in this server. Apache HTTP Serveris a well-known for its ease of
management and low cost of ownership. The necessary processing of data is going to
be done here ensuring data consistency and integrity.
4.4 Physical design of the system
Coronel and Crockett (2015) define physical design as the translation of abstract logical
model into the specific technical designed system. It is concerned with how the hardware
components of the proposed system are going to be laid out and how they are going to be
communicating with each other.

The system is going to be accessed via the network and it is connected to Internet. Kwekwe
Polytechnic’ suppliers will have to log in with their access rights to use the system. The
administrator will be able to use the server from any other machine when performing
administrative duties.
The following hardware requirements will be required to implement the new system:
 PC’s with a Pentium 4 Celeron processor with at least 1GB Ram.
 Hubs, routers, bridges, switches and modems.
 80 GB and more hard drives.
 A server with 1GB Ram and hub.
 Mouse and keyboards.
 Network cables.
 Tape disks.
 Printers.
 Surge protectors.

4.5 Database design

Coronel and Crockett (2008) define database design as the process of constructing a
comprehensive data model of a database. At this stage the developer focuses on the database
architecture, and illustrates the database the database schema and the concept using tables. In
a database architecture design, data is arranged in the database in layers known as schemas
namely the physical layer, the conceptual layer and the application layer. These three
schemas are descriptive of data that exists at the physical level.
The web based procurement system will be running on a central sever which makes it easy to
deploy the system over a local area network
4.5.1 The physical level
This level defines how data is actually stored and is the lowest level of abstraction. (Coronel
and Crockett, 2008). It includes the physical implementation of relations into database
management system.
 4.5.2 The conceptual level
The data that is actually stored in the database is defined in this level as well as the
relationships that exist amongst the data (Coronel and Crockett, 2008). The conceptual
database design includes the identification of the entities, relationship between entities and
defining the attributes. The table’s field name and data type are defined. Queries are also
defined in this level and they are related to each other.
4.5.3 The application layer/ view level
Coronel and Crockett (2008) assert that this level shows the highest level of abstraction and it
aims to simplify the user’s interaction with the database by providing an interface that the
user can simply manipulate and understand. The details stored in the database can be viewed
using forms, reports and tables.

External View External View External View

External level 1 2 3

Community view
Conceptual level Conceptual Schema
of the database

Conceptual/Internal

Internal level Physical representation

Internal Schema
of the database

Physical data
organisation Stored Database
Stored Database Stored Database

Fig 4.6 Database Architecture

4.5.4 Database tables design

The data stores of the proposed system will be in the form of database tables. The tables and
their attributes are defined below as well as their description;

Table 4.2 Users

Field name Data type Description
Username Varchar This is the username of the
user attempting to use the
 system
Password Varchar The password of the user
Access_level Text The access level which
defines the extent to use the
site
Place of birth Varchar Helps in password recovery
4.3 Supplier registration
Field name Data type Description
Supplier_name Text The name of a supplier
Address Varchar The physical address of the
supplier
City Text The city where the supplier
is located
Country Text The country in which a
supplier is located
Post_code Integer The post code for the
country in which the
supplier resides
Phone_number Integer The cell number or
telephone number of the
supplier
Fax_number Integer The supplier’s fax number
Email_address Varchar The email address of the
supplier
Cell number Interger Contact cell number

Table 4.4 Quotation request

Field name Data type Description
Job reference number Integer The unique identifier of the
quotation request
Date Varchar The date on which the
quotation request is sent
Product_name Text The name of the product for
which a quotation is
requested
Product_specifications Varchar The features of the product
(chassis number, colour, such as colour, weight and
weight) material
Desired_delivery_date Varchar The date on which Kwekwe
Polytechnic wants the
product to be delivered on
Delivery_address Varchar The address where the
product will be delivered
Quantities Integer The quantities of the product
needed

Table 4.5 Quotations

 Field name Data type Description
Quotation_number Integer The unique identifier of a
quotation
Job_reference_number Integer The identifier of the
quotation request for which
the quotation is directed to
Product_name Varchar Name of the product
Price_($) Integer The price of the product
Delivery_date Varchar The date on which the
supplier can deliver the
product
Supplier name varchar Name of supplier

Table 4.6 Order request

Field name Data type Description
Order_number Integer The unique identifier of the
order
Order_date Varchar The date when an order is
made
Quotation_number Integer The identifier of the
quotation
Order date Varchar Date of order

Table 4.7 Delivery

Field name Data type Description
Delivery_note_number Integer Unique identifier of a
delivery note
Order_date Varchar The date the order was made
Date Varchar Date of delivery
Delivery_details Text Details of the delivery
Delivery_method Text Method of delivery
Quantities Varchar Quantities delivered
Supplier name Varchar Name of the deliverer
Product name Varchar Name of product being
delivered

Table 4.8Invoice
Field name Data type Description
Date Varchar Date of issue of invoice
Invoice_number Integer Unique identifier of invoice
Job_reference_number Integer Identifier of job
Order_number Integer Identifier of order
Order_price ($) Integer Price charged
Discounts ($) Integer Discounts that has been
 allowed by supplier
Supplier name Varchar Name of the supplier

Table 4.9 Procurement Report

Field name Data type Description
Report_number Integer Unique identifier of report
Quotation_details Varchar Details of quotation sent by
supplier
Invoice_details Varchar Details of payments
Delivery_details Varchar Details of delivery
Supplier name Varchar Name of supplier

Table 4.10 Supplier’s scorecard

Field name Data type Description
Scorecard number int Unique identifier of
scorecard
Product name Varchar Name of product
Supplier_name Text Name of the supplier
Score/rating Integer Current score

Table 4.11 Request for Payment(RFP)

Field name Type Description
Request number Integer Unique identifier of request
for payment
Order number Integer The identifier of order
Product details Varchar Details of product ordered
Price Integer Price to be paid

Table 4.12 response to RFP

Field name Type Description
Date of response Varchar Date of response
Order number Interger Identifier of order
Price Interger Amont to be paid
Response Text Acceptance or rejection
Comments Varchar Reasons for acceptance

4.6 Interface design

Whitten, et al (2003), define interface design as the design of the graphical controls that the
user is to use so as to interact with the system and it provides a link between two modules or
entities. Interface design outlines the design of the menus, reports, forms, and help screens. A
Graphical User Interface, user friendly system is be designed for the proposed system and it
is to be designed in a way allows easy navigation of the entire system.

At first glance of the interface, the users will have an impression on whether the system
meets their requirements or not. This makes the interface design an issue of great importance
to the successful implementation of the system (Coronel & Crockett, 2008).
4.6.1 Menu design
The procurement system will consist of the user login screen on which the user will have to
enter his or her username and password so as to access further options of the system. When
successfully logged in, a home page with a main menu will appear for the user depending on
user category, each user category has a different page.
4.6.1 Main menu
Fig 4.3 shows the structure of the menus of the Procurement System for all system users.
Below are each user and the functions performed by that user in the system.
 Login

accountant Supplier Procurement procurement

Officer Manager

Receive Create
Create
invoices request for Approve
quotation
quotation quotations
Receive Process
invoices purchase Create
Reports
order purchase
Systems (delivery) order
admin
Scorecard
Record
management
Manage users goods
received

Edit suppliers

Fig 4.7 Main menu structure

4.6.1.2 Sub menus

Supplier home page

LOGOUT CHANGE
PASSWORD
QUOTATIONS ORDERS INVOICES SALES
FIG 4. 8 Supplier homepage

Fig 4.9 Procurement manager homepage

PROCUREMENT MANAGER HOME PAGE

LOGOUT CHANGE PASSWORD

QUOTATIONS SCORECAR PAYMENT REPORTS

DS REQUESTS

PROCUREMENT OFFICER HOME PAGE

LOGOUT CHANGE PASSWORD

QUOTATO ORDE STOCK REPORTS SUPPLIERS PAYME

NS RS NT

Fig 4.10 Procurement manager home page

ACCOUNTANT HOME PAGE

LOGOUT CHANGE PASSWORD

INVOICES PAYMENTS

Fig 4.11 Accountant home page

 ADMINISTRATOR HOMEPAGE

LOGOUT CHANGE PASSWORD

Kwekwe SUPPLIERS
Polytechnic’
USERS

Fig 4.12 Admin homepage

4.6.2 Input design

Facilitates the entry of purchasing data into the respective text boxes designed on the form. A
user can automatically go for the next page or quit the form screen by clicking a command
button. Inputs include requisition date, purchase requisition title, delivery terms etc. The
details form these forms update underlying normalised tables. Data will be validated on entry
into the system to avoid having an inconsistent database.

Welcome to the Kwekwe Polytechnic’ procurement system

Please log in to continue

Username

Password

Access level

LOG IN Forgot Password

Fig 4.13 Log in form

Name

Surname

Address

 
E-mail
 
Account Number

IMAGE
House Number

Password
 
Confirm Password
 

Register Clear Form

Fig 4.14 Procurement officer Registration Form

 Name

Surname

Address

 
E-mail
 
Account Number

IMAGE
House Number

Password
 
Confirm Password
 

Register Clear Form

Fig 4.14 Procurement Manager Registration Form

 Account Details ZETDC Acc.

Total Paid: Amount

Balance: Eco-Cash

Latest Payments Account Num.

Date:Amount: PIN

Payment Method

Pay Online Clear

Fig 4.15 Online payments form

Signup form

Accountant Name

Accountant Email

Accountant Password

Accountant Image Browse No File Selected

Accountant Contact

Accountant Address

Create Account

Figure 5.0 Signup Form

Fig 4.15 New supplier registration form

Supplier registration

Supplier code
Supplier name
Address

City
Country
Post code
Phone number
Fax number
Email address

Register Cancel

4.6.3 Output design

The output design will mainly focus on the outputs that are produced after the processing has
been carried out. The major output for the system will include reports such as GRVs,
scorecards, approved, on-hold and declined purchase requisitions.
 Delivery Supplier Product Order Delivery Delivery Delivery quantities
note name name date date method
details
number

Fig4.16 Delivered orders details form

SUPPLIER SCORE CARD

SCORECARD NUMBER SUPPLIER NAME PRODUCT NAME SCORE

Fig 4.17 supplier scorecard

PROCUREMENT REPORTS

Report number Supplier name Quotation details Payment details Delivery details

Fig 4.18 Procurement report

 List of records for an online payment on a particular day

Account Number House Number Customer Name Amount Paid Date Random Numbers

Prepared By

Fig 4.17 Payments Report

Sample Report

Company Profile

Customer Name
Address Account Num.

Statement Period

Bill Charges

Fig 4.20 Sample Report

4.7 Pseudo Code

Neapolitan (2014) defined pseudo code as a detailed readable description of what a computer
algorithm should do, presented in natural language rather than in programming language
.Pseudo code helps programmers to express program design in detail. Pseudo code is a
showcase of the actual code in the language that can be easily understood by everyone who’s
not aware of programing.
 User Login Module
 // Authenticates users and restricts access to unauthorized entry.
 Accept Username, Password
 Select username and password from users table.
 Where username and password match the entered details.
 If a match is found Then
 Direct user to user’s main Page
 Else
 Display error message of login failure
 // Close User Login Module
 View goods in Kwekwe Polytechnic stock module
 //allows the Kwekwe Polytechnic procurement officer to view products in stock
 Accepts product name
 Select product number from delivery table.
 Where the product name matches the one entered.
 If a match is found Then
 Display a message of product availability
 Else
 Display a message of product in availability
 // Close View good in Kwekwe Polytechnic Stock Module
 User Maintenance Module
 Function Capture User Details
 Check to see all textboxes
 If all are filled then
 Capture new supplier details;
 Select user folder;
 Store data in supplier table;
 Else
 Popup message
 Please fill up all fields
 End if
 // close capture details function
 Score Card Maintenance Module
 Function Score Card Details
 Enter the supplier name;
 Enter the rating of the score card;
 Store data in online score card table;
 // close score card details function
 Function Output
 Read entered score card details;
 IF Rating is greater or equal to fifty and less than seventy five Then
 Output Good;
 Show score card details;
 ELSE IF Rating is greater than seventy five Then
 Output very good;
 Show score card details;
 Else
 Output poor;
 Show score card details;
 // end if statement
 // close output function
 // Close Score Card Module
 Upload Quotation Module
 Function Capture Quotation Details
 If all fields have been filled Then
 Capture new quotation details;
 Select quotation folder;
 Store details in quotation table;
 Else
 Display pop up message
 Enter all details
 // end if statement
 // close quotation function
 // Close Quotation Module
 Upload order Module
  Function Capture order Details
 If all field are filled then
 Capture new order details;
 Select order folder;
 Store details in order table;
 Else
 Popup message
 Please fill up all fields
 // close capture order details function

4.8 System Design

System security one of the most important aspects of the project. There is a need to protect
the system as any harm that can come to it can affect the day to day operations of the
business, according to Bentley (2004).
4.8.1 Physical Security
Physical security focuses mainly on the safety and protectiveness of the physical environment
of the system (Bentley, 2004). The major part of the system is the system server is to be
locked up in a different room from the other computers access and its access physically will
be limited to a small number of individuals. The physical security will also include where the
backup information is going to be located and the server will be fitted air conditioners to
prevent the machines from overheating.

4.8.2 Software Security

 Administrators’ passwords and usernames will be used to gain access to the system, to
ensure that privacy prevails and to avoid data destruction by malicious-users. Only
authorized users will have usernames and passwords for the system.
 The ESET Smart security 7 antivirus is to be installed on all machines to ensure
security against viruses, Trojan horses, web phishing and other hacking tactics that
may happen.
4.8.3 Operational security

This is a technique of perceiving key data and accordingly reviewing genuine activities
expert to mastermind improvement and vehicle registration issuing and differing exercises to:
(a) pick and execute designates that take or decreasing to an estimable measurement the
vulnerabilities of neighborly activities to show misuse (b) see those activities that can be seen
by different understanding systems.(c) pick markers that undermining quick structures may
get that could be deciphered or managed to choose fundamental data so as to be valuable to
other particular structures (Langer, 2018).

4.9 Conclusion
What the system is to look like has been covered in this chapter, including, the database
design, physical design and the interface design. System user friendliness and security has
been considered in designing the proposed system. This chapter has also addressed the
procurement system goals through the application of effective design principles in
preparation for the next phase, which is the implementation phase