Software Requirements Specification Inventory Management System 1

 

Software Requirements Specification (SRS) On INVENTORY MANAGEMENT SYSTEM BACHELOR OF TECHNOLOGY IN COMPUTER SCIENCE AND ENGINEERING Submitted to: Inderjit Singh By

ERAMALLA ARAVIND 11709190 Roll No: B-35 Section: K17DM

School of Computer Science and Engineering

Lovely Professional University

 

DECLARATION STATEMENT  

I hereby declare that the case study entitled “ONLINE INVENTORY MANAGEMENT SYSTEM (SALESBINDER.COM)” submitted at Lovely Professional University, Phagwara, Punjab is an authentic work and has not been submitted elsewhere. I understand that the work presented herewith is in direct compliance with Lovely Professional University’s Policy on plagiarism, intellectual property rights, and highest standards of moral and ethical conduct. Therefore, to the best of my knowledge, the content of this case study represents authentic and honest effort conducted, in its entirety,  by me. I am fully responsible for the contents of my case study report.  

E.ARAVIND

 

ROLLNO:B-35

 

 

Table of Contents 1. In Intr trod oduc ucti tion on 1.1   Overview 1.2   Purpose 1.3   Scope 1.4   Glossary 1.5   Overview

2. Ov Over eral alll desc descri ript ptio ion n 2.1   Product Perspective 2.2   Product Function 2.3   Potential user of the system 2.4   User Characteristics 2.5   User Assumptions and dependencies

 

3. Sp Spec ecif ific ic Req Requi uire reme ment ntss 

3.1 

Functonal Requiremens

3.1.1 3.1.2 3.1 .2 3.1.3 3.1 .3 3.1.4 3.1.5

General functional requirements:

Functi Functiona onall Requirem Requirement entss for Produc Productio tion n Control Controller  ler  Functi Functiona onall Requirem Requirement entss for Produc Productio tion n Supervi Supervisor  sor   Functional Requirements for Administrator  Qualiy Functon Depolymen

3.1.5.1 3.1.5 .1 Normal Normal Requiremens Requiremens 3.1.5.2 3.1.5 .2 Exceped Exceped Requiremens Requiremens

 

3.1.5.3 Exciting Requirements  

4. Int Interf erface acess and De Desig sign n 4.1   User Interface 4.2   Hardware Interface 4.3   Software Interface  4.4   Communicational Interface

 

5. No Non n Fun Functi ctiona onall Req Requir uireme ements nts 5.1   Performance Requirements

 

5.2   Reliability Requirements 5.3 Availability Requirements

 

5.3

Security Requirements

5.4

Maintainability

5.5

Portability Requirements

5.6

Operational Requirements

6.   Constraints 6.1

7.

Sc Scen enar ario io Ba Base sed d Mode Modell 7.1 7.2

8.

Use case diagram Activity diagram

Flow Model 8.1 8.2

9.   10. 11.

Design constraints

Data flow model (level 0) Data flow model (level 1)

Class diagram Sequence diagram Collaboration diagram

 

1. Introductio Introduction n In software industry requirement requirement engineering engineering is one of the most important important parts of software engineering process, which one gives us the proper scenarios what the customers want, analyzing their needs and checking the feasibility what they need, negotiating a reasonable soluti sol ution on etc. etc. In softwa software re indust industries ries,, a softwa software re projec projectt begins begins when when a bu busin siness ess need need is identified. So the first step is we need to understand identified. understand the customer needs. Figure Figure out a rough feasibility analysis, not only the customer’s need but also with the people who are apparently involved with the introducing system. In this phase after interacting with our client “Sleek  Fa Fash shio ion n Ltd. Ltd.”, ”, we get get some some re requ quir irem emen ents ts fo forr an in inve vent ntor ory y mana manage geme ment nt so solu luti tion on..  This paper will be more easeful after communicating with our client with their more specific requir req uireme ements. nts. At the same time, time, in this this paper paper we will will focus focus on Invent Inventory ory manageme management nt modu mo dule le.. Agai Again n th this is pa pape perr is a pa part rtia iall subm submiss issio ion; n; more more de deta tail il will will be in incl clud uded ed as pe per  r  communicating with the entire stakeholder’s.

1.1 Purpose The purpose of this document is to present a detailed description of the Online Inventory Management System. It will explain the purpose and features of the system, the interfaces of  the system, what the system will do, the constraints under which it must operate and how the system will react to external stimuli. In th this is do docu cume ment nt we wi will ll tr try y in intr trod oduc ucee ou ourr stak stakeh ehol olde ders rs al alon ong g with with th thei eirr respe respect ctiv ivee viewpoints, describe the existing problem, combining those various view points, balancing those tho se to reach reach an ultima ultimate te “theor “theoretic etical” al” soluti solution on of the identi identifie fied d proble problems, ms, generat generating ing graphical reviews through unified modeling language (UML) to formulate the problems and the proposed proposed soluti solution, on, the project project scope scope and the projec projectt schedu schedule. le. Next Next we presen presentt the solution including system analysis, the deviation between final and initial design, the function of our Inventory management system and testing plan. Finally we evaluate our work on different aspects, present areas of improvement and conclusion.

1.2 Scope The outcome of the project would be automated inventory management service .The software will have all common features and functionalities along with some other special facilities.    To provide user efficient working environment. 

User friendly interface for the target stakeholders.



Proper monitoring facility for the authority.



Easy maintenance and administration.



Ensure high level of security.

 

This system will help in tracking records so that past records can be verified through them and one can make decisions based on the past records. This system will complete the work  in a very less time resulting in less time consumption and high level of efficiency.

1.3 Glossary Key Terms

Definition

RMG

Ready Made Garments

Inventory

Inventory means a list compiled for some formal purpose

Production Controller 

Who guide and supervise production work.

QC

Quality Control

IIS

Internet Information System

SRS

Software Requirement Specification

DFD

Data Flow Diagram

PQ

Production Controller  

1.4 Overview The next chapter is identifying stakeholders. In this chapter gives an over view who are directly or indirectly depend on the developing system and what is their point of view.

The next chapter, the General Description section, of this document gives an overview of the functionality of the product. It describes the informal requirements and is used to establish a context for the technical requirements specification in the next chapter. The Forth chapter, Requirements Specification section, of this document is written primarily for the developers and describes in technical terms the details of the functionality of the  product. All the sections of the document describe the same software product in its entirety, .

 

2. Over Description 2.1 Product Perspective In this modern world of commercialization, garments business has been established as one of  the flourishing flourishing in Bangladesh. Bangladesh. It has been one of the most flourishing flourishing export sectors for our  country, as we have told in background. Now, our project is concerned with this sector. This is a huge field to cover, as hundreds of manageable aspects can be found to maintain the highest high est productivit productivity y of textile textile manufacturi manufacturing. ng. We choose choose the inventory management management as our   preferred field to work. To instantiate, this can be specified as a b2b system, from producers to abroad or home dealers through some intermediate business nodes. The important deals that our RMG sector  are mostly from abroad interests, as stated above. And our goal would be facilitate this whole  process, from collecting raw materials to the finished product shipment. Unlike Unli ke th thee old old da days ys,, RMG RMG se sect ctor or of Bang Bangla lade desh sh ha hass be been en impl implem emen entin ting g a va vari riet ety y of  management software, in order to enhance the productivity, and to satisfy the customers’ needs. As these deals are very sensitive to handle, and there are a lot of variables that must be maintained, maint ained, the need of online online interaction interaction between the buyer and the seller, or even seller to seller, is a must, and can play a dramatic influence on these deals. As the whole process has multiple steps to the way to finished goods, a single delay in a single step can cause delay in the shipment schedule, suppose our delay in cutting can demolish the required time structure, which can also cause financial damage and bad business reputation. The existing systems have been using not for so long, and the maturity level of software industry in our country is still very low. So, the systems which are being used in recent days in th thee ga garm rmen ents ts in indu dustr stry y do ha have ve a lot lot of bu bugs gs,, fu func ncti tion onal al de depe pend nden encie ciess an and d de desi sign gn constraints. Besides, there is still a lacking of a complete solution for managing garments which is yet to be made. And we have to say, after studying, we find that majority of the garment industry doesn’t use any automated management system, where a large amount of   problems in manual management can be solved in automated automated system. The thing is missing all through and which we have been planning to introduce in these kind of usual management system, is online interface to control the system. Internet has been a  pivotal determiner in every aspects life. We are proposing to introduce internet controlling module of this system, so that the authority of our client can monitor and manipulate the system, as well as the database through the internet. At the same same time, time, there there are technol technologi ogies es being being used used to manage manage payrol payroll, l, appoin appointme tments, nts, inventory, and in many other purposes. But as our major concerns will be inventory oriented, we will focus the most on that.

 

2.2 Product Functions Inventory Management System must be designed to meet the dictates of the marketplace and support the company's strategic plan. Along with the inventory system Garment industries need nee d some some more more special special att attrib ribute utes. s. The The Softwa Software’ re’ss for Garmen Garmentt are special specially ly made made for  managing the various steps in order processing of garments manufacturing process. This software is modular in design and is web enabled for remote access as well as intranet usage without the need to install in every machine. Inventory Management System has some features which are badly needed for a complete Inventory system of Garment industries. So the features are,            

Web based interface User based Login - password based authentication for data protection. Dyna Dy nami micc Modu Modula larr str struc uctu ture re – Each Each an and d ev ever ery y secti section on relat related ed to a  production has separate menus. Manage master details of buyer, supplier and vendor. Job Work tracking. Raw material tracking. Shipment tracking. Product category and product stock information with value. Reports include purchase, issues, stocks & categories. Customized package  Notification System in case of any process delay. Check sheet automation.

These features are primary requirement of our client for this inventory management system. This feature list will change in terms of client demand

2.3 Potential Potential User of the System There are two groups of users in our system. They are the production controller and the system maintenance administrators. They have different authorities in our system which is shown as follows;  Production Controller: They are the Controller of the production in each and every section related to total production. They can insert the detail product information which is completed. Besides, they are able to view order sheet and sample sheet to keep their production accurate. But their authentication domain is limited between their field, which can be exemplified as the production controller who is in charge of  cutting, will not have the access to the information about payroll or customers. 

Administrator: They are authorized staffs to control the system. They are assigned with different level of authority to control different parts of the system like inventory and administrators. In addition, administrators are responsible to maintain database.

 

2.4 User Characteristics The users of the software are classified into two categories – Registered user and unregistered user. Both users will be able to visit the homepage of the website but only the registered user is allowed to give input in the system. To work through the system one user should go through some fixed steps     

First of all the user should be registered. Thee se Th sepa para rate te pr prod oduc ucti tion on modu module le wi will ll be pr pres esen ente ted d to th thee us user er as a catalog for viewing. The user can browse through the categories to choose the module they desire. The user can input partially complete production quantity of the total  production. Finally the product will be delivered within a fixed and trusted time  period to the next production module. module. And the process will continue until the shipment is completed

2.5 Assumptions and Dependencies After completing our study about inventory and inventory management system, we thought that, our Inventory management software will be ideal one in terms of garments industries of  our country. According to our view that inventory system will Contain module like:   Information of different products category   Available stock    Price of different items  transaction details  One can also extract any reports relating to purchase and Sale.  The inventory management application will have all the categories,  Subcategories, items, Stock details and reports. The administrator of this inventory system will have right to create product, add items delete items etc. The application application will provide provide all informatio information n of the products. products. The category will be tagged with subcategory. Again the subcategories are tagged with different items in the respective category and rate of the item. Each item will have a specific bar code. The rates will be tagged to the bar code. Using these functions the user can:  Add items to inventory  Edit items in inventory  Add an action for an item

The application will also help to generate reports to get latest update on  

Master Entry Purchase order entry

 Receive entry

 

 

Delivery entry Report

This inventory system also has some dependencies like cannot be deleted except administrator   If data’s are inserted it cannot  User can insert a data but can’t delete  If data’s are not inserted, user cannot view report.

.

3. Requirement Analysis Requireme Requir ement nt Analys Analysis is presen presents ts the requir requireme ement nt specif specificat ication ion,, softwar softwaree and hardwa hardware re requirements for both system developers and system users, process model and data model. In this section we specify the External Interface Requirements, functional and nonfunctional requirements of the system.

3.1 Functional Requirements  Functional requirements define the functions that are requested by our stakeholders Different

functions are needed by different users of the system. Different administrators have authority to main maintai tain n th thee syste system. m. The The sy syste stem m sp spec ecif ifies ies th thee au auth thor orit ity y of th thee ad admi mini nistr strato ator. r. The The administrator has got control over the database of the system. S/He can make changes to update the total inventory system, and the update will be carried out dynamically. 3.1.1 General functional requirements:  

Garment production is combination of different partial production. To keep track  of those partial production there will some modules in the system those are,  





the ga garm rmen entt manu manufa fact ctur urin ing g th thee first first step step is Sketch Submissio Sketch Submission n: In the designing the sketch for the dresses that have to be prepared. That sketch contains all sort of information related to the product. So in the time of   production work this sketch is followed very strictly. Our client wants functionali funct ionality ty in the system that the administrator administrator can submit a sketch in the system according to their buyer that can available to all the other  us user erss of th thee syste system. m. And And this this sket sketch ch wi will ll he help lp th thee ad admi mini nist strat rator or to  prepare a well-balanced check sheet for the production. The pa patt tter ern n de desi sign gn is ta take ken n fo forr creat creatin ing g th thee Producti Prod uction on Pattern Pattern::  The  production patterns according to the sketch design. The production  pattern is one which will be used for huge production of garments. The  pattern maker makes the patterns on standard pattern making paper. But our client wants a module that will keep all the production pattern according to their buyer name. Spreading:  With the help of spreading machines, fabric is stacked on

on onee an anot othe herr in reache reachess or lays lays th that at may go over over 10 100 0 ft. ft. Long Long and hundreds of plies (fabric pieces) thick. But our system will calculate the

 

amount amou nt of fabric fabric piec pieces es to ba bala lanc ncee it with with th thee ch check eck sheet sheet to ge gett  profitable production. Cutting: Cutting the clothes to the desired sizes is a massively important  job in RMG business.  

 



Sorting: Sorting the inventory to increase the productivity is challenge, which must be overcome to ensure the best management of the company. The sorter sorts the patterns according to size and design and makes  bundles of them. Sewing: There are sewing stations for sewing different parts of the cut  pieces. In this workplace, there are many operators who perform a single operation. One operator may make only straight seams, while another  may make sleeve insets.

Finishing.

Packing. These modules contain the database of every worker and supervisor accounts created, as well as the amount of resources, raw materials and other facilities received from the authority, and their outcomes must be posted in a regular basis by the person responsible to handle a specific module, the controller, which is noted in the functional requirements for controllers 

 below.      

An effective database to store important data of every deal. Every module will have separated record for all the transactions occur. Limited external accessibility, between a company or between a selected group. Limited internal accessibility, one module can be maintained and manipulated by one person or one group of responsible employees.

3.1.2 Functional Requirements for Production Controller 

Login.



Browse desired modules.



Browse desired supervisor portfolio.



 Notify the system about the module requirements.



Input product quantity after compiled.



Distribute requirements between the production supervisors.



Supervise inter-work station combination.



View production details with delivery date.



Browse through different production areas.



Balancing the check sheet.

3.1.3 Functional Requirements for Production Supervisor

 

 

Login.

 

Get update from the controller.

 

Setting the goal of the group and updating it on the system.

 

Input the worker-to-worker data.

 

Supervise own worker group performance.

     

 Notify the dependent working group group supervisors through the system. Balancing the group input and output. Submitting the group balance sheet to the responsible controller.

3.1.4 Functional Requirements for Administrator 

Login.



Accessibility to the whole system.



Monitoring the total system as well as the database.



Giving the total goal of a deal as the input.



Clarifying the resources.



Distributing the job segments to the controllers.



Getting update information about the production.



Getting update information about production delay.



Getting update information about operation.



Invoice information collection.



Change settings

3.1.5 Quality Function Deployment

Quality function deployment is a method to transform user demands into design quality, to deploy the functions forming quality, and to deploy methods for achieving the design quality into into subs subsys yste tems ms an and d co comp mpon onen entt part parts, s, and and ulti ultima mate tely ly to sp spec ecif ific ic el elem emen ents ts of th thee manufacturing process.  QFD is designed to help planners focus on characteristics of a new or existing product or  serv servic icee from from th thee view viewpo poin ints ts of market segments segments,, company, company, or technology-d technology-develo evelopment pment needs. The technique yields graphs and graphs and matrices. matrices. QFD helps transform customer  needs into needs into engineering characteristics engineering characteristics for a product or service,  prioritizing each product or service characteristic while simultaneously setting development targets for product or service.

 

Quality Function Deployment (QFD) can be categorized by  

 Normal Requirements, Expected Requirements, and Exciting Requirements.

Here is the list of functional quality of our product, 3.1.5.1 Normal Requirements Requirements

 Normal requirements are those requirements which stakeholders want to be available in the System. The normal requirements of this proposed application are given below

The In The Inve vent ntor ory y Syst System em must must ke keep ep track track of al alll co comp mpil iled ed pr prod oduc ucts ts or  re reso sour urce cess recor records ds,, which which is ex expe pect cted ed to ge gene nera rate te an and d must must no noti tify fy if  resources associated with the production is missing or order is incomplete.



The system must have an option to produce check sheet.



The system will perform perform authorization authorization of users for security security purposes. purposes. All the users as well as the administrator must have to perform this part.



All types of resources and price information related to any production must have to store in the system.



If any kind of change will occur, there will be an update option in the system, using that administrator can change the existing information.



Users can browse through different production module.



The system must have the production plan making option. Every module will have separated record for all the compilations occur. Limited Limi ted external external accessibility, accessibility, between companies or between between selected selected groups. Limi Limited ted inter interna nall ac acces cessib sibil ilit ity, y, on onee modu module le ca can n be main mainta tain ined ed an and d manipulated by one person or one group of responsible employees. Well-structured database to store inventory records.

       

3.1.5.2 Expected Requirement Requirementss

Expec Ex pected ted requir requireme ements nts are those those requir requireme ements nts which which stakeho stakeholde lders rs not mentio mentioned ned to be available in the system but he/she expects this will provide by the developer in the system. The expected requirements for our proposed system are given below-

 



The system will contain user friendly interface that will be designed in a manner which implements functionalities that are easily accessible by the users.



The system system must must ensure ensure databa database se backup backups, s, which which are as recent recent and complete as possible



Check sheet, production planning, and backup files should be in readable



file format or in crystal reports format. Order will be issued according to buyer name. This will help authority to deal with their respected buyer.

3.1.5.3 Exciting Requirements Requirements

Exciting requirements are those requirements which stakeholders not actually want but these requirements have to fulfill to make the system interesting. The exciting requirements for our   proposed system are given below

Pr Prod oduc ucti tion on plan planni ning ng wi with th in inve vest stme ment nt an and d estim estimat ated ed pr prof ofit it wi will ll be calculated through the system.



 Normal users and administrators have to login through different login  page which will ensure that, without administrator no one can change any information of a production as well as the system.



System has the notifying system for any kind of delay occurs in the given period. But the system can notify the dependent working group supervisors if the administrators need them.



Administrators can distribute the job segments to the controllers.

4. Requirement Analysis Requireme Requir ement nt Analys Analysis is presen presents ts the requir requireme ement nt specif specificat ication ion,, softwar softwaree and hardwa hardware re requirements for both system developers and system users, process model and data model. In this section we specify the External Interface Requirements, functional and nonfunctional requirements of the system.

4.1 User Interfaces

User interface is one of the most important elements in any software. Most of the software’s are used by non- technical persons. So they always seek of user friendly environment in their  system. And the user interface makes the system more familiar to its user. For our system we do not design an user interface yet. But the process is going on. 4.2 Hardware Interfaces

In the current version of the software, it will have no special hardware interface with other external systems. It will run in a general-purpose computer system with general-purpose hardware and software.

 

4.3 Software Interfaces

The Current version of this system will be built on the following software:  

Server:   Internet Information system   MsSQL server 2008.   MVC 3.

 

Client:  JavaScript.  OpenSSL.  JavaScript (synchronous/asynchronous) Enable Browser.

4..4 Communications Interfaces

All sorts of communications communications between server and client programs programs will be using ADO.NET ADO.NET (ActiveX Data Objects for .NET) is a set of computer software components that programmers can use to access data and data services. It is a part of the  base class library that library that is included with the Microsoft .NET Framework . It is commonly used by programmers to access and modify mod ify data stored stored in relational database systems, systems, though though it can also access access data in nonnonrelational sources and the messaging will be done by XML format.

5 Other Non-Functional Requirement

 Non-functional Requirements of a system specify the performance, reliability, availability, security, maintainability, portability of a system. So below there are a short description each of those non-functional requirements.

5.1 Performance

Our proposed inventory management system will be used in Garment industry. There are lot of intern internal al and extern external al operat operation ion which which are inter-r inter-rela elated ted with with each each other other for fruit fruit full full  production. So the communication among each end system should be tightly scheduled and the notification should be sent in timely manner.

5.2 Reliability The production process in the garment industries is a combination of different operations, which generate lots of data. These data lose can cause high damage to a specific module as well as to the total process. So if the reliability is not confirmed, this lacking will affect the  production performance. 5.3 Availability

This system will be dedicated to a particular client. So the availability will be restricted of  this system.

5.4 Security

This system will deal with huge amount of data. So security is a prime issue of our system. So the system should be secured from external interfere by providing efficient security to the entire system.

 

5.5 Maintainability

Software maintenance in software engineering is engineering is the modification of a software product after  delivery to correct faults, to improve performance or other attributes. Maintainability of  software is categorized in four classes: 

Adaptive – dealing with changes and adapting in the software environment.



Perfective – accommodating with new or changed user requirements which concern functional enhancements to the software.



Corrective – dealing with errors found and fixing it.



Preventive – concerns activities aiming on increasing software maintainability and  prevent problems in the future. So to maintain our system we will try to concentrate on this four classes.

5.6 Portabili Portability ty 

Portability is the degree to which software running on one platform can easily be converted to run on another. Portability is hard to quantify, because it is hard to predict on what other   platforms the software will be required to run. So to make our system portable we have to use languages, operating systems and tools that are universally available and standardized. 5.7 Operational Requirement 

The system can be viewed by open source Mozilla Firefox.



The system is supported by the IIS(Internet information’s system).



The team used MsSQL database to develop and maintain the database management systems.

6 Constr Constraints aints 6.1 Design constraints constraints

When the project team is started to design the system, at that time the team always tries to meet all the requirements of their client properly. But some time client’s make the job difficult for the team to design the system by raising some last moment requirements. This is considered as main constraints of designing a system.

 

 7. Scenario Based Model

7.1 Use Case diagram

In software  software  an and systems systems engineering engineering,, a use use case case is a list list of step steps, s, ty typi pica call lly y de defi fini ning ng interactions between a role or actor and a system, to achieve a goal. The actor can be a human or an external system. Initially after analyzing the requirements of our client we notify two potential actors in our   proposed system. But this can change any time time when their requirements are modified. So in this system normal users are production controllers. They can browse through their   production related modules. They can view all the production details, all the partial  production areas related to their production, can create check sheet according to order  quantity.

 

  Figure : Use Case Diagram

On the other hand admin can change system setting settings, s, update update operation operation information, information, Update  production information etc  7.2 Activity Diagram Activity Activi ty diagra diagrams ms are graphi graphical cal represe representa ntatio tions ns of workflows  workflows  of stepwise stepwise activitie activitiess and ac acti tion onss wi with th su supp ppor ortt fo forr ch choi oice, ce, iter iterati ation on an and d co conc ncur urren rency cy.. In th thee Unified Unified Modeling Modeling Language,, activity diagrams can be used to describe the business and operational step-by-step Language workflows of components in a system. An activity diagram shows the overall flow of control.

If we consider the given activity diagram, it will easier for us to find out step-by step operational workflows of total system. When the process starts it will allow a user to select his/he his /herr own authenti authenticati cation. on. If the user logged logged in as an Admin Administr istrato ator, r, the user has the

 

authority to select operation between change settings of the working module and update information of the production.

8. Flow model

 Data flow diagram  A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system, system, modeling its process aspects. Often they are a preliminary step used to create an overview of the system which can later be elaborated. DFDs can also be used for  the visualization of visualization of data processing . processing . A DFD shows what kinds of data will be input to and output from the system, where the data will come from and go to, and where the data will be stored. It does not show information about abo ut the timing timing of process processes, es, or inform informatio ation n about about wheth whether er process processes es will will op operat eratee in sequence or in parallel

Figure 5: Data Flow Diagram (Level 0)

Data flow diagram (level 0):

DFD level 0 , is the representation re presentation of the system which can only sshows hows the inputs and outputs of the system without dealing with any function and file or database issue. In the given figure this is the data flow diagram (Level 0) for our proposed inventory management system. Control panel and the planning is two input entity which can give data command to the system, all the inputs will process in the system and the outputs will view in the display panel or as notification. And the system also can produce check sheet according to given planning.

 

 

Figure : Data Flow Diagram (Level 1)

Data flow diagram (Level 1):

DFD level 1, is the representation of the system which can visualize the relation among the functions and the file or database with the inputs and outputs. Control panel and planning entity can give input command to the system, which can process by some functions in this system like interact with user, configure, and update input, display status. There is a database related with configure function which one can modify productio production n informatio information. n. And display status sta tus,, notifi notificati cation, on, check check sheet sheet can produc producee output output depend depend on all the functi functions ons which which configure inputs.

 

9. Class Model Class Diagram

In software engineering, engineering, a class diagram in the Unified Modeling Language (UML) 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 the classes. classes

 

Figure : Class Diagram

In the above exposed diagram ‘Module’ is the parent class which has two child classes ‘Administrator’ and ‘Production Controller’. Order Class deals with all the steps related to

 

orde orderr an and d main mainta tain ined ed by ad admi mini nistr strat ator or.. ‘Sto ‘Store re ‘a ‘and nd ‘Shi ‘Shipm pmen ent’ t’ class class main maintai taine ned d by  production controller.

10.Sequence Diagram

Figure : Sequence Diagram

A sequence diagram in a Unified Modeling Language (UML) Language (UML) is a kind of interaction diagram that showssystem’s how processes operate one another and in shows whatsorder. is a construct of our   proposed Sequence Chart. Chartwith . A sequence sequen ce diagram diagr am show object objectItinteractions intera ctions arranged in time sequence. It depicts the objects and classes involved in the scenario and the sequence of Command exchanged between the objects needed to carry out the functionality of the scenario.

 

11. Collaboration Diagram

Figure : Collaboration Diagram

Collaboration Collaborati on diagrams belong to a group of UML diagrams called Interaction Diagrams. Diagrams. Collaboration diagrams, like Sequence Diagrams, show how objects interact over the course of time. However, However, instead of showing the sequence sequence of events events by the layout on the diagram, diagram, collaboration diagrams show the sequence by numbering the Commands on the diagram. This makes it easier to show how the objects are linked together, but harder to see the sequence at a glance.