March 7, 2005

1. ZIMS – SUC Definition and Development: Next Steps March 7, 2005 Presented to: ZIMS Global Review Workshop Participants

2. What can we each do to move the project forward, be successful in the next stage and ensure we deliver the ZIMS application we want and require. Agenda

3. ZIMS Development Overview We are here

4. Functional Requirements: Describe the functionality of ZIMS. Define the scope, boundaries and interfaces to related systems. Define the business rules that ZIMS must conform to. Non-Functional Requirements: Describe the look and feel of the system. Describe what ZIMS must do to allow for actor interaction with the system. Define system usability, and the performance requirements. Describe the intended operating environment, maintainability, portability. Defines ZIMS system security. Describes cultural, political, legal and compliance requirements that ZIMS must conform to. Requirements Types of Requirements

5. Business Use Cases: Describes the interaction between the people, departments and organizations within the ZIMS user community. There is no mention of technology since these use cases are focused on business operations. The focus of the business use cases is to highlight how the organizations that are part of the ZIMS user community interact – currently and in future. System Use Cases: Describes the interaction between an “Actor” and a “System” (ZIMS). It provides the details of the “Actors” achieving goals within a “System” (ZIMS). System use cases are technology focused. BUC – SUC Comparison

6. Key Elements of the System Use Case • SUC tile & reference • Introduction • SUC description • BUC cross-references - Used for Traceability Analysis. • Links • SUC Attachments (example: Prototype pages, test scripts, reference documents related to SUC) • Actors • Data Elements • Common business name • Definition • Field Name: Technical database name • Field length • Data type (example: text, numeric, date, alphanumeric etc.) • Reference: How it will be used in the system. • Data Standard reference

7. Key Elements of the System Use Case (continued) • Goals and Scope • Goal: the objective that will be achieved by the SUC • Scope: the boundaries of what is included and not included in the SUC • Scenarios • Each SUC is made up of scenarios • A scenario can be defined as a sequence of interactions between the system and the actor (user) that apply to a particular system use case • Every different sequence represents a different scenario in the use case • Exception flows are a type of scenario. • Each scenario produces a flow diagram.

8. Key Elements of the System Use Case (continued) • Within each Scenario, the following are defined: • Name and description of scenario • Triggers • Preconditions • Priority • Steps including: • Actor • Step (short description) • Description • Branches • Mandatory vs. Optional vs. System-generated Data Elements • Validation Rules. • Each scenario has a notes section in which issues related to the Scenario can be recorded. • Non-functional requirements associated with each Scenario are also recorded.

9. Key Elements of the System Use Case (continued) • Security Requirements • Different requirement for each type of security (example: View and Update permissions) • Any comments or questions related to Security are recorded as a SUC note.

10. Essential elements include: Process Flow (Scenario’s) that includes the System, a rational set of roles (Actors). Page Designs Menu and Navigation Lists and Selection Criteria Links to other pages and information Data fields data types, field lengths, validation rules, Create (Allowed/Mandatory) Read (Allowed) Update (Allowed/Mandatory) Delete (Allowed) Actions (and rules) Exceptions Preparation for the System Use Cases

11. What can you do ahead of time? Many of the System Use Cases will include a number of standard views: List View Details View Transaction View For every list What are the top 15 data fields that might be used to select an item from a list within this context For every page What data will you want on the page When is the data allowed/mandatory to be created, read, updated, deleted. May have a “Privacy” view For all data What are the rules for determining that the data is valid? When you see the page, ensure you have enough space for the data entry How should it be presented? How should it be grouped? For every action What are all the activities that occur? Preparation for the System Use Cases

12. Review comments will include: Rules New rule required Rule not required Rule should be changed Process Step is mandatory Step should be optional New Step required Step is unnecessary Step should be changed Pages New page required Split page into two pages Additional fields required, field not required Data should be presented or organized differently This page should be reachable from another page Data Additional Data Rule, Changed Data Rule New Field Required Data Type or Data Length change Actions Additional/Different action required on the page Additional/Different action rule required What are our expectations?

13. Every Major Entity will have a detail page and a list page. Drugs/Pharmaceuticals Animals Enclosures Systems Collections … Start with the list page What are the main fields you need to select an item from the list? Looking at a details page What data is the absolute minimum that you need on the page? What additional data would be useful or valuable? Remember – It will be possible to make more data mandatory on a page, the opposite is not true. How can you use this information?

14. Non – Functional Requirements • Non-functional requirements that apply across the entire ZIMS application are documented in the Design Goals and Constraints section of the Software Architecture document. • Ex: The User Interface of ZIMS should support multiple languages. • Those that apply to specific system use cases will be documented in the system use cases. • Ex: In the View Diagnostic Images system use case there may be a non-functional requirement to facilitate the ability for a user to download the image to the users workstation, or a requirement to display the image in a separate browser window.