March 7, 2005

1
ZIMS SUC Definition and Development Next Steps

• March 7, 2005

Presented to ZIMS Global Review Workshop
Participants
2
Agenda

• 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.

3
ZIMS Development Overview
We are here
4
Requirements
Types of Requirements

• 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.

• 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.

5
BUC SUC Comparison

• 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.

• 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.

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
Preparation for the System Use Cases

• Essential elements include
• Process Flow (Scenarios) 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

11
Preparation for the System Use Cases

• 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?

12
What are our expectations?

• 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

13
How can you use this information?

• 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.

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.