• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
JIN CACH Customer Requirements Report v26.doc
 

JIN CACH Customer Requirements Report v26.doc

on

  • 469 views

 

Statistics

Views

Total Views
469
Views on SlideShare
469
Embed Views
0

Actions

Likes
0
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    JIN CACH Customer Requirements Report v26.doc JIN CACH Customer Requirements Report v26.doc Document Transcript

    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Washington JIN CACH Customer Requirements Report Non-Functional Requirements - JINDEX # Non-Functional Project Applicability / Notes Requirement NFR1 Performance Stakeholder interview with Trever Esko from King County indicated JINDEX messaging some preliminary performance metrics. KC’s JILS application will likely framework should be able be one of the first consumers of JIN web services. JILS’ UI application to handle 15 transactions for criminal and case history must run within acceptable performance per second (average) guidelines. It should take no more than 5-8 seconds total response time for a JILS inquiry. KC expects that county users will eventually be conducting 1200-1400 inquiries/day, most of which should be during normal business hours (= ~ 2.5 requests per minute). Online anticipates a small client start to the project, with managed growth over time as service contracts with other agencies are established. KC represents a large proportion of Washington’s population base and hence a relative proportion among Law Enforcement Agencies and JIN service consumers. In the 2000 census, KC represented 29% of the state population. The percentage is projected to be 26% in 2030. (source http://www.wsdot.wa.gov/planning/wtp/datalibrary/population/countiespo pgrowth.htm) Planning for a 74% increase over JILS’ figures for CACH consumption seems prudent. Similarly, since CACH is expected to be just one of many web services in use across the JIN, a forty-fold increase in traffic as new services are brought online is advised. Each web service is assumed to follow an asynchronous request/reply paradigm (equally applicable to event-driven), putting 2 distinct messages through a messaging broker. JIN’s messaging backbone, therefore, should be able to handle at least 15 XML transactions per second. (1400 tx / 8 hours / 3600 seconds / 26% population * 40 new web services * 2 messages per request/reply) = 15 transactions per second This metric pertains strictly to the messaging framework and is irrespective of the endpoints applications. JINDEX cannot control the performance of applications such as ACCESS or AOC. The metric simply demonstrates the number of messages that the JINDEX should be able broker to the various endpoints. NFR2 Performance JINDEX could potentially broker more messages to an endpoint JINDEX should be able to application than the application could handle. In order to avoid throttle messages in overloading applications, JINDEX should be able to define throttling accordance with the metrics by endpoint (e.g. application X receives a maximum of 2 requests performance limitations per second, application Y receives a maximum of 3 requests per second, of endpoint applications etc.) Messages in excess of throttling maximums would be held in a queue and forwarded to the endpoints at the next available interval. Version 25 (Draft) Page 25
    • Washington JIN CACH Customer Requirements Report Non-Functional Requirements - JINDEX # Non-Functional Project Applicability / Notes Requirement NFR3 Usability Usability takes on a new meaning within the context of machine- Web services must be consumable web services. Simply put, there is no traditional user easily discoverable by interface in this domain. Usability is, however, still very much applicable potential service as a non-functional requirement for this and future web services-based consumers. JINDEX will projects. document both short and Usability in the JIN domain should be considered from the perspective of long term plans for business users (who are potential service consumers) and system statewide information integrators. devolution. Business users must be able to easily discover services available to them across the State. As service providers bring new services online, these services cannot remain hidden, to be discovered through happenstance and word of mouth. Rather, the implementation of a carefully and deliberately planned integration framework for the JIN must include both short and long term plans for information dissemination to potential service consumers. Eventually, UDDI may be the mechanism with which to address usability for business users. (The Universal Description, Discovery and Integration (UDDI) specifications define a registry service for Web services and for other electronic and non-electronic services. A UDDI registry service is a Web service that manages information about service providers, service implementations, and service metadata. Service providers can use UDDI to advertise the services they offer. Service consumers can use UDDI to discover services that suit their requirements and to obtain the service metadata needed to consume those services. Source - http://www.uddi.org/) In the short term, however, the cost of implementing UDDI services may not be offset by the benefit of large numbers of consumers able to dynamically discover web services. With this consideration, the non- functional requirement of easy discoverability may be accomplished through less elegant, although more pervasively available means, such as a JINDEX email newsletter, website publishing similar to grandcentral.com, etc. This will ultimately be decided by the JIN Board through the alternatives evaluation process. Feedback from King and Yakima counties, as the initial consumers of Criminal and Case History Web Services, will be key in validating whether ‘easy discoverability’ has been achieved, regardless of the delivery mechanism. Version 25 (Draft) Page 26
    • Washington JIN CACH Customer Requirements Report Non-Functional Requirements - JINDEX # Non-Functional Project Applicability / Notes Requirement NFR4 Usability Web Services Description Language (WSDL) is commonly used among Web services system integrators and is generally supported by commercial middleware must be self- products. If used properly, WSDL can speed the integration process and describing for can eliminate much of the paper documentation that has historically system accompanied the establishment of trading partner relationships. What integrators. WSDL provides is a machine-consumable template for endpoint JINDEX will integrators to use in tying their back-office systems and applications to a provide web service. WSDL can only achieve these goals, however, if certain documented guidelines are followed. For example, request and reply schemas must guidelines for include appropriate levels of embedded annotation to clearly define the the usage of semantics of each data element, and the business context of the messages WSDL. as a whole. URIs and ports for both production and test environments should be detailed, ideally within a single WSDL file (although separate files may be required). JINDEX will provide documented guidelines for systems integrators to follow in developing WSDL for future JINDEX services. NFR5 Operational In an integration framework involving multiple remote agencies accessing JINDEX should allow for multiple statewide services, self-support capabilities become essential. intuitive and service- DIS cannot be expected to field all support calls for JINDEX problems, based remote debugging unless additional resources are funded, which seems unlikely. Where a and support. message has become ‘lost’ or a service unresponsive, endpoint agencies must be able to access separate services to debug. This must be independent of the broker technology used to implement the framework. If the integration framework is implemented using either Biztalk or Sonic, remote agencies shall not be required to have the product installed in order to debug. A browser-based or a web-services based management console/querying capability should allow for users to query based on message type, date/time, and message originator/recipient (where the querying user must be either party to the transaction) NFR6 Operational/R Reliable messaging reduces support requirements, as it typically involves eliability/ elements such as automatic retries, configurable timeouts, and Maintainabilit configurable escalation and notification mechanisms (e.g. ‘notify support y via email if message could not be delivered after 5 attempts). Most JINDEX requires reliable middleware software technologies implement proprietary guaranteed or messaging. This should be reliable messaging mechanisms. In a topology such as JIN, where implemented based on an multiple remote agencies may be using multiple middleware open, standards-based technologies, the requirement to use a standards-based reliable messaging reliable messaging framework becomes evident. Unfortunately, standards such as WS- framework. Reliable Messaging are still emerging and have not yet received ratification. The design phase of this project will examine the pros and cons of implementing un-ratified standards. Version 25 (Draft) Page 27
    • Washington JIN CACH Customer Requirements Report Non-Functional Requirements - JINDEX # Non-Functional Project Applicability / Notes Requirement NFR7 Reliability Washington State’s justice community will, over time, come to rely on JINDEX should achieve the JINDEX framework as more integrated justice services come online. at least a 94% availability System uptime will therefore be crucial to the community. Users will level. expect JINDEX to be available, similar to the way in which a dial tone is expected when lifting a telephone receiver. As the state’s dial tone for integrated services, JINDEX should achieve a high level of availability. The 94% availability metric is based on 23 hours per day, 6 days per week, and 20 hours of availability on the 7th day (a scheduled weekly outage during off-peak hours, whether it is taken or not, will allow for regular system upgrades and deployment of new services). Depending on service level agreements achieved with the JINDEX hosting agency (likely DIS), greater levels of availability may be realized. System availability can easily be measured by examining server logs over a trial period of several weeks for any downtime. NFR8 Reliability In a latent, asynchronous messaging framework, recoverability from JINDEX should be fault system downtime is essential. Servers go down for a number of reasons, tolerant. Queued and the JINDEX must not lose messages as a result. messages should be recoverable across server bounces. NFR9 Operational/U When a new JIN service comes online, it may be immediately useful sability across the state. Many agencies, however, will not have achieved a state JINDEX should allow for of technological maturity requisite in order to consume the web service service consumption by programmatically. Building SOAP XML messages and being able to users with varying consume like responses is a goal that may be several years away for technological maturities. numerous justice agencies’ IT departments. Alternatives must exist for these consumers to take advantage of JIN services without the use of XML messaging and middleware. As part of the JINDEX Center of Excellence concept, guidelines and examples will be written for new service development that include, for example, recommended practices on alternative delivery mechanisms using pervasive technology (e.g. implementing a web-form interface to an XML web service). The Case and Criminal History Query web services will provide the initial template. Although these will both be SOAP/XML based services, a UI will be implemented for demonstration not only of the end functionality, but also how service providers should plan implementations to encourage more widespread uptake by all service consumers. Version 25 (Draft) Page 28
    • Washington JIN CACH Customer Requirements Report Non-Functional Requirements - JINDEX # Non-Functional Project Applicability / Notes Requirement NFR10 Operational/Sa A myriad of authentication and authorization paradigms are implemented fety across the state. Network-level security, single-point authentication JINDEX should gateways, and application security all have legitimate origins and will implement an open, continue to co-exist as long as different agencies are mandated with standards-based different security requirements (i.e. forever). Fundamental to a service- framework for based architecture is enabling efficient authentication and authorization in authentication and this type of varied topology. ‘Efficient’, in this context, generally means authorization. not having to login with the same credentials multiple times in order to gain access to the desired services. Emerging standards such as WS-Security are trying to address these issues. Credentials are tokenized in a standard form and passed within SOAP headers such that gateways, endpoints and applications can re-use credentials. As with WS-Reliable Messaging, lack of ratification remains an issue. Options will be examined in detail during the project design phase. As an example, JINDEX may provide a single service to interface with existing state security gateways such as Fortress and Transact Washington. JINDEX security services could build the SOAP WSS header based on information received from the gateway. The WSS header, including security tokens such as username, ORI, etc. would be passed to endpoint applications such as ACCESS. These would then determine if the ‘upstream’ authentication and authorization mechanisms were sufficient. If not, the endpoint applications could choose to re- validate credentials. NFR11 Resource/Acce Systems integrators, end users, and maintenance personnel will have a ptance/ steep learning curve with the many new technologies used in the JIN Documentatio framework. As part of the Center of Excellence concept, Online Business n Systems will provide documentation and examples for developers to Consolidated, concise develop their own web services for future integrated justice projects. JINDEX framework Artifacts should include appropriate primer documentation on standards documentation will be (e.g. SOAP, WSS (if used), WS Reliable Messaging (if used)), guidelines published as a project (e.g. how to write your WSDL), technologies used in implementation artifact (asynchronous messaging, Sonic/Biztalk), and samples/examples. Artifacts will be non-proprietary, free from IP encumbrances, and will be available for use by Washington State constituents on future projects. This approach, combined with a concerted internal marketing effort, offers the best chance at success for end-user (statewide) acceptance of JINDEX. By making the technology open, well documented, and accessible to all, uptake of JINDEX and development of additional integrated justice services should be the result. Version 25 (Draft) Page 29
    • Washington JIN CACH Customer Requirements Report Non-Functional Requirements - JINDEX # Non-Functional Project Applicability / Notes Requirement NFR12 Portability By nature of implementing JINDEX using open web services standards, Integration technology solutions will be inherently portable and interoperable with any other selected for systems that support these standards (all significant middleware vendors implementation of the and most application servers now support web services). Sonic and JINDEX should allow for Biztalk are the two technology platforms to be evaluated by the state. One endpoint integration of the evaluation criteria will be how well these products can without the use of remote architecturally support remote endpoint integration without the agents, or by using a deployment of an agent. Occasionally, however, adapters will need to be different integration developed in order to interface with endpoint applications. This NFR technology would give preference to the technology that could be easily deployed and hosted on existing, low-cost, or open-source infrastructure. In other words, can Biztalk adapters be hosted on Windows servers independently from Biztalk? Can Sonic adapters be hosted on Java application servers independently from Sonic? NFR13 Portability WS-I promotes interoperability across platforms, operating systems, and CACH services should be programming languages. Following WS-I profiles ensures, for example, compatible with the that a Biztalk Web Service can communicate with a Sonic Web Service. appropriate WS- Interoperability (WS-I) profile NFR14 Performance (1400 TX / 8 hours / 3600 seconds / 26% population * 2 messages per CACH should be able to request/reply) = 0.4 transactions per second handle 0.4 transactions per second NFR15 Usability WSDL provides the usability aspect for service developers. It presents an CACH services must have easily understandable view of the functionality expectations, connection published WSDL that is details and message formats. consumable by King and Yakima counties NFR16 Resource Future integrated justice projects are likely to be implemented by a JINDEX Center of mixture of IT resources internal to Criminal Justice Agencies, as well as Excellence shall publish external vendors. Guidelines for recommended skillsets will assist in recommended skillsets for resource planning, internal training initiatives, and vendor solicitation. systems developers, architects, and maintenance personnel. Additionally, the aforementioned guidelines and examples for web service development should be usable as training guides for skilled developers with little previous exposure to web services. Version 25 (Draft) Page 30
    • Washington JIN CACH Customer Requirements Report Non-Functional Requirements - JINDEX # Non-Functional Project Applicability / Notes Requirement NFR17 Reusable A fundamental tenet of SOA, and indeed services in general, is the intent All JINDEX core services to reuse functionality. Reuse has traditionally been problematic, and CACH services shall especially in heterogeneous communities (such as the multitude of be developed using a Criminal Justice Practitioners and Agencies across an entire state). Web Service Oriented Services and SOA, however, provide both the framework and the Architecture (SOA) technical means to finally make reuse both feasible and practical. Remote methodology. SOA agencies can dynamically discover a service someone else is offering methodology guidelines through UDDI. They can develop interfaces to this service with minimal shall be documented and interaction and effort through the self-describing, machine-consumable published in for the WSDL. The technologies use standards supported by all major vendors, Center of Excellence. thus the traditional separation of developer communities into ‘camps’ is eliminated. A number of principles must still be followed, however, and these will form a significant part of the Center of Excellence artifacts in the implementation phase of this project. NFR18 Safety/Reliabil The nature of criminal justice dictates that some tasks must be given more ity urgency than others. The officer in the field requires data in a more JINDEX will provide timely fashion than a typical office clerical inquiry. It stands to reason, guidelines for the future therefore, that JINDEX should be able to delineate separate message provisioning of Quality of precedences and accordingly prioritize delivery. While QOS provisioning Service (QOS) levels is out of scope for implementation of CACH services, Online Business within the messaging Systems will research any emerging standards in this domain and will framework. include recommendations/guidelines for the Center of Excellence on how QOS might be achieved in the future. Version 25 (Draft) Page 31
    • Washington JIN CACH Customer Requirements Report Non-Functional Requirements - JINDEX # Non-Functional Project Applicability / Notes Requirement NFR19 Safety Criminal Justice information is, by nature, sensitive and must be JINDEX will maintain protected. Numerous manual and automated access controls, logging, and data integrity and audit procedures are already in place across Washington State. The confidentiality. JINDEX implementation of JINDEX must not compromise any of these principals, will provide mechanisms rather it should enhance and facilitate more efficient security processes. which could facilitate XML messages transmitted in plain text over a network could be logging and audit. ‘snooped’, thereby compromising confidentiality and injecting threats to integrity. All JINDEX services, therefore, should be implemented using HTTPS. Agencies will continue to retain ownership of the information in their custody, and hence will manage authorization rights and protecting misuse of information. JINDEX will facilitate authentication and authorization, as previously described in this section. The statement “JINDEX will provide mechanisms which could facilitate logging and audit” is deliberately left somewhat open. The JINDEX framework will definitely allow for full logging of who messages were sent from and to, the types of messages, the dates and times sent, and the contents of messages. This type of detailed logging allows for detailed and even automated auditing, but it also confers immense memory requirements. Even with a modest 5 KB XML message, the performance planning metrics outlined in NFR1 above would mean the monthly accumulation of more than 64 Gigabytes of log data. (1400 tx / 26% population * 40 new web services * 2 messages per request/reply * 30 days * 5000 bytes) Omitting the message payload from the logs can reduce this metric by an order of magnitude, but the memory requirements are still significant. It is therefore recommended that JINDEX logs follow a paradigm such as a 6 month ‘sliding window’, such that log entries older than 6 months are continually archived. JINDEX logs would primarily be for debugging purposes, with limited time-bound auditability. These parameters will be configurable by the JINDEX hosting agency (e.g. DIS) and the option to log more or less, and for what time period will need to be negotiated among stakeholders. Version 25 (Draft) Page 32
    • Washington JIN CACH Customer Requirements Report 9 TECHNICAL REQUIREMENTS Prior to the precise definition of technical or architectural requirements, the bulk of customer related requirements must be examined, discussed and ratified. The Requirements Baseline deliverable will examine the specific architectural requirements, identifying the needs for: Data Model - Present a high-level data model which captures the business process view of the data and data relationships. Data Integrity - Identify requirements for maintaining data correctness: fixes, tolerances, redundancies, built-in checks. Data Characteristics - Describe data types, volumes, volatility, unusual access requirements Data Distribution - Identify location and geography requirements, along with replication, translation, READ- ONLY requirements associated with the distribution. Data Synchronization - Describe time-value, latency tolerance replication demands of all data synchronizations. Critical Dependencies and Interfaces - Identify dependencies in terms of timing and information flow as well as critical interfaces to legacy systems. Application Deployment Requirements - Identify the chronological order of deployment as well as the location of each deployment and its platform needs. Application Performance Requirements - Identify required throughputs, response times, and transaction volumes for peak and non-peak periods. Expected Service Levels - Detail the "up time" requirements for each application: global availability versus local availability; reliability and maintainability needs. Application Development Environment - Identify methodologies and tools to be used in the application development. Infrastructure Deployment - Define geographic constraints on the technology: location, stability, accessibility, performance for hardware, software, and network components. Expected Service Levels - Detail the "up time" requirements for all portions of the infrastructure incorporating mean time between failure (MTBF) constraints. Support Roles - Describe new roles and responsibilities needed in the support organizations and in the consumer organizations. Include training requirements. Support Coverage - Identify staffing levels and coverage schemes needed to support each major function including skill sets required. Expected Service Levels - Determine expected problem resolution time frames and identify acceptable time frames for each major architecture component. Once the Technical Requirements are identified, they will be mapped back to each Customer Requirement (Business Requirements, User Requirements, Functional Requirements, Non-functional Requirements, Critical Success Factors, Constraints, and Risks). Traceability mapping identified technical requirements that do not map back to business requirements (requirement creep or vision, depending on your point of view) and business requirements, CSFs, risks, or constraints that are not reflected in technical requirements. Version 25 (Draft) Page 33
    • Washington JIN CACH Customer Requirements Report APPENDIX A – REQUIREMENTS ASSESSMENT INTERVIEWS This section provides the key observations from each of the stakeholder interviews. Stakeholder interviews were conducted and interview notes captured and reviewed by each stakeholder individually prior to drawing conclusions / requirements from the content. This process has proven beneficial to the project in establishing a collaborative environment in which to ratify user requirements amongst the diverse stakeholder group. In addition, questions and clarification from the background documentation review were explored during the interviews, leading to additional material to review and identifying areas that would require further analysis and follow-up. The complete interview notes are not provided here, instead, key observations are summarized in order to provide context for the actual customer requirements, captured thought this document. # Key Observations 1 Web Services standards adoption! 2 Not a User Interface, but an application-to-application environment using web services to connect state systems and regional systems. 3 Conform to agency audit and logging requirements. Individual user access and reasons for access must be logged depending on particular Service Contract is established. 4 DIS would be a logical agency to host the shared CACH application. 5 Both individual services and consolidated services are required, allowing each Agency to choose to consume whichever service best fits within their existing or planned applications. 6 QOS and Priority options should be available for JIN offered services. While this is outside the scope of the JIN Project, consideration must be given to establishing a priority of service fulfillment based on role. 7 Counties will play a key role in the building of test cases and the acceptance testing of the application. 8 Build the application with extensibility in mind. 9 What is developed is the physical manifestation of the design principals and not just another point- to-point solution. 10 Separate the Framework from the Query Services, ensuring adequate effort is spent on other facets of the project. Do not assume the framework will be a legacy of a pure Query Service implementation effort. Version 25 (Draft) Page 34
    • Washington JIN CACH Customer Requirements Report APPENDIX B – DOCUMENTATION REVIEW This section presents a summary of the DIS, AOC, WSP, King County, Yakima County and JIN background documentation that was reviewed in support of the assessment of the current operational environment, as well as the legal and procedural requirements for information sharing and in the preparation of the customer requirements details. The following artifacts were reviewed during the requirements assessment phase and in the preparation of this deliverable. # Artifact Notes 1 Summary Offender Two user guide type reference documents, as well as the operator's guide. Profile Design Document 2 Equarius POC Final Not the results or lessons learned – contains more of a presentation of the POC report solution. 3 SOP Review County review of the pilot rollout of SOP 4 POC Evaluation University of Washington SOP Evaluation documentation – graduate students 5 King County Law, Strategic Information Plan and Technical Architecture Safety and Justice Integration planning documents 6 SOP Data Element by List of the data elements by source. Less useful without the mapping logic in Source System the source code. 7 SOP Phase II SOW from Templar for spending the additional 50K in services on something Requirements that adds value to CACH and SOP Phase 2 8 AOC Security Email thread from AOC that discusses security, including Discussions INFRASTRUCTURE DEPARTMENT POLICY 7.14.1: Cryptographic Key Management 9 WSP Security Document available on the web. access.wsp.wa.gov Discussions 10 WSP ACCESS Manual Contains security procedures, user guides and specs for command access (Query/response) to the WSP ACCESS switch. 11 JIN Proof of Concept Evaluation criteria for JIN Technical POC 12 JIN Feasibility Study March 1997 by ECG Consultants 13 JIN Strategic Plan Reviewed. 14 JIN Technical Contains DESIGN DECISIONS that should be validated. Can serve as a good Architecture Report starting point for interview discussions. dated June 2002 15 2002 Implementation Reviewed. Recommendations 16 JIN Common Referenced by the answers to RFP respondent questions during RFP process. Architecture Data Created by JIEM tool I believe. Process flows and data standards. Must Dictionary confirm the usability of this material. 17 DIS IT portfolios Reviewed. Version 25 (Draft) Page 35
    • Washington JIN CACH Customer Requirements Report # Artifact Notes 18 AOC IT portfolios JIS Migration Plan is the state of IT at AOC as of 2001 and the second document is a current picture ‘working’ document. Understanding both permits a balanced view on priority shifts, plan deviances, etc. Contains courts consensus building for their projects and how this is accomplished. 19 WSP IT portfolios http://sww.wa.gov/dis/mostd/WSPportfolio/default.htm 20 Yakima County Not yet received. Technical Services Law & Justice System Integration planning documents 21 SOP source code Proprietary connection/query logic for WSP/AOC adapters. 22 JIN Board meeting Reviewed. minutes 23 DIS Security Policies Reviewed during DIS Design Review. 24 JIN Common Referenced by the answers to RFP respondent questions during RFP process Architecture Data Dictionary 25 DIS Design Review Obtained during DIS collaboration. Network Diagram and DIS review Materials checklist. Version 25 (Draft) Page 36
    • Washington JIN CACH Customer Requirements Report APPENDIX C – LEGAL AND PROCEDURAL REQUIREMENTS ASSESSMENT Review of Policies, Authorizing Legislation JIN Authorizing Legislation Chapter 10.98 of the Revised Code of Washington (RCW) defines the requirements for collecting and transmitting criminal justice information for the purpose of reporting criminal histories. A key component of this section – the Criminal Justice Information Act – was the creation of the Washington Integrated Justice Information Board in 2003. The authorizing language defines the goal of the Board is to “develop and maintain, in a cost-effective manner, a statewide network of criminal justice information that enables sharing and integrated delivery of justice information maintained in the state's independent information systems.”1 Specifically, the statute requires the promotion of standards for justice-related information systems and information sharing to reduce redundant data entry and promote timely access of information while at the same time adhering to State law governing information security and citizen privacy rights2. The Board is a stand-alone body (it is not housed under another agency or the Office of the Governor) and is governed by its authorizing legislation and the by-laws it has created. Chapter §10.98 prescribes the composition of the Board as well as its authority to meet and appoint new members. The Integrated Justice Information Board has many responsibilities with regard to the implementation of justice information sharing, including: coordinating and facilitating the governance, implementation, operation, maintenance, and enhancement of sharing and integrated delivery of complete, accurate, and timely justice information; encouraging the creation of interfaces between justice agencies; establishing and implementing uniform data standards and protocols; and adopting strategic and tactical plans for to implement, maintain and enhance integrated justice efforts statewide. The statute clearly states that the responsibilities of the Board will in no way supercede those of the Department of Information Systems (DIS) or the authority of the involved court, state, or local agencies to maintain control over their own data. 3 Regarding funding for justice information sharing, the Integrated Justice Information Board has responsibility to provide the Office of Financial Management with budgetary and policy review of state agency plans affecting the justice information network. They also have the authority to pursue, develop, and coordinate grants and other funding opportunities for state and local justice information projects that will expand or enhance the sharing and integrated delivery of statewide justice information and to recommend to the governor, the supreme court, and the legislature those legislative changes and appropriations needed to implement, maintain, and enhance a statewide justice information network and to assure the availability of complete, accurate, and timely justice information. However, there is no authorized appropriation included in § RCW 10.98 for Board activities or justice integration projects. The Justice Information Network (JIN) program office is charged with implementing the vision and priorities set forth by the Integrated Justice Information Board. According to its Strategic Plan, JIN was created in 2003, around the time of the Board’s creation. Five of the Board’s largest participating agencies – the Administrative Office of the Courts, the Department of Information Systems, the Department of Corrections, the Washington State Police, and the Department of Law – agreed to fund the creation of the JIN program office at DIS to support the Integrated Justice Information Board’s governance structure4. Privacy and Security Policy in Washington In 2000, Governor Gary Locke created Executive Order 00-03, which outlines state policy with regard to personal information about individuals that is collected and maintained by public sector agencies. The Executive Order 1 § RCW 10.98.200 2 § RCW 10.98.210 3 § RCW 10.98.220 4 Justice Information Network Strategic Plan 2005-2007, Executive Summary, page 1. Version 25 (Draft) Page 37
    • Washington JIN CACH Customer Requirements Report calls for state agencies to minimize the collection, retention, and release of personal information by the state. It also prohibits the unauthorized sale of citizens’ personal information by state government and provides citizens with the opportunity to know what personal information about them the state holds, and to review and correct that information. 5 Also in 2000, the DIS promulgated its Information Security Policy, which promotes an enterprise-wide view of information security, and encourages agencies that use information systems to support critical State business functions develop, implement, maintain, and test security processes, procedures, and practices to protect and safeguard voice, video, and computer data computing and telecommunications facilities -- including telephones, hardware, software, and personnel -- against security breaches. 6 The security policy provides general guidelines but leaves the implementation of these guidelines to the individual agencies. SWOT Analysis In many respects, the legislation and policies around integrated justice in Washington are proactive and provide strategic vision to justice agencies looking to implement interfaces to support justice information sharing. This vision – set by the Integrated Justice Information Board – has been translated to tangible, tactical goals and objectives by the JIN program office. These goals are supported by the DIS vision and infrastructure, which have helped provide guidance on such matters as security, privacy, and compliance with the statewide architecture and accepted technology and information sharing standards. As the State of Washington moves from planning for integrated justice to actual implementation, there may be other issues that need to be addressed through statute, administrative procedure, or a memorandum of understanding among the Integrated Justice Information Board’s members. At the highest level, these issues concern funding/staffing, state/local issues, and maintenance/support-related issues. Each one of these will be addressed in turn below. Funding/Staffing While the legislative language authorizing the Integrated Justice Information Board allows it to seek grants and other funding requests to support justice information sharing, it does not authorize a specific funding level to support the justice information sharing project or the program management function of JIN, which is currently housed at DIS. Currently, JIN is a one-person shop, with hopes of bringing on a few more staff members to help support the Board’s vision. However, since these individuals are DIS employees (whose positions are contributed to from other Board agencies), there needs to be some manner in which the Integrated Justice Information somehow exercises its role as the real authority over JIN while DIS is simply a place to administratively house the program. To sustain an integrated justice effort, it is clear that funding for program management as well as system maintenance issues (see below) must be included as a component of the effort. State/Local Issues The legislative language authorizing the Integrated Justice Information Board only addresses interaction between state and local agencies in a few spots; namely, with the appointment of a county clerk, a county council member, a local police representative, a sheriff, a prosecutor, and a local-level appointee named by the Association of Washington Cities. Garnering local level involvement in justice information sharing is incredibly difficult, given the number of disparate systems used among local law enforcement agencies alone. However, improving information sharing at the local level is key to ensuring quality data for state-level information sharing. Currently, addressing local level integration projects in a proactive manner seems outside of the scope of the JIN initiative and the overall priorities. The role of local agencies in JIN and state-level integration will likely need to be addressed at some point. Implementation/Operation Maintenance/Support In several places in the Integrated Justice Information Board’s authorizing language, issues around system maintenance and support are addressed. For example, in § RCW 10.98.230 (c), the statute requires the Board to 5 Executive Order 00-03: Public Records Privacy Protections, State of Washington, April 2000. 6 Information Technology Security Policy, Washington State Department of Information Services, page 5. Version 25 (Draft) Page 38
    • Washington JIN CACH Customer Requirements Report “coordinate and facilitate the governance, implementation, operation, maintenance, and enhancement of sharing and integrated delivery of complete, accurate, and timely justice information.” While the Board’s vision, documented in the JIN strategic plan, outlines broad goals and objectives as well as the governance for statewide justice information sharing, it is unclear at this point how JIN and the Board’s partner agencies will manage implementation, operation, and maintenance-related issues. A question exists as to the exact role JIN will play in the implementation and operation of an integrated system. A well defined JIN architecture that the state and local agencies will be encouraged to follow is apparently a mandate. What has not yet been defined is what role JIN will play in implementing and operating the architecture. Very specific user requirements are emerging, such as guaranteed receipt and recover, which imply a strong central operation. Other requirements seem suggest a loosely coupled, non-intrusive architecture relying on open standards and understood services which each agency may expose and consume. Will JIN enforce and guarantee the requirements, build the architecture up to the door of local servers, assist beyond the door to the adapter level, or will JIN simply address architecture and policy issues. The options are not exclusive but the role will dictate governance and funding issues in the future. For JIN to guarantee that user requirements are met greatly increases the resource requirements for JIN as well as the ability to manage policy set by the Board. An example of the need for further clarity around system maintenance and support is around adherence to State- level information security policies. The DIS security policy requires that agencies using information technology undertake several specific tasks, such as establishing its secure state business applications within the Washington State Digital Government framework, which requires that all parties interact with agencies through a common security architecture and authentication process. The policy also requires staff training on information security policies. At this point, it is unclear how the Board will implement such policies: currently, JIN is too small an office to coordinate that effort on behalf of participating agencies. These maintenance, implementation, and support issues may be easily addressed in the current Board/JIN Program Office infrastructure by clarifying these responsibilities, identifying means to support them (through JIN or Board participating agencies) and formally establishing them through memoranda of understanding or other officially recognized documented agreements. Version 25 (Draft) Page 39
    • Washington JIN CACH Customer Requirements Report In summary, the following SWOT (strengths/weaknesses/opportunities/threats) analysis describes the strengths and some potential weaknesses of the legal and procedural environment for justice information sharing in Washington State: Strengths Weaknesses *Clear governance structure and role *No funding authorization for program office or definition for state-level justice information justice integration projects in existing statute sharing. *Lack of clarity about roles and responsibilities for *Well-document and accepted strategic maintenance and support issues vision and plan for statewide information sharing Opportunities Threats *Early success of JIN could encourage *Reliance for funding based on soliciting outside continued support from key agencies to grants and individual appropriations. As such, fund/expand the JIN Program Office future funding is subject to shifting conditions and priorities. *Pilot projects could help build support among other key stakeholders for justice *Unclear how local agencies will participate in information sharing, which could bring more justice information sharing efforts. support for staff, funding projects, etc. JIN Program Office Recommendations In summary, we have the following recommendations regarding the role of the JIN Program Office: • Define the user requirements JIN intends to satisfy beyond architecture; • Begin planning for information system support and maintenance and formalize those roles, responsibilities, and how they will be supported financially; • Utilize the Board in an active way politically to measure JIN’s ability to meet the user community’s expectations if they go beyond architecture standards and message routing. • Formalize (whether through a memorandum of understanding or legislative change) the JIN Program Office and adequate funding for its support and operations; • Begin planning for how to work with local justice agencies to support integrated justice systems. Version 25 (Draft) Page 40
    • Washington JIN CACH Customer Requirements Report APPENDIX D – ISSUES The following items have been compiled during stakeholder interview and in the preparation and identification of the Customer requirements. These items will help set the agenda for the TAG (Technical Advisory Group) meetings in January and have been listed here to serve as a starting point for topics of discussion. Discussion of these issues may result in the establishment of new assumptions and constraints, requirements or open issues. There is no particular ordering to these issues, which have been roughly grouped by functional areas. Issues that are left blank represent issues that are still being explored and that might yet impact the requirements. This impact will be reflected in the Requirements Baseline deliverable – which establishes the baseline for the design alternatives selection and solution design. # Issue I01 Guaranteed Delivery. What is the specific Customer Requirement driving the need for a Technical Requirement covering guaranteed delivery of messages? Guaranteed transactional (part of process orchestration) messaging solutions will likely require Agencies to host transaction software (adapter) for the servers at their location, forming a tightly-coupled, fault tolerant communication protocols which are in general proprietary to the integration software. This requirement could be negated if JIN was limited to hosting SOAP query only transactions. This would limit the patterns necessary to be supported in the ‘Center of Excellence’ as well. I02 SOP Version 1 tight coupling. There is an impression that SOP exposed the AOC database structures and this contributes to the view that SOP was proprietary and was based on a tightly coupled protocol. This is perceived to contribute to a high fragility and unsustainable cost of ownership. Minor database changes must be insulated from affecting all those that rely on this information. The initial assumption for the adapter to AOC was SQL/ODBC, however, screen scraping is being advised. Screen scraping is the least effective means of integrating application for numerous reasons. The ‘exposure’ issue must be resolved or the adapter will involve a screen scraping Technology requirement. You can solve this by facading each partner's database(s) with web services. However, even for read- only applications (and definitely for transactional applications), it is dangerous to bypass the business logic encoded in applications. E-Trip is considering utilizing this form of integration adapter since their requirements call for process orchestration with services brokering application logic as opposed to the initial scope of JIN CHQ project as a Request/Reply message pattern. I03 Multiple application/data stores within the AOC Repository. Initial assumption for this query/response type web services was to access a single repository via SQL/ODBC/JDBC. Multiple distinct applications have been discussed during the interviews: SCOMIS, DISCIS and JIS. Version 25 (Draft) Page 41
    • Washington JIN CACH Customer Requirements Report # Issue I04 Hybrid Security Model. King County chose the Standard certs, through Transact Washington for user access to JILS. It was decided that this provided adequate authentication for law enforcement. They recommend the "Standard Roaming" since that does not tie the user to a specific PC and doesn't have a software footprint on the machine, making it easier to communicate as a requirement to multiple agencies. Costs run around $10.00 per year. I05 Leveraging SOP. 1Dec received first set of sample source code artifacts from templar, being used to access suitability before purchase. Expectation from the beginning of this project was that the Query Agents contain the mapping logic to satisfy the functional requirements. I06 Base solution on Justice XML. Intermediate business format will present web services as easily consumable by other agency applications. Methods of leveraging Justice XML must permit explicit sub-schema creation without reference to the Master namespace. This centralized reference model does not fit the deployment in a location transparent deployment model whereas parsing and validation will require excessive network traffic unless the schema makes explicit definition of elements as opposed to referencing a central XML namespace. I07 UDDI Automated Registry functionality vs. Manual. While web services, SOAP and WSDL have achieved a great deal of global traction, UDDI is somewhat of a late comer. Case studies, vendor implementations, and documentation are available, but somewhat limited. As such, UDDI usage patterns may change significantly in the coming years. A great deal of effort can be spent on implementing UDDI for this project, to the benefit of only the more technologically advanced stakeholders in the state. The recommended approach may be to pilot UDDI with King and Yakima counties, but not to invest cycles in development of statewide enterprise level UDDI hosting and support. I08 Emerging WS-xx standards. Several project requirements mention the use of standards to accomplish specific business tasks, predominantly to ensure interoperability between heterogeneous systems. Unfortunately, within several domains such as reliability, security, and orchestration, standards are still in developmental phases and have yet to be ratified. Implementing a solution based on un-ratified standards injects a risk that there is a delta between the state of the standards at the point in time when the project goes live, and the standards’ ‘final’ state. It is generally felt, however, that this is the lesser of evils, when the alternatives include implementing vendor-specific or even project-specific mechanisms for achieving the business objectives. I09 Design or Enhancement to agency applications that need to be compatible with JIN. All parties have an inherent assumption that existing applications will not need to be enhanced or re- engineered in order to be integrated. Placing a web-services façade in front of existing applications essentially hides their specific implementations and insulates them from the need to change. An adapter will need to be created for each application, whether this adapter uses existing APIs, method calls, SQL commands, etc. Adapter development, however, occasionally confers remote agent hosting requirements. If, for example, a Biztalk adapter making SQL calls into the AOC repository were developed, this adapter would need to be hosted somewhere. The specific architectures of Biztalk and Sonic for adapter development, and their potential to be hosted on low-cost, lightweight, and/or open source platforms, is discussed in NFR 12. I10 Third Party Database. Includes security schema. I11 Fully Functional Solution. Not a requirement. Version 25 (Draft) Page 42
    • Washington JIN CACH Customer Requirements Report # Issue I12 Support Open Protocols. Both integration technologies being considered for JINDEX, Sonic and Biztalk, include support for SOAP, XML, and HTTPS. Support for emerging protocols, such as WSS, WS-Reliable Messaging will not be beyond beta implementation. I13 Message Queue. I14 User Interface. Multiple interfaces already. I15 Development Environment. I16 Development Tools. I17 Off the Shelf Adapters. Both integration technologies being considered for JINDEX, Sonic and Biztalk, have available off the shelf adapters for major technologies, ERPs, and databases. I18 Transformation Capabilities. Both integration technologies being considered for JINDEX, Sonic and Biztalk, include inherent transformation capabilities. I19 Leveraging LESA Functionality A relatively late development in the requirements gathering phase indicates a great deal of potential to leverage code developed by LESA that interfaces with ACCESS. Similar to SOP, advantages of leveraging an existing codeset include decreased project risk and fewer overall interfaces into ACCESS (and hence components to maintain and support). Even more beneficial to the state than leveraging SOP, LESA’s code is not proprietary to a vendor. Unfortunately, the LESA avenue was not discovered until early December 2004, and hence requires further time for detailed analysis. Version 25 (Draft) Page 43