Software Engineering Project

Group 3
Chevaughn Walker 1203383

Carlington Palmer 1201861
Julia Pottinger 1200639

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:
Group 3

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
Group 3

Project
Background
Group 3

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.
Group 3

PROJECT
PLAN
Group 3

SMARTBOX TECHNOLOGY
Phone: 876-962-1946
Email:smartbox123@hotmail.com
Fax: 876-622-7481
DATE OF REQUEST
02/09/2014
SERVICE REQUESTED FOR DEPARTMENT(S)

Customer Services, Repair Services
SUBMITTED BY (key user contact)

EXECUTIVE SPONSOR (funding authority)
Name: Carlington Palmer
Name: Stephen Hing
Title: Manager
Title: President
Office: C00T
Office:007
Phone: 567-4564
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_
Backlogged until date: ______________
Reason: ________________________________________
Request delayed
Request rejected
Authorized Signatures:
_____________________________________
Project Executive Sponsor
Group 3

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.
Group 3

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.
Group 3

Work Breakdown Structure

Ulti- Stocks & Data
Management
Problem
Definition
Risk
Analysis
Establish
Business
Objectives
Feasibility
Report
System
Analysis
Fact
Finding
/Elicitation
Identification
of Problem
Design and
Development
Define System
Requirements
Cause and
Effect Analysis
Network
Design
Design
System
Environment
Design Security
and System
Controls
Implementation,
Testing and
Training
Database
Design
User
Interface
Design
Debug and
Test Software
Code
User
Interface
Creating and
Testing
Databases
Train
Users
Create
User
Manual
Implement
Software
Code system
and security
controls
Install
Systems
Environment
and Network
Group 3

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 UltiStocks & Database Management System may be broken down into 4 levels.
Group 3

Precedence Table
Task Description
Detailed Activity
Task
Predecessor
Duration
(Days)
Identification of
Problem
Identifying the problem the

current system has
Establish Business Identify what it is the

Objectives
proposed system should
achieve
Feasibility Report Estimate budget, deadline.
Identify resources
Risk Analysis
Conduct Risk analysis of the
problem at hand
Fact
Conduct interviews and
Finding/Elicitation questionnaires.
Cause& Effects
Conduct cause and effect
analysis of the problem at
hand
Define System
Ascertain from the customer
Requirements
the features and behaviour of
the proposed system.
A,B
A,B
Network Design
15
25
16
Define how system will

interact with other systems
and establish network based
on strategic plan.
Database Design
-Create ERD
-Choose database structure
-Design database architecture
-design database schema
-design referential integrity
constraints
Environment
Define all the technology
Design
required to support the
Group 3

software application
Design Security
-define controls for access by
and System
different users
controls
-design how to protect the
15
13
H,I,J,K,L
15
H,I,J,K,L
25
10
10
database from
software/hardware failure
-define how to protect
communications on the
network
Design User
defines how user interacts
Interface
with system
Code User
Create the user interface
Interface
including GUI, mouse

controls, sound, video and
voice commands.
Create and Test
Create the actually database
Database
and test its efficiency and

correctness
Code system and
Limit access to authorized
security controls
users, and implement other

necessary security measures.
Install Systems
Install Operating System,
environment and
Local Area Network
Network
connections and Desktop

Computers.
Debug and Test
System Evaluation.
Software
Introduce prototype &

observe reactions. Perform
cost/benefit analysis.
Implement
Install the software and Test

9
Group 3
Software
it.
Create User
Create document to guide
Manual
Users on how to use the

10
10
system.
Train Users
Present final proposal. Train

users to use the system
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.
10
Group 3

Gantt chart
A 2
B
C
D
2
8
Task
15
25
16
Start
Duration
15
13
15
25
10
10
10
10
11
Group 3

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
2
3
4
Catastrophic
Critical
Marginal
Negligible
Risk Summary/Description
Customer fail to participate
Malfunction of Computers / System
failure
Lack of experience in Software
Development
Insufficient capital
Change of project requirements
Insufficient time to complete project
A team member may be unable to
continue school
Risk Category
Customer Risk/Customer
characteristics
Technology
Probability
14%
Impact(1-4)
3
10%
Technical Risk
35%
Budget
Scope
Business Impact
Project completion risks
30%
25%
15%
19%
2
3
3
3
12
Group 3

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
13
Group 3

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.
14
Group 3

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.
15
Group 3

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
16
Group 3

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
17
Group 3

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:
18
Group 3

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.
19
Group 3

Reporting Structure
Project Manager
Designer
Chief
Engineer
Development
Manager
Coder/
Programmer
Technical
Writer
/Librarian
Requirements
Analyst
Architect
GUI
Designer
Project
Database
Designer
Systems
Environment
Designer
Trainer
Interaction
Designer
20
Group 3

Roles and Responsibilities of team members

Role
Project Manager
Team Member
Functions
Julia Pottinger
-Coordinates and oversee all
Chevaughn Walker
activities of the project.

- Help ensure that the software
development process works as
it is intended.
Development Manager
Chevaughn Walker
- managing multiple priorities
Julia Pottinger
of conflicting projects.
-address issues from the team,
which it is unable to resolve
internally
Designer
Carlington Palmer
Design the entire network
Chevaughn Walker
inclusive of:
Stephen Hing
-defining controls for access
Julia Pottinger
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.
21
Group 3

- 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
Design the database.
Julia Pottinger
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
- Write code for all aspects of
Chevaughn Walker
the system and implement the
Stephen Hing
software
Julia Pottinger
-Create the actually database

and test its efficiency and
correctness
- Limit access to authorized
users, and implement other
22
Group 3

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
23
Group 3

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
- Creates the materials
Carlington Palmer
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
24
Group 3

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
25
Group 3

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.
26
Group 3

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.)
27
Group 3

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
28
Group 3

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.
29
Group 3

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.
30
Group 3

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.
31
Group 3

Problems, opportunities, objectives and constraint matrix
Cause-And-Effect Analysis
System Improvement Objectives
Problem or
Causes and Effects
System Objective
Insufficient
This may be as a result of the
The proposed system
customer data
store clerk not taking all the
should reduce the time
necessary information from
spent searching for
the customer. This may result
customer information to
in the customer not being
approximately 30
contacted when their repair
seconds. It should also
has been completed. Also the
store all relevant data on
company will receive less
the customer.
Opportunity
customers due to a bad

reputation
Manual stock
Stock is only checked every
The automated system
checking system two weeks. This results in
will check stock every
is too outdated
stock at times running out and
day after closing hours
and is not
the store clerks not being
and will have a reorder
preformed
aware of it. This results in
level that alerts the store
regularly as
orders not being filled as there clerks or the relevant
required
is no stock there. It may also
persons that the item(s)
32
System Constraint
Group 3

result in repairs not being
is/are running low and
done as the stock to complete
needs to be refilled. It
these repairs are not there.
will also attempt to
This will result in disgruntled
reorder the stock based
customers.
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
This is as a result of the store
To provide stock
The system
process at times
clerk not knowing beforehand
information and
developed must be
is long and
if the item is in stock or not.
significantly reduce
compatible with the
tedious for the
The store clerk will have to go delays
latest windows
customer.
and check if the item is there.
operating system
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
33
Group 3

prompt the customer to start

seeking other stores that offer
the same services and this
may result in Smartbox losing
customers.
Incorrect
Stock is counted incorrectly
System will eliminate
Counting of
as a result of various things.
manual checks with an
stock.
They include:
automated one.
The person counting the
This will be done by
stock may miscount.
updating the stock
They may forget to write
inventory every time
down the correct amount for a
something is sold and
particular stock.
every time an item is put
Whatever the reason this
in stock.
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.
34
Group 3
Items taken
This occurs when the

The system will have a
from stock room technician uses items from the feature which requires
and used in
stock room without properly
the technician to record
repairs arent
recording it. This results in
the items that were used
being recorded
the incorrect number of items
in each repair and
as sales.
being counted as being in
whether or not that
stock.
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.
35
Actor Identification Form of existing system

Who or what
Clerk
provides input
Cashier
to the system?
Who or what
receives outputs
from the
Clerk
Cashier
Customer
system?
Are interfaces
required to
other systems?
Are there events
that are
automatically
triggered at a
predetermined
time?
Who will
maintain
information in
The Clerk
the system?
34
Group 3

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?
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
35
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?
_____
_____
_____
Group 3

Use Case Diagram of Existing System
Arrange
Payment
Order
item
Supply data
<<Association>>
<<include>>
<<include>>
Update
inventory
Clerk
Check store
room
<<include>>
Purchase
<<extend>>
Item
Customer
Takes customer
info
Request
Repair
<<extend>>
Assign
computer to
customer
<<extend>>
Request Internet
service
<<include>>
<<include>>
Allocates
chosen time
Choose time
Bills customer
Cashier
Issues receipt
Cash items
36
Group 3

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
Complete Inventory Tracking
Benefits
Record, update and search items such as product types and prices.
Automatic Reminder &
Automatically calculates the sales and costs of items and prompts
Calculator
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
37
Group 3

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 viewonly 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
38
Group 3

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
39
Group 3

Actor Form of Proposed System
Who or what
Clerk
provides input
Cashier
Merchant
Cashier
Customer
to the system?
Who or what
receives outputs
from the
Clerk
system?
Are interfaces
required to
other systems?
An order
request is
Are there events signaled when
that are
stocks are on a
automatically
low
triggered at a
predetermined
time?
Who will
maintain
information in
The Clerk
the system?
40
Technician
Group 3

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?
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)
Cashier
Bills customer
Price of item
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,
Store clerk
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?
The current
inventory of
items.
_____
_____
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
41
_____
Yes- stocks are Yes

back in stock
remember to
Group 3
stock
Ulti-Stocks
System
Database
System
Technician
Maintains
items currently
in stock
Stores
customer
information
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

Types of stock
needed,
Amount of
stock need
Item info
Customer
personal info
such as contact
info and
address
Stock
inventory of
parts and items
that may be
needed.
42
of purchase,
delivery dates
The current
inventory of
items
Info on
customers and
the items they
have left for
repairs
Customer
billing for
repairs
restock
Whether or not
the inventory
is empty
When item has
been repaired
If new parts
are required
and if the
customer
would like to
continue with
repairs by
purchasing
these parts.
Whether or not
the item have
been picked up
by the
customer
The removal of
stock that has
been
purchased and
used in repairs.
Group 3

Use Case Diagram of Proposed System
Arrange
Payment
Order
item
Supply data
Update
inventory
<<Association>>
<<include>>
<<include>>
Clerk
Check store
room
<<include>>
Purchase
<<extend>>
Item
Customer
Takes customer
info
Request
Repair
Request Internet
service
<<include>>
<<extend>>
Assign
computer to
customer
<<extend>>
<<depend>>
<<include>>
Choose time
Bills customer
Allocates
chosen time
Issues receipt
Cashier
Cash items
Tracks store
inventory
Stores customer info

<<extend>>
<<depend>>
Calculate & generate

fee
Stores repair info

Database System
Inventory System
<<depend>>
Identify Problem
Buy Stocks
Fix Problem
43
Merchant
Technician
Group 3

Use Case Narratives
Author (s): Chevaughn WalkerUlti-Stocks System
USE CASE NAME:

USE CASE ID:
PRIORITY:
SOURCE:
PRIMARY BUSINESS
ACTOR:
OTHER
PARTICIPATING
ACTORS:
OTHER INTERESTED
STAKEHOLDERS:
DESCRIPTION:
PRE-CONDITION:
TRIGGER:
TYPICAL COURSE
OF EVENTS:
Request Purchase
SB2014-01
High
Date: March 28, 2014

Version:
1
USE CASE TYPE
Business Requirements:
Customer
Inventory System
Smartbox-Interested
The use case describes the event of a customer requesting to purchase an

item. Once he/she has done so, clerk will assist them.
The applicant must be able to pay for item.
The applicant must have valid identification
The uses case is initiated when the applicant selects the item he/she would
like to purchase.
Actor Action
System Response
Step 1: The customer indicates Step 2 The system validates product
they would like to purchase an identity.
item
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
44
Group 3
ALTERNATE COURSES:
CONCLUSION:
POST-CONDITION:
BUSINESS RULES
IMPLEMENTATION
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:
OPEN ISSUES:

Step 9: The system generates receipt to

customer
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.
The use case concludes when the customer receives receipt.
The customers purchase info is recorded along with other customer data.
There are no refunds only exchanges.
Only cash and debit/credit cards are accepted.
The customer should be willing to provide certain personal info to be
stored
The system updates the inventory of the item/s sold
45
Group 3

USE CASE NAME:

USE CASE ID:
PRIORITY:
SOURCE:
PRIMARY BUSINESS
ACTOR:
OTHER
PARTICIPATING
ACTORS:
OTHER INTERESTED
STAKEHOLDERS:
DESCRIPTION:
PRE-CONDITION:
TRIGGER:
TYPICAL COURSE
OF EVENTS:
ALTERNATE COURSES:
CONCLUSION:
POST-CONDITION:
BUSINESS RULES
IMPLEMENTATION
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:
OPEN ISSUES:
Store Repair Info

SB2014-02
High

Version:
1
USE CASE TYPE
Database System
Customer
Smartbox-Interested
The use case describes the event of storing repair info for a customer
The customer must have an item to be repaired.
The customer must have valid identification
The uses case is initiated when the customer states the problem with the
device.
Actor Action
System Response
Step 1: The customer indicates Step 2 The system verifies if the device
they have an item for repair
can be repaired.
Step 4:The system collects info on the
malfunctioning device and customer
Step 3: The customer provides Step 5: The system records collected
device info and personal info
data to database
Step 6: The system issues date to
recollect device
Step 7: The system records recollection
dates
Alt-Step 2: The device the customer wants to repair might be too
damaged for repair.
The use case concludes when the customer receives date to collect device.
The customers device info is recorded along with some contact info.
The customer should be willing to provide certain personal info to be
stored
The customer will be back to collect the device
46
Group 3


USE CASE NAME:
USE CASE ID:
PRIORITY:
SOURCE:
PRIMARY BUSINESS
ACTOR:
OTHER
PARTICIPATING
ACTORS:
OTHER INTERESTED
STAKEHOLDERS:
DESCRIPTION:
PRE-CONDITION:
TRIGGER:
TYPICAL COURSE
OF EVENTS:
ALTERNATE COURSES:
CONCLUSION:
POST-CONDITION:
BUSINESS RULES
IMPLEMENTATION
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:
OPEN ISSUES:
Buy Stocks
SB2014-03
High

Version:
1
USE CASE TYPE
Merchant
Inventory System
Smartbox-Interested
The use case describes the merchant buying products to restock the
inventory
The inventory must be running low
The merchant must have supplier
The uses case is initiated when the inventory is low and a reorder is
alerted
Actor Action
System Response
Step 2: The store manager
Step 1 A reorder stocks alert is
contacts merchant to buy
generated.
stocks.
Step 3:The system generates a report on
what inventory items needs to be
replenished
Step 4: The merchant buys
Step 5: The system updates the
inventory items from the
inventory system with the newly bought
stores suppliers.
items
Alt-Step 1: A reorder stocks alert is not generated because inventory is
not running low
The use case concludes when the inventory system is updated with the
newly bought items.
The inventory system must be updated
There might be a bug in the system in calling the reorder function even
when the inventory is not running low
The inventory is running low
47
Group 3


USE CASE NAME:
USE CASE ID:
PRIORITY:
SOURCE:
PRIMARY BUSINESS
ACTOR:
OTHER
PARTICIPATING
ACTORS:
OTHER INTERESTED
STAKEHOLDERS:
DESCRIPTION:
PRE-CONDITION:
TRIGGER:
TYPICAL COURSE
OF EVENTS:
ALTERNATE COURSES:
CONCLUSION:
POST-CONDITION:
BUSINESS RULES
IMPLEMENTATION
CONTRAINTS AND
SPECIFICATIONS
ASSUMPTIONS:
OPEN ISSUES:
Track store inventory

SB2014-04
High

Version:
1
USE CASE TYPE
Inventory System
Customer, Clerk
Smartbox-Interested
The use case describes how the inventory is maintained by the system
New items added to the inventory are verified
Items removed from the inventory via purchases are verified
This use case is initiated as soon as a purchase is made
Actor Action
System Response
Step 1: A customer requests
Step 2: The system is checked for item
purchasing an 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,
Alt-Step 2: The requested item might not be available therefore a sale
would not be made
The use case concludes when the inventory system is updated of the sale
of an item, which has been removed from stock
The inventory system tracks amount of each items left in stock
Incorrect data might be stored about an item in stock
The inventory updates itself after sales
48
Group 3

Sequence Diagrams
Purchase Item Diagram
Customer
Purchase Item
Supply Data
Payment
AcceptsItem
Clerk
User Interface
Check Stock
Takedata
Ulti-Stock System
Track itemfile
Verify
GiveItem
Calculatefee
GenerateFee
UpdateInvento
ry
49
Check
itemfile
showfile
StoreData
StoreData
Database
Group 3

Store Repair Info Sequence Diagram
Customer
Repair Item
IssueDate
Clerk
User Interface
Ulti-Stock System
EnterInfo
generatedate
VerifyDevice
Verify
50
createfile
storeData
Database
Group 3

Buy Stocks Sequence Diagram
Merchant
User Interface
Inventory System
Ulti-Stocks System
RequestOrder
EnterOrder
Update
SendReport
BuyStock
Reorder
51
Group 3

Track Inventory Sequence Diagram
Customer
Inventory System
User Interface
PurchaseItem
Purchase
CheckStock
getdata
Update
GenerateCost
RemoveItem
Update
52
Group 3

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
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
Technician
-repair_num:int
-cost:float
-items_used:string
-customer:Customer
-Technician()
-RecordItemsUsed(int,string):void
-GetCustomerInfo():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
53
Group 3

Entity Relational Diagram

Repair_num
Decription
Date
Repair
Address
Address
ID
ID
Name
Name
Cashier
Cashed
Distributes
Customer
Purchase
ID_code
Amount
Item_name
Merchandiser
Supply
Product
Item_name
Type
Price
ID_code
Type
Price
Amount
54
Group 3

Process Diagram
Reorder
No
Place order
Purchase or
Repair
Purchase
Is
product
availablility?
Picking up
Complete
payment
Repair
Dropping off or
picking up?
Dropping
Take customer
info
Make deposit
55
Yes
Cash product
Group 3

Activity Diagram
Reorder Product
NO
YES
[Check place
next order]
[Check if
Purchase]
[Check
product
availablility]
YES
Place order
Purchase
[Check
purchase
more]
NO
NO
Cash product
YES
YES
NO
Repair
[Check
Dropping
off]
NO
Picking up
YES
Take customer info
and Item
Make deposit
56
Complete payment
Group 3

Appendices
57
Group 3

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.
58
Group 3

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
59
Group 3

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.
60
Group 3

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?
61
Group 3

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-disadvantagesand-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/
62

Software Engineering Project

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Engineering Project

Uploaded by

Copyright:

Available Formats

Group 3

Chevaughn Walker 1203383

Julia Pottinger 1200639

Software Engineering: Analysis & Design

Company Name: Smartbox

Name of System: Ulti-Stocks and Database Management

Julia Pottinger 1200639

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

Julia Pottinger 1200639

Julia Pottinger 1200639

Background to the Problem

Julia Pottinger 1200639

Julia Pottinger 1200639

SERVICE REQUESTED FOR DEPARTMENT(S)

SUBMITTED BY (key user contact)

Approved Budget $ __500,000___________

Julia Pottinger 1200639

Identification and Justification of process model and methodology being

Julia Pottinger 1200639

Julia Pottinger 1200639

Work Breakdown Structure

Julia Pottinger 1200639

Final product delivered.

Julia Pottinger 1200639

Identifying the problem the

Establish Business Identify what it is the

Define how system will

Define all the technology

required to support the

Julia Pottinger 1200639

-define controls for access by

-design how to protect the

defines how user interacts

Create the user interface

including GUI, mouse

Create and Test

Create the actually database

and test its efficiency and

Code system and

Limit access to authorized

users, and implement other

Install Operating System,

Local Area Network

connections and Desktop

Debug and Test

Introduce prototype &

Install the software and Test

Create document to guide

Users on how to use the

Julia Pottinger 1200639

Present final proposal. Train

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.

Julia Pottinger 1200639

Julia Pottinger 1200639

Risk Mitigation table

Julia Pottinger 1200639

Lack of training and understanding of software

Julia Pottinger 1200639

Julia Pottinger 1200639

Malfunction of Computers / System failure

Julia Pottinger 1200639

Approved Budget $ 500,000_________