Online Inventory Management System 3g71v
This document was ed by and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this report form. Report 2z6p3t
Overview 5o1f4z
& View Online Inventory Management System as PDF for free.
More details 6z3438
- Words: 6,666
- Pages: 32
Online Inventory Management System Software Requirement Specification
Online Inventory Management System
Software Requirements Specification Course Title: Software Project Lab 2 Course Code: SE 505
Online Inventory Management System Version 1.2 10/03/2012 Submitted to: Md. Shafiul Alam Khan Assistant Professor Institute of Information Technology University Of Dhaka
Submitted by: Atish Dipongkor
BIT0217
Muttakin Ahmed
BIT0222
AshrafulHoque
BIT0231
Software Requirements Specification
Page 1
Online Inventory Management System
Revision History Date 3.3.2012
Description Version 1.0
10.3.2012 Version 1.1
Author Atish Kumar Dipongkor Muttakin Ahmed Khan Md. Ashraful Hoque
Comments First Revision Second Revision
Document Approval The following Software Requirements Specifications have been accepted and approved by the following: Signature Printed Name Title Date Assistant Professor Md. Shafiul Alam IIT ,University of Dhaka Khan Supervisor, Project Team
Software Requirements Specification
Page 2
Online Inventory Management System
Contents REVISION HISTORY...................................................................................................................................................II DOCUMENT APPROVAL............................................................................................................................................II 1. INTRODUCTION......................................................................................................................................................1 1.1 PURPOSE 1.2 SCOPE 1.3 GLOSSARY 1.4 REFERENCES
1 1 2 2
2. STAKEHOLDERS.....................................................................................................................................................3 2.1 QUESTIONERS 2.2 STAKEHOLDER’S POINT OF VIEW 2.3 COLLABORATION
3 4 4
3. GENERAL DESCRIPTION.......................................................................................................................................5 3.1 PRODUCT PERSPECTIVE 3.2 CURRENT SYSTEM ANALYSIS 3.3 PRODUCT FUNCTIONS 3.4 POTENTIAL OF THE OF THE SYSTEM 3.5 CHARACTERISTICS 3.6 ASSUMPTIONS AND DEPENDENCIES
5 6 7 7 8 8
4. REQUIREMENT ANALYSIS....................................................................................................................................9 4.1 EXTERNAL INTERFACE REQUIREMENTS 4.1.1 Interfaces 4.1.2 Hardware Interfaces 4.1.3 Software Interfaces 4.1.4 Communications Interfaces 4.2 FUNCTIONAL REQUIREMENTS 4.2.1 General Functional Requirements 4.2.2 Functional Requirements for Production Controller 4.2.3 Functional Requirements for Production Supervisor 4.2.4 Functional Requirements for 4.2.5 Quality Function Deployment 4.3 NON-FUNCTIONAL REQUIREMENTS 4.3.1 Performance 4.3.2 Releability 4.3.3 Availability 4.3.4 Security 4.3.5 Maintainability 4.3.6 Portability 4.3.7 Operational Requirement 4.3.8 Design Constraints
9 9 9 9 9 10 10 11 11 12 12 14 14 14 14 14 15 15 15 15
5. ANALYSIS MODELS..............................................................................................................................................15 5.1 SCENARIO BASED MODEL 5.1.1 Use Case Diagram 5.1.2 Activity Diagram 5.1.3 Swim Lane Diagram 5.2 FLOW MODEL Software Requirements Specification
16 16 18 19 20
Page 3
Online Inventory Management System
5.2.2 Data flow model (level 1)
5.2.1 Data flow model (level 0)
20 21
5.3 CLASS MODEL 5.3.1 Class Diagram 5.3.2 CRC Diagram 5.6 BEHAVIORAL MODEL 5.4.1 State Representation Diagram 5.4.2 Sequence Diagram 5.4.3 Collaboration Diagram
22 22 23 24 24 25 26
6.CONCLUSION..........................................................................................................................................................26
List of Figure Figure 1- Current System Figure 2- Use Case Diagram Figure 3- Activity Diagram Figure 4- Swim Lane Diagram Figure 5- Data Flow Diagram (Level 0) Figure 6- Data Flow Diagram (Level 1) Figure 7- Class Diagram Figure 8- CRC Diagram Figure 9- State Representation Diagram Figure 10- Sequence Diagram Figure 11- Collaboration Diagram
6 17 18 19 20 21 22 23 24 25 26
Software Requirements Specification
Page 4
Online Inventory Management System
1. Introduction In software industry requirement engineering is one of the most 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 solution etc. In software industries, a software project begins when a business need is identified. So the first step is we need to understand the customer needs. 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 Fashion Ltd.”, we get some requirements for an inventory management solution. This paper will be more easeful after communicating with our client with their more specific requirements. At the same time, in this paper we will focus on Inventory management module. Again this paper is a partial submission; more detail will be included as per 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 this document we will try introduce our stakeholders along with their respective viewpoints, describe the existing problem, combining those various view points, balancing those to reach an ultimate “theoretical” solution of the identified problems, generating graphical reviews through unified modeling language (UML) to formulate the problems and the proposed solution, the project scope and the project schedule. Next we present 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 efficient working environment. friendly interface for the target stakeholders. Proper monitoring facility for the authority. Easy maintenance and istration. Ensure high level of security. Software Requirements Specification
Page
Online Inventory Management System
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
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 References
www.agilemodeling.com/artifacts/crcModel.html. http://en.wikipedia.org/wiki/Unified_Modeling_Language http://en.wikipedia.org/wiki/Requirements_analysis http://rfptemplates.technologyevaluation.com/rfp/for/inventory-management-garments.html http://www.slideshare.net/ahmedhasan/ieee-830-1998-software-requirements-specifications http://gulnazahmad.hubpages.com/hub/A-Step-by-Step-of-Garment-Manufacturing
1.5 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.
Software Requirements Specification
Page
Online Inventory Management System
The Forth chapter, Requirements Specification section, of this document is written primarily for the developers and describes in technical the details of the functionality of the product. The fifth chapter, Analysis model section. In this section of this document there are some model diagrams. List of all these analysis models used in developing specific requirements . All the sections of the document describe the same software product in its entirety,
2. Stakeholders The stakeholders of the software project are those people or positions who are directly or indirectly affected or effected by the project. The stakeholders and s who are most immediately involved in an Inventory management system can be divided in to four groups, they are: Executives and upper management. Production Controller. Production supervisor. The root level workers. System developers.
2.1 Questioners 1. 2. 3. 4. 5. 6. 7.
How the processes work? Who are the primary and secondary actors of the whole process all through? Who will be the vital actors in the required system? What is the usual working procedure for an order? What are the major flaws that forced you to automated management solution? Will it be more specific in of some major flaws you want us to solve? How will you appreciate the functional facilities as an of the proposed system? 8. Who are the people you want to directly to interact with the system and what should be their domain? 9. What event starts the use case? 10. How does the use case end? 11. Are there any optional situations for the use case? 12. How the processes will work, if the system will become automated?
2.2 Stakeholders view point
Software Requirements Specification
Page
Online Inventory Management System
Different Stakeholders achieve different benefits form a software system. Consequently each of them has a different point of view. So we have to recognize the requirements from multiple view point. For this Inventory management system point of view of stakeholders is:
Executives and upper management beholds the people who are concerned with company management and company’s financial states. They always deal with the profitability and increasing production unit. So their view about the system is how to utilize the system to gain highest profit. Production controller is the people who supervise a part of a production unit. They will interact with our system to input the data of their subordinate workers. Their view point would be to input that information without any kind of difficulties and maintain the private s of each worker
The production supervisors are the people who act as the subordinates of the production controllers, and they must have the real interactions with the root operation. This is not necessary that every supervisor will have distinguished areas to work with; there can be more than one supervisor to supervise a single activity, when it’s a larger one. The supervisors are responsible to check the given input and the outcomes they managed to produce. As these information are required for the operation of our system, production supervisors are identified as one vital stakeholder.
One of the indirect stakeholders of our proposed system is the root level workers of RMG sector, who use to do the primary level jobs of cutting, printing, and combing all the parts together, or any other jobs for example. As because of our limitation of resources, all the workers won’t use our system frequently. But, for occasional possibilities, some of them will use his system, and their illiteracy must be considered by the system developers.
2.3 Collaboration As information from multiple viewpoints is collected, emerging requirements may be inconsistent or may conflict with one another. So considering the scope of feasibility, we have collaborated the following list of requirements from multiple viewpoints. The extracted ideas gathered from the inventory department are:
Online status of item quantity in of on-hand, on-hand available, reserved, ordered, to order, rejected, defective and rework able quantities. Complete excise functionality and generation of excise s. Quality Control based on QC parameters. Physical verification of stock. Purchasing and subcontracting. ing – inventory synchronization. Update delay notification. Keep Track of partial Production.
Software Requirements Specification
Page
Online Inventory Management System
All Financial transactions related to production. . The next steps of this analysis are analyzing credibility and go/ no- go decision making. For these, this team needs more data to be analyzed and communicating with the client. We hope that we will be able to submit the full Functioning paper within a short time.
3. General Description 3.1 Product Perspective In this modern world of commercialization, garments business has been established as one of the flourishing in Bangladesh. It has been one of the most 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 productivity of textile manufacturing. We choose the inventory 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 the old days, RMG sector of Bangladesh has been implementing a variety 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, the need of online 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 the garments industry do have a lot of bugs, functional dependencies and design 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 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.
Software Requirements Specification
Page
Online Inventory Management System
At the same time, there are technologies being used to manage payroll, appointments, inventory, and in many other purposes. But as our major concerns will be inventory oriented, we will focus the most on that.
3.2 Current System Analysis
Figure 1: Current System. The given diagram is a scenario of current system. In the present system, when the sealed the production order then the people related to the production, specially PQ ,’s make the total production planning, and according to the plan the make a check sheet. According to the production planning total production work is divided in to partial productions. These partial productions are the part of total production. Combining this entire partial production element total production take place. But the fact is that in each stage of this partial production face production loses because of manual updating system. They cannot follow the check sheet properly. So they cannot deliver their shipment with in due date. So our client wants a system which can provide automated updating system, accurate calculation of produced goods, provide proper stock information, send notification if the shipment won’t take place on due date, keep track of partial production, and all Financial transactions related to production.
Software Requirements Specification
Page
Online Inventory Management System
3.3 Product Functions Inventory Management System must be designed to meet the dictates of the marketplace and the company's strategic plan. Along with the inventory system Garment industries need some more special attributes. The Software’s for Garment are specially 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 based - based authentication for data protection. Dynamic Modular structure – Each and every section related 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 of client demand
3.4 Potential of the of the System There are two groups of s in our system. They are the production controller and the system maintenance s. 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. : 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 s. In addition, s are responsible to maintain database.
Software Requirements Specification
Page
Online Inventory Management System
3.5 Characteristics The s of the software are classified into two categories – ed and uned . Both s will be able to visit the homepage of the website but only the ed is allowed to give input in the system. To work through the system one should go through some fixed steps
First of all the should be ed. The separate production module will be presented to the as a catalog for viewing. The can browse through the categories to choose the module they desire. The 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. And the process will continue until the shipment is completed
3.6 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 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 of this inventory system will have right to create product, add items delete items etc. The application will provide all information of the 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 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
Software Requirements Specification
Page
Online Inventory Management System
Purchase order entry Receive entry Delivery entry Report
This inventory system also has some dependencies like If data’s are inserted it cannot be deleted except can insert a data but can’t delete If data’s are not inserted, cannot view report. .
4. Requirement Analysis Requirement Analysis presents the requirement specification, software and hardware requirements for both system developers and system s, process model and data model. In this section we specify the External Interface Requirements, functional and nonfunctional requirements of the system.
4.1 External Interface Requirements 4.1.1 Interfaces 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 friendly environment in their system. And the interface makes the system more familiar to its . For our system we do not design an interface yet. But the process is going on. 4.1.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.1.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.1.4 Communications Interfaces All sorts of communications between server and client programs will be using ADO.NET (ActiveX Data Objects for .NET) is a set of computer software components that programmers Software Requirements Specification
Page
Online Inventory Management System
can use to access data and data services. It is a part of the base class library that is included with the Microsoft .NET Framework. It is commonly used by programmers to access and modify data stored in relational database systems, though it can also access data in nonrelational sources and the messaging will be done by XML format.
4.2 Functional Requirements Functional requirements define the functions that are requested by our stakeholders Different functions are needed by different s of the system. Different s have authority to maintain the system. The system specifies the authority of the . The 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. 4.2.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, Sketch Submission: In the garment manufacturing the first step is deg 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 functionality in the system that the can submit a sketch in the system according to their buyer that can available to all the other s of the system. And this sketch will help the to prepare a well-balanced check sheet for the production. Production Pattern: The pattern design is taken for creating 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 one another in reaches or lays that may go over 100 ft. Long and hundreds of plies (fabric pieces) thick. But our system will calculate the amount of fabric pieces to balance it with the check sheet to get 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.
Software Requirements Specification
Page
Online Inventory Management System
Finishing. Packing. These modules contain the database of every worker and supervisor s 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. 4.2.2 Functional Requirements for Production Controller
.
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.
4.2.3 Functional Requirements for Production Supervisor
.
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 supervisors through the system.
Balancing the group input and output.
Submitting the group balance sheet to the responsible controller.
Software Requirements Specification
Page
Online Inventory Management System
4.2.4 Functional Requirements for
.
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
4.2.5 Quality Function Deployment Quality function deployment is a method to transform demands into design quality, to deploy the functions forming quality, and to deploy methods for achieving the design quality into subsystems and component parts, and ultimately to specific elements of the manufacturing process. QFD is designed to help planners focus on characteristics of a new or existing product or service from the viewpoints of market segments, company, or technology-development needs. The technique yields graphs and matrices. QFD helps transform customer needs into 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,
Software Requirements Specification
Page
Online Inventory Management System
4.2.5.1 Normal 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 Inventory System must keep track of all compiled products or resources records, which is expected to generate and must notify 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 authorization of s for security purposes. All the s as well as the 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 can change the existing information.
s 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 external accessibility, between companies or between selected groups. Limited internal accessibility, one module can be maintained and manipulated by one person or one group of responsible employees. Well-structured database to store inventory records.
4.2.5.2 Expected Requirements Expected requirements are those requirements which stakeholders not mentioned 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 friendly interface that will be designed in a manner which implements functionalities that are easily accessible by the s.
The system must ensure database backups, which are as recent and complete as possible
Software Requirements Specification
Page
Online Inventory Management System
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.
4.2.5.3 Exciting 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
Production planning with investment and estimated profit will be calculated through the system.
Normal s and s have to through different page which will ensure that, without 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 s need them.
s can distribute the job segments to the controllers.
4.3 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. 4.3.1 Performance Our proposed inventory management system will be used in Garment industry. There are lot of internal and external operation which are inter-related with each other for fruit full production. So the communication among each end system should be tightly scheduled and the notification should be sent in timely manner. 4.3.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. 4.3.3 Availability
Software Requirements Specification
Page
Online Inventory Management System
This system will be dedicated to a particular client. So the availability will be restricted of this system. 4.3.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. 4.3.5 Maintainability Software maintenance in software 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 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.
4.3.5
Portability
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. 4.3.7 Operational Requirement The system can be viewed by open source Mozilla Firefox. The system is ed by the IIS(Internet information’s system). The team used MsSQL database to develop and maintain the database management systems.
4.3.8 Design 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 deg a system. Sometime clients do not give the proper information which is needed by the team to design software, because of company policies. At that situation software project team start their work without proper overview through the existing system to design new one. Software Requirements Specification
Page
Online Inventory Management System
5. Analysis Models Analysis model is one of the most important parts of SRS. All the models give us clear view of the developing system. In this section, here is the list of all analysis models used in developing specific requirements of the current developing system.
Scenario based model:
Flow Model
Data Flow Diagram.
Class Model:
Use Case Diagram. Activity Diagram. Swim lane Diagram.
Class Diagram. CRC Diagram.
Behavioral model:
State transition Diagram. Sequence Diagram. Collaboration Diagram.
5.1 Scenario Based Model
5.1.1 Use Case diagram In software and systems engineering, a use case is a list of steps, typically defining interactions between a role or actor and a system, to achieve a goal. The actor can be a human or an external system.
Software Requirements Specification
Page
Online Inventory Management System
Initially after analyzing the requirements of our client we notify two potential actors in our proposed system. But this can change any time when their requirements are modified. So in this system normal s 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 2: Use Case Diagram Software Requirements Specification
Page
Online Inventory Management System
On the other hand can change system settings, update operation information, Update production information etc.
5.1.2 Activity Diagram Activity diagrams are graphical representations of workflows of stepwise activities and actions with for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.
Software Requirements Specification
Page
Online Inventory Management System
Figure 3: Activity Diagram. 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 to select his/her own authentication. If the logged in as an , the has the authority to select operation between change settings of the working module and update information of the production. On the other hand if the logged in as a production controller, after valid authentication the production controller can give input in the system to ensure the partial production of the total production. In any state of the production if the delay is occurred, production controller can notify istration about the delay to handle shipment related issues.
Software Requirements Specification
Page
Online Inventory Management System
5.1.3 Swim Lane Diagram A swim lane is a visual element used in process flow diagrams, or flowcharts, that visually distinguishes responsibilities for sub-processes of a business process.
Figure 4: Swim Lane diagram This is the swim lane view of our proposed system according to present requirements .System column shows the entire operational function .and and production controller column shows the task that they will do using the system
5.2 Flow model 5.2.1 Data flow diagram A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system, modeling its process aspects. Often they are a preliminary step used to Software Requirements Specification
Page
Online Inventory Management System
create an overview of the system which can later be elaborated. DFDs can also be used for the visualization of data 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 the timing of processes, or information about whether processes will operate in sequence or in parallel
Figure 5: Data Flow Diagram (Level 0)
Data flow diagram (level 0): DFD level 0 , is the representation of the system which can only shows 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 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 or as notification. And the system also can produce check sheet according to given planning.
Software Requirements Specification
Page
Online Inventory Management System
Figure 6: 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 and planning entity can give input command to the system, which can process by some functions in this system like interact with , configure, and update input, display status. There is a database related with configure function which one can modify production information. And display status, notification, check sheet can produce output depend on all the functions which configure inputs.
Software Requirements Specification
Page
Online Inventory Management System
5.3 Class Model 5.3.1Class 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 the classes.
Figure 7: Class Diagram
In the above exposed diagram ‘Module’ is the parent class which has two child classes ‘’ and ‘Production Controller’. Order Class deals with all the steps related to order and maintained by . ‘Store ‘and ‘Shipment’ class maintained by production controller.
Software Requirements Specification
Page
Online Inventory Management System
5.3.2 Class Responsibility Collaboration Diagram
Figure 8: CRC Diagram A Class Responsibility Collaborator (CRC) model is a collection of standard index cards that have been divided into three sections, Section 1: A class represents a collection of similar objects. Section 2: A responsibility is something that a class knows or does. Section 3: A collaborator is another class that a class interacts with.
Software Requirements Specification
Page
Online Inventory Management System
5.4 Behavioral model 5.4.1 State Representation Diagram
Figure 9: State Representation Diagram. A state diagram is a type of diagram used to describe the behavior of systems. State diagrams require that the system described is composed of a finite number of states; sometimes, this is indeed the case, while at other times this is a reasonable abstraction. Many forms of state diagrams exist, which differ slightly among each other. In the given figure, this is the state representation diagram for our proposed system. In the given figure there are four states, first one “reading state” just read the instructions. Second one “comparing state” compares the given command. When the state compare , if the is invalid, total system will be locked for a while. Or if the is valid it will move a step ahead to select operation what the system allow an .
Software Requirements Specification
Page
Online Inventory Management System
5.4.2 Sequence Diagram
Figure 10: 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 our proposed system’s 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 Command exchanged between the objects needed to carry out the functionality of the scenario.
Software Requirements Specification
Page
Online Inventory Management System
5.4.3 Collaboration Diagram
Figure 11: Collaboration Diagram Collaboration diagrams belong to a group of UML diagrams called Interaction Diagrams. Collaboration diagrams, like Sequence Diagrams, show how objects interact over the course of time. However, instead of showing the sequence of events by the layout on the 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.
Software Requirements Specification
Page
Online Inventory Management System
Software Requirements Specification Course Title: Software Project Lab 2 Course Code: SE 505
Online Inventory Management System Version 1.2 10/03/2012 Submitted to: Md. Shafiul Alam Khan Assistant Professor Institute of Information Technology University Of Dhaka
Submitted by: Atish Dipongkor
BIT0217
Muttakin Ahmed
BIT0222
AshrafulHoque
BIT0231
Software Requirements Specification
Page 1
Online Inventory Management System
Revision History Date 3.3.2012
Description Version 1.0
10.3.2012 Version 1.1
Author Atish Kumar Dipongkor Muttakin Ahmed Khan Md. Ashraful Hoque
Comments First Revision Second Revision
Document Approval The following Software Requirements Specifications have been accepted and approved by the following: Signature Printed Name Title Date Assistant Professor Md. Shafiul Alam IIT ,University of Dhaka Khan Supervisor, Project Team
Software Requirements Specification
Page 2
Online Inventory Management System
Contents REVISION HISTORY...................................................................................................................................................II DOCUMENT APPROVAL............................................................................................................................................II 1. INTRODUCTION......................................................................................................................................................1 1.1 PURPOSE 1.2 SCOPE 1.3 GLOSSARY 1.4 REFERENCES
1 1 2 2
2. STAKEHOLDERS.....................................................................................................................................................3 2.1 QUESTIONERS 2.2 STAKEHOLDER’S POINT OF VIEW 2.3 COLLABORATION
3 4 4
3. GENERAL DESCRIPTION.......................................................................................................................................5 3.1 PRODUCT PERSPECTIVE 3.2 CURRENT SYSTEM ANALYSIS 3.3 PRODUCT FUNCTIONS 3.4 POTENTIAL OF THE OF THE SYSTEM 3.5 CHARACTERISTICS 3.6 ASSUMPTIONS AND DEPENDENCIES
5 6 7 7 8 8
4. REQUIREMENT ANALYSIS....................................................................................................................................9 4.1 EXTERNAL INTERFACE REQUIREMENTS 4.1.1 Interfaces 4.1.2 Hardware Interfaces 4.1.3 Software Interfaces 4.1.4 Communications Interfaces 4.2 FUNCTIONAL REQUIREMENTS 4.2.1 General Functional Requirements 4.2.2 Functional Requirements for Production Controller 4.2.3 Functional Requirements for Production Supervisor 4.2.4 Functional Requirements for 4.2.5 Quality Function Deployment 4.3 NON-FUNCTIONAL REQUIREMENTS 4.3.1 Performance 4.3.2 Releability 4.3.3 Availability 4.3.4 Security 4.3.5 Maintainability 4.3.6 Portability 4.3.7 Operational Requirement 4.3.8 Design Constraints
9 9 9 9 9 10 10 11 11 12 12 14 14 14 14 14 15 15 15 15
5. ANALYSIS MODELS..............................................................................................................................................15 5.1 SCENARIO BASED MODEL 5.1.1 Use Case Diagram 5.1.2 Activity Diagram 5.1.3 Swim Lane Diagram 5.2 FLOW MODEL Software Requirements Specification
16 16 18 19 20
Page 3
Online Inventory Management System
5.2.2 Data flow model (level 1)
5.2.1 Data flow model (level 0)
20 21
5.3 CLASS MODEL 5.3.1 Class Diagram 5.3.2 CRC Diagram 5.6 BEHAVIORAL MODEL 5.4.1 State Representation Diagram 5.4.2 Sequence Diagram 5.4.3 Collaboration Diagram
22 22 23 24 24 25 26
6.CONCLUSION..........................................................................................................................................................26
List of Figure Figure 1- Current System Figure 2- Use Case Diagram Figure 3- Activity Diagram Figure 4- Swim Lane Diagram Figure 5- Data Flow Diagram (Level 0) Figure 6- Data Flow Diagram (Level 1) Figure 7- Class Diagram Figure 8- CRC Diagram Figure 9- State Representation Diagram Figure 10- Sequence Diagram Figure 11- Collaboration Diagram
6 17 18 19 20 21 22 23 24 25 26
Software Requirements Specification
Page 4
Online Inventory Management System
1. Introduction In software industry requirement engineering is one of the most 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 solution etc. In software industries, a software project begins when a business need is identified. So the first step is we need to understand the customer needs. 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 Fashion Ltd.”, we get some requirements for an inventory management solution. This paper will be more easeful after communicating with our client with their more specific requirements. At the same time, in this paper we will focus on Inventory management module. Again this paper is a partial submission; more detail will be included as per 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 this document we will try introduce our stakeholders along with their respective viewpoints, describe the existing problem, combining those various view points, balancing those to reach an ultimate “theoretical” solution of the identified problems, generating graphical reviews through unified modeling language (UML) to formulate the problems and the proposed solution, the project scope and the project schedule. Next we present 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 efficient working environment. friendly interface for the target stakeholders. Proper monitoring facility for the authority. Easy maintenance and istration. Ensure high level of security. Software Requirements Specification
Page
Online Inventory Management System
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
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 References
www.agilemodeling.com/artifacts/crcModel.html. http://en.wikipedia.org/wiki/Unified_Modeling_Language http://en.wikipedia.org/wiki/Requirements_analysis http://rfptemplates.technologyevaluation.com/rfp/for/inventory-management-garments.html http://www.slideshare.net/ahmedhasan/ieee-830-1998-software-requirements-specifications http://gulnazahmad.hubpages.com/hub/A-Step-by-Step-of-Garment-Manufacturing
1.5 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.
Software Requirements Specification
Page
Online Inventory Management System
The Forth chapter, Requirements Specification section, of this document is written primarily for the developers and describes in technical the details of the functionality of the product. The fifth chapter, Analysis model section. In this section of this document there are some model diagrams. List of all these analysis models used in developing specific requirements . All the sections of the document describe the same software product in its entirety,
2. Stakeholders The stakeholders of the software project are those people or positions who are directly or indirectly affected or effected by the project. The stakeholders and s who are most immediately involved in an Inventory management system can be divided in to four groups, they are: Executives and upper management. Production Controller. Production supervisor. The root level workers. System developers.
2.1 Questioners 1. 2. 3. 4. 5. 6. 7.
How the processes work? Who are the primary and secondary actors of the whole process all through? Who will be the vital actors in the required system? What is the usual working procedure for an order? What are the major flaws that forced you to automated management solution? Will it be more specific in of some major flaws you want us to solve? How will you appreciate the functional facilities as an of the proposed system? 8. Who are the people you want to directly to interact with the system and what should be their domain? 9. What event starts the use case? 10. How does the use case end? 11. Are there any optional situations for the use case? 12. How the processes will work, if the system will become automated?
2.2 Stakeholders view point
Software Requirements Specification
Page
Online Inventory Management System
Different Stakeholders achieve different benefits form a software system. Consequently each of them has a different point of view. So we have to recognize the requirements from multiple view point. For this Inventory management system point of view of stakeholders is:
Executives and upper management beholds the people who are concerned with company management and company’s financial states. They always deal with the profitability and increasing production unit. So their view about the system is how to utilize the system to gain highest profit. Production controller is the people who supervise a part of a production unit. They will interact with our system to input the data of their subordinate workers. Their view point would be to input that information without any kind of difficulties and maintain the private s of each worker
The production supervisors are the people who act as the subordinates of the production controllers, and they must have the real interactions with the root operation. This is not necessary that every supervisor will have distinguished areas to work with; there can be more than one supervisor to supervise a single activity, when it’s a larger one. The supervisors are responsible to check the given input and the outcomes they managed to produce. As these information are required for the operation of our system, production supervisors are identified as one vital stakeholder.
One of the indirect stakeholders of our proposed system is the root level workers of RMG sector, who use to do the primary level jobs of cutting, printing, and combing all the parts together, or any other jobs for example. As because of our limitation of resources, all the workers won’t use our system frequently. But, for occasional possibilities, some of them will use his system, and their illiteracy must be considered by the system developers.
2.3 Collaboration As information from multiple viewpoints is collected, emerging requirements may be inconsistent or may conflict with one another. So considering the scope of feasibility, we have collaborated the following list of requirements from multiple viewpoints. The extracted ideas gathered from the inventory department are:
Online status of item quantity in of on-hand, on-hand available, reserved, ordered, to order, rejected, defective and rework able quantities. Complete excise functionality and generation of excise s. Quality Control based on QC parameters. Physical verification of stock. Purchasing and subcontracting. ing – inventory synchronization. Update delay notification. Keep Track of partial Production.
Software Requirements Specification
Page
Online Inventory Management System
All Financial transactions related to production. . The next steps of this analysis are analyzing credibility and go/ no- go decision making. For these, this team needs more data to be analyzed and communicating with the client. We hope that we will be able to submit the full Functioning paper within a short time.
3. General Description 3.1 Product Perspective In this modern world of commercialization, garments business has been established as one of the flourishing in Bangladesh. It has been one of the most 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 productivity of textile manufacturing. We choose the inventory 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 the old days, RMG sector of Bangladesh has been implementing a variety 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, the need of online 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 the garments industry do have a lot of bugs, functional dependencies and design 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 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.
Software Requirements Specification
Page
Online Inventory Management System
At the same time, there are technologies being used to manage payroll, appointments, inventory, and in many other purposes. But as our major concerns will be inventory oriented, we will focus the most on that.
3.2 Current System Analysis
Figure 1: Current System. The given diagram is a scenario of current system. In the present system, when the sealed the production order then the people related to the production, specially PQ ,’s make the total production planning, and according to the plan the make a check sheet. According to the production planning total production work is divided in to partial productions. These partial productions are the part of total production. Combining this entire partial production element total production take place. But the fact is that in each stage of this partial production face production loses because of manual updating system. They cannot follow the check sheet properly. So they cannot deliver their shipment with in due date. So our client wants a system which can provide automated updating system, accurate calculation of produced goods, provide proper stock information, send notification if the shipment won’t take place on due date, keep track of partial production, and all Financial transactions related to production.
Software Requirements Specification
Page
Online Inventory Management System
3.3 Product Functions Inventory Management System must be designed to meet the dictates of the marketplace and the company's strategic plan. Along with the inventory system Garment industries need some more special attributes. The Software’s for Garment are specially 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 based - based authentication for data protection. Dynamic Modular structure – Each and every section related 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 of client demand
3.4 Potential of the of the System There are two groups of s in our system. They are the production controller and the system maintenance s. 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. : 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 s. In addition, s are responsible to maintain database.
Software Requirements Specification
Page
Online Inventory Management System
3.5 Characteristics The s of the software are classified into two categories – ed and uned . Both s will be able to visit the homepage of the website but only the ed is allowed to give input in the system. To work through the system one should go through some fixed steps
First of all the should be ed. The separate production module will be presented to the as a catalog for viewing. The can browse through the categories to choose the module they desire. The 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. And the process will continue until the shipment is completed
3.6 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 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 of this inventory system will have right to create product, add items delete items etc. The application will provide all information of the 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 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
Software Requirements Specification
Page
Online Inventory Management System
Purchase order entry Receive entry Delivery entry Report
This inventory system also has some dependencies like If data’s are inserted it cannot be deleted except can insert a data but can’t delete If data’s are not inserted, cannot view report. .
4. Requirement Analysis Requirement Analysis presents the requirement specification, software and hardware requirements for both system developers and system s, process model and data model. In this section we specify the External Interface Requirements, functional and nonfunctional requirements of the system.
4.1 External Interface Requirements 4.1.1 Interfaces 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 friendly environment in their system. And the interface makes the system more familiar to its . For our system we do not design an interface yet. But the process is going on. 4.1.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.1.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.1.4 Communications Interfaces All sorts of communications between server and client programs will be using ADO.NET (ActiveX Data Objects for .NET) is a set of computer software components that programmers Software Requirements Specification
Page
Online Inventory Management System
can use to access data and data services. It is a part of the base class library that is included with the Microsoft .NET Framework. It is commonly used by programmers to access and modify data stored in relational database systems, though it can also access data in nonrelational sources and the messaging will be done by XML format.
4.2 Functional Requirements Functional requirements define the functions that are requested by our stakeholders Different functions are needed by different s of the system. Different s have authority to maintain the system. The system specifies the authority of the . The 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. 4.2.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, Sketch Submission: In the garment manufacturing the first step is deg 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 functionality in the system that the can submit a sketch in the system according to their buyer that can available to all the other s of the system. And this sketch will help the to prepare a well-balanced check sheet for the production. Production Pattern: The pattern design is taken for creating 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 one another in reaches or lays that may go over 100 ft. Long and hundreds of plies (fabric pieces) thick. But our system will calculate the amount of fabric pieces to balance it with the check sheet to get 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.
Software Requirements Specification
Page
Online Inventory Management System
Finishing. Packing. These modules contain the database of every worker and supervisor s 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. 4.2.2 Functional Requirements for Production Controller
.
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.
4.2.3 Functional Requirements for Production Supervisor
.
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 supervisors through the system.
Balancing the group input and output.
Submitting the group balance sheet to the responsible controller.
Software Requirements Specification
Page
Online Inventory Management System
4.2.4 Functional Requirements for
.
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
4.2.5 Quality Function Deployment Quality function deployment is a method to transform demands into design quality, to deploy the functions forming quality, and to deploy methods for achieving the design quality into subsystems and component parts, and ultimately to specific elements of the manufacturing process. QFD is designed to help planners focus on characteristics of a new or existing product or service from the viewpoints of market segments, company, or technology-development needs. The technique yields graphs and matrices. QFD helps transform customer needs into 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,
Software Requirements Specification
Page
Online Inventory Management System
4.2.5.1 Normal 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 Inventory System must keep track of all compiled products or resources records, which is expected to generate and must notify 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 authorization of s for security purposes. All the s as well as the 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 can change the existing information.
s 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 external accessibility, between companies or between selected groups. Limited internal accessibility, one module can be maintained and manipulated by one person or one group of responsible employees. Well-structured database to store inventory records.
4.2.5.2 Expected Requirements Expected requirements are those requirements which stakeholders not mentioned 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 friendly interface that will be designed in a manner which implements functionalities that are easily accessible by the s.
The system must ensure database backups, which are as recent and complete as possible
Software Requirements Specification
Page
Online Inventory Management System
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.
4.2.5.3 Exciting 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
Production planning with investment and estimated profit will be calculated through the system.
Normal s and s have to through different page which will ensure that, without 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 s need them.
s can distribute the job segments to the controllers.
4.3 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. 4.3.1 Performance Our proposed inventory management system will be used in Garment industry. There are lot of internal and external operation which are inter-related with each other for fruit full production. So the communication among each end system should be tightly scheduled and the notification should be sent in timely manner. 4.3.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. 4.3.3 Availability
Software Requirements Specification
Page
Online Inventory Management System
This system will be dedicated to a particular client. So the availability will be restricted of this system. 4.3.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. 4.3.5 Maintainability Software maintenance in software 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 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.
4.3.5
Portability
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. 4.3.7 Operational Requirement The system can be viewed by open source Mozilla Firefox. The system is ed by the IIS(Internet information’s system). The team used MsSQL database to develop and maintain the database management systems.
4.3.8 Design 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 deg a system. Sometime clients do not give the proper information which is needed by the team to design software, because of company policies. At that situation software project team start their work without proper overview through the existing system to design new one. Software Requirements Specification
Page
Online Inventory Management System
5. Analysis Models Analysis model is one of the most important parts of SRS. All the models give us clear view of the developing system. In this section, here is the list of all analysis models used in developing specific requirements of the current developing system.
Scenario based model:
Flow Model
Data Flow Diagram.
Class Model:
Use Case Diagram. Activity Diagram. Swim lane Diagram.
Class Diagram. CRC Diagram.
Behavioral model:
State transition Diagram. Sequence Diagram. Collaboration Diagram.
5.1 Scenario Based Model
5.1.1 Use Case diagram In software and systems engineering, a use case is a list of steps, typically defining interactions between a role or actor and a system, to achieve a goal. The actor can be a human or an external system.
Software Requirements Specification
Page
Online Inventory Management System
Initially after analyzing the requirements of our client we notify two potential actors in our proposed system. But this can change any time when their requirements are modified. So in this system normal s 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 2: Use Case Diagram Software Requirements Specification
Page
Online Inventory Management System
On the other hand can change system settings, update operation information, Update production information etc.
5.1.2 Activity Diagram Activity diagrams are graphical representations of workflows of stepwise activities and actions with for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams can be used to describe the business and operational step-by-step workflows of components in a system. An activity diagram shows the overall flow of control.
Software Requirements Specification
Page
Online Inventory Management System
Figure 3: Activity Diagram. 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 to select his/her own authentication. If the logged in as an , the has the authority to select operation between change settings of the working module and update information of the production. On the other hand if the logged in as a production controller, after valid authentication the production controller can give input in the system to ensure the partial production of the total production. In any state of the production if the delay is occurred, production controller can notify istration about the delay to handle shipment related issues.
Software Requirements Specification
Page
Online Inventory Management System
5.1.3 Swim Lane Diagram A swim lane is a visual element used in process flow diagrams, or flowcharts, that visually distinguishes responsibilities for sub-processes of a business process.
Figure 4: Swim Lane diagram This is the swim lane view of our proposed system according to present requirements .System column shows the entire operational function .and and production controller column shows the task that they will do using the system
5.2 Flow model 5.2.1 Data flow diagram A data flow diagram (DFD) is a graphical representation of the "flow" of data through an information system, modeling its process aspects. Often they are a preliminary step used to Software Requirements Specification
Page
Online Inventory Management System
create an overview of the system which can later be elaborated. DFDs can also be used for the visualization of data 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 the timing of processes, or information about whether processes will operate in sequence or in parallel
Figure 5: Data Flow Diagram (Level 0)
Data flow diagram (level 0): DFD level 0 , is the representation of the system which can only shows 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 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 or as notification. And the system also can produce check sheet according to given planning.
Software Requirements Specification
Page
Online Inventory Management System
Figure 6: 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 and planning entity can give input command to the system, which can process by some functions in this system like interact with , configure, and update input, display status. There is a database related with configure function which one can modify production information. And display status, notification, check sheet can produce output depend on all the functions which configure inputs.
Software Requirements Specification
Page
Online Inventory Management System
5.3 Class Model 5.3.1Class 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 the classes.
Figure 7: Class Diagram
In the above exposed diagram ‘Module’ is the parent class which has two child classes ‘’ and ‘Production Controller’. Order Class deals with all the steps related to order and maintained by . ‘Store ‘and ‘Shipment’ class maintained by production controller.
Software Requirements Specification
Page
Online Inventory Management System
5.3.2 Class Responsibility Collaboration Diagram
Figure 8: CRC Diagram A Class Responsibility Collaborator (CRC) model is a collection of standard index cards that have been divided into three sections, Section 1: A class represents a collection of similar objects. Section 2: A responsibility is something that a class knows or does. Section 3: A collaborator is another class that a class interacts with.
Software Requirements Specification
Page
Online Inventory Management System
5.4 Behavioral model 5.4.1 State Representation Diagram
Figure 9: State Representation Diagram. A state diagram is a type of diagram used to describe the behavior of systems. State diagrams require that the system described is composed of a finite number of states; sometimes, this is indeed the case, while at other times this is a reasonable abstraction. Many forms of state diagrams exist, which differ slightly among each other. In the given figure, this is the state representation diagram for our proposed system. In the given figure there are four states, first one “reading state” just read the instructions. Second one “comparing state” compares the given command. When the state compare , if the is invalid, total system will be locked for a while. Or if the is valid it will move a step ahead to select operation what the system allow an .
Software Requirements Specification
Page
Online Inventory Management System
5.4.2 Sequence Diagram
Figure 10: 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 our proposed system’s 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 Command exchanged between the objects needed to carry out the functionality of the scenario.
Software Requirements Specification
Page
Online Inventory Management System
5.4.3 Collaboration Diagram
Figure 11: Collaboration Diagram Collaboration diagrams belong to a group of UML diagrams called Interaction Diagrams. Collaboration diagrams, like Sequence Diagrams, show how objects interact over the course of time. However, instead of showing the sequence of events by the layout on the 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.
Software Requirements Specification
Page
Related Documents c2h70
Online Inventory Management System 3g71v
November 2019 60
Online Inventory Management System 3g71v
December 2019 64
October 2019 249
Smart Inventory Management System 6c56
December 2019 47
Inventory Management System. 3qb4v
April 2020 29
Inventory Management System 1z6v1f
April 2020 15More Documents from "adugnaw azanaw" 343r4r