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.
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.
March 7, 2005
ZIMS Global Review Workshop Participants
We are here
Describe the functionality of ZIMS.
Define the scope, boundaries and interfaces to related systems.
Define the business rules that ZIMS must conform to.
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
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
Process Flow (Scenario’s) that includes the System, a rational set of roles (Actors).
Menu and Navigation
Lists and Selection Criteria
Links to other pages and information
Actions (and rules)
ExceptionsPreparation for the System Use Cases
Many of the System Use Cases will include a number of standard views:
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
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 requiredWhat are our expectations?
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?