You are on page 1of 7
UNIVERSITI KUALA LUMPUR MALAYSIAN INSTITUTE OF INFORMATION TECHNOLOGY L02 ICB 20403 OBJECT ORIENTED SYSTEM ANALYSIS AND

UNIVERSITI KUALA LUMPUR

MALAYSIAN INSTITUTE OF INFORMATION TECHNOLOGY

L02

ICB 20403 OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN

PART 2 PROPOSAL: STOCK INVENTORY MANAGEMENT SYSTEM

NO.

GROUP NAME

STUDNETS ID

  • 1. NURUL HANIS BINTI SHAMSUDIN

52213116045

  • 2. NURUL BAHIYAH BINTI MOHD ATZAHA

52213116015

  • 3. NUR SYAMIMI BINTI SAMRI

52213116057

  • 4. MUHAMMAD TALHA

52213215352

  • 5. SITI NURATIQAH BINTI BAKHTIARLILI

52213116039

PREPARED BY:

PREPARED FOR:

MADAM WAN HAZIMAH BINTI WAN ISMAIL

TABLE OF CONTENTS

  • 1.0 INFORMATION GATHERING AND MODELING..................................................5

    • 1.1 ABOUT CURRENT SYSTEM..........................................................................5

    • 1.2 FUNCTIONAL REQUIREMENTS....................................................................6

      • 1.2.1 User Login...........................................................................................6

      • 1.2.2 Add New Scarf/Product........................................................................6

      • 1.2.3 Search Scarf/Product...........................................................................7

  • 1.3 NON FUNCTIONAL REQUIREMENTS............................................................8

    • 1.3.1 Usability...............................................................................................8

    • 1.3.2 Reliability.............................................................................................8

    • 1.3.3 Performance........................................................................................8

    • 1.3.4 Interfacing...........................................................................................9

    • 1.3.5 Supportability......................................................................................9

  • 1.4 USE CASE DESCRIPTION.............................................................................9

  • 1.5 USE CASE DIAGRAM...................................................................................9

  • 1.6 ACTIVITY DIAGRAM.....................................................................................9

  • 1.7 CLASS DIAGRAM........................................................................................9

  • 1.8 SEQUENCE DIAGRAM.................................................................................9

  • 1.9 STATE DIAGRAM.........................................................................................9

  • 2.0 TECHNOLOGY AND DOMAIN..........................................................................9

  • 3.0 GENERAL CONSTRAINTS...............................................................................9

  • 1.0

    INFORMATION GATHERING AND MODELING

    • 1.1 ABOUT CURRENT SYSTEM

    The existing system that they used is using a lot of papers. They must update the stock of items by the list on the papers given by the manager. After the stock of hijab is sold out, the paper is also wasted. The paper wasted could cause the waste of trees. Furthermore, the workers job will be harder because of they had to search for the hijab one by one according to the list in the file. Some of existing system semi-automated and many are manual to keep the transaction record of the inventory in the departmental store. People still prefer to follow the manual method even if there is automated system to keep the record. We have found that employees first record all information in their ledger before entering in computer system. They are using both ways to keep the record of stock purchase, inventory, sales monitoring, etc. Following this method is very time consuming and tedious. It has many drawbacks as there may be mistakes while recording large data and this may disrupt the important transaction.

    1.2

    FUNCTIONAL REQUIREMENTS

    The System aims at providing an efficient interface to the user for managing of inventory, it shall also provide the user varied options for managing the inventory through various functions at hand. The design is such that the user does not have to manually update the inventory every time, the System does if for the user.

    • 1.2.1 User Login

    Description of feature

    This feature used by the user to login into system. They are required to enter user id and password before they are allowed to enter the system .The user id and password will be verified and if invalid id is there user is allowed to not enter the system.

    Functional requirements User id is provided when they register

    o

    o

    The system must only allow user with valid id

    o

    and password to enter the system The system performs authorization process

    o

    which decides what user level can access to. The user must be able to logout after they finished using system.

    • 1.2.2 Add New Scarf/Product

    Description of feature

    This feature allows to add new scarf in the inventory system

    Functional requirements System must be able to verify information

    o

    o

    System must be able to enter number of copies into table.

    o

    System must be able to add the quantity when the same name of scarves adding

    1.2.3 Search Scarf/Product

    Description of Feature

    This feature is found in scarf maintenance part. We can search scarf based on scarf id, scarf name, and date or by vendor name.

    Functional requirements

    o

    System must be able to search the database based on select search type.

    o

    System must be

    able

    to

    filter scarf

    based on

    o

    keyword entered. System must be able to show the filtered scarf in table view.

    • 1.3 NON FUNCTIONAL REQUIREMENTS

    1.3.1

    Usability

    The

    system

    must

    be

    easy

    to

    use

    by

    both

    sales

    managers and administrator such

    that

    they do

    not

    need to read an extensive amount of manuals.

     

    The system must be quickly accessible by both sales managers and administrator.

    The system must be intuitive and simple in the way it displays all relevant data and relationships.

    The menus of the system must be easily navigable by the users with buttons that are easy to understand.

    • 1.3.2 Reliability

     

    The System must give accurate inventory status to the user continuously. Any inaccuracies are taken care by the regular confirming of the actual levels with the levels displayed in the system.

    The System must successfully add any scarves by the user and provide estimations and inventory status in relevance with the newly updated entities.

    The system must provide a password enabled login to the user to avoid any foreign entity changing the data in the system.

    The

    system

    should

    provide

    the

    user updates on

    completion of requested processes and if the requested processes fail, it should provide the user the reason for the failure.

    The system should not update the data in any database for any failed processes.

    • 1.3.3 Performance

     

    The system must not lag, because the workers using it do not have down-time to wait for it to complete an action.

    The system must complete updating the databases, adding the scarves and vendor successfully every time the user requests such a process.

    All the functions of the system must be available to the user every time the system is turned on.

    • 1.3.4 Interfacing

     

    The system must

    offer

    an

    easy and simple

    way

    of

    viewing the current inventory.

     

    The system must be able to display the relationships between vendors, and scarves in an intuitive manner.

    • 1.3.5 Supportability

    The software is designed such

    that it works even

    on

    systems having the minimum configuration.

    The system is adaptable even if additional plugins or modules are added at a later point.

    The data can be exported to the administrator so as to make the system more portable.

    • 1.4 USE CASE DESCRIPTION

    • 1.5 USE CASE DIAGRAM

    • 1.6 ACTIVITY DIAGRAM

    • 1.7 CLASS DIAGRAM

    • 1.8 SEQUENCE DIAGRAM

    • 1.9 STATE DIAGRAM

    • 2.0 TECHNOLOGY AND DOMAIN

    • 3.0 GENERAL CONSTRAINTS