The Van Hire Business
A garage runs a van hire business. The business is ticking over satisfactorily but it is likely that the just-tolerable efficiency of the current manual system, already under strain, will soon decrease to unacceptable levels. The garage has put into motion plans to expand the business by enlarging its premises and increasing its fleet size. The results of a feasibility and cost- benefit study have produced the strong recommendation that the garage should, as Part of the expansion, computerise its hire business to increase efficiency, profitability and quality of service to the customer. A brief preliminary analysis of the current business operation has revealed the following set-up:
As the result of a market survey and consultant advice, the garage has come down in favour of bespoke software rather than an off-the-shelf data-management product, mainly because of the dedicated features that can be built into the former. The software house that has won the contract to develop the system happens to be a forward-looking company. It tends to adopt a formalised methods approach to development work for outside clients where it judges that the technology is appropriate and will not be over-stretched on the project. Past experience has shown that formalised methods are particularly cost-effective with computerisation of small-to-medium sized information systems whose scope and functionality are relatively stable and well understood.
In any system development problem like this, the two requirement definition objectives that will have the greatest impact on the technical specification are identification and documentation of:
· The 'relevant domain subject matter' that the system needs 'to keep track of' so that it is able to provide the services desired by the client
· The system functionality that will provide the client with those desired services.
The first of these two sets of requirements will form the basis of the Class model; out of the second set of requirements will come the Use Cases.
Some Analysis
The business outline is obviously insufficient on its own to act as the basis for developing an acceptable computer system. Thus, we will imagine a period of extensive consultation with the client during which the developer has sought to clarify a number of important issues, including the following:
Q. Over what length of period can a customer hire a van?
A. Up to a maximum of 28 days, though we reserve the right to refuse a booking from a potential customer especially a customer previously unknown to us who requires a hire period length at or near the maximum. Hire periods are defined in terms of their start and end dates; these, of course, cannot be days like Sundays, bank holidays, etc.
Q. Presumably, though, times are just as important as dates?
A. Yes, but times merely dictate what we charge the customer. For the first day of hire, we charge a full day's rate for hirings starting up till 13.00 and thereafter half the full day rate. There are, however, no such variations relating to the return time of a van. A return time that keeps to contract is by definition any time during the last day of hire before close of business (18.00 each working day), up to and including 08.45 of the following day but no later. Obviously, vans can be returned only on working days; intervening Sundays, holidays, etc. must be paid for as part of the hire period booked.
Q. Suppose a pre-booked customer is late in collecting, or even fails to collect, a van; or suppose a customer is late in returning a van?
A This situation is taken care of by the standard hire contract, a copy of which we have given to you. The relevant small print says that if a customer has not arrived to collect a van by close of business on the agreed start day, the contract is made void; also, the customer receives no refund. For late returns, we levy a minimum of twice one full day's rate for the first day, plus quadruple this rate for each subsequent day. These heavy surcharges act as a strong disincentive to potential late returners. In practice, the disincentive works-there have been only two late returns in the last six months. We can of course reduce or waive these penalties at our discretion.
Q. We are under the impression that you permit customers to hire only one van at a time. if so, isn't that a bit restrictive and not good business strategy?
A. Our customers are mainly individual members of the general public; we don't operate hire agreements with firms-that is not the slice of the business we target. So nearly all our customers require just one van to fit a certain job they have in mind. In fact, although one van per customer used to be our policy, we haven't operated it for at least a year. Now we just use our discretion. Requests for more than one van at a time are actually quite rare. Where it happens, we treat each individual van request as a separate booking. Note that we offer five different types of van for hire-more than some of our rivals which, in our view, caters for all needs. The van types are: mini; transit; light; medium; and heavy-duty, the latter mainly being used for home contents removal work.
Q. Is it the case that when customers make bookings, they are allocated specific vans at the time of booking?
A. Only when a booking is immediate, i.e., hiring is to start straight away. For advanced bookings, what we do is merely earmark particular van classes as being reserved, as per the customer's requirements. In doing this, we check in principle that we are not overbooking. We know of some hire firms that adopt this dubious practice, but not us. When the customer turns up on the hire start date, we allocate available vans in the requested class(es).
Q. How can you be sure of van availability, and what do you mean by 'in principle' in your answer to the previous question?
A. We mean that we make a quick check against the size of our fleet to see if a van of the required class is available over the desired period. But we do not take into account vans that are currently unavailable, e.g., late in being returned or off the road for repair. This approach works well enough in practice. Late returns are extremely rare, and the number of vans we have off the road simultaneously for any length of time is always arranged to be as small as possible (unpredictable accident repair notwithstanding).
Q. But this procedure does not GUARANTEE availability.
A. No, of course not, but almost. Naturally, customers making immediate bookings have to take what is available and risk being disappointed. But for advance bookings, a minimum 24 hours notice enables us virtually to guarantee customer satisfaction. If we think there is the slightest risk of an availability problem, we contact certain local external suppliers who normally can produce vans of the right kind for us within the hour; the vans then temporarily become part of our fleet. However, we try to avoid this since it increases our costs substantially, and is the main reason why we are absolutely rigorous about not overbooking. In the very unlikely event that a customer, having made an advance booking and despite our checks etc., arrives on the start date to find we have insufficient vans available, we offer either a re-arrangement of the hire period free of charge or a complete refund. This has happened only once since we started up the business about three years ago.
Q. OK, but how do you manage the interleaving of bookings with vans off the road for servicing. Could you clarify please?
A. When a van is approaching its next service point, we simply fit the van's service into any spare time slot that we can find for it. This is typically an afternoon or evening since most vans get returned either early in the morning or late afternoon, and a service does not usually take more than two hours. If necessary, we get one of our mechanics to do some overtime.
Q. Can you please confirm that there are no such things as 'provisional bookings'?
A. Confirmed. Enquiries are welcomed, e.g., by phone, but a booking is made only by the customer making a personal call to our hire centre and either paying up in full or, for an advance booking, making a minimum deposit of 30% of the total charge. However, subject only to using our discretion again, booking can be done any time in advance of the desired hire start date to avoid disappointment.
Q. Presumably a customer can cancel a booking. What then?
A. There is a sliding scale of cancellation fees depending on how close to the hire start date the cancellation is made, working up to the full deposit paid if the cancellation is made within two days of the start date.
Q. Can a customer make multiple bookings?
A. If you mean bookings with different, possibly overlapping, hire periods, then yes, but again it is entirely at our discretion; we tend to permit it only for regular customers. Remember that we also treat a request for more than one van over the same hire period as a multiple booking. Actually, multiple bookings are relatively infrequent. They are just about worth it, even though they complicate the paperwork. Presumably that is at least one problem which computerisation will help alleviate!
Conducting interviews is a standard part of the requirements elicitation repertoire. Much of the above is simply trying to understand the domain of van hiring as operated .by the garage. In a real sense, therefore, we are also understanding the computer system to be built, since that system will in effect partly be a computerised version or model-even 'emulation'-of the domain it is servicing.
Of course, the developer needs other information as well as that contained in the answers to the previous questions. For example, answers are needed to questions like:
What query/report functionality would you like? For example, do you want to be able to see the extent of booking day by day over a specified period?
What kind of interface do you want, e.g., when entering booking data?
Nevertheless, although the above-imagined interview mainly addresses clarification of the domain, it suffices for present purpose making of progress with developing a SSADM specification.
Class Model for the Van Hire System
Back to the development problem. The reason why we are focusing on domain data modelling is that it is capable of providing a sound basis for UML Class modelling, particularly for the kind of system under consideration here. The Van Hire business is an entity-rich domain, and such domains yield information that is vital to a meaningful class model. The class model we will construct for the van hire business uses standard parlance such as objects, associations and attributes. Class modelling is a skill and a craft in its own right with many associated techniques.
A common feature of Class modelling is a class-association description, which scopes the domain in terms of relevant entity types and how they are related. Typically, certain real-world entities stand out as obvious candidates for incorporation into the class model, and in the Van Hire system we would surely include VANs and CUSTOMERs in this category. However, it would soon be apparent that a richer basket of class types is needed to support the client's functional requirements, and that inclusion of VANCLASS entities in the model is also necessary.
Ends.