march 7 2005 n.
Skip this Video
Loading SlideShow in 5 Seconds..
March 7, 2005 PowerPoint Presentation
Download Presentation
March 7, 2005

Loading in 2 Seconds...

play fullscreen
1 / 14

March 7, 2005 - PowerPoint PPT Presentation

  • Uploaded on

ZIMS – SUC Definition and Development: Next Steps. March 7, 2005. Presented to: ZIMS Global Review Workshop Participants. 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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'March 7, 2005' - tamra

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
march 7 2005

ZIMS – SUC Definition and Development: Next Steps

March 7, 2005

Presented to:

ZIMS Global Review Workshop Participants

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


Types of Requirements

buc suc comparison
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
key elements of the system use case
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
key elements of the system use case continued
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.
key elements of the system use case continued1
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.
key elements of the system use case continued2
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.
preparation for the system use cases
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)


Preparation for the System Use Cases
preparation for the system use cases1
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
what are our expectations
Review comments will include:


New rule required

Rule not required

Rule should be changed


Step is mandatory

Step should be optional

New Step required

Step is unnecessary

Step should be changed


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


Additional Data Rule, Changed Data Rule

New Field Required

Data Type or Data Length change


Additional/Different action required on the page

Additional/Different action rule required

What are our expectations?
how can you use this information
Every Major Entity will have a detail page and a list page.






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?
non functional requirements
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.