Online Book Store Management System Software engineering project report pdf

Software engineering project report pdf ,Online Book Store Management System,Software engineering project report pdf ,Online Book Store Management Sys

 

Study With Vishal

Department of Computer Engineering

 

SYCO-A

SEMESTER 4 [2021-2022]

(GROUP 1)

SUB: Software Engineering

 

                                                 VISHAL

                            APEKSHA

                                                  RAJNANDHINI

                            VAIBHAV

                             

Guided by:  Mr.Vishal Chavare  

 

  

Certificate

  

This is to certify the following group of students roll no. 54-59 of 4th semester of diploma in COMPUTER ENGINEERING of institute, Vishal chavare . (Code:0 2) has completed the Micro Project satisfactorily in subject-SEN (22413) for the academic year 2019-2020 as prescribed in the curriculum.

 

Place: __________                                                      Enrolment No.: _________

Date: ___________                                                     Seat No.: ______________

 

 

 

Subject Teacher                     Head of the Department                            Principal


  

 


ACKNOWLEDGEMENT

 

We would like to express our special thanks of gratitude to our institute Thakur Polytechnic and our Principal Dr. S.M Ganechari, our subject teacher and head of the Department Ms.Vaishali Rane who gave us the opportunity to make this micro project on the topic to develop software based on matrimonial portal. This has greatly helped us in expanding my cohere of knowledge. We are thankful to each other because every one of us aided to complete this project within the limited time frame.

 

 PROPOSAL

 

Name of Micro-Project: - Online Book Store Management System

 

       1.0 Aim of the Micro-project

               To develop software based on Online Book Store Management   

               System.

      2.0 Course Outcomes addressed

              1. Select suitable Software Process model for software development.

              2. Prepare software requirement specifications.

              3. Use Software modelling to create data designs.

              4. Estimate size and cost of software product.

              5. Apply project management and quality assurance principles in      

                  software development.

  

    3.0 Proposed Methodology

            1. Writing of problem statement and scope of the project.

            2. Choosing Appropriate software model.

            3. Requirement Gathering.

            4. Preparing Software Requirement Specifications(SRS) for the project.

            5. Preparing Use case diagram, Data flow diagram and Timeline chart

                for the project.

 

Sr.

No

Details of

Activity

Planned

Start

Date

Planned

Finish Date

Name of

responsible

team member

1.

 

Proposal of Micro project

 

16/12/2019

 

24/12/2019

 

VISHAL

2.

 

Problem Statement

 

07/01/2020

 

25/01/2020

 

APEKSHA

3.

 

Software

Requirement

Specification

(SRS)

06/02/2020

 

20/02/2020

VAIBHAV

4.

 

Use case diagram

 

24/02/2020

29/02/2020

VISHAL

5.

 

Data flow diagram

 

02/03/2020

10/03/2020

VISHA,VAIBHAV

6.

 

Timeline chart

 

12/03/2020

19/03/2020

APEKSHA

7.

 

Micro project Report

 

19/03/2020

23/03/2020RAJNDHINI

             

5.0 Resources Required

 

Sr.

No

Name of Resource/material

 

Specification

 

Quantity

 

 

1.

 

 

Personal Computer

 

Any

configuration

with support of

4GB RAM

 

1

 

2.

 

 

Microsoft Word

 

Office 365

 

 

1

 

 

3.

 

 

Internet

 

Minimum 32 Mbps

 

 

1

 

 

4.

 

 

Operating System

 

Microsoft

Windows or any other higher

 

1

 

Name of Team Members

 

 

Sr. No                Name                      Roll No

   

   1.                 VISHAL                          54

 

   2.                 APEKSHA                   55

 

   3.                 RAJNDHINI                   56

 

   4.                 VAIBHAV                       57

 

 

 

 

   Signature

VISHAL CHAVARE

 

  

REPORT

 

Report

 

1.0 Rationale

 

Software Engineering is the foundation for professional processes to be followed involving principles, techniques and practices for software development. The course provides a framework for software professionals for building quality assured software products. It enables students to blend the domain specific knowledge with the programming skills to create quality software products.

 

 

2.0  Aims/Benefits of the Micro-Project

 

           Aim: -

         To develop software based on online book store management system.

 

          Benefits: -

        In this project, we have learnt about software development by choosing appropriate

          software process model. We also learnt how to use software modelling to create software

          designs. We also understood the purpose and objective of this Micro-Project. This project

          aims at creating a full-fledged website for matrimony.

 

 

 

3.0 Course Outcomes Achieved

      

1.     Select suitable Software Process model for software development.

2.     Prepare software requirement specifications.

3.     Use Software modelling to create data designs.

4.     Estimate size and cost of software project.

5.     Apply project management and quality assurance principles in software development.

 

4.0 Literature Review

 

Problem Statement:

 

Almost every activity in the world today is controlled by computer driven software programs. His trend was first accommodated by engineering applications in the past. However, as the lifestyle became more and more complex, every area of human interactions was invaded by various software systems, such as real time, business, simulation, embedded, web based, personal and more recently, artificial intelligence software etc.

According to the above facts, managing and maintaining a book shop could also be controlled by efficient software. This project focuses attention on designing efficient and reliable software which controls the transactions of a bookshop.

In real world, it tends to associate with automated systems as they provide many benefits than doing the same thing in manually. As above mentioned, here we have introduced a system which can be used to maintain a bookshop.

When we are concerning the manual process of a bookshop, the major problem is the waste of time. A customer has to waste his/her valuable time when he needs to buy a book as all the events such as searching, purchasing are done by members of the staff .In briefly, the manual process is very slow. But automation will reduce the time taken in the whole process.

In a bookshop we should deal with a large store. Then person (storekeeper) has to maintain it with documents which are recorded by him. Therefore, there may be defective reports. Also company has to appointed more persons to complete the maintenance of the stationery. Then the company has to have an additional cost.

As we familiar with this type of system at instance we will be able to have the results that we want. Communication with suppliers, customers and other related organizations will be more successful as the system is so fast.

When the bookshop issues an item to a customer, all the stages of the transaction procedure will be facilitated by the system & it will be more accurate.

Scope

Book Store Management System is the web application to automate all kinds of operations in the book shop. The purpose of this software is to manage the books in the book store. Generally, it includes the Order Processing, Stock Management and Accounts Management. We developed this software to maintains records of sales, purchase and staff records. This project developed using ASP.NET as front end and SQL Server as Back end. Here we are try to develop such type system which is provide the automation on the any type of the bookshop. That means a shop which has the type system which provides the facility to the customers of the shop to purchase the books from the shop without any complexity.

This Book Shop Management System is used to overcome the entire problem which they are facing currently, and making manual system to computerized system. -
Purposed Book shop management system should help the customers query whether a book in a stock the user can query the availability of a book either by using the book title or by using the name of author. The objective and scope of this Project Book Shop Management System is to record the details various activities of user. It simplifies the task and reduce the paper work. Book store management system should generate sales statistics (book name, publisher, ISBN number, number of copies sold and the sales revenue) for any period.

At present, the Wholesale and Retail outlets are working under manual management. The client uses MS Excel, All records related to Products, Sales, Suppliers, Orders, Payment are stored in excel files. there is lot of duplicate work, and chance of mistake. When the records are changed, they need to update each and every excel file. In case of Customer records, all information related to customers and the product which the customer has purchased is to be stored in the Customers excel files. If the changes in the customer profile (like Phone no. , Address) occur, excel file must be updated.
To manage the whole data, the person maintaining records has to take great pain. Various excel files has to be maintained for each separate process. There is no option to find previous saved records. There is no security; anybody can access any report and sensitive data.
This software can be easily implemented under various situations. Any education institute can make use of it for providing information about author, content of the available books in their library. Modifications can be easily done according to requirements and when necessary. It can be used in any type of Book Shop for managing all the sales and purchased activities and managing the data records related to Book house
.

Software Requirement Specification(SRS)

A software requirement specification(SRS) is a complete description of the behaviour of the system to be developed. It includes a set of use cases describes all of the interactions that the users will have with the software.

SRS for online book store management system:

  

 

Software Requirement Specification for Matrimonial Portal

Version 1.0

                             Prepared by

                                              

     VISHAL

   APEKSHA

    RAJNANDHINI

   VAIBHAV

 

 

Instructor: VISHAL CHAVARE  

Course: Computer Engineering

Lab section: Computer Lab 2

Teaching assistant: VISHAL CHAVARE  

Date: 30/5/2022

 

Table of Contents

1. Introduction……………………………………………………..5

1.1  Purpose ………………………………………………………….5

1.2  Scope…………………………………………………………….5

1.3  Definitions , acronyms , and abbreviations……………………...5

1.4  Organization……………………………………………………..5

 

2. Overall Description………………………………………………6

2.1 Product Perspective……………………………………………….6

2.2 Product Functions…………………………………………………6

2.3 User Characteristics……………………………………………….6

2.4 Constraints…………………………………………………………6

2.5 Assumptions and Dependencies……………………………………6

2.6 Approportioning of Requirements………………………………….6

3. Specific Requirements……………………………………………..7

3.1 Restrictions…………………………………………………………7

3.2 Data Structure……………………………………………………….7

3.3 System……………………………………………………………….7

      3.3.1 Browse Inventory………………………………………………...7

      3.3.2 Search Inventory…………………………………………………7

      3.3.3 Create, Update and Destroy (CRUD) Functionality……………..7

      3.3.4 Shopping Cart……………………………………………………7

      3.3.5 Checkout Procedure…………………………………………….7

      3.3.6 Authentication System………………………………………….7

      3.3.7 Promotions………………………………………………………7

      3.3.8 Automated Reorder……………………………………………...7

      3.3.9 Order Logging…………………………………………………...7

 

  3.4 External Interface Requirements…………………………………...7

        3.4.1 Hardware Interface Requirement……………………………7

        3.4.2 Software Interface Requirement…………………………….7

     

  4. Functional Requirements…………………………………………8

  

  5. Non-Functional Requirements……………………………………8   

 

 

1 Introduction

The Software Requirements Specification is designed to document and describe the agreement between the customer and the developer regarding the specification of the software product requested [5]. Its primary purpose is to provide a clear and descriptive “statement of user requirements” [5] that can be used as a reference in further development of the software system. This document is broken into a number of sections used to logically separate the software requirements into easily referenced parts.

This Software Requirements Specification aims to describe the Functionality, External Interfaces, Attributes and Design Constraints [4] imposed on Implementation of the software system described throughout the rest of the document. Throughout the description of the software system, the language and terminology used should unambiguous and consistent throughout the document.

1.1 Purpose

Defining and describing the functions and specifications of the Book E-Commerce

System (BECS) is the primary goal of this Software Requirements Specification (SRS).

This Software Requirements Specification illustrates, in clear terms, the system’s primary

uses and required functionality as specified by our customer.

The intended audience of this document is our primary Book E-Commerce System

customer: Mr. Borzoo Bonakdarpour, the CSE435 instructor Dr. Betty Cheng, the fall semester 2007 CSE435 Group 4 members, as well as the other students attending CSE435 that will require access to such documentation.

1.2 Scope

The software system being produced is called Book E-Commerce System or BECS. It is being produced for a customer interested in selling books via the Internet. This system is designed to “provide automation support” [2] for the process of placing books for sale on the Internet and facilitating the actual sale. This system is largely cross-platform and is available to anyone using the Computer Science Department’s provided computer resources in the MSU Engineering Building. The system will be run on a central server with each user having a remote user interface through a web browser to interact with it. The Book E-Commerce System will allow any user to create an account to become a customer. The customer, through the process of account creation, will have the option to become a member of the site. The system will allow customers to browse, search, select, and add books to a shopping cart. Then, provided they have books in their shopping cart, check out books in shopping cart and decrement the stock that the inventory the system maintains. The BECS also allows a manager to manage the inventory with full create, retrieve, update and delete (CRUD) functionality with regards to books in the system. It will also allow, on an inventory wide basis, customers and managers to interact with a promotion system that handles percentage-off promotions that can be applied to member’s orders. This interaction includes the creation (by managers) and the application to orders (by customers) of the promotions. The BECS has full email capabilities; the automated email functionality will be used to send promotions to members of the system as well as provide the managers with low-stock notifications. The BECS will have numerous constraints on what it can do. The system will not have full credit-card processing capabilities. It will not allow managers to be customers. The manager will be a hard-coded user and only a single manager will exist. There will be no actual book ordering and order completion, however the system will provide the customer with a receipt and it will log the transaction details. The system will not allow multiple promotions to be added to a single shopping cart nor will it allow a customer to add more than one of each item to their cart. The system also will not allow users to retrieve passwords or edit their user details.

 

 

1.3 Definitions , acronyms , and abbreviations

BECS

Book E-Commerce System.

Barcode

A unique identifier assigned to single items.

Book

An instance of an item that has these additional attributes: Title, Author.

Button

A user interface element that allows a User to click and inform the system to take an action.

Checkbox

A user interface element that allows a User to inform the system that he/she selected a particular item.

Checkout

The process a Customer goes through to purchase an item.

CRUD

Create, Retrieve, Update, Delete.

Customer   

A person that is user of the system but has created an account.

Inventory

An object that holds items available for purchase by the customer.

Item

An individual entity in the inventory which has several descriptive attributes: Barcode, Price, Reorder Threshold, Stock

Manager

A single person that has the ability to create, retrieve, update and delete items in the store. This person cannot simultaneously act as a Customer and Manager.

Member

A person that is a customer of the system and has requested to be sent promotions.

Promotion

An item-wide percentage-off price discount applied to a Member’s shopping cart.

Reorder

The system process that automatically orders new stock of an item.

Reorder Threshold

The numeric value of an item’s stock that must be reached before the system will order additional quantities of the item.

Session

The time which a User is actively using the system.

Shopping Cart

An object that lists a Customer’s selected Items, their applied promotions and gives them an option to check out.

SRS

Software Requirements Specification.

Stock

The quantity of any particular item the inventory has on hand.

Text Box

A user interface element that allows a User to input text to the system.

Transaction

The information related to a customer’s purchase that is logged.

User

The person who operate the software product.

 

1.4 Organization

This Software Requirements Specification document is divided in to multiple subsections. The first section includes explanations of the Purpose, Scope and Organization of the document. The first section also handles the description of project specific words, acronyms and abbreviations that will be used in the document.

The second section of the document is separated into the following five different sections, each detailing specific details of system uses and their corresponding actions: Product Perspective, Product Functions, User Characteristics, Constraints, Assumptions and Dependencies, Apportioning of Requirements. The third section is an enumerated listing of all of the requirements described for this system. The fourth section encompasses all of the Use-case, Sequence, State and Class diagrams that model the system. In the fifth section there exists a Prototype of the system along with a sample scenario that graphically describes the use of the system. The sixth section contains a listing of all related reference materials used in this document. The seventh and final subsection is dedicated to providing a point of contact for any viewer of this document.

2 Overall Description

This section includes details about what is and is not expected of the BECS system in addition to which cases are intentionally unsupported and assumptions that will be used in the creation of the BECS system.

2.1 Product Perspective

BECS is an online bookstore website which supports a number of functions for both the consumer and store's management. The website must be available to anyone using the Computer Science Department’s provided computer resources in the MSU Engineering Building and as such must work correctly in both Internet Explorer and Mozilla Firefox. As stated by the customer, there are no hardware or software requirements beyond these including, but not limited to, memory or specific software packages that need to be utilized nor software packages that need not be utilized.

2.2 Product Functions

BECS will provide a number of functions; each is listed below.

• Maintain data associated with the inventory (a collection of books)

• A book has a title, author and price

• The inventory also keep track of the stock/quantity of each book

• Maintain records for many customers

• A customer can be either a member or non-member.

• A customer has a username (unique across all users), password (no restrictions), email address (no restrictions), and postal address (unverified.)

• Anyone may sign up for a customer account.

• Allow any customer to become a member.

• Show a listing of available books

• Books are to be displayed in ascending alphabetical order by title.

• Each book will list the following from left to right

• Title

• Author

• Price

• Allow customers and managers to log in and out of the system.

• Users (both customers and the manager) will be logged out if inactive for 30 minutes.

• Shopping cart

• Anyone is able to add one or more books to the shopping cart.

• The shopping cart does not need to allow multiple copies of any book.

• Checkout

• Checkout is only available to logged-in customers. A user that is not logged in as a customer is given a chance to log in.

• Member customers may enter a promotion code.

• Only one promotion code may be used per purchase

• The promotion is a fixed percentage discount that is to be applied to an entire order.

• The discount is specified by the manager at the time of the promotion’s creation or most recent update/edit.

• Collect a 16-digit credit card number from the customer

• Log/record the transaction

• Allow manager to specify a stop-order for a book

• Each book has its own stop-order status – either on or off. Details of its use are involved in the following feature.

• Notify manager when books need to be reordered

• When the quantity a book falls below a threshold, the manager is notified that the book needs to be reordered.

• One exception is if the manager has already specified a stop-order for this book.

• Every book must either have stop-order enabled or disabled

• Allow manager to update stock quantities

• Allow manager to change any book's price

• Allow manager to view transaction logs

• Allow manager to create promotions

• A promotion is a percentage discount that can be applied to an entire order

• Promotions may only be used by member customers

• A promotion has an expiration date specified by the manager

When a promotion is created, it is emailed to all member customers via the email address on record

2.3       User Characteristics

The typical BECS user is simply anyone that has access to the Internet and a web browser in the computer science department at Michigan State University. It is assumed that the user is familiar enough with a computer to operate the browser, keyboard and mouse and is capable of browsing to, from and within simple websites.

2.4      Constraints

As stated by the customer, security is not a concern for this system. The database may store passwords in plain text and there doesn't need to be a password recovery feature nor lockout after numerous invalid login attempts. As such, the system may not work correctly in cases when security is a concern. These cases include those listed above in addition to lack of an encrypted connection when sending credit card information and forcing users to use “strong” passwords. A strong password is a password that meets a number of conditions that are set in place so that user's passwords cannot be easily guessed by an attacker. Generally, these rules include ensuring that the password contains a sufficient number of characters and contains not only lowercase letters but also capitals, numbers, and in some cases, symbols.

 

The system may not behave correctly when used with Internet browsers other than Firefox and Internet Explorer.

 

 

 

 

SCR

"Software Cost Reduction (SCR) is a set of techniques for designing software systems developed by David Parnas and researchers from the U.S. Naval Research Laboratory beginning in the late 1970s." [7]

Mode Class

"A mode class is a finite state machine, with states called system modes" [8]

System State

The current state or mode that the system is in. The system must be in exactly one state at any moment in time.

Event

An event is any action that can trigger an action within the software system. Examples include but are not limited to changing values of variables or user-triggered events.

Event Notation

We may need to refer to both the old and new value of a

 

variable: 

Used primed values to denote values after the event 

@T(c) ≡ ¬c ^ c’ e.g. @T(y=1) ≡ y<>1 ^ y’=1 

@F(c) ≡ c ^ ¬c’ 

A conditioned event is an event with a predicate 

@T(c) WHEN d ≡ ¬c ^ c’ ^ d [8]

Controlled Variable

A variable whose value can change throughout the lifetime of the system and whose value is critical and must be maintained correctly.

Mode Transition

When the mode (state) changes from one mode (described as the old mode) to a new mode.

Mode Class Table

Table consisting of a list of modes that the system can be in, modes that can be transitioned to, and the conditions required for the transition to occur. The table if formatted such that the first column lists the current mode (old mode) and the last column lists the new mode. The columns between the first and last columns each describe a specific event.

Event Table

 

An event table illustrates how an input event can affect a controlled variable. The first column shows modes and the

 

 

 

last row shows the values that the controlled variable will be set to. The remaining cells are conditions required for a mode to affect the value of a controlled variable.

 

Condition Table

A condition table shows the conditions (one of which must be met) in order for a controlled variable to be set to some specified value. The first column lists modes and the last row names the controlled variable and the values it is set to.

 

Condition Table                            

Mode                                 Conditions

AddPromotion      TRUE     FALSE PromotionAdded TRUE    FALSE

 

Mode Class                                                                                                             

Old Mode

Login

IsManager

IsCustomer

Logout

New Mode

UserLoggedOut

@T

t

-

-

ManagerLoggedIn

 

@T

-

t

-

CustomerLoggedIn

ManagerLoggedIn

-

-

-

@T

UserLoggedOut

CustomerLoggedIn

-

-

-

@T

UserLoggedOut

 

Event Table                

 

@T(User::Login() == UserLoggingIn      TRUE)

never

UserLoggingOut         never

@T(Logout() ==

TRUE)

User::LoggedIn TRUE  

FALSE

Condition Table         

 

Mode                             Conditions

 

UserLoggedOut                                     FALSE

TRUE

ManagerLoggedIn                                TRUE

FALSE

CustomerLoggedIn                              TRUE

FALSE

UserLoggedIn                                      TRUE

FALSE

 

2.5        Assumptions and Dependencies

Client:

We have assumed that all of the computer systems in the Engineering building labs are in proper working condition and that the user is capable of operating these system's basic functions including but not limited to being able to power on the system, login and open either Internet Explorer or Mozilla Firefox, and navigate the browser to the address of this BECS website. 

Provider:

We have assumed that the BECS will be running on a properly working web server and database system with an Internet connection that allows this system to perform all communications with clients. 

 

Assumptions:

      There is no need for anyone to be able to order more than a single copy of a book (or any item) in a single transaction.

      The manager account’s username and password maybe hard coded.

      The manager cannot be a customer.

      Any user cannot edit their account information.

 

2.6       Approportioning of Requirements

As stated by the customer, security is not a concern of this project. As such, it is beyond the scope of this system to encrypt personal user data, encrypt credit card information, prevent unauthorized login attempts, or any other concern of this nature. Additionally, the system is not responsible for the following:

 

      Verifying that credit card information is valid

      Verifying the email address provided by a user

      Storing additional information about a book beyond simply the title, name of author, and price

      Allowing users to edit their account details (username, password, mailing address, etc)

      Allowing customers to order multiple copies of a book in a single order

      Providing individual product pages (one page for every item in the inventory)

      Allowing the manager to update login credentials or other information about the manager

 

Additionally, the system may need to later be extended to provide additional functions. One such example is added support for visually impaired users. In many cases a screen reading program is used and ensuring that page-layout reads from top-left to bottom-right in a logical manner would be required.

 

3 Specific Requirements 

1.     Restrictions

1.1.User Side

1.1.1.       Software

1.1.1.1.            Internet Explorer or Mozilla Firefox

1.1.2.       Hardware

1.1.2.1.            Computer Science Department Laboratory Terminal

1.2.System Side

1.2.1.       Software

1.2.1.1.            Web-based application

1.2.1.2.            Database information storage system

 

 

 

2.     Data Structure

2.1.Book has these attributes

2.1.1.       Unique ID (auto-increment starting at 1)

2.1.2.       Title

2.1.3.       Author

2.1.4.       Price

2.1.5.       Reorder Threshold

2.1.6.       Stop-order Boolean value

2.1.7.       Stock

 

2.2.Customer has these attributes

2.2.1.       Unique Username

2.2.2.       Password

2.2.3.       Name

2.2.4.       Email Address

2.2.5.       Postal Address

2.2.6.       Member/Not Member Boolean value

2.3.Manager has these attributes

2.3.1.       Username

2.3.2.       Password

2.3.3.       Email address

2.4.Order log entries have these attributes: 

2.4.1.       Unique ID (auto generated)

2.4.2.       Time transaction took place

2.4.3.       Date transaction took place

2.4.4.       Username of customer

2.4.5.       Listing of the contents in customer’s shopping cart

3.     System    

3.1.Browse Inventory

3.1.1.       Organization

3.1.1.1.            Items Listed on single page

3.1.1.2.            Items shown in tabular format

3.1.1.3.            Each Item listing contains

3.1.1.3.1.                  Title

3.1.1.3.2.                  Name of Author

3.1.1.3.3.                  Price

3.1.1.4.            Listing sorted by Ascending item Title

3.1.1.5.            No individual Item pages

3.1.2.       Interaction

3.1.2.1.            Each Item has checkbox to mark selection

3.1.2.2.            Single button to add all selected items to Shopping Cart

3.2.Search Inventory

3.2.1.       Search available only by Title of book

3.2.2.       Search is exact-match only

3.3.Create, Update and Destroy (CRUD) Functionality 3.3.1. Only managers are allowed to modify inventory

3.3.2. Managers have an interface to:

3.3.1.1.            Create a book entry

3.3.1.2.            Update a book entry

3.3.1.3.            Update the stock/quantity of a particular book

3.3.1.4.            Create a new promotion

3.3.1.5.            Review current inventory

3.3.1.5.1.                  Using the same interface to browse inventory as described in section 3.1, the manager has an additional “Edit Item” option for each book.

3.3.2.5.1.1. Manager has full CRUD capabilities on each book.

3.3.3. Managers may delete items from the inventory

 

 

 

 

3.4.Shopping Cart

3.4.1.       Logged In

3.4.1.1.            Can add items to cart

3.4.1.1.1.                  If Item is not in stock, message displayed informing user to try again later

3.4.1.1.2.                  Customer can only purchase one of each item (no quantities associated with orders)

                       3.4.1.1.3.           

3.4.1.2.            If shopping cart not empty, a user may begin Checkout procedure

3.4.2.       Not Logged In

3.4.2.1.            Can add items to cart

3.4.2.2.            User required to login before they may begin Checkout procedure

3.5.Checkout procedure

3.5.1.       User must successfully use shopping cart before beginning this procedure

3.5.2.       Checkout page consists of 

3.5.2.1.            A text box for promotion entering

3.5.2.2.            An overview of the purchase 

3.5.2.3.            A text box to hold the credit card number

3.5.2.4.            A button to complete the order

3.5.3.       Order details sent via email after the checkout has completed 

3.5.4.       On order completion the inventory is decremented based on items purchased by user

3.6.Authentication System

3.6.1.       User Levels

3.6.1.1.            Manager (single, hardcoded user, no orders)

3.6.1.2.            Customer (unlimited, open creation, unlimited orders)

3.6.2.       Account Creation

3.6.2.1.            Everyone is allowed to create an account

3.6.2.2.            Required Information

3.6.2.2.1.                  Listed in section 2.2

3.6.3.       Account Modification

3.6.3.1.            Users are not able to modify any aspect of their account after creation

(“it would be nice but not needed”)

3.6.4.       Login and Logout

3.6.4.1.            There is no lost-password recovery

3.6.4.2.            Logging in allows one to logout

3.6.4.3.            Logging in allows checkout

3.6.4.4.            There is a 30-minute session time out after which a logged in user will be logged out automatically.

3.7.Promotions

3.7.1.       Specifications

3.7.1.1.            Applies to entire order

3.7.1.2.            Percentage-off type promotion (x% off entire order)

3.7.1.3.            Expiration occurs at manager specified date

3.7.1.4.            Multiple coupons cannot be applied to same order

3.7.1.5.            Non-member users cannot apply promotions to order

3.7.2.       Creation

3.7.2.1.            Promotion created by manager

3.7.2.2.            Each promotion has a unique identifying number (can be auto generated)

3.7.2.3.            Email containing promotion sent to all member users of the BECS system

                  3.7.2.4.        

3.7.3.       Deletion

3.7.3.1.            Promotions are auto-deleted when the expiration date has passed

 

 

 

3.8.Automated Reorder

3.8.1.       Specifications

3.8.1.1.            Manager sets reorder threshold on a per-item basis

3.8.1.2.            If item reaches the reorder threshold, an email is sent informing the manager of the item’s status and the system automatically reorders the item

3.8.1.2.1.                  If the item has a stop-order applied to it, it will not automatically reorder until the manager removes it.

3.8.1.3.            A manager may increase the stock of an item using the manager’s account

3.9.Order Logging

3.9.1.       Specifications

3.9.1.1.            Required Information:

3.9.1.1.1.                  Listed in section 2.4

3.9.1.2.            A manager can view all past transactions from all users

Order log entries are generated when a user successfully checks out their shopping cart

 

3.2 Hardware Requirements

§  RAM: Minimum 1GB or higher.

§  HDD: Minimum 50 GB.

§  Processor: Intel Pentium 4 or AMD.

§  LAN: Version 1.6.6.406(For fixing up client disconnection).

3.3 Software Requirements

§  Operating System: Windows (XP, 7, 8, 8.1) or Mac OSX (Tiger, Leopard, Snow      

                                                     Leopard, Lion, Yosemite).

§  Web Browser: Google Chrome, Internet Explorer (ver. 8 or later), Mozilla     

                          Firefox, Safari (Mac).

§  Database Management System: MySQL, SQL Server, Microsoft Access,  

                                                        Oracle.

§  Web Development System: Visual Studio 2010 or later, Adobe Dreamweaver,  

                                                                  Notepad,  and Notepad++.

§  Others: .NET FRAMEWORK.

 

4.     Functional Requirements

     · The system supports customers booking and able to modify them

      · Customers can search based on hotel, apartment, inns (ex. Radisson, Singapore)

      · When a customer search for hotels, apartment, and the search result must contain hotel

          or apartment information (Address, Ratings, and Price) and also its availability within

          choosing check in and check out date.

     · Customers able to cancel their booking from their account.

     · Staffs able to edit customers booking information (updating check in, check out, room

        preferences, bed preferences and also cancelling booking).

     · Customers can book online and pay with credit or debit card.

     · The system must send booking confirmation email after successful payment.

     · Customers can write reviews about hotels and apartment and also rate them.

     · Customers able to check their booking status from their individual account.

     · Customers can send feedback or call the company for booking purposes.

     · Customers can check for latest promotion or deal.

5.     Non-Functional Requirements

· The system must ensure that all the transferable data as for examples customers credit 

   or debit card number, CVV Code, e-payment should be done in secured connection.

· The system must be able to handle multiple transactions a time.

· The system must provide customers 24*7 hours online booking service.

· The system should support almost all the browsers (Internet Explorer, Safari, Chrome,

   and Firefox).

· The system should be able to convert the price from Malaysian to USD and SGD.

· System should send the newsletter about ongoing promotions or deal to registered

   customers.

 

· Customers need to cancel the booking before 24 hrs. otherwise their credit card will be

   charged for one day.

· In promotion time the system will charge credit card promptly.

 

Use case diagram

     Use case is a term used in system analysis to determine, clarify and integrate all system

      requirements.

      It describes how user interacts with the software to achieve certain goals. It also describes

      various business activities carried out by the system.

      Use cases consists of 4 basic elements as boundary, actor, use cases and relationships.

      Use case diagram for online book store management system:

      

 

 

 

 

 

 

Actors

Shown in the diagram as stick figures with a name

underneath. They represent elements that will be directly

interacting with the system.

Use Cases

Oval shapes that have their names in the center. These

represent direct functionality within the system that must

be implemented.

Interactions

Lines that connect the actors with the different Use Cases.

These show that there is some form of direct interaction

between the actor and that specific functionality.

Includes

Dotted lines labeled “<<include>>” that connect two use

cases and have an arrow pointing towards one. This

means that the use case without the arrow calls on the

functionality of the use case with the arrow.

Extends

Dotted lines labeled “<<extend>>” that connect two use

cases and have an arrow pointing towards one. This

means that the use case without the arrow takes all of the

functionality of the use case with the arrow and adds extra

functionality.

The System Boundary

The large rectangle that contains the Use Cases.

Everything within the rectangle is what the system is

responsible for implementing

Use Case Template

Describes the basic functionality and features of each use

case and the can be found in the pages following the use

case diagram.

Type

A field in the use case template that states whether or not

the use case is directly interacted with by an actor

(Primary) or not (Secondary) as well as whether or not it is

essential to having a functioning system.

Cross Ref

A field in the use case templates that states which one of

the original requirements that particular use case satisfies.

Use-Cases

A field in the use case templates that state which other use

cases must be executed prior to that particular use case.

 

Data flow diagram

Data Flow Diagrams show the flow of data from external entities into the system, and

from one process to another within the system. There are four symbols for drawing a

DFD:

1. Rectangles representing external entities, which are sources or destinations of data.

2. Ellipses representing processes, which take data as input, validate and process it

and output it.

3. Arrows representing the data flows, which can either, be electronic data or physical

items.

4. Open-ended rectangles or a Disk symbol representing data stores, including

electronic stores such as databases or XML files and physical stores such as filing

cabinets or stacks of paper.

 

 

 

 

Figures below are the Data Flow Diagrams for the current system. Each

process within the system is first shown as a Context Level DFD and later as a

Detailed DFD. The Context Level DFD provides a conceptual view of the process and

its surrounding input, output and data stores. The Detailed DFD provides a more

detailed and comprehensive view of the interaction among the sub-processes within

the system.


 

 

 

Timeline chart

Timeline charts illustrate events, in chronological or sequential order — for example the progress of a project, advertising campaign, acquisition process — in whatever unit of time the data was recorded — for example week, month, year, quarter.

 

Timelines are extremely important in project management because they help to visualize time-related metrics, synchronize tasks, set deadlines and define potential delays.

 

 

5.0 Actual Methodology Followed

 

 

1. Writing of problem statement and scope of the project.

2. Choosing Appropriate software model.

3. Requirement Gathering.

4. Preparing Software Requirement Specifications(SRS) for the project.

5. Preparing Use case diagram, Data flow diagram and Timeline chart for the 

    project.

 

6.0 Actual Resources Used

 

Sr.

No

Name of Resource/material

 

Specification

 

Quantity

 

 

1.

 

 

Personal Computer

 

Any

configuration

with support of

4GB RAM

 

1

 

2.

 

 

Microsoft Word

 

Office 365

 

 

1

 

 

3.

 

 

Internet

 

Minimum 32 Mbps

 

 

1

 

 

4.

 

 

Operating System

 

Microsoft

Windows or any other higher

 

1

 

 

 

7.0 Skills Developed/Learning outcome of this Micro-project

 

We learnt how to write problem statement and scope of a project. We also learnt how to prepare a SRS, Use case diagram, Data flow diagram and timeline chart for a particular project. Hence we understood how to develop a software based on a given topic i.e. Matrimonial portal.

 

 

8.0 Applications of this Micro-project

 

With the help of this micro-project we learnt how to develop a software based on online book store management system.

 

 

 

 


 

 

Roll Number of the Team Members

 

Name of the Team Members

 

54

VISHAL

55

APEKSHA

56

RAJNADHINI

57

VAIBHAV

 

 

 

 

 

 

 

 

                                                                                              

 Mr.VISHAL CHAVARE

_________________




 


I am Vishal Chavare , I'm a coder, animater. I'm extremely fond of anything related to education, animation & coding. I aim to reach my creative goals one step at a time I believe everyth…

Post a Comment

© MSBTE CO/IT STUDY MATERIAL. All rights reserved. DMCA.com Protection Status

Msbte 👉👉 Website

please chat with our team Admin will reply in a few minutes
Hello, Is there anything we can help you with? ...
Join group...