Software Design Specification Report

Anderson’s auto parts

Table of ContentsIntroduction.................................................................................................................................................5

Purpose of Report...................................................................................................................................5

Project Scope and Objectives..................................................................................................................5

Description of Organization.................................................................................................................5

Description of Project..........................................................................................................................6

Major Functional Requirements..........................................................................................................6

Non-Functional Requirements.............................................................................................................6

Hardware Requirements.....................................................................................................................6

Major Problems Encountered..............................................................................................................6

Design and Implementation Constraints...........................................................................................10

Major Input & Output Requirements................................................................................................12

Description of the Design Process.........................................................................................................13

Actual Estimates & Schedule for Project...............................................................................................15

Work Break Down..............................................................................................................................15

Pert Diagram......................................................................................................................................16

Gantt chart.........................................................................................................................................16

Data Design...............................................................................................................................................17

File & Database Structure......................................................................................................................17

Architectural Design..................................................................................................................................18

Architecture Context Diagram (CAD).....................................................................................................18

ACD Description.....................................................................................................................................19

UML Deployment Diagram....................................................................................................................21

Procedural Design......................................................................................................................................22

Expanded Diagrams...............................................................................................................................22

Use Case Diagrams............................................................................................................................22

Class Diagram....................................................................................................................................32

Sequence Diagram.............................................................................................................................34

Derived Program Structure........................................................................................................................40

Hierarchical Chart (Subsystems & Modules)......................................................................................40

Anderson’s Auto Parts | Software Design Specification Report

Employee management Module...........................................................................................................43

Processing narrative..........................................................................................................................43

Interface description.........................................................................................................................43

Design Language................................................................................................................................43

Modules Used....................................................................................................................................44

Internal Data Structure......................................................................................................................44

Comments/ Limitations/Performance Requirements & Issues..........................................................45

Customer management module............................................................................................................45

Processing Narratives........................................................................................................................45

Interface description.........................................................................................................................45

Modules Used....................................................................................................................................45

Design Language................................................................................................................................45

Module Used.....................................................................................................................................46

Internal data structure.......................................................................................................................46

Comments/Limitations/Performance Requirements & Issues...........................................................47

Supplier module....................................................................................................................................47


Interface Description.........................................................................................................................47

Design Language................................................................................................................................47

Modules Used....................................................................................................................................48

Internal Data Structures....................................................................................................................48


Financial Management Module.............................................................................................................49



Design Language................................................................................................................................49

Modules used....................................................................................................................................51

Internal Data Structures....................................................................................................................51


Product Module.....................................................................................................................................52

Processing Narrative..........................................................................................................................52



Design Language................................................................................................................................52

Modules Used....................................................................................................................................53

Internal Data Structure......................................................................................................................53

Comments/Limitations/Performance Requirement & Issues............................................................53

User Interface Design................................................................................................................................54

Bibliography...............................................................................................................................................58

Appendices................................................................................................................................................59


Introduction

Purpose of Report

The purpose of this plan is to illustrate to all stakeholders in the project, why this solution is

necessary, and precisely how it could be implemented. It also seeks to define the resources

available to carry out the project, the work breakdown and a schedule for carrying out the work. It

will also identify any possible risks that may threaten the success of the project.

Through this, possible contingency plans can be created long before risks become a reality, allowing

for fast mitigation. After thorough examination of the project plan, the main stakeholders will be

better armed with information necessary for making decisions regarding the implementation of the

project.

The ultimate aim is to implement a system which would satisfy Anderson’s Auto parts and make it a

better computerized company. This system will enable the company to be more productive and

efficient during its daily business activities. The proposed plan, seeks to outline the necessary steps

involved in allowing Anderson’s Auto parts to serve its customers better, while keeping an accurate

record of all sales and purchases made on a day to day basis.

This on the other hand will enable the company to keep more accurate records of the transactions

made when compared to those being done manually.

Project Scope and Objectives

Description of Organization

Anderson’s Auto Parts is located at 13 Sandringham Avenue, Kingston 10. Anderson’s Auto Parts is

a middle size business which has 15 employees whom are employed to work with the company full

time. The company was started in 1988 by Ferdinand Anderson but most of the managerial duties

have now been delegated to his two sons Andre and Martin Anderson.


After its inception in 1988, the company has grown in terms of number of employees, structure and

revenues. They now focus on importing auto parts for a range of Mitsubishi line of vehicles.

Anderson’s Auto Parts does both Business-to-Business (B2B) and Business-to-Customer (B2C)

transactions daily. They supply from the individual customer to large businesses such as the dealer

of Mitsubishi in Jamaica, Motor Sales. Anderson’s Auto Parts deals solely in the Mitsubishi make

parts both new and used.

The company has operated successfully from the fifth year after inception to date with minor

problems and constraints. They have no intentions of expanding the business in the near future, but

to concentrate more on the problems and constraints they’ve been experiencing with the current

structure.

Only some of the business’ operations are computerized. Anderson’s uses computers in the

business solely to generate receipts to keep track of sales made on a day to day basis. The inventory

management is handled manually and is done monthly.

Description of Project

We are designing an inventory management system for Anderson’s Auto Parts to assist in keeping

track of goods sold, available, sold by whom, amongst other features of inventory management.

Major Functional Requirements

Non-Functional Requirements

Hardware Requirements

Major Problems Encountered

The following general problems were encountered during the design of the project. Specific tasks were

delegated to group members of whom some of them did not understand what to do. Group meetings

were arranged and some group members were unable to attend for some reason or the other. Another

major problem encountered was the unwillingness of management to give out sensitive information and

so close assumptions had to be made.


One of the biggest challenge encountered however was to juggle the completion of this project with the

other course work we had doing. At times disagreements were encountered during the requirement

phase but instinctive analysis was used to overcome them.


Other problems included:

1. Inadequate Financing – financial changes may occur after all requirement specifications are

finalized and therefore could put pressure on management to fully finance the system. This may

affect the outcome of the final product.

2. Staff Inexperience – All members of the technical team are relatively new to the field of

software engineering. The possibility exists that we could run into complex problems and do not

know how to deal with them accordingly.

3. Staff Size – The software engineering team consists of only five members. We are responsible

for outlining the system’s requirements and all the other processes that lead to system

implementation. There is much work to be done and it means that each member will have to

take on more than one task at some point in time. This may result in difficulties trying to meet

the project deadline.

4. Schedule Risk – This takes into consideration the degree of uncertainty that the project will be

maintained and the product will be delivered on time.

5. Vulnerability to Computer Viruses – All the computers are going to network. Viruses may be

transferred to the system via the internet or secondary storage devices. Whether done

intentionally or unintentionally, viruses loaded on a system for malicious reasons or fun, have

the capability of destroying sensitive information in the system and could severely affect its

entire functionality.

6. Performance Risks – The degree of uncertainty that the system will meet its requirements and

be fit for its intended use. In the initial stage, all the system requirements were defined and

therefore all implementation tools and strategies were pipelined. There could be defects in the

requirements definition which could affect design. This will make the system less efficient and

defeats the entire purpose of designing the system.

7. Product Enhancement – The system should be built in a way that it is easily adoptable to its

environment. It also should be change oriented. Therefore if the software is built in a very

complex way using a low level programming language, then it will not be easy to change and

adapt to certain environments.


RMMM Plan for each Risk (Mitigation, Monitoring & Management)

1.0. Risk 1 - Inadequate Financing

1.1 Mitigation

Get consultants approval of the economic feasibility and inform management. Ensure that there is no cost overrun by purchasing tools that are critical and are on the

initial budget. Keep product enhancement price within the original project plan.

1.2 Monitoring

Produce a report of phase implementation along with budget reort for that particular phase implementation.

1.3 Management

Keep budget within projected amount Scale down project to meet funds available

2.0. Risk 2 – Staff Inexperience

2.1. Mitigation

Ensure that team members are aware of what is going on and ensure that they are competent.

Do a comprehensive research on the material to be covered.

2.2. Monitoring

Keep the communication link with consultants to ensure that objectives and guidelines are met.

Produce a report of work completed on each phase of system development.

2.3. Management

Ensure that each team has a basic understanding of work to be done. If one member is not competent in an area, other team members will seek to improve

his or her ability. Manage the activities planned and ensure they are completed on schedule.


3.0. Risk 3 – Staff Size

3.1. Mitigation

Select the minimum number of team members required to successfully implement the system.

Ensure that the selected team members are goal oriented. Team members should be able to prioritized and willing to do large volume of work.

3.2. Monitoring

Keep team members close and ensure set objectives are achieved. Asked team members to write a formal report on problems they are experiencing.

3.3. Management

Allocate 2 additional team members and keep them abreast of the steps in project development. Therefore if one team member is unable to complete a task then those additional members can fill in.

Ensure that each team member is supported irrespective of how big or small a task being undertaken by that specific team member.

4.0. Risk 4 – Schedule Risk

4.1. Mitigation

Set deadline for system implementation Ensure each phase has a schedule time of completion.

4.2. Monitoring

Record schedule dates to ensure imported project dates are kept. Assign a team member to give reminders of scheduled tasks.

4.3. Management

Consult with group members to ensure deadlines are met. Provide feasible solutions for task that exceeds schedule deadline.

5.0. Risk 5 – Vulnerability to Virus

5.1. Mitigation

Install an up-to-date anti-virus program that is formally accepted and is competent. Scan files stored on the system on a daily basis to ensure the system is virus free.


Scan secondary storage devices before opening them on the system.

5.2. Monitoring

Set up an auto scan for the system. Carry out a comprehensive update of antivirus whenever update is available.

5.3. Management

Disallow any installation of software at all subordinate levels. Create back up of files and store them separately. Create system with check pointing facilities.

6.0. Risk 6 – Performance Risk

6.1. Mitigation

Ensure that initial requirements are feasible and make sure the management is involved in the decision process.

Provide management with a prototype of the actual system and accept inputs for system enhancement and change.

Ensure users are trained properly and understands the system in its entirety.

6.2. Monitoring

Keep track of all system requirements. Test system thoroughly during the testing and debugging phase to ensure it is error free

and does its intended functions. Monitor and test system regularly.

6.3. Management

Carry out an investigation into any failure and make amendments. Ensure that programmers and analysts understand each other and arrange meetings to

clear up any misunderstanding.

Design and Implementation Constraints

One of the major constraints faced by the software development team was time. The time given to complete the assignment was quiet limited as we had to share interest with other courses we were undertaken and that were quite a setback. On the other hand management was quiet skeptical about disseminating any sensitive information and therefore this lead us to make close assumptions. Other general constraints includes


a) Interface constraints

The user’s link to the systems information and software’s utilities is the interface. We had to ensure that the design was easy to use, graphically and very user friendly. Therefore close analysis was had to be placed in this particular area.

b) Implementation constraints

This refers to whether the system will be fully installed on time or not. As stated before, time was a major constraint. Furthermore, the security of the system was a cause for concern and the software development had to make sure that all necessary steps are taken to prevent and security contravene.


Major Input & Output Requirements


Functional Area Input Output

Payroll Employee’s Id Employee’s Position Employee’s Name Hours Worked

Pay Slip:1. Employee’s Id2. Employee’s Position3. Employee’s Name4. Gross Salary5. Net Salary

Transactions Cashier Id Customer Name Product Price Quantity of Products

Receipt:1. Date2. Cashier Id3. Product Id4. Product Name5. Total Amount

Employee Validation Employee’s

Username Employee’s

Password

Welcome Screen

Order List Date Supplier’s Name Supplier’s Code Address Tel No. Product Id Product Name Amount Required

Invoice:1. Date2. Supplier’s Name:3. Supplier’s Code:4. Address:5. Tel No.:6. Product Id7. Product Name

Inventory Report Date Product Id Product Name Amount received

from supplier Amount Sold

Inventory report:1. Date2. Product Id3. Product Name4. Amount Sold 5. Amount Available

Description of the Design Process

What was done Where How By Whom

Introduction University of

Technology, Jamaica

This was generated

from the

requirements analysis

document.

Wayne Jones

Data Dictionary University of

Technology, Jamaica

The data items

needed for the system

to function were

identified and then

described.

Patrick Malcolm

ER Diagram University of

Technology, Jamaica

The tables identified

in the data dictionary

were used to develop

the ER Diagram.

Wayne Jones

File and Database

Structure

University of

Technology, Jamaica

Developed from the

Data Dictionary and

ER Diagrams.

Kedrian James

Architecture Context

Diagram

University of

Technology, Jamaica

This was designed

based on who uses

the system and the

input/output

variables of the

system.

Patrick Malcolm

ACD Description University of

Technology, Jamaica

The different

components were

described as to how

they would interact

with one another.

Wayne Jones, and

Kedrian James

UML Deployment University of Major functions of the Patrick Malcolm and


Diagram Technology, Jamaica system were used to

create the diagram.

Wayne Jones

Derived Program

Structure

University of

Technology, Jamaica

In order to develop

the structure the

different modules and

sub-modules were

identified

Kedrian James and

Patrick Malcolm

UML Diagrams University of

Technology, Jamaica

Obtained and

improved upon from

the SRD Document.

Kedrian James and

Wayne Jones

Modules Description University of

Technology, Jamaica

After obtaining the

different modules

from the derived

program structure

they were then

elaborated upon.

All group members

User Interface Design University of

Technology, Jamaica

These were

developed based on

the different modules.

Patrick Malcolm


Actual Estimates & Schedule for Project

Work Break Down


Description Task

Must

Follow Duration (Days)

Introduction A _ 5

Data Dictionary B A 2

ER Diagram C B 4

File & Database Structure D C 7

Architecture Context Diagram

(ACD)

E D,C 8

ACD Description F E 2

UML Deployment Diagram G F,E,D 4

Derived Program Structure H G 1

Expanded Use Case, Class,

Sequence, Association &

Responsibility Diagrams

I H 6

Major Modules Description J I 10

User Interface Design K J,I 10

5 2 4

7

8

2

4 1 6

10

10

A B C

D

E

F

G H I

J

K

Pert Diagram

A-B-C-E-G-H-I-K = 40 days

A-B-C-E-G-H-I-J-K = 50 days

A-B-C-E-F-G-H-I-K = 42 days

A-B-C-E-F-G-H-I-J-K = 52 days

A-B-C-D-E-G-H-I-K = 47 days

A-B-C-D-E-G-H-I-J-K = 57 days

A-B-C-D-E-F-G-H-I-K = 49 days

A-B-C-D-E-F-G-H-I-J-K = 59 days

A-B-C-D-G-H-I-K = 39 days

A-B-C-D-G-H-I-J-K = 49 days

The Critical Path is 59 Days

Gantt chart


Data Design

File & Database Structure


Architectural Design

Architecture Context Diagram (CAD)


ACD Description

As architecture design begins, the software to be developed must be put into context, the design should

define the external entities that the software interacts with and the nature of the interaction. This

information can generally be acquired from the analysis model and all other information gathered

during requirement engineering. At the architecture design level, a software architect uses an

architectural context diagram (ACD) to model the manner in which software interacts with entities

external to its boundaries. The architecture diagram for Guthrie’s hardware is comprised of:

1. User interface

2. Input processing

3. Output processing

4. Error handling and testing

User Interface

The user interfaces facilitate interaction within the system itself, its environment and the users of the

system. The user interface for this system will be one in which the user can be interact with and

understand. For each level of users, there are different user interface for security purposes for security

reasons.

Input Processing

Input processing facilitates the execution of queries and other processes. In order to get access to the

system and employee will have to first enter the username which is their identification number along

with their password. Once access is gain, then other processes can be carried out. The manager/ owner

have total access to the system and are therefore authorized to add, edit or delete employee, product

or customer from the database. The accountant will have access to generate and print payroll

information. The mouse is responsible for all the interaction with the system via the graphical user

interface, while the keyboard is used to enter all information/data into the systems’ database.


Output processing

The systems’ output devices are the printer and the monitor. The printer is used to print invoices,

payrolls, receipts and inventory report. The monitor displays system prompts and provides the visual

interaction with the system.

Error Handling and Testing

The system will be designed to prevent unauthorized access and will have validation criteria’s. An

uninterrupted power supply will be provided in case of power outage. In addition if information is lost

because of adverse situation, back up facilities will deal this data recovery.

Main System

This is the hub of all interaction which assists with internal communications within the different

subsystem. It is comprise of Inventory system, accounting, cashiering and the central database.

Accounting is responsible for the management of payroll and committed customers who credit goods

from the company. Inventory is responsible for all stocks that comes in and leaves the company’s

warehouse. The inventory controller is also responsible for generating a monthly report with the

amount of goods sold and bought from the company. All subsystem is connected to the main database

to which they have limited access in certain case.


PC

Accounting

System

Server

Anderson’s Auto PartsDatabase

PC

Cashiering

Transactions

Receipts

PC

Inventory Control

Server

Anderson’sInventorySystem

UML Deployment Diagram


Main system and Database are hosted on servers

Logical Relationships

Sub systems and PCs connect to the database and Main system

Log into system

Print Cashier Report

Cashier Customer

Process Transactions

Print Receipts

Procedural Design

Expanded Diagrams

Use Case Diagrams

Cashier

Use Case #1 – Cashier

Case Name: Print Receipts

Participating Actor (s): Cashier, Customer

Entry Conditions: Goods being purchased and their prices initiated

Exit Condition: Display total cost of item and change, then print the receipt

Special Requirements: None

Case Name: Log into System


Participating Actor (s): Cashier

Entry Conditions: Password initiated

Exit Condition: Cashier is logged in to system


Case Name: Print Cashier Report

Participating Actor (s): Cashier

Entry Conditions: password initiated

Exit Condition: Display monthly report and print it.


Case name: Process Transaction

Participating Actors: Cashier, Customer

Entry Conditions: Goods must be purchased

Exit condition: Display total cost of transaction and calculate change

Special Requirements: Product must be available


Analyze Cashier Report

Log into system

Update InventoryInventory Clerk Supplier

Print Inventory Report

Print Order List

Inventory Clerk

Use Case #2 – Inventory Clerk

Case Name: Print Inventory Report

Participating Actor (s): Inventory Clerk


Exit Condition: Display and Print the inventory list

Special Requirements: after inventory is updated

Case Name: Logs into System



Exit Condition: Inventory clerk is logged in to the system


Case Name: Analyze cashier report



Entry Conditions: obtain cashier’s daily report and update inventory accordingly.

Exit Condition: Inventory clerk is logged in to the system


Case Name: Update inventory Report



Exit Condition: Obtain daily sales and update inventory

Special Requirements: After each day

Use Case Name: Print Order List

Participating Actor (s): Inventory clerk, Supplier


Exit Condition: Display and Print the inventory list and give to the supplier

Special Requirements: After an item reaches reorder amount, it is added to the order list.


Log into System

Create Summary of Bills

Print Summary of Bill

Accountant

Prepare Payroll

Manager

<extends>

Accountant

Use Case #3 – Accountant

Case Name: Print Summary Bills

Participating Actor (s): Accountant

Entry Conditions: password initiated, employees work

Exit Condition: The of all bills summary have been printed

Special Requirements: After bills are obtained

Case Name: Logs into System



Exit Condition: Accountant is logged in to the system


Case Name: Create Summary of bills



Entry Conditions: password initiated, Bills have been received

Exit Condition: Generate a summary of all bills


Case Name: Prepare payroll

Participating Actors: Accountant, Manger

Entry Conditions: Totals hours worked by an employee have been received

Exit Condition: Generate and calculate payroll list

Special requirements: Hours have to be entered


Manager

Analyze Payroll

Print Payroll

Log into System

Add Product

Modify Product

Manager

Use Case #4 - Manager

Use Case Name: Logs into System

Participating Actor (s): Manager


Exit Condition: Manager is logged in to the system


Use Case Name: Analyze Payroll



Exit Condition: Analyze and agree on all payroll calculation

Special Requirements: after a week


Use Case Name: Print Payroll


Entry Conditions: Obtain payroll information from analysis

Exit Condition: Display and print payroll.

Special Requirements: After a week

Use Case Name: Add Product


Entry Conditions Product identification must be unique for all additions

Exit Condition: Product will be added to the database and its record count increased.


Use Case Name: Modify Product


Entry Conditions: Product identification must exist for all modifications.

Exit Condition: Product will be added to the database and its record count increased.



Makes an Order

Make Payment

Customer

Use Case #5 – Customer

Use Case Name: Make an Order

Participating Actor (s): Customer

Entry Conditions: None

Exit Condition: Order made to cashier.

Special Requirements: Goods must be available.

Use Case Name: Make a Payment

Participating Actor (s): Customer

Entry Conditions: provide Cash upfront

Exit Condition: Cashier receives payment for goods and a receipt is received.

Special Requirements: Cash should be greater than total cost of items


Obtain Order List

Supply Orders

Supplier Inventory Clerk

Supplier

Use Case #6 – Supplier

Use Case Name: Obtain Order List

Participating Actor (s): Supplier

Entry Conditions: Order list must be printed

Exit Condition: Goods must be ready for delivery.


Use Case Name: Supply Orders

Participating Actor (s): Supplier

Entry Conditions: None

Exit Condition: All goods must be available.

Special Requirements: All goods on order list must be ready for delivery.


Guthrie’s Hardware

Name: StringAddress: StringTelephone No.

Display ( )

Employee

Employee Id: Integer Name: StringAddress: StringTelephone No.: IntegerPosition: StringHourlyRate: float Display ( )

Customers

Fname: StringLname: StringAddress: StringTelephone No.

Makes_Order ( )Makes_payment ( )Display ( )

Supplier

Supplier’s IdName: StringAddress: StringTelephone No.

Receives_Order_list ( )Display ( )

Cashier

Process_transaction ( )Print_reciept ( )Print_report ( )

Products

Product Id: integerName: StringSellingPrice: integerQuantity : integer

Product_Available ( )Add_Product ( )Modify_Product ( )Remove_Product ( )Display ( )

Manager

Analyse_payroll ( )Print_payroll ( )

Accountant

Prepare_payroll ( )Create_summary_of_bills ()Print_summeary_of_bills ()

Inventory Clerk

Analyse_cashier_report ( )Update_inventory ( )Print_inventory_repport ( )Print_order_list ( )

Is A

Buys Supplies products to

EmploysHas

1..1 1..*1..11..*

1..*

1..11..*

1..*

Class Diagram

Anderson’s Auto Parts

:Username verifier :Password verifier

Sequence DiagramLogging into System


Valid ( )

Cashier

Accountant

Administrator

Requests password( )

Enters username ( )

:Inventory Controller

ProduceList ( )

:Inventory SystemPrint Button

Create ( )

PrintList ( )

Print Order List


Print Payroll


Instigate ( )

Produce Report ( )

Cashier Report

Cashier

Create ( )

Print Report ( )

Print Button Employee System

Commence ( )

Employee Id ( )

Found Employee ID

Print Payroll ( )

Payroll Printed

Manager Print Button

:Inventory System:Inventory Controller

Print Cashier Report


Initiate ( )

Produce Bills ()

Summary of Bills

Accountant

Create ()

Print Bills ()

Print Button:Inventory System:Inventory Controller

Print Summary of Bills


Order good()

Order

Customer

OkToOrder()

AdjustStockL

evel()

addtoOrder()

scansProduct()

:Stock Record :Barcode Reader :Order:Order Line

Makes an Order


Payroll list

Transform Center (Payroll)

Input Controller (Payroll) Output Controller (Payroll)Transform Process (Payroll)

Transform Center (Login)

Input Controller (Login) Output Controller (Login)Transform Process (Login)

Derived Program Structure

Hierarchical Chart (Subsystems & Modules)

Validate User Welcome Screen

Transaction Center (Invoice)

Receptor (Invoice)

Dispatcher (Invoice)

Employee_id Pay slipHours worked Hours worked Deduct Tax

Supplier_id Product Description

Quantity Invoice

Employee_id Employee Password

Transform Center (Make an order)

Input Controller (Make an order) Output Controller (Make an order)Transform Process (make an order)

Transform Center (Summary of bills)

Input Controller (summary of bills) Output Controller (summary of bills)Transform Process (summary of bills)

Transform Center (Cashier report)

Input Controller (Cashier report) Output Controller (Cashier report)Transform Process (Cashier report)

Cashier

Bill type

Bill_id Calculate total

Print Bills Product_id Product Description Customer_id Calculate

changeReceipt

Processing Narrative

Interface Description

Design Language

Modules Used

CommentsLimitations

Performance Requirements & Issues

Internal Data Structures

Employee management Module

Processing narrative

This module is responsible for the management of all employee employed to the company.

Management includes retrieve, add, edit/update and delete employee information. This will help

management to make systematic changes and maintain a track record of all employees. Therefore if

the company employs new employee then general information about that employee will be added

to the database, conversely if the company needs to remove or upgrade an employee then the

database design will facilitate it. Every employee will be given a username and a password to use

the systems. Once logged on, they will be greeted with a welcome screen after which the have

different options from which to choose in order to proceed.

Interface description

Add Employee

Employee Management

View Entire Employees

Design Language

Start

If Employee called from Login or Lock Screen Window

Check if entered user information exists in database

Return Check result

Accept User Selection

If Selection equals Add Employee

Generate new employee id

Get supplier information from user

Write supplier information to database


Else If Selection equals View Entire employee List

Read employee List from Database

Return employees List

Else If Selection equals employee Management

Accept employee id from user

Read record with employee id from Database equal to id entered

Return record

If Selection equals Update employee

Accept employee information entered

Overwrite record with id equal to id of employee

information entered

Else If Selection equals Delete employee

Delete emplyee record

End if

End if

End if

Stop

Modules Used

Employee management

Internal Data Structure

None


Comments/ Limitations/Performance Requirements & Issues

Only the manager can access this module as it is directly connected to the database. Most of

this module is restricted except the viewing of employee.

Customer management module

Processing Narratives

All information related to registered customer is taken care by this module. This module will allow

users who are authorized to update/edit delete or add a customer to the database. It is important to

keep track of customers as discount is given at irregular intervals to consistent customers who

purchase items from the company.

Interface description

Add Customer

Customer Management

View Entire Customer List

Modules Used

Customer management

Design Language

Start

If Customer called from Login or Lock Screen Window


Return Check result


If Selection equals Add Supplier

Generate new customer id

Get customer information from user

Write customer information to database


Else If Selection equals View Entire Customer List

Read customer List from Database

Return customer List

Else If Selection equals Customer Management

Accept Customer id from user

Read record with customer id from Database equal to id entered

Return record

If Selection equals Update Supplier

Accept customer information entered

Overwrite record with id equal to id of customer

information entered

Else If Selection equals Delete Supplier

Delete customer record

End if

End if

End if

Stop

Module Used

Customer module

Internal data structure

None


Comments/Limitations/Performance Requirements & Issues

It is necessary to keep customers in the database as management offers price reduction to regular

customers at the company.

Supplier module


Information about all suppliers is vital in the overall operation of the system. The database will link

all suppliers to the respective goods that they supply. Management therefore will be able to

distinguish between the different suppliers and in the case of adverse situations, they will know

who to contact.


Add Supplier

Supplier Management

View Entire Supplier List

Design Language

Start

If Supplier called from Login or Lock Screen Window


Return Check result


If Selection equals Add Supplier

Generate new supplier id

Get supplier information from user

Write supplier information to database

Else If Selection equals View Entire Supplier List

Read Suppliers List from Database


Return Suppliers List

Else If Selection equals Supplier Management

Accept Supplier id from user

Read record with supplier id from Database equal to id entered

Return record

If Selection equals Update Supplier

Accept supplier information entered

Overwrite record with id equal to id of supplier

information entered

Else If Selection equals Delete Supplier

Delete supplier record

End if

End if

End if

Stop

Modules Used

Supplier module


None


The date that goods were supplied will be a major requirement for system performance.


Financial Management Module


All the financial aspects of the company are taken care by this module. This will be responsible for

generating payroll and inventory reports. The manager and the company’s accountant will be given

direct access to the functionality of this module.


Generate Payroll

Generate Invoice

Generate Inventory report

Financial Settings

Design Language

Start

Display Menu

Input selection

Accept selection

If selection = Generate invoice

Then

Input invoice number

Input supplier code

Input supplier name

Input date

Input product_id


Input product description

Input quantity

Store to database

Display invoice information

Else if selection = Generate payroll

Input employee_id

Input hours_worked

Input hourly_rate

Net Pay hours_worked * hoursly rate – tax

Display pay slip

Store to database

Else if selection = Generate Inventory report

Input inventory_report_id

Read products sold from database

Amount_in_stock product_sold – amount_in_stock

Display amount_in_stock

Display report

Store to database


Else if selection = Financial settings

Input employee_id

Update hourly_rate

Input product_id

Update product price

Store to database

End if

End if

End if

Stop

Modules used

Financial module


None


The inventory clerk will be given the privilege of generating invoice and inventory report while

both the manager and the accountant will be responsible for generating payroll and make any

modification to the financial settings.


Product Module

Processing Narrative

Management of all products that enters and leaves the company’s warehouse will be taken care by

this module. Information with regards to product name, description quality and other imperative

information will be stored to the database through this module.


Add Product

Product Management

View Entire Product List

Design Language

Start

If product management called from Login or Lock Screen Window


Return Check result


If Selection equals Add product

Generate new product id

Get product information from user

Write product information to database

Else If Selection equals View Entire product List

Read product List from Database

Return product List

Else If Selection equals product Management


Accept product id from user

Read record with product id from Database equal to id entered

Return record

If Selection equals Update product

Accept product information entered

Overwrite record with id equal to id of product

information entered

Else If Selection equals Delete product

Delete product record

End if

End if

End if

Stop

Modules Used

Product

Internal Data Structure

None

Comments/Limitations/Performance Requirement & Issues

This will be a link with this module and the financial module as financial update such as adjustment

of price will be reflected in the product module. The inventory clerk will be able to add, delete or

update a product once given the authority by management.


User Interface Design


+


Bibliography


Appendices


Software Design Specification Report

Documents

Transcript of Software Design Specification Report