Samsan Tech, Inc.

AI Voice Command with Image Recognition Software

A Project Study Presented to the

College of Informatics and Computing Sciences
Batangas State University
Batangas City

In Partial Fulfillment of the Requirements for the Courses:

IT311: Systems Administration and Maintenance
IT312: System Integration and Architecture
IT313: System Analysis and Design
IT314: Web Systems and Technologies

By:

Name1
Name2
Name3
Name4
Name5

IT-NT-3101

December 2020
 Table of Contents

I. Introduction
I.1. Project Context
I.2. Purpose and Description
I.3. Objectives
I.4. Scope and Limitations

II. System Analysis

II.1. Development Model
II.2. Development Approach
II.3 Schedule and Timeline
II.4 Project Teams and Responsibilities
II.4.1 Responsibilities
II.4.2 Activities and Tasks

III. System Design

III.1. System Analysis and Design
III.1.1. Functional Requirements
III.1.2. Non-Functional Requirements
III.2. Data Flow Diagram
III.3. Graphical User Interface

IV. System Integration

IV.1. Integration Support
IV.1.1. Resources and their Allocation
IV.1.2. Training
IV.1.3.Testing
IV.1.4.Change procedures and history

V. System Administration and Maintenance

V.1. Risk Management Process
V.2. Financial Impact
V.3 Timeline Impact
V.4 Risk Monitoring
V.5. Risk Categories
V.6. Risk Assessment Matrix
V.7. Mitigation Grading Matrix
V.8. Stakeholder Tolerances
I. INTRODUCTION

A. Project Context
 This will be the general overview of the project
 Introduce your project by capturing the reader’s interest in the first paragraph.
 Discuss the problem background and why you decided to develop your project.
What’s wrong with the traditional method?

B. Purpose and Description

 Provide a short description of the project being specified and its purpose, including
relevant benefits (or beneficiaries)
o What is your main purpose in doing the project?
o Who is/are your target clients, end user/s or beneficiaries of the project?

C. Objectives
 Detailed statements or elaboration of the project goal and should be clearly stated and
logically presented
 Present the sub-objectives in a logical sequence from factual to analytical along
mutually exclusive dimensions (no overlaps) with the exclusion of the overview,
expected conclusions, implications and recommendations of the project.
 Specific objectives should be SMART. Specific, Measurable, Achievable, Realistic
and Time-bounded.

D. Scope and Limitations

 Discuss here the boundaries of the study and those likely part of the study
researcher/s do not intend to accomplish (or what the design of the study inherently
will not allow)
 Describe any global limitations or constraints that have a significant impact on the
design of the system/software (and describe the associated impact).
 Describe any items or issues that will limit the options available to the developers.
These might include: corporate or regulatory policies; hardware limitations (timing
requirements, memory requirements); interfaces to other applications; specific
technologies, tools, and databases to be used; parallel operations; language
requirements; communications protocols; security considerations; design
conventions or programming standards
 Limitations that are not readily apparent at the start of the research project may
develop or become apparent as the study progresses. In any case, limitations should
not be considered alibis or excuses; they are simply factors or conditions that help
the reader get a truer sense of what the study results mean and how widely they can
be generalized. While all project have some inherent limitations, you should address
only those that may have a significant effect on your particular study.
II. SYSTEM ANALYSIS

II.1. Development Model

This may include the following models: Conventional waterfall type,
Incremental, Throw-away, prototyping, Evolutionary prototyping and any other
model which is most appropriate to the kind of research project being
undertaken.

II.2. Development Approach

This may include either Top down or Bottom-up approach of development.

II.3 Schedule and Timeline

It may contain Gantt chart, Activity Chart, Critical Path Analysis and other
scheduling techniques that will list the activities to be done in order to achieve
the objective. Usually it includes the phases and its sub-phase of the systems
development life cycle.

II.4 Project Teams and Responsibilities

It should contain the assignments of modules and activities to be done by each
team member.

II.4.1 Responsibilities
In this section, identify the System Proponent, the name of the responsible or
issuing organization, and titles and telephone numbers of the staff who serve as
points of contact for the system integration. It should also include who has
approval authority for each unit of the system. If this activity is contracted out,
list the names and phone numbers of the contractor responsible for the
development and integration.

II.4.2 Activities and Tasks

This section provides a brief description of each major task required for the
integration of the system. Also include a schedule for when these tasks are
expected to be completed. Add as many subsections as necessary to this section
to describe all the major tasks adequately. Include the following information for
the description of each major task, if appropriate:
a) What the task will accomplish
b) Resources required to accomplish the task
c) Key person(s) responsible for the task
d) Criteria for successful completion of the task

Examples of major tasks are the following:

a) providing overall planning and coordination for the integration
b) providing appropriate training for personnel
c) providing appropriate documentation on each unit for integration
d providing audit or review reports
e) documented software unit and database
e) establish software requirements
f) establish test procedures
g) conduct unit testing
h) conduct qualification testing
i) integrate units into system
III. SYSTEM DESIGN

III.1. SYSTEM ANALYSIS AND DESIGN

System analysis focuses on system requirement description; defines the system functional
requirements, and requirement specification of the proposed system.

System design provides the technical specification and construction of the solution for the
requirements identified during the system analysis phase of the research/project. This
should include but not limited to: details of data structures, architecture, interfaces, and
procedural detail of software component of the research/project.

III.1.1. Functional Requirements

III.1.2. Non-Functional Requirements

III.2. DATA FLOW DIAGRAM

Context Diagram and Level-0 Diagram shall be included in the documentation.

III.3. GRAPHICAL USER INTERFACE

Include screenshots of the web design
IV. SYSTEM INTEGRATION

The integration document defines the activities necessary to integrate the software units and
software components into the software item. The integration document contains an overview of
tile system, a brief description of the major tasks involved in the integration, the overall
resources needed to support the integration effort. The plan is developed during the
Development Phase and is updated during the Integration and Test Phase; the final version is
provided in the Implementation Phase.

IV.1. INTEGRATION SUPPORT

This section describes the support software, materials, equipment, and facilities required for
the integration, as well as the personnel requirements and training necessary for the
integration.

IV.1.1. Resources and their Allocation

In this section, list all support software, materials, equipment, and facilities required for the
integration. Describe the test environment and any resources needed. Describe the number
of personnel needed and an estimate of the costs for them.

IV.1.2. Training
This section addresses the training, if any, necessary to prepare for the integration and
maintenance of the system; it does not address user training, which is the subject of the
Training Plan. If contractors are performing the integration functions and activities, this
may not be necessary. It however, State staff are performing these activities some training
might be needed. List the course(s) needed by title, instructor and cost.

IV.1.3.Testing
In this section, list all the test requirements for each unit. If more than one unit is being
tested, include a description for each unit. Include the descriptions of the data included,
procedures for testing, who is responsible for the testing and a schedule. This could be
accomplished in one plan or several depending on the complexity of the unit being tested.

IV.1.4.Change procedures and history

Include all changes made during the unit testing. This information should be included in the
Configuration Management Plan and updated during the Development Phase.
V. SYSTEM ADMINISTRATION AND MAINTENANCE

V.1. RISK MANAGEMENT PROCESS

Define process / approach.

V.2. FINANCIAL IMPACT

Estimated Funds Required & Budgetary Impact

ESTIMATE ADDITIONAL COMMENTS

Initial fees $

Recurring fees $  

Assumptions $

Pricing
 
Methodology

Budget Impact

V.3 TIMELINE IMPACT

Describe any impact to plan schedule. List any start / end dates effected.
V.4 RISK MONITORING

REVIEWS OF RISKS & ISSUES – Check for issues that may have escalated.
REVIEW FREQUENCY

PARTIES RESPONSIBLE FOR REVIEWING

MONITORING
REVIEW FREQUENCY

PARTIES RESPONSIBLE FOR REVIEWING

REPORTING
REVIEW FREQUENCY

PARTIES RESPONSIBLE FOR REVIEWING

 
V.5. RISK CATEGORIES

Define grouping methodology / organization process of potential causes.

V.6. RISK ASSESSMENT MATRIX

LOW MEDIUM HIGH EXTREME

0 1 2 3
Acceptable ALARP as low Generally Intolerable
RISK as reasonably Unacceptable
RATING practicable
KEY

Ok to Proceed Take Mitigation Seek Support Place Event

Efforts On Hold

SEVERITY
ACCEPTABLE TOLERABLE UNDESIRABLE INTOLERABLE
 
Little to no effect Effects are felt, Serious impact to Could result in
on event but not critical to course of action disaster
outcome and outcome

IMPROBABLE LOW MEDIUM MEDIUM HIGH

Risk is Unlikely –1– –4– –6– – 10 –

to Occur
LIKELIHOOD

POSSIBLE LOW MEDIUM HIGH EXTREME

risk will likely –2– –5– –8– – 11 –

occur

PROBABLE MEDIUM HIGH HIGH EXTREME

risk will occur –3– –7– –9– – 12 –

V.7. MITIGATION GRADING MATRIX

RISK MATRIX
SECTIONS IMPACTED
LOW MEDIUM HIGH EXTREME
LOW N D C A
LIKELIHOOD MEDIUM D C B A
HIGH C B A A

RISK MITIGATION BASED UPON GRADE

GRADE POSSIBLE ACTION

As a priority, mitigation actions reducing both likelihood
A and seriousness are to be identified and implemented at start
of project.
Mitigation actions reducing both likelihood and seriousness
B are to be identified and implemented throughout course of
project.
Mitigation actions reducing both likelihood and seriousness
C are to be identified and costed for possible action should
funds permit execution.
Risk to be noted: No action is required unless grading
D
increases over time.
Risk to be noted: No action is required unless grading
N
increases over time.

V.8. STAKEHOLDER TOLERANCES

Define time and limitations of cost contingency reserves.

 FORMAT OF DOCUMENT

1. Paper Size : The paper required must conform to the following requirements:
 Color: White
 Size: 8 ½ by 11 inches

2. Page Margins: For every page, margins on all sides shall be two and a half centimeters
or one inch. All information including page numbers should be within the text area. The
margin regulations must be met on all pages used in the project document including
pages with figures, tables, or illustrations.

3. Text/Font Styles and Sizes:

a. Acceptable serif type font style is Arial 12 or Times New Roman 13.
b. Text must be justified on both sides.

4. Spacing, Paragraphing and Indentions: The general text of the document shall be
double spaced.

5. Page Numbering: Page numbering must start from I-Introduction. Page number must be
placed at the bottom (center) of every page.