IS6127/IS6152: Assessment

Title: Client Configuration Tracking System

Due Date: Friday December 1st before 9.00 PM

Where: Please submit your projects on blackboard.

Marks: Project is worth 50% of module marks

Individual Project
 Case Background
Dragon Systems Consulting is a provider of managed computer networks and web services located
in Destin, Florida. The staff of seven IT technicians, web designers, and systems integrators
provides a range of networking, computer hardware, and software solutions to area businesses.
Dragon works with clients to analyze their business needs. They then provide a packaged solution
that often combines web services, networking and computer hardware, purchased software, and
custom programming. In addition to the seven technicians, Dragon has one receptionist/bookkeeper.
As a small organization, Dragon is an informal, "shirt-sleeve" environment. Everyone is on a first-
name basis, even with Peter Charles, the president.

Organization Structure

Dragon Systems Consulting

 Information Systems Facilities

PCs
Each technician works uses a Dell notebook:
o Pentium M class machines with 4 Gig RAM, 1 TB hard drives
The bookkeeper/receptionist has a Dell Optiplex desktop running a Pentium 4, 1 GB
RAM, and an 500 GB hard drive:
Operating systems - MS Windows Windows 10
Tools - MS Office 2016 suite plus other software depending on use
Internet Browser Edge and Mozilla FireFox
E-mail Client - Mozilla Thunderbird
Various inkjet and laser printers

Servers
Dell PowerEdge 2800 Server
o 8 GB of RAM, I TB RAID-5 hard drive storage
o Operating system - MS Windows Server 2011
o Providing DHCP, Security, and Internet Access, and Database Management (SQL
Server 2000)
Dell PowerEdge 1850 Server
o Providing Web hosting
o Operating system Windows Server 2003 with IIS

Networking
The company headquarters is equipped with wireless networking so notebooks can roam
throughout the building. Notebooks also have integrated Ethernet NICs and modems so
they can connect to the Internet at home and at clients' places of business.

The Problem
As Dragon's client base and the complexity of installations have grown, keeping track of the clients'
hardware and software configurations has become a nightmare. Each client PC contains various
components, such as video cards, NICs, and keyboards which are replaced at different times and so
have differing warranty periods that must be tracked. Every client has multiple PCs and network
devices, whose passwords and configurations must be accessible by technicians in the Dragon
office and in the field. One technician is "on-call" every weekend, meaning the data has to be
accessible from home as well. This has to be organized in a way that is easily accessible by any
technician at any time or place but secure from unauthorized users.

In addition to tracking components and passwords, clients call and e-mail the Dragon office
whenever they have any kind of hardware or software problem. These requests and the work done
to resolve them need to be organized and documented.

The president, Peter Charles, wants to develop a system that is both responsive to clients and
helpful to technicians. He would like to see a system that allows technicians to access and update
client equipment hardware and software configurations. He wants an easy way for technicians to
track the installation of new hardware components, possibly using barcode scanning. He wants the
system to allow clients to directly enter their service requests, allow technicians to document the
work done on those requests, and for everyone to be able to see the history and status of each
request. Mr. Charles also wants the system to be able to generate statistics and reports so he can
pursue continuous improvement in this area.

Assignment
Anna Kelly is an analyst/programmer who has been working for Dragon 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 Dragon's efficiency and customer service. After thinking about it a few days, she has
decided to share it with the president, Peter Charles.

Deliverables Part 1
1. To complete the Request for System Services form, use information from the case background.
Make assumptions where necessary.
2. 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?
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
configuration tracking system.

Exhibit 1.1
Scene: The office of Peter Charles, president of Dragon Systems Consulting. Peter is working
at his desk. Anna Kelly knocks on the open door.
Anna: 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: 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 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 you that it doesnt
work very well. As a result, Jeff and Ben sometimes get out on site and dont have the
right equipment or drivers. Then they have to make a trip back here to get it. We dont
bill clients for making an extra trip that shouldnt 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 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: 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.
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 Im excited. This will be the first full application Ive 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: 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 wouldnt 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?
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: Ill 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 well 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.
 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.

Deleiverables Part 2
1. 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.
2. Create a tentative list of requirements for the proposed system, classifying each as a
functional or non-functional requirement.
3. Create a zero level DFD (Context) for the entire system.
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 Dragon 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
configuration tracking system. By configuration 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 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. Id 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: 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?
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 "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.
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 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 connecting to a web application which connects to 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. We could also
make the application accessible from a mobile phone this could really save us lugging
laptops or touch screens around.
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.
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.
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.
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: 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. Id 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 from the proposed system. Let me know if you have any comments or
questions.
 Assignment
Now that we have studied the current system and analyzed some of its problems and
opportunities, plus gained approval to proceed, we can now start to identify the business
requirements for the system and model them. In this assignment we will use our results of the
previous milestones and transcripts of an interview with president Peter Charles, IT consultant
Jeff Summers, and web server administrator Dane Wagner of Dragon Systems Consulting. The
results of this activity will identify the system requirements for the proposed system.
Exhibit 3.1 is a copy of the transcript of the interview. Refer to the transcript, sample forms, and
results from Milestones 1 and 2 for the information necessary to complete the activities.

Deliverables Part 3
1. Complete a Use-Case Glossary. Make assumptions where necessary.
2. Prepare a Use-Case Model Diagram.
3. Prepare a fully-documented Use-Case Narrative for the View Unresolved Requests use case
described in the interview.

The following is a copy of the transcript of an interview conducted by Anna Kelly with president
Peter Charles, IT consultant Jeff Summers, and web server administrator Dane Wagner of
Dragon Systems Consulting. The goal of this interview was to determine requirements for the
proposed system.

Exhibit 3.1
Scene: The meeting room at Dragon Systems Consulting. Anna Kelly is interviewing Peter
Charles, Jeff Summers, and Dane Wagner about the system requirements for the
Customer Configuration tracking System.
Anna: What I want to get out of this meeting is consensus on everything the Customer
Configuration tracking System needs to do and who will be using each part of that
functionality. Ill try to keep us on track so this wont take too much time.
Peter: Sounds good, Anna. Lets go.
Anna: I already know the basic functions for the system. Clients need to be able to service
requests. Technicians need to enter their records of work on those requests. We also
need to track hardware components installed in a client's equipment and software
configuration information. What else?
Peter: Well also need to be able to set up clients and even employees, also. But I suppose the
employee entry is so rare that we can ignore that for your initial high-level modeling.
Anna: Right. Who would set up clients?
Peter: I'd like to have Kathy [Kathy Gray, the receptionist/bookkeeper] do that. That way the
client will be entered the same way as it is in our billing system.
Dane: One thing I think would be helpful would be for the techs to be able to view a list of
their unresolved requests and view the complete history of any request and all the work
done on it. Sometimes I have so many things on my plate, I can forget some of them.
Peter: That's a good idea, Dane. As a manager I'd like to see that, too, to see whats going on.
Of course, each Tech would see all of his or her own unresolved requests. I'd like to see
everyone's unresolved requests, but just those that have been open for more than 72
hours. We could even allow clients to view their own unresolved requests.
Jeff: (laughing) Then we better be careful what our techs write in the memos.
Peter: We should anyway. Remember our clients are our partners and our bread and butter.
Jeff: Oh, I know, Boss. If we are checking unresolved requests, then we need some way to
mark them resolved to take them out of the unresolved list.
Dane: Good point. We might view several unresolved requests and be able to mark one or two
as resolved.
Anna: That makes sense.
Jeff: Or sometimes we know that an issue is resolved as soon as we put in the work record.
You know, we stick in a video card, and the system works again.
Anna: So youre saying that we need to be able to resolve a request in a couple of ways.
What should that process look like?
Dane: First, I should only get to any of this functionality after I logon. We want to keep this
secure from people other than clients and employees. So If I view unresolved requests,
the system shows me a list depending on who am I. I can click on any one of those
requests either to see the history or to mark it as resolved. We just as well give clients
the right to mark their own requests as resolved. They would probably know if the
problem is still a problem. If we do mark a request as resolved, then the system records
the resolved date and shows us the updated list of unresolved requests.
Anna: Do you both agree?
Peter: I need to do some thinking about whether I want clients to be able to mark a request as
resolved. If they accidentally marked one as resolved, it could mess up the entire
system.
Jeff: You know, some of the support systems I work with for software that we use e-mail me
a suggested fix. Then 48 hours later if they haven't heard from me with a follow-up
question, they e-mail me and say they will assume the issue is resolved if they don't
hear from me in another 24 hours.
Anna: In other words, requests are automatically marked as resolved if so much time goes by
and they don't hear back from you.
Jeff: Right. I'm wondering if that could work. Clients wouldn't be able to directly mark a
request as resolved, but indirectly they could by not responding.
Peter: I like that better. But the clock on automatic resolution only starts ticking after we have
responded somehow sent an e-mail, done some work, whatever.
Anna: I'll make a note of that. Other requirements?
Dane: I also think that more than just clients need to be able to add service requests. I know
that sometimes a client phones in a problem and Kathy needs to enter it to the system.
 Both ourselves and the clients also need to be able to run a series of reports which tell
us if service requests have been started and completed. For the client, they should be
able to select by date and status of request. For ourselves, we should be able to select
for a single client or all clients, start date, complete date and status.
Jeff: Or while Im on site fixing one problem, a client tells me about another problem.
Anna: OK. What else?
Jeff: Theres also the component end of it. Viewing the list of components installed in a
piece of equipment. Adding a new component to a piece of equipment. Or for that
matter, installing a completely new piece of equipment for a client.
Dane: Dont forget that your list of standard components changes pretty frequently. We used
to sell plain, vanilla CD-ROM drives. Now it's all combination CD-ROM rewritable
and DVD drives or CD-ROM rewriteable and DVD rewriteable drives. Who knows
whats next? It would save us entry time if we kept a list of those standard components
so as we make entries we could just pick one from the list.
Jeff: Right. This is less frequent, but sometimes we need to change the list of standard
equipment types. You know PCs, servers, routers, printers.
Anna: Who would update the lists of standard components and standard equipment types?
Peter: Anyone could anyone who is actually in the system, that is. Remember that the
component and software configuration parts of the system cannot be on the Internet. So
it would be employees only.
Anna: Right. I talked with Ben and Doug last week about using barcoding with component
entry. That would require using barcodes when Kathy checked-in inventory.
Peter: Sounds like a good idea. That would really tie our installed components to our
purchases. That means the inventory check-in will also have to be part of the system.
Anna: Right. What about the software configuration part of the system?
Dane: In some ways it will be simpler than the components. You won't have standard lists of
things like with the components. The techs will just enter the configuration information.
It is kind of freeform information.
Jeff: Well, not entirely freeform. I envision it a little like the Windows registry a tree
structure of client and equipment and then a series of name/value pairs. For instance,
Client X's router would have a configuration entry with the name of password and a
value of x7u@1. But maybe that's just me. I'm a geek.
Anna: It's an interesting idea, Jeff, but a little premature. For now I just need to know the
system requirements and who will do what with the system. Is there anything else along
those lines that we need to discuss? (no one speaks) Ill take your silence as a sign to
quit before you dream up any more work for me. Thank you for your time. This was a
productive session. Lets see if I can turn this into some use cases.
Peter: Ill look forward to seeing them.
 Assignment
In this assignment we will use our results of the previous milestones and transcripts of an
interview with IT consultant Jeff Summers and receptionist/bookkeeper Kathy Grey, both of
Dragon Systems Consulting. The results of this activity will identify the business data
requirements for the proposed system.
Exhibit 4.1 is a copy of the transcript of the interview. Refer to the transcript, sample forms, and
results from Milestones 1-3 for the information necessary to complete the activities.

Deliverables Part 4
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. Entity relationship diagram
3. Prepare a UML Class Diagram
4. Candidate systems matrix
5. Feasibility matrix
The following is a copy of the transcript of an interview conducted by Anna Kelly with IT
consultant Jeff Summers and receptionist/bookkeeper Kathy Gray of Dragon Systems
Consulting. The goal of this interview was to obtain sample forms and to ask questions about
them to discover data entities of the system.

Exhibit 4.1
Scene: The meeting room at Dragon Systems Consulting. Anna Kelly scheduled the interview
to obtain instructions and sample forms for designing the data structure for the
customer response system.
Jeff: Good morning, Anna!
Anna: Good morning, Jeff. Good morning, Kathy. Thanks for taking the meeting.
Jeff: You requested some samples of the forms we use now out on site. Here are copies of
the main forms I think will be relevant.
Anna: Great! That will be a big help. I think you have received copies of the use case glossary,
diagram, and narratives. The use cases and those forms you brought will be guiding our
discussion in this meeting. What I want to accomplish is to get answers on some
questions I have concerning the data requirements.
Jeff: The first form is the PC Configuration Sheet [Exhibit 4.2]. This is just a spreadsheet
that we currently use to keep track of equipment in each PC. We build one of these
sheets for each client where we service hardware and keep it in our disorganized
binders.
Anna: OK. Are these columns all the pieces of information that need to be tracked for each
PC?
Jeff: I dont think this whole format works very well. A few years ago we had to change the
name of the CD-ROM column to CD/DVD when DVD drives started getting popular.
Anna: Today, we may need a column for mouse as we are getting all kinds of specialty mice
and other pointing devices on the market.
Jeff: We may need a column for web cam, also. But the point is that we dont want to be
restructuring the data every time theres a technology shift. Also, we have a problem
with this format in that it doesnt allow for multiple hard drives or multiple CD ROMs.
That happens pretty often.
Anna: I see. So we ought to move away from having specific components as fields.
Jeff: That's what I think. For each machine, we should be able to enter any number of
components. And for each component, we should be able to select a component type
from a list and then fill in the detailed information.
Anna: When I was talking to Ben and Doug about it the other week, they thought we could
use barcodes to speed the entry process and tie the information back to when we check
it into inventory.
Jeff: I can see how that would help. As you can see from the spreadsheet, some of our data is
pretty sketchy. A barcode would tie each entry to a specify model number.
Anna: I've never worked with barcodes in an information system.
Jeff: I have. Every barcode symbol is associated with a numeric or alpha-numeric identifier.
The identifier is printed just above or below the barcode symbol, so you can actually
see what it is. When you scan the barcode, that identifier is entered into the computer
just as if someone had typed the identifier on the keyboard. Often the identifier is the
serial number of the component, so every one is unique.
Anna: I see. How long are those identifiers?
Jeff: It varies. But I think 20 characters should be sufficient.
Anna: But then we would end up with the equivalent of this spreadsheet filled with identifiers.
That would be less informative than what we have already. That's where that Check In
Inventory use case comes in. Kathy, how do you check in inventory now?
Kathy: I have an Access database. I type in model number, a description of the item, quantity,
date purchased, and the vendor.
Anna: Not the purchase price?
Kathy: No. That information is in the accounting system. But it isn't relevant to inventory.
Anna: OK. We would need those same pieces of information. Plus we would need you to scan
the barcode.
Kathy: Sounds like more work.
Anna: An extra second or two to scan the barcode. But I remember about a month ago you had
to dig up a list of all Teac DVD+RW drives brought into inventory over a three month
period.
Kathy: Oh, yes. What a hassle that was! That was to see if a particular drive was still under
warranty.
Anna: Well, I think this new system could eliminate those searches. We would tie every
installed component to a specific purchase date with the barcode.
Kathy: Then that would be well work the extra second. But I heard Jeff say that "often" the
identifier is a unique serial number. What about cases where it's just a model number?
That wouldn't be unique and so we couldn't tie the installed component to a specific
purchase date.
Anna: I'll put that on my open issues list to check out. Worst-case scenario is that we put our
own barcode on those items. We could generate a whole list of unique numbers and
print barcode labels for them. It would be an extra step to apply those labels...
Kathy: But still worth it in the long run.
Anna: I'm glad you agree. What else do we have to talk about with the component end of the
system?
Jeff: Well, lets say I replace the video card. I know what the PC now has. But I dont know
what it had before, how long that component was in service.
Anna: So you want a history of each PC.
Jeff: From a component standpoint, I just need to see a list of all components that have ever
been in the PC, when those components were added, and when they were removed.
Anna: Its not that Im questioning your processes, but why do you need to know about
components that are no longer in a PC?
Jeff: For one thing, clients like us to tell them about PCs that are causing problems over and
over. Another reason is so on continuing problems we can see what was tried before.
Anna: That makes sense. So we don't want to just write over the information of the old
component with the information of the new component. We want to keep adding to the
list with an installed date and a removed date.
Jeff: For things such as RAM, I need to track a quantity, too.
Anna: OK. Given the changes you want, I think we ought to define the word component.
Jeff: Good question. You have to think about how we buy and upgrade. Sometimes we buy a
complete system with CPU, monitor, mouse, keyboard the works in one package.
Anna: If you buy it as one unit, do you get all the detailed component information and enter it
to the columns?
Jeff: No, because if we bought it as a unit we let the vendor service it as a unit under
warranty. In those cases a complete system would be a single component. But then later
we upgrade a hard drive, add RAM, replace something, etc. A replacement NIC can be
a separate component.
Anna: I know we custom build some PCs. What about them?
Jeff: A PC that we build from individual parts is all components.
Anna: So, if everything is a component, is there any information that pertains to the PC in
general?
Jeff: Yes. First of all, this PC Configuration Sheet doesnt show it, but we need to track
whether we are talking about a PC, a printer, a router, a hub or some other kind of
technology equipment.
Anna: We service all those?
Jeff: If by service, you mean repair, then no. But if you mean make sure it is operational and
handle sending it in for warranty work, then yes.
Anna: So I should call it equipment instead of PC. What else do we track about each piece of
equipment?
Jeff: Each piece of equipment is given a name. We let the users name their own machines.
Sometimes they change them. Also, everything has an In Service Date. And, of
course, we track which client owns the equipment.
Anna: I notice this sheet tracks the user.
Jeff: Yeah. But tracking the user just doesnt work. We dont get informed of personnel
turnover. So we go into an office months later and cant find the people we have on file.
 Thats why we have started using a numeric ID for each piece of equipment. We just
have it printed on a sticker that we attach to the machine.
Anna: I think that covers the equipment and component questions. What about the software
configurations?
Jeff: I brought along some sample information [Exhibit 4.3]. This isn't all the kinds of
configuration information we track. But it is representative.
Anna: Walk me through this, if you would.
Jeff: We see the client name at the top: Family Vacation Rentals. All this configuration
information pertains to them. The DSL IP is simple. They have a DSL line, and this is
the static IP address for it. The other items are more complex. You see we have a LAN
IP for the network server. We also have the administrator username and password for
that server. Then we have the LAN IP and username/passwords for three different
logins for the SQL Server machine. We have a little configuration information for the
network router, also it's LAN IP and username/password. There should be more
information on the router, such as the DHCP range, port forwarding information, etc.
Anna: Can't you just view all that information on the router once you login?
Jeff: Sure. Unless the router dies. Then we need to have it documented.
Anna: Got it. I can think of several ways to structure this data. Could we just dump all this
information into a memo type of field?
Jeff: I've brought you a short one. Some of these configuration lists are pages and pages. We
desperately need some organization so it can be searched.
Anna: So one big memo field isn't a good idea. I'll have to think through the pros and cons of
various implementations. That leaves the service requests. Unfortunately we dont have
any forms for that, do we?
Kathy: Not unless you count sticky notes and e-mails.
Anna: So lets approach it this way: What information do you need to communicate to a tech
when a service request comes in?
Kathy: Well, which client it is, of course. Also a description of the problem and the person
reporting the problem.
Jeff: If it deals with a particular machine, we need that, too. But not all do. Some deal with
web hosting or software.
Kathy: And the date when the request comes in. Sometimes that is a point of contention.
Anna: All right. Then we need to track the work a technician does on a request. What would
that look like?
Jeff: Well, we would want the date of that work and the technician's initials and kind of a
memo pad for notes.
Anna: Earlier we had talked about a mechanism for marking requests as resolved. So we need
that tracked. My opinion is a resolution date field would give us better information in
the long run than a resolution checkbox.
Jeff: Makes sense. We had also talked about an automatic resolution mechanism after a tech
does work. So we need a FinishTime field. We just as well have a StartTime field, too.
If a task has remained unresolved for a defined period of time(probably set up in the
system configuration), then the task will be escalated to the supervisor for this client or
technician..
Anna: OK. This system is about client service requests and client equipment and client
configurations. What kind of general information do we need to keep on each client?
Kathy: They are all companies with company names. And we always have a primary contact
person.
Jeff: I dont know how many times Ive needed a client phone number or e-mail address or
mailing address. I would say we should have all that data handy in the system.
Anna: Thats a good point, Jeff. Wow. Im glad I talked with you two. This is giving me lots
of good information. In fact, I think I have everything I need now to design the data.
Jeff: Were just glad youre working on this system. It sounds like a lifesaver.
Anna: Well, thanks for your time. You have both been a big help.
Exhibit 4.2

PC Configuration Sheet

Machine name Processor RAM NIC Video Card Hard Drive CD/DVD User
Mertz P4 512 Built-in Radeon 9200 Maxtor 40Gb Teac DVD+RW
Child P4 256 Built-in GeForce2 64MB Maxtor 60 Gb. Sony CDRW/DVD AJM
Rambo P4 512 Built-in Maxtor 40Gb Teac CD RW Isiah A.
Gilligan P4 512 Built-in nVidia Maxtor 60gb. Sony CDRW/DVD JB Richland
Moll P4 512 Built-in Maxtor 30 Gb Teac DVD+RW Laura
Poe P4 256 Linksys 10/100 IBM 80 Gb. Teac CD-ROM Mark
Bradbury Athlon 512 SMC9452TX Maxtor 40Gb Sony CDRW/DVD Vanessa
Marlow P4 512 Linksys 10/100 GeForce2 64MB Maxtor 20 Gb Sony CD-ROM
DeSoto P4 512 Built-in Western Dig. 40 Gb Teac DVD+RW Rich
Princeton P4 512 Built-in GeForce2 64MB Seagate 60 Gb Sony CDRW/DVD
Frag Athlon 512 Built-in Maxtor 90 Gb Teac DVD+RW Jennifer
Hoser Athlon 512 SMC9452TX Teac CD-ROM Lisa
Rose Athlon XP 256 Netgear FA311 10/100 GeForce 128MB Maxtor 60 Gb Sony CDRW/DVD Norma
Troi P4 256 Linksys LNE100TX Seagate 60 Gb Sony CDRW/DVD Rebecca
Nimitz P4 512 Netgear FA311 10/100 Radeon 9200 Maxtor 90 Gb Teac CD-ROM Mary
Beetle P4 512 Linksys LNE100TX IBM 80 Gb. Teac CD RW Beth C.
Reverb P4 256 Linksys 10/100 IBM 20 Gb Teac CD RW Lab
Reliant P4 512 SMC9452TX IBM 80 Gb. CD RW/DVD Lab
Tiger P4 512 Netgear FA311 10/100 IBM 40Gb. CD RW/DVD Lab
Goober Pentium M 512 802.11g Radeon 9200 Maxtor 40 Gb. Sony CD-ROM Lab
Lamer P4 512 Built-in Seagate 30 Gb. Teac CD-ROM Lab
Bug P4 512 Built-in IBM 40 Gb. ATA CD RW Lab
OkieDokie P4 512 Netgear FA311 10/100 All-In-Wonder Maxtor 40 Gb Teac CD RW CIS
Enola P4 512 802.11g IBM 40 Gb. CD RW/DVD CIS
Wolfman P4 512 Linksys LNE100TX GeForce 128MB Sony CDRW/DVD CIS
Horsefeathers P4 512 Netgear FA311 10/100 Teac CD-ROM Sonya
Encroachment Pentium M 512 Netgear Wireless-G Western Dig. 40Gb Sony CD-ROM Byron
Coyote P4 512 Linksys LNE100TX IBM 40Gb. ATA CD RW Stephanee
Swordfish P4 512 Netgear FA311 10/100 Maxtor 40Gb ATA CD RW Teri
Exhibit 4.3
Software Configurations

Family Vacation Rentals

DSL IP: 69.210.15.30

Network Server:
LAN IP: 192.168.100.5
Username: administrator
Password: funinsun05

SQL Server:
LAN IP: 192.168.100.6
Username: sa / Password: gumb@ll
Username: dba / Password: gummyw0rm
Username: user / Password: goodnplenty

Router:
LAN IP: 192.168.100.1
Username: admin / Password: cotton76
Deliverables
In summary, you must deliver the following:
Request for system services
Problem statement matrix
Problems, Opportunities, Objectives, and Constraints Matrix
A tentative list of requirements for the proposed system, classifying each as a functional or
non-functional requirement.
Zero level data flow diagram (Context diagram) for entire system
Use-Case Glossary.
Use-Case Model Diagram.
Fully-documented Use-Case Narrative
Entity definition matrix
Entity Relationship Diagram
Class diagram just show properties dont include methods.
Candidate systems matrix
Feasibility Matrix

NOTE: When submitting on blackboard:

Make sure you submit a single zip file
Ensure the file name is name__studentnumber_is6XXX_.zip
Inside the zip file, ensure that all files have clear names.
All files will be either word or excel apart from the class diagram and entity relationship
diagram which will be Visio.