1. Introduction
The fashion belts Company is the leather belt manufacturer located in Northamptonshir and developed from the conventional boot and shoe industry present there. However, the recent owner of the company is the New Zealand couple who bought the company six years back where they observed for the high quality leather belts in the flourishing consumer market (Clegg & Barker, 1994). In the manufacturing workshop, the operations are performed in the sequential manner with the leather arriving at one end of the building and different production stages following each other round the building. In the shop, there are several machinists where the belts are stitched and sown while the supervisor carries the buckles and studs to the machinists for their stage of process and at the end, the completed belts are dispatched from the workshop (Sundar, 2010). The management of the fashion belts is concerned to make sure that customer orders are processed effectively and correctly and hence asked the team to provide initial report, which evaluates the requirements of the customer order processing system (COPS)(Kulak & Guiney, 2004).
However, with the evaluation of the report the company Fashion belts intending the confirmation of the managing director for placing the contract with the company to develop the COPS system (Shelly et al., 2009). It is observed that the rapid application development is the system development methodology that assists joint application design by acquiring user input, prototyping and utilizing case technology to accelerate the effective system design (Shelly et al., 2009). The rapid application development approach assists the system developers to encourage fast, effective, correct system development and delivery. The RAD involves enhanced user communication, user cooperation, user commitment and encourages better documentation of the system with the utilization of effective tools (Wang & Wang, 2012). The report provides the illustration of functional and non-functional requirements related to COPS development as well as describes categories of prototype required to be developed along with description of user classes that will be involved in the development of system, draw class and user case diagram.
Section 2 A Requirements Catalogue
The requirements catalogue is comprised of functional and non-functional requirements for the development of customer order processing system, which are analyzed and illustrated as follows:
2.1 Functional Requirements
It is observed that the functional requirements describe about the function of the software system and its components where the function illustrate as the collection of input, behaviors and outputs (Aurum & Wohlin, 2005). The functional requirements can be technical details, data manipulation and processing as well as other particular functionality, which defines that what the system is supposed to attain. It is effective to differentiate between the baseline functionality essential for the system to compete in that system domain and features which distinguish the system of the company from its competitors to acquire business productivity (Kulak & Guiney, 2004). The functional requirement includes the functions performed by the particular screens, outlines of workflows performed by the system and other business requirements of the system should be fulfilled (Shelly et al., 2009).
2.1.1 System Interface Requirements
The system is required to contain the belt information, which is based on style describing the overall style description. The system should also provide the description of thickness and width of belt strap (Aurum & Wohlin, 2005). The system should also describe about different components including belt strap, buckle, and studs where only particular combination of components can be taken place for each belt design. The user for more than one belt while ordering where the combination being exactly determined by the strap material can utilize the similar components (Chung et al., 2000). The system must provide unique design number for each belt design with the demonstration of three types of belts including large, medium, and small. Therefore, in order to place the order with unique order number for the belt the system needs to provide the design number, the color and its length description to the customer order system users and these details will be provided in the belt specification section (Clegg & Barker, 1994). The orders within the system must always be recorded on the standard format of FB/1 order form as demonstrated in the appendix, which should be uniquely numbered(Kulak & Guiney, 2004).
However, each order provide information concerning the belt design number , belt color , length of belt , belt style and the quantity for each belt ordered by the users(Shelly et al., 2009). Once the order is placed the sales staff then ensures that the order can be met in full by the required date using the system while the sales department retains the copy of the order form on which they log the process of order (Shelly et al., 2009). The orders within the systems should always be completely dispatched where the price of each belt is can be determined by the design of belt. The customers can ask for several distinct belts on the similar order therefore the system should be capable to meet this requirement of users where the payment for the order can be outstanding to the final demand letter, which is sent to the customers (Kulak & Guiney, 2004). The customer order processing system should also contain section where the customer complaint along with the information concerning the department that is dealing with the compliant is provided. The system should provide daily reports to different acknowledged department to demonstrate the complaints that have been passed to them(Shelly et al., 2009).
2.1.2 Business Requirements
The business requirements includes that the new customer order processing system should have the volume of throughput as follows:
- The COP system should acquire 600 sales orders per day while the acceptable range can be vary in between 550 to 650(Aurum & Wohlin, 2005).
- The system should conduct 10 complaints reports per day.
- The new system should conduct final demand per day where the acceptable range lies between 25 and 35 and the final demand must be printed on the relevant company headed forms(Kulak & Guiney, 2004)
- The customer order processing system is required to be able to print all the forms at the rate of 10 per minutes while the lower limit of eight per minute is acceptable for the final demands (Shelly et al., 2009).
2.1.3 Compliance Requirements
The new customer order processing system is required to have functional audit trail on the continual basis. However, the new system is also required to restrict access to the authorized users and based on privileges provided to them(Sundar, 2010). For the effective compliance of the system, all the data should be secured with electronic signatures. The customers are required to insert their correct id and password in order to login into the system(Clegg & Barker, 1994).
2.1.4 Security Requirements
The customer order processing system should provide different access levels where the system should be capable to report only update only, complete system access based on the privileges provided to the particular users of the system(Shelly et al., 2009). For instance , the administrator of the system should have complete system access including creating , reporting and updating orders(Chung et al., 2000). However, the general staff is required to be able to report different departments concerning complaints. On the other hand, the system is required to be implemented on the local area network of the company and to ensure the data security all the data should be encrypted and backup effectively(Aurum & Wohlin, 2005).
2.2 Non Functional Requirements
It is observed that the non functional requirements describes the particular criteria which can be utilized to judge the operations of the system somewhat than particular behaviors and it is usually considered as qualities of the system(Clegg & Barker, 1994). However, the qualities of the non-functional requirements are analyzed as follows: (Aurum & Wohlin, 2005)
2.2.1 Availability
The availability is the amount of time on which the system is available for use and it is required that COP system should be available to the user all the time with expected downtime during the activities of database upgrades and backups(Kulak & Guiney, 2004).
2.2.2 Flexibility
The new system should be flexible enough to be extended to meet the future requirements and does not negatively influence the design, development, testing and testing of the system(Sundar, 2010).
2.2.3 Reliability
The system should be reliable enough to maintain its performance with the passage of time and should not be sensitive to malfunction while performing ordering tasks(Chung et al., 2000).
2.2.4 Scalability
The new system should be capable to be scalable and handling several system configuration sizes by enhancing hardware capacity and additional software(Clegg & Barker, 1994).
2.2.5 Usability
The system should provide effective ease of use to the system users by addressing the factors, which make up the capacity of the software to be understood, learned, and utilized by users(Sundar, 2010).
Section 3 Categories of Prototype To Be Developed
It is observed that with the new system development there comes particular level of ambiguities concerning whether the system will be able to meet and establishment the requirements of systems users(Sundar, 2010). Hence, to assist in this aspect the prototype is made which is conventionally the test version of the system design, which verifies the mistakes and drafts the final system solution. Usually prototypes are categorized on different aspects to acquire essential adjustments within the resulting system until it meets the required standard and user expectations. However, since prototypes are usually utilized interchangeably therefore it is considered in terms of categories surrounding their functions for system development(Clegg & Barker, 1994).
Proof of Concept Prototype
For the development of new customer order processing system, the RAD approach will be adopted as the RAD approaches effectively replaces the design and coding processes of system development which dependents upon the skills of isolated individuals where the automated design and coding utilized by RAD is inherently more stable process which give opportunity of continuous improvement(Clegg & Barker, 1994). While, the JAD workshop approach assist the team comprised of end users of the system, management and IT staff to conduct effective meetings for discussing and defining the project solution in different workshop sessions(Chung et al., 2000). Since, the team also includes the actual users of the system therefore the system analyst capable to acquire the better picture of the system that what the client is interested to get within their new system. The rapid computer aided software engineering (CASE) tools is also used during the rapid application development approaches in order to effectively and clearly understand the whole software engineering process(Shelly et al., 2009). On the other hand, it is observed that since rapid application development approaches emphasizes on speed therefore consistency and reliability can be overlooked which requires giving significant considerations in these aspect while developing customer order processing system(Clegg & Barker, 1994).
Feasibility Prototype
The system will be implemented on the company local area network which will accepts the users input to place the order with different privilege user access levels where the system administrator will have complete access of system with insertion , deletion , modification and reporting rights(Aurum & Wohlin, 2005). The system will have product form where all the information related to different belts of company will be provided which includes unique belt design number, length, color, and overall belt style description. The order form will be made on the specified standard of fashion belt FB/1 order form that will contain the unique order number, design number, belt color, belt length, belt style, quantity option for each ordered belt(Chung et al., 2000). The order form will also contain order placement, order confirmation and order completed status while the form will also contain the general information regarding customer which includes customer name, address , postcode , telephone number , customer contact , order date , expected delivery date , actual delivery date , payment due date and payment received(Clegg & Barker, 1994). However, the order and payment details will also be printed out from the system. The system will intend to provide minimum 600 orders, 10 complaints, and 35 final demands per day. The system will provide header form for individual company to send the final demands(Sundar, 2010).
Horizontal or User Interface Prototype
The user interface prototype is the demonstration of whole system to illustrate its usage of windows dialogue boxes, labels, text boxes, menus, screens, reports, and forms. The user interface design of the COP system is demonstrated as follows:(Kulak & Guiney, 2004)
Figure 2: Sales Order Form
Functional Prototype
The functional prototype is used for modeling the business function to describe the user interface and flow of system application where the storyboard functional prototypes demonstrates the screen that are required to build for the application which is being prototyped(Wang & Wang, 2012).
3.1 The Classes of Users to Be Involved In Development
The users of the systems make sure that the system is meeting its both functional and non-functional requirements. The major classes of the users that are involved in the development of customer order processing system includes:(Kulak & Guiney, 2004)
3.1.1 System Analyst
The system analyst of the COP will be responsible in understanding the system and analyzing the user requirements and prioritize it. The system analyst will also analyze the resource constraints for the development of system(Aurum & Wohlin, 2005).
3.1.2 System Designer
The system designers of the customer order processing system will have the responsibility to provide the architectural design that will offer the fundamental framework to the system developers(Clegg & Barker, 1994).
3.1.3 System Developers
The system developers will have the responsibility to build the system based on the specifications of users and systems analyst by utilizing advanced system development tools(Kulak & Guiney, 2004). The system developer will write the codes of the system design(Wang & Wang, 2012).
3.1.4 Quality Assurance Engineers and System Testers
The system testers will test the faults and errors within the functionality, user interface and coding of the system development to make sure that the COP system is meeting the specified functional and non-functional user requirements(Shelly et al., 2009). The SQA engineer will review the design before finalizing the in terms of usability and user experience aspects(Sundar, 2010).
3.1.5 End Users and Management of Company
The customers and management of the company will check the user convenience of system at different levels of system development to ensure that the system is meeting all the customer user experience and business requirements of the Company management(Chung et al., 2000).