The main focus of this report is to inform of the progresses made until now and to discuss on the situations beyond the initial JAD Workshop that has already held.
This report will be given to Mr. B. Hudson who is the managing director of Designer Belts Ltd. Designer Belts Ltd is a leather belt manufacturer based in Bedfordshire.
The management of Designer Belts Ltd. wants the customer orders that are processed efficiently and accurately with providing with high quality leather belts in the booming consumer market.
This report is trying to provide analysis of the requirements of Customer Order Processing System (COPS).
This report will contain 6 sections in total. Section 1 is Introduction which will describe summary of why the report is being produced and what are included in the report. Section 2 will contain A Requirement Catalogue that is showing functional requirements and non-functional requirements altogether required when COPS implements. Section 3 will provide Description of the Categories of Prototype that will be developed to check that the requirements are fulfil or not by the management. Section 4 and 5 will contain Class Diagram and Use Case Diagram trying to discuss the transactions occurs inside the company. Section 6 will be Conclusion.
What is Customer Order Processing System (COPS)?
In traditional most customers' orders come via phone or fax. They are manual and time consuming. Sometimes they make some mistakes that usually take a lot of time in week ends to correct. Then we will need to automate these processes. The solution is customer order processing system.
Designer Belt Ltd always wants to promote better customer satisfaction. Then the management decided to develop a customer order processing system (COPS).
The main purpose of this project is to analysis to develop and apply a customer order processing system to provide the features of order management, order creation, order processing, customer management etc.
Benefits of Customer Order Processing System
Faster in order process
Faster and better order management
Reduce time consuming
Reduce cost per sales order
Quick audit in sale order
More satisfied customers and more
We will focus the analysis in the aspect of Dynamic System Development (DSDM) frameworks that is already agreed in the JAD workshops.
Section 2
A Requirement catalogue
2.1 Functional Requirements
The functional requirements of the systems are providing in the following tables:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req01
Functional Requirement: Create Order
Customer makes order to sale person. Each order details contain design number, the belt colour, the length of belt, the style of belt and the quality of each belt ordered.
Non-Functional Requirement:
Description:
Target Value:
600 Sales Orders per day
Acceptable Rage:
550 -650 Sale Orders per day
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req02
Functional Requirement: Verify and accept customer payment
After customer made order, he or she will verify and accept the information of the payment for the order(s)
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req03
Functional Requirement: Give shipping Information
After verifying the customer payment, customer gives the shipping information
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req04
Functional Requirement: Give Payment Information
After given shipping information, customer gives the payment information
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req05
Functional Requirement: Inform workshop about order
After completion of order creation, sale person inform workshop about order(s)
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req06
Functional Requirement: Update order status
Sale person updates order status
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req07
Functional Requirement: Retain order form copy
After sale staff confirms an order, sale person retains order form copy
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req08
Functional Requirement: Update order progress
Supervisor update order progress to sale person and managing director
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req09
Functional Requirement: Log order progress
Sale person log the progress of the order.
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req010
Functional Requirement: Generate order progress daily report
To make sure the order in progress, order progress daily report is generated daily
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req11
Functional Requirement: Confirm order
Sale person confirm require date to customer
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req12
Functional Requirement: Send invoice
Sale person send initial payment letter to customer to give payment to the order
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req13
Functional Requirement: Accept initial payment
After receiving initial payment letter from Designer Belt Ltd, customer give payment for the order
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req14
Functional Requirement: Generate Final Demand Letter
If the payment of the order is outstanding, a final demand letter is sent to the customer.
Non-Functional Requirement: Final demand letters must be printed with the company headed forms
Description:
Target Value:
35 Final Demand Letter per day
Acceptable Rage:
25-35 Final Demand Letter per day
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req15
Functional Requirement: Accept final payment
After receiving final demand letter, customer paid the order finally
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req16
Functional Requirement: Accept customer complaints
The department that deals with complaints accepts customers' complaints
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req17
Functional Requirement: Record Customer Complaints
The department record customer complaints that are dealt with them. Sometimes customers' complaints may be dealt with more than one department. Then each department produce a daily report that shows the complaints that are dealt with them
Non-Functional Requirement:
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: Req18
Functional Requirement: Produce Daily Complaint Report
The department produce daily complaint report that has been passed to them. A complaint letter may be dealt with by more than one department.
Non-Functional Requirement:
Description:
Target Value:
10 Reports per day
Acceptable Rage:
2.2 Non Functional Requirements
Non function requirements of the system are providing in the following tables:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: NReq01
Non-Functional Requirement: Levels of access
Report only: sale department, other departments
Update only: sale person, sale department
Complete System Access: system administrator
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: NReq02
Non-Functional Requirement: System architecture
The system should implement on the company local area network (LAN)
The system should be developed in Microsoft Visual Basic and Microsoft Access
All data should be encrypted
Description:
Target Value:
Acceptable Rage:
Source: Customer Order Processing System (COPS)
Sign Off: Customer Order Processing System (COPS)
Requirement ID: NReq03
Non-Functional Requirement: Print out of orders, daily reports and final demand letters
The system should be able to print orders forms, daily complaints reports and final demand letters.
Description:
Target Value:
10 per minute
Acceptable Rage:
8 per minute of final demand letter
Section 3
Categories of prototype to be developed in the development
According to Dynamic System Development Methodology, we need to go to construct prototypes. Prototype is an important stage in the framework supported by DSDM approach for the development.
Constructing prototypes aims to audition our ideas through several prototypes and decide together what system should meets the needs of the management to produce a better final system.
A prototype allows stakeholders to interact with an envisioned product, to gain some experience of using it in a realistic setting, and to explore imagined uses. [1]
According to DSDM Consortium, there are four main types of prototypes. They are
Business prototype
Usability prototype
Performance and Capacity prototype
Capability / Technique prototype
Even there are several types of prototype; we will not construct all types of these. It is shown prototyping in logical. We will need to construct one physical prototype that might cover some of these categories. Let's see inside in a few of these categories:
Business prototypes aim to show the business processes that are being automated. They try to express functional requirements of purposed system to developers and they also show the users how final system could operate to compare with the needs of their business. The business prototype aims to show the business processes that are covered by the system. The business prototype will not deal with secondary functionality and user interface. We could use "Create Order" prototype to design and display the functionality of creating customer orders into order table in the database as a business prototype.
After the developing of business prototype, then we need to turn to Usability prototypes to ensure the system is easy to use and enjoyable. Usability prototypes try to shape the interface functionality but they will not aim at the process in automation. We should perform Usability prototypes before doing of Performance and Capacity prototype.
After Usability prototypes are being performed or running continuously, we can also emphasize in prototyping of performance and capacity prototype. Performance and Capacity prototype are dealing with non functional requirements of the systems. We can identify and test the non functional requirements of the Customer Order Processing System (COPS) such as amount of reports letters within one minute etc.
Capability/ Technique prototype tries to provide the developers a particular design approach and tool to help in choosing of approach, technique or tool for design phase.
We will provide a prototype to demonstrate the processes and functions of purpose system (COPS) to compare and check with the requirements of the management as well as the system users.
Figure 1 is functional prototype for New Customer Registration to create new account into Customer Order Processing System (COPS)
Figure Customer Registration From for new customer
Figure 2 shows Functional prototype of Order Registration Form to create new order.
Figure Order registration form
Figure 3 is a prototype for Create New Complaint
Figure Form for Create New Complaint
3.1 The classes of users to be involved in development
A skill common to all roles is that of effective communication. Developers of all types must be able to listen effectively and communicate their ideas in non-technical language. Users must be competent in expressing their own needs and the vision of the business (J. Stapleton, 1997)
As we are following the framework of Dynamic System Development Method (DSDM), the participation of users throughout the development stages is very important to develop the system successfully. Success and failure of system is depending upon it as well. So I would like to request you the following users to participate along through the development stages.
Executive Sponsor (Managing Director)
Sale Person
Supervisor
Customer Representative
Executive sponsor (Managing Director)
Executive sponsor or managing director of designer belt ltd will need to involve in the development. The participation of managing director as an executive sponsor is very important. They are only users who can decide what kind of system should be developed or what features should include in the system. The management's suggestions and recommendations is critical in the time of designing of report design, complain report design. They can decide what features should include in their related report designs.
Sale Person
Sale person is one of the main users of system. Sale person can give certain knowledge of order processing, customer relationships and day-to-day basis being automated. They are very useful in analysis and design of the purpose system. Sale person's suggestions and recommendations are very useful in developing prototypes such as order registration, customer registration, order progress daily report, complaints daily reports and so on.
Supervisor
In general, the main purpose of supervisor's role is to supervise the belts production. Therefore the supervisor can give a lot of knowledge and suggestions about product details for ordering being automated. Supervisor also can give useful suggestions and recommendations in prototyping stages such as order registration, order progress daily report etc.
Customer Representative
Customer representative can give knowledge of high level view such as what functions should include in the system. Customer representative can also advise and suggest in prototyping stages to produce successful system development that meets the needs of users. Their involvement is important to produce a reliable system. Their suggestion and recommendations are very important to identify the system reliability.
Section 4
Class Diagram
Class Diagram.jpg
Section 5
Use Case Diagram
Use Case diagram describing Designer Belt's environment
Order Processes Use Case
Order Progress Use Case
Generate Final Demand Letter Use Case
Produce Daily Complaints Report Use Case
Section 6
Conclusion
This report showed you the functional requirements and non functional requirements of the purposed system (COPS). This report highly stress requirement analysis with the use of powerful UML tools such as Class Diagram and Use Case which show what the system should performs and who are the system users. This report also showed functional prototypes of customer registration and order creation. I believe this report is clear and understandable for you. I highly acknowledge the active participation of you and your people. Without them, this report will not finish completely and perfectly.
After we agree over matters that contains in this report in coming few days, we will go to Design and Build Iteration Stage containing in DSDM framework. After all, we go to implementation stage.
I am hoping the successful system development as we get active user involvements especially the involvement of the management.
Throughout all coming stages, as I mentioned, the managing director's participation will highly need for the development of successful system.
