{"id":232,"date":"2023-12-24T13:48:36","date_gmt":"2023-12-24T18:48:36","guid":{"rendered":"https:\/\/blogs.bu.edu\/john2011\/?p=232"},"modified":"2023-12-24T13:52:01","modified_gmt":"2023-12-24T18:52:01","slug":"system-proposal-document","status":"publish","type":"post","link":"https:\/\/blogs.bu.edu\/john2011\/john_aghadiuno\/2023\/system-proposal-document.html","title":{"rendered":"System Proposal Document"},"content":{"rendered":"

9-2 Final Project – System Proposal Document<\/strong><\/p>\n

John C. Aghadiuno<\/p>\n

9-2 Final Project – System Proposal Document<\/a><\/p>\n

Southern New Hampshire University<\/p>\n

Professor Allyson Heisey<\/p>\n

07\/01\/2018<\/p>\n

 <\/p>\n

 <\/p>\n

Contents<\/p>\n

Introduction. 4<\/a><\/span><\/p>\n

Background. 4<\/a><\/p>\n

Problem Statement 4<\/a><\/p>\n

Audience. 5<\/a><\/p>\n

Systems Requirements. 5<\/a><\/p>\n

Requirements Models. 5<\/a><\/p>\n

Output 5<\/a><\/p>\n

Input 6<\/a><\/p>\n

Process. 6<\/a><\/p>\n

Performance. 6<\/a><\/p>\n

Control 7<\/a><\/p>\n

Data Process Model 8<\/a><\/p>\n

Data Flow Diagram.. 9<\/a><\/p>\n

Data Dictionary. 10<\/a><\/p>\n

Object Modelling. 13<\/a><\/p>\n

Use Cases and Actors. 14<\/a><\/p>\n

Use Case Diagram.. 15<\/a><\/p>\n

State Transition. 16<\/a><\/p>\n

Systems Design. 17<\/a><\/p>\n

Specification. 17<\/a><\/p>\n

Requirements Models. 20<\/a><\/p>\n

Data Design. 22<\/a><\/p>\n

Logical Data Model 23<\/a><\/p>\n

Data Flow Diagram.. 30<\/a><\/p>\n

Data Dictionary. 31<\/a><\/p>\n

Object Models. 34<\/a><\/p>\n

User Interface Design. 36<\/a><\/p>\n

Sitemap. 36<\/a><\/p>\n

Homepage Template. 36<\/a><\/p>\n

People Search Template. 37<\/a><\/p>\n

Person Details Template. 38<\/a><\/p>\n

Case Details Template. 39<\/a><\/p>\n

System Architecture. 40<\/a><\/p>\n

Feasibility Analysis. 42<\/a><\/p>\n

Project Plan. 46<\/a><\/p>\n

Work Breakdown Structure. 46<\/a><\/p>\n

Project Monitoring and Control Plan. 47<\/a><\/p>\n

Definition of Done. 47<\/a><\/p>\n

Timeline. 49<\/a><\/p>\n

Resource Sheet 50<\/a><\/p>\n

Cost Sheet 51<\/a><\/p>\n

References. 52<\/a><\/p>\n

 <\/p>\n

<\/a>Introduction<\/h1>\n

<\/a>Background<\/h2>\n

CPCS currently maintains three separate \u201ccase management\u201d 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\u2019s 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.<\/p>\n

<\/a>Problem Statement<\/h2>\n

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 \u201ccounts\u201d (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.<\/p>\n

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:<\/p>\n