Skip to end of metadata
Go to start of metadata


  • Use case fit-gap analysis
  • Identify types of data we need to account for and how they fit into this model
  • Identify existing data sources and whether/how to migrate them
  • Clarify proposed data model
  • Identify project risks

Use Cases

  • Major categories
    • Support/Self-help documentation
    • Decision-making criteria
      • Use cases and opinions (will this work in my context; have others, like me, used this)
      • Comparing options (what other options should I compare this to)
    • Anything missing
      • Proposed: for DOCS or RSSP, a central place to document bugs and publicize workarounds they have found
      • Proposed: for service provider, a central place to get input and feedback from customers
      • Proposed: for IST. a place to direct people to the service catalog and procurement
      • "Soutions"--a product or support
      • Awareness of available solutions/seeing what the options are
      • of information there
      • Need to discuss how we get to "nodes" in the TSR (homepage, marketing, how do we help people get to the right place, overviews of options in a category, not a service for these reasons ("not implemented because"), (from Ian: Forums??))
      • Where do we document lessons learned
      • Ongoing projects related to services
      • Is a system is down?
      • What comes out of IST website?  Do we replace the whole thing, or how do we select what comes out of IST website into TSR?
  • What do service providers want/need from this tool?
    • Use to set expectations for customers
    • Damage control--respond to concerns
    • Maintenance announcements
    • Desires for future services/wish list/feedback
    • Voting for enhancements
    • Polls
    • Project communication?  Long term?  "Swiss army knife?"
  • What does the service catalog want/need from this tool?
    • Direct people to the right place to buy, and vice versa
    • SLAs, etc.
    • Who's using the service already?
    • What are people using this for?
    • What users are looking for, how users will be affected, what they will experience, what training features do they need, continual feedback?

Types of Data

  • What types of data already exist?
    • Service specific data
    • How to select the right options
    • Other
    • Good example: Web hosting and VMs--decision support tool  (IST site web hosting matrix)
    • For each technology might a different solutions
    • "Here's what I want" --> "Here's a good potential solution"
    • TAM questionnaires--presalses to help guide people to the right solution
    • Question after reading all the information--need help/info/a little training.  Making sure that the service desk folks have the proper training so that the service desks can really help?
    • Training materials?  Keep in simple form?  Where exactly do I find this?
    • Sometimes the fastest way to get info is X?
    • Capture how to get things done?  PROCESS DOCUMENTATION
    • When do I go to TAM vs. Service Desk vs. guy down the hall?  HOW DO I GET THIS DONE?
    • Decision support at higher level?  How do I get this process done most efficiently?
    • Is a forum maybe the best option?
    • Marketing tool?  Branding IST stuff?

Sources of Information for TSR & Migration

  • IST web site(s)
  • Knowledge Base
  • WikiHub?
  • Individual web sites?
  • Can these all migrate?
  • Shopping cart (also on website--huge website there) (Will merge with shopping cart, service catalog into sciquest service catalog)
  • Wiki has been internal service provider only

Viewable without CalNet ID?
Recommendation is publicly visible
Selling to other UCs: shib, other authentication to other UCs is important.

Data elements

  • Clarify the meaning of "required" and "optional" – for IST only
  • For branding, should any of the optional item be required if they exist? last meeting
  • Future possibility (administrative processes would need to be developed): For branding, several folks have raised the idea of linking this to SOA Governance – do we want a "good-housekeeping" seal for items that have passed certain requirements

Project Risks


  • Telephony: Identify alternate fields that might apply to B2C services; use cases for consumers
  • Service Providers: use cases for service providers; how do the data types need to reference each other
  • Service Catalog: use cases for the catalog and IST; how do we best source data that needs to appear in more than one place?
  • Knowledge Base: Identify risks of posting knowledge base data in TSR and allowing other users to add to it.
  • All: Muse on how we prevent the data in the TSR from becoming stale.  (Preparation for next week's discussion.)
  • No labels