TARGET ENTERPRISES LTD

This case was developed by Professor Steve Erlank for Wiley solely to provide material for class discussion. We
have subsequent modify some of the content to be more representiative of today’s business practice. The author
does not intend to illustrate either effective or ineffective handling of a managerial situation. The statements and
opinions contained in this case are those of the individual contributors or advertisers, as indicated. The Publisher
has used reasonable care and skill in compiling the content of this case. However, the Publisher and the Editors
make no warranty as to the accuracy or completeness of any information on this case and accept no responsibility
or liability for any inaccuracy or errors and omissions, or for any damage or injury to persons or property arising
out of the use of the materials, instructions, methods or ideas contained on this case.

OVERVIEW
Target Enterprises Limited (TEL) is a mail order company which markets a variety of consumer
items - luxury, consumer and novelty items mainly to the Cape region by posting catalogues to
customers on their mailing list, and also by inserting catalogues (for a fee) in newspapers and
selected magazines. They are expanding rapidly, and with the changing technological landscape in
their primary geographical region urgently need some assistance to manage the administration of
their order processing processes.

Background

Acccording to Ivor Mereck, Managing Director, Target Enterprises, is a small direct-mail order
company based in Cape Town. They market a variety of luxury, consumer and novelty items mainly
to the Cape region by posting catalogues to customers on their mailing list, and also by inserting the
catalogues (for a fee) in newspapers and selected magazines. When orders come in from customers,
they are dispatched by parcel post. The company also have two brick-and-motar showrooms in
Wynberg and Belville where customers can view items and place their orders. There is limited stocks
available for sale at these showrooms.
The company now employs 27 people, including a marketing manager, an operations manager , and
a finanacial managerwho report to the Managing Director. There are a number of clerical staff some
of whom are responsible for ordering and receiving new goods from our suppliers in the Far East,
while others process incoming orders and dispatch goods to customers. There are a few packers in
the dispatch area as well, who pack items ready for posting.
The company is that point where they are getting bogged down in paperwork on the incoming
orders side, and it is becoming difficult to maintain our customer list, because of the volume of new
customers. Errors in their database has led to a lot in unnecessary postage. If they are to survive in
the mail-order business, they need to ensure that they manage and use their customer database more
effectively – capturing and maintaining more information about customer tastes and purchase
history. With expansion plans on the horizon – Target will be aggressively moving into South Africa
and the neighbouring countries, their current operating model will not be able to cope.
CIS 300 – System Analysis and Design Target Enterprises Ltd

Use Cases Analysis

Use cases are used to explain and document the interaction that is required between the user and the
system to accomplish the user’s task. Use cases are created to help the development team
understand more fully the steps that are involved in accomplishing the user’s goals. Once created,
use cases often can be used to derive more detailed functional requirements for the new system.

A use case depicts a set of activities performed to produce some output result. Each use case
describes how an external user triggers an event to which the system must respond. For example, in a
video rental system, a customer might rent a DVD or return a DVD, or a DVD might become
overdue. The act of renting or returning DVDs and the passage of time are all events triggering a set
of activities the system must perform. With this type of event-driven modeling, everything in the system
can be thought of as a response to some trigger even. When there are no events, the system is at
rest, patiently waiting for the next event to trigger it. When a trigger event occurs, the system (and
the people using it) responds, performs the actions defined in the use case, and then returns to the
waiting state.

Identifying the Major Use Cases

The first step in creating the use cases is to identify the major use cases according to the
requirements definition, which was developed in the last chapter and shown in the System Proposal
document. Take a minute and carefully read the requirements definition. Identify the major use
cases that you think need additional definition before you continue reading.

The information in the functional requirements definition sometimes just flows into the use cases,
but it usually requires some thought as to how to structure the use cases. After you read the
requirements definition, you may be tempted to identify use cases that correspond directly to the
requirement categories, such as (1) search and browse, (2) purchase, and (3) promote. However,
creating an event response list helps to clarify the number and scope of the use cases. (See below)

Event Response Requirements

Customer searches and New entries in Favorite list and/or interests 1.1., 1.2,1.3,1.4, 3.1, 3.3
browses Web site
Music is selected for Purchase and download transaction is 2.1, 2.2, 2.3, 2.4
purchase completed
Promotions are created

Thinking carefully about these requirements, we can see that there are three significant triggering
events: A customer arrives at the site to search and/or browse music selections; a customer selects a

CIS300_Target_Enterprises_Ltd_CaseStudy_Milestone_03 Page - 2
CIS 300 – System Analysis and Design Target Enterprises Ltd

tune to download and buy; and the marketing department wishes to create special promotions. Let’s
look at each event in turn.

When a customer arrives at the site, he or she will normally browse a predefined category of music
(1.1) or enter a search for a particular title, artist, or genre of music (1.2). If the customer has visited
the site and created entries on a Favorites list or has purchased any times in the past, the display of
tunes on the site will be tailored to the customer’s interests (3.1, 3.3). The customer may select one
or more music samples to which to listen (1.3, 3.1). The customer may add tunes to his Favorites list
at any time (1.4). As you can see, this event encompasses requirements from both category 1 and
category 3.

The second event, a customer triggering the purchase process, is kept separate from the search and
browse event, although both events involve the customer. Purchasing involves gathering
information about the customer (2.1), the music selection (2.2), and the method of payment (2.1,
2.3) and verifies the payment information (2.4) before the download process is triggered. Finally, on
a periodic basis, customer Favorites lists and purchase records are reviewed by the marketing
department so that promotions and Web specials can be developed (3.2). Targeted promotions are
created for when customers revisit the site (3.3). Specific e-mails will be directed to customers,
offering additional special promotions (3.4).

Elaborating on the Use Cases

During the JAD sessions, the team followed the steps of the process outlined earlier. For each use
case, the primary actor and trigger were identified and a brief description was written. The next step
was to define the major steps for each use case. The goal at this point is to describe how the use case
operates. The best way to begin to understand these use cases is to visualize yourself browsing a
sales-oriented Web site, searching for particular items, investigating specific items further, finally
making a decision to buy, and completing the purchase. The techniques of visualizing your
interaction with the process and thinking about how other systems work (informal benchmarking)
are important techniques that help analysts and users understand how processes work and how to
write the use cases. Both visualization and informal benchmarking are commonly used in practice.
The next step is to add more detail to the steps by identifying their inputs and outputs. This means
identifying what inputs are needed to complete the step (e.g., information, forms, and reports) and
what outputs are produced by each step.

Alternative branches in logic were discussed and the team looked for error conditions that might
occur. As the inputs and outputs were described, they were written in the summary area at the end
of the form. Once all the use cases had been defined, the final step in the JAD session was to
confirm that they were accurate. The project team had the users role-play the use cases. A few minor
problems were discovered and easily fixed.

CIS300_Target_Enterprises_Ltd_CaseStudy_Milestone_03 Page - 3
CIS 300 – System Analysis and Design Target Enterprises Ltd

Figures 3-1 shows the completed use case. Refer to this use case as you read the remaining material
in this chapter. Can you follow the steps? Do they seem logical? If you find something that you
think may be missing, remember that use cases are created with gradual refinement, and errors and
omissions can be corrected as they are discovered. Also, we have purposely tried to avoid getting
lost in the details. Our goal is to include the major activities that are performed, but not necessarily
every tiny detail at this point.

Search and Browse Tunes

For the Search and Browse Tunes use case, the primary trigger is the Tune Shoppers arrival on the
Web site. The actor is specified as "Tune Shopper,” because this person may not necessarily
purchase a tune from Tune Source. The preconditions for this use case are that the Web site is up
and running and the Tunes database is available. After you connect to the Web Site, you may browse
through the categories of selections that are featured on the page. If you are a first-time visitor, the
page displays generic information. However, if you have visited the site before, any interests that
were created on your previous visit will be used to customize your page and display selections that
are tailored to you.

In addition, if you choose to open your account, you will be able to view the Favorites list you
created in your account. The Tune Shopper may request searches fortunes based on title, artist, or
genre. The Tune Shopper may select tunes so that they can listen to samples, automatically adding
those selected tunes to the tile that tracks each customer’s interests. If you like what you hear, but
are not ready to buy, you may add the tune to your Favorites list so that you don’t lose track of it.
You can also remove tunes you had previously added to your Favorites list. If you are ready to buy,
you signal that decision, usually by placing the item in a "shopping cart." You can continue to
browse and search, adding more tunes to your shopping cart or removing tunes from the cart, or
you may be ready to complete the purchase and "check out.”

One of the challenges in creating this use case is that users do not follow a particular pattern when
browsing a Web site. Although the steps listed under the Normal Course are numbered, they are not
necessarily performed in order. Therefore, each step is somewhat independent from the other steps.
The post conditions tell us that several things may occur as a result of this use case: there may be
new entries made for shopper interests; there may be modifications to an account holder Favorites;
and there may be items placed in the shopper’s shopping cart.

Purchase Tunes
For the Purchase Tunes use case, the actor is specified as the Tune Buyer. This designation is made
because the user of the Web site has indicated an intention to actually purchase the item(s) in the
cart. Therefore, a precondition is that there must be one or more items in the shopping cart. After
the user specified he is ready to purchase, the Tune Buyer must supply payment information. The
Tune Buyer may enter a username and password if he has an account; otherwise, he may establish an
account or just provide purchase information for the current session only. If the Tune Buyer

CIS300_Target_Enterprises_Ltd_CaseStudy_Milestone_03 Page - 4
CIS 300 – System Analysis and Design Target Enterprises Ltd

chooses to create an account, customer details will be gathered from the customer and a new
account record will be created. Payment information will be gathered from the Tune Buyer and will
be stored in the account (if there is one) or just used for the current session. Once the payment
information is verified, the customer authorizes the transaction, a new purchase record is written to
the sales file, and the tune is released for download by the customer.

A Note on Creating Use Cases

A use case contains all the information needed to build one part of a process model, expressed in an
informal, simple way. A use case has a name, number, importance level, brief description, primary
actor, trigger(s), preconditions, post-conditions, major inputs and outputs, and a list of the major
steps required to perform it. Use cases can be identified by reviewing the functional requirements.
An event-response list also is useful in identifying the significant events that should be described in a
use case. Once the use case is completed, often new and expanded functional requirements can be
derived. When writing a use case:

1. Identify the triggering event (external or temporal) and the primary actor.
2. Develop a list of the major steps involved in using the input(s) to produce the needed
output(s) and desired response(s) to the event.
3. Think more deeply about each step and identify the specific input(s) and output(s) for every
step.
4. Have the users role-play the use case to verify that it is correct as written.

Appendix 3-A

Use Case Name: ID: Priority:

Actor:
Description:
Trigger:
Type:  External  Temporal
Preconditions:
Normal Course: Information for Steps:
Alternative Courses:
Postconditions:
Exceptions:

Summary
Inputs Source Outputs Destination

Figure 1 - Blank Use Case Form

CIS300_Target_Enterprises_Ltd_CaseStudy_Milestone_03 Page - 5
CIS 300 – System Analysis and Design Target Enterprises Ltd

Use Case Name: Search and Browse Tunes ID: UC-1 Priority: High
Actor: Tune Shopper
Description: This use case describes a tune shopper who searches and browses through tunes
Trigger:
Type:  External  Temporal
Preconditions:
Web site is available; Tune database is online
Normal Course: Information for Steps:
1.0 Search and browse tunes and select tunes to purchase
1.1 System displays default home page or customized page
1.2 Tune Shopper browses links on page or enters account username and password Username/password
1.3 Tune Shopper want to create an account: perform Create Account use case
1.4 Tune Shopper enters search request Search Criteria
1.5 System displays tune(s) matching search request Tunes Matching Search
1.6 Tune Shopper selects a tune and wants to hear a sample Tune samples
New Interest
1.7 Tune Shopper selects a tune to add to Favorites New Favorites
1.8 Tune Shopper selects a tune to remove from Favorites Modified Favorites
1.9 Tune Shopper selects a tune to buy by placing it in shopping cart New Shopping Cart Entry
1.10 Tune Shopper elects a tune to remove from shopping cart Modified Shopping Cart
Alternative Courses:
1.1 Tune Shopper is a return visitor (branch to step 1)
1.1.1 System displays page customized for the return visitor using interests from Interest database
prior visits
1.2 Tune Shopper has created an account (branch at step 2) Favorites database
1.2.1 System displays welcome message to account holder
Targeted Promotions
1.2.2 Page is customized for the account holder using Favorite List and Targeted
database
Promotions

Postconditions:
1. One or more tunes are added to shopper interests
2. Account holder favorites list may be modified
3. Shopping cart contents may be modified
Exceptions:
E1: Account is not valid (occurs at step 2)
1. System displays message that username/password is not valid
2. System asks Tune Shopper to re-enter username/password or contact customer service for help.

E2: Search request returns no results (occurs at step 3)

1. System displays message that no results were found for that search
2. System ask Tune Shopper to try another search

Summary
Inputs Source Outputs Destination
Username/password Tune Shopper New interest Interests database
Search criteria Tune Shopper New Favorites Favorites database
Tunes matching search Tunes database Modified Favorites Favorites database
Tune samples Tune Samples database New Shopping Cart Entry Shopping Cart database
Modified Shopping Cart Shopping Cart database
Figure 2: UC-1 - Search and Browse Use Case

CIS300_Target_Enterprises_Ltd_CaseStudy_Milestone_03 Page - 6
CIS 300 – System Analysis and Design Target Enterprises Ltd

Process Modeling

A process model describes business processes – the activities that people do. A process model is a
graphical way of representing how a business system should operate. It illustrates the processes or
activities that are performed and how data move among them. Process models are developed for the
as-is system and/or the to-be system. Let look at Data Flow Diagrams (DFD).

Elements of Data Flow Diagrams

The language of DFDs includes a set of symbols, naming conventions, and syntax rules. There are
four symbols in the DFD language (processes, data flows, data stores, and external entities), each of
which is represented by a different graphic symbol. There are two commonly used styles of symbols,
one set developed by Chris Gane and Trish Sarson and the other by Tom DeMarco and Ed
Yourdon (Figure 4-1). Neither is better than the other; some organizations use the Gane and Sarson
style of symbols and others use the DeMarco/Yourdon style, we will use the Gane and Sarson style
in this class.

Process A process is an activity or a function that is performed for some specific business
reason. Processes can be manual or computerized. Every process should be
named starting with a verb and ending with a noun (e.g., "Determine request
quantity"). Names should be short, yet contain enough information so that the
reader can easily understand exactly what they do. In general, each process
performs only one activity, so most system analysts avoid using the word “and"
in process names because it suggests that the process performs several activities.
In addition, every process must have at least one input data flow and at least one
output data flow.

Data Flow A data flow is a single piece of data (e.g., quantity available) (sometimes called a
data element), or a logical collection of several pieces of information (e.g., new
chemical request). Every data flow should be named with a noun. The
description of a data flow lists exactly what data elements the flow contains. For
example, the pick-up notice data flow can list the LCA name, chemical, and
quantity requested as its data elements. Data flows are the glue that holds the
processes together.

Data Store A data store is a collection of data that is stored in some way (which is
determined later when creating the physical model). Every data store is named
with a noun and is assigned an identification number and a description. Data
stores form the starting point for the data model and are the principal link
between the process model and the data model.

CIS300_Target_Enterprises_Ltd_CaseStudy_Milestone_03 Page - 7
CIS 300 – System Analysis and Design Target Enterprises Ltd

Data flows coming out of a data store indicate that information is retrieved from
the data store. Data flows going into a data store indicate that information is
added to the data store. Finally, data flows going both into and out of a data
store indicate that information in the data store is changed (e.g. by retrieving data
from a data store, changing it, and storing it back).

External Entity An external entity is a person, organization, organization unit, or system that is
external to the system, but interacts with it (e.g., customer, clearinghouse,
government organization, accounting system). The external entity typically
corresponds to the primary actor identified in the use case. External entities
provide data to the system or receive data from the system, and serve to establish
the system boundaries; every external entity has a name and a description.

Using DFD to Define Business Processes

Most business processes are too complex to be explained in one DFD. Most process models are
therefore composed of a set of DFDs. The first DFD provides a summary of the overall system,
with additional DFDs providing more and more detail about each part of the overall business
process. Thus, one important principle in process modeling with DFDs is the decomposition of the
business process into a hierarchy of DFDs, with each level down the hierarchy representing less
scope but more detail. Figure 4-2 shows how one business process can be decomposed into several
levels of DFDs.

Context Diagram The first DFD in every business process model, whether a manual system or a
computerized system, is the context diagram (see Figure 4-2). As the name
suggests, the context diagram shows the entire system in context with its
environment. All process models have one context diagram.

The context diagram shows the overall business process as just one process
(i.e., the system itself) and shows the data flows to and from external entities.
Data stores usually are not included on the context diagram, unless they are
"owned" by systems or processes other than the one being documented. For
example, an information system used by the university library that records who
has borrowed books would likely check the registrar’s student information
database to see whether a student is currently registered at the university. In
this context diagram, the registrar’s student information data store could be
shown on the context diagram because it is external to the library system, but

CIS300_Target_Enterprises_Ltd_CaseStudy_Milestone_03 Page - 8
CIS 300 – System Analysis and Design Target Enterprises Ltd

used by it. Many organizations, however, would show this as an external entity
called "Registrar’s Student Information System," not as a data store.

Level 0 Diagram The next DFD is called the level 0 diagram or level 0 DFD. (See Figure 3.)
The level 0 diagram shows all the processes at the first level of numbering (i.e.,
processes numbered l through 3), the data stores, external entities, and data
flows among them. The purpose of the level O DFD is to show all the major
high-level processes of the system and how they are interrelated. All process
models have one and only one level O DFD.

Figure 3: Relationship among Levels of Data Flow Diagrams (DFDs)

Another key principle in creating sets of DFDs is balancing. Balancing means
ensuring that all information presented in a DFD at one level is accurately

CIS300_Target_Enterprises_Ltd_CaseStudy_Milestone_03 Page - 9
CIS 300 – System Analysis and Design Target Enterprises Ltd

represented in the next-level DFD. This doesn’t mean that the information is
identical, but that it is shown appropriately. There is a subtle difference in
meaning between these two words that will become apparent shortly, but for
the moment, let’s compare the context diagram with the level 0 DFD in Figure
3 to see how the two are balanced, In this case, we see that the external entities
(A, B) are identical between the two diagrams and that the data flows to and
from the external entities in the context diagram (X, Y, Z) also appear in the
level 0 DFD. The level 0 DFD replaces the context diagram’s single process
(always numbered O) with three processes (l, 2, 3), adds a data store (D1), and
includes two additional data flows that were not in the context diagram (data
flow B from process l to process 2; data flow A from process 2 to process 3).

Level I Diagrams In the same way that the context diagram deliberately hides some of the
system’s complexity, so, too, does the level 0 DFD. The level 0 DFD shows
only how the major high-level processes in the system interact. Each process
on the level 0 DFD can be decomposed into a more explicit DFD, called a
level 1 diagram, or level 1 DFD, which shows how it operates in greater detail.

ln general, all process models have as many level 1 diagrams as there are
processes on the level 0 diagram; every process in the level 0 DFD would be
decomposed into its own level 1 DFD, so the level 0 DFD in Figure 3 would
have three level 1 DFDs (one for process 1, one for process 2, one for process
3)..

Level 2 Diagrams The bottom of Figure 3 shows the next level of decomposition: a level 2
diagram, or level 2 DFD, for process 2.2. This DFD shows that process 2.2 is
decomposed into three processes (2.2.1, 2.2.2, and 2.2.3). The level 1 diagram
for process 2.2 shows interactions with data store D1, which we see in the
level 2 DFD as occurring in process 2.2.3. Likewise, the level 2 DFD for 2.2
shows two input data flows (1-1, K) and two output data flows (C, G), which
we also see on the level 2 diagram, along with several new data flows (Q, R, S).
The two DFDs are therefore balanced. It is sometimes difficult to remember
which DFD level is which. It may help to remember that the level numbers
refer to the number of decimal points in the process numbers on the DFD. A
level O DFD has process numbers with no decimal points (e.g., l, 2), whereas
a level l DFD has process numbers with one decimal point (e.g., 2.3, 5.1), a
level 2 DFD has numbers with two decimal points (e.g., l .2.5, 3.3.2), and on.

CIS300_Target_Enterprises_Ltd_CaseStudy_Milestone_03 Page - 10
CIS 300 – System Analysis and Design Target Enterprises Ltd

Tune Source’s Context Diagram

The project team began by creating the context diagram. They read through the summary area of the
three major use cases in developed in the last exercise to find the major inputs and outputs. The
team noticed that the majority of data flow interactions are with the customers who are using the
Web site to browse music selections and make download purchases. There will be an interaction
with the payment clearinghouse entity that will handle payment verification and processing of
purchases. Finally, although it is not obvious from the use cases, the marketing managers will be
using sales information from the system to design and implement promotional campaigns. The team
used the major inflows and outflows from the use cases and developed the context diagram shown
in shown below.

Figure 4: Tune Source System Context Diagram

Deliverables (#3)
Using the information from your completed Target Enterprises Requirements Definition with
features you would like to see and/or are necessary for a smooth Online/Brick and Mortar Retail
store.

1. Project Milestone #3A: Create the Major Use Cases identified in the Requirements
Definition Document
2. Project Milestone #3B: Create Context Diagram, Level 0 and Level 1 Data Flow Diagrams
for the Use Cases identified for Target Enterprises.
3. Due Date: 10/14/2016 @ 11:55pm

For Milestone #3 please use templates figures 4.3.

CIS300_Target_Enterprises_Ltd_CaseStudy_Milestone_03 Page - 11