III. Methodology to Solve Problem
In developing this system, I'm working to follow the Waterfall Method by moving stepwise while updating a testing routine. In accordance with the requirements stage, I have met with the user representative from Jay County Abstract Co., Inc. and developed a requirements document through dialogs there and through my own experience as an abstractor. This document lays out the required input possibilities and structures as well as the resulting required output. While this document is included in greater detail, the main points are the inclusion of one-time insertion of data, as well as the database query option for this insertion, and the ability to adjust certain document information or to delete it entirely. Also the ability for the user to include documents in the form at any stage is very important to ensure correctness, as there could be hundreds of thousands of dollars at stake. The output in general terms, is a form that has been checked by an abstracter and/or an agent for Commonwealth and is found to be correct. |
Working from the list of required input and related output for the system, the next step was to define how the input is transformed into correct output. This is the requirements stage of development. This entails a lot of narrowing and expanding of the developed list of requirements and defining some of the relations among input, and between input and output. I've divided all input into classes that fit into a hierarchical scheme, where document or form information is an instance of class. Documents are made of these instances, and forms are made up of instances combined with a set of documents. |
After defining these classes, I have moved on the the UML implementations of the application, which will be my design representation. I will use these diagrams to lay out the information, document, and form classes and their relationships so that I may easily implement them and their relationships to make the application. |
IV. Documents
Requirements Document
There will be two types of allowable input for this system. The first will be user input with the following requirements. The user must be able to delete and adjust any of the information in the form. This is very important to ensure correctness of the form as a whole. The user must be able to enter all form information using a tool that will populate all the default form fields at once and in the proper syntax. Later on, we have the option of populating these fields from information stored in a database, and we must retain the choice of the user to change these fields to ensure correctness. The user must be able to add a document to the form, by choosing the type of document and entering the pertinent data, which will be populated into the form in the proper place and with syntax specific to the document type. This is the second most important functionality of this system because the a database will not usually contain the information for every document required for a particular parcel of land. |
The second type of input will be database input into the system that will achieve, if possible, the following requirements. The user will be able to find a particular document, if it exists in the database, with which the system can render the stored document information into the form in the appropriate syntax. The inclusion of database input will depend greatly on the accessibility of the information stored in an application owned by Jay County Abstract Co., Inc. If possible, I will make queries directly to this application. Otherwise, depending on time, I will attempt to port the information to a relational database so that I may run queries against the information. If this is not possible, I will populate a set of test data to run against the system for testing purposes. Depending on the ability and time complexity of accessing the stored information, there are additions to the allowable database input I would like to make, as follows. The system will find a set of real estate properties owned by a particular person or set of people. This set of properties must be rendered in a way that allows the user to choose one property (or set of properties if they are stored together as one parcel) from the set. In choosing a property, the user will populate a form or set of forms with the information related to this property and the documents pertaining to it. Depending on time, a useful addition to this would be to allow this process multiple times in one document. Again, my ability to further develop this functionality will depend greatly on time and accessibility of the set of stored document information. |
The required output of this system will be a set of forms that are demonstrated to contain correct information embedded in the proper syntax. The forms must comply with Commonwealth standard forms, of which I have examples. The information in the form is required to be checked by an agent of Commonwealth and any corrections made before issuance of any commitments or policies for insurance. I have all of the necessary forms and the proper syntax for insertion of document information into the forms. (Will show examples of forms) |
Specifications Document
To better define the input and and it's representation in the forms, it is necessary to break the input down into several groups. The first groups of input are specific to the form being created. A Commitment for Title Insurance requires the following information: commitment number, effective date, owner, description, taxes, and any liens against the property. There are more requirements based on whether the commitment is for owners or lenders insurance, or both. If the commitment is for a lenders policy, then additional requirements are: amount of insurance, proposed insured (bank or lending institution), address, and who will be taking out the mortgage. If the commitment is for owners insurance, then additional requirements are: amount of purchase, purchaser, and address. The two policy types are not independent of each other, that is to say that a commitment can be for both an owners insurance policy and a lenders insurance policy. When issuing a policy, there is a set of similar required information. An owners policy requires: policy number, purchase amount, new deed information, address of buyer, description, and any liens against the property. A lenders policy requires: policy number, new mortgage information, address of lenders, owners, description, and any liens against the property. For all of these documents, a lien is defined as any document that demonstrates money owed again the property, such as a mortgage, court judgment, outstanding taxes, easement, or oil and gas lease. |
Individual documents that are liens against a property each have their own set of required information. A deed requires the following information: date and time recorded, owner, seller, description, document number, and number of pages. A mortgage requires: date recorded, owner, lender, amount, document number, number of pages, and description. An easement includes: granted by, granted to, record information, date signed, and date recorded. An oil and gas lease requires the same information as an easement, as it is a specific type of easement that we like to denote separately. Required judgment information includes: plaintiff, defendant, cause number, date of filing, book and page numbers, and amount owed. Outstanding taxes are not laid out in a document, unless there is a tax warrant, which is defined as a judgment, so there is no recording information. To denote outstanding taxes we need the total taxes and the additional penalty for each installment, and the computer number, which identifies a parcel of land. |
This break-down gives us three classes of forms, six classes of documents or liens against a property, and several more classes describing the other elements of the forms and documents. The information in the documents is related by a certain syntax, which is the required output for any document. In the form, any deed is represented by the following syntax: "A deed to <owner> from <seller> recorded in 'Document no. <document number>, pages 1-<pages>' OR 'Deed record <book>, pages <page numbers>' on <date> in the Office of the Jay County Recorder." Similarly, a mortgage is represented in the following way: "A Mortgage by <owner> to <lender> in the amount of <amount> recorded in 'Document no. <document number>, pages 1-<pages>' OR 'Mortgage record <book>, pages <page number>' on <date> in the Office of the Jay County Recorder. Other document are represented in similar ways, though these two documents have the most important syntactic form. |
The matter of describing a document in terms of it's elements involves defining the different possible document fields. If there is a document number, it is a seven-digit integer. However, if a document was recorded before 1997, it instead has a book and page number. The book and page numbers can have up to three digits, though the page numbers will include all pages of the document, as they are usually several pages long. Because there are two forms for this field, I will allow for either possibility, and exclude the other by possibly using checkboxes. The date is best represented by the abbreviated month, the day, and the full year, which could be chosen from a set of drop down menus. In the case of a deed, we would like to store the time of recording, in 12-hour format as well. When identifying the owner, in some cases we want to keep track of the owner's full title as printed on the deed. To do this, I will allow for several preefined suffixes, such as "husband and wife", or "as equal tenants with rights of survivorship", as well as an option to define a prefix. A lender or seller may also have a prefix, and I plan to deal with these in the same manner, allowing for some predefined and one undefined prefix. The description field is a very large field, sometimes including several descriptions, and it may not be useful to carry them around with every document. Instead, maybe I will display a section at the top of the screen devoted to the description of the deed or deeds included, so that the user may check the description of any document before adding to the form. It would be a pain to require entering a description by hand, so in this way it would be nice to allow database storage of this large field. A computer number is a three digit number followed by a dash, followed by a five digit number, followed by a dash and another three digit number. These are used by the Treasurer's Office for tax information. A cause number is defined as 38D01 or 38C01 followed by a dash and a four digit number representing the part of the year, followed by a dash and up to a five digit number. These are used by the Clerk's Office, and Jay County is uniquely identified is Indiana by the 38[D or C]01. This defines all of the information making up the different classes of documents. |