Cornerstones Unified Database Design Project

SYST 699: Fall 2014

Analysis

After defining the problem and planning the work, our team performed an analysis of the existing system. The analysis phase consisted of two major efforts – developing use cases for the delivered system and evaluation of the Cornerstones artifacts we received.

The use cases were analyzed so that the GMU Team and Cornerstones could come to an agreement of the high-level functionality of the unified database. Additionally, the use cases were used to derive the high-level requirements for the system, which would allow us to have an effective test plan for the delivered system.

The artifacts that we received from Cornerstones for analysis covered both the front-end and back-end data that Cornerstones collects during their client tracking and reporting operations. The specific items received from Cornerstones were:

1. Intake forms from the three Neighborhood Resources programs:

a.    Food Pantry (ASAPP)
b.    CBI
c.    Wellness Support

2. Microsoft Excel Spreadsheets

a.    Food Pantry Master Report
b.    CBI Master Report
c.    Neighborhood Improvement Program (NIP) Master Report

The analysis of these materials involved identification of all data collected, identification of all data reported, and then determination of how each collected item rolled into the reported figures. We also performed a gap analysis of the existing intake forms to determine what overlap existed across the data that was collected at each program. The results of this investigation were used to determine if there was sufficient data collected to provide for unique identification of all clients. Our team identified additional data fields that should be collected to ensure that each client can be identified uniquely within the Neighborhood Resources programs operated by Cornerstones.

Use Cases

The following use cases were identified to capture the processes of Cornerstones’ existing programs, how the staff interacts with clients, and how the database will be operated.

1. Use Case 1: New Applicant Filling Out Form

2. Use Case 2: Staff Providing Food Pantry Service to Existing Applicant

3. Use Case 3: Client Attends Service

4. Use Case 4: Staff Generates Reports for Program

5. Use Case 5: Create New Entry From Household

6. Use Case 5a: Single Client Becomes Part of a Household

7. Use Case 5b: Client Moves from Member of a Household to His/Her Own Household as a Head

8. Use Case 6: Add New Client to Database

9. Use Case 7: Update Existing Client Record in Database

The detailed descriptions of the Use Cases can be found in the Final Report.

Paper Intake Form Analysis

There were three paper intake forms that our team received from Cornerstones. Each form was unique to the program that it was being used in – ASAPP, CBI, and Wellness Support. However, there was significant overlap in the data fields that were collected across all three programs. The following table shows each data field captured and the form that the field was found in. It also provides the type of data that was collected (e.g. text, date, yes/no, etc.). A green check mark represents a field that is present in the form listed. The “NEW” column represents data fields that were not collected in any of the programs, but our team determined would be important to collect in order to support the unique identification of clients.

The Final Report includes scans of the original paper intake forms received for these three Neighborhood Resources programs.

The fields identified in this analysis were major drivers for the preliminary requirements for the envisioned system. Our team’s goal was to enhance the client tracking and reporting functions of the Cornerstones organization, so it was important to ensure that all the data that they currently track is accounted for in our unified database design.

Existing Cornerstones Reports Analysis

The second set of documents that were received from Cornerstones for analysis was the bac-end reports. These include the Food Pantry Master Report, CBI Master Report, and the Neighborhood Improvement Program (NIP) Master Report. Our team analyzed each report by documenting the statistics presented in the report, the data fields that are summarized in the statistics, and which reported values will be required as a minimum for the Cornerstones Unified Database.

Overall, we found that the following list of reported items would be a minimum requirement for the reporting functions of the Cornerstones Unified Database:
•    # of individuals client by race
•    # of households client by race
•    # of individuals client by ethnicity
•    # of households client by ethnicity
•    # of households with any children (under 18)
•    # of households with a senior (over 55)
•    # of households with an unemployed member
•    # of times a service is received/delivered over a given time frame
•    # of households by income category
•    # of households headed by gender type

The Final Report contains the detailed analysis of the existing reports and identifies the statistics that relied on client data captured in the intake forms.

Requirements

After identifying the use cases for the envisioned system and analyzing the front-end and back-end artifacts that Cornerstones captures during client processing and tracking, our team developed a requirements baseline for the project. The requirements were generated directly from the needs that were identified in the use cases and the received documents. A formal requirements document was delivered to the customer. After review by their staff, our team updated the document according to their feedback and redelivered for their acceptance.

The main categories of requirements captured in this system include:

•    Functional Requirements: capture the main functions of the database, such as data entry, storage, and maintenance; retrieval and update of data; reporting of data; and configuration of the database.
•    Interface Requirements: capture the interface that allows database users to interact with the database, including both software and hardware interfaces.
•    Non-Functional Requirements: capture all non-functional aspects of the database such as performance, environment, and security.

The Functional requirements include the following subsections, which represent the categories of requirements:

• Data Management: The Data Management requirements include all specifications around the management of Cornerstones client data. This includes specific data fields collected for each client, the organization of data fields as part of a table, and the queries used to retrieve data from the database.

o    Data Field Requirements: The Data Field requirements capture the minimum set of data fields to be tracked for each client/household in the database.
o    Import/Export: The Import/Export requirements capture the specifications for the import and export of data into the database from existing records, and export of data into reports.
o    Reporting: The Reporting requirements capture the specifications for the reports that the database must provide at a minimum in order to support the needs of the existing report formats.

• Configuration: The Configuration specifications detail all the configuration needs of the database.

The Interface requirements include the following subsections, which represent the categories of requirements:

• User Interface: The User Interface requirements capture the methods that the users will interact with the database.
• Hardware: The Hardware specifications provide the requirements around the hardware used to support the database.

The Non-Functional requirements include the following subsections, which represent the categories of requirements:

• Performance: The requirements in this Performance section provide the performance specifications for the database’s operations.

o Capacity: The Capacity requirements provide requirements around the volume of data entries that must be supported by the database.
o Availability: The Availability requirements provide requirements around the availability of the database and how many down times are acceptable performance.

• Operational Environment: The Operational Environment requirements describe the environment that the database will operate within.
• Security: The Security requirements provide all the detailed security needs for the database.

o Protection: The Protection specifications detail the ways in which the client data will be protected, including security of the data as well as security of the facility that houses the database.
o Authorization and Authentication: The Authorization and Authentication requirements detail the access privileges of users and who is able to access, update, and delete data from the database.

The Final Report contains all of the requirements for the system. It is organized according to the categories above. Each requirement was assigned a unique ID which was used to track the requirement through the life of this project. In addition, the requirement ID’s were useful during our test and verification activities, where each requirement was tracked in a traceability matrix to verify that the integration of the system was successful in addressing the specific requirements. The traceability matrix also allowed us to associate design elements to the requirements that they addressed. This traceability matrix can be found in the Final Report.

Thank you for visiting our page!