Contents 1.00 SYSTEM DESIGN DOCUMENTATION (SDD 2 1.10 Introduction 3 1.20 Purpose of the SDD 3 1.30 Scope 3 1.40 Control Objective 4 CHAPTER2 6 2.00SYSTEM REQUIREMENTS 6 2.10 Functional Requirements: 6 2.20 Performance Requirements: 6 2.30 Non Functional Requirements: 6 2.40 External Interface Requirements: 7 2.50 Operating environment 7 3.00 CHAPTER 3 9 3.10 SYSTEM AND SUB SYSTEMS ARCHITECTURE 9 3.20 Communication architecture 9 3.30 Customer Architectural design 10 3.40 Admin Architectural design 11 CHAPTER 4 12 4.00 DATABASE DESIGN: 12 4.10 TABLES 12 CHAPTER 5 15 5.00 INPUT FORMATS AND OUTPUT LAYOUTS 15 5.10 Input Design 15 5.20 Menus 15 5.30 Dialog Box 15 6.00 HUMAN MACHINE INTERFACES 16 6.10 New user registration interface 16 6.20 Admin login monitoring interface 16 6.30Admin interfaces 17 6.40 Available stock 17 6.50 Admin Backup interface 18 6.60 Sales report 18 6.70 Transaction receipt 19 CHAPTER 7 20 7.00 DETAILED DESIGN 20 CHAPTER 8 21 8.00 PROCESSING LOGIC 21 CHAPTER 9 22 9.00 SYSTEM INTEGRITY CONTROLS 22 9.10 System Integrity Controls 22

CHAPTER1
1.00 SYSTEM DESIGN DOCUMENTATION (SDD)
1.10 Introduction
Online store system will allow buying of goods and services from merchants who sell on the Internet. Since the emergence of the World Wide Web, merchants have sought to sell their products to people who surf the Internet. Shoppers can visit web stores from the comfort of their homes and shop as they sit in front of the computer. Consumers buy a variety of items from online stores. In fact, people can purchase just about anything from companies that provide their products online. Hardware, software, and other computer accessories are just some of the hundreds of products consumers can buy from an online Store management system.
1.20 Purpose of the SDD The purpose of this SDD is to provide developers of online store management system with guidance in understanding and meeting the design documentation requirements contained in the online store management system specification. To accomplish this, the guideline addresses two goals. First, the guideline increases the vendors’ awareness of the importance of design documentation to the security of their system throughout the system life-cycle. Second, the guideline forms an initial basis of understanding between the vendor and evaluator communities concerning what is expected by the evaluation team in the review process and deliverables for design documentation. Any examples in this document are not to be construed as the only implementation that will satisfy the online store management system requirement. The examples are merely suggested implementations.

The recommendations in this document are also not to be construed as supplementary requirements to the online store management system. The online store management system is the only metric against which systems will be evaluated.

This guideline is part of the Technical Guidelines Program to provide helpful guidance on online store management system issues and the features they address.
1.30 Scope
Design Documentation of an online store management system requirement is one of the four types of documentation required by the online store management system. The other three documentation requirements are-: * Trusted Facility Manual (TFM). * Security Features Users Guide (SFUG), * Test Plan Documentation. Design Documentation assists vendors during the system life-cycle by thoroughly defining the policies that the system enforces.
It also provides the material by which the evaluator can assess whether, and to what degree, the design intent was carried into the implementation.

The design documentation is intended to guide the implementation of the product; it is not intended merely as an abstract philosophical exercise completely divorced from the "real" product.

Design documentation also increases the developer's level of understanding of the system. It should facilitate the correct implementation of the intended behavior and features of the system. This guideline will discuss design documentation and its features as they apply to computer systems and products that are being built with the intention of meeting the requirements of the online store management system.
1.40 Control Objective
Each of the online store management system requirements serves to ensure that one of the three basic control objectives for 1.trusted computing security policy, 2.accountability, and 3.assurance - are satisfied.

Throughout the system life-cycle, design documentation aids in attaining the third objective, assurance, by helping to "substantiate claims for the completeness of access mediation and degree of tamper resistance."

The online store management system gives the following as the Assurance Control Objective:-

"Systems that are used to process or handle classified or other sensitive information must be designed to guarantee correct and accurate interpretation of the security policy and must not distort the intent of that policy. Assurance must be provided that correct implementation and operation of the policy exists throughout the system's life-cycle."

Design documentation plays an important role in providing this life-cycle assurance. It demonstrates that correct implementation and enforcement of the system's security policy exists throughout the system's life-cycle. As it relates to this control objective, design documentation facilitates the efforts of vendors and system developers in modifying and maintaining the system throughout its life-cycle, without compromising the trustworthiness of the system.

In addition, design documentation serves as a useful training tool. Design documentation presents a technical history of the system, containing documentation on past changes to the system as well as the current system. It can be used in the training of new systems programmers and hardware engineers to familiarize them with the system. 1.50 Constraints * The graphical user interface is only in English. * Login and password is used for identification of the customer. * A general user cannot be able to buy any product unless he /she registers in the system to be a legally identified customer.
1.60 Assumptions and Dependencies
The product does require back-end database server MySQL for storing the username and password for different types of user of the system as well as various databases regarding various insurance information. 1. Assumptions: * User must be trained for basic computer functionalities. * User must have the basic knowledge of English * The system must be able to respond to database software within reasonable time. 2. Front-end (user interaction): * The product will require a computer with an application program or with any other application program and a communication channel. * The speed of the communication channel (if any) must be, at a minimum 28.8 kbps in order to support message transfer in reasonable time.
1.70User Class and Characteristics:
There are 3 types of user of this software- * General public
General public can use the system to access the company mission and vision. They can also have a view of some of the product offered by the company. The general user can also register to be a customer
General user cannot buy the products. * Customers Customers are using the system for viewing and buying the products. Customer can also write feedbacks for products and services * Administrator. Administrators can add, edit & delete products and provide services to the customer. Administrator can see the daily sell. It can also get to know the product with high demand by viewing the reports of what is being requested most.
CHAPTER2
2.00SYSTEM REQUIREMENTS 2.10 Functional Requirements:
The System must provide following functionalities— * Keeping records of admission of customers. * Keeping the records of products. * Storing the items selected by the customer in the temporary storage. * Keeping the receipt transaction number in order to identify customer when he/she comes to correct the goods.
2.20 Performance Requirements:
In order to maintain an acceptable speed at maximum number of uploads allowed from a particular customer will be any number of users can access the system at any time. Also connections to the servers will be based on the criteria of attributes of the user like his location, and server will be working whole 24X 7 times.
2.30 Non Functional Requirements:
Following Non-functional requirements will be there in the Insurance on internet:
i). Secure access of confidential data (customer’s details). ii). 24 X 7 availability. iii). Better component design to get better performance at peak time. iv). Flexible service based architecture will be highly desirable for future extension Non functional requirements define system properties and constraints It arise through user needs, because of budget constraints or organizational policies, or due to the external factors such as safety regulations, privacy registration and so on.
Various other Non-functional requirements are:
1. Security
2. Reliability
3. Maintainability
2.40 External Interface Requirements: * User Interface:
User of the system will be provided with the Graphical user interface, there is no command line interface for any functions of the product. The user will get 2 pages
1. Login page followed by Password * Hardware Interface:
Hardware requirements for Insurance on internet will be same for both the parties which are follows:
Processor: - Pentium I or above.
RAM: - 128 MB or above.
HD: - 20 GB or above.
NIC: - For each party * Software Interface:-
Software required to make working of product is:- * Operating System: Windows XP/vista/7 or later version, Linux OS which supports networking. * Macromedia Dreamweaver 8 * WAMPServer
2.50 Operating environment Hardware Configuration
1.At least 2.0 GHz Processor speed
2. 1GB RAM minimum
3. At least 40GB HDD capacity

Software Configuration
1. OS : Windows XP or Windows 07 and above
2. Wamp Server that consists of : - Apache –Web server . -MySQL – for Database Design -PHPMyAdmin
3.Macromedia Dreamweaver 8 –for creating interfaces.
Website Interface requirements
Any Web browsers: Mozilla Firefox, Google Chrome, Opera and Internet Explorer
User Environment requirements
Internet access
Any Web browsers: Mozilla Firefox, Google Chrome, Opera and Internet Explorer
Web Environment
Any Web browsers: Mozilla Firefox, Google Chrome, Opera and Internet Explorer.

3.00 CHAPTER 3
3.10 SYSTEM AND SUB SYSTEMS ARCHITECTURE

3.20 Communication architecture
The two parties should be connected through either by LAN or WAN for the communication. SENDER
RECEIVER
Communication channels

Users interface Architecture

Gen.user

SERVER
DATABASE
REQUEST
Customer
ADMIN

3.30 Customer Architectural design
View delivery report

Id & password customer login

Rejected if not matched

Delivery details Rejected if not available
Selected products
Store table

Rejected if not available

Buy product

Product details
Make payment
Add feedback
See selected items

If available in store

Selected items
Total bill
Payment details
Feed ack details

Product table
Temp table
Account table

Feedback

3.40 Admin Architectural design
Add products
Edit products
View daily sell
Add & view daily report
View feedback
Feedback table
Sell table
Delete products
Product table
Category table
Verified data
ADMIN
LOGIN
VIEW CUSTOMER DETAILS
Data verification
Id & password
Customer details
Delivery details
Feed back
Sell details
Product details
Category details

LOGIN TABLE

Rejected if not matched

Store Table
Feed back User table

CHAPTER 4
4.00 DATABASE DESIGN:
A database design is a collection of stored data organized in such a way that the data requirements are satisfied by the database. The general objective is to make information access easy, quick, inexpensive and flexible for the user. There are also some specific objectives like controlled redundancy from failure, privacy, security and performance.
A collection of relative records make up a table. To design and store data to the needed forms database tables are prepared. Two essential settings for a database are:
 Primary key: - The field that is unique for all the record occurrences.
 Foreign key: - The field used to set relation between tables. Normalization is a technique to avoid redundancy in the tables.
4.10 TABLES Category table Column name | Data type | Key constraints | Cat_id | Int | Primary key(not null) | Cat_name | Varchar (20) | Not null |

Product table Category name | Data type | Key constraints | Prod_id | Int | Primary key(not null) | Cat_id | Int | Foreign key(not null) | Product_name | Varchar(50) | not null | Product_description | Varchar (50) | null | Price | double | (not null) | Available | Int | (not null) | Add_date | Date | (not null) |

Admin Login table Column name | Data type | Key constraints | User_id | Int | Primary key(not null) | Pass_word | Varchar (20) | Not null |

Store table Column name | Data type | Key constraints | Order _id | Int | Primary key(not null) | Report | Varchar (20) | Not null |

Temp table Category name | Data type | Key constraints | Prod_id | Int | Primary key(not null) | Product_name | Varchar(50) | not null | Price | Double | not null | Items | Int | Not null | User_id | Int | Foreign key(not null) | Purchase_date | Date | (not null) | Order_no | Int | ( null) |

User table Category name | Data type | Key constraints | User_id | Int | Primary key(not null) | Password | Varchar(50) | not null | Sex | Varchar(50) | not null | Address | Varchar(50) | Not null | User_id | Int | not null) | Date_of_Birth | Date | not null) | Date of Registration | Varchar(50) | Not null) |

Feedback table Category name | Data type | Key constraints | User_id | Int | Primary key(not null) | Type | Varchar(50) | not null | Feedback | Varchar(50) | not null | Address | Varchar(50) | Not null | Comment | Int | null | feedback Date | Date | Not null |

Account table Category name | Data type | Key constraints | Bank_name | Int | not null | Account_no | Varchar(50) | not null | Password | Varchar(50) | not null | Balance | Double | Not null |

Sell table Category name | Data type | Key constraints | Prod_id | Int | Primary key(not null) | Product_name | Varchar(50) | not null | Price | Double | not null | Items | Int | Not null | User_id | Int | Not null | Purchase_Date | Date | Not null | Order_no | int | Not null |

CHAPTER 5
5.00 INPUT FORMATS AND OUTPUT LAYOUTS
5.10 Input Design
A process of converting user originated inputs to a computer-based format. Input design is an important part of development process since inaccurate input data are the most common cause of errors in data processing. Erroneous entries can be controlled by input design. It consists of developing specifications and procedures for entering data into a system and must be in simple format. The goal of input data design is to make data entry as easy, logical and free from errors as possible. In input data design, we design the source document that capture the data and then select the media used to enter them into the computer.
There are two major approaches for entering data in to the computer. They are
· Menus.
· Dialog Boxes.

5.20 Menus
A menu is a selection list that simplifies computer data access or entry. Instead of remembering what to enter, the user chooses from a list of options. A menu limits a user choice of response but reduce the chances for error in data entry.
5.30 Dialog Box
Dialog boxes are windows and these windows are mainly popup, which appear in response to certain conditions that occur when a program is run. It allows the display of bitmaps and pictures. It can have various controls like buttons, text boxes, list boxes and combo boxes. Using these controls we can make a ‘dialog’ with the program.
The system is divided into three modules: The Administrator, or customers

Administrator
He can login into the system with a valid username and password.
He can view registered customers, add confirm new users, edit customers or remove existing customers from the database.
He can manage all users.
He can back-up the database at any time.
He can track login by viewing the user logs, which reflect who logged in at what time, thus ensuring security to system.
Customer
He can login into the system using a valid username and password.
He can view the list of available customer, by searching by products.
He can view his own details
He can view the appointments that have been made to him by patients by searching through the database.
IMPORTANT CODE
Backup code
<?php
backup_tables('localhost','root','','onlinejmstore');

/* backup the db OR just a table */
$host='localhost';
$user='root';
$pass='';
$name='onlinejmstore';

function backup_tables($host,$user,$pass,$name,$tables = '*')
{

$link = mysql_connect($host,$user,$pass); mysql_select_db($name,$link); //get all of the tables if($tables == '*')
{
$tables = array();
$result = mysql_query("SHOW TABLES"); while($row = mysql_fetch_row($result))
{
$tables[] = $row[0];
}
} else {
$tables = is_array($tables) ? $tables : explode(',',$tables);
}
foreach($tables as $table)
{
$result = mysql_query("SELECT * FROM $table");
$num_fields = mysql_num_fields($result);

$row2 = mysql_fetch_row(mysql_query('SHOW CREATE TABLE '.$table));
$return.= "\n\n".$row2[1].";\n\n";

for ($i = 0; $i < $num_fields; $i++)
{
while($row = mysql_fetch_row($result))
{
$return.= 'INSERT INTO '.$table.' VALUES('; for($j=0; $j<$num_fields; $j++)
{
$row[$j] = addslashes($row[$j]); if (isset($row[$j])) { $return.= '"'.$row[$j].'"' ; } else { $return.= '""'; } if ($j<($num_fields-1)) { $return.= ','; }
}
$return.= ");\n";
}
}
$return.="\n\n\n";
}

//save file
$data=date("F j, Y, g-i a");
$handle = fopen('DB_backup/'.'db-backup-'.$data.'-'.$name.'.sql','w+'); fwrite($handle,$return); fclose($handle);
}
header("location:backupDB.php");

?>
Add supply
<link rel="stylesheet" href="../Date/jquery-ui.css"/> <script src="../Date/jquery1.js"></script> <script src="../Date/jquery2.js"></script>

<script> $(function() { $( "#datepicker" ).datepicker(); }); </script> <script type="text/javascript"> function validateForm()
{
var a=document.forms["addSup"]["description"].value; if (a==null || a=="") { alert("Description is empty!"); return false; } var b=document.forms["addSup"]["unit"].value; if (b==null || b=="") { alert("Unit is emplty!"); return false; } var c=document.forms["addSup"]["date"].value; if (c==null || c=="") { alert("Date is empty!"); return false; } var d=document.forms["addSup"]["qty"].value; if (d==null || d=="") { alert("Quantity is empty!"); return false; } var e=document.forms["addSup"]["unitcost"].value; if (e==null || e=="") { alert("Unit Cost is empty!"); return false; }
}
</script>
<SCRIPT language=Javascript> <!-- function isNumberKey(evt) { var charCode = (evt.which) ? evt.which : event.keyCode if (charCode > 31 && (charCode < 48 || charCode > 57)) return false;

return true; } //--> </SCRIPT>

<link rel="stylesheet" type="text/css" href="../CSS/general.css"/>
<link rel="stylesheet" type="text/css" href="../CSS/modalWindow.css"/>

<div class="modCon"> <center> <div class="modHeader"> <h3 class="modalHeader"> ADD STOCK </h3> </div> <form action="execAddSupply.php" method="post" enctype="multipart/form-data" name="addSup" onsubmit="return validateForm()"> <div class="modContent"> <div class="Row1"> <table border="0" width="482"> <tr> <td width="350"> Image </td> </tr> <tr> <td width="310"> <input class="modText" type="file" name="image" tabindex="1" value="" size="20" /> </td> <td> </td> </tr> <tr> <td width="350"> Description </td> <td width=""> Unit </td> </tr> <tr> <td width="310"> <input class="modText" type="text" tabindex="1" name="description" value="" size="33" /> </td> <td> <input class="modText" type="text" tabindex="1" name="unit" value="" size="11" /> </td> </tr> <tr> <td width="310"> </td> <td width=""> </td> </tr> <tr> <table border="0" width="482"> <tr> <td> Date Purchased </td> <td> Qty </td> <td> Unit Cost </td> </tr> <tr> <td> <input type="text" id="datepicker" class="modText" size="15" name="date1" readonly="readonly"/> </td> <td> <input class="modText" type="text" tabindex="1" name="qty" value="" size="9" onkeypress="return isNumberKey(event)" /> </td> <td> <input class="modText" type="text" tabindex="1" name="unitcost" value="" size="10" onkeypress="return isNumberKey(event)"/> </td> </tr> </table> <tr> </tr> <tr> <td height="75"> <input type="submit" name="submit" value="save" class="button" style="margin-top:10px; margin-left:4px;"/> </td> </tr> </table> </div> </div> </form> </center>
</div>

6.00 HUMAN MACHINE INTERFACES
6.10 New user registration interface

6.20 Admin login monitoring interface

6.30Admin interfaces
6.40 Available stock

6.50 Admin Backup interface

6.60 Sales report

6.70 Transaction receipt

CHAPTER 7
7.00 DETAILED DESIGN

CHAPTER 8
8.00 PROCESSING LOGIC
Buy product
Make payment
Write feedback
See delivery
Account
Feedback
Store
Product id
Prod_name
price quality User id
User name
Phone no address Email id sex Account number
Pin no
Receipt no feedback Comment
Feedback type

report
Receipt no
PRODUCT
Customer details

CHAPTER 9
9.00 SYSTEM INTEGRITY CONTROLS
9.10 System Integrity Controls
Since the store management system database will be hosted online, it will be imperative to implement integrity controls in order to make sure that the data is free from unauthorized alteration.
Integrity Controls used include: * Encrypted Passwords – The system will implement a cryptographic algorithm to encrypt user passwords (in the Admin web interface). This will ensure security and prevent unauthorized or malicious access to the system data.
Conclusion
This Design Specification Document is an outline of the detailed design structure of the online store management system. It has captured in depth all the design processes that will be used to implement the system in the next stage.

CHUKA | | UNIVERSITY |
DEPARTMENT OF COMPUTER SCIENCE

Bachelor of Science in Computer Science

COMP 402: Computer System Projects System Design Document NAME: MBUGUA, JOSEPH MUOHO

REG. No.: EB1/02400/10 Course Instructor: Mr. B. Osero Submission Date: April 16th, 2011