Specification Reorganization

From HTNG Connectivity Wiki

Jump to: navigation, search

Contents

Specification Reorganization

This page provides a work area for the Governance Council Specification Reorganization Team to collaborate and share notes.

Purpose
Provide use cases, schemas, and other specification components in formats that are easily re-usable by other work groups
  • Workgroups will create/identify
    • business need description (where and why),
    • core business use cases (what),
    • business process (BPM diagram and narrative [how]),
    • roles (who),
    • services/new services (description, WSDL, schemas to support services)

Use cases generic for all specifications or specific to specifications?

Should be specific to make it easy for implementer - Sue

If there is a significant difference between use cases for two different circumstances, have separate processes outlined

Technical specification should still address business problem, requirements, use cases, use case report/user story, etc.

Use cases, WSDLs and schemas part of master library

CSQ would definitely change, but to what extent is not clear yet

Product Specification may not be relevant anymore

All to review this framework and think bring ideas to next meeting

Beyond a new structure/format for specs, are we changing the scope of what WGs are doing? Chris

WG members need to think of their work as helping create industry standards, not just respective WG Sue

Thoughts on Spec Template

Document History

Document Information

  • Document Purpose
  • Scope
  • Audience
  • Overview
  • Known Issues

Business Section

Actors/Roles
Describes the roles played in the business scenarios. To distinguish from role and actor, use role when referring to a system, actor when referring to participants.
Business Scenarios
Describes a specific business situation including particpants(actors in their roles)and goals
a description of the essence of the process (generic)
  • describes actors involved
    • who initiates scenario and
    • who participates in the scenario
  • what is the goal achieved by scenario (Why am I doing this?)
  • where this occurs (i.e. property-based)
Use Cases
A use case in our context is a more specific circumstance than what may be described in the scenario. For example there maybe a Business Scenario for Check-In and a Use Case for Check-In via Kiosk.
Business Process Flows
Depicts the basic business process for each use case or scenario

Technical Section

  • Message Flow
  • Message Description
  • WSDL
  • Schemas
  • Message Samples

Appendices

  • Glossary
  • Implementation Notes & Guidelines
  • Links (optional)
  • References (optional)

Example based on Kiosk

Intro

Blah Blah Blah

Business Background

Roles

PMS System
Represents the property management system that provides room assignment services
Kiosk System
The kiosk system used by the Guest
Guest
Hotel guest
Front Desk Clerk
Used in business scenario but function replaced by Kiosk

Business Scenarios

Check-in
  • Confirm Guest Identity
  • Locates reservation
  • Confirms payment method,
  • assigns room to guest,
  • issues key, and
  • enables in-room devices and functions
Participants - Guest, Front Desk Clerk or Kiosk
Check-out
Guest is presented with charges to review, approve, and optionally print and may turn in key.
  • Locate stay record
  • retrieve folio
  • present room charges for approval (optionally print)
  • settle
  • return/cancel key (optional)
  • disable in-room devices and functions
Participants - Guest, Kiosk or Desk clerk.
Reserve Room
Reserve a room for a future stay
Review and Print Room Charges
Review and optionally prints room charges (without check-out)
Print Boarding pass
Prints airline boarding pass
Order Transportation
yada yadda yadda
Virtual Concierge
blah blah blah
Personal tools
administrative tools