Requirement specification Customer Relationship Management Software

1. Document History 2. Introduction 1.1 Scope Functionality of CRM soft • • • • • • • • • • • Customer base Product base Customer Enquiry Quotations Customer Purchase Orders Contract Reviews Work Orders generation Invoice generation Billing and Collections Customer Feed Back Reports


1.3Terms and references 3. Functionality of MMSOFT • • • • • • • Material Requisition Supplier Master Supplier Enquiry Comparison Chart Purchase Order Financial Concurrence Reports

4. Quality plan


1. Document History
VERSION DATE DOCUMENT HISTORY 0.1 First draft for prechecking with the customer 1.0 1.1 1.2 2. Introduction 1.1 Scope of CRMSoft Customer related process management soft (CRM soft) provides information for managing the business/sales process, monitor, analyze and improve all the related activities. The most advantageous feature is, all the activities and their respective summary reports are management informative for decision-making, paperless and with least effort. CRM Soft is used to maintain the database of client. This starts from identifying and making a database of all potential customers, their interactions, answering queries, review and sending quotations for products, receiving orders, acceptance of orders, automatic generation of work orders to Design Production, monitoring the work or product process, raising invoices realization of bills through finance department. The main purpose of the project is to develop an integrated marketing module, so that communication across the various departments of the organization becomes easier and maintainable through ERP package (ERP Soft). This module covers all customer queries, raises quotations based on customer enquiry and accepts a purchase order from the customer. Considering the purchase order and quotation a contract review will be generated. If the contract review is accepted then a work order will be generated and hand over to the Production division. The production and dispatch status of the Product will also available with the marketing division. This module can be operated independently and as a module of integrated ERP Soft. Version after prechecking Version after the review Version for protoype II

Flow Chart:



Billing / Collection


Order Execution


Purchase Order

Contract Review Work Order Generation

Customer Product Master Information Transport Insurance


Figure 1: Flow Diagram of CRM Soft


1.2 Functionality Proposed modules and description • • • • • • • • • • • Customer base Product base Customer Enquiry Quotations Customer Purchase Orders Contract Reviews Work Orders generation Invoice generation Billing and Collections Customer Feed Back Reports

Customer Base: A master list of the potential customers is maintained. The common information about the customer like name, address, area etc stored here. The customer information is globally accessed through out the project Customer information will be searched dynamically based on name, code and area. All the information provided in the database should be reflected in the database since it is a master form. Customer information can be updated but deletion is prohibited, else with the approval form the management, since other tables shares the data. Note: The new Customer information will be deleted or the status of the customer will be sleep else active, if the purchase order will not be received within 6 months of quotation.


Product Catalog: The organization produces Rail Testers with different parameters. An independent product master will be maintained which will be accessed by the project dynamically. The user can search the product based on the name and code. Any modification in any of the specification will be considered as a new project. Hence it is recommended using some unique prefix to distinguish the product groups.



Customer Enquiry: The marketing manager receives enquiry from a customer through Telephone, fax, Tenders, Letters etc. The customer may request for a product by modifying the some of the specifications. At that point of time the new product will be generated as per the customer’s request and the information will deliver accordingly. From the Enquiry Interface a link will be provided to the customer form as well as product form. Each enquiry will have Enquiry Number and Date, Customer name and Address, Product code and name, Unit price of the product, Quantity Requested, Discount and Total amount, Delivery period, payment terms, Lead period for Quotation, Delivery point, Remarks However the other implied factors will be intimated in the quotation. A dynamic search option will be provided to search a quotation for a quotation number, for a customer or against a product. The same will be also available for the reports. Considering the financial year all the Enquiry numbers will be generated. As per the conversation with the customer and consulting the finance team it is decided to consider the financial year from 1st of April to 31st of March. So the Enquiry numbers will be generated in the following format (“YY/Enq/MM/001”) for Example: (04/Enq/01/001). The system creates the Enquiry number automatically.


Quotations: Once the enquiry is received the user has to send the quotation after consulting the team within the due period. The quotation can be send through telephonic conversation, email, fax, letter etc. The enquiries can be clubbed together and send a single quotation for the same.(customer wise enquiry) The following information will be maintain for a quotation Quotation No, Date, Enquiry No, Date, Customer Information, Product code, Product Name, UOM, Unit Price, Quantity, Discount, Amount, Delivery Date, Total Price, APGST, CST, Excise Duty, Freight, Insurance, Others, Grand Total, Payment mode, Payment Terms, Dispatch mode, Delivery Point, Remarks. The user may split the products in to two types in the same quotation based on the customer request, delivery date and other implied factors. Hence duplicate product selection should be provided. Using the dynamic search option the user can search the quotation information by quotation number, customer and product information. As like the Enquiry Quotation numbers will be generated. The system will generate the quotation numbers in the following manner. “YY/Qt/MM/001” for example: (04/Qt/01/001). The system creates the Enquiry number automatically. Once the quotation is raised against an enquiry that enquiry information will not display in the enquiry list. Their may be a commercial and product specification negotiation between the customer and the organization, in such cases the user will send a revised quotation / update the quotation information to match with the customer purchase order. i.e. a new quotation number will be generated and the old quotation number will also available in the old quotation.


Customer Purchase Order: On satisfactory acceptance of quotation, the customer places a purchase order. The Purchase order may receive based on the quotation / telephonic conversation. The customer may send the Purchase order after a telephonic conversation, hence in this case Enquiry plays a vital role, i.e. Enquiry information will be considered as the quotation. The user has to simply enter the purchase order information. Purchase order Interface consists, PONo, Date, EnqNo, date, QtNo, date, Customer Name Address, (Header) Product Code, Name, UOM, UP, Qty, Total Price, Delivery Date, Status(in a Grid) Requirement Type ( Normal , Urgent) Grant Total, APGST, CST, Excise Duty, Freight, Insurance, Other Load Factors, Grant Total, Pay mode, Payment Terms, Guarantor name, Dispatch Mode, Delivery place, Remarks. The customer may amend the Purchase Order after raising the purchase order, in such case there should be a provision to update the purchase order information.


Contract Review: A review will be made for each product in the PO. The user can negotiate the commercial and functional parameters like price, quantity, Unit price, Delivery schedule, pH factor, viscosity etc. If the user likes to modify the quotation at the time of contract review he should be permitted with the auto generation of a revised quotation, which will be considered for further processing of the orders. The user will select the Purchase order Number, considering which all the information like Quotation No, date, Customer and product information will be retrieved and he has to check the commercial and functional parameters for each product and decide to accept / reject of the order. If the order is accepted a draft work order will be generated automatically for the same. This will be converted into work order (consolidated) in the next step. Once the review is done the product name will exclude from the P.O. product list and if all products are reviewed the complete Purchase order will exclude from the PO list i.e. only the pending Purchase orders will display in the list.


Work order Generation: The user will raise the work orders product wise and handed over to the production department with the product specifications. The user will select a Product name and all the draft work orders will display. The user will check the Work orders and prepare a consolidated work order, which will be easy for bulk production. The work order can be search dynamically by customer wise, product wise, within a period. The same may be available for the report generation. The work order will contain the WoNo, Date, P.O. No, Date, Order Mode, Product code, Name, Specification, Qty, UOM, Delivery Date. Requirement (Urgent/ Normal), Remarks.


The work order No will be generated by the system, with the following format (“YY/wo/MM/0001”) i.e. “04/wo/11/0001” , The numbers will be generated based on a financial year, i.e 0001 will be the first work order generated on 1st of April of every year.

Invoice Generation: Marketing department raise the invoice at the time of order execution, with to the finance department consultation. The invoice contains the same information For all accepted orders an Invoice is raised and send to the customer along with the product. The invoice will have following information(s), i.e. Invoice Number and Date, Purchase order Number and Date, Date of Dispatch, Customer Information, Product Details, Quantity send, Price details etc. Tax information and insurance. The invoice may or may not be included in the insurance list. Hence If value is zero then it will not be included in the insurance list. Using the dynamic search option the user can retrieve the information about the work order requested / generated from a customer, periodically, area wise etc.


Bills / Collection: The marketing department takes care of collections. Once the order is executed and invoice is raised the invoice amount will be credited to the customer account. The user will send a request to finance department to raise the bill and update the invoice collection amount. The system will generate the pending collection reports once the invoice cross the due date, so that the marketing department will make a follow up to the sundry creditors. Dynamic search option will help the user to get the information based on a product, customer, Area, periodically etc, so that it will be better to monitor the information to the management accordingly.


Reports will be generated based on daily collection, customer wise invoice realization and pending amount, Area wise collection / pending list, collection within a period / pending.

Customer Feed Back: A feedback from the customer is taken based on the business completed. This is stored and reviewed periodically. This gives the input for improvement in our products and services.

Reports: • • Enquiries received Quotations sent


• • • • • •

Orders received Progress on the orders Product Status Feed back received Sales / Order Execution Master Reports (Customer, Product, Transport, Insurance)

The reports can be obtained by <a> Customer Wise <b> product wise, <c> period or any other condition with in the framework of data base designed (ie like area, dealer etc.).

1.3 Terms and references CRM: Customer Relationship Management LOC: Lines of code LUCOS: is a three-year project which goals are to develop a method for improving the controllability of product development, as well as tools supporting the method. BUG: A inconsistency or an error in a written document (source code or otherwise) that can lead to an observable failure or misunderstanding. GROUP: A certain number of people, in this course currently defined as being 4-7 people. INPUT FORM: A form viewable by browsers that takes input from the user, the data can be sent to the server that created the form.


FORM GENERATOR: A piece of software that creates a browser viewable page from a separate form description language (see configuration files). FRAMEWORK: The basic structure of the software system itself. SCRIPT: A set of commands that can be executed on a computer, scripts are interpreted from source code CONFIGURATION FILES: The files that can be sent through a form generator to create a form. EXPORTED DATA: Data that is extracted from somewhere e.g. a database and converted into another format if necessary. DATABASE: A place where permanent data is stored. 3. Quality plan Goal Functionality Description Good quality of the framework = produces robust, bug free software which contains all necessary requirements Documentation If used in other projects documentation is of real value All the required documents will be produced with a good level of English language. Source code will be commented = produces consistent, easy to read documentation Modularity Simplicity of system architecture Independence of code modules = produces a system that is easy to update and maintain Customer satisfaction 8 Customer satisfaction Customer satisfaction Evaluation metrics 10 Priority




Is part of the code going to be used elsewhere = produces simple and independent code modules that can be reused Customer satisfaction



How general the form generation language is Simplicity vs. functionality of the form language = Speeds up form development but does not limit functionality Customer satisfaction



Effective, clear = simplify communications internally and with customers

Customer satisfaction and internal acceptance. Following deadlines, evaluation of effectiveness in reviews.



Can some tasks be late? (Overwhelming workload on certain tasks) = Reduces some risks


Working methods & Tools of the group Scalability

= can significantly speed up development time Internal acceptance


Simultaneous users, if not this course what about other? = produces multi-user proof software

Passing of scalability tests and customer satisfaction Testing the outputted pages on


Browser independence

What restricts the usage of browsers?


different browsers How to evaluate at the end of the course the results in relation with the quality plan? The goals have a priority which goes from 10 to 1, from the most important to the less important.


The overall of the course could be evaluated in the following way: Each goal is given a grade which goes from 0 to 10 Then that grade is multiplied by its priority in the table After doing the same with all the goals, they are added together and divided by 5.5 this way is possible to get a percentage of how the quality plan has been accomplished. For example: let's suppose that the group gets a 5 in each of the goals of the quality plan, this would mean that in average the overall of the project group has met 50% of the initial requirements. The total of the points in this case would be 275, then 275/5.5 = 50 (50%)


Sign up to vote on this title
UsefulNot useful