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 Coastline 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.
The meeting room at Coastline 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!
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 1.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 don’t 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 don’t want to be restructuring the data every time there’s a technology shift. Also, we have a problem with this format in that it doesn’t 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?
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?
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.
An extra second or two to scan the barcode. But I remember about a...
Please join StudyMode to read the full document