In developing the applications (Overall Gateway, Dog Licensing, Parcel Transfer Verification Check, and the Contract Repository) the Prototype Team performed business process analysis to map the process as it currently exists (see process maps in Appendices A, B, C). Through documenting the process from end-to-end, the Prototype Team created a shared understanding of information flows and responsible parties at each step. From these maps, the team collectively defined a scope statement and developed a set of functional and data requirements for each application. This information was then used to develop the prototype.

Below are each application’s requirements as developed by the Prototype Team.

Scope Statement. The purpose of the Overall Gateway was to pull several different G2G business functions from different state and local agencies through one common place on the Internet. Functions of the overall gateway include:

• single sign-on,
• centralized identification and authorization of users,
• access to the look up feature of the Contact Directory with ability to do predefined sorts and queries,
• access to role-appropriate business functions (e. g. dog licensing, parcel transfer data verification check, contact repository),
• access to general information resources, and
• access to Help and FAQs.

Role Designations. Each Prototype user was assigned a role based on his or her daily job functions. A user name and password was used to authenticate individuals to their roles. User names and passwords were issued and validated by the Gateway Administrator at CTG.

• All users were assigned to the role of General User. A General User had access to all links to resources, a searchable, unified Contact Directory of state and local government professionals, and user support functions including FAQs and Help features.
• Those who held the responsibility of transacting dog licensing functions within their local government or state agency were given access rights to the Dog Licensing Application.
• Those who held the responsibility of reviewing and assessing parcel transfer records within their local government or state agency were given access rights to the Parcel Transfer Verification Check Application.
• Those who held the responsibility of submitting and updating contact information for officials within their local government or state agency were given access rights to the Contact Repository Application.

Functional Requirements. The basic functional requirements included the ability of the application to:

• Perform the functions listed in the Overall Gateway Scope Statement.
• Provide all appropriate users access to the application via a standard web browser.
• Run within the Prototype system.
• Remain self-contained and not integrate with existing production systems.

More specifically, the most important function of the Overall Gateway was the single sign-on to multiple applications where each user’s role was identified and matched to a specific application. This allowed all three applications to be channeled through the Prototype and allowed access to an application only if the user had the correct credentials.

Data Requirements. All data entered into the Prototype was identified and prioritized by the Prototype Team.

• The links to Resources on information about laws and regulations, professional associations, data resources, and other helpful information was selected by the participating state and local officials.
• Information for the Frequently Asked Questions.
• Help information was developed by the corporate partners for the applications that they each developed.
• Information about each user’s role (and subsequent access to applications) was collected and validated.

Scope Statement. This application, modeled after the Office of the State Comptroller’s MACROS system, provided access, input, and updating capabilities to a single repository of contact information for state and local government officials. This application included:

• a decentralized data management process in which each state agency or local government was the owner of its respective contact information,
• role-based assignment of data owners and data entry operators,
• ability for the data owner to change, delete or add data,
• ability for all users to search, view, and export contact information, and
• ability for all users to propose a change to any record for the approval of the record’s data owner.

Role Designations. Individuals given access to the Contact Repository Application were responsible for updating contact information for people within their jurisdiction. Within the Contact Repository Application, two additional user roles were defined to support multiple security levels within the application. The roles are described below.

• A General User had the ability to search, view, and export contact information, and propose a change to any record for the approval of the record’s Data Owner.
• A Data Owner is the person within the organization responsible for the correct contact information for officials and professionals within the organization. This person could change, add or delete contact information for officials within that jurisdiction. A data owner also had all the rights of the General User.
• The Data Entry Operator was the person who completes the forms or enters data but is not the final check for the accuracy of the data within an organization. A Data Entry Operator also has the rights of the General User.

Functional Requirements. This application was created to provide a single, authentic directory of contact information about state and local government officials where the data could be monitored for accuracy by permitting each entity to be responsible for it’s own data. The basic functional requirements included the ability of the application to:

• Perform the functions listed in the Contact Repository Application Scope Statement.
• Provide all appropriate users access to the application via a standard web browser.
• Run within the Prototype system.
• Remain self-contained and not integrate with existing production systems.

More specifically, the most important aspect of the functional design was that all records of contact information had to be tied to a Data Owner. Each Data Owner was responsible for adding, changing, and deleting contact information for officials within their own jurisdiction.

Data Requirements. All data requirements in the Contact Repository Application were identified by the Prototype Team. The Team defined "public fields" that were accessible to General Users and then "private fields" available only to Data Owners and Data Entry Operators (See Tables 4 and 5).

Table 4. "Public" Data Fields Available to General Users

Field Name	Required	Comment
Last Name	Yes	Last Name of the Contact
First Name	Yes	First Name of the Contact
MI	No	Middle initial of the Contact
Salutation	Yes	Preferred greeting for the contact to use in correspondence, (Mr., Ms., Dr., Hon., etc.)
Suffix	No	Suffix to follow the last name of the contact (e.g., Jr., Sr., Esq., etc.)
Organization	Yes	Agency or municipality to which the contact belongs.
Title	Yes	Official title for the contact. One and only one is permitted. (See Job Function for recording additional job responsibilities).
Address 1 Line # 1	Yes	1st line of the primary address
Address 1 Line # 2	No	2nd line of the primary address
City 1	Yes	City of the primary address
State 1	Yes	State of the primary address
Zip 1	Yes	Zip Code of the primary address
Phone 1	Yes	Phone Number at the primary address
Fax 1	No	Fax Number at the primary address
Cell Phone # 1	No	Primary cell phone number for the contact
Email # 1	No	Primary e-mail address for the contact
Year End	No	Fiscal Year End
Legislative District 1	No	Legislative district served by the contact
Legislative District 2	No	Legislative district served by the contact
Legislative District 3	No	Legislative district served by the contact
Legislative District 4	No	Legislative district served by the contact
County	Yes	County served by the contact
Country	No	Country

Table 5. "Private" Data Fields Available to Data Owners and Data Entry Operators (in addition to all "public" data fields)

Field Name	Required	Comment
Address 2 Line # 1	No	1st line of the secondary address
Address 2 Line # 2	No	2nd line of the secondary address
City 2	No	City of the secondary address
State 2	No	State of the secondary address
Zip 2	No	Zip Code of the secondary address
Phone 2	No	Phone Number at the secondary address
Fax 2	No	Fax Number at the secondary address
Email # 2	No	Secondary e-mail address for the contact
Muni Code	Yes	Unique code that identifies the municipality
Owner	Yes	Owner of the data. Source for the most accurate up to date information for the contact.
Custodian	Yes	Custodian of the data. Authorized to make modifications to the contact data, including updates.
Office Expiration Date	No	Date that Term of Office Ends
Cell Phone # 2	No	Secondary cell phone number for the contact

Scope Statement. This application represented a high volume transaction process involving the NYS Department of Agriculture and Markets and cities, towns, and villages throughout New York State. The Dog Licensing Application provided:

• data as required in the existing DL1 Form,
• input into a repository of new dogs and owner information, producing generic recording of licenses for non-purebred dogs,
• renewal of licenses (excluding mailing renewal notices to owners), transfer of ownership, and local reporting functions.

Role Designations. Individuals given access to the Dog Licensing Application were responsible for processing dog licensing applications within their municipality. Within the Dog Licensing Application two roles were assigned:

• Dog-Licensing Agents (DLA) could perform all the functions that are part of processing dog licenses. This includes new registrations, renewals, and transfers. In addition, this role had the capability to run reports and search for specific dog licenses.
• Agriculture and Markets Staff were able to review state-wide data and produce reports. In addition they had access to an administrative function that allows this role to update information requirements about dog licensing.

Functional Requirements. The basic functional requirements included the ability of the application to:

• Perform the functions listed in the Dog Licensing Application Scope Statement.
• Provide all appropriate users access to the application via a standard web browser.
• Run within the Prototype system.
• Remain self-contained and not integrate with existing production systems.

More specifically, the major functional requirement of the application was to provide all Dog Licensing users with a database of new dog licenses, which allows them to input, edit and access data, so that there is a single repository of license data, the data exchange process is simplified, and that better quality data is online more quickly for all users. In addition, the application was designed to perform these five major business processes:

• Research request for dog license application
• Process initial dog license and renewals
• Process transfer of dog ownership
• Update information about the dog or owner
• Process Queries and Reports

Data Requirements: Specific fields that capture data about a dog license was taken directly from the DL1 Form and data requirements were selected by the Prototype Team to support the functional requirements of the application. The selected data fields to support the dog licensing application are in shown in Table 6.

Table 6. Selected Data Fields for the Dog Licensing Application

Data Item(s)	Requirement
Owner Name and Address	Accommodate for multiple addresses (mailing and location addresses)
Owner E-mail	New data item outside of DL-1 form
Dog Address	Some dogs may be harbored in a location other than the owner’s
Dog Birth Date	There are different business rules for registration based on dog’s age
Dog Breed, Color, Mix Designation	For tracking, identification and reporting purposes
Dog Municipality	Where the dog itself resides. DLAs are responsible for the registrations within their municipality.
Dog Spayed, Neutered	There are different business rules for registration based on dog’s status
Dog Gender, Dangerous Designation, Identifying Marks	For tracking, identification and reporting purposes
Dog License Number	Exists for the life of the dog
TCV (Town, City, Village)	Track history of where dog has been registered, for the life of the dog Municipality designation (location of licensing agent) which came from Ag. & Mkts data source
Look Up Tables	Colors, Breeds, Mixes, Registration Types, Vaccination Types extracted from DL1 form (list of standard category items for each data type)
Security Tables	Maintain role based security to grant/deny access to dog application specific functionality
Registration Date	The Start Date is calculated by looking at all of the transactions for this dog and taking the latest end date and adding one day The End Date is calculated by adding two years to the Start Date The Start Date and End Date are overrideable, but the Start Date must occur before the End Date
License Type	If birth month is supplied, dog birthday is rounded to the first of the month for purposes of subsequent calculations If birth month is not supplied, birthday is rounded to first of year for purposes of subsequent calculations If dog is female and spayed, default to "Female, spayed" type If dog is female and unspayed, default to "Female, unsprayed (xxx)" type with the under/over four months calculated from birthday and current date. If birthday is not supplied, default to "Female, unsprayed (under 4 mos.)" If dog is male and neutered, default to "Male, neutered" type If dog is male and unneutered, default to "Male, unneutered (xxx)" type with the under/over four months calculated from birthday and current date. If birthday is not supplied, default to "Male, unneutered (under 4 mos.)"

Scope Statement. This application involved the NYS Office of Real Property Services, county real property officials, and town and city assessors. It consisted of a data quality check on the status of parcel transfers in localities throughout New York State. The application applied nine business rules that identified potential data problems. The application provided:

• a validation of data input from the required RP5217 form,
• an alert to assessors, county real property tax service officers, and ORPS staff about potential data conflicts or abnormalities,
• a simplified verification and more accurate recording of parcel transfer data in the initial stages of reporting.

Role Designations. Three roles assigned within the application were as follows:

• The Assessor had the ability to review flagged records for his or her municipality and make a change in the status of the record.
• The County Real Property Tax Services (RPTS) Official had the ability to review flagged records for all municipalities within their county. In addition, the County RPTS person was responsible for sending the electronic county data to the Prototype system for review.
• The NYS ORPS staff had the ability to review flagged records for the entire state.

Functional Requirements. The basic functional requirements included the ability of each application to:

• Perform the functions listed in the Parcel Transfer Verification Check Application Scope Statement.
• Provide all appropriate users access to the application via a standard web browser.
• Run within the Prototype system.
• Remain self-contained and not integrate with existing production systems.

More specifically, the aim of the parcel transfer process in the Prototype was to reduce or eliminate the errors that currently exist in identifying incorrect tax roll information. In many instances the current process of identifying incorrect data is a manual effort. The Prototype reduced or eliminated the manual process by accepting, at regular intervals, an extract file of the RP5217 data in the existing SalesNet database. SalesNet is an application developed by the NYS Office of Real Property Services that facilitates county entry of RP5217 real property transfer information and allows verification of assessment roll data for transferred parcels.

The Prototype validates each record in this file, based on edit checks of "key word" searches, cross validation of existing data and monitoring of the variance of the sales price to the equalized value of the parcel. When any of records fails one or more of the Prototype edits it gets "flagged" and an automated email is sent to the appropriate assessors, indicating property information, and the reason for the notification. Flags did not mean that a record is indeed inaccurate. Only the assessor could definitely determine if the record was in need of adjustment. Furthermore, the benefit of passing each of the records through the validation was three fold:

• all records were assessed for validity rather than a random sample of records
• more data errors were identified and adjusted earlier
• it was easier for the assessor to catch possible data errors.

Data Requirements. Table 6 shows a list of fields within the RP5217 (real property transfer document) that are likely to have an error, the conditions that make the information erroneous, and potential solutions to the error. Table 7 lists the business rules programmed into the Gateway Prototype. The RP5217 column represents the section of the RP5217 form which contains the data being checked. The issue column represents the business rule applied to that data. The resolution explains why a record was flagged for this check and suggests what to do to resolve it. This information appears on the detailed summary screen for each flagged record. A flag does not necessarily mean that the record is invalid, it is simply an alert that the record appears to be unusual and may need investigation.

Table 7. Data Validation Rules for Checking Parcel Records

RP-5217 Field Description	Condition/Issue	Resolution
Full Sale Price	Full sale price is >$999,999.	Please verify that sale price is correct.
Full Sale Price	Full sale price is <101 and there is no condition associated with the sale.	Full sale price is <101 and there is no transfer condition associated with the sale. Please verify that the sale price is correct and identify transfer condition, if appropriate.
New Construction on Vacant Land	New construction on vacant land is checked but condition code is not.	New construction on vacant land is checked but transfer condition code is not. If new construction has occurred since last final roll available at time of sale, then 15G (significant change) needs to be checked.
New Construction on Vacant Land	If Item No. 9 is checked then Item No. 7 cannot be equal to C, D, or L.	If new construction then property use cannot be vacant land or forest land.
Conditions of Sale	Condition Code J is checked or no condition code is checked with entry in memo field.	(Transfer condition codes) Condition Code J is checked, or no condition code is checked but there is an entry in memo field. Based on entry in memo field determine whether a transfer condition code (other than J) should be indicated.
Buyer Name Seller Name	Keyword Search Error	Keyword search validation has identified this transfer as failing one or more of the Keyword criteria. Verify this transactions buyer and seller names for such things as Agency, Bank, Credit, County, Exec, NYS, Referee, Trust.
Sale Contract Date	Sale Contract Date is not earlier than or equal to date of sale.	Please verify that sale dates are correct.
Buyer Name	Buyer’s last name is the same as the sellers last name and condition code <>A or C.	Buyer’s last name is the same as the seller’s last name and transfer condition code A (sale between relatives) or C (one of the buyers is also the seller) is not checked. Please verify whether transfer condition code should be indicated.
Number of Parcels	Number of parcels – 1 and parcel box is not checked (See calculations of Equalization rates).	The ratio of the equalized full value to the sale price is <.6 or >1.4. Please verify the sale price and transfer condition code, if appropriate.