CTTS CASE STUDY – Milestone 3: Modeling System

CTTS CASE STUDY – Milestone 3: Modeling System Requirements Page 3-1
MILESTONE 3 – MODELING SYSTEM REQUIREMENTS
• Synopsis
The requirements analysis phase answers the question, ‘What does the user need and want
from the new system?’ The requirements analysis phase is critical to the success of any new
information system! In this milestone we need to identify what information systems requirements
need to be defined from the system users’ perspectives.
Use-case modeling has gained popularity as a technique for expressing system requirements for
two reasons: (1) it facilitates user-centered development, which often leads to building systems
that better satisfy user needs, and (2) use cases diagrams and narratives are easy for users to
understand.
In this milestone you will first uncover the actors, use cases, and relationships that define the
requirements for the proposed system and document that information in a Use-Case Glossary.
You will use that to build a Use-Case Model Diagram for the system and a Use-Case Narrative
for one use case.
• Objectives
After completing this milestone, you should be able to:
⇒ Understand and perform the techniques for requirements discovery.
⇒ Determine actors, use cases, and relationships.
⇒ Construct a Use-Case Glossary.
⇒ Construct a Use-Case Model Diagram.
⇒ Write a fully-documented Use-Case Narrative.
3.
CTTS
CTTS CASE STUDY – Milestone 3: Modeling System Requirements Page 3-2
• 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 Coastline 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.
• Activities
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.
Deliverable format and software to be used are according to your instructor’s specifications.
Deliverables should be neatly packaged in a binder, separated with a tab divider labeled
“Milestone 3”.
References:
Milestone 2 Solution
Provided by your instructor
Transcripts of Interview
Exhibit 3.1
Templates
See on-line learning center website for the textbook.
Deliverables:
Use-Case Glossary: Due: __/__/__
Time:_______
Use-Case Model Diagram: Due: __/__/__
Time:_______
Fully-documented Use Case Narrative: Due: __/__/__
Time:_______
CTTS CASE STUDY – Milestone 3: Modeling System Requirements Page 3-3
ADVANCED OPTION
For the advanced option, prepare fully-documented Use-Case Narratives for additional use
cases as directed by your instructor.
Fully-documented Use Case Narratives: Due: __/__/__
Time:_______
Milestone’s Point Value: _______
CTTS CASE STUDY – Milestone 3: Modeling System Requirements Page 3-4
CTTS CASE STUDY – Milestone 3: Modeling System Requirements Page 3-5
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
Coastline Systems Consulting. The goal of this interview was to determine requirements for the
proposed system.
Exhibit 3.1
Scene: The meeting room at Coastline Systems Consulting. Anna Kelly is interviewing Peter
Charles, Jeff Summers, and Dane Wagner about the system requirements for the
Customer Technology Tracking System.
Anna: What I want to get out of this meeting is consensus on everything the Customer
Technology Tracking System needs to do and who will be using each part of that
functionality. I’ll try to keep us on track so this won’t take too much time.
Peter: Sounds good, Anna. Let’s 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: We’ll 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 what’s 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.
CTTS CASE STUDY – Milestone 3: Modeling System Requirements Page 3-6
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 you’re 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.
Jeff: Or while I’m on site fixing one problem, a client tells me about another problem.
Anna: OK. What else?
Jeff: There’s 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.
CTTS CASE STUDY – Milestone 3: Modeling System Requirements Page 3-7
Dane: Don’t 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
what’s 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) I’ll 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. Let’s see if I can turn this into some use cases.
Peter: I’ll look forward to seeing them.
SADM 5/ed – CASE STUDY 4 – Milestone 3: Data Modeling Page: 3-8
Prepared by Gary B. Randolph for
Systems Analysis & Design Methods 5ed
by J. L. Whitten, L. D. Bentley, & K. C. Dittman Copyright Irwin/McGraw-Hill 2001
TAKE ADVANTAGE OF OUR PROMOTIONAL DISCOUNT DISPLAYED ON THE WEBSITE AND GET A DISCOUNT FOR YOUR PAPER NOW!