CTTS CASE STUDY - Milestone 2: Problem Analysis Page: 2-7MILESTONE 2 – PROBLEM ANALYSIS Synopsis T here’s an old saying that suggests, “Don't try to fix it unless you understand it.” With those words of wisdom, the next milestone of our project is to study and analyze the existing system. There is always an existing system, whether computerized or manual or some of both. The problem analysis phase provides the project team with a more thorough understanding of the problems, opportunities, and/or directives that triggered the project. Indeed, the analyst frequently uncovers new problems and opportunities. The problem analysis phase may answer the questions, “Are the problems worth solving?” and “Is a new system worth building?” The purpose of the problem analysis phase is threefold. First and foremost, the project team must gain an appropriate understanding of the business problem domain. Second, we need to answer the question, “Are these problems (opportunities, and directives) worth solving?” Finally, we need to determine if the system is worth developing. The problem analysis phase provides the systems analyst and project team with a more thorough understanding of the problems, opportunities, and/or directives that triggered the project. In the process, they frequently uncover new problems and opportunities. In this milestone you will perform Cause-Effect Analysis and document your findings using the Problems, Opportunities, Objectives, and Constraints Matrix. The PIECES framework, originally developed by James Wetherbe, and then adapted by the authors, can serve as a useful tool to classify the various problems, opportunities, and directives identified in Milestone 1. Second, you will develop a Context Diagram to begin to understand the proposed system and whether or not it is worth developing. A Context Diagram looks at the system as a whole and how it interacts with the world around it. Objectives After completing this milestone, you should be able to: Perform Cause-Effect Analysis to be able to thoroughly understand a system’s problems, opportunities, and/or directives that triggered the project. Use and understand the PIECES framework for classifying problems, opportunities, and directives. Complete the Problems, Opportunities, Objectives, and Constraints Matrix. Create a Context Diagram for the proposed system. Assignment Now that we have completed the survey of the system and gained approval to proceed, we can attempt to gain a better understanding of the current system and to evaluate whether the proposed system is worth developing. Activities To complete the Problems, Opportunities, Objectives, and Constraints Matrix, use the interview presented in this milestone. Use the PIECES framework as a model to classify the problems, opportunities, and directives. Create a Context Diagram of the proposed system, using the interview presented in this milestone and interview from Milestone 1. Deliverable format and software t.

1. CTTS CASE STUDY - Milestone 2: Problem Analysis
Page: 2-7MILESTONE 2 – PROBLEM ANALYSIS
Synopsis
T
here’s an old saying that suggests, “Don't try to fix it unless you
understand it.” With those words of wisdom, the next milestone
of our project is to study and analyze the existing system. There
is always an existing system, whether computerized or manual
or some of both. The problem analysis phase provides the
project team with a more thorough understanding of the
problems, opportunities, and/or directives that triggered the
project. Indeed, the analyst frequently uncovers new problems
and opportunities. The problem analysis phase may answer the
questions, “Are the problems worth solving?” and “Is a new
system worth building?”
The purpose of the problem analysis phase is threefold. First
and foremost, the project team must gain an appropriate
understanding of the business problem domain. Second, we need
to answer the question, “Are these problems (opportunities, and
directives) worth solving?” Finally, we need to determine if the
system is worth developing. The problem analysis phase
provides the systems analyst and project team with a more
thorough understanding of the problems, opportunities, and/or
directives that triggered the project. In the process, they
frequently uncover new problems and opportunities.
In this milestone you will perform Cause-Effect Analysis and
document your findings using the Problems, Opportunities,
Objectives, and Constraints Matrix. The PIECES framework,

2. originally developed by James Wetherbe, and then adapted by
the authors, can serve as a useful tool to classify the various
problems, opportunities, and directives identified in Milestone
1.
Second, you will develop a Context Diagram to begin to
understand the proposed system and whether or not it is worth
developing. A Context Diagram looks at the system as a whole
and how it interacts with the world around it.
Objectives
After completing this milestone, you should be able to:
Perform Cause-Effect Analysis to be able to thoroughly
understand a system’s problems, opportunities, and/or directives
that triggered the project.
Use and understand the PIECES framework for classifying
problems, opportunities, and directives.
Complete the Problems, Opportunities, Objectives, and
Constraints Matrix.
Create a Context Diagram for the proposed system.
Assignment
Now that we have completed the survey of the system and
gained approval to proceed, we can attempt to gain a better
understanding of the current system and to evaluate whether the
proposed system is worth developing.
Activities
To complete the Problems, Opportunities, Objectives, and
Constraints Matrix, use the interview presented in this
milestone. Use the PIECES framework as a model to classify
the problems, opportunities, and directives.

3. Create a Context Diagram of the proposed system, using the
interview presented in this milestone and interview from
Milestone 1.
Deliverable format and software to be used are according to
your instructor’s specifications.
References:
Case Background
Case Study Introduction
Milestone 1
Solution
Provided by your instructor

4. Transcript of Interview with Peter Charles
Milestone 1, Exhibit 1.1
Transcript of Client Technology Tracking System meeting
Exhibit 2.1
Templates
See on-line learning center website for the textbook.
Deliverables:
Problems, Opportunities, Objectives, and Constraints Matrix:

5. Due: __/__/__
Time:_______
Context Diagram:
Due: __/__/__
Time:_______
Tentative List of Functional and Non-Functional Requirements:
Due: __/__/__
Time:_______
ADVANCED OPTIONS
Write a detailed study report for the phase. This deliverable
was not discussed in the narrative because students need to be
exposed to modeling (data, process, and interface) before this
report can be completed. For those ambitious individuals who
are familiar with those skills and wish to be challenged, use the

6. detailed study report outline found in Chapter 5 of the textbook
as a guideline.
Another advanced option is to develop one or more fishbone
diagrams for problems outlined in the case. To complete this
advanced option, you may need to make some assumptions
about causes and effects.
Study Report:
Due: __/__/__

7. Time:_______
Fishbone Diagrams:
Due: __/__/__
Time:_______
Milestone’s Point Value:

8. ____
The following is a transcript of a meeting of Anna Kelly
(analyst/programmer), Kathy Grey (receptionist/bookkeeper),
Doug Drake (system integrator), and Ben Logan (IT consultant).
Exhibit 2.1
Scene:
The meeting room at Coastline Systems Consulting. Anna Kelly
has just greeted the other participants.
Anna:
OK. I feel a little funny being the most junior member of the
team and leading this meeting. But Peter has asked me to lead a
design project for a proposed customer technology tracking
system. By technology tracking, I mean a system that would
track each of the components installed in each of the computers
and other devices at a client's business as well as track all
configuration information. The system would do some other
things also, such as allow clients to submit service requests and

9. problems and track the progress of the request until it is
resolved. I need your input to design the system correctly. I
need you to help me (1) more fully understand the current
system, (2) understand what we need in the new system and (3)
document any constraints for designing the new system – things
that it either must do or must not do. Each of you has received a
copy of the Request for System Services and the Problem
Statement Matrix. I’d like to start with problems in the current
system. How does the present system work?
Ben:
Here's how it's supposed to work. We keep a three-ring binder
on each client and place in it papers with all the configuration
information. But it doesn't work very well. For one thing, the
papers are disorganized so it is hard to find anything in it. But
the information is never really complete anyway. By the time
you finish a job, you don't have time to update the paperwork
because another job is demanding your attention.
Doug:
Sometimes I make pencil corrections in the binder while I'm on-
site. But after a while that just looks like chicken scratches. The
word processing document never gets updated.
Ben:

10. And yet, without updated information at hand we end up
spinning our wheels the next time we go out to that client. It's
frustrating.
Doug:
It frustrates the clients, too. They see us out there not being
prepared. They complain about the time it takes to fix problems.
I can think of a couple of clients we may have lost because of it.
Ben:
What we need is a searchable database.
Doug:
A database system could solve the disorganization. But if we
don't solve the updating problem, we still won't have a solution.
Anna:
Do you have any ideas on that?
Ben:
For the component tracking, I would suggest barcode scanning.
Nearly every component we buy already has a barcode on it.
Kathy:
How would that work?

11. Doug:
Well, when we put a component into inventory, we would have
to scan the barcode and manually record what kind of
component it is – a NIC, a video card, whatever.
Kathy:
Checking things into inventory is my job. Would scanning be
difficult?
Anna:
It shouldn't be. It would probably save you time because of less
typing. But it would be a small change in the check-in process.
Ben:
Then out in the field we could scan the barcode when we install
the component. The system could pick up the system date
automatically.
Doug:
Of course, you'd also need a barcode on the computer that it was
being installed in. We would need to make sure we used
barcoding on every piece of equipment. It would be as easy as
select "install component" from a menu, then scan the
computer's barcode, then scan the component's barcode, and

12. "Bob's-your-uncle" you're done.
Anna:
Slow down, boys. Let's not write the code yet. But I think we're
onto something – at least for the component tracking. What
about the configuration information? Peter talked about tracking
usernames, passwords, IP addresses and port numbers, and web
addresses. How does that system work now?
Ben:
That stuff is supposed to be in the notebook, too. But that has
the same problems with completeness and accuracy. And the
consequences are sometimes worse. If we lose a password, we
may have to completely reset a router. That's a big time waster,
and Peter doesn't want us to bill a client for things that are
really our fault.
Anna:
So how do we fix that?
Ben:
Configuration information should be in the same searchable
database. Well, we're a small company. We should be able to
convince everyone that it is in their interest to invest the time in
updating it.

13. Doug:
But, let's design the system so it is easy to update.
Anna:
For instance?
Doug:
For instance, we should have to wait until we get back into the
office. The longer we wait the more likely it is that something
else will take precedence. So we have a web-enabled database
we can update from the client's place of business.
Anna:
Jack has already nixed the idea of having configuration and
component information on the Internet for security reasons.
Ben:
Besides, some of that information we need while we are
standing in a wiring closet or sitting under a client's desk or
other places where the Internet isn't accessible.
Anna:
As Peter told me, we can't jump into implantation yet. But by
way of an example, I was thinking about having an intranet

14. application. In our office, it would run on our in-house web
server and connect to a master database. In the field we would
run in on our laptops with a web server running on the laptop
and connecting to a copy of the database.
Doug:
Intriguing. You'd have to work out replicating, or updating, the
data back and forth between the copies and the master.
Ben:
Maybe we could switch to tablet PCs to make data entry even
easier.
Anna:
That's a possibility. What about the service request part of the
system? What is the present system?
Kathy:
Clients call in with reports of problems. Sometimes I can
transfer the call to a consultant. Generally I have to send an e-
mail. If the consultant is out on a call, it may be hours before
the client gets a response. Sometimes the client calls back and
I'll transfer them to whoever is available just so they feel that
something is happening. That's when the confusion starts.

15. Ben:
Yeah, I can't tell you how many times I've come in and found an
e-mail from Kathy on a problem but found out that Jeff or Doug
or even Dane was already working on it. So as it is, before I
start working on a problem, I need to ask around and make sure
no one else is working on it.
Anna:
That sounds like a time waster. We need to eliminate that.
Ben:
Can this part of the system be on the Internet?
Anna:
Yes, Peter suggested it. He even wants clients to be able to
enter their own requests.
Kathy:
Without calling in? That would be wonderful. But if they do
call in, I'll still need a way to enter service request for them.
Ben:
And the techs should be able to enter service requests, too.
Sometimes when we're on-site, clients tell us about other
problems.

16. Anna:
Sounds good.
Ben:
The Problem Statement Matrix said something about
maintaining the history of service on a problem. That would be
great. I often follow-up on things Jeff worked on. I need to
know what he did. That would make me more efficient.
Anna:
Good. That's what I need to cost justify this system.
Kathy:
How are the techs going to know what service requests are
assigned to them?
Ben:
I have a suggestion on that. We really want the next available
tech to take each service request unless there is a compelling
reason to assign it to a specific tech. So let's just have all the
techs view the open list, and they can take the next one. And
they can view the history for any request from that list of
unresolved request.

17. Anna:
Integrate the two functions together.
Ben:
Sure.
Anna:
I'll give it some thought. Sounds good. I'm sure Peter, as
management, would want to view the open requests and their
history, too.
Doug:
And clients should be able to view their own requests and
history. And that brings up a point that the service requests part
of the system will need security, too. We don't want someone
flooding us with bogus requests. Or worse, what if someone
hacked our database and messed up our data. I want this system
to solve problems, not create more.
Ben:
Right. Make sure that only techs can enter work records and
new equipment. And only techs should be able to mark a service
request as resolved.
Doug:

18. Techs get so busy on new requests, they might forget to mark a
request as resolved or to do the follow-up with the client to
make sure it is resolved. Maybe we need a way for the system to
automatically mark a service request as resolved if we don't
hear anything more from the client after so much time.
Anna:
That's a good point. Let me give that some thought. Anything
else we need to discuss?
Kathy:
If you can do all this, it would be great!
Anna:
I know it would help me. Well that gives me plenty to work on.
I’d like to thank each of you for your time. I will be sending
you a copy of my problems, opportunities, objectives, and
constraints matrix, a tentative list of system requirements, and a
context diagram fro the proposed system. Let me know if you
have any comments or questions.
CTTS CASE STUDY - Milestone 1: Scope Definition
Page: 1-2 SHAPE * MERGEFORMAT

19. MILESTONE 1 – SCOPE DEFINITION
Synopsis
T
he purpose of the preliminary investigation phase is threefold.
First, it answers the question, “Is this project worth looking at?”
To answer this question, this phase must define the scope of the
project and the perceived problems, opportunities, and
directives that triggered the project.
In this milestone you will prepare a Request for System
Services, which is the trigger for the Preliminary Investigation
Phase. Also, you will use fact-finding techniques to extract and
analyze information from an interview to determine project
scope, level of management commitment, and project feasibility
for the Client Technology Tracking System. With these facts
and facts obtained from the Case Background, you will have the
necessary information to complete the Problem Statement
Matrix.
Objectives
After completing this milestone, you should be able to:

20. Complete a Request for System Services form, which triggers
the preliminary investigation phase.
Analyze a user interview and extract pertinent facts that can be
used to assess project feasibility.
Complete a Problem Statement Matrix documenting the
problems, opportunities, or directives of the project.
Assignment
Anna Kelly is an analyst/programmer who has been working for
Coastline Systems Consulting for one year since her college
graduation. So far she has handled small web applications for
clients, designing and writing the XHTML, JavaScript, and
.NET code. Anna recently got an idea of how to improve
Coastline's efficiency and customer service. After thinking
about it a few days, she has decided to share it with the
president, Peter Charles.
Refer to the Case Background found in the Introduction and the
interview transcript in Exhibit 1.1for the information necessary
to complete the following activities.
Activities

21. To complete the Request for System Services form, use
information from the case background. Make assumptions where
necessary.
To complete the Problem Statement Matrix, use the interview
with Peter Charles and the case background for the basis of your
information. Make assumptions where necessary. Place yourself
in the shoes of Peter Charles. Which problems do you believe
have the highest visibility, and how should they be ranked? Try
to determine the annual benefits. State assumptions and be
prepared to justify your answers! Finally, what would be your
proposed solution based on the facts you know now?
Deliverable format and software to be used are according to
your instructor’s specifications.
References and Templates:
Case Background
Workbook Introduction

22. Transcript of Interview with Peter Charles
Exhibit 1.1
Templates
See on-line learning center website for the textbook.
Deliverables:
Request for System Services:
Due: __/__/__

23. Time:_______
Problem Statement Matrix:
Due: __/__/__
Time:_______

24. ADVANCED OPTION
For the advanced option, prepare a Project Feasibility
Assessment Report. A template for this report can be
downloaded from the textbook website. Use the information
provided by the case background, the user interview, and the
completed problem statement matrix. Be sure to include a
Statement of Work and Gantt charts for the project schedules.
Information on the Statement of Work and Gantt charts can be
found in Chapter 4 of the SADM 7th ed. textbook.
Project Feasibility Assessment Report:
Due: __/__/__

25. Time:_______
Milestone’s Point Value:
_______
The following is a copy of the transcript of an interview
between Mr. Peter Charles, President, and Anna Kelly, Web
Programmer. This was the initial discussion concerning the
proposed client technology tracking system.
Exhibit 1.1
Scene:
The office of Peter Charles, president of Coastline Systems
Consulting. Peter is working at his desk. Anna Kelly knocks on
the open door.
Anna:

26. Hey, Boss, do you have a few minutes?
Peter:
The door is always open, Anna. Have a seat. What's on your
mind?
Anna:
I have an idea I'd like to bounce off you. I was talking to Ben
the other day. He told me about going out to Fox Motors to
check out a problem with their router. When he got there he
discovered that the router password he had in his files wasn't
right. He had to call back to our office to see if anyone knew
what was going on. Turns out Jeff had replaced the router three
months ago. Jeff had a record of its configuration, but Ben
essentially wasted most of an hour learning what Jeff already
knew.
Peter:
Ouch. Sad to say, that isn't the first time something like that has
happened.
Anna:
Well, it got me thinking.
Peter:

27. How so?
Anna:
I've heard the other consultants tell similar stories. Someone
goes out on a job and doesn't know what another consultant has
already done. What if we build a company-wide database for
storing that information?
Peter:
I like that idea.
Anna:
It would be really simple. It would need to keep all
configuration information for every piece of equipment for
every client. But that shouldn't be so hard.
Peter:
Except that all those pieces of configuration information are
different. Some are usernames and passwords. Some are IP
addresses with or without port numbers. Some are web
addresses where we go to setup databases or e-mail addresses or
whatever else.
Anna:
That just means we need to design the data carefully. I do

28. databases for our web programming clients all the time.
Peter:
There are a couple other pieces of the puzzle that maybe you
haven't thought of since you don't often make field calls.
Anna:
Like what?
Peter:
Like hardware components. We sell and service computers.
Sometimes the servicing gets confusing. Speaking as someone
who has been known to crack open a case at a client's office, we
need keep track of each piece of equipment (computers,
printers, scanners, etc.) that we have in service. We need to
know how each computer is configured in terms of RAM, hard
drive, video card, etc. And we need to know when each
component was purchased, because each has a different
warranty period that we have to honor.
Anna:
I thought we were keeping that information already.
Peter:
We keep notes on that information for each client. But I can tell

29. you that it doesn’t work very well. As a result, Jeff and Ben
sometimes get out on site and don’t have the right equipment or
drivers. Then they have to make a trip back here to get it. We
don’t bill clients for making an extra trip that shouldn’t need to
be made. If it is tourist season that can easily be a wasted hour
that would normally be billed at $75. I bet every week either
Jeff or Ben has a situation like that.
Anna:
(taking notes) Hmmm. That increases the complexity of the
system.
Peter:
Yes, but we should build something that meets our needs. Also,
components change over time. We might like to know what
components were previously installed on each PC and when
they were changed out.
Anna:
Anything else the system should do?
Peter:
Well, let's think about the example with Ben that you opened
with. How did that service call originate? The client called in or
e-mailed in with a problem. I'd like to build an Internet

30. application off our home page that would allow clients to
submit service requests. Then consultants could enter notes of
their work on those requests.
Anna:
If we had had that system, Ben might have known the router had
been changed out before he got there.
Peter:
Right. Plus on ongoing problems, any consultant could access
that history and know what not to do. In addition, this would
probably save Kathy 5 hours a week in answering service
request calls and trying to pass them on to technicians.
Anna:
Having service requests on the Internet is a good idea. But we
can't have the configuration and component information on the
Internet, can we?
Peter:
Heavens no. That would be a hacker's candy store. That part of
the system will have to be secure. I don't want it exposed to the
Internet at all with even the best security.
Anna:

31. But then how will the consultants get at that information out in
the field?
Peter:
Good question. We'll have to think about it. Maybe we can
replicate the data to laptops when they go in the field.
Anna:
What about having our in-house network accessible through a
VPN?
Peter:
That might be okay if our people were always on the Internet
when they are in the field. But they aren't.
Anna:
Then data replication may be the only way.
Peter:
Don't rush to judgment. We'll investigate it.
Anna:
Well, suddenly this system has grown way beyond what I had
envisioned.

32. Peter:
Systems have a way of doing that. That's why we design first
and build second. Anna, I'd like to turn the design of this
project over to you.
Anna:
Thank you. I was hoping you'd say that. I've already been
thinking about how the data would look and some of the
programming routines we would need.
Peter:
Don't jump into implementing it yet. Design first, build second.
Anna:
Sorry. I guess I’m excited. This will be the first full application
I’ve designed and built from the ground up.
Peter:
Yes, and it will be a high profile system both to us and to our
clients. This will help us keep our clients satisfied. It is hard to
put a dollar figure on that without knowing more about what the
current problems cost us in terms of lost or dissatisfied clients.
But if we can make clients happier, it will surely payoff.
Anna:

33. Where do we start?
Peter:
The first step is to prepare a formal Request for System
Services to request the investigation of a system development
project. I'd also like you to do a Problem Statement Matrix.
Anna:
Do we have to do that even when we are requesting our own
services? I mean this system is for our own use.
Peter:
Yes, we do. We have to justify our allocation of human
resources to this project as opposed to projects than generate
client billings. How long do you think it will take you to
complete the project?
Anna:
I wouldn’t know how to begin to estimate it.
Peter:
It comes with experience. But you have some experience
already from working on your other projects. How does this one
compare in terms of complexity of the data?

34. Anna:
My original ideas could have been implemented with a pretty
simple data structure. The PC components and the request
tracking makes it more complex. I guess it is about twice as
complex as the shopping cart application I wrote.
Peter:
So where does all that lead you in terms of a ballpark estimate?
Anna:
I’ll say six months for now. But that is very rough. I would need
to look at it more closely to be sure.
Peter:
Exactly. That is why we design first and build second. Use six
months as your initial estimate. Then we’ll see what the
Problem Statement Matrix and the Request for System Services
say before we start investing any serious time in this.
Anna:
OK. You're the boss, Boss. I'll get right on it.

35. MIS 342
Final Exam – Part 2
Student Name: _____________________________ Student
ID: _________________________________
Good Luck!
1. Mark T (True) or F (False) for the following statements. (2
points)
· Foreign keys cannot have null values. _____
· A primary key must always be unique. _____
2. Discuss briefly (10 points)
a. Identify and briefly explain the importance of the two
characteristics of primary keys? (5)
b. Suppose we have a table for keeping track of the history of
employees' salary as follows: SAL_HIST (Emp#, Salary,
Reason, Raise-Date) representing how many times the employee
had raises. What should be the primary key? Explain your
reasoning. (5)
3. Use the following ERD for questions a

36. CUSTOMER
RECEIVES
INVOICE
APPLIES_TO
PAYMENT
1
N
N
M
cust
_no
lname
pay
_no
date
amount
inv
_no
inv
_total
(a) What are the primary keys of the relationships? (3)

37. APPLIES_TO
4. Design an ER schema with attributes, primary keys,
cardinalities and participation constraints if appropriate.
For keeping track of information about votes taken in the U.S.
House of Representatives during the current two-year
congressional session. The database needs to keep track of each
U.S. STATE’S Name (e.g., Texas, New York,
California) and include the Region of the state (whose domain
is {North-east, Midwest, South-east, Southwest,
West}). Each CONGRESSPERSON in the House of
Representatives is described by his or her name, plus the
District represented, the StartDate, when the congressperson
was first elected, and the political party to which he
or she belongs (whose domain is {Republican, Democrat,
Independent, Other}). The database keeps track of each
BILL (i.e., proposed law), including the BillName, the
DateOfVote on the bill, whether the bill PassedOrFailed

38. (whose domain is {Yes, No}, and the Sponsor (the
congressperson(s) who sponsored-that is , proposed-the bill).
The database keeps track of how each congressperson voted on
each bill (domain of vote attribute is {Yes, No,
Abstain, Absent}). Draw an ER schema diagram for this
application. State clearly any assumptions you make.
(10 Points)
3
_1263795992.doc
CUSTOMER
RECEIVES
INVOICE

39. APPLIES_TO
PAYMENT
1
N
N
M

40. cust_no
lname
pay_no
date
amount
inv_no
inv_total

41. CTTS CASE STUDY – Final Exam Part 1
MILESTONE 4 – DATA MODELING
· Activity 1 – Entity/Definition Matrix
Entity/Definition MatrixENTITY
BUSINESS DEFINITIONEntity NameEntities Business
Definition

42. · Activity 2 – Conseptual Data Model
T
his model should be constructed based on the entities identified
in Activity 1. All of the cardinalities of the major entities can
be determined from the interview or the forms.
· Activity 3 – Key-Based Logical Data Model
T
his model is constructed by adding the primary keys and
Foreign Keys to the model in Activity 2. The primary keys are
based on how the user uniquely identifies each entity.

44. Final Exam
Machine nameProcessorRAMNICVideo CardHard
DriveCD/DVDUser
MertzP4512Built-inRadeon 9200Maxtor 40GbTeac DVD+RW
ChildP4256Built-inGeForce2 64MBMaxtor 60 Gb.Sony
CDRW/DVDAJM
RamboP4512Built-inMaxtor 40GbTeac CD RWIsiah A.
GilliganP4512Built-innVidiaMaxtor 60gb.Sony CDRW/DVDJB
Richland
MollP4512Built-inMaxtor 30 GbTeac DVD+RWLaura
PoeP4256Linksys 10/100IBM 80 Gb.Teac CD-ROMMark
BradburyAthlon512SMC9452TXMaxtor 40GbSony
CDRW/DVDVanessa
MarlowP4512Linksys 10/100GeForce2 64MBMaxtor 20 GbSony
CD-ROM
DeSotoP4512Built-inWestern Dig. 40 GbTeac DVD+RWRich
PrincetonP4512Built-inGeForce2 64MBSeagate 60 GbSony
CDRW/DVD

45. FragAthlon512Built-inMaxtor 90 GbTeac DVD+RWJennifer
HoserAthlon512SMC9452TXTeac CD-ROMLisa
RoseAthlon XP256Netgear FA311 10/100GeForce
128MBMaxtor 60 GbSony CDRW/DVDNorma
TroiP4256Linksys LNE100TXSeagate 60 GbSony
CDRW/DVDRebecca
NimitzP4512Netgear FA311 10/100Radeon 9200Maxtor 90
GbTeac CD-ROMMary
BeetleP4512Linksys LNE100TXIBM 80 Gb.Teac CD RWBeth
C.
ReverbP4256Linksys 10/100IBM 20 GbTeac CD RWLab
ReliantP4512SMC9452TXIBM 80 Gb.CD RW/DVDLab
TigerP4512Netgear FA311 10/100IBM 40Gb.CD RW/DVDLab
GooberPentium M512802.11gRadeon 9200Maxtor 40 Gb.Sony
CD-ROMLab
LamerP4512Built-inSeagate 30 Gb.Teac CD-ROMLab
BugP4512Built-inIBM 40 Gb.ATA CD RWLab
OkieDokieP4512Netgear FA311 10/100All-In-WonderMaxtor
40 GbTeac CD RWCIS
EnolaP4512802.11gIBM 40 Gb.CD RW/DVDCIS
WolfmanP4512Linksys LNE100TXGeForce 128MBSony
CDRW/DVDCIS
HorsefeathersP4512Netgear FA311 10/100Teac CD-ROMSonya
EncroachmentPentium M512Netgear Wireless-G Western Dig.
40GbSony CD-ROMByron

46. CoyoteP4512Linksys LNE100TXIBM 40Gb.ATA CD
RWStephanee
SwordfishP4512Netgear FA311 10/100Maxtor 40GbATA CD
RWTeriMILESTONE 4 – DATA MODELING
· Synopsis
D
ata modeling is a technique for organizing and documenting a
system’s data. Data is viewed as a resource to be shared by as
many processes as possible. As a result, data must be organized
in a way that is flexible and adaptable to unanticipated business
requirements – and that is the purpose of data modeling.
In this milestone you will first discover those entities in the
system that are or might be described by data. With each entity
we identify, we will define it in respect to the business. Then,
we will construct a Context Data Model that graphically depicts
each of the entities and the relationships they have with each
other. Next, we will refine the context data model to include
primary and foreign keys. The resulting model is called a Key-
Based Data Model. Finally, we refine the key-based data model
to include any hierarchies and attributes, and this model is
referred to as the Fully Attributed Data Model.
· Activities

47. 1. Complete an Entity/Definition Matrix. Analyze each of the
forms referenced by the user interview plus any comments made
by Jeff Summers. Make assumptions where necessary.
2. Prepare a Conseptual Data Model.
3. Prepare a Key-Based Logical Data Model.
References:
Milestone 3