Software Engineering Project

Group 3 Chevaughn Walker 1203383 Julia Pottinger 1200639 Carlington Palmer 1201861 Stephen Hing 1306717

Software Engineering: Analysis & Design

Tutor: Arleen Penrose-Whittaker

Company Name: Smartbox

Address: Shop 5 Grove Court Shopping Centre,

Mandeville, Manchester, Jamaica

Name of System: Ulti-Stocks and Database Management

Members:

Chevaughn Walker 1203383

Julia Pottinger 1200639

Carlington Palmer 1201861

Stephen Hing 1306717


Contents Background to the Problem .................................................................................................................................1

Identification and Justification of process model and methodology being used ................................................4

Work Breakdown Structure .................................................................................................................................6

Precedence Table .................................................................................................................................................8

Gantt chart ........................................................................................................................................................ 11

Risk Mitigation table ......................................................................................................................................... 12

Risk Mitigation ................................................................................................................................................. 13

Reporting Structure .......................................................................................................................................... 20

Roles and Responsibilities of team members ................................................................................................... 21

A Breakdown of major Roles and their responsibilities ................................................................................... 24

Accurately assess the needs of their clients, should be familiar with the SDLC. ................................. 25

Understand what clients want, and to present the proposed solutions in terms that the user can

visualize and understand. .............................................................................................................................. 25

Responsibility: ............................................................................................................................................. 25

Responsibility: ............................................................................................................................................. 26

Object Oriented Analysis .................................................................................................................................. 29

Problems, opportunities, objectives and constraint matrix ............................................................................. 32

Actor Identification Form of existing system .................................................................................................... 34

Use Case Identification Form of existing system .............................................................................................. 35

Use Case Diagram of Existing

System.36

Functional and Non-Functional Requirements .................................................................................................. 37

Actor Form of Proposed System ....................................................................................................................... 40

Entity Relational Diagram ................................................................................................................................. 54

Process Diagram ................................................................................................................................................ 55

Appendices ........................................................................................................................................................ 58

Minutes ......................................................................................................................................................... 58

Fact- Finding Technique ................................................................................................................................ 61


Project

Background


1

Background to the Problem

Smartbox is an authorized dealer in computer and computer supplies. The store is located at

Shop 5 Grove Court Shopping Centre, in Mandeville, Manchester, Jamaica. Smartboxs main

purpose is to sell customers the best computers and other technological devices available on the

market today. Smartbox also offers computer repairs for customers and it also has Internet Caf

where customers can access the internet.

Smartbox has only one branch which is located in Manchester. It employs on average 10

persons to ensure the efficient running of the organization. Its customer base on a daily basis is

between 65-75 individuals.

The business has excellent customer support and payment plans. Smartbox offers numerous

payment plans, therefore customers can expect affordable deals and ample time to pay for their

purchases. Also customers are given the option of exchange, if they no longer want an item they

have already purchased.


2

PROJECT

PLAN


3

SMARTBOX TECHNOLOGY

Phone: 876-962-1946

Email:[email protected]

Fax: 876-622-7481

DATE OF REQUEST SERVICE REQUESTED FOR DEPARTMENT(S)

02/09/2014 Customer Services, Repair Services

SUBMITTED BY (key user contact)

Name: Carlington Palmer

Title: Manager

Office: C00T

Phone: 567-4564

EXECUTIVE SPONSOR (funding authority)

Name: Stephen Hing

Title: President

Office:007

Phone:878-8756

TYPE OF SERVICE REQUESTED:

Information Strategy Planning Existing Application Enhancement

Business Process Analysis and Redesign Existing Application Maintenance (problem fix)

New Application Development Not Sure

Other (please specify ________________________________________________________

BRIEF STATEMENT OF PROBLEM, OPPORTUNITY, OR DIRECTIVE (attach additional

documentation as necessary) The manual inventory system at Smartbox does not provide details of when the inventory needs to be

restocked. They have to manually check the stocks, as the system does not prompt as to when the stock

needs to be refilled. In addition, the method of keeping track of computer repairs and customer

information related to these repairs is manual. Both methods of keeping track of inventory, customer

information and the related repairs being done can be tedious, time consuming and error prone.

BRIEF STATEMENT OF EXPECTED SOLUTION

A software is required that should be dedicated to the updating and tracking of stock and customer

information and the associated computer repair jobs. The software should help the Smartbox store to

keep better track of their stock inventory. It should reduce the time used to check inventory level from

two days to a couple of minutes at most. The designed software will have a reorder function that

automatically checks and informs Smartbox if items in stock are at a low percentage or number and

needs to be refilled. It will also have a database to keep track of the customers that want to have repairs

done and also to keep track of the repairs that are done. A form will be created that will ask the user for

contact information and other information related to the repair of the item.

ACTION (ISS Office Use Only)

Feasibility assessment approved Assigned to _Chevaughn Walker_

Feasibility assessment waived Approved Budget $ __500,000___________

Start Date _21/01/2014_ Deadline 31/03/2014_

Request delayed Backlogged until date: ______________

Request rejected Reason: ________________________________________

Authorized Signatures:

_____________________________________

Project Executive Sponsor


4

Name of System: The name of the system is Ulti-Stocks and Database Management. This name is

suitable because of its likeness to the problem it was designed to solve i.e. inventory/stock

management and creating a customer database to manage customer and stock information

efficiently.

Identification and Justification of process model and methodology being

used In creating this system, our team will be using the Incremental Process Model and will be

combining the Object Oriented and the prototyping methodologies. The Incremental Process Model

will be used as the system that will be created working software is required by the client quickly and

early during the software life cycle. With the Incremental process model at each stage of the

increment a prototype is produced to be shown to the client. As a result of this the users of the

system will have an idea of what the system is capable of and if there are any changes that the user

wishes to make then it is less costly to change scope and requirements.

The Incremental Model was chosen as each week or every two week a specific task was

completed and a deliverable was produced at the end of that time. Prototyping and Object oriented

methodologies were incorporated in the completion of the system due to the fact that with

prototyping a working model of the system will be provided so that the users- employees at

Smartbox will get a better understanding of the system being developed. In doing this we will be

better able to determine the real needs of the customer, thus by choosing this model the customer

will be satisfied. In addition to that we will get a faster user response and this should lead to a better

solution being developed.


5

The object oriented methodology is also being incorporated as an object oriented system is

easier to manage and maintain and the user will be able to understand the system better as it will be

built in a way related to real world scenarios as our software will more closely reflect the real world.

In addition the Object Oriented approach is very stable in that if we want to make small changes to

the system, the entire system wont be affected.


6

Work Breakdown Structure

Ulti- Stocks & Data

Management

Network

Design

Feasibility

Report

Cause and

Effect Analysis

Define System

Requirements

Fact

Finding

/Elicitation

Risk

Analysis

Problem

Definition

System

Analysis Design and

Development

Implementation,

Testing and

Training

Database

Design

User

Interface

Design

Code

User

Interface

Creating and

Testing

Databases

Install

Systems

Environment

and Network

Debug and

Test Software

Implement

Software

Train

Users

Create

User

Manual

Design

System

Environment

Design Security

and System

Controls

Identification

of Problem

Establish

Business

Objectives

Code system

and security

controls


7

Final product delivered.

The work breakdown structure is a fundamental part of defining the project scope. It is used to

identify the project deliverables or tasks; the WBS starts at a high level and decomposes the project

deliverables to a work package level. At a work package level, it is possible to determine which

activities are necessary to produce the deliverable and achieve the key project objectives. The Ulti-

Stocks & Database Management System may be broken down into 4 levels.


8

Precedence Table

Task Description Detailed Activity Task Predecessor Duration

(Days)

Identification of

Problem

Identifying the problem the

current system has

A 2

Establish Business

Objectives

Identify what it is the

proposed system should

achieve

B A 3

Feasibility Report Estimate budget, deadline.

Identify resources

C A,B 2

Risk Analysis Conduct Risk analysis of the

problem at hand

D A,B 8

Fact

Finding/Elicitation

Conduct interviews and

questionnaires.

E D 5

Cause& Effects Conduct cause and effect

analysis of the problem at

hand

F E 5

Define System

Requirements

Ascertain from the customer

the features and behaviour of

the proposed system.

G D 7

Network Design Define how system will

interact with other systems

and establish network based

on strategic plan.

H G 15

Database Design -Create ERD

-Choose database structure

-Design database architecture

-design database schema

-design referential integrity

constraints

I G 25

Environment

Design

Define all the technology

required to support the

J G 16


9

software application

Design Security

and System

controls

-define controls for access by

different users

-design how to protect the

database from

software/hardware failure

-define how to protect

communications on the

network

K G 15

Design User

Interface

defines how user interacts

with system

L G 13

Code User

Interface

Create the user interface

including GUI, mouse

controls, sound, video and

voice commands.

M H,I,J,K,L 15

Create and Test

Database

Create the actually database

and test its efficiency and

correctness

N H,I,J,K,L 25

Code system and

security controls

Limit access to authorized

users, and implement other

necessary security measures.

P N 10

Install Systems

environment and

Network

Install Operating System,

Local Area Network

connections and Desktop

Computers.

O P 10

Debug and Test

Software

System Evaluation.

Introduce prototype &

observe reactions. Perform

cost/benefit analysis.

Q O 5

Implement Install the software and Test R O 7


10

Software it.

Create User

Manual

Create document to guide

Users on how to use the

system.

S R 10

Train Users Present final proposal. Train

users to use the system

T R 10

The precedence table shows a list of activities labeled from A-H.

These activities or tasks are represented by their description.

The predecessor is stated if there is any.

The duration for each activity to be completed is stated in the durations column. The

duration is represented in days.


11

Gantt chart

2

3

2

8

5

5

7

15

25

16

15

13

15

25

10

10

5

7

10

10

A

B

C

D

E

F

G

H

I

J

K

L

M

N

O

P

Q

R

S

T

Task

Start

Duration


12

Risk Mitigation table

There are a number of risks associated with the design and implementation of the Ulti-Stocks and

Database Management System. The goal of the risk mitigation plan is to identify as many potential

risks as possible. When all risks have been identified, they will then be evaluated to determine their

probability of occurrence, and how the project will be affected if they do occur. Plans will then be

made to avoid each risk, to track each risk to determine if it is more or less likely to occur, and to

plan for those risks if they should occur.

The table below outlines the probability of a risk occurring.

Impact Values Description

1 Catastrophic

2 Critical

3 Marginal

4 Negligible

Risk Summary/Description Risk Category Probability Impact(1-4)

Customer fail to participate Customer Risk/Customer

characteristics

14% 3

Malfunction of Computers / System

failure

Technology 10% 3

Lack of experience in Software

Development

Technical Risk 35% 2

Insufficient capital Budget 30% 2

Change of project requirements Scope 25% 3

Insufficient time to complete project Business Impact 15% 3

A team member may be unable to

continue school

Project completion risks 19% 3


13

Risk Mitigation

A Team Member may be unable to continue School.

Students from time to time are unable to continue with their education at university as a result of

financial issues, being deregistered, late enrollment, death or illness. This results in the team being

short on a member and this places strain on the remaining members.

Mitigation: Meetings will be held to discuss the possibility of any member having to discontinue

school. Measures will be put in place to have the work delegated in a manner that if 1 person

discontinues then the aspect of the project that they are doing will jeopardize the entire project.

Monitoring: Students progress will be monitored to ensure that they are completing their part of the

project in a timely manner. They will also be asked on different intervals about their state of affairs

with the school.

Managing: The team will have to find ways to finish the project without the team member. Delegate

work that wasnt completed by that member and try as best as possible to complete the project on

time.

Lack of training and understanding of software

If the person that you are creating the software for does not understand how to use the software

efficiently, then despite how the good the software that you create is a problem will still exist in the

organization.

Mitigation: Training session will be held to teach the employees of Smartbox how to use the system

properly. There will be a series of training sessions involving various employees with various skill


14

set and roles in the organization. Persons that will be interacting with the system directly will be

given special training so as to ensure that are well equipped to use the system.

Monitoring: During the development of the system at various stages the employees will be met with

and the different software that will be used in the system and the different interfaces will be

discussed with them. An idea of their technical experience and what they know and dont know to do

will be gathered and based upon that knowledge training sessions will be held to teach them. Their

progress will be monitored and improvements noted and any adjustments that need to be made in

their training will be made.

Managing: In the event that the employers cannot use the system properly then we would have to

create an interface that they can use more easily or that they are more familiar with. If that does not

work, then the company will have to hire new employees that are tech savvy and will be better able

to use the system.

Customer fail to participate

An important part of the entire end result is that the customers that come into the store are willing to

fill out the form and provide information so that the database can be created on the customers that

want to repair electronic items.

Mitigation: The team will do their best to create a form that is efficient in collecting all the relevant

information and at the same time does not take a lot of time to fill out. A prototype of the form

filling out process could be created so that the customer would have a feel of what is coming and

valuable feedback could be gained from this that would help the team to know what to add or

subtract from the form.


15

Monitoring: This process would be monitored over a period of time and questionnaires could be

given to the customers so as to find out their opinion on the entire process.

Managing: If the customers are reluctant to fill out the form then another method to gather the

needed data will have to be implemented.

Malfunction of Computers / System failure

The cost associated with a computer crash resulting in a loss of data is crucial. As a result, Smartbox

will be instructed to make multiple backup copies of the software in development and all

documentation associated with it, in multiple locations. System failures happen to companies of all

sizes. They dont always occur regularly but when they do occur they can be devastating to the

companys finances.

Mitigation: The Company will create a parallel system that can act as a solution if the current

system should fail. The system will also have an auto-backup feature that will ensure only minimal

data is lost from the databases if a system failure should occur.

Monitoring: The system is checked regularly for malicious software and other types of intrusions.

Checks for signs of a possible system crash will be carried out, thus giving an early warning system

for system failures.

Managing: If the system fails, then the early warning system would have predicted it but we were

just unable to stop it. In such a case, the databases would have already been backed up and the

alternative system put in place to ensure the continued operation of the system.


16

Lack of experience in Software Development

This lack of experience could result in the project being poorly planned and as such the system that

is delivered to the customer is of a poor quality. Poor project planning skills and not knowing the

correct steps to take in developing software could result in the wasting of time and resources.

Mitigation: In order to prevent this from happening, the development team will be required to learn

the different skills and techniques needed to develop the software properly. The member of the team

that is the most experienced in a particular area will need to instruct those who are not as well

versed. Guidance should be sought from persons who have experience in software development.

Monitoring: Each member of the team should watch and see areas where another team member

may be weak. Also if one of the members is weak in a particular area it should be brought to the

attention by that member, to the other members.

Management: The members who have the most experience in a particular area will be required to

help those who dont out should it come to the attention of the team that a particular member needs

help.

Insufficient capital

Companies from time to time attempt to save money by suggesting surprisingly low budgets for

complex projects. At times these companies refuse to adjust the budget to a seemingly sensible

budget. With a budget being too low, most of the expectations of the company cannot be met not

unless the developers suffer a loss in the process.

Mitigation: A detailed pricing scheme will be given to the company highlighting the different costs

for the project and how the final estimate was reached. With a logical and detailed explanation of


17

how the final figure was reached, the company is generally less likely to try and undercut the figure

being given. Once a figure is agreed on, a written agreement is signed between the vendor and the

company to ensure the project is funded to at least this figure.

Monitoring: Our team plans to deliver regular progress reports to the company in an effort to keep

them interested in spending money. If an investor sees that his money is working, he/she is more

likely to continue investing.

Management: In the event the company attempts to undercut the agreed price, then the written

agreement will be used as leverage to say that this is what we agreed on and if we do not get that

amount then it will be very difficult for you to get the finished system that you want at the deadline

that you want and with the quality that you want.

Change of Project Requirements

During a projects development cycle, the company may have a change of heart or comes across a

problem that they didnt notice before or forgot to mention. Whenever this happens the development

team is usually asked to adjust their project to suit the new requirements of the company. These

changes create added difficulty for the development team. This could affect whether or not the team

is able to meet the deadline. If the deadline is no longer feasible then this added pressure can cause

forced errors in the system.

Mitigation: The development team will conduct detailed interviews with the company in an attempt

to cover all angles. This should ensure that most of the necessary features are included in the system

that the company and the team agree to build and that the product we are producing, and the


18

requirements of the customer are equivalent.

Monitoring: During the development cycle of the project, the company will be requested for

consultation and testing of the project. Prototypes will be created at various stages of the project so

that any issues that the company may have with the system can be dealt with in a fast and timely

manner. This will create a sort of early warning system for the team, allowing us to predict possible

changes.

Managing: Should the development team come to the realization that their idea of the product

requirements differs from those of the customer, the customer should be immediately notified and

whatever steps necessary to rectify this problem should be taken. Preferably a meeting should be

held between the development team and the customer to discuss at length this issue. If the company

needs the project to be delivered on the agreed date then we will add more members to the team to

compensate for the additional work or have the current team work longer hours.

Insufficient Time to complete Project

It is very challenging to balance the time between the many courses that one is required to do while

at university and plan a project at the same time. There is a limited time in which this project has to

be planned and with the many different negative factors in play the project may be completed late.

Mitigation:

Steps have been taken to ensure a timely delivery by gauging the scope of project based on the

delivery deadline. Work Breakdown Structure and precedence tables have been made so as to guide

the team as to the timeline for completing the project.

Monitoring:


19

A schedule has been established to monitor project status. Falling behind schedule would indicate a

potential for late delivery. The schedule will be followed closely during all development stages.

Managing:

If it becomes apparent that the project will not be completed on time, the only course of action

available would be to request an extension to the deadline from the customer. In the event that this is

not possible then the area of the project that was completed will be given to the customer and further

tasks will be held towards seeking time to finish the project.


20

Reporting Structure

Architect

Project Manager

Technical

Writer

/Librarian

Coder/

Programmer

Systems

Environment

Designer

Project

Database

Designer

GUI

Designer

Development

Manager

Designer Chief

Engineer Requirements

Analyst

Interaction

Designer

Trainer


21

Roles and Responsibilities of team members Role Team Member Functions

Project Manager Julia Pottinger

Chevaughn Walker

-Coordinates and oversee all

activities of the project.

- Help ensure that the software

development process works as

it is intended.

Development Manager Chevaughn Walker

Julia Pottinger

- managing multiple priorities

of conflicting projects.

-address issues from the team,

which it is unable to resolve

internally

Designer Carlington Palmer

Chevaughn Walker

Stephen Hing

Julia Pottinger

Design the entire network

inclusive of:

-defining controls for access

by different users

-design how to protect the

database from

software/hardware failure

-define how to protect

communications on the

network

- Define all the technology

required to support the

software application

-Delegate task to other

designers

-supervise other designers that

report to him.


22

- Generate system-level

description of what the system

is to do.

GUI Designer Chevaughn Walker -Design the user interface

including GUI, mouse

controls, sound, video and

voice commands.

- defines how user interacts

with system

Project Database Designer Chevaughn Walker

Julia Pottinger

Design the database.

Create ERD

-Choose database structure

-Design database architecture

-design database schema

-design referential integrity

constraints

Chief Engineer Stephen Hing -Determines the (stakeholders)

needs that the product must

meet and continually oversees

the development of the

product to ensure that its on

target to meeting those needs.

Coder/Programmer Carlington Palmer

Chevaughn Walker

Stephen Hing

Julia Pottinger

- Write code for all aspects of

the system and implement the

software

-Create the actually database

and test its efficiency and

correctness

- Limit access to authorized

users, and implement other


23

necessary security measures.

- Install Operating System,

Local Area Network

connections and Desktop

Computers.

- Install the software and Test

it.

Technical Writer/Librarian Julia Pottinger - Prepare and store all

documents that are used

during the life cycle of the

system.

-Create document to guide

Users on how to use the

system.

- Estimate budget, deadline.

Identify resources

- Conduct Risk analysis of the

problem at hand

Requirements Analyst Chevaughn Walker - Works with Smartbox,

breaking down what their

wants into discrete

requirements.

-Identifying the problem the

current system has

- Identify what it is the

proposed system should

achieve

- Conduct interviews and


24

questionnaires.

- Conduct cause and effect

analysis of the problem at

hand

- Ascertain from the customer

the features and behaviour of

the proposed system.

Architect Carlington Palmer -Help to catch faults that the

system overlooks

- Converting the requirements

into an architecture and design

that will become the blueprint

for the solution being created.

Trainer Stephen Hing

Carlington Palmer

- Creates the materials

necessary to train users how to

use software.

-Present final proposal. Train

users to use the system

A Breakdown of major Roles and their responsibilities

Project Manager

Main Function- Coordinates and oversee all activities of the project.

Responsibility:

-Assessing User Needs


25

Connect and communicate between software developers, programmers and other members of

the technical team and the non-technical users who actually work with the project every day.

Accurately assess the needs of their clients, should be familiar with the SDLC.

Understand what clients want, and to present the proposed solutions in terms that the user can

visualize and understand.

-Building a Team

Know which resources will be needed, this can include members of the programming team,

software developers and even outside vendors. Understanding who to turn to get the job done

is an essential part of the job.

Programmer

Responsibility:

Responsible for the underlying architecture for the software program, as well as for

overseeing the work being done by any other software engineers working on the project.

Act as a mentor for new or lower-level software developers or programmers, as well as for

all the members on the development team.

Code, test and troubleshoot programs utilizing the appropriate hardware, database, and

programming technology.

Trainer

Responsibility:

Training


26

Prepare and maintain training materials for standard products and end user applications.

Present using a variety of techniques and styles, including team exercises, group discussions,

presentation slides, and demonstrations.

Monitor level of success of training engagements and recommend suggestions for continued

improvements.

Work with clients to identify specific training needs and prepare individual curriculum to fulfil

needs.

Assist with end user support to ensure highest level of client satisfaction.

Provide assistance with software installation and implementation.

GUI Designer

Responsibility:

Design the graphical environment for the software ensuring that the different users will be

able to easily interact with the system

Responsible for ensuring that users with different access can only see certain aspects of the

system.

Librarian

Responsibility:

To ensure that all the relevant documents that are to be developed at every stage of the SDLC

are created in a timely and efficient manner. Also ensuring that these documents are up to

standard.


27

To keep all relevant document including receipts and the documents used in the analysis

phase in order and have them available when necessary.

Chief Engineer

Responsibilities

Determines the (stakeholders) needs that the product must meet and continually oversees the

development of the product to ensure that its on target to meeting those needs.

Listens to the stakeholders and then negotiates with the project team to address the

stakeholders needs (and desires).

Architect

Responsibilities

Ensuring the product or service under development achieves its performance and other

qualitative requirements.

Guiding the interfacing and Integration of the solution components of this project into the

existing architectural landscape.

Requirements Analyst

Responsibilities

Solicitation and elaboration of stakeholder needs and requirements.

Technical Writer

Responsibilities

Providing early feedback to the core and extended teams about e.g. desirable features.

Creating closer and more productive relationships with the various stakeholder communities

(through e.g. creating tutorials, reference manuals, technical overviews, brochures, video,

audio, etc.)


28

Designer

Responsibilities

Finding solutions to known requirements.

Exploring the requirement space.

Coder

Responsibilities

Advising on economic feasibility of implementing designs / requirements in available

programming languages.

Implementing i.e. user stories in whatever language is most suited to the problem at hand


29

Object Oriented Analysis Description of Existing System

At Smartbox, a manual inventory system is used. The day to day operation of Smartbox is as

follows.

A customer comes into the store seeking a particular item.

The store clerk takes the customer request and if the item is on the rack or in the

display case he/she takes the item, cashes it and gives it to the customer.

Whenever items are cashed, it is recorded in a log book.

If the item that the customer wants is not on the shelf then the clerk will go into the

stock room and search for the item.

This causes inefficiencies when dealing with their customers as it is error prone and

sometimes the item that the customer wants is not there. The waiting process at times is long and

tedious for the customer. Due to the inefficient inventory system that Smartbox has, at times the item

that the customer wants is not in stock. The store then tries and source the item. This can take 3-4

weeks.

It also takes time for the employee in the store to search for the item in the store room after

the customer has requested the item that they want. This takes a bit of time as there are a lot of items

in the store room. The customer waits an average time of 10-20 minutes for the clerk to search the

stock room and to return with the item or in some instances without the item if the item is out of

stock.


30

Smartbox does an inventory check every two weeks. This is really inefficient and time

consuming as it is manual and takes on average 1-2 days. It is error prone as:

The person counting the stock may miscount.

They may forget to write down the correct amount for a particular stock.

The book in which they keep track of the items sold may be incorrect or illegible and

this may result in the calculating of items sold to be wrong. This may also result in

the calculation of the items left in stock to be incorrect as at times they subtract the

number of items sold from that of the number of items that were bought.

Other problems sometimes arise as they cannot find invoices and sales receipts and as

such they cannot accurately calculate the number of items left in stock. Whenever this

happens they have to go into the stock room and check every item that is there.

At Smartbox, they do not have a computerized customer database in which they store

customer information and the repairs that they are getting done. The process is like this:

The customer brings an item to be repaired.

The item is recorded in a book and the customer is asked to make a deposit of half the

cost of repairing the item. The customers first name and telephone number is taken

and recorded in the book.

While the item is being repaired the technician at times takes items from the store

room to repair the item. However, this item is not recorded in the sales book that is to

be used to determine the items left in the store room. The customer is billed for this

item however a copy of the sales receipt is not made and placed with those used to

check sales made from the store room.


31

After the item is repaired the customer is called. At times the customer is not called

as their information cannot be found and they have to come to the store and ask if

their item is repaired.

The problems with this system are that Smartbox record all the customer and repair

information in a book. When the items are finished being repaired it takes a long time for the

employee to find the contact information for the customer to inform them to come and collect the

item. This is so as they have to search through the entire book looking for the item. At times there

are several of the same items being repaired so the employer has no idea which customer it belongs

to.

In addition to that, at times the parts used to repair the item are taken from the store and the

customer is billed for it along with being billed for the repairs that were done. They do not have a

proper inventory system in place that keeps track of the items that are used for repair and update the

amount of that item left in stock.


32

Problems, opportunities, objectives and constraint matrix

Cause-And-Effect Analysis System Improvement Objectives

Problem or

Opportunity

Causes and Effects System Objective System Constraint

Insufficient

customer data

This may be as a result of the

store clerk not taking all the

necessary information from

the customer. This may result

in the customer not being

contacted when their repair

has been completed. Also the

company will receive less

customers due to a bad

reputation

The proposed system

should reduce the time

spent searching for

customer information to

approximately 30

seconds. It should also

store all relevant data on

the customer.

Manual stock

checking system

is too outdated

and is not

preformed

regularly as

required

Stock is only checked every

two weeks. This results in

stock at times running out and

the store clerks not being

aware of it. This results in

orders not being filled as there

is no stock there. It may also

The automated system

will check stock every

day after closing hours

and will have a reorder

level that alerts the store

clerks or the relevant

persons that the item(s)


33

result in repairs not being

done as the stock to complete

these repairs are not there.

This will result in disgruntled

customers.

is/are running low and

needs to be refilled. It

will also attempt to

reorder the stock based

on the information that

was set. This

information includes the

number of items to

order, who to order it

from and contact

information for the

supplier.

The waiting

process at times

is long and

tedious for the

customer.

This is as a result of the store

clerk not knowing beforehand

if the item is in stock or not.

The store clerk will have to go

and check if the item is there.

If it isnt there then the

customer would have wasted

a lot of time waiting. This

result in the customer getting

irritated. This may also

To provide stock

information and

significantly reduce

delays

The system

developed must be

compatible with the

latest windows

operating system


34

prompt the customer to start

seeking other stores that offer

the same services and this

may result in Smartbox losing

customers.

Incorrect

Counting of

stock.

Stock is counted incorrectly

as a result of various things.

They include:

The person counting the

stock may miscount.

They may forget to write

down the correct amount for a

particular stock.

Whatever the reason this

miscount results in an

incorrect amount of stock

being reported and this may

result in further problems

when the expected amount of

stock is not there.

System will eliminate

manual checks with an

automated one.

This will be done by

updating the stock

inventory every time

something is sold and

every time an item is put

in stock.


35

Items taken

from stock room

and used in

repairs arent

being recorded

as sales.

This occurs when the

technician uses items from the

stock room without properly

recording it. This results in

the incorrect number of items

being counted as being in

stock.

The system will have a

feature which requires

the technician to record

the items that were used

in each repair and

whether or not that

particular item was

taken from the stock

room. If it was taken

from the stock room

then it will be deducted

from the main inventory

system and the number

of items left in stock

will be adjusted

accordingly.

34

Actor Identification Form of existing system

Who or what

provides input

to the system?

Clerk

Cashier

Who or what

receives outputs

from the

system?

Clerk Cashier Customer

Are interfaces

required to

other systems?

Are there events

that are

automatically

triggered at a

predetermined

time?

Who will

maintain

information in

the system?

The Clerk


35

Use Case Identification Form of existing system

Actors What are the main tasks of the actor?

What information does the actor needs from the system?

What information does the actor provide to the system?

Does the system need to inform the actor of any changes or events that have occurred?

Does the actor need to inform the system of any changes or events that have occurred?

Customer To request a service.

Purchase information

_____ _____ _____

Clerk To help manage stock and customer requests.

Previous stocks that have been written down and the amount sold(to calculate current stuck)

The current inventory of items.

_____ _____

Cashier Bills customer Price of item


36

Use Case Diagram of Existing System

Check store

room

Purchase

Item

Request

Repair

Request Internet

service

Takes customer

info

Assign

computer to

customer

Bills customer

Update

inventory

Cash items

Issues receipt

Order

item Supply data

Cashier

Clerk

Arrange

Payment

Customer

Choose time

Allocates

chosen time


37

Functional and Non-Functional Requirements Functional Requirements of the Ulti-Stocks and Database Management System

The Ulti-Stocks and Database Management System shall make it easier for the

employees of Smartbox to keep track of the items currently in stock.

The system shall have a display stock feature which enables employees to view their

entire stocks along with the amount in supply and prices.

The user shall be able to save customer information in a database so that it can be

easily accessed.

The sales and costs of items shall be automatically calculated and the system shall

prompt the user of ordering when the stocks are low.

The Smartbox System shall allow users to add new items to their stocks that they

want to be sold.

The cashier shall help with customers requests and make sure these services are met

and efficiently billed.

The clerk is to check the system inventory and adequate update it to maintain daily

business.

Software Features

Feature Benefits

Complete Inventory Tracking Record, update and search items such as product types and prices.

Automatic Reminder &

Calculator

Automatically calculates the sales and costs of items and prompts

the user of ordering when the stocks are low.

Edit Inventory Allows users to add new items to their stocks that they want to be


38

sold.

Controlled User Security Control the tasks users are allowed to perform, and the

information they can view. Allows users access to different areas

according to their responsibilities, while giving other users view-

only rights.

Display Feature Enables users to view their entire stocks along with the amount in

supply and prices.

Manage Customer Repairs Track customer information such as contact details and device

being repaired.

Non-functional requirements

The system shall prompt users to enter a password if before gaining access to any

information. This will enhance the security of the system

The system shall have user accounts which allow only specific user to have certain rights.

The system shall have quick recovery times of approximately 1-3 minutes in case of errors or

failures. This shall be dependent on the processor speed of the computer the user is using.

The system runtime shall take a matter of seconds to execute and display output. The system

shall be very robust.

The Smartbox System shall occupy little space of approximately 250mb

The Smartbox system shall be very scalable in the amount of platforms it can be installed on

i.e. laptops, desktops, notebooks and even some cellular phones, particularly those with


39

android technology.

Implementation of the software

In using this software, Smartboxs management will make sure the following objectives are met:

Train their staff appropriately in its use.

They will also ensure that all manuals applicable to the implementation of the system are

available when needed.

Provide all needed technical assistance.

Scheduling any special computer processing required for the implementation

Acquiring special hardware or software

Prepare data to be loaded into the system


40

Actor Form of Proposed System

Who or what

provides input

to the system?

Clerk

Cashier Merchant Technician

Who or what

receives outputs

from the

system?

Clerk Cashier Customer

Are interfaces

required to

other systems?

Are there events

that are

automatically

triggered at a

predetermined

time?

An order

request is

signaled when

stocks are on a

low

Who will

maintain

information in

the system?

The Clerk


41

Use Case Identification Form of Proposed system

Actors What are the main tasks of the actor?

What information does the actor needs from the system?

What information does the actor provide to the system?

Does the system need to inform the actor of any changes or events that have occurred?

Does the actor need to inform the system of any changes or events that have occurred?

Customer To request a service.

Purchase information

_____ _____ _____

Clerk To help manage stock and customer requests.

Previous stocks that have been written down and the amount sold(to calculate current stuck)

The current inventory of items.

_____ _____

Cashier Bills customer Price of item

Store clerk

Takes customer order, Record item that was bought, cashes item, Check if item is in stock, Count stock, Calculate sold items. Collect customer info, Contact customer

Invoice, Sales receipts, Price, Stock count, Customer info, Customer who owe,

Customer request, Calculation Customer info, Stock info,

Yes- that the store is running out of stock,

Yes- new stock is available

Merchant

To order new

Stock count ,

Confirmation

Yes- stocks are

back in stock

Yes remember to


42

stock Types of stock

needed,

Amount of

stock need

of purchase,

delivery dates

restock

Ulti-Stocks

System

Maintains

items currently

in stock

Item info The current

inventory of

items

Whether or not

the inventory

is empty

Database

System

Stores

customer

information

Customer

personal info

such as contact

info and

address

Info on

customers and

the items they

have left for

repairs

When item has

been repaired

Whether or not

the item have

been picked up

by the

customer

Technician 1.Identify the

problem with

the system

2. Fix the

problem and

bill for new

equipment

used to fix the

computer and

to then

compile a bill

Stock

inventory of

parts and items

that may be

needed.

Customer

billing for

repairs

If new parts

are required

and if the

customer

would like to

continue with

repairs by

purchasing

these parts.

The removal of

stock that has

been

purchased and

used in repairs.


43

Use Case Diagram of Proposed System

Check store

room

Purchase

Item

Request

Repair

Request Internet

service

Takes customer

info

Assign

computer to

customer

Bills customer

Update

inventory

Cash items

Issues receipt

Order

item Supply data

Cashier

Clerk

Arrange

Payment

Customer

Choose time

Allocates

chosen time

Buy Stocks

Stores customer info

Inventory System Database System

Merchant

Stores repair info

Tracks store

inventory

Calculate & generate

fee

Technician

Identify Problem

Fix Problem


44

Use Case Narratives

Author (s): Chevaughn WalkerUlti-Stocks System Date: March 28, 2014

Version: 1

USE CASE NAME: Request Purchase USE CASE TYPE USE CASE ID: SB2014-01 Business Requirements: PRIORITY: High SOURCE: PRIMARY BUSINESS

ACTOR: Customer

OTHER

PARTICIPATING

ACTORS:

Inventory System

OTHER INTERESTED

STAKEHOLDERS: Smartbox-Interested

DESCRIPTION: The use case describes the event of a customer requesting to purchase an

item. Once he/she has done so, clerk will assist them. PRE-CONDITION: The applicant must be able to pay for item.

The applicant must have valid identification TRIGGER: The uses case is initiated when the applicant selects the item he/she would

like to purchase. TYPICAL COURSE Actor Action System Response OF EVENTS:

Step 1: The customer indicates

they would like to purchase an

item

Step 2 The system validates product

identity.

Step 3:The system verifies product

availability Step 4: The customer

identifies the method of

payment

Step 5:The customer enters

their credit/debit card number

and currency type

Step 6: The system validates the

credit/debit card. Step 7: The system determines the total

cost for the item or items. Step 8: The system records purchase

information and releases the purchase


45

Step 9: The system generates receipt to

customer ALTERNATE COURSES:

Alt-Step 1: The customer may decide to not purchase an item but instead

just looking around at different items Alt-Step 6: If the customer did not specify credit or debit card as there

method of payment, the customer may choose to pay for the item with

cash. CONCLUSION: The use case concludes when the customer receives receipt. POST-CONDITION: The customers purchase info is recorded along with other customer data. BUSINESS RULES There are no refunds only exchanges.

Only cash and debit/credit cards are accepted. IMPLEMENTATION

CONTRAINTS AND

SPECIFICATIONS

The customer should be willing to provide certain personal info to be

stored

ASSUMPTIONS: The system updates the inventory of the item/s sold OPEN ISSUES:


46


Version: 1

USE CASE NAME: Store Repair Info USE CASE TYPE USE CASE ID: SB2014-02 Business Requirements: PRIORITY: High SOURCE: PRIMARY BUSINESS

ACTOR: Database System

OTHER

PARTICIPATING

ACTORS:

Customer

OTHER INTERESTED


DESCRIPTION: The use case describes the event of storing repair info for a customer PRE-CONDITION: The customer must have an item to be repaired.

The customer must have valid identification TRIGGER: The uses case is initiated when the customer states the problem with the

device. TYPICAL COURSE Actor Action System Response OF EVENTS:

Step 1: The customer indicates

they have an item for repair

Step 2 The system verifies if the device

can be repaired. Step 4:The system collects info on the

malfunctioning device and customer Step 3: The customer provides

device info and personal info

Step 5: The system records collected

data to database Step 6: The system issues date to

recollect device Step 7: The system records recollection

dates ALTERNATE COURSES:

Alt-Step 2: The device the customer wants to repair might be too

damaged for repair. CONCLUSION: The use case concludes when the customer receives date to collect device. POST-CONDITION: The customers device info is recorded along with some contact info. BUSINESS RULES There are no refunds only exchanges.


CONTRAINTS AND

SPECIFICATIONS

The customer should be willing to provide certain personal info to be

stored

ASSUMPTIONS: The customer will be back to collect the device OPEN ISSUES:


47


Version: 1 USE CASE NAME: Buy Stocks USE CASE TYPE USE CASE ID: SB2014-03 Business Requirements: PRIORITY: High SOURCE: PRIMARY BUSINESS

ACTOR: Merchant

OTHER

PARTICIPATING

ACTORS:

Inventory System

OTHER INTERESTED


DESCRIPTION: The use case describes the merchant buying products to restock the

inventory PRE-CONDITION: The inventory must be running low

The merchant must have supplier TRIGGER: The uses case is initiated when the inventory is low and a reorder is

alerted TYPICAL COURSE Actor Action System Response OF EVENTS:

Step 2: The store manager

contacts merchant to buy

stocks.

Step 1 A reorder stocks alert is

generated.

Step 3:The system generates a report on

what inventory items needs to be

replenished Step 4: The merchant buys

inventory items from the

stores suppliers.

Step 5: The system updates the

inventory system with the newly bought

items ALTERNATE COURSES:

Alt-Step 1: A reorder stocks alert is not generated because inventory is

not running low CONCLUSION: The use case concludes when the inventory system is updated with the

newly bought items. POST-CONDITION: The inventory system must be updated BUSINESS RULES There are no refunds only exchanges.


CONTRAINTS AND

SPECIFICATIONS

There might be a bug in the system in calling the reorder function even

when the inventory is not running low

ASSUMPTIONS: The inventory is running low OPEN ISSUES:


48


Version: 1 USE CASE NAME: Track store inventory USE CASE TYPE USE CASE ID: SB2014-04 Business Requirements: PRIORITY: High SOURCE: PRIMARY BUSINESS

ACTOR: Inventory System

OTHER

PARTICIPATING

ACTORS:

Customer, Clerk

OTHER INTERESTED


DESCRIPTION: The use case describes how the inventory is maintained by the system PRE-CONDITION: New items added to the inventory are verified

Items removed from the inventory via purchases are verified TRIGGER: This use case is initiated as soon as a purchase is made

TYPICAL COURSE Actor Action System Response OF EVENTS:

Step 1: A customer requests

purchasing an item

Step 2: The system is checked for item

availability Step 3: The system gets stored info on

the item selected for purchase Step 4: The system generates cost of

item Step 5: That item is removed from the

inventory for sale Step 6: The inventory system is updated

of the sale of an item, ALTERNATE COURSES:

Alt-Step 2: The requested item might not be available therefore a sale

would not be made CONCLUSION: The use case concludes when the inventory system is updated of the sale

of an item, which has been removed from stock POST-CONDITION: The inventory system tracks amount of each items left in stock BUSINESS RULES There are no refunds only exchanges.


CONTRAINTS AND

SPECIFICATIONS

Incorrect data might be stored about an item in stock

ASSUMPTIONS: The inventory updates itself after sales OPEN ISSUES:


49

Sequence Diagrams

Purchase Item Diagram

Customer Clerk User Interface Ulti-Stock System Database

Purchase Item

Check Stock Track itemfile Check

itemfile

Supply Data Takedata Verify showfile

Payment GiveItem Calculatefee StoreData

AcceptsItem GenerateFee UpdateInvento

ry

StoreData


50

Store Repair Info Sequence Diagram

Database

Repair Item

EnterInfo VerifyDevice createfile

IssueDate generatedate Verify storeData

Customer Clerk User Interface Ulti-Stock System


51

Buy Stocks Sequence Diagram

RequestOrder EnterOrder BuyStock

Update

Reorder SendReport

Merchant Inventory System Ulti-Stocks System User Interface


52

Track Inventory Sequence Diagram

PurchaseItem Purchase

CheckStock

GenerateCost

Customer Inventory System User Interface

getdata

Update

RemoveItem

Update


53

Class Diagram

Customer

-name :string

-id:int

-address:string

-down_payment:float

-tel_num:int

+Customer()

+Customer(string, int, string float, int)

+SetName(string):void

+GetName():string

+SetId(int):void

+GetId():int

+SetAddress(string):void

+GetAddress():string

+SetD_Payment(float):void

+GetD_Payment():float

+SetTelNum(int):void

+GetTelNum():int

+MakePayment():void

+OrderItems():void

+CollectItems():void

Technician

-repair_num:int

-cost:float

-items_used:string

-customer:Customer

-Technician()

-RecordItemsUsed(int,string):void

-GetCustomerInfo():void

Store Clerk

-name: string

-Id: integer

-salary: integer

-address: string

- inventory: Inventory

-customer: Customer

-merchant: Merchant

+checkStock(): bool

+getCustomer(): void

+getInventory(): void

+makePayment(): void

+addStock(): void

+addCustomer(): void

Inventory

Type: string

ItemNum: integer

Price: integer

TotNumofStock: integer

+ countStock(): integer

+ checkIfStockAvail(): bool

+ getType(): integer

+ searchStock(): bool

+ reorder(): void

+ calculate(): void

Merchant

-email:string

-phone: integer

-address:string

-merhantRep:string

-Item_name: string

-Price: integer

-Type: string

-amount: integer

+sell_stock(): void

+getOrder(): void

+deliverItem(): void

+recievePayment():void


54

Entity Relational Diagram

Cashier

Name

Address

ID

MerchandiserItem_name

Amount

ID_code

Type Price

Distributes

Product

Type

Amount

ID_code

Item_name

Price

Customer

Name

Address

ID

Cashed

Supply

Purchase

Repair

Repair_num

Date

Decription


55

Process Diagram

Place orderPurchase or

RepairCash product

Is

product

availablility?

Repair

Purchase Yes

No

Dropping off or

picking up?

Take customer

info

Make deposit

Reorder

Picking up

Dropping

Complete

payment


56

Activity Diagram

Cash product

Complete payment

Place order

Take customer info

and Item

Make deposit

Reorder Product

[Check if

Purchase] YES

NO

Purchase

[Check

product

availablility]

NO

YES

[Check place

next order]

YES

NO

[Check

purchase

more]NO

YES

Repair

[Check

Dropping

off]

YES

NO

Picking up


57

Appendices


58

Appendices

Minutes

Minutes for Meeting held on Sunday February 10, 2013.

Meeting was called to order at 1 pm.

The meeting was held to discuss the different aspects of the project that we had to work on. Work

was delegated to each member of the group. Carlington did the RSS form. Julia did the background

to the problem and the problem statement, whilst Chevaughn and Stephen did the Cause and Effect

table. The work was put together and Submitted via email to the teacher.

Further plans were made as to how to move forward with the project. A date for the next meeting

was set. It was agreed that the group would meet again on Sunday February 16, 2014.

Minutes for Meeting held on Sunday February 16, 2014.

Meeting was called to order at 12:30 pm.

The meeting was held to discuss corrections to the project as we had added a new aspect to the

project. The problem statement was updated and the solution was altered to add the new aspect of

the project that we had incorporated. The project plan was started and different portions of it were

allocated to the different members of the group. The deliverables for the project that were due in the

week was discussed and ways on how we were going to finish it was discussed. We agreed to meet

in class to collate what we had done. The next meeting was scheduled for Tuesday February 18,

2014.


59

Minutes for Meeting held on Tuesday February 18, 2014.


The meeting was held to discuss how far we were in the project. The project plan was put together. It

was discussed that we were a bit behind on the project and we needed to put more time into doing

the project. All aspects of the project plan were not completed and as such we agreed that we needed

to put more work into the project. We agreed to meet and complete as much of the project as

possible. The next meeting was set for Wednesday February 19, 2014.

Minutes for Meeting held on Wednesday February 19, 2014.


The meeting was held to complete the project plan and to discuss other aspects of the project that

needed completing. Issues in the project were addressed and work was done on the project. The risk

Mitigation was done in addition to the roles and responsibilities of the group members. Other aspects

of the project plan were completed and the meeting was adjourned at 4:30.

A date was not set for the next group meeting.

Minutes for meeting held on Sunday March 2, 2014.


The meeting was held to discuss how far we are in the project. The project plan was completed and

the project put in a specific order. The project was then scrutinized by the team to ensure that it met

all the requirements that the rubric asked for. The next phase of the project was discussed and steps


60

to how it should be approached were decided upon. It was agreed upon that Miss needed to look at

the project and see how far we were and if we were on the right track. It was also brought up by a

member of the group that the only place we should have the problem statement and the expected

solution was in the RFISS form. It was checked and found to be true and the project6 was then

corrected accordingly. The meeting was adjourned at 5:00 pm..

A date was not set for the next meeting.


61

Fact- Finding Technique

Interview

1. Where do you get all of your supplies from and how long does it take for those supplies to be

delivered to the store?

2. Are there different departments that have specific tasks to ensure the efficient running of the

organization? What are they and what are their roles?

3. What are some of the inefficiencies experienced when processing customers orders?

4. Describe the process of serving a customer?

5. How do you meet the demands for a specific item needed by a customer?

6. How do you keep track of items in stock?

7. Are there any concerns with the tracking of items in stock?

8. Is there a need for software to run your store and if so what kind of software?

9. What information is needed from the customer for them to order items?

10. Do you provide a delivery service?

11. What kind of convenience do you make for customers payment scheme?

12. How is a customer billed?

13. How do you keep track of the item that a customer has brought in to be repaired?

14. How do you bill the items that are used to repair a customer computer or other electronic

device? And how do you link that to the inventory that is kept?


62

References

ISQTB- International Software Testing Qualifications Board. (2012, January 12). What is Prototype

model- advantages, disadvantages and when to use it? Retrieved March 2014, from ISQTB - Exam

Certification: http://istqbexamcertification.com/what-is-prototype-model-advantages-disadvantages-

and-when-to-use-it/

Tilloo, R. (2013, August 4). What Is Incremental Model In Software Engineering ? Its Advantages

& Disadvantages. Retrieved March 2014, from Technotrice :

http://www.technotrice.com/incremental-model-in-software-engineering/

Software Engineering Project

Documents

Transcript of Software Engineering Project