UML Weekend Crash Course™ - To Parent Directory

288
Sunday Afternoon
Enter contact data such as names, phone numbers, and addresses.
Enter appointment data such as date, time, and description.
Associate contacts with appointments.
Search for specific contacts or appointments.
Receive notification when an appointment is approaching.
The current system is a standalone application with no network component. Friendly
Reminder is a well-established product with a loyal customer base, but the company has
received many requests from users who would like to be able to view their appointments on
the World Wide Web. The customers complain that they have no way to check appointments
when they’re away from their own computer. The client’s initial project specification
requests that you develop a small application that will allow their users to
Upload all their appointments and contacts to a server where they can be remotely
accessed.
Query those appointments and contacts whenever and from wherever they wish.
Requirements Gathering
Regardless of whether you’re developing a Web or standalone application, the requirementsgathering
phase is a process of careful communication with the client to discover and
document the business requirements and to ensure that the development team knows what
it must create in order for the customer to be successful.
In the case study, the clients required that users be able to upload all their appointments
and contacts to a server where they can later access them remotely. Because the client is a
very conservative company and is a little bit apprehensive about moving onto the Web, it
specifies a constraint that the new system must pose the smallest possible risk to the reliability
of their current system. Because the current application has no network component,
all appointments are stored in a file on the user’s machine. Based on this experience, the
client adds a constraint that all appointments must still be saved on the local machine
while a copy of the appointment data can be uploaded to a server for remote access. Also
due to its apprehension, the company wants to limit users to entering appointments only in
the existing Visual Basic application and not on the Web.
In these discussions, we also find out that the users have been requesting access to their
appointments and contacts from traditional wired Web devices such as PCs, as well as from
wireless devices like cell phones. After some discussion, this is identified as a key functional
requirement that can be fulfilled and will be factored into the cost of the project.
In design, as you craft a solution to these requirements, the technological options are
more critical and more extensive in a Web system than a standalone system. Here are some
of the factors you should consider when evaluating technology in a Web system:
Availability and reliability: Must the system be available 24/7 with virtually no
failures It is possible to make a Web system that almost never fails or is never
unavailable, but that kind of reliability comes at a substantial cost. In the case
study, the client protects the reliability of the current system by specifying that the
Web system only keep a duplicate of the data and that nothing in the standalone
system should be dependent on the new Web system.