Department of Information Systems

Target Enterprises Project Specifications1

Target Enterprises (Pty) Ltd

Implementation Project Guidelines

Objectives of the project

Your requirement is to write a Direct Marketing System that conforms to specifications that you have devised in the tutorials this semester. In order to ensure consistency across the whole class, these guidelines will help you define the scope of what will be acceptable as a project.

The objectives of the project are for you to implement a computer system that you have specified yourself. In this way, you will begin to understand how the quality of the analysis and design phase affects the programming phase, and to see how each phase in the SDLC links to the next. This process is realistic; it is rare in these times that you will be given a carefully designed and specified “project spec” in the real world.

How the project works

The scope of your analysis and design should include all of the business functions described in the tutorials. In other words, the system that will eventually be written for Target will be a flexible, powerful, GUI system that will automate virtually all of their order processing, dispatch, marketing, and purchasing functionality. It will probably have some Internet features as well and will be fully networked.

It will take some time for the full system to be written, and Ivor Merck is interested in seeing results quickly. You have thus decided to split the actual writing of the system into two phases. Phase 1 is to write a fully working system that computerizes the most important business processes, with the less important ones remaining manual for the time being. This phase 1 system will be used by Ivor Merck as a pilot system to train users and to see get an idea of how well the full system will operate in Target. You and a partner must write the phase 1 system in PowerBuilder.

Phase 2 (which you will not actually need to write) will be to complete the rest of the functionality of the system and to incorporate any additional features that Merck identifies while he is using phase 1. Your URS must show the users requirements for the full system, and you should use your ingenuity to find an appropriate way of showing which of these requirements fall into phase 1 and which will be developed only in phase 2.

You should be guided quite strongly by the descriptions of business processes and user requirements as laid down in the tutorials and previous handouts. This information tells you how Target deals with its business processes and exceptional situations that arise.

Required functionality to appear in phase 1 of the system

Essentially, the functionality to be included in phase 1 is to provide computerized support for the entire business process from order capture to dispatch. A few extra functions are also required.

The system, which must be written in PowerBuilder by groups of 2 students, should contain at least the following functionality:

1. Stock movements.
   The system must be able to create new stock items. It should also be able to record deliveries of stock items, and it must update stock levels in a controlled and auditable fashion (see tutorial 4 for more details). It is not sufficient to just update the quantity on hand. A transaction record of some kind must be recorded for each stock movement. Stock adjustments are also required (for example where stock losses have occurred), and the quantity on the database needs to be adjusted.

1. Order processing
   The system must handle the capture of an order from the order form, or telephonically. Order status must be automatically changed by the system by the order capture and dispatch processes (see tutorial 4). Appropriate validation of stock levels, etc. must be done. The ability to do cancellation of orders, and to cancel order items described in tutorial 4 must also be in the system.

1. Order dispatch
   You may assume that the system will eventually be on a network, although you do not have to implement the networked version in phase 1. You must, however include the functionality to dispatch (deliver) an order. This includes printing a picking list for the order, and recording which items have been packed in which parcel. In phase 1, the courier, SATS, or postal slips will still be written by hand, but this information must still be recorded in the system. See tutorial 4 to see how incomplete orders are handled. The system should have the capability to call up incomplete orders to complete delivery as and when stock arrives.
2. Order enquiry
   The system should allow for an order enquiry, which will show full details of the order, the items ordered and the status of the order as well as the delivery status of each item on the order (i.e. full drill-down enquiry). Note that the user should be able to access the order enquiry by knowing the either the customer number, the customer name, or the order number.

1. Payment batch report
   Printing of payments received each day, to be batched with the cash and checks themselves and sent through to the Accounts Dept for banking. Note that this report may not necessarily be printed on the day that payments were received. Thus each time the report is run, it should only reflect payments that have not already appeared on a previous batch report (you can't deposit the same payment twice!)

1. Stock movement report
   The stock movement report should reflect all stock movements that took place in a given period (specified by the users, who can run it daily, weekly or monthly if they want). This includes deliveries, stock adjustments, and sales of each item.

1. Detailed sales analysis report
   The users want to see what their best-selling items are, shown by value and quantity, for a particular period. This is similar to the stock movement report except it just shows sales, not all movements.

What functionality may be deferred to version 2?

1. You need not develop a system with true multi-user or network capabilities in phase 1. However, the system should appear to be multi-user capable in that it will have order handling and dispatch processes in it.

1. There will be a few entities in the data model that are typical 'lookup' tables. An example might be DELIVERY_TYPE. These 'lookup' tables will typically be used in drop-down lists (actually dropdown DataWindows!). In the final system these lookups will all be updateable, and you will need to write functions to update all of the lookup tables. In phase 1, it will be acceptable for you to create these lookup tables and the data in them using the database painter.

1. The following functions will be deferred for version 2 of the system, and are not required in the project you deliver in phase 1. However, you should show them as part of the user requirements in the URS. You could also show them as disabled items on your main menu!

• Printing of stock re-order reports, issuing of purchase orders, ordering of new stock from suppliers and payment for new stock deliveries
• Printing of labels, and mailing lists for the marketing department
• Mailing list management (e.g. importing of new names and addresses from other lists, reports to track down duplicate addresses)
• Any additional functions requested by the Marketing Department.
• Internet functionality

Deliverables

On or before the due date, you must submit a printed and bound User Requirements Specification for the full system, as well as a working computer project of phase 1 of the system.

1. User Requirements Specification
   This comprises the documentation from the Systems Analysis phase of the project. The documentation should describe everything the user requires in the system, including the functionality, data, interfaces, etc. Hint: Include all of your models, correctly and accurately drawn, of the new system.

For this project, you should be aiming at about 8 pages of typed material, plus any diagrams, layouts and appendices as extra. Your URS should be neat and tidy, with cover and contents pages. Handwritten specs are not acceptable.

1. Working System
   The working computer-based information system consists of the functions that carry out phase 1 of the user requirements of as well as sufficient test data to run the system properly. For control purposes you are required to hand in your source code library (.PBL files) on the due date. The marker may request you to use this PBL file when demonstrating your project. Normally, with any system you would also hand in user documentation that describes how to use the system, and systems documentation that describes how to install and run the system. For the purposes of this project, you need not hand in any such documentation.

The project marking process

You will be required to demonstrate your project to a marker in a half-hour appointment. The objectives of this demonstration are to:

• Speed up the marking process, and allow you to understand the marking process better
• Allow you to present your system in the best possible light and ensure the marker sees the results of your efforts
• Provide the marker with an opportunity to explain where your project has good features, and where it should be improved (richer feedback)
• Allow the marker to ask the student more technical questions about the project, if the marker believes that the project is not the student’s own work

The .pbl file that was handed in will be compared with the one to be used in the demonstration. If any discrepancy is discovered, the original .pbl file will be used.

Students should prepare a demonstration plan and should have sufficient sample data in the databases to demonstrate that their prototype works properly. Insufficient realistic data in the databases may indicate to the marker that the system has not been properly tested.

Further, the marker may, at his or her discretion, require either member of the group to demonstrate sufficient technical understanding of the system to be able to state how certain changes might be made to the system, or to explain how a particular piece of script works.

Some markers will have computers that can handle PowerBuilder but some may not. Please verify this with your marker beforehand. Students who are working on computers at home are counseled to ensure that their entire system is thoroughly tested on the network well before the demonstration if they intend to demo from the network.

It is acceptable (recommended) that you use your own computer for the demonstration if you have been working at home. In cases where technical problems arise, the marker will move the demonstration into the Lab.

The onus is on the student to ensure:

• That the system is ready to run, and that all components of the system (e.g. .pbl file, databases, bitmaps) are correctly loaded before the system is to be demonstrated
• That their databases have sample data in them
• That recent printed copies of all reports are available for scrutiny

Dishonesty and uneven effort in the group

Both partners in the group should have worked equally hard on the URS and the system

Marks will be awarded jointly to the group, even where there may have been differing skills levels on the part of each member. If however, in the opinion of the marker, the workload and effort in the group has been unequally distributed, or the system has suffered significantly because of non-participation or poor effort by a partner, students may be required to demonstrate the project separately and individually for re-evaluation. In such circumstances, the total marks for the project are likely to be redistributed on a basis that reflects the student effort.

The following plan gives a rough indication of how many marks will be allocated to aspects of the project.

User requirements specification counts 5% towards the year mark. The system counts 15% towards the year mark.

The following mark breakdown is likely to be used with regard to the system.

Hints when developing the system

1. Complete your data models and your CRUD diagrams very soon.

1. Design the layout of your reports and enquiries (and THINK about the kind of information that will be useful!)

1. Create your database tables. Create sample data which you will need in the tables that will not be updated by your own programs.

1. Design each and every program you are going to write, using pseudocode or just making notes. Pay particular attention to how the program will read or update each database file.

1. Use the CRUD diagram to identify the sequence in which programs must be written. Estimate how much time you need for each program, leaving time at the end for overall testing and putting in good amounts of data.

1. Complete each program, running and tested before you start the next.

1. BE AWARE THAT THE LABS WILL BE VERY CROWDED TOWARDS THE END OF THE PROJECT. Response times will be slower, help resources will be stretched, and everything you try to do will take twice as long. Get smart and put in the hours you need NOW, not then!

1. Ensure that you have a fair amount of proper data in the system! This indicates to the marker that you have, in fact, been able to use the system yourself, and that you have tested it properly, and it also makes your reports and enquiries much more interesting!

1. To obtain a pass mark for the system, the system needs to allow the user to do everything specified in a reasonably efficient and businesslike way. Bugs, crashes or errors will mean that the user can’t use that function, and you will lose marks for it.

1. Better marks will be awarded for more elegant designs and solutions, non-hard coded aspects, lookups, validation, better business solutions, more effort on the interface, etc.

GOOD LUCK.