Template-05 - Project Report (Part-1) 123

SUPERIOR UNIVERSITY LAHORE
Faculty of Computer Science & IT
Final Year Project

PROJECT REPORT (Part-1)
[Store Management System]
Project ID: [write ID here Issued by FYP Manager]
Project Team
Student Name Student ID Program Contact Number Email Address
M Faisal MitM-s19-012 MIT 03244368810 Mitm-s19-12@superior.edu.pk
Muhammad Akram MitM-s19-004 MIT 03484226503 Mitm-s19-12@superior.edu.pk
Muhammad Waqas MitM-s19-003 MIT 03350488672 Mitm-s19-12@superior.edu.pk
[Mam Fatima Riaz]

([Lecturer])
< Store Management System >
Project Report
[Store Management System]
Change Record
Author(s) Version Date Notes Supervisor’s Signature
1.0 <Original Draft>
<Changes Based on
Feedback from
Supervisor>
<Changes Based on
Feedback From Faculty>
<Added Project Plan>
<Changes Based on
Feedback from
Supervisor>
Faculty of CS&IT, Superior University Lahore, Pakistan 2

APPROVAL
PROJECT SUPERVISOR
Comments: ___________________________________________________________________
_____________________________________________________________________________
Name:______________________________
Date:_______________________________ Signature:__________________________
PROJECT MANAGER
Comments: ___________________________________________________________________
_____________________________________________________________________________
Date:_______________________________ Signature:__________________________
HEAD OF THE DEPARTMENT

Comments: ___________________________________________________________________
_____________________________________________________________________________
Date:_______________________________ Signature:__________________________

Dedication
This work is dedicated to my Mam Fatima Lecturer in

Superior university in Gold campus.

Acknowledgements
I am really thankful to my supervisor who has fully supported me in my all work and delivered me all
content already that support to understand work.

Executive Summary
Table of Contents
Dedication.......................................................................................................................................iv
Acknowledgements..........................................................................................................................v
Executive Summary.........................................................................................................................vi
Table of Contents...........................................................................................................................vii
List of Figures..................................................................................................................................ix
List of Tables.....................................................................................................................................x
Chapter 1.........................................................................................................................................1
Introduction.....................................................................................................................................1
1.1. Background.......................................................................................................................2
1.2. Motivations and Challenges..............................................................................................2
1.3. Goals and Objectives.........................................................................................................3
1.4. Literature Review/Existing Solutions.................................................................................3
1.5. Gap Analysis......................................................................................................................3
1.6. Proposed Solution.............................................................................................................5
1.7. Project Plan.......................................................................................................................5
1.7.1. Work Breakdown Structure...........................................................................................5
1.7.2. Roles & Responsibility Matrix........................................................................................6
1.7.3. Gantt Chart....................................................................................................................6
1.8. Report Outline...................................................................................................................7
Chapter 2.........................................................................................................................................8
Software Requirement Specifications..............................................................................................9
2.1. Introduction......................................................................................................................9
2.1.1. Purpose..........................................................................................................................9
2.1.2. Document Conventions.................................................................................................9
2.1.3. Intended Audience and Reading Suggestions...............................................................9
2.1.4. Product Scope..............................................................................................................10
2.1.5. References...................................................................................................................10
2.2. Overall Description..........................................................................................................10
2.2.1. Product Perspective.....................................................................................................10
2.2.2. Product Functions........................................................................................................11
2.2.3. User Classes and Characteristics.................................................................................12
2.2.4. Operating Environment...............................................................................................12
2.2.5. Design and Implementation Constraints.....................................................................13
2.2.6. User Documentation.....................................................................................................7
2.2.7. Assumptions and Dependencies...................................................................................7
2.3. External Interface Requirements......................................................................................8
2.3.1. User Interfaces...............................................................................................................8
2.3.2. Hardware Interfaces......................................................................................................8
2.3.3. Software Interfaces........................................................................................................8
2.3.4. Communications Interfaces...........................................................................................9
2.4. System Features................................................................................................................9
2.4.1. System Feature 1...........................................................................................................9
2.4.1.1. Description and Priority.............................................................................................9
2.4.1.2. Stimulus/Response Sequences..................................................................................9
2.4.1.3. Functional Requirements...........................................................................................9
2.4.2. System Feature 2.........................................................................................................10
2.4.2.1. Description and Priority...........................................................................................10
2.4.2.2. Stimulus/Response Sequences................................................................................10
2.4.2.3. Functional Requirements.........................................................................................10
2.4.3. System Feature 3 (and so on)......................................................................................11
2.5. Other Nonfunctional Requirements...............................................................................11
2.5.1. Performance Requirements........................................................................................11
2.5.2. Safety Requirements...................................................................................................11
2.5.3. Security Requirements................................................................................................12
2.5.4. Software Quality Attributes.........................................................................................12
2.5.5. Business Rules.............................................................................................................12
2.6. Other Requirements........................................................................................................12
Chapter 3.......................................................................................................................................13
Use Case Analysis...........................................................................................................................13
3.1. Use Case Model...............................................................................................................14
3.2. Fully Dressed Use Cases..................................................................................................14
Chapter 4.......................................................................................................................................15
System Design................................................................................................................................15
4.1. Architecture Diagram......................................................................................................16
4.2. Domain Model................................................................................................................16
4.3. Entity Relationship Diagram with data dictionary..........................................................16
4.4. Class Diagram..................................................................................................................17
4.5. Sequence / Collaboration Diagram.................................................................................17
4.6. Operation contracts........................................................................................................17
4.7. Activity Diagram..............................................................................................................18
4.8. State Transition Diagram.................................................................................................18
4.9. Component Diagram.......................................................................................................18
4.10. Deployment Diagram..................................................................................................19
4.11. Data Flow diagram [only if structured approach is used - Level 0 and 1]...................19
Chapter 5.......................................................................................................................................20
Implementation.............................................................................................................................20
5.1. Important Flow Control/Pseudo codes...........................................................................21
5.2. Components, Libraries, Web Services and stubs............................................................21
5.3. Deployment Environment...............................................................................................21
5.4. Tools and Techniques......................................................................................................22
5.5. Best Practices / Coding Standards...................................................................................22
5.6. Version Control................................................................................................................22
Appendices....................................................................................................................................23
Appendix A: Information / Promotional Material.........................................................................24
Reference and Bibliography...........................................................................................................27
Index..............................................................................................................................................29
List of Figures
List of Tables
1.5.2 Gap analysis process 4
1.7.1 work break down structure 6
1.7.3.1 Table Gantt chart 7

Chapter 1
Introduction
Chapter 1: Introduction
Stores Management System is a web based manufacturing system that enables a
manufacturing industry to schedule its manufacturing operations based on the daily update of
sales from its dealers. Once the sales figures of items for the past week are entered by the
dealers over the internet along with the orders for the next delivery, the schedule for the next
week’s production will be drawn up. A report of the required raw materials or parts will be
drawn up with the product requirements over the internet & asked to quote their rates.
1.1. Background
This system normally put all the incoming and outgoing product in store all the record will insert
on computer .users can shop from store and computerized bill issued by the computer for the
user all record will remain save in system as a record shopkeeper can checked all the detail of
his store on the computer in past it was a huge task many problem faced by manually work.
1.2. Motivations and Challenges

For long time people handle and manage all their record manually that was a huge task and
time consuming process .Due to these perspective we need advance techniques to manage our
task and overall purpose man comfort.
Challenges:
 Managing Warehouse Space/Layout. Real estate is a tremendous asset. ...
 Communication.
 Time Management.
 Inventory Accuracy/Tracking.
 Customer Expectations.
 Redundant Processes.
 Product Diversification.
 Product Picking Optimization.

1.3. Goals and Objectives

 Reducing Excess Inventory Costs
 Methods for Tracking Inventory Systems
 Maximize Overall Profit Margin
 Avoiding Stock-Outs and Lost Sales
 Keep Goods Moving Efficiently
1.4. Literature Review/Existing Solutions

The existing system is a manually maintained system. All the hostel student details are entered
into records manually. Separate records are to be maintained for the details of each student, fee
details, room allocation , attendance etc. All these details are entered and retrieved manually.
We have researched on many software in internet ,related our field and we have found that
database management system is less used for hostel management but it is used in other fields.
Most of them were web-based .System like library management, hospital management, student
management etc are used a lot. In Library Management System , system used to manages the
catalog of a library. This helps to keep the records of whole transactions of the books available
in the library. In this system we found many admin panel those who were library staffs.
1.5. Gap Analysis

The GAP analysis is aimed at the role of the management within the process of implementation
of the management system with regard to the achievement of organizations vision.
1.6. Proposed Solution

The store management system will provide owner and customer friendly environment all the
record will updated and the record will occupy many less space other than manual system .store
management system give information all sold ,available ,new delivery short delivery etc.

1.7. Project Plan

The project duration is six month first three month more than fifty percent work will be done
we use water fall model in our project that our work plan totally defined already the work will
start step by step procedure after one completion next work will start
1.7.1. Work Breakdown Structure
The Tree Structure View is the most popular format for the WBS. It presents an easy to
understand view into the WBS; however, it is also tricky to create without an application
specifically designed for creating this organizational chart structure.
1.7.2 Roles & Responsibility Matrix

The RACI matrix is a responsiblity assignment chart that maps out every task, milestone or key
decision involved in completing a project and assigns which roles are Responsible for each
action item, which personnel are Accountable, and, where appropriate, who needs to be
Consulted or Informed.
1.7.3 Gantt Chart
The chart is showing work criteria and time duration .work will be start and complete in his
duration time scale .
Table (1.7.3.1) Gantt chart
1.8 Report Outline


Chapter 2
Software Requirement
Specifications

Chapter 2: Software Requirement Specifications
2.1 Introduction
A Software Requirements Specification (SRS) is a document that describes the nature of a
project, software or application. In simple words, SRS document is a manual of a project
provided it is prepared before you kick-start a project/application. This document is also known
by the names SRS report, software document
2.1.1 Purpose
The purpose of the document is to collect and analyze all assorted ideas that have come up
to define the system, its requirements with respect to consumers. Also, we shall predict and
sort out how we hope this product will be used in order to gain a better understanding of the
project, outline concepts that may be developed later, and document ideas that are being
considered, but may be discarded as the product develops.
2.1.2 Document Conventions

<Describe any standards or typographical conventions that were followed when writing this SRS,
such as fonts or highlighting that have special significance. For example, state whether priorities
for higher-level requirements are assumed to be inherited by detailed requirements, or whether
every requirement statement is to have its own priority.>
2.1.3 Intended Audience and Reading Suggestions

<Describe the different types of reader that the document is intended for, such as developers,
project managers, marketing staff, users, testers, and documentation writers. Describe what the
rest of this SRS contains and how it is organized. Suggest a sequence for reading the document,
beginning with the overview sections and proceeding through the sections that are most
pertinent to each reader type.>

2.1.4 Product Scope

Primarily, the scope pertains to the utility store features for making store management
system and Home Entertainment project live. It focuses on the company, the stakeholders
and applications, which allow for online sales, distribution and marketing of electronics.
This SRS is also aimed at specifying requirements of software to be developed but it can
also be applied to assist in the selection of in-house and commercial software products.
The standard can be used to create software requirements specifications directly or can be
used as a model for defining a organization or project specific standard. It does not identify
any specific method, nomenclature or tool for preparing an SRS.
2.1.5 References
The references are:
 Utility Store Structural Model

 utility Behavioral Model
 utility NFR Model
 Vision Draft 5
2.2 Overall Description

2.2.1 Product Perspective
This document contains the problem statement that the current system is facing which is
hampering the growth opportunities of the company. It further contains a list of the
stakeholders and users of the proposed solution. It also illustrates the needs and wants of
the stakeholders that were identified in the brainstorming exercise as part of the
requirements workshop. It further lists and briefly describes the major features and a brief
description of each of the proposed system.
The following SRS contains the detail product perspective from different stakeholders. It
provides the detail product functions of E-Store with user characteristics permitted
constraints, assumptions and dependencies and requirements subsets.

2.2.2 Product Functions

Introduction
This subsection contains the requirements for the e-store. These requirements are
organized by the features discussed in the vision document. Features from vision
documents are then refined into use case diagrams and to sequence diagram to best
capture the functional requirements of the system. All these functional requirements can
be traced usingtractability matrix.
2.2.2.1. Sell Configured to Ordered Products.

 Display all the products that can be configured.
 Allow user to select the product to configure.
 Display all the available components of the product to configure
2.2.2.2 Provide comprehensive product details.

 display detailed information of the selected products.
 provide browsing options to see product details.
 Detailed product Categorizations
2.2.2.3 . Provide Search facility.

 The system shall enable user to enter the search text on the screen.
 The system shall enable user to select multiple options on the screen to search.
 The system shall display all the matching products based on the search
 The system shall display only 10 matching result on the current screen.
2.2.2.4. Provide personalized profile

 The system shall display both the active and completed order history in the customerprofile.
 The system shall allow user to select the order from the order history.
 The system shall display the detailed information about the selected order.
2.2.2.5. Provide Customer Support.

 provide online help, FAQ’s customer support, and sitemap options forcustomer support.
 allow user to select the support type he wants.
 allow user to enter the customer and product information for the support.
2.2.2.6. Email confirmation.

The system shall maintain customer email information as a required part of customerprofile.
The system shall send an order confirmation to the user through email.

2.2.2.7. Detailed invoice for customer.

The system shall display detailed invoice for current order once it is confirmed.
The system shall optionally allow user to print the invoice.
2.2.2.8 Provide shopping cart facility.
The system shall provide shopping cart during online purchase.
The system shall allow user to add/remove products in the shopping cart.
2.2.3 User Classes and Characteristics
 User
 Create account
 Change password
 Provide features for updating profile
 Update customer balance
 Administrator
 Update shop information
 Add new product
 Product check available
2.2.4 Operating Environment

The all operation will operate on electronic devices like computer attach scanner for scan
code ,printer for bill etc. all data will store in DBMS record and web base system .
 IBM
 ORACLE
 MY SQL
 VISUAL STUDIO
2.2.5 Design and Implementation Constraints

<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 (for example, if the customer’s
organization will be responsible for maintaining the delivered software).>

2.2.6 User Documentation

The components are :
 Nuxeo
 Office
 Greek bok
2.2.7 Assumptions and Dependencies

<List any assumed factors (as opposed to known facts) that could affect the requirements stated
in the SRS. These could include third-party or commercial components that you plan to use,
issues around the development or operating environment, or constraints. The project could be
affected if these assumptions are incorrect, are not shared, or change. Also identify any
dependencies the project has on external factors, such as software components that you intend
to reuse from another project, unless they are already documented elsewhere (for example, in
the vision and scope document or the project plan).>
2.3 External Interface Requirements

2.3.1 User Interfaces
 The user interface for the software shall be compatible to any browser such as Internet
Explorer, Mozilla or Netscape Navigator by which user can access to the system.
 The user interface shall be implemented using any tool or software package like Java
Applet, MS Front Page, EJB etc.
2.3.2 Hardware Interfaces
Since the application must run over the internet, all the hardware shall require to connect
internet will be hardware interface for the system. As for e.g. Modem, WAN – LAN,
Ethernet Cross-Cable.

2.3.3 Software Interfaces

 The store system shall communicate with the Configurator to identify all the
available components to configure the product.
 The store shall communicate with the content manager to get the product
specifications, offerings and promotions.
 The store system shall communicate with billPay system to identify available
payment methods , validate the payments and process payment.
 The store system shall communicate to credit management system for handling
financing options.
 The store system shall communicate with CRM system to provide support.
2.3.4 Communications Interfaces

The e-store system shall use the HTTP protocol for communication over the internet and
for the intranet communication will be through TCP/IP protocol suite.
 .Licensing Requirements
 Not Applicable
 Legal, Copyright, and Other Notices
 store should display the disclaimers, copyright, word mark, trademark and product warranties of
the Marvel electronics and home entertainment.
 Applicable Standards
 It shall be as per the industry standard.
2.4 System Features

They included such items as: reliability, availability, serviceability, security, scalability,
maintainability. Unlike the functional requirements (which are usually narrative in form),
the system qualities usually consist of tables of specific metrics that the system must meet to be
accepted

2.4.1 1. Improved inventory control and forecasting/projection

2.4.1.1 Description and Priority
As simple as this sounds, this should top your list. How should this new system assist in
managing and controlling inventory? Here are a few key questions to get you thinking about
major features and functions:
1. How robust is the SKU item master file? This is a good place to start the review of
systems. What data is available by SKU, such as product costing methods and product
characteristics?
2. Does the system project or forecast demand for an SKU? As in, will the system
calculate the quantity of a product required forward over a time horizon? A critical
function is to calculate when a product will “stock out” based on selling plans, rate of
sale, and project demand forward based on these rates of sale and using the vendor lead
time. Is history by item available for multi-years?
3. Will the system provide a channel view of your multichannel business, such as a
wholesale or ecommerce company? Does the system provide sales, customer demand
(orders), and dedicated stock by channel for promotional events and products, including
catalogs, web promotions, retail sales, and clearance sales?
2.4.1.2 Stimulus/Response Sequences

<List the sequences of user actions and system responses that stimulate the behavior
defined for this feature. These will correspond to the dialog elements associated with use
cases.>
2.4.1.3 Functional Requirements
<Itemize the detailed functional requirements associated with this feature. These are the
software capabilities that must be present in order for the user to carry out the services
provided by the feature, or to execute the use case. Include how the product should
respond to anticipated error conditions or invalid inputs. Requirements should be
concise, complete, unambiguous, verifiable, and necessary. Use “TBD” as a placeholder
to indicate when necessary information is not yet available.>
<Each requirement should be uniquely identified with a sequence number or a

meaningful tag of some kind.>
REQ-SF1-1: <Write your requirement here>

REQ-SF1-2:

REQ-SF1-3:
2.4.2 Barcoding & Scanning

2.4.2.1 Description and Priority
A barcode is a visual, machine-readable representation of data. Essentially, it is electronic data
entry using a scanner. The data contained in the barcode is typically tied to something, such as a
SKU, lot number, customer shipment, or a purchase order. Once scanned, this data is accessed
and displayed for the user to learn more information or take an action.
Bar code functions may be provided by the WMS vendor, but the inventory app needs to support
the use.
<Provide a short description of the feature and indicate whether it is of High, Medium, or
Low priority. You could also include specific priority component ratings, such as benefit,
penalty, cost, and risk (each rated on a relative scale from a low of 1 to a high of 9).>
2.4.2.2 Stimulus/Response Sequences
<List the sequences of user actions and system responses that stimulate the behavior
defined for this feature. These will correspond to the dialog elements associated with use
cases.>
2.4.2.3 Functional Requirements
<Itemize the detailed functional requirements associated with this feature. These are the
software capabilities that must be present in order for the user to carry out the services
provided by the feature, or to execute the use case. Include how the product should
respond to anticipated error conditions or invalid inputs. Requirements should be
concise, complete, unambiguous, verifiable, and necessary. Use “TBD” as a placeholder
to indicate when necessary information is not yet available.>
<Each requirement should be uniquely identified with a sequence number or a

meaningful tag of some kind.>
REQ-SF2-1:
REQ-SF2-2:
REQ-SF2-3:

2.4.3 System Feature 3 (and so on)
2.5 Other Nonfunctional Requirements

2.5.1 Performance Requirements
A non-functional requirement defines the performance attribute of a software system. Types
of Non-functional requirement are:
 Scalability Capacity,
 Availability,
 Reliability,
 Recoverability,
 Data Integrity, etc.
2.5.2 Safety Requirements

 Do not leak user information
 User order accuracy
 System granted
 Control Any third person presence
 backup
2.5.3 Security Requirements

 The system will secure
 Only register member use software
 System update only admin

2.5.4 Software Quality Attributes

<Specify any additional quality characteristics for the product that will be important to either
the customers or the developers. Some to consider are: adaptability, availability, correctness,

flexibility, interoperability, maintainability, portability, reliability, reusability, robustness,

testability, and usability. Write these to be specific, quantitative, and verifiable when possible.
At the least, clarify the relative preferences for various attributes, such as ease of use over ease
of learning.>
2.5.5 Business Rules

<List any operating principles about the product, such as which individuals or roles can perform
which functions under specific circumstances. These are not functional requirements in
themselves, but they may imply certain functional requirements to enforce the rules.>
2.6 Other Requirements

<Define any other requirements not covered elsewhere in the SRS. This might include database
requirements, internationalization requirements, legal requirements, reuse objectives for the
project, and so on. Add any new sections that are pertinent to the project.>

Chapter 3
Use Case Analysis

Chapter 3: System Analysis

In IT, systems analysis can include looking at end-user implementation of a software package or
product; looking in-depth at source code to define the methodologies used in building software;
or taking feasibility studies and other types of research to support the use and production of a
software product, among other things.
Systems analysis professionals are often called upon to look critically at systems, and redesign or
recommend changes as necessary. Inside and outside of the business world, systems analysts
help to evaluate whether a system is viable or efficient within the context of its overall
architecture, and help to uncover the options available to the employing business or other party
3.1. Use Case Model

Store Management System Use Case Diagram. This Use Case Diagram is a graphic depiction of
the interactions among the elements of Store Management System. It represents the
methodology used in system analysis to identify, clarify, and organize system requirements
of Store Management System
3.1.1 the relation between and among actors and use case of store management syatem
 Super admin entry
 Manage inventory
 System user entity
 Manage inventory
 Customer entity
 Cashier entity

3.2. Fully Dressed Use Cases
3,2,1 figure

Chapter 4
System Design

Chapter 4: System Design

Systems design is the process of defining the architecture, modules, interfaces, and data for
a system to satisfy specified requirements. Systems design could be seen as the application
of systems theory to product development. The purpose of the System Design is to supplement
the system architecture providing information and data useful and necessary for
implementation of the system elements.
4.1. Architecture Diagram

A system architecture diagram would be used to show the relationship between different
components. Usually they are created for systems which include hardware and software and
these are represented in the diagram to show the interaction between them. However, it can
also be created for web applications

4.2. Domain Model

A domain model is a system of abstractions that describes selected aspects of a sphere of
knowledge, influence or activity (a domain). The model can then be used to solve problems
related to that domain. Domain modeling is a technique used to understand the project
problem description and to translate the requirements of that project into software
components of a solution. A domain model contains conceptual classes, associations between
conceptual classes, and attributes of a conceptual class
4.3. Entity Relationship Diagram with data dictionary

Show all visual instrument of database table and relation between sales , discount, product ,
inventory etc. it use structure data and define relationship between structure data group of
store management system functionality main entity sales , payments discount stock and
inventory .
4.3.1 :store management system entity and attributes
 Product entity ,attributes are id ,product name , type
 Sale entity ,attributes are amount, id ,date type name
 Payment entity ,attributes are id ,name amount , time,
 Discount entity ,attributes are id ,amount ,product id ,
 Stock entity ,attributes are id amount , product id
 Inventory entity ,attributes are id ,date,

4.3.2 figure

4.4. Class Diagram

In software engineering, a class diagram in the Unified Modeling Language (UML) is a
type of static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, operations (or methods), and the relationships among
objects
 4.4.1 classes of store management system
 Store class
 Product class
 Stock class
 Bill class
 Retail price class
 Billing counter class
 4.4.2 class and attributes
 Store attributes: store rid, store name, store type
 Product attributes: product id, product customer id, product item
 Stock attributes :stock id , stock name ,
 Bill attributes: bill no , bill date bill description
 Retail price attributes : id name
 Billing counter attributes: id name
 4.4.3 Classes and method
 Store method :add store(),del store(), del store()
 Product method :add store(),del product(), del product() add product()
 Stock method :add stock(),del stock(), del stock()
 Bill method :add store(),del store(), del store()
 Retail price method :add store(),del store(), del store()
 Billing counter method :add bill(),del bill(), del bill()

4.4.4 Figure
4.5. Sequence / Collaboration Diagram

A sequence diagram shows object interactions arranged in time sequence. It depicts the objects
and classes involved in the scenario and the sequence of messages exchanged between the
objects needed to carry out the functionality of the scenarioThe instance involve in UML
sequence diagram of store management system are:
Discount object
Payment object
Stock object
Sale object

Product object
4.5.1:login sequence diagram
Where admin user will be able to login their account after login user can manage all operation
on stock ,discount ,payment sale all page such as sale purchase product stock will be secure and
user can access after login
.
4.5.2 figure
4.6. Operation contracts

4.7. Activity Diagram

Activity diagram is defined as a UML diagram that focuses on the execution and flow of the
behavior of a system instead of implementation. It is also called object-oriented
flowchart. Activity diagrams consist of activities that are made up of actions which apply to
behavioral modeling technology .UML activity diagram as follow
 Product activity
 Sales activity
 Stock activity
 Payments activity
 Inventory avtivity
4.7.1Features of UML store management system
Admin user can search product ,view description of selected product ,and products
update and delete product.
Its show the activity flow of editing ,adding and updating sales.
User will be able to search and generate report of stock ,payments, inventory.
All object such as(product , sale ,inventory) are interlinked.
Its show full description and flow of products payments inventory sale stock.

4.7.2 Figure
4.7.3 login activity diagram

4.7.4 figure
4.8. State Transition Diagram

A transition between one state into another state occurs because of some triggered event. To
draw a state diagram, one must identify all the possible states of any particular entity. The

purpose of these UML diagrams is to represent states of a system. States plays a vital role
in state transition diagrams
4.9. Component Diagram

A component diagram, also known as a UML component diagram, describes the organization
and wiring of the physical components in a system. Component diagrams are often drawn to
help model implementation details and double-check that every aspect of the system's required
functions is covered by planned development.
4.9.1 components
 Customer components
 Billing counter components
 Retail price components
 Stock components
 Product components
4.9.2 Features of components diagram.

 You can show model the components of retail store management system.
 Model the database schema of store management system.
 Model the executable of an application of store management system.
 Model the system source code of store management system.

4.9.3 Figure
4.10. Deployment Diagram

[Paragraph Text 12 pt, Calibri, 1.5 Line Spacing, Justified]

4.11. Data Flow diagram [only if structured approach is used - Level 0 and 1]

Chapter 5
Implementation

Chapter 5: Implementation
Implementation is the part of the process where software engineers actually program
the code for the project. Software testing is an integral and important phase of
the software development process. This part of the process ensures that defects are
recognized as soon as possible
5.1. Important Flow Control/Pseudo codes

5.2. Components, Libraries, Web Services and stubs

Components :
Basic components of Retail Management Systems. Typically, a retail business incorporates
multiple business operations - manufacturing, distribution, inventory, procurement,
replenishment, merchandising, Point of Sales, finances, customer management,
employee management, and much more.
5.3. Deployment Environment


5.4. Tools and Techniques

5.4.1.Deployment Tools
 Microsoft visual Studio
 Microsoft SQL server Management Studio Express
 NET Framework
Technology Used
 NET Framework Structure
 Compilation to Manage Code
 JIT compilation
 JIT compilation Data Provider
 The Connection object
 The command Object
 The Data Reader object
5.5. Best Practices / Coding Standards

5.6. Version Control


Appendices

Appendix A: Information / Promotional Material

[Between 4 to 8 lines describe what is this appendix all about ]
A.1. Broacher
A.2. Flyer
A.3. Standee
A.4. Banner

A.5. First Level heading [16 pt, Calibri, Bold, Left aligned]
A.5.1. Second level heading [14 pt, Calibri, Bold, Left aligned]
A.1.1.1. Third level heading [12 pt, Calibri, Bold, Left aligned]

Appendix [no.]: Appendix Title

[Between 4 to 8 lines describe what is this chapter all about ]
A.1. First Level heading [16 pt, Calibri, Bold, Left aligned]
A.1.1. Second level heading [14 pt, Calibri, Bold, Left aligned]
A.1.1.2. Third level heading [12 pt, Calibri, Bold, Left aligned]

Reference and
Bibliography

Reference and Bibliography
[1] M. Sher, M. Rehman, “Title of the Paper” Conference name/Journal Name, Edition,
Volume, Issue, ISBN/ISSN, PP, Publisher/City-Country, Year.
[2] ……

Index

Index
[A]
[B]
[C]



Template-05 - Project Report (Part-1) 123

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Template-05 - Project Report (Part-1) 123

Transféré par

Droits d'auteur :

Formats disponibles

SUPERIOR UNIVERSITY LAHORE

Faculty of Computer Science & IT

Final Year Project

[Store Management System]

Project ID: [write ID here Issued by FYP Manager]

[Mam Fatima Riaz]

Faculty of CS&IT, Superior University Lahore, Pakistan 2

HEAD OF THE DEPARTMENT

Faculty of CS&IT, Superior University Lahore, Pakistan 3

This work is dedicated to my Mam Fatima Lecturer in

Faculty of CS&IT, Superior University Lahore, Pakistan 4

Faculty of CS&IT, Superior University Lahore, Pakistan 5

Faculty of CS&IT, Superior University Lahore, Pakistan 10

1.2. Motivations and Challenges

 Product Picking Optimization.

Faculty of CS&IT, Superior University Lahore, Pakistan 2

1.3. Goals and Objectives

1.4. Literature Review/Existing Solutions

1.5. Gap Analysis

1.6. Proposed Solution

Faculty of CS&IT, Superior University Lahore, Pakistan 3

1.7. Project Plan

1.7.2 Roles & Responsibility Matrix

Table (1.7.3.1) Gantt chart

1.8 Report Outline

Faculty of CS&IT, Superior University Lahore, Pakistan 4

Faculty of CS&IT, Superior University Lahore, Pakistan 5

Faculty of CS&IT, Superior University Lahore, Pakistan 6

Chapter 2: Software Requirement Specifications

2.1.2 Document Conventions

2.1.3 Intended Audience and Reading Suggestions

Faculty of CS&IT, Superior University Lahore, Pakistan 7

2.1.4 Product Scope

 Utility Store Structural Model

2.2 Overall Description

Faculty of CS&IT, Superior University Lahore, Pakistan 8

2.2.2 Product Functions

2.2.2.1. Sell Configured to Ordered Products.

2.2.2.2 Provide comprehensive product details.

2.2.2.3 . Provide Search facility.

2.2.2.4. Provide personalized profile

2.2.2.5. Provide Customer Support.

2.2.2.6. Email confirmation.

Faculty of CS&IT, Superior University Lahore, Pakistan 9

2.2.2.7. Detailed invoice for customer.

2.2.4 Operating Environment

2.2.5 Design and Implementation Constraints

Faculty of CS&IT, Superior University Lahore, Pakistan 10

2.2.6 User Documentation

2.2.7 Assumptions and Dependencies

2.3 External Interface Requirements

2.3.2 Hardware Interfaces

Faculty of CS&IT, Superior University Lahore, Pakistan 11

2.3.3 Software Interfaces

2.3.4 Communications Interfaces

2.4 System Features

Faculty of CS&IT, Superior University Lahore, Pakistan 12

2.4.1 1. Improved inventory control and forecasting/projection

2.4.1.2 Stimulus/Response Sequences

<Each requirement should be uniquely identified with a sequence number or a

REQ-SF1-1: <Write your requirement here>

Faculty of CS&IT, Superior University Lahore, Pakistan 13

2.4.2 Barcoding & Scanning

<Each requirement should be uniquely identified with a sequence number or a