Requirements and Specification: Customer Order Entry System - Term Paper Example

Requirements & Specification: Customer Order Entry System Name: Institution: Software Requirements Specification: Version 1.0 1 Introduction 1.1. Application: summary, Scope and Objectives This is a Customer Order Entry System (COES), which incorporates order entry and a checkout model. The system will offer the functionality of taking order entries and reviewing them – with respective Admin options for better maintenance and performance. The system describes the COES’ “Functionality, Usability, Reliability, Performance and Supportability (FRUPS).” The system will offer a document template repository to all clients, for their order entries – so they can retrieve the information – in the future or during maintenance of historic data (Harwell, 1997). 1.2. Need for the application The application will offer a robust, user-friendly order entry model – which offers seamless integration with current internal order management systems (Wiegers, 2001). 1.3. Purpose of the Document This outline explains the needs order entry system for customers. This will document the desired input-output for the COES. The document will serve as a guide for future integration with the earlier systems of COES functions (Harwell, 1997). 1.4. Vision/ Views of the technical principal/ project sponsor This will offer a platform for the improvement of customer order entry models – offering an end to end solution to customers, for order entry, recording and details management. This application is part to a loosely bound system – which presents other internal systems for integration into the COES system (Harwell, 1997). 2 Application Environments 2.1 Technology environment a). Windows XP, Windows 2003 b) Net 2005, Visual Studio, SQL Server 2000-2005, Framework 3.0, JavaScript, DHTML, HTML, Web Services. 2.2 Security System VPN entrance to the application through an external network along with a user_id/password for the application process and for the users who access it from a LAN, user_id/password – where authentication is executed. The application offers a secure FTP location password security-based check, over userid’s and passwords (Wiegers, 2001). 2.3 External interfaces Not valid for this stage, but will be incorporated into future phases 2.3.1 Hardware Interfaces: N/A 2.3.2 Software Interface USPS web service: This will be useful for the on-line verification of customer data. COES: Order entry services which will be developed further. 2.3.3 Communication interface Protocol used: SOAP over the SMTP, HTTP, TCP/IP 3. Functional Description 3.1 Process/ Function Description The application is divided in two main components: 3.1.1 User/ Guest User section There is a standard course system to be followed by users. The system shall have pages with a pool of canned order definitions i.e. predefined customer order definitions to select from during order entry – to have the order registered. The order pre-definitions will have different parameters for products, prices, quantity and product quality among others. Details will be presented at the price-calculate sheet (Harwell, 1997). The system comprises of a complete Order Entry workflow – where there are different order states and screens. The orders typically have 4 states: Order initiation: where order entry is initiated – various attributes from where a customer can select the purchases needed, and then move to the next step. This step is compulsory during the order entry course. Order Fulfillment: At this stage, the order is provided by data. The core business of the company is to have online order entry – so the order can be attached to a document. This step can be skipped – but later completed. This stage is very important in the initiation of the ordering process (Harwell, 1997). Order proofing and Verification: This is the state where orders are proofed and verified. The proofing and cropping functions are very important – for the validation of the order details entered. The basic infrastructure for this tool has been offered, but will be refined in future phases. Order Confirmation: At this stage, the order is completed and verified. Following the verification, the user is charged according to the pricing outline, and their credit card details, which are validated through (Verisign). The gateway is vital for the verification of credit card information. The system will offer a customer workbench for registered users, where customers will get the privilege of managing their order information: track orders or reuse the saved data for future orders. This section will also offer a settings profile, where the customer can turn the notification system on or off (Harwell, 1997). 3.1.2 Admin Admin section The administrator section will have an administrator workbench – from where they can view and revise, user information and process orders, as well as offer order management for users. An administrator workbench for making required system and system artifact changes will be managed by administrators. 3.1.3 Order document Library Order document Library: this is a very explicit segment for order details, which will be available to users. For this segment, all registered users will control a space of 1 GB, while guest users will control 15-30 Kb space. The users will receive regular reminders upon registration and returning to the system. The user space will be developed, on the basis of the user’s id and date – which will be created based on user ids. Context Diagram showing the main actors and the business of the COES system Context diagram and Business Data Flow Diagrams 4. Requirements 4.1 Requirement 1 Requirement: When a customer makes an order over the chat enabled COES application, either asking for a home delivery or a self-collect order, the administrator chatting with them asks for the number or retrieves it from the information entered by the customer, especially when an administrator was not available to chat during the time of ordering. 4.2 Requirement 2 Requirement: The information is keyed into the system to retrieve their credit card information and address. 4.3 Requirement 3 Requirement In the case that the information is not available, the customer is prompted for it. 4.4. Requirement 4 Requirement: The system allows users to key in the number matching to an item on the menu, as it is requested for 4.5. Requirement 5 Requirement: Each item must be confirmed prior to addition to the order 4.6. Requirement 6 Requirement: The system should maintain an increasing total amount for the cost of the order. 5.0 SPECIFICATION 5.1 Design Behavior Tree (DBT) 6.0 DESIGN 6.1 Component integration Network (CIN model) The design process The designers followed these steps when designing the COES application. They did a review of the requirements that were necessary, then discussed changes with product managers, and later created and edited dialog boxes. Next was the preparation of a preliminary design outline – which incorporated the new dialog boxes, dialog box descriptions and sample procedures. The preliminary design was presented to the product manager and the database architect for critique and review (Ralph & Wand, 2009). A meeting was held for the review of the proposed design, during which suggestions of change to the design document were made, and then it was distributed to the review team. The review team raised necessary questions – after which another review meeting was held by the software designer. After all the preceding processes, the software was taken through review, before it was developed to completion. This process was aimed at testing the functionality of the proposed design (Ralph & Wand, 2009). End users were not included in the design process for a number of reasons: the management was not willing to offer the resources and the time required for participatory and iterative designing. The users may exert the need that the application under development – should operate, exactly like other systems they are familiar with. Most of the target users did not posses experience related to graphic user interfaces, therefore, did not comprehend the range of features that could be incorporated into the model (Ralph & Wand, 2009). Design Document preparation process In developing the design document, the designing team had in mind – the needs of the customers, who were to be served by the order entry system: the users of the system and the administration team, who would control the system. The designers started by developing and modifying dialog boxes – using the OS/2 Dialog Box editor. After the review of initially developed version of the dialog boxes was completed, the development of the design documented was commenced. The final step of the process was the insertion of a table – which presented descriptions of the different buttons and fields (Ralph & Wand, 2009). Later, the listing of boxes in the newly developed dialog boxes was done. During the process of drafting the document, the dialog boxes incorporated into the design would change as enhancements were discovered and due to design flow. The development of the entire process was completed in a period of six weeks – after which the design was ready to be taken through the review process. The resultant design document for the users, the administrators, client features and the agency incorporated sample procedures. The sample procedures were interspersed with descriptions for the newly developed dialog boxes. Due to the similar nature of the developed dialog boxes, pictures were not incorporated into every point, during the procedure. Instead, references were placed at the points where each of the design dialog boxes was placed. Change Impact Analysis Based on Static Program Slicing for the COES application For the change impact analysis, static program slicing was used. Static program slicing is the computation of application points that are affected or which effect by other application or program points. While using this model, the forward slice from application point p, incorporates all the program points at the forward control flow, which are influenced by the computation or the condition test at p. Vertices or program points are the very fundamental components of the source code (Pfleeger & Atlee, 2006; Pfleeger & Atlee, 2006). The production team used the commercial static analyzer, codesurfer, to directly impose static program application slicing during the change impact analysis process. The analysis was done between two release versions of the COES application. The release versions were noted as V1 (older version of the COES application) and V2 (the new version). The team took account of component X, which is a major constituent of Y and contains 1.18 MLOC, designed using C/C++. The teams used TFS (the Microsoft Team Foundation Server) for version control. Between the release dates of the two versions, there was one year (Pfleeger & Atlee, 2006). A change refers to the contiguous block of lines, which has been changed between the earlier, and the latter versions or the block of lines supplemented to the recent version. Codesurfer calculates the impact of the change noted – in terms of the lines affected in the latter application. For any given alteration, Codesurfer applies forward slicing to calculate the set of lines impacted by the change (impact set). To calculate the forward slice, codesurfer executes several static application inspections, for instance dependency and pointer analysis. This process takes place through a transparent integration with the linking and the building of the application. Build link evaluation is referred as the build stage. The data computed during the build stage is used in computing the impact set (Pfleeger & Atlee, 2006). During the study, the changes between Versions V1 and V2 were checked using a diff-like plane over the TFS platform. For the initial analysis, the team considered an approximate of thirty changes present in the source code for version V1 and V2. The experiments were run from a 2GHZ quad-core, 2008 server system running on Windows. The machine had specifications of 24GB RAM and 2.8 Terabytes of disk space. The team ran codesurfer on the changes, initially using the HIGH setting then using the LOW profile settings (Pfleeger & Atlee, 2006). Of the thirty changes checked, highlights of the basic changes were highlighted –as these were representative of the others. These statistics are shown in table 1. For the succeeding three steps, an analysis of the data from the initial study was presented and a discussion offered – on how static slicing-based changes influence analysis. When applied directly, they can obstruct normal software progression at industrial settings (Ren et al., 2005). Table 1: Impacted lines (LOC), Slice Time and Total Slice Time (ST) and (TST) based on HIGH and LOW profile settings: 10 changes analyzed using CodeSurfer. ID H (LOC) ST (m:s) L (LOC) ST (m:s) 1 336216 4m:22s 758 < 1s 2 338117 5m:51s 58 < 1s 3 342542 6m:12s 25 < 1s 4 342460 5m:21s 3144 1s 5 335838 5m:00s 211 < 1s 6 333665 5m:55s 92 < 1s 7 355675 15m:17s 343758 22s 8 342772 6m:52s 309925 14s 9 86 1s 93 < 1s 10 37 < 1s 27 < 1s TST: ~ 55m TST: Read More