Sie sind auf Seite 1von 31

Chapter 2-System analysis

2.1. Data Analysis


2.1.1. System requirements

System Requirement a description of the needs and desires for an information system a requirement
may describe functions, features and constraints.
There are many people who have tried to solve such problems but they have not been successful to
find out a proper solution that will analyze the condition of the store and Give the detailed report of
the requirements.
Also the present condition in the development of this kind of software is that presently much such
software that have been successful in providing all the functionalities that are required by the
storekeepers. But the major drawback of this kind of software is that all the presently available
software is in the form of the different requirements based on the storekeepers. And after purchasing
the different software they want to install the all software to one system.
The software which the user will purchase that will consist of various tools that will be used in that
software to generate the reports such as balanced sheets, attendance sheet, salary reports etc. And the
results of these will be displayed to the user as report like above.
The project that we are going to make is about developing a desktop application that will be
published as software in the market and the Target Users such as the small shops to the big super
market will be able to get all the information from the software which they want to know for that
record.
By using this desktop application the users have to just create an account on the application and after
that the users will be able to do their work for free without purchasing any web based software.
The shopkeepers of present market want the new technologies to be used in the software of their
store that will provide a more accurate result and better comfort. So, this desktop application will
implement the latest technologies of the store and provide the reports to the users on the desktop.

2.1.1.1. Functional and data requirements

The functional requirements focus on the main functions that the new system will provide, describe
the interaction between the system and its environment independent from the implementation, a
function or features that must be included in an information system that satisfy the business need and
be acceptable by the users. Our project contains the following functional requirements like:-
i. This system takes care of reports.
ii. It also processes the items.
iii. The key features that we likes to add to the new module “Store
management System(SMS)”
iv. SMS- needs to have accept information and requirements tracking from
the manager.
v. Damage report should provided by storekeeper.
Data requirements
Describe the data requirements by producing a logical data model, which consists of entity relationship
diagrams, entity definitions, and attribute definitions. This is called the application data model. The data
requirements describe the business data needed by the application system. Data requirements do not
describe the physical database.

ER Diagram for data requirements

Name
Item note Item code

n: 1
ITEM Include CATEGORY

n: n
1: n
Item description n: 1

Include Have
Have

UNITE MEASURE SUB CATEGORY

LOCATION

Name
Name

Name
Address
ER for supplier
SUPPLIER
Supplier name:
Contact person:
Contact full name:
Address:
Phone (primary):
Phone (alternative):
Fax:
Email:

Entity Definitions and Attribute Definitions

Entity Definitions Attribute Definitions


ITEM Item code: it may be input/scan bar
code
Item note: any note about item
Item description:
CATEGORY Name: category name
UNITE MEASURE Name: unite measure name (kg, meter,
feet, pound…)
LOCATION Name: store name
Address: store address
SUPPLIER Supplier name: eg. organization name
Contact person:
Contact full name:
Address:
Phone (primary): 555 555 555 555
Phone (alternative): 555 555 555 555
Fax:
Email: eg. Sproject1@mtu.com
Table 1 Entity and Attribute Definition
2.1.1.2. Non-functional requirements

The non-functional requirements deals with the quality of the systems needed to be developed from
different evaluation point of view like the response time of the system to a given user queries, the user
friendliness of the website and These requirements do not directly affect the performance of the system
but they are important.
 Maintenance: The store Management System is being developed in VB. VB is an
object oriented programming language and shall be easy to maintain

 Portability:-The store Management System shall run in any Microsoft Windows


environment that contains VB Runtime and the Microsoft Access database.

 Reliability: - The store Management System service should not access without
authenticate user.
 Standards Compliance: - The graphical user interface of the system shall have easily
understood to the user (have consistent look and feel graphical user interface).
 Performance: -Acceptable response times for system functionality.
 Security: - Access to the various subsystems will be protected by a user log in screen
that requires a user name and password.

2.1.2. Proposed solutions

2.1.2.1. Use case model


2.1.2.1.1. Use case diagram
The following use cases have been identified from the system specification

Use case
 Register User
 Add items
 Generate report
 calculation
 finding item
 View
The identified actors that will be participating in the system are:

Actors
User/admin
Actors: Any user for store Management System.
a. Use case description
A use case is a methodology used in system analysis to identify, clarify, and organize system
requirements. The use case is made up of a set of possible sequences of interactions between
systems and users in a particular environment and related to a particular goal. Use case is a list of
steps, typically defining interactions between a role (known in UML as an actor) and a system, to
achieve a goal. The actor can be a human or an external system.

Use case name manage

Participating actor User

Entry condition The user click the application to start for first use.

Exit condition When the user click close button or cancel.

Pre condition The user has to install the system.

Post condition The user see the main window.

Table 2 Register

Use case name Backup data

Participating actor User

Entry condition The user click Backup menu item from the tools menu.

Pre condition The user should select tools.

Exit condition When click Backup or cancel button

Post condition The database will be backup

Table 3 Backup data


Use case name Restore data

Participating actor User

Entry condition The user click Restore menu item from the tools menu

Pre condition The user should select tools.

Exit condition When click restore or cancel button

Post condition The database will be restore

Table 4 Restore data

Use case name Add Item

Participating actor User

Entry condition The user select Add Item button

Pre condition The user should open to the system

Exit condition When the click Add Item or cancel button

Post condition The data base will be updated

Table 5 Add item

Use case name Receive stoke

Participating actor User

Entry condition The user click receive stoke button.

Pre condition The user should open the system.

Exit condition When the click Receive or cancel button

Post condition The receive data will be saved

Table 6 Receive Stoke


Use case name Inventory

Participating actor User

Entry condition The user click Inventory menu item.

Pre condition The user should click Add Item button.

Exit condition When the click Add Item or cancel button

Post condition The inventory information add to item will be updated

Table 7 Inventory

Use case name Delete Item

Participating actor User

Entry condition The user click Delete button.

Pre condition The user should select item/s to be delete.

Exit condition When the click ok or cancel button

Post condition The database will be updated

Table 8 Delete Item

Use case name View Report

Participating actor User

Entry condition The user click Report button.

Pre condition The user open the system.

Exit condition When the click close button

Post condition The report will be generated

Table 9 View Report


Use case name Find Item

Participating actor User

Entry condition The user click Find Item button.

Pre condition The user should run the system.

Exit condition When click cancel button

Post condition The discovered items displayed

Table 10 Find item

Use case name Add Request

Participating actor User

Entry condition The user click Add Request button.

Pre condition The user should run the system.

Exit condition When click cancel button

Post condition The request data saved

Table 11 Add Request

Use case name Cancel Request

Participating actor User

Entry condition The user click Cancel Request button.

Pre condition The user should run the system.

Exit condition When click cancel button

Post condition Request will be deleted/canceled

Table 12 Cancel Request


Use case name Supplier

Participating actor User

Entry condition The user click Supplier button.

Pre condition The user should run the system.

Exit condition When click cancel button

Post condition Supplier information will be store

Table 13 Supplier
2.1.2.2. Sequence Diagram
A sequence diagram in a Unified Modeling Language (UML) is a kind of interaction diagram that shows how
processes operate with one another and in what order. It is a construct of a Message Sequence Chart. 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 scenario. Sequence diagrams typically (but not always), are associated with use case
realizations in the Logical View of the system under development. Sequence diagrams are sometimes called
event diagrams, event scenarios, and timing diagrams.
.

Figure 1 add item


Figure 2 add request
Figure 3 backup
Figure 4 cancel request
Figure 5 delete item
Figure 6 find item
Figure 7 inventory
Figure 8 manage
Figure 9 receive stoke
Figure 10 restore data
Figure 11 view report
2.1.2.3. Behavioral model
2.1.2.3.1. Activity diagram

Figure 12 Add item


Figure 13 add/cancel request
Figure 14 backup
Figure 15 delete item
Figure 16 manage application
Figure 17 receive stoke
Figure 18 restore
Figure 19 search item
Figure 20 view report

Das könnte Ihnen auch gefallen