XAF bootcamp: Defining the business problem

(See this post to see what this is all about and to set the stage.)

I had an enjoyable chat with Kelly last Friday about the problem that she needs solving. Also present in the interview was Larry, the IT Manager for the District Attorney's office, who was very interested in the eXpressApp Framework (XAF) technology I would be using.

Kelly leads a department of 13 staff, of which 6 are Victim Advocates. Although the department comes under the aegis of the DA's office, legally it's separate. They are there for the victims of felony violent crime (for non-US readers, a felony crime is one that will generally involve jail time if found guilty, whereas a misdemeanor crime will usually just involve fines and/or community service and other such), vehicular homicide (that is, a driving accident involving death, sadly most often also involving alcohol), and domestic violence. They also deal with victim compensation to aid with medical bills and the like arising out of the crime, and restitution for victims from convicted criminals. The Victim Advocates provide victims with information on the criminal justice system, court case updates, referrals and court accompaniment, as well as emotional support. Having watched my wife, who's a Senior Deputy District Attorney, prosecute a couple of nasty cases involving child victims, I can well attest to the work these Victim Advocates do.

It seems that the DA's office here in El Paso County deals with about 5000 felony cases a year, and the Victim/Witness Section gets involved in about 2000 of them. The staff at the DA's office make well over 6000 contacts (mostly phone calls, but also face-to-face meetings, emails, and letters) with the victims of these cases, say about 3 contacts per case. Kelly does note though that the current system that tracks all this is not 100% reliable so there may be other contacts being made that are not getting tracked properly. Anyway, it does give us a sense of the scale of the data input and reporting.

According to the Colorado Victim Rights Act, departments like Kelly's must log and report on the number of victim contacts made by their associated DA's office every year. These numbers must be broken down in various categories, for example by date range, by the type of crime, and so on.

In chatting with Kelly, I made lots of notes about the goals she needed to attain, and how the current Access system didn't fulfill those goals, resulting in extra manual work for the staff in the department. Back in my office, I made an attempt to work out the various entities and attributes that my notes exposed. I'm using a pretty standard methodology to analyze my notes here to build up an entity model, but one of the things we're seeing already with XAF is that some developers haven't had the training or experience to understand how to do this formally. There are several books that describe how to distill an entity model (or a domain model, if you follow the Domain-Driven Deisgn methodology) out of a series of interview notes, and I'll have to write a post that describes those I've used in the past.

If you get the entity model wrong, it's not the end of the world when using XAF, but it can make things a little more difficult later on. So bear with me as I describe what I found.

Rereading my notes, I identified several things or entities that I should track in the new system. The four big ones, if I may call them that, are: Victim, Defendant, Case, and Contact.

A Case embodies the DA's view of the crime. Although there can be an awful lot of information related to a Case (such as police reports, medical reports, motions, evidence lists, and so on, so forth), for this system we can get away with just a few basic attributes. The most important one is the victim, of course, but Kelly did note that sometimes there may be more than one victim in a crime, so we'll need to maintain a list of Victims. Next up is that a Case has a defendant. Again usually there's one such but sometimes there may be more than one. There is an exception to the rule here as well: in the very early stages of a case, the crime has been committed and we know who the victim is, but there may not be a defendant yet. Maybe the police are still trying to identify one, but that doesn't mean that the victim won't be contacted. I've already mentioned in passing that a Case must be of a certain type (say, Domestic Violence, Vehicular Homicide, etc). There's also a small set of attributes we'll also need to track as part of a Case: the court division it's in, the DA in charge (this can change throughout the life of the Case, but for this system we only need to track the current DA), the Victim Advocate currently assigned to the case. Finally we need to track the case number allocated to the case.

A Victim embodies the information about a victim of the crime. Mostly this is the usual type of information you'd store about a person: name, address, phone numbers (there may be more than one), email addresses (ditto). Kelly said she'd like to be able to store some freeform notes about a victim as well. This is something I'm a bit leery about -- there have been systems I've worked on where I was writing reports that selected records based on some values in the middle of such freeform fields, but at the moment I'll go along with the request and have asked Kelly to let me know if she's going to track some particular kind of information that might be better served as another separate field. The Victim also has a list of Cases, hopefully only one.

A Defendant is pretty simple (by that I really mean the Defendant entity in the system is pretty simple; I'm not making a judgment call on the intelligence of defendants involved in violent crimes): we need to know the name, maybe some freeform notes, and a list of Cases. I'd like to add "hopefully only one" here too, but recidivism is always a problem. Of course, the Victim/Witness Section aren't going to be contacting the defendant any time soon, but at the very least they need to know who it is.

Finally, a Contact embodies the information about a particular contact made by someone in the DAs office (prosecutor, advocate, paralegal, investigator, etc) to a victim in a case. We need to know: the Victim, the Case, the person doing the contacting (I'm calling this the "contactor"), the date and time of the contact, the type of the contact (email, letter, phone call, etc), and some freeform notes about the contact.

(We had a little discussion about the "time" part of the contact. It's not currently tracked at the moment, the contact date being the more important part of the data. I made the case that, if I made it easy to enter some kind of time information (for example, not the exact time, but something like morning, midday, afternoon, evening), it might be helpful in the future. We'll see: at present it's not an important part of the Contact entity.)

From these descriptions, I'm sure you can see lots of other smaller entities that are making themselves known. For example, CaseType, ContactType, Contactor, ContactorType, PhoneNumber, EmailAddress, and so on. And I'm sure that you can identify some of their attributes too (and that some won't have any attributes apart from a name, since they're essentially enumerations).

Note that, in describing these entities, I'm not describing any behavior for either them or the system as a whole. At the moment, the system is panning out to be a data-driven system rather than a behavior-driven system, but maybe we'll discover some behavior as we proceed through some prototypes.

Next time, we'll start building the business object model.

Free DevExpress Products – Get Your Copy Today