9-2 Final Project – System Proposal Document
John C. Aghadiuno
9-2 Final Project – System Proposal Document
Southern New Hampshire University
Professor Allyson Heisey
07/01/2018
Contents
Project Monitoring and Control Plan. 47
Introduction
Background
CPCS currently maintains three separate “case management” systems in use by staff (i.e., CASEY, TRIS, and CMS). They share a core set of functionalities, mandated by statute and ethical obligation. They also attempt, with varying degrees of success, to address a separate tier of functions aimed at improving staff efficiency and practice, as well as the allocation of resources. The agency’s recent growth and a desire to better leverage our data for the good of our clients has resulted in the addition of functions to this separate tier. Design of the current systems, however, impedes implementation of such expanded functionality.
Problem Statement
Due to deficiencies in the current system design and the lack of standard data input practices, most of the data collected for purposes other than case “counts” (i.e., everything except case numbers and runsheet narratives) is of poor quality, and in their current form they do not seem to be either complete or accurate. The data are inconsistent when considered across multiple offices/working groups (even within the same division), as various groups adhere to differing practices. Additionally, the current system introduces demonstrably unnecessary work and complexity (e.g., duplicate data entry). Consequently, users have had to adapt their workflows to the system rather than having the system support the best workflows.
Based on the above deficiencies in the current systems, it is necessary to construct a system built on a more robust understanding of our data and user needs. The purpose of this document is to outline the business requirements for such a solution, one that would replace the existing systems with a single, well-designed system capable of ensuring the following:
- Improved efficiency: ensure that users are required to enter data in the system only once, and that they can enter what they need, and that they can easily find the information they require
- Improved data quality: create robust data validation mechanisms that ensure the system can use the data that users enter
- Effective, user-friendly design: ensure that users are able to easily view necessary system information, and navigate seamlessly through the system
- Improved system flexibility: ensure the system is adaptable to the evolving needs of CPCS.
Audience
The intended audience for this document shall be the Project Sponsors, Project Team, IT Development team, Quality Assurance team and other interested parties, including anyone who will be involved in support and maintenance of this application.
Systems Requirements
Requirements Models
Output
- The system must provide UIs for reporting current and historical case data statewide.
- The system must provide functionality for filtering and aggregating case data.
- The system must be simple and intuitive, and unambiguous output.
- The system must provide authentication to access its resource.
- The system must provide authorization and implement access control to its resource.
- The system must provide secure access online and be available to any device.
- The system must allow access to customizable reports based on staff roles.
Input
- The system must allow for case management by staff.
- The system must store case activity and event logs.
- The system must capture relevant information about staff reporting preferences.
- The system must allow management to assign staff to roles.
Process
- The system must integrate with the existing case systems.
- The system must be able to generate reports based on user provided metrics.
- The system must be able to pull data from existing systems and aggregate data.
- The system must have built-in algorithms to enforce agency rules and objectives.
- The system must be able to export data in various formats.
Performance
- The system must be able to scale and support thousands of users simultaneously.
- The system must be able to handle core business processes.
- The system must have a friendly interface, easy to use and accessible on any device.
Control
- The system must provide a secure single log-in enterprise-wide.
- The system must provide authentication, authorization and access control mechanisms consistent with business rules.
- The system must provide for the security, integrity, reliability, retention and back-up of data in accordance with applicable state laws, governing bodies, industry standards and business rules.
Data Process Model
Data Flow Diagram
Data Dictionary
Associative Entity
Notation Entity
Object Modelling
Use appropriate object modeling techniques and tools to describe the system requirements.
Every person in the database will inherit from the PERSON class, including attorneys, clients, investigators, judges, defendants, witnesses, etc. While they inherit and share a common set of characteristics, as can be seen in the models below, they can possess their own characteristics.
Use Cases and Actors
Primary use cases and actors for the ZENO system include:
- ATTORNEY (actor) can VIEW OWN CASE REPORTS (use case).
- MANAGER (actor) can VIEW ALL CASE REPORTS (use case).
- OFFICE ASSISTANT (actor) can PRINT CASE REPORTS (use case).
Use Case Diagram
State Transition
Systems Design
Specification
| The reporting application will provide UIs for reporting current, and/or historical case data statewide. These reports will also provide additional functionality for filtering and aggregating case data. | |
| 1 | Given a set of filters (e.g., Division, Unit, Office, date) the Events screen will return a list or graphical display of aggregate counts for the given filters grouped by filtered agency entities. When comparing multiple date ranges, aggregate counts will be replaced by differences. |
| 2 | Filtering characteristics should include:
● Period (e.g., custom, today, yesterday, last week…) ○ From (Starting Date) ○ To (Ending Date) ● Comparison (i.e., no comparison, compare to previous period, and compare to previous year) ○ When not “no comparison” ■ From (Starting Date) ■ To (Ending Date) ● Division (e.g., PD, CAFL, YAD, MH) ● Unit (e.g., trial, appeals) ● Office (e.g., Lowell District) ● Staff Detail |
| 3 | The Period filter should present a set of predefined periods including:
● Custom ● Today ● Yesterday ● Last Week ● Last Month ● Q2 FY2017 ● Q1 FY2017 ● Q4 FY2016 ● Q3 FY2016 . . . Where the divisions by quarter are the preceding 8 quarters, excluding the current quarter. |
| 4 | The values of the From and To dates associated with Period are automatically set after selecting a period. If they are altered, the Period selection is set to Custom. |
| 5 | The Comparison selection can be:
● No comparison ● Custom ● Compare to previous period ● Compare to previous year |
| 6 | The Comparison’s From and To fields only appear when Comparison is not equal to “No comparison” |
| 7 | The values of the From and To dates associated with Comparison are automatically set after selecting a ..previous period or …previous year. If they are altered, the selection is set to Custom. |
| 8 | The span of time covered by the From and To dates associated with Comparison must be the same as that covered by the From and To dates associated with Period. |
| 9 | The Division, Unit, and Office fields should be pulldown menus. |
| 10 | All pulldown values should default to ALL. |
| 11 | The Division, Unit, and Office pulldowns should allow for multiple selections. |
| 12 | The available Unit options should be contingent of selected Divisions, and the available Office options should be contingent on the selected Unit. This is to avoid logical impossibilities that would lead to null results (e.g., Division = CAFL and Office = Lowell District). |
| 13 | Staff Detail should be a pulldown, defaulting to all, and allowing for multiple selects (e.g., attorney, SSA, investigator). |
| 14 | Filtered results should be displayed in four slices:
● Mixed Division, Unit and Office List ● Staff List ● Graph ● Cases List |
| 15 | The Mixed Division, Unit and Office List should display
● A nested list of the selected Divisions, Units and Offices ● As well as a TOTALS row at the top, aggregating values for the following rows. Each row should contain columns noting ● Start: The number of open cases at the Start of the Period ● Asd: The number of cases Assigned during the Period that are not Probation or Bail ● Prob: The number of Probation cases assigned during the Period ● Bail: The number of Bail cases assigned during the Period ● Tch: The number of Touched Cases (start + asd + prob + bail) ● Clsd: The number of cases that were closed during the Period ● End: The number of cases open at the end of the Period. |
| 16 | When fetching search results the system should display a loading message to make clear that a search is underway. Ideally, this would take the form of a progress bar to indicate how much time is left. |
| 17 | Mixed Division, Unit and Office List counts should count each individual case, not each time a staffer touches a case. So if two attorneys worked the same case, it would show up only once. |
| 18 | The content of the Mixed Division, Unit and Office List is contingent on the filtering selections. |
| 19 | The content of the Staff List is contingent on those rows selected in the Mixed Division, Unit and Office List. It should be possible to select more than one such row. |
| 20 | The Staff List should display rows for each involved staff member with subdivisions for offices. Office subdivisions should not include counts. However, each staff row should include the same columns and counts as the Mixed Division, Unit and Office List but tailored for the staff member. |
| 21 | The Staff List should count each time a staffer touches a case. So if two attorneys worked the same case, it would show up as a single case in each attorney’s row. |
| 22 | The report will show either Details or Graph |
| 23 | When Comparison is not No Comparison, the counts in rows will show the difference between the older period and the newer period. For example, if period 1 had 20 touched cases and period 2 had 19, the displayed number would be -1. |
| 24 | When Comparison is not No Comparison, the Graph will display lines for period 1 and period 2. |
| 25 | Graphed data will plot counts for the number of open cases. That is, the Y axis should start with the number of open cases at the beginning of the period, going up with newly opened cases and going down with newly closed cases. |
| 26 | The graph will contain data for the most granular selection above. For example, if Lowell District is selected in Mixed Division, Unit and Office List and there no selection in the Staff List, the counts will be those of all Lowell District cases matching the filtering criteria. If, however, Attorney Smith is selected in the Staff List, the counts will be those of Attorney Smith’s cases. |
| 27 | The start and end dates on graphed data will be set by the min and max opening dates found in matching cases. |
| 28 | The granularity of dates in graphed data will allow for user editing. For example, the x axis could show individual days, weeks, months or quarters, depending on the user selection. These delineations would count cases in groupings. So, if the divisions were by weeks, the Y axis would display counts per week. |
| 29 | The granularity of date data in graphed data should be a function of the difference between the start and end date of the graph. For example, if the time spans days, the level of detail should be days, if it spans years, quarters or months would be appropriate. |
| 30 | The Case Grid should display a row for each case encompassed by the above selections, with columns for
● Case Number ● Docket Number ● Client Name ● The “most important” charges (limited by space) ● The case’s office ● The opening date ● The attorney(s) on the case ● The closing date ● An indicator if there was an adverse disposition on any charge |
| 31 | The results should include a total number of matches as an output. |
| 32 | When the total number of matches is sufficiently small, there should be the option to output results to a csv or xls file. |
| 33 | When a case number is displayed, it should be a hyperlink to the case’s details as seen in the current system (i.e., CASE, TRIS or CMS). |
Requirements Models
Output
- The system must provide UIs for reporting current and historical case data statewide.
- The system must provide functionality for filtering and aggregating case data.
- The system must be simple and intuitive, and unambiguous output.
- The system must provide authentication to access its resource.
- The system must provide authorization and implement access control to its resource.
- The system must provide secure access online and be available to any device.
- The system must allow access to customizable reports based on staff roles.
Input
- The system must allow for case management by staff.
- The system must store case activity and event logs.
- The system must capture relevant information about staff reporting preferences.
- The system must allow management to assign staff to roles.
Process
- The system must integrate with the existing case systems.
- The system must be able to generate reports based on user provided metrics.
- The system must be able to pull data from existing systems and aggregate data.
- The system must have built-in algorithms to enforce agency rules and objectives.
- The system must be able to export data in various formats.
Performance
- The system must be able to scale and support thousands of users simultaneously.
- The system must be able to handle core business processes.
- The system must have a friendly interface, easy to use and accessible on any device.
Control
- The system must provide a secure single log-in enterprise-wide.
- The system must provide authentication, authorization and access control mechanisms consistent with business rules.
- The system must provide for the security, integrity, reliability, retention and back-up of data in accordance with applicable state laws, governing bodies, industry standards and business rules.
Data Design
This document will define the data architecture for the CPCS Case Management System. The data architecture for a system is comprised of the following:
- Logical/physical data models that detail the structure and relationships between the major entities of the system. The data models defined during data architecture may not be fully flushed out to include every possible column or data point required. However, the primary entities and their relationships will be completed.
- Standards and best practices to be used in designing and developing the data architecture.
- A data migration strategy for migration of data from existing databases into the new database.
Logical Data Model
In order to develop the data model for this project, an SSDT (SQL Server Data Tools) Database Project was created and used in order to define a set of schemas and tables that will become the persistence layer of the system. In this way, a more “logical” data model was not generated in favor of creating a detailed physical data model that will have immediate use in development of the system. However, the following diagrams and descriptions will act as a logical data model, describing the major entities of the system and how they relate to each other.
Person
The person entity and its assorted one-to-many related entities will store personal and demographic information with various degrees of completeness for any person who has a role in the Case Management System. Examples of person include, but are not limited to, a client, a CPCS attorney, a non-CPCS attorney, a judge, a witness, and a victim. As each person is entered into the system, the system/UI will incorporate workflow and other mechanisms in order to minimize duplicate entry of the same person into the system as much as possible. The details of the duplicate check mechanism are not part of the data architecture documentation. Although there is the concept of a Person being in one or more “position” (see PersonPosition entity below), that will be primarily used as a filtering mechanism when searching for a specific Person. It is when related to other entities that a Person will take on a role as part of that relationship through the PersonRelateType entity. See the Person Main Entity Diagram below followed by descriptions of the nature and usage of each entity.
Person Entity Diagram
Organization
The organization entity and its assorted one-to-many related entities will store details about any conceptual or physical organization of persons that will be used in the system. There will be a special set of Organization records that will conceptualize an organization structure for CPCS itself. Although that organizational structure is currently loosely modelled as divisions with regions, units and offices below them, the OrganizationRelate/OrganizationType concept will allow for the hierarchy to be defined at any number of levels over time, while preserving the history of how it was structured at any earlier point in time. This flexible Organization relationship concept can also be used to model flat or hierarchical relationships outside of the CPCS realm. For example, if there is a hierarchy to the Massachusetts court system courts, the courts could be related this way. See the Organization Main Entity Diagram below followed by descriptions of the nature and usage of each entity.
Organization Main Entity Diagram
Matter
The Matter entity will store details about the possible matters that could be associated with a case. The Matter entity will store both criminal and civil matter data. Think of the Matter entity as more of a specialized reference table. The Matter entity is somewhat equivalent to the current “Charge Index” in the current system, in that it contains the definitions of the types of matter that could be related to any Case in the system but does not hold the actual instances of matters for each case. See the Matter Main Entity Diagram below followed by descriptions of the nature and usage of each entity. Since the Matter entity contains mostly pointers to the reference tables described below, the Matter Main Entity Diagram depicts both the Matter entity and its related reference tables.
Matter Main Entity Diagram
Case
The Case entity and all of its related entities will store all of the information about each case that is handled by CPCS in the Case Management system. See the Case Main Entity Diagram below followed by descriptions of the nature and usage of each entity.
Case Main Entity Diagram
Data Flow Diagram
Data Dictionary
Associative Entity
Notation Entity
Object Models
Every person in the database will inherit from the PERSON class, including attorneys, clients, investigators, judges, defendants, witnesses, etc. While they inherit and share a common set of characteristics, as can be seen in the models below, they will possess, in varying degrees, their own characteristics.
User Interface Design
Sitemap
Homepage Template
People Search Template
Person Details Template
Case Details Template
System Architecture
Feasibility Analysis
For the past four years CPCS has collected data on user needs regarding case management. This has involved both formal and informal conversations, including insights gained from direct user feedback, multiple listening tours, surveys, and formal meetings for the Gideon Project. Since May, we have conducted thirty-six new interviews, and five group lunch talks, as part of site visits. Interviews have included sessions with Deputy Chief Counsels, Managing Directors, AICs, AAs, SSAs, Social Workers, Investigators, Directors of SSAs/social workers, PD’s lead investigator, and a paralegal. These recent meetings included members from PD, CAFL, YAD, MH, and A&O in offices across the commonwealth, including Boston, Lawrence, Norwood, Quincy, Roxbury, and Worcester. All told, it is estimated that the entire multi-year process has involved in-person meetings with roughly a hundred staff members in offices from Boston to Pittsfield. This is in addition to a little over two hundred anonymous survey replies. Consequently, we have spoken with members of every practice area, including representatives of every user type. All of these have served to inform the current set of functional requirements.
Findings
We have identified eight high-level themes that apply to the system as a whole, and four areas of focus that help to define specific groupings of features. The focus areas are themselves comprised of specific requirements and a summary is presented below.
Themes
- Centralization (Facilitates Collaboration and Avoids Duplicate Data Entry)
- Mobile Access
- Granular Data Collection & Flexible Data Elements
- Data Aggregation & Analysis (e.g., Standard Reporting and Predictive Modeling)
- User Interface & Workflow Support
- Permissions, Security, & Privacy
- Reliability of Data and System (Including Technical Performance and Data Quality)
- Smooth Transition to a New System (Data and Training)
Focus Areas & Features
| People & Groups | ||||
| Requirement(s) | In Current? | Complexity | Impact | Priority |
| The ability to find, edit, and add information on people and groups, including the relationships of people to each other, to cases, and to groups. | in part | med | high | high |
| Radically improved search: fuzzy/statistical search/match (esp. conflict check) | no | high | high | high |
| Public person and group profiles w/ user comments | no | low | med | low |
| Case Management, Document Management, and Calendaring | ||||
| Requirement(s) | In Current? | Complexity | Impact | Priority |
| The ability to find, edit, and add information on cases. Such information includes:
● Relationships of people and groups to cases ● Runsheets, including fine-grain action tracking (e.g., did you argue a motion today?) ● Calendars ● Documents (external and internal) ● Matter dispositions and procedural history |
in part | high | high | high |
| The system should be capable of producing documents from user-defined templates. | in part | high | high | med |
| Improved collaboration:
● In-system referrals (investigators et al.) ● Separate communications channel for supervision ● Internal notifications of involved parties (e.g., letting SSA know when a runsheet entry was made) |
in part | med | high | high |
| Reports & Research | ||||
| Requirement(s) | In Current? | Complexity | Impact | Priority |
| Standard reporting nomenclature (e.g., agreement on what one counts when counting cases) | no | med | high | high |
| Static reports (e.g., trends & counts by office, employee et al.) | in part | med | high | high |
| Dynamic Reports (e.g., Boolean queries of most data fields) | in part | high | med | high |
| The ability to export or make available via API information for consumption by external systems (e.g., export to csv, Excel) | in part | low | high | high |
| Access to CPCS research material (e.g., training and synced charge info) and pointers to external resources (e.g., linking to statutory language or model jury instructions). | no | med | med | low |
| Administration | ||||
| Requirement(s) | In Current? | Complexity | Impact | Priority |
| Permissions based on relationships to cases and groups’ membership (roles) | no | med | high | high |
| Workflow management & business rules
● Contextual delivery of best practices (e.g., serving up appropriate documents and presenting links to additional resources) ● Data entry support |
no | high | high | low |
| Flexible nomenclature | no | med | high | high |
| Adaptive presentation
● Custom Home Screen / Dashboard ● Data filters for specific roles and divisions |
no | med | med | high |
Project Plan
Work Breakdown Structure
Project Monitoring and Control Plan
Definition of Done
The Definition of Done is a set of agreed-upon definitions for when a given software feature is regarded as truly completed (feature complete), and ready to be delivered and closed out as a work item. The definition, as agreed upon by all key stakeholders, consists of far more than just the code, as regarded by the developer, being completed; rather, each delivered feature is subjected to the same standards for quality and delivery to ensure a greater level of efficiency and verifiability when developing a given feature.
To ensure quality of delivery of features, CPCS defines the following checklist items as its Definition of Done:
- Code Completed
The code is considered complete by the developer. All to-do items present in the code are resolved, and the developer considers it completed and that it fully addresses the scope of the User Story in question.
- Code Commented, Checked In, and run against current Source Control Version
The developer has sufficiently documented the code, based on the agreed-upon code documentation standards, and checked it into source control. Normally, this means the code check-in has been associated with the relevant work item in the relevant project management utility. Additionally, the developer has gotten the latest version of the code branch in question and ensured that their code still runs against that branch.
- Builds without Errors or Warnings
The developer has produced code that compiles without errors. Additionally, it is a standard best practice that production-ready code should also build without any compiler warnings whatsoever. Typically, consistent checks against this are performed on a nightly or on-demand basis by a Continuous Integration process, that automatically compiles the application as of its current version.
- Unit Tests Written and Passing
The developer has produced accompanying unit tests, encompassing an acceptable level of code coverage (60-75% code coverage would be recommended in general, with the level reflective of how critical and complex the component is) for the given component. These unit tests must all pass.
- Code Reviewed, and meets Development Standards
The developer has produced code that meets the agreed-upon code quality standards, as determined by a peer review. The peer review will ensure that the code not only meets general syntax and stylistic guidelines, but also that the code adheres to general principles of abstraction and DRY (Don’t Repeat Yourself).
- Any Build/Deployment/Configuration Changes are Implemented/Documented/Communicated
Any configuration changes necessary (application-level configuration, or permissions changes, or credentials) are documented and communicated to the team.
- Hours for the Task or User Story are set to Zero, and the work item is marked as “completed”
Once the item has passed the previous enumerated items, the work item can be marked as completed.
- The Code is deployed to a Test Environment, and System Tests are completed
After the item is marked as completed, it must be deployed to a dedicated test environment for further vetting and ensured that the system still functions as expected.
- The Code is verified in the Test environment and signed off on
A person other than the developer who implemented the code (typically a dedicated QA resource) tests and verifies the code, and ensures that it matches expectations, as set out by the requirements for the work item. If available, UAT signoff may be incorporated into the development process, but is not necessary to consider an item to be “done”.
- The work item is marked as closed, and considered “done”
Timeline
Resource Sheet
Cost Sheet
Rosenblatt, H., & Scott, T. (2017). Systems Analysis and Design (11th ed.). Retrieved from https://mbsdirect.vitalsource.com/#/books/9781337424202/