Friday
April 25, 2014

Homework Help: system analysis and palnning

Posted by dipaksinh on Thursday, July 26, 2012 at 11:07pm.

objective

The Milestone Assignments are based on the Projects and Cases for use with the Systems Analysis and Design Methods textbook by Whitten & Bentley.
There are six (6) parts to the Project, consisting of twelve (12) milestones. During Weeks 2-7, you will be required to complete two (2) milestones. Each milestone is worth 40 points. Milestones 5 and 10 are included as already completed work, so you only need submit them as part of the assignment.

Guidelines

Be sure to read the Project area of each Assignment section, as they talk directly to the milestone tasks. Also, for review purposes, note that typical milestone solutions will be posted on Wednesday morning of the following week. This is necessary as it is important for you to observe your errors as you further build on your cases. Note: Once milestone solutions are posted, no late work can be accepted.
Client Technology Tracking System - Case Introduction
The milestones will be graded based on how well they convey the needed information, use of tools and techniques for the section involved, and timeliness of submission.
Note: Please upload your completed assignments to the Dropbox as directed. Please be sure to submit BOTH milestone assignments to the Dropbox using ONE Word document. (Also, please paste created diagrams and illustrations from other software—like Visio—into this document.


Basic Tasks in Visio 2010
Visio 2010 Training



Part 1 of 6: Milestones 1 & 2 (80 pts.) - Due Week 2

Be sure to read the Project area of each Assignment section, as they talk directly to the milestone tasks. Also, for review purposes, note that typical milestone solutions will be posted on Wednesday morning of the following week. This is necessary as it is important.
Deliverables:
• Request for System Services form
• Problem Statement Matrix
• Context Diagram
• Problems, Opportunities, Objectives, and Constraints Matrix
• Tentative List of Functional and Non-Functional Requirements
Review all of the Milestone project steps below. Post questions in the CTTS Milestone discussion area.
Milestone 1
The 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 (CTTS). With these facts and facts obtained from the Case Background, you will have the necessary information to complete the Problem Statement Matrix.
Milestone 1 Instructions
For this milestone, you will be using the following templates/resources:
• Click here for Template A
• Click here for Template B
Note: Please be sure to submit BOTH milestone assignments to the Dropbox using ONE Word document. (You may paste created diagrams and illustrations from other software as needed.)
Milestone 2
There’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 business system, regardless of whether it currently uses a computer. 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 a cause-effect analysis on the Client Technology Tracking System (CTTS) 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.
Milestone 2 Instructions
For this milestone, you will be using the following templates/resources:
• Click here for Template C
Note: Please be sure to submit BOTH milestone assignments to the Dropbox using ONE Word document. (You may paste created diagrams and illustrations from other software as needed.)

Part 2 of 6: Milestones 3 & 4 (80 pts.) - Due Week 3

Be sure to read the Project area of each Assignment section, as they talk directly to the milestone tasks. Also, for review purposes, note that typical milestone solutions will be posted on Wednesday morning of the following week. This is necessary as it is important.
Deliverables:
• Use-Case Glossary
• Use-Case Model Diagram
• Use-Case Narrative
• Entity Definition Matrix
• Context Data Model
• Key-Based Data Model
• Fully Attributed Data Model
Review all of the milestone project steps below. Post questions in the Milestone Virtual Lab Forum discussion area.
Milestone 3
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.
Milestone 3 Instructions
For this milestone, you will be using the following templates/resources:
• Use-Case Glossary - create in Word or Excel
• Use-Case Narrative
Milestone 4
The requirements analysis phase answers the question, “What does the user need and want from a 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 and draw graphical, logical models to document the data requirements for a new and improved system.
Data modeling is a technique for organizing and documenting a system’s data. Data modeling is sometimes called database modeling because a data model is usually implemented as a database. 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. Then we will define each entity we identify in respect to the business. Then we will construct a Context Data Model that graphically depicts each of the entities and their relationships 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.
Milestone 4 Instructions
For this milestone, you will be using the following templates/resources:
• Entity Definition Matrix - create using Word or Excel (see Table 8-5)
• Context Data Model - create using Visio or other drawing tool
• Key-Based Data Model - create using Visio or other drawing tool
• Fully Attributed Data Model - create using Visio or other drawing tool
Note: Please be sure to submit BOTH milestone assignments to the Dropbox using ONE Word document. (You may paste created diagrams and illustrations from other software as needed.)


Part 3 of 6: Milestones 5 & 6 (40 pts.) - Due Week 4

Be sure to read the Project area of each Assignment section, as they talk directly to the milestone tasks. Also, for review purposes, note that typical milestone solutions will be posted on Wednesday morning of the following week. This is necessary as it is important.
Deliverables:
• Entity Relationship Diagram in Third Normal Form
• Context Diagram
• Event Decomposition Diagram
• Four Event Diagrams of Your Choosing
• System Diagram
• Primitive Data Flow Diagram
Review all of the milestone project steps below. Post questions in the Milestone Virtual Lab Forum discussion area.
Milestone 5
The purpose of this milestone is to normalize the data model created in Milestone 4, along with additional data requirements, to be in third normal form. This work has already been completed for you and you should have accessed the deliverable and include as part of your Milestone 3. Note that there are no points for this milestone.
Milestone 5 Instructions
This milestone was completed using the following templates/resources:
• Entity Relationship Diagram - create using Visio or other drawing tool
Milestone 6
Process modeling is a technique for organizing and documenting the structure and flow of data through a system’s processes and/or the logic, policies, and procedures to be implemented by a system’s processes. In this milestone, we focus on using and constructing data flow diagrams (DFDs) and decomposition diagrams to perform process modeling. Data flow diagrams are tools that depict the flow of data through a system and the work or processing performed by that system. A decomposition diagram is a DFD planning tool that shows the top-down functional decomposition and structure of a system. During this milestone, you will first construct a context diagram to establish project scope and boundaries. Secondly, you will draw an event decomposition diagram to partition the system into logical subsystems and/or functions. Thirdly, you will draw event diagrams to model individual processes. Finally, you will construct a system data flow diagram that shows the big picture of the system, and a primitive data flow diagram for a single event process.
Milestone 6 Instructions
For this milestone, you will be using the following templates/resources:
• Context Diagram - create using Visio or other drawing tool
• Event Decomposition Diagram - create using Visio or other drawing tool
• Event Diagrams - create using Visio or other drawing tool
• System Diagram - create using Visio or other drawing tool
• Primitive Data Flow Diagram - create using Visio or other drawing tool
Note: Please be sure to submit BOTH milestone assignments to the Dropbox using ONE Word document. (You may paste created diagrams and illustrations from other software as needed.)


Part 4 of 6: Milestones 7 & 8 (80 pts.) - Due Week 5

Be sure to read the Project area of each Assignment section, as they talk directly to the milestone tasks. Also, for review purposes, note that typical milestone solutions will be posted on Wednesday morning of the following week. This is necessary as it is important.
Deliverables:
• Activity Diagram
• Potential Object List
• System Sequence Diagram
• Class Diagram
• Candidate Matrix
Review all of the milestone project steps below. Post questions in the Milestone Virtual Lab Forum discussion area.
Milestone 7
Object-oriented analysis emphasizes the integration of processes and data. Like data and process modeling, object modeling is a technique for defining business requirements for a new system. But where traditional data modeling (ERDs) model just the static data and traditional process modeling (DFDs) model the processes of the system, object modeling integrates data and process concerns into constructs called objects.
The object modeling technique uses methodologies and diagramming notations that are completely different from the ones used for data and process modeling. These techniques are part of the Unified Modeling Language (UML). Object-oriented analysis techniques are best suited to projects that will implement systems using emerging object technologies. However, they can be used with any implementation technology.
In Milestone 3, we used use cases to model system requirements. Use case diagrams are one type of UML model. In this milestone, we will transform a use case narrative into an activity diagram that will graphically depict the process steps of the use case. We will also identify objects, their data attributes, and relationships that support the required business functionality and model them in an object class diagram.
Milestone 7 Instructions
For this milestone, you will be using the following templates/resources:
• Activity Diagram - create using Visio or other drawing tool
• Update Exhibit 7.1 - copy the chart into Word and update as required
• Draw a class diagram - create using Visio or other drawing tool
Milestone 8
The purpose of the decision analysis phase is to identify candidate solutions, analyze those candidate solutions, and recommend a target system that will be designed and implemented. Alternative solutions to be considered should be those that address the business requirements of the information system.
In this milestone, you will complete a candidate matrix. This matrix will include three alternative candidate solutions that you have determined will meet the business requirements for the CTTS. Some of the solutions you will consider may have been posed from the design ideas and opinions from the system owners and users. Others may come from various sources, including systems analysts, system designers, technical consultants, and other information systems (IS) professionals. Some technical choices may be limited by a predefined, approved technology architecture provided by system managers. When completing the matrix, it is not your intent to evaluate the candidates at this point, only to identify and define them.
Milestone 8 Instructions
For this milestone, you will be using the following templates/resources:
• Click here for Template A (Candidate Matrix)
Note: Please be sure to submit BOTH milestone assignments to the Dropbox using ONE Word document. (You may paste created diagrams and illustrations from other software as needed.)

Part 5 of 6: Milestones 9 & 10 (40 pts.) - Due Week 6

Be sure to read the Project area of each Assignment section, as they talk directly to the milestone tasks. Also, for review purposes, note that typical milestone solutions will be posted on Wednesday morning of the following week. This is necessary as it is important.
Deliverables:
• Physical DFD
• Relational Database Schema
Review all of the milestone project steps below. Post questions in the Milestone Virtual Lab Forum discussion area.
Milestone 9
Just as we modeled business requirements during systems analysis, we should model technology architecture and requirements during systems design. The models serve as blueprints for system design, prototyping, and construction.
In this milestone you will prepare a physical data flow diagram. Physical data flow diagrams model the technical and human design decisions to be implemented as part of an information system. They communicate technical and other design constraints to those who will actually implement the system—in other words, they serve as a technical blueprint for the implementation.
Milestone 9 Instructions
For this milestone, you will be using the following templates/resources:
• Physical DFD - create using Visio or other drawing tool
Milestone 10
All information systems create, read, update, and delete data. This data is stored in files and databases. To fully exploit the advantages of database technology, a database must be carefully designed. Database design translates the data models that were developed for the system users during the requirements analysis phase into database structures supported by the chosen database technology. Subsequent to database design, system builders will construct those data structures using the language and tools of the chosen database technology. Like Milestone 5, this part of the assignment has been completed and the deliverable is available for you to include in the weekly milestone. Note that there are no points for this milestone.
Milestone 10 Instructions
For this milestone, you will be using the following templates/resources:
o Relational database schema - create using Visio or other drawing tool
Note: Please be sure to submit BOTH milestone assignments to the Dropbox using ONE Word document. (You may paste created diagrams and illustrations from other software as needed.)

Part 6 of 6: Milestones 11 & 12 (80 pts.) - Due Week 7

Be sure to read the Project area of each Assignment section, as they talk directly to the milestone tasks. Also, for review purposes, note that typical milestone solutions will be posted on Wednesday morning of the following week. This is necessary as it is important.
Deliverables:
• Output Design (Screen)
• Input Design (Screen)
• User Interface Design (Screen)
• Design Use Case
• Sequence Diagram
• Design Class Diagram
• State Machine Diagram
Review all of the milestone project steps below. Post questions in the Milestone Virtual Lab Forum discussion area.
Milestone 11
Management and users make important decisions based on system outputs. Outputs present information to system users. Outputs, the most visible component of a working information system, are the justification for the system. These outputs are produced from data that is either retrieved from databases or, more often, input by users.
Good input and output design can make the difference in whether or not an information system is used effectively. User interface design provides a roadmap or dialog that integrates the inputs and outputs.
In this milestone, you will design outputs, inputs, and user interface for the CTT System.
Milestone 11 Instructions
For this milestone you will be using the following templates/resources:
• Outputs - create using Visio or other drawing tool
• Inputs - create using Visio or other drawing tool
• Interface - create using Visio or other drawing tool
Milestone 12
In performing object-oriented analysis (Milestone 7), we identified objects and use cases based on ideal conditions and independent of any hardware or software solution. During object-oriented design, we want to refine those objects and use cases to reflect the actual environment of our proposed solution.
In this milestone, you will first transform the use case course of events prepared in Milestone 7 to be a design use case. Secondly, we will model the use case with an object robustness diagram. We will also construct a sequence diagram for the use case. Finally, we will transform our object class diagram from Milestone 7 into a design class diagram.
Milestone 12 Instructions
For this milestone, you will be using the following templates/resources:
o Design use-case - create using Visio or other drawing tool
o Sequence diagram for the analysis use case - create using Visio or other drawing tool
o Partial design class diagram - create using Visio or other drawing tool
Note: Omit the object robustness diagram.






Client Technology Tracking System
INTRODUCTION

I
n this section you will learn background information that will prepare you to understand and complete each of the milestones of this case study. This information includes a history of the business, a description of the business’s current facilities, and the descriptions of the problems that triggered the project.
 Case Background
Coastline 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. Coastline 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, Coastline has one receptionist/bookkeeper.

As a small organization, Coastline is an informal, "shirt-sleeve" environment. Everyone is on a first-name basis, even with Peter Charles, the president.



 Organization Structure

Coastline Systems Consulting




 Information Systems Facilities
PCs
• Each technician works uses a Dell notebook:
o Pentium M class machines with 512 MB RAM, 30-50 GB hard drives
• The bookkeeper/receptionist has a Dell Optiplex desktop running a Pentium 4, 256 MB RAM, and an 80 GB hard drive:
• Operating systems - MS Windows Windows XP Professional
• Tools - MS Office 2003 suite plus other software depending on use
• Internet Browser – IE 6 and Mozilla FireFox
• E-mail Client - Mozilla Thunderbird
• Various inkjet and laser printers
Servers
• Dell PowerEdge 2800 Server
o 1 GB of RAM, 80 GB RAID-5 hard drive storage
o Operating system - MS Windows Server 2003
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 Coastline'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 Coastline 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 Coastline 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.



Be sure to read the Project area of each Assignment section, as they talk directly to the milestone tasks. Also, for review purposes, note that typical milestone solutions will be posted on Wednesday morning of the following week. This is necessary as it is important.
Deliverables:
• Request for System Services form
• Problem Statement Matrix
• Context Diagram
• Problems, Opportunities, Objectives, and Constraints Matrix
• Tentative List of Functional and Non-Functional Requirements
Review all of the Milestone project steps below. Post questions in the CTTS Milestone discussion area.
Milestone 1
The 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 (CTTS). With these facts and facts obtained from the Case Background, you will have the necessary information to complete the Problem Statement Matrix.
Milestone 1 Instructions
For this milestone, you will be using the following templates/resources:
• Click here for Template A
• Click here for Template B
Note: Please be sure to submit BOTH milestone assignments to the Dropbox using ONE Word document. (You may paste created diagrams and illustrations from other software as needed.)
Milestone 2
There’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 business system, regardless of whether it currently uses a computer. 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 a cause-effect analysis on the Client Technology Tracking System (CTTS) 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.
Milestone 2 Instructions
For this milestone, you will be using the following templates/resources:
• Click here for Template C


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 and, if assigned, construct the Project Feasibility Assessment Report.
 Objectives
After completing this milestone, you should be able to:

 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.
 Prepare and understand the structure and content, of the Project Feasibility Assessment Report.
 Prerequisites
Before starting this milestone the following topics should be covered:
1. The scope definition phase - Chapters 3 and 5
2. Optional – project management - Chapter 4
 Assignment
PROBLEM STATEMENT MATRIX

PROJECT: <insert name of system> PROJECT MANAGER: <instructor’s name>
CREATED BY: <student name> LAST UPDATED BY: <student name>
DATE CREATED: MM/DD/YYYY DATE LAST UPDATED: MM/DD/YYYY

Brief Statements of Problem, Opportunity, or Directive Urgency Visibility Annual Benefits Priority or Rank Proposed Solution
EXAMPLE:
1. The dollar amount of lost, stolen, or damaged tools has exceeded $125,000 per year.
6 months
High
(Physical Plant Management)
In the thousands.
1
New Development
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?
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 1” and accompanied with a Milestone Evaluation Sheet.
References and Templates:
Case Background
Workbook Introduction
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: __/__/__
Time:_______
Problem Statement Matrix: Due: __/__/__
Time:_______
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: __/__/__
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: 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 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 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 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: 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?
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.



MILESTONE 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.
The third step in this milestone moves us from the problem analysis phase into the requirements analysis phase, which will be covered more fully in Milestone 3. You will make a list of system requirements and classify them as either functional or non-functional.

 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.
 List functional and non-functional requirements for the system.
 Prerequisites
Before starting this milestone the following topics should be covered:
1. The problem analysis phase – Chapters 3 and 5
2. Problem analysis techniques – Chapter 6
3. PIECES Framework – Chapter 3 and 5
4. Milestone 1 Solution
 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
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 Context Diagram of the proposed system, using the interview presented in this milestone and interview from Milestone 1.
3. Create a tentative list of requirements for the proposed system, classifying each as a functional or non-functional requirement.
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 2” and optionally accompanied with a Milestone Evaluation Sheet.
References:
Case Background
Case Study Introduction
Milestone 1 Solution
Provided by your instructor
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:
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 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: __/__/__
Time:_______

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


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 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: 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 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.
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. 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.

PROBLEM STATEMENT MATRIX

PROJECT: <insert name of system> PROJECT MANAGER: <instructor’s name>
CREATED BY: <student name> LAST UPDATED BY: <student name>
DATE CREATED: MM/DD/YYYY DATE LAST UPDATED: MM/DD/YYYY

Brief Statements of Problem, Opportunity, or Directive Urgency Visibility Annual Benefits Priority or Rank Proposed Solution
EXAMPLE:
2. The dollar amount of lost, stolen, or damaged tools has exceeded $125,000 per year.
6 months
High
(Physical Plant Management)
In the thousands.
1
New Development
3.
4.
5.
6.
7.
8.



<INSERT COMPANY NAME HERE>

Phone: Fax:



DATE OF REQUEST SERVICE REQUESTED FOR DEPARTMENT(S)
MM/DD/YYYY

SUBMITTED BY (key user contact) EXECUTIVE SPONSOR (funding authority)
Name Name
Title
Title
Office Office
Phone Phone

TYPE OF SERVICE REQUESTED:
0 Information Strategy Planning 0 Existing Application Enhancement
0 Business Process Analysis and Redesign 0 Existing Application Maintenance (problem fix)
0 New Application Development 0 Not Sure
0 Other (please specify _______________________________________________________________________

BRIEF STATEMENT OF PROBLEM, OPPORTUNITY, OR DIRECTIVE (attach additional documentation as necessary)






BRIEF STATEMENT OF EXPECTED SOLUTION



ACTION (ISS Office Use Only)

0 Feasibility assessment approved Assigned to _<name of student>_

0 Feasibility assessment waived Approved Budget $ _____________
Start Date __ _____ Deadline _ ___

0 Request delayed Backlogged until date: ______________

0 Request rejected Reason: ________________________________________________
Authorized Signatures:
_____________________________________ _________________________________________________
Project Executive Sponsor





Milestone 3
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.
Milestone 3 Instructions
For this milestone, you will be using the following templates/resources:
• Use-Case Glossary - create in Word or Excel
• Use-Case Narrative
Milestone 4
The requirements analysis phase answers the question, “What does the user need and want from a 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 and draw graphical, logical models to document the data requirements for a new and improved system.
Data modeling is a technique for organizing and documenting a system’s data. Data modeling is sometimes called database modeling because a data model is usually implemented as a database. 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. Then we will define each entity we identify in respect to the business. Then we will construct a Context Data Model that graphically depicts each of the entities and their relationships 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.
Milestone 4 Instructions
For this milestone, you will be using the following templates/resources:
• Entity Definition Matrix - create using Word or Excel (see Table 8-5)
• Context Data Model - create using Visio or other drawing tool
• Key-Based Data Model - create using Visio or other drawing tool
• Fully Attributed Data Model - create using Visio or other drawing tool
Note: Please be sure to submit BOTH milestone assignments to the Dropbox using ONE Word document. (You may paste created diagrams and illustrations from other software as needed.)

Be sure to read the Project area of each Assignment section, as they talk directly to the milestone tasks. Also, for review purposes, note that typical milestone solutions will be posted on Wednesday morning of the following week. This is necessary as it is important.
Deliverables:
• Entity Relationship Diagram in Third Normal Form
• Context Diagram
• Event Decomposition Diagram
• Four Event Diagrams of Your Choosing
• System Diagram
• Primitive Data Flow Diagram










MILESTONE 3 – MODELING SYSTEM REQUIREMENTS

 Synopsis
T
he 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.
 Prerequisites
Before starting this milestone the following topics should be covered:
5. Requirements discovery – Chapter 6
6. Use-case modeling – Chapter 7
7. Milestone 2 Solution
 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:_______

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: _______




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.
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.
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.


Author (s): _______________ Date: ___________
Version: ___________
USE CASE NAME: USE CASE TYPE
USE CASE ID: Abstract: 
PRIORITY: Extension: 
INVOKED BY:
PARTICIPATING ACTORS:
DESCRIPTION:
PRE-CONDITION:
TYPICAL COURSE
OF EVENTS: Step 1:


ALTERNATE COURSES:
POST-CONDITION:











MILESTONE 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.
 Objectives
After completing this milestone, you should be able to:

 Understand and perform the techniques for entity discovery.
 Define each entity with respect to the business and complete an entity/definition matrix.
 Perform the necessary data modeling techniques to organize and document the data requirements for the proposed system.
 Construct the Context, Key-Based, and Fully Attributed data models.
 Prerequisites
Before starting this milestone the following topics should be covered:
8. Data modeling – Chapter 8
9. Milestone 3 Solution

 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 Coastline 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.
 Activities
4. 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.
5. Prepare a Context Data Model.
6. Prepare a Key-Based Data Model.
7. Prepare a Fully Attributed Data Model. Add the data attributes for each entity.
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 4”.
References:
Milestone 3 Solution
Provided by your instructor
Transcripts of Interview with Jeff Summers and Kathy Grey and Accompanying Sample Forms and Report
Exhibits 4.1-4.5

Templates
See on-line learning center website for the textbook.

Deliverables:
Entity Definition Matrix: Due: __/__/__
Time:_______
Context Data Model: Due: __/__/__
Time:_______
Key-Based Data Model: Due: __/__/__
Time:_______
Fully Attributed Data Model: Due: __/__/__
Time:_______

ADVANCED OPTION
For the advanced option, assume that the proposed system must also track purchase orders for buying software components from vendors. Your instructor will specify additional system requirements for this part of the system. Modify your initial Entity Definition Matrix and Fully Attributed Data Model to be able to handle this system requirement.
Entity Definition Matrix: Due: __/__/__
Time:_______
Fully Attributed Data Model: Due: __/__/__
Time:_______



Milestone’s Point Value: _______



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.

Exhibit 4.1
Scene: 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!
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 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?
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, let’s say I replace the video card. I know what the PC now has. But I don’t 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: It’s not that I’m 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 doesn’t 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 doesn’t work. We don’t get informed of personnel turnover. So we go into an office months later and can’t find the people we have on file. That’s 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 don’t have any forms for that, do we?
Kathy: Not unless you count sticky notes and e-mails.
Anna: So let’s 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.
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 don’t know how many times I’ve 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: That’s a good point, Jeff. Wow. I’m 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: We’re just glad you’re 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




Exhibit 4.3
Software Configurations





Milestone 5
The purpose of this milestone is to normalize the data model created in Milestone 4, along with additional data requirements, to be in third normal form. This work has already been completed for you and you should have accessed the deliverable and include as part of your Milestone 3. Note that there are no points for this milestone.
Milestone 5 Instructions
This milestone was completed using the following templates/resources:
• Entity Relationship Diagram - create using Visio or other drawing tool
Milestone 6
Process modeling is a technique for organizing and documenting the structure and flow of data through a system’s processes and/or the logic, policies, and procedures to be implemented by a system’s processes. In this milestone, we focus on using and constructing data flow diagrams (DFDs) and decomposition diagrams to perform process modeling. Data flow diagrams are tools that depict the flow of data through a system and the work or processing performed by that system. A decomposition diagram is a DFD planning tool that shows the top-down functional decomposition and structure of a system. During this milestone, you will first construct a context diagram to establish project scope and boundaries. Secondly, you will draw an event decomposition diagram to partition the system into logical subsystems and/or functions. Thirdly, you will draw event diagrams to model individual processes. Finally, you will construct a system data flow diagram that shows the big picture of the system, and a primitive data flow diagram for a single event process.
Milestone 6 Instructions
For this milestone, you will be using the following templates/resources:
• Context Diagram - create using Visio or other drawing tool
• Event Decomposition Diagram - create using Visio or other drawing tool
• Event Diagrams - create using Visio or other drawing tool
• System Diagram - create using Visio or other drawing tool
• Primitive Data Flow Diagram - create using Visio or other drawing tool
Note: Please be sure to submit BOTH milestone assignments to the Dropbox using ONE Word document. (You may paste created diagrams and illustrations from other software as needed.)
Be sure to read the Project area of each Assignment section, as they talk directly to the milestone tasks. Also, for review purposes, note that typical milestone solutions will be posted on Wednesday morning of the following week. This is necessary as it is important.
Deliverables:
• Activity Diagram
• Potential Object List
• System Sequence Diagram
• Class Diagram
• Candidate Matrix
Review all of the milestone project steps below. Post questions in the Milestone Virtual Lab Forum discussion area.











MILESTONE 5 – DATA MODEL NORMALIZATION

 Synopsis
I
n this milestone you will normalize the data model created in Milestone 4, along with additional data requirements, to be in third normal form.

 Objectives
After completing this milestone, you should be able to:

 Normalize a logical data model to remove impurities that can make a database unstable, inflexible, and non-scalable.
 Prerequisites
10. Data analysis - Chapter 8
11. Milestone 4 Solution
 Assignment
The goal of this project is to normalize our logical data model to remove impurities that can make a database unstable, inflexible, and non-scalable.

 Activities
8. To construct an Entity Relationship Diagram to be in 3rd Normal form, follow the normalization procedure outlined in Chapter 8 of the SADM 7th ed. textbook. Use feedback from your the ERD solution of Milestone 4 as well as the data dictionary provided at the end of this milestone to prepare the new data model.
9. Specify all data types (your instructor will specify the target database or allowable set of data types).
10. Specify all primary and foreign keys.
11. Specify which attributes are required (not nullable).
12. Add and normalize additional entities and attributes as directed by your instructor. Make assumptions where necessary.
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 5”.
References:
Previous Milestone Solutions
Provided by your instructor
Data Attribute Dictionary
Provided at the end of this milestone
Refer to a Copy of Your Fully Attributed Data Model Created for Milestone 4.
Deliverables:
Logical Data Model in 3rd Normal Form: Due: __/__/__
Time:_______

Milestone’s Point Value: _______


Data Attribute Dictionary

Below is a Data Attribute Dictionary that contains all the attributes and definitions. Note: the attributes below are listed in alphabetical order, not by entity.

Address A 30-character alphanumeric field holding the client’s street or box address.
Barcode A 20-character alphanumeric barcode ID that is either pre-printed on each component package or added via a label at Coastline Consulting.
City A 20-character alphanumeric field holding the name of the client’s city.
ClientID A system-generated large integer numeric value unique to each client.
ClientName A 50-character alphanumeric field holding the client’s company name.
ComponentType A 10-character alphanumeric classification of the type of component.
ConfigurationID A system-generated large integer numeric value unique to each software configuration record.
ContactFirstName A 20-character alphanumeric field consisting of the first name of the client contact person.
ContactLastName A 30-character alphanumeric field consisting of last name of the client contact person.
DateInstalled Date field consisting of the date a component was installed into a piece of equipment.
DatePurch A date field representing the date a component was purchased.
DateRemoved Date field consisting of the date a component was removed from a piece of equipment.
Description A 30-character description of the component.
Email A 70-character alphanumeric field consisting of the client contact’s e-mail address.
Equipment A 20-character alphanumeric description of the piece of equipment, if any, for a software configuration record.
EquipName A 15-character alphanumeric field holding the identifying name for the piece of equipment
EquipNum A system-generated numeric value unique to each piece of equipment.
EquipType A 10-character alphanumeric field identifying the equipment as PC, Printer, Scanner, etc.
FinishTime A time field holding the time a technician finished work on a request.
InfoName A 20-character alphanumeric description of the information stored in a software configuration record.
InfoValues A 50-character alphanumeric information value stored in a software configuration record.
InServiceDate A date field consisting of the date the piece of equipment was placed in service.
ModelNum A 10-character alphanumeric identifier of the model number of the component.
Quantity A numeric field specifying the quantity of items installed as an EquipmentComponent. This is always a whole number. An inspection of past forms shows no quantity exceeding 50.
ReportDate A date field holding the date a service request was reported.
ReportedBy A 50-character alphanumeric field holding the first and last name of the person reporting a service request.
ReqNum A system-generated large integer numeric value unique to each service request.
ResolutionDate A date field holding the date a service request was resolved.
StartTime A time field holding the time a technician began work on a request.
State A 2-character abbreviation for the client’s state.
TechInitials A 3-character alphanumeric field consisting of the initials of the technician performing work.
Vendor A 30-character field holding the name of the vendor from whom a component was purchased.
WorkDate A date field consisting of the date a technician did work on a request.
WorkDescription A large alphanumeric field describing the work done on a work record.
WorkNum A system-generated large integer numeric value unique to each work record.
Zip A 10-character alphanumeric postal code of a client.










MILESTONE 6 – PROCESS MODELING

 Synopsis
P
rocess modeling is a technique for organizing and documenting the structure and flow of data through a system’s processes and/or the logic, policies, and procedures to be implemented by a system’s processes. In this milestone we focus on using and constructing data flow diagrams (DFDs) and decomposition diagrams to perform process modeling.
Data flow diagrams are tools that depict the flow of data through a system and the work or processing performed by that system. A decomposition diagram is a DFD planning tool that shows the top-down functional decomposition and structure of a system.
During this milestone you will first construct a context diagram to establish project scope and boundaries. Secondly, you will draw an event decomposition diagram to partition the system into logical subsystems and/or functions. Thirdly, you will draw event diagrams to model individual processes. Finally you will construct a system data flow diagram that shows the big picture of the system, and a primitive data flow diagram for a single event process.
 Objectives
After completing this milestone, you should be able to:

 Construct a context diagram to illustrate a system’s interfaces with its environment.
 Identify external and temporal business events for a system.
 Logically group events to create an event decomposition diagram.
 Create event diagrams.
 Merge event diagrams into a system data flow diagram.
 Draw appropriate primitive data flow diagrams.
 Prerequisites
12. Process modeling - Chapter 9
13. Optional: Solutions for Milestone 1-5

 Assignment
The preliminary investigation and problem analysis phases of the methodology have been completed and you understand the current system’s strengths, weaknesses, limitations, problems, opportunities, and constraints. You have already built the data model (Milestones 4 and 5) to document business data requirements for the new system. You now need to build the corresponding process models.
 Activities
13. If you have not already drawn a Context Diagram in Milestone 2, draw one now based on the meeting transcript in Exhibit 2.1 of Milestone 2 plus the accompanying use-case (event/response) matrix in Exhibit 6.1. Note that not everything in the transcript is related to the Context Diagram.
14. Given the accompanying use-case (event/response) matrix in Exhibit 6.1, draw the Event Decomposition Diagram. For background information on each use case, see the meeting transcript in Exhibit 3.1 of Milestone 3 and Exhibit 4.1 of Milestone 4.
15. Given your decomposition diagram from above and the use-case matrix, draw Event Diagrams. Your instructor will tell you which ones to draw. Use your data model from Milestones 3 and 4 as an attribute reference. Also, state any assumptions you make.
16. Merge your event diagrams from #3 above into a System Diagram.
17. For all transaction processes described in the accompanying narrative, draw the Primitive Data Flow Diagram.
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 6”.
References:
Completed Solutions from Prior Milestones
Completed Use-Case (or Event-Response) List
Exhibit 6.1
Primitive Diagram Narrative(s)
Exhibit 6.2
Deliverables:
Context Diagram: Due: __/__/__
Time: _______
Decomposition Diagram: Due: __/__/__
Time: _______
Event Diagrams: Due: __/__/__
Time: _______
System Diagram: Due: __/__/__
Time:_______
Primitive Diagram(s): Due: __/__/__
Time: _______

ADVANCED OPTION
Exhibit 6.1 is a partial use-case (event/response) list. Add the following maintenance Use-Cases: Enter/Edit Component Type, Enter/Edit Equip Type, Enter New Client. See the meeting transcript in Exhibit 3.1 of Milestone 3 for detailed information on these use cases. Draw the Event Diagrams and the System Diagram based on the complete list.
Event Diagrams: Due: __/__/__
Time: _______

System Diagram: Due: __/__/__
Time: _______

Milestone’s Point Value: _______



Exhibit 6.1
Below is a Use-Case list for the major processes of the system. For more information on each of these use cases, see the meeting transcripts in Exhibit 3.1 of Milestone 3 and Exhibit 4.1 of Milestone 4.

Actor(s) Event
(or Use-Case) Trigger Responses
Client
Technician
Receptionist/Bookkeeper Enter Service Request Upon request Create new Service Request in database

Client
Technician
Management View Unresolved Requests/History Upon request Display service request information and, optionally, work history on the request on screen
Technician Enter Work Record Tech performs work Create new Work Record in database
Technician Manually Resolve Service Request When problem is solved Update Resolution Date field in Service Request in database
Time Automatically Resolve Service Request 48 hours after last Work Record Email sent to client

Update Resolution Date field in Service Request database if no response from client in 24 hours
Technician Enter Component Information New component is installed Create new Equipment Component in database
Technician Enter New Equip New equipment is installed for client Create new Equipment in database
Technician View Software Configuration Info Upon request with search criteria for keywords Display configuration information on screen
Receptionist/Bookkeeper Check In Inventory Inventory comes in Create new Inventory in database.
Technician Enter Configuration Information New or revised configuration information Update Configuration in database
Technician View Installed Components Upon request with Equip criteria Display Component information on screen
Any Employee Enter/Edit Equip Type List of Equipment Types needs to be updated Equipment Type data is updated
Any Employee Enter/Edit Component Type List of Component Types needs to be changed Component Type data is updated
Receptionist/Bookkeeper Enter New Client New Client signs contract New Client added in database


Exhibit 6.2
Use the following narrative to construct the Primitive Diagram for the Enter Component Information event.
The user will select the Enter Component option from the user interface. The technician will be asked to identify the client. Depending on implementation, the client selection may need to be checked for validity. If it is not valid, send an error response to the user. The system will then display a list of equipment installed for that client. The user will select the appropriate piece of equipment where the component was installed. Depending on implementation, the equipment selection may need to be checked for validity. If it is not valid, send an error response to the user. The system will then provide a screen requesting that the user select the type of component. The user will then scan the barcode of the item that is being installed. The DateInstalled will default to the current system date, and the Quantity will default to 1. Both can be changed by the user. The new component information will then be recorded in the data store and a confirmation message will be given to the user.

Answer this Question

First Name:
School Subject:
Answer:

Related Questions

Analysis & Design - A milestone is a goal or objective and deliverables from the...
psychology - 1.Identify a typical developmental milestone for a person at a ...
math - An objective function and a system of linear inequalities representing ...
Objective functon - An objective function and a system of linear inequalities ...
Financial Management of Healthcare Organizations - The objective of your Final ...
aiu - Analysis techniques include the following: • Comparative financial ...
lab.... - when doing a lab you need an anayliss, but what is it and how do I ...
PSYCHOLOGY IN SOCIAL LIFE - A planning committee has decided to determine the ...
Human Resources Management - The certification process in skill-based pay is ...
motion analysis - 5. (a) Using the information below estimate the time required ...

Search
Members