Product stock management_synopsis


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Product stock management_synopsis

  1. 1. Product Stock Management SYNOPSIS:INTRODUCTION: The project entitled PRODUCT STOCK MANAGEMENT is to maintain the stock inthe warehouse.PROJECT: PRODUCT STOCK MANAGEMENT is a software application maintaing the recordsrelated to goods in, goods out and stock.OBJECTIVE: The main objective of the application is to automate the existing system of manuallymaintaing the records of the goods in, goods out and stock.SCOPE: This application can be used by any warehouse to maintain the stock record.PROBLEM DEFINITION: The transactions related to Goods In, Good Out and returns are maintainedmanually at present along with maintaining the accounts of the customers and thesuppliers. All these are to be automated and an application is required to relate all of themrelatively and logically so that the current system can be replaced and accepted withoutmajor changes and problems. The application should provide quick access to the records maintained and mustreveal the important reviews about the business so that the growth can be easilycompared and should provide with the various reports showing the related details so thatthe important decisions could be taken easily.
  2. 2. SOFTWARE REQUIREMENT SPECIFICATION:An SRS is basically an organizations understanding (in writing) of a customer or potentialclients system requirements and dependencies at a particular point in time (usually) priorto any actual design or development work. Its a two-way insurance policy that assuresthat both the client and the organization understand the others requirements from thatperspective at a given point in time.The SRS document itself states in precise and explicit language those functions andcapabilities a software system must provide, as well as states any required constraints bywhich the system must abide. The SRS also functions as a blueprint for completing aproject with as little cost growth as possible. The SRS is often referred to as the "parent"document because all subsequent project management documents, such as designspecifications, statements of work, software architecture specifications, testing andvalidation plans, and documentation plans, are related to it.Its important to note that an SRS contains functional and nonfunctional requirements only;it doesnt offer design suggestions, possible solutions to technology or business issues, orany other information other than what the development team understands the customerssystem requirements to be.A well-designed, well-written SRS accomplishes four major goals: • It provides feedback to the customer. An SRS is the customers assurance that the development organization understands the issues or problems to be solved and the software behavior necessary to address those problems. Therefore, the SRS should be written in natural language, in an unambiguous manner that may also include charts, tables, data flow diagrams, decision tables, and so on. • It decomposes the problem into component parts. The simple act of writing down software requirements in a well-designed format organizes information, places borders around the problem, solidifies ideas, and helps break down the problem into its component parts in an orderly fashion. • It serves as an input to the design specification. As mentioned previously, the SRS serves as the parent document to subsequent documents, such as the software design specification and statement of work. Therefore, the SRS must contain sufficient detail in the functional system requirements so that a design solution can be devised. • It serves as a product validation check. The SRS also serves as the parent document for testing and validation strategies that will be applied to the requirements for verification.SRS are typically developed during the first stages of "Requirements Development," whichis the initial product development phase in which information is gathered about whatrequirements are needed--and not. This information-gathering stage can include onsitevisits, questionnaires, surveys, interviews, and perhaps a return-on-investment (ROI)
  3. 3. analysis or needs analysis of the customer or clients current business environment. Theactual specification, then, is written after the requirements have been gathered andanalyzed.The National Bureau of Standards, IEEE (Standard No: 830-1984), and the U.SDepartment of Defense have all proposed candidate formats for software requirementsspecifications. The general structure is implemented with the related software applicationINTRODUCTION: The project entitled PRODUCT STOCK MANAGEMENT is developed as part ofthe VI Semester RDBMS package project for the partial fulfillment of the BCA degree. It isa software application maintaing the records related to all the transactions occurring at thecounter of a shop.OBJECTIVE: The main objective is to maintain the inventory records of a generic shop which dealsin musical tapes. • To keep accounts of Goods in, Goods Out • To know the current position of the Stock • Transaction report • Stock maintenanceSCOPE: As this is generic software it can be used by a wide variety of outlets (Retailers andWholesalers) to automate the process of manually maintaining the records related to thesubject of maintaining the stock and material flows.GOAL: The main goal of the application is to maintain the records of stock, billing, details ofIn, Out of the product and their current stock positions with the company.
  4. 4. Hardware RequirementsProcessor : Pentium IV 2GHz and AboveRAM : 2GB RAMMonitor : 15” Color MonitorKeyboardMouseSoftware RequirementsOperating System. : Windows XPDeveloping Tool : Visual Basic 6.0Database : MS Access