Problem statement

Develop a working definition and description of the problem you will be solving. Include details from client meeting and project proposal. Identify metrics answering the following question: What are the desired outcomes? How will you know when you've solved the client's problem?

*Individual writing assignment means each person must write his/her own unique draft.

Competencies translating client demands into technical solutions; articulating development goals in writing; creating performance metrics

Assignment Description Now that you have met your project group and have (hopefully) contacted and heard back from your client, you need to sit down with them and really hammer out what, exactly, your project is intended to be. As we all know, some of the project descriptions on Capstone web site are rather...vague. In many cases, that vagueness is due to the limited space on the original project template, rather than any confusion in the mind of the project client.

Sit down (most likely virtually) with your client, and have a conversation about what project is. Within the context and boundaries of their initial ideas, make your voice heard. After all, this is your project to design and implement. Please do not be pushy or rude, and remember that you have to make your client happy with the project. This assignment will be individually graded; however, you can discuss your ideas with your teammates and share any research resources you might have, if you choose to.

To Write List ● Project abstract (Links to an external site.)​ summarizing the entire document in 100-150

words. We will be discussing how to write an abstract during our next class. ● Definition and description of the problem you are trying to solve written for a general, but

educated audience ● Proposed solution ● Performance metrics: Tell how you will know when you have completed the project.

Metrics help you and your client agree on what successful completion (e.g., % faster, $-amount cheaper, easier to use, "a working prototype," a complete white paper with research results) of the project looks like.

Keep in mind, the point of this document is to define the project in a way that leaves both you and the client happy.

This document is not intended as a requirements document, which is much longer, more detailed, and written for a more technical audience than the problem statement. For this assignment, you will be providing the reader with 10,000 foot view through descriptions and definitions.

LaTeX help:

https://www.sharelatex.com (Links to an external site.)

https://guides.library.oregonstate.edu/intro_to_latex (Links to an external site.)

Format Guidelines ● Word count:​ approximately 1000 words ● Spacing: single ● Font: 10 pt serif (computer modern or similar) ● Geometry: Letter paper, 0.75" margins ● Title page: required. Include name, class, title, term, abstract (at minimum) ● Abstract: required on title page ● Style: IEEETran ​(You can google this to find the template.) ● Columns: 1 (use draftclsnofoot,onecolumn options to document class) ● Document type: PDF ● Captions: required on all figures, must be meaningful ● Code listings: using either pygments or listings package. Use color for syntax

highlighting. ● If necessary:

○ Citations: in text as [x], with x being numerical order in works cited. ○ Bibliography: IEEEtran style

I'll try to pull together some real data to get to you soon but I have to make sure it has been HIPPA sanitized. In the meantime, I've attached some fake data that was sampled from Atlantis(see below).

Given that the island of Atlantis isn't really just off the coast of Oregon, take the responses with a grain of salt...it should give you a decent idea of what the data looks like, though. The gist of what happens when you call 911(correct me if I'm wrong, Carl):

1. The person that answers the phone is the dispatcher. They handle calls for both the fire and police departments.

2. You explain to the dispatcher what is happening and then based on that, they send an appropriate response. So far, we have the data that is shown in the call file(what happened, when it happened, and where it happened).

3. As the dispatched fire and/or police units get to the scene, they get more data. They then relay this back to the dispatcher.

4. Based on the additional information the dispatcher receives, they make decisions on what happens next. This could be sending extra units if it is worse than expected or calling back units that were sent if it's not as bad.

5. The actions in 3-4 are logged in the response file. This includes, when the unit was dispatched, when it left the station, when it got on scene, when it cleared the scene, etc. Responses are linked to the calls by the UniqueID field.

This is way over-simplifying what happens but it is the gist of it. What we care about: Our simulator mimics the behavior of fire departments. We allow them to run through scenarios virtually so that they can make decisions and get a general idea of the impacts before making the changes for reals. A major component of that is mimicking the behavior of the dispatcher.

This is currently done in a couple of manual steps. First, the user builds what we call a cause tree based on the "Nature Code" field of the call file. In the file I attached, we used what is referred to as NFIRS(​here is a document outlining what the numbers mean​). The nature codes could be literally anything, however, so the cause tree is a way of organizing the nature codes. Think of it like a folder system for files on your computer. A real cause tree looks something like this:

The cause groupings are then used by the dispatch rules to tell the software what response plan to use for different things(i.e. telling the software how to mimic a dispatcher). These can get very complex but it is more or less saying if X criteria is met, do Y. Let's use MVA in the above cause tree as an example. The cause group MVA(Motor Vehicle Accident) is linked to the dispatch rule here:

That is saying that if a MVA happens on a freeway, send the Code3 MVA Augmented Response. Otherwise, send the regular Code3 MVA Response. So for this jurisdiction, if an MVA happens, they will send an Engine, a Truck, and a Command unit. If it happens on the freeway, send an extra engine.

The goal of this project would be to take in the data(more or less what I have attached), analyze what happened, and piece together that department's real dispatch rules from it. More or less, automatically do the last two steps of what I described above.