JIN CACH Customer Requirements Report v26.doc

496 views
426 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
496
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

JIN CACH Customer Requirements Report v26.doc

  1. 1. Washington Justice Information Network Criminal and Case History Query Project Customer Requirements Report December 17, 2004 Version 25 (Draft) Online Business Systems One World Trade Center 121 SW Salmon St. Portland, Oregon 97204
  2. 2. Washington JIN CACH Customer Requirements Report Document History Version Date Author Comments 24 16Dec2004 Murray Laatsch Draft submitted to JIN Project Director for approval and consideration by the JIN Steering Committee. 25 17Dec2004 Andy Ross Applied JIN Program Director feedback and re- submitted for approval and consideration by the JIN Steering Committee. ii
  3. 3. Washington JIN CACH Customer Requirements Report Table of Contents 1 INTRODUCTION...................................................................................................................................................1 1.1 DOCUMENT PURPOSE........................................................................................................................................1 1.2 RELATED ARTIFACTS........................................................................................................................................1 1.3 DISTRIBUTION.................................................................................................................................................1 2 EXECUTIVE SUMMARY.....................................................................................................................................2 3 BACKGROUND......................................................................................................................................................4 4 METHODOLOGY..................................................................................................................................................5 5 BUSINESS NEEDS ANALYSIS.............................................................................................................................6 5.1 BUSINESS SCOPE.............................................................................................................................................6 5.2 BUSINESS GOALS AND OBJECTIVES.....................................................................................................................9 5.3 BUSINESS REQUIREMENTS................................................................................................................................14 5.4 CRITICAL SUCCESS FACTORS...........................................................................................................................15 5.5 RISK...........................................................................................................................................................16 5.6 CONSTRAINTS...............................................................................................................................................17 6 USER REQUIREMENTS.....................................................................................................................................18 7 FUNCTIONAL REQUIREMENTS....................................................................................................................20 8 NON-FUNCTIONAL REQUIREMENTS..........................................................................................................24 9 TECHNICAL REQUIREMENTS.......................................................................................................................33 APPENDIX A – REQUIREMENTS ASSESSMENT INTERVIEWS...............................................................34 APPENDIX B – DOCUMENTATION REVIEW................................................................................................35 APPENDIX C – LEGAL AND PROCEDURAL REQUIREMENTS ASSESSMENT....................................37 APPENDIX D – ISSUES.........................................................................................................................................41 iii
  4. 4. Washington JIN CACH Customer Requirements Report 1 INTRODUCTION 1.1 DOCUMENT PURPOSE The primary purpose of this document is to identify, elicit and ratify the requirements of the JIN Criminal History Query Project. Several acronyms are used throughout this document and are briefly explained here: • JIN – Justice Information Network. The overall Washington State Program for integrated justice. • JINDEX – The JIN Data Exchange. This includes the integration broker, the technical infrastructure for implementation, and the Center of Excellence for future development projects. • CACH - Case and Criminal History. While this project was initially named Criminal History Query, stakeholder feedback has indicated the important distinction between case and criminal history information. As such, CHQ is relabeled CACH. The initial set of JIN Requirements has been vetted through stakeholder interviews. The key findings from these interviews are captured and this document will confirm the initial understanding of the project in preparation for technical requirements and Design sessions / interviews. In addition to the review of the related documents, interviews and walkthroughs were conducted to increase the understanding of project team members with respect to the existing system and project needs. The information gleaned has been captured in this document. This document and its included work products are intended to form the initial input into the JAD Sessions that follow to gather and refine technical requirements. 1.2 RELATED ARTIFACTS Artifact Description Contract A04-PSC-007 Contract between State of Washington DIS and Online Business Systems dated 1Nov2004. Statement of Work JIN SOW – Exhibit A within Contract A04-PSC-007. Defines detailed success criteria, deliverables and work expectations. Online Proposal Online Business Systems technical proposal (Volume 1) to Washington DIS in response to RFP # A04-RFP-005. Contains the Overall Online approach being utilized on the project. JIN CHQ Project Charter V12 Approved Project Charter. 1.3 DISTRIBUTION Brian LeDuc State of Washington – JIN Program Director Murray Laatsch Online Business Systems Ltd. – Senior Solutions Architect / JIN CACH Project Manager Andy Ross Online Business Systems Ltd. – Technical Architect / JIN CACH Technical Team Lead Dave Usery URL Integration Ltd. – Integrated Justice Domain Business Analyst David Neufeld Online Business Systems Ltd. – Delivery Manager Version 25 (Draft) Page 1
  5. 5. Washington JIN CACH Customer Requirements Report 2 EXECUTIVE SUMMARY The Customer Requirements report contains summarizations and conclusions of the information that has been acquired through the collaborative series of workshops and interviews with key project stakeholders and contributors to date. The requirements documented here are primarily non-technical in nature. They provide the ratified business requirements upon which the technical requirements and design will be derived. A cursory examination of the proposed requirements initially seemed to reveal the need to simply increase the functionality already inherent within the Summary Offender Profile (SOP) application. That is, enhance this JIN application to permit queries by person demographics such as name, date of birth, etc. The results of this query would reveal a set or list of possible name matches and the associated person identifier. This identifier would then be selected, revealing criminal history information regarding that person only. The search would query both the Washington State Patrol (WSP) and the Administrative Office of the Courts (AOC) repositories, combining the results into a consolidated criminal history query. The results of our detailed examination of the underlying business goals, user requirements, functional requirements and non-functional requirements tells a different story altogether. In fact, the requirements of the JIN stakeholders clearly express the need for a statewide standard framework and an architected set of services that are designed to support a wide variety of state based criminal justice Agencies. The solution would be application to application integration without a large focus on the User Interface but more focus on how individual agency solutions (JILS, Protrak) could be enhanced by calling standard services to augment local information instead of re-building interfaces with each agency – rebuilding what each other already has. The onus for this project will be on developing a single access method for such services and registering their availability and potential for reuse. A maturing set of middleware standards have made such a solution practical and affordable. But more importantly, standards are drawing likeminded agencies together into ‘communities of interest’ such as JIN. All with the goal of leveraging these standards (Justice XML GJXDM, Web Services and Service Oriented Architecture methodologies) to promote the overall objective – Public Safety. What are the requirements for a central state integrated justice web services registry? This document introduces the requirements from a business perspective. While the individual web services (Criminal History Queries introduced in the RFP) are part of the solution, the development of these web services is intended to provide examples of the types of services that can be registered. This framework, JINDEX (Justice Information Network Data Exchange) will provide developers with an easily accessible Center Of Excellence, containing ratified standards, example solutions, and most of all a central standards based registry upon which each agency can expose a single accepted invocation method for which they expect all other agencies to use in support of their local criminal justice efforts. Within this document are sections that cover: Methodology. The JIN Criminal History Project relies on a standard definition of the principals of Service Oriented Architecture (SOA). The Customer Requirements deliverable provides a brief overview of the principles of SOA and the methodology that has been adopted for the JIN CHQ project. Business Needs Analysis – provides an evaluation of proposed requirements and the specification of business requirements discovered from the review of background documentation and stakeholder/steering committee interviews. Context. This section contains a statement on the project’s business scope intended to define the boundaries of the project effort, define the business domain and introduce key concepts and terminology that will be used throughout the remainder of the project efforts. The project’s business goals and objectives are represented as a collection of business requirements that have been determined from a number of inputs – including JIN technology and design principles from JIN office charters and documentation as well as proposed JIN requirements that have been discovered thru the collaborative series of workshops and interviews with key project stakeholders and contributors to date. Building upon goals and objectives within scope, the business requirements are more distinctly defined. In general, business requirements restate the JIN vision and direction. Ratifying this set of business requirements permits the correlation and trace-ability of each requirement (user, functional and non-functional) back to a Version 25 (Draft) Page 2
  6. 6. Washington JIN CACH Customer Requirements Report business reason. The project’s critical success factors provide a list of the overriding factors and accomplishments necessary within the architecture to consider the effort a success. Importantly, in keeping with the distinction between the two facets of the project, the success factors have been similarly listed distinctly – one list presenting factors that relate to what is referred to now as JINDEX, the second listing those factors related to the JINDEX CACH (Case And Criminal History Services. Finally within the context of the Business Needs Analysis, a number of project risks and constraints have been identified and documented. User Requirements provide a concrete list of behaviors and functionality that users expect to see from the solution. The user requirements have been derived from stakeholder interviews and represent both the requirements of the integration framework (JINDEX) and the JINDEX CACH web services, as identified in the Business requirements. Finally, the complete known list of functional, non-functional requirements as discovered during stakeholder interviews and existing documentation reviews are presented. Version 25 (Draft) Page 3
  7. 7. Washington JIN CACH Customer Requirements Report 3 BACKGROUND The justice process in Washington involves federal, state and local entities, including law enforcement officers, courts, prosecutors, and corrections. The stakeholders in this process employ a variety of mainframe and server-based applications. There are numerous policies, rules, and standards relating to these systems. The Justice Information Network (JIN) will be the means by which these constituents share information. The Integrated Justice Information Board (The Board) is the governance structure for JIN. The governor and the legislature have endorsed the JIN effort and its governing board is established by statute. The Board’s membership includes the Chief of the Washington State Patrol, the Attorney General, Administrator for the Courts, the Chief Information Officer, the Secretary of the Department of Corrections, Director of the Department of Licensing and various members of the local justice community, including sheriffs, police chiefs, prosecutors, judges and county clerks. Additional background is available on the JIN website at www.jin.wa.gov. The mission of JIN is to improve public safety by providing criminal justice practitioners with complete, timely and accurate information, and to improve operating efficiency by facilitating the integration of disparate systems throughout the state. Pursuant to statute (RCW §10.98.200), JIN has the following objectives: • Maximize standardization of data and communications technology; • Improve workflow within the criminal justice system; • Provide complete, accurate, and timely information to criminal justice agencies; • Maintain security and privacy rights respecting criminal justice information. JIN will be the foundation for justice information sharing projects within the State enterprise and participating local government entities. Once implemented, JIN will give its participants the ability to exchange information and conduct transactions reliably, in real time, consistent with the individual operational requirements of the agencies. Generally, the JIN should support the following: • Manage movement of data among applications; • Support consolidated queries among applications; • Interact with existing technology, without the need to invest in major changes or upgrades to existing applications or infrastructure; • Provide a user interface for access to justice information; • Provide for data security and user authentication The Board has engaged Online Business Systems to assist in developing and implementing a model for information sharing in the justice community and for the construction of a service that validates the model. The Board is seeking solutions based on an open, distributed standards and service-based architectures that improve the flow of information in a flexible and cost-effective manner. The goal of the project is to assist the Board in answering the following questions (Part 1) and to build and deploy a consolidated query of justice information (part 2): Part 1 What are the network security and performance requirements of the justice community? How should justice information move physically and logically across the network? Part 2 Design and deploy a standards and service-based query tool for public information that extracts information from the AOC and WSP data repositories to allow for identification of suspects and to provide consolidated history for known individuals. Version 25 (Draft) Page 4
  8. 8. Washington JIN CACH Customer Requirements Report 4 METHODOLOGY The JIN Criminal History Project relies on a standard definition of the principals of Service Oriented Architecture (SOA). Familiarity with the principals of SOA forms the methodology for the eventual solution. In fact, the evolution of this methodology has influenced Public and Criminal Justice Practitioner expectations that their needs for integrated justice can be achieved and will provide value. As with most methodologies or approaches, the precise definition of SOA is impossible to pin down, however, Online has adopted a working definition for this project which is based on the materials of thought leaders in this field and Online’s internal methodology (ROAD Rapid Online Application Development). SOA - The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface. SOA is as a style resulting from the use of particular policies, practices and frameworks that deliver services that conform to certain industry accepted norms. Examples include certain granularity, independence from the implementation platform or location, and standards compliance. What these definitions highlight is that any form of service can be exposed with a web services interface. However higher order qualities such as reusability and independence from implementation, will only be achieved by employing some science in a design and building process that is explicitly directed at incremental objectives beyond the basic interoperability enabled by use of web services. The goal for a SOA is a worldwide mesh of collaborating services, which are published and available for invocation. Adopting SOA is essential to deliver the business agility and IT flexibility promised by web services. These benefits are delivered not by just viewing service architecture from a technology perspective and the adoption of web service protocols, but require the creation of a Service Oriented Environment that is based on the following key principals. • Service is the important concept. Web Services are the set of protocols by which Services can be published, discovered and used in a technology neutral, standard form. Properly architected and designed logic is still required, behind this web services façade. • SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed. • With SOA it is critical to implement solutions that ensure that there are at least two different and separate processes—for provider and consumer. Rather than leaving developers to discover individual services and put them into context, the Service Registry is instead their starting point that guides them to a coherent set that has been assembled for their domain. The State of Washington Criminal Justice domain – JINDEX (Justice Information Network Data Exchange). If the principles of service oriented architecture are complied with, the following benefits are achievable: There is real synchronization between the business and IT implementation perspective. For many years, business people haven't really understood the IT architecture. With well designed services we can radically improve communications with the business, and indeed move beyond alignment and seriously consider convergence of business and IT processes. A well formed service provides us with a unit of management that relates to business usage. Enforced separation of the service provision provides us with basis for understanding the life cycle costs of a service and how it is used in the business. When the service is abstracted from the implementation it is possible to consider various alternative options for delivery and collaboration models. No one expects that, at any stage in the foreseeable future, core enterprise applications will be acquired purely by assembling services from multiple sources. However it is entirely realistic to assume that certain services will be acquired from external sources because it is more appropriate to acquire them. For example authentication services, a good example of third party commodity services that can deliver a superior service because of specialization, and the benefits of using a trusted external agency to improve authentication. Version 25 (Draft) Page 5
  9. 9. Washington JIN CACH Customer Requirements Report 5 BUSINESS NEEDS ANALYSIS This section is part evaluation of proposed requirements and the specification of Business Requirements derived from the review of background documentation and Stakeholder/Steering Committee interviews. In addition, critical success factors, risks and constraints are identified. Prior to examining the proposed requirements, it seems prudent to introduce the context of the JIN Criminal History Query project though an examination of the Business Scope. 5.1 BUSINESS SCOPE This section is intended to define the boundaries of the project effort, define the business domain and introduce key concepts and terminology that will be used throughout the remainder of the project efforts. The background section of this document introduced the Stakeholders of JIN. The following diagram depicts a subset of these as Key Stakeholders in Unified Modeling Language (UML) ‘actor’ notation. ud Context - JIN Stakeholders Justice Information Netw ork (JIN) CHQ Proj ect Key Stakeholder Key Stakeholder Key Stakeholder Key Stakeholder Department of Key Stakeholder Information Systems (DIS) King County (KC) Washington State Yakima County (YC) Patrol (WSP) Adminstrativ e Office of the Courts (AOC) Version 25 (Draft) Page 6
  10. 10. Washington JIN CACH Customer Requirements Report In terms of a services oriented architecture, the JIN Stakeholders are can be viewed as both Service Providers and Service Consumers. The majority of these Stakeholders are State Criminal Justice Agencies, that make up the limited scope of service consumers for JIN. This is in contrast to the broad scope of Service Providers, which may include Local, County, State or Federal agencies. The following diagram depicts this service provider/consumer contrast. ud Context - Actors Serv ice Prov ider Serv ice Consumer Other Gov ernment Criminal Justice Agencies Agencies Federal Justice County Justice Local Justice Agencies State Justice Agencies Agencies Agencies JIN CHQ Project Seattle Municipal Court Other Local Justice Agencies Other Counties Tacoma County Pierce County JIN CHQ Project Yakima County (YC) King County (KC) Washington State Adminstrativ e Office Corrections Other State Justice Patrol (WSP) of the Courts (AOC) Agencies Criminal Justice Practitioners Couty Clerks Law Enforcement Officers Public Defenders Prosecutors Judges The preceding diagram presents an important concept/requirement for JINDEX. That is, only Criminal Justice Agencies are Service Consumers. That is the mandate of JIN. This does not preclude Other Government Agencies from being Service Providers, in essence, developing services that are certified and Registered with JINDEX, making them available to this targeted set of Service Consumers. Version 25 (Draft) Page 7
  11. 11. Washington JIN CACH Customer Requirements Report The following diagram provides context for the Customer Requirements. Boundaries are drawn between JINDEX and the Service Providers that form the scope for the JINDEX CACH Services. This is not a long term vision context diagram. It represents the vision upon completion of the JIN CHQ Project, whereas, the longer term vision would include many more Service Providers and Service Consumers. They have been excluded for clarity and brevity and to reflect project scope. ud Context JINDEX JINDEX Center Of Excellence (COE) « artifact» « artifact» « artifact» Standards XML Schemas Implementation Patterns Serv ice Dev eloper « artifact» « artifact» « artifact» Contractual Guidelines / Forms Code Examples Best Practices « common service» « artifact» « artifact» COE Prov isioning Marketing and Education Test Cases Criminal Justice Agencies JINDEX Support Serv ices AOC « artifact» WSP « common service» Service Contracts Dev elopment « datastore» AOC Case Repository « datastore» « artifact» « common service» WSP ACCESS Criminal Certification / Governance Model Adminstration History Repository JINDEX Serv ice Registry JINDEX CACH Serv ices « web service» Consolidated Person ID by Person JINDEX CACH Serv ices « web service» Detail Query AOC Person ID by Case Person Detail Query « web service» « web service» WSP Person ID by File Person Detail Query Consolidated Detail by Person ID Query « web service» « web service» AOC Case Detail by Person ID Query WSP Charge Detail by Person ID Query « common service» « common service» Web Service Director Logging and Audit Notification « common service» « common service» Security Registration « common service» Message Serv ice Prov ider Validation « service request» « service request» Yakima County King County Protrack JILS Criminal Justice Practitioners The notation used is not intended to imply a physical hosting arrangement nor a responsibility to deliver. This diagram is above all a reflection of needs. The needs for JINDEX are shown in UML package notation, representing groups of related high level functionality requirements. These groups include: JINDEX Center Of Excellence, containing many artifacts or document repositories for primary use by Service Version 25 (Draft) Page 8
  12. 12. Washington JIN CACH Customer Requirements Report Developers. JINDEX Support Services – providing the development, administrative and governance models for JINDEX. JINDEX Services Registry – providing the central web Services Director, receiving service requests from both Yakima and King County applications with the intent of directing the service calls to wherever the may reside. Providing location transparency for the Agency Applications. The JINDEX CACH Services are packages contain the repository specific web services, with the Consolidated web services being assembled ‘on the fly’ within the JINDEX Service Registry. Throughout this context diagram are nodes labeled (stereotyped) <<common services>>. This designation aligns with the principals of Service Oriented Architecture, stressing reuse of logging, error handling and other less ‘business aligned’ services than their outward facing cousins – the <<web services>>. 5.2 BUSINESS GOALS AND OBJECTIVES In attempting to validate the JIN goals for technology, design principles and proposed requirements, we must examine them in comparison to the principals of Service Orientation. In defining and clarifying these principals, they become valuable in setting policies, benchmarks and so on. The majority of the technology principals / proposed requirements have been restated as Business Requirements or User Requirements, subsequent to stakeholder interviews and a validation effort involving the Steering Committee members. Where no obvious applicability could be found, or the goal requires clarification, an issue number is assigned. Each issue is explored in greater detail in the Issues section found in Appendix D. Proposed Business Goal Description Project Applicability JIN Technology Principles JIN constituents should conform to This principal has been national, state, and open industry incorporated into a Business Standards standards wherever possible. Requirement BR7. JIN Technology Principles New applications should focus on This principal has been interoperability with the JIN infrastructure incorporated into a Business Interoperability and data sharing as part of the design Requirement BR1. process. JIN Technology Principles The JIN community will use shared This principal has been infrastructure appropriately and leverage incorporated into a Business Shared Infrastructure existing infrastructure to the fullest extent Requirement BR2. possible. JIN Technology Principles Disclosure of data is the responsibility of This principal has been the owner of the data according to incorporated into a Business Security and Privacy applicable laws. Applications, data and Requirement BR6. security are the responsibility of their respective owners. JIN Technology Principles Applications that need to exchange data This principal has been via the JIN should be designed or incorporated into a Critical Applications and Data enhanced to be compatible with the JIN Success Factor CSF6. Exchanges infrastructure. JIN Technology Principles Applications should use common, reusable This principal has been components, data and designs wherever incorporated into a Business Reusable Components possible. Requirement BR4. JIN Design principles Exchanges will be event-driven and This principal requires timely, and designed to optimize clarification and is explored in Exchanges efficiency for publishers and subscribers. greater detail in Appendix D, Issue I01. Version 25 (Draft) Page 9
  13. 13. Washington JIN CACH Customer Requirements Report Proposed Business Goal Description Project Applicability JIN Design Principles The Justice Information Network is a This principal has been service provider. incorporated into a Business Services Requirement BR3. JIN Design Principles Exchanges will be secure and will comply This principal has been with all state and federal requirements. incorporated into a Business Security Requirement BR6. Proposed JIN Requirements Allow applications to be integrated in a This proposed requirement has loosely coupled fashion. been incorporated into a Business Core Application Requirement BR4. Proposed JIN Requirements Support industry standard component This proposed requirement has models. been incorporated into a Business Core Application Requirement BR7. Proposed JIN Requirements Support open communications protocols. This proposed requirement is explored in greater detail in Core Application Appendix D, Issue I12. Potential Technical Requirement. Proposed JIN Requirements Implement integration with minimal This proposed requirement is impact and changes to existing explored in greater detail in Core Application applications. Appendix D, Issue I01. Proposed JIN Requirements Allow processing to continue if one or This proposed requirement has more connected applications are been incorporated into a User Core Application temporarily unavailable. Requirement UR17. Proposed JIN Requirements Make use of third party databases for the This proposed requirement is storage of business rules, routing explored in greater detail in Core Application information, metadata information, and Appendix D, Issue I10. schema definitions. Potential Technical Requirement. Proposed JIN Requirements Allow applications to register their This proposed requirement has services or their interest in a given event been incorporated into a User Core Application without disrupting the operation or Requirement UR04. configuration. Proposed JIN Requirements Provide a secure and managed The security aspect of this environment for integration exchanges. proposed requirement has been Core Application incorporated into Business Requirement BR6 with the managed environment aspect incorporated into Business Requirement BR4. Proposed JIN Requirements Scale the solution as applications, This proposed requirement has transactions, and services are added. been incorporated into a Non- Core Application Functional Requirement NFR14. Proposed JIN Requirements Facilitate guaranteed, bi-directional The bi-directional aspect of this information exchange among disparate proposed requirement has been Communications applications. incorporated into Business Requirement BR1 with the guaranteed aspect explored in greater detail in Appendix D, Issue I01. Version 25 (Draft) Page 10
  14. 14. Washington JIN CACH Customer Requirements Report Proposed Business Goal Description Project Applicability Proposed JIN Requirements Fully functional transactional and data This proposed requirement is integrity infrastructure for the network explored in greater detail in Communications Appendix D, Issue I11. Proposed JIN Requirements Employ a protocol that supports once only This proposed requirement is delivery of messages. explored in greater detail in Communications Appendix D, Issue I12. Potential Technical Requirement. Proposed JIN Requirements Message queues and the tools required for This proposed requirement is managing those queues. explored in greater detail in Communications Appendix D, Issue I13. Potential Technical Requirement. Proposed JIN Requirements Transform or manipulate the data before This proposed requirement is either transporting it to another application explored in greater detail in Communications or presenting it to a user. Transformation Appendix D, Issue I18. capabilities must include both logical Potential Technical Requirement. (e.g., field merges) and structural (e.g., format changes) transformations. Proposed JIN Requirements Define these transformations as business This proposed requirement is rules to be performed during any activity explored in greater detail in Communications involving a specific data source. Appendix D, Issue I18. Potential Technical Requirement. Proposed JIN Requirements Provide guarantee once-only message This proposed requirement is delivery. explored in greater detail in Communications Appendix D, Issue I01. Proposed JIN Requirements Provide the ability to return receipts of This proposed requirement is message deliveries. explored in greater detail in Communications Appendix D, Issue I01. Potential Functional Requirement. Proposed JIN Requirements Allow for content-based message routing. This proposed requirement has been incorporated into a Business Communications Requirement BR7. Proposed JIN Requirements Provide notification of message delivery This proposed requirement is failure, and maintain state to rollback and explored in greater detail in Communications restore data in the event of failure. Appendix D, Issue I01. Proposed JIN Requirements Provide the ability to dynamically This proposed requirement is reconfigure message routing without considered a Technical Communications impacting any services. Requirement and is explored in greater detail in Appendix D, Issue I18. Proposed JIN Requirements Provide the ability to log high-priority The priority aspect of this messages to persistent storage without proposed requirement has been Communications impacting performance incorporated into User Requirement U18 with the storage aspect explored in greater detail in Appendix D, Issue I10. Version 25 (Draft) Page 11
  15. 15. Washington JIN CACH Customer Requirements Report Proposed Business Goal Description Project Applicability Proposed JIN Requirements Provide the ability to restrict or control The restrict or control aspect of message delivery based on security-based this proposed requirement has Communications access rights; Provide a security schema been incorporated into Business that can be based on individual messages, Requirement BR6 with the message groups, or message content. security schema considered a Technical Requirement and is explored in greater detail in Appendix D, Issue I04. Proposed JIN Requirements Perform all message transport This proposed requirement has transparently among different hardware been incorporated into a Business Communications platforms, databases, and operating Requirement BR1. systems. Proposed JIN Requirements Metadata management associated with the This proposed requirement has data, exchanges, transactions, and been incorporated into a User Data Management processes developed within and connected Requirement UR03. to the JIN. Proposed JIN Requirements Data schema management and This proposed requirement has documentation to be used in been incorporated into a Business Data Management transformations and exchanges, including Requirement BR7. the ability to manage an exchange schema using JusticeXML v3.0 Proposed JIN Requirements Relational database to capture information This proposed requirement is to support audit, reporting, and considered a Technical Data Management administration functions. Requirement and is explored in greater detail in Appendix D, Issue I10. Proposed JIN Requirements JIN should provide software connections This proposed requirement has among agency platforms, applications, and been incorporated into a Business Connectivity databases in a scalable, high-performance, Requirement BR1. non-intrusive manner. Proposed JIN Requirements Enable the organization to perform This proposed requirement has standard data exchanges, XML based been incorporated into a Business Connectivity communications, and file exchanges with Requirement BR7. other participants, regardless of the existing technology employed by either the transmitting or receiving systems. Proposed JIN Requirements Include the mechanisms for providing the This proposed requirement is required connectivity for all applications considered a Technical Connectivity in the justice community. This may Requirement and is explored in include off-the-shelf adapters to connect greater detail in Appendix D, Issue to the relevant technologies, or guidelines I17. for creating such adapters. Proposed JIN Requirements Include development tools that can This proposed requirement is support the aspects of integration considered a Technical Application and Interface associated with developing web-based Requirement and is explored in Development Services applications and user interfaces. greater detail in Appendix D, Issue I16. Version 25 (Draft) Page 12
  16. 16. Washington JIN CACH Customer Requirements Report Proposed Business Goal Description Project Applicability Proposed JIN Requirements Basic graphical UI development for This proposed requirement is presenting data consolidated from multiple considered a Technical Application and Interface sources. Requirement and is explored in Development Services greater detail in Appendix D, Issue I14. Proposed JIN Requirements Small-scale application development This proposed requirement is leveraging data and components from considered a Technical Application and Interface underlying systems. Requirement and is explored in Development Services greater detail in Appendix D, Issue I15. Proposed JIN Requirements Mission critical application development This proposed requirement is capabilities considered a Technical Application and Interface Requirement and is explored in Development Services greater detail in Appendix D, Issue I15. Version 25 (Draft) Page 13
  17. 17. Washington JIN CACH Customer Requirements Report 5.3 BUSINESS REQUIREMENTS This section lists the reasons that JIN needs the Criminal/Case History Query application and why it needs a service oriented integration framework. In general, business requirements restate the JIN vision and direction. Ratifying this set of business requirements permits the correlation and traceability of each requirement (user, functional and non-functional) back to a business reason. ud Business Requirements «BR7» «BR8» Promote Public Safety Integration Standards Criminal Justice Practitioners «BR1» Exchange Criminal Justice Information «BR2» Lev erage Existing State Infrastructure «BR9» «BR6» Physical Netw ork JIN Legislated Connectiv ity «BR3» Information Prov ide Criminal Ow nership Justice Integration Serv ices «BR4» Central Statew ide Integration «BR5» Framew ork Criminal Justice Lev erage Summary Agencies Offender Profile Application Version 25 (Draft) Page 14
  18. 18. Washington JIN CACH Customer Requirements Report Each Business Requirement (BR##) identified is explored in greater detail in the following table. This list is presented as the findings from the Stakeholder Interviews and the background documentation review. # Business Requirement BR Exchange Criminal Justice Information. 1 BR Leverage Existing State Infrastructure. 2 BR Provide Criminal Justice Integration Services. 3 BR Central State Integration Framework. 4 This is the main premise of JINDEX, providing the Center Of Excellence, Support Services and the Services Registry. BR Leverage Summary Offender Profile Application. 5 Both the application logic and the lessons learned from the development project. BR Legislated Information Ownership. 6 Not a business requirement of JIN, but remains a requirement / responsibility of Criminal Justice Agencies. BR Promote Integration Standards. 7 Advocacy within JIN stakeholders and state agencies – encouraging them to adopt pure service-oriented architecture as they migrate their applications to web-based platforms. Doing so will significantly reduce the costs and risks of integration. BR Public Safety. 8 Not a business requirement of JIN, but remains a requirement / responsibility of Criminal Justice Practitioners. BR Physical Network Connectivity. 9 Not a business requirement of JIN, but remains a requirement / responsibility of Criminal Justice Agencies. 5.4 CRITICAL SUCCESS FACTORS The following is a list of specific overriding factors and accomplishments necessary within the architecture to consider the effort a success. Typically, these are very specific and constrained restatements of one or more of the business goals. This section presents considerations for Critical Success Factors (CSF##). The Requirements Baseline will define the quantitative techniques that will be used for measurement. In keeping with the distinction between the 2 facets of the JIN CHQ Project as discovered during the requirements assessment activities, the Critical Success Factors have been separated into 2 tables. The first presents those factors that relate to what is being referred to as JINDEX. The second lists those factors related to the actual web services themselves. In order to make then recognizable and discernable, they are referred to as JINDEX CACH Services. The numbering schema used to reference each Critical Success Factor (CSF) has evolved from the presentation at the Steering Committee validation meeting. As such, the numbers are randomly distributed between the 2 tables. Version 25 (Draft) Page 15
  19. 19. Washington JIN CACH Customer Requirements Report This is intentional. JINDEX # Critical Success Factor CSF2 Increased awareness of Criminal Justice service availability. CSF5 Criminal Justice Agencies increase solution delivery effectiveness by leveraging SOA best-practices and examples. CSF6 Criminal Justice Agencies design / deliver solutions and projects that use or consider JINDEX principals. The following table outlines the Critical Success Factors related to the second aspect of this project, the query services themselves. JINDEX CACH Services # Critical Success Factor CSF1 AOC Case and WSP Criminal History repository information consumable as a web service. CSF3 King County users are delivered Integrated Justice information through web services interface. CSF4 Yakima County users are delivered Integrated Justice information through web services interface. 5.5 RISK This section outlines the Risks (R##) inherent or perceived with regards to the previously identified Business Requirements. The requirements Baseline deliverable will explore each risk in detail, including the outline of a plan for each item, declaring how much risk can be tolerated and the means to do so. # Risk R Evolving Web Services standards. 1 Some form of governance for the standards is required to be ratified by the state to facilitate service development against these standards. R Criminal justice agency reliance on vendor delivered Solutions. 2 R Lack of broad Service Oriented Architecture education. 3 This includes lack of awareness of the benefits related to developing applications within an architected solution. Benefits are not short term, but are realized as the number of services increase. R Interpretations of security and ownership responsibilities. 4 Version 25 (Draft) Page 16
  20. 20. Washington JIN CACH Customer Requirements Report # Risk R Proliferation of project documentation to assist solution developers. 5 The sheer volume of material that must be consulted in order to determine which standards to adhere to is overwhelming. R Other Integrated Justice initiatives within the state define/adopt conflicting standards. 6 This risk is related to existing initiatives, like e-citations, that are either relying on the standards that JINDEX has yet to ratify or developing solutions without considering potential JINDEX services for reuse. 5.6 CONSTRAINTS This section outlines the assumptions and Constraints (C##) that have been captured as a starting point. Each of these has been vetted with project stakeholders through the interview process. Constraints include those gleaned from an assessment of the Legal and Procedural requirements for information sharing, details of which is contained the Appendix C of this document. Constrains are factors that place limitations or direction on the design of the eventual solution but are not necessarily related to any specific business goal or requirement. # Constraint C All JINDEX web services will adhere to common WS Standards, including the ratified WS-nn family 1 of standards. The standards adopted by JINDEX will be examined and defined during Design. C JIN does not have the legislative responsibility of providing guaranteed delivery of messages between 2 stakeholders. This issue is explored in Issue # I01 in Appendix D. C Service consumers are restricted to Criminal Justice Agencies. 3 This does not preclude the certification and registration of services by Other Government Agencies. C All service requests and replies will use HTTPS transport. 4 Version 25 (Draft) Page 17
  21. 21. Washington JIN CACH Customer Requirements Report 6 USER REQUIREMENTS User Requirements (UR##) give a concrete list of behaviors and functionality that users expect to see from the solution. The following user requirements have been derived from stakeholder interviews and represent both the requirements of the integration framework (JINDEX) and the CACH Case And Criminal History web services, identified in the business requirements. JINDEX # User Requirement User UR1 Allow access to service usage/access details to support ownership auditing. Service Owner UR3 Receive examples, guidance and best practices for developing services Service Developer / destined for registering on JINDEX. Tester UR4 Permit users to register their intent to receive new services. Criminal Justice Practitioner UR7 Notification of new service availability. Criminal Justice Agency UR8 View service availability including current up/down status of underlying Service Developer / service components. Tester Criminal Justice Practitioner UR9 Notification when errors occur. Solution Support U10 Support the design, development, testing and deployment of web services Service Developer / solutions. Tester UR1 Standards & guidelines conformance. Service Developer / 5 Tester UR1 Maintain/view service contracts between Service Provider and Service Service Developer / 6 Consumer. Tester Service Owner UR1 Service developers will utilize the JINDEX web services as examples of Service Developer / 8 suitable design / patterns implementation and implementation best Tester practices. Version 25 (Draft) Page 18
  22. 22. Washington JIN CACH Customer Requirements Report JINDEX CACH Services # User Requirement User UR2 All services will be consumable through WS-nn and a generic Web User Service Developer / Interface. Tester UR5 Broker automated authorization according to the service owner Criminal Justice requirements. Agency UR6 Companion test services that support service solution development. Service Developer / Tester UR1 WSP Criminal Justice “ACCESS switch” repository information Service Developer / 1 available through an ‘ID of Possible Match Query’ Web Service. Tester Criminal Justice Practitioner UR1 AOC Case repository information available through an ‘ID of Possible Service Developer / 2 Match Query’ Web Service Tester Criminal Justice Practitioner UR1 WSP Criminal Justice “ACCESS switch” repository information Service Developer / 3 available through a ‘Consolidated Criminal History Query’ Web Service. Tester Criminal Justice Practitioner UR1 AOC Case repository information available through a ‘Consolidated Service Developer / 4 Criminal History Query’ Web Service. Tester Criminal Justice Practitioner UR1 Allow processing to continue if one or more connected application is Criminal Justice 7 temporarily unavailable. Practitioner UR1 Utilize the CACH services as examples of suitable design / patterns Criminal Justice 8 implementation and implementation best practices. Practitioner UR1 WSP Criminal Justice “ACCESS switch” repository information and the Service Developer / 9 AOC Case repository information available through a single combined Tester ‘ID of Possible Match Query’ web service. Criminal Justice Practitioner UR2 WSP Criminal Justice “ACCESS switch” repository information and the Service Developer / 0 AOC Case repository information available through a single combined Tester ‘Consolidated Criminal History Query’ Web Service. Criminal Justice Practitioner Version 25 (Draft) Page 19
  23. 23. Washington JIN CACH Customer Requirements Report 7 FUNCTIONAL REQUIREMENTS This section outlines the collective Functional Requirements (FR##) for the JINDEX CACH services and the associated JINDEX framework. These requirements show the intended behavior of the solution and define the application capabilities that are required to fulfill the User Requirements. ud Functional Requirements JINDEX Center Of Excellence «FR24» «FR25» Publish Standards « include» View Standards «FR26» «FR27» Publish Code View Code Examples « include» Examples « include» Criminal Justice Serv ice Dev eloper «FR28» Agencies View Serv ice API JINDEX Support Services «FR37» «FR38» Dev elop Serv ice «FR39» Test Serv ice Host Consolidated Serv ices «FR31» «FR22» Certify Serv ice View Serv ice Metrics JINDEX Service Registry «FR30» «FR32» «FR21» Apply for Serv ice Register New View Serv ices Certification JIN « include» Av ailable Serv ice « include» «FR36» Register Interest «FR33» «FR34» in Serv ice Type «FR29» Add Integration View Integration View Serv ice Contract « include» Contract Certification Requirements «FR4» «FR35» «FR23» Notification of Contract «FR20» Resume/Suspend Serv ice Type Expiration View Audit Log Serv ice Status Change Notification JINDEX CACH Services JINDEX Common Services Query AOC «FR15» Person ID by External Person Details Authorization «FR5» « include» « include» « include» Query «FR16» Consolidated Redirect Serv ice « include» Person ID by Calls Protrack (Yakima Person Details County) « include» « include» « include» «FR11» «FR10» Authorize Serv ice Query WSP Authenticate User Person ID by « include» Serv ice User Person Details « include» « include» Query AOC Case « include» Detail by Person ID «FR18» Validate Message Query « include» Consolidated Detail by Person ID JILS (King County) « include» «FR19» Query WSP File Audit Serv ice Usage Detail by Person ID The preceding diagram presents a high level overview of JINDEX functional requirements, as a means of demonstrating the breadth of potential user interactions with JINDEX. This diagram is not intended to define the scope of this project, as this is documented elsewhere. As well, readers should not infer automated or machine- Version 25 (Draft) Page 20
  24. 24. Washington JIN CACH Customer Requirements Report based solutions for each node in the diagram, as many will likely be delivered manually. The complete set of Functional Requirements is presented in the following table. JINDEX # Functional Requirement User Requirement Ref FR1 WSP ACCESS data will be accessible through an ‘ID of Possible Match’ UR11 query. In this query, a subset of a person’s attributes is passed into ACCESS. ACCESS returns a list of persons who are possible matches based on the input. FR2 WSP ACCESS data will be accessible through a ‘Criminal History’ query. UR13 In this query, an explicit person identifier is passed into ACCESS. ACCESS returns all criminal history data for that person. FR3 AOC data will be accessible through an ‘ID of Possible Match’ query. In UR12 this query, a subset of a person’s attributes is passed into AOC. AOC returns a list of persons who are possible matches based on the input. FR4 AOC data will be accessible through a ‘Case History’ query. In this query, UR14 an explicit person identifier is passed into AOC. AOC returns all case history data for that person. FR5 A ‘Consolidated ID of Possible Match’ query will access both AOC and UR19 WSP systems. Given a single request to the consolidated query, the query will in turn redirect the request to both AOC and WSP systems. FR6 A ‘Consolidated Case and Criminal History’ query will access both AOC UR20 and WSP systems. Given a single request to the consolidated query, the query will in turn redirect the request to both AOC and WSP systems. FR7 All queries will be implemented as asynchronous request/reply web UR2 services. FR8 JINDEX will implement reliable messaging, to include definable UR17, UR9 conversations (i.e. a CACH conversation can take different parameters from other, future conversations) and configurable parameters, including number of retries, time between retries, and escalation/notification procedures (e.g. email alerts) FR9 All requests and replies will consist of a SOAP message with an embedded UR2 Justice XML document in the SOAP body FR10 A common JINDEX authorization service will interface with existing UR5 Washington State security gateways, injecting security tokens in the SOAP header in accordance with information received from the gateway (e.g. a user sends a basic SOAP request with no security tokens in the header. The request goes through Fortress authenticated. JINDEX authorization service builds a WSS header to inject in the SOAP header of the original message. This example is illustrative only; design will be finalized during the design phase) FR11 Standardized security tokens (e.g. username, ORI, GUID) in the SOAP UR5 header will enable external applications to perform necessary authorization, without needing to re-authenticate. FR12 Translation to and from Justice XML and existing AOC interfaces will be done by the JINDEX integration framework. Existing interfaces may or may not include leveraging other applications that are currently interfacing with this system. Version 25 (Draft) Page 21
  25. 25. Washington JIN CACH Customer Requirements Report JINDEX # Functional Requirement User Requirement Ref FR13 Translation to and from Justice XML and existing WSP interfaces will be done by the JINDEX integration framework. Existing interfaces may or may not include leveraging other applications that are currently interfacing with this system. FR14 As an asynchronous request/reply pattern, all requests must contain the URI to which replies should be posted. FR15 Service providers will be responsible for providing services/logic that can be accessed by a JIN common authorization service, such that, JINDEX brokers the call for authorization. FR16 Service calls from Agency applications will be redirected to a web service UR17 that fulfills the request embedded in the call. This is done in a location transparent fashion. Service consumers will be responsible for developing application functionality that can handle multiple replies received asynchronously (e.g. a request from JILS will be redirected to both AOC and WSP. AOC and WSP will respond separately to JILS. JILS must be able to refresh query display results as they are received from AOC and WSP) FR17 All requests and replies will conform to the WS-I Basic Profile, and UR2, UR18 potentially other WS-I profiles, as determined in the project design phase. FR18 JINDEX will be capable of validating individual messages against relevant XSD schemas (although performance considerations may recommend or dictate that validation be performed at endpoints, rather than in the messaging framework) FR19 All messages sent across JINDEX will be logged. Sender, receiver, UR1 date/time, and message type will be recorded at a minimum. FR20 Users will be able to examine JINDEX logs both for debugging and audit UR1 purposes. Access rights to examine logs will be restricted. All users will be able to examine transactions where they were either the sender or the receiver. Only selected users will be able to examine complete logs. FR21 Service status and availability will be visible to authorized users UR8 FR22 Service usage metrics will be visible to administrator users UR1 FR23 Criminal Justice Agencies / service producers (the owners of a particular service) will be able to both suspend and resume their services. Suspending a service takes it offline from the JINDEX, essentially insulating it from receiving any messages from the framework. Resuming a service brings it back online. FR24 JINDEX users will be able to publish standards for service development UR3 in the Center of Excellence FR25 Criminal Justice Agencies will be able to view standards for service UR3 development in the Center of Excellence FR26 JINDEX users will be able to publish code examples for service UR3 development in the Center of Excellence FR27 Criminal Justice Agencies will be able to view code examples for service UR3 development in the Center of Excellence Version 25 (Draft) Page 22
  26. 26. Washington JIN CACH Customer Requirements Report JINDEX # Functional Requirement User Requirement Ref FR28 Criminal Justice Agencies users will be able to view Service APIs for UR3 service development in the Center of Excellence FR29 JINDEX users will be able to view Service Certification Requirements FR30 Criminal Justice Agencies will be able to apply for certification of new services FR31 JINDEX users will be able to certify new services FR32 Once certified, service providers will be able to register their new services FR33 Service providers will be able to add/publish integration contracts, UR16 defining specific requirements for use of their service(s) (e.g. WSP may require the ORI security token in their SOAP header, whereas AOC may not) FR34 Service consumers will be able to view integration contracts for available UR16 services. FR35 Service consumers will be able to receive notification on expiry of UR16 integration contracts. FR36 Criminal Justice Agencies will be able to register their interest in new UR7 services. FR37 Service developers will have a platform upon which new services can be UR10 developed FR38 Service developers will have a platform upon which new services can be UR10 tested FR39 Criminal Justice Agencies will be able to have consolidated services hosted by JINDEX support services Version 25 (Draft) Page 23
  27. 27. Washington JIN CACH Customer Requirements Report 8 NON-FUNCTIONAL REQUIREMENTS This section describes the Non-Functional Requirements (NFR##) captured during the stakeholder interviews and documentation review. While functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks or activities, non-functional requirements describe the overall qualities of the application as a whole. Qualities are properties or characteristics of the system that its stakeholders care about and hence will affect their degree of satisfaction with the system. Informally we can think of functional requirements capturing what the system must do, and the non-functional requirements as describing how well these functional requirements are satisfied—where “how well” is judged by some externally observable/measurable property of the system behavior, not its internal implementation. In other words, “how well” may be judged by the user in terms of some characteristic that the user values or is concerned about, such as: • Usability (ease-of-use, learnability, memorability, efficiency, etc.) • Configurability and supportability • Correctness, reliability, availability • Quality of service requirements such as performance (throughput, response time, transit delay, latency, etc.) • Safety properties (so-called because they “prevent bad things from happening”), such as security and fault tolerance • Operational scalability including support for additional users or sites, or higher transaction volumes NFRs ensure fitness of the system for purpose, apart from the specific functions that the system is capable of. That is, they constrain how the functions may be implemented and provide the criteria for evaluating each technical option. Subsequent to this deliverable is the Requirements Baseline document, which will express each NFR in a measurable (testable) form. However, this can be difficult due to the nature of NFRs and they are often evaluated subjectively. As options are considered throughout the project lifecycle, the evolving prioritized list of NFRs will be used to evaluate options, as part of the discussion and collaboration process and will be relied upon to justify the choice of one option over another, driving efficient and timely decision making. Several major design decisions will be made, based primarily on the weighted measurement of Non-Functional Requirements against each alterative. Included is the selection of Sonic ESB vs MS BizTalk. The following list has been captured from the IEEE/ANSI830-1993, IEEE Recommended Practice for Software Requirements Specifications and tailored to fit the JIN CHQ Project. A final, prioritized list of NFRs will be presented in the Requirements Baseline deliverable of the project. Here we have to be clear—not all services that JIN may provide need all of these characteristics; however it is important that if a service is to be used by multiple consumers, (as is typically the case when a SOA is required), the specification needs to be generalized, the service needs to be abstracted from the implementation, and developers of consumer applications shouldn't need to know about the underlying model and rules. The specification of obligations that client applications must meet needs to be formally defined and precise and the service must be offered at a relevant level of granularity that combines appropriate flexibility with ease of assembly into the business process. Version 25 (Draft) Page 24

×