User:Lum Pfohl/LSL Goodies/HI-WA Occupancy Counter System/Business Requirements

From Second Life Wiki
Jump to navigation Jump to search

DETAILED REQUIREMENTS

Help Island/Welcome Area Occupancy Counter System - Overview

Background

This is a system of scripts, sensors and servers designed to sense, collect, report and disseminate information on the occupancy levels of Orientation Islands, Help Islands, Welcome Areas and Infohubs.

Statement of Business Need

The information described above, when expanded to distinguishing Second Life Mentors from New Residents, can be useful in determining effectiveness of Second Life Mentoring Program and Greeter Program as well as helping Mentors decide where to offer help to New Residents.

Project Scope

This following list indicates the new functionality included as part of the enhancement package of the HI-WA Occupancy Counter System:

 1. Design, architect and build a system that will detect, count and tally the occupancy levels in certain areas within Second Life.

 2. The areas for consideration include, but are not limited to:

  • Orientation Islands (all)
  • Help Islands (all)
  • Welcome Areas / Infohubs.

 3. Allow for a number of clients which can poll for this information and utilize it in various ways. Some such methods include, but are not limited to:

  • Text Displays
  • HUDs
  • Database/Warehousing Server
  • Other Occupancy Counter Systems.

Project Out Of Scope

The following is a list of items that are specifically excluded from this enhancement:

 1. Real-time info.

 2. Resident names and personal metrics.

 3. Data warehousing capabilities although external systems (under a separate project) can interface to it to gather limited info.

User Characteristics

The Second Life Mentor group has several thousand members whose focus is on locating areas where New Residents require basic help. The Mentors are at least 6 months old (based on calendar days from their rez-date), and possess a certain level of knowledge of the intricacies of Second Life, the usage of certain basic tools and widgets available to them, in order to complete their business tasks. The Second Life Mentor group also have a number of Linden Lab employees (for example: VTeam) whose focus is on the effectiveness of the Second Life Mentor Program and the retention of New Residents as they enter Second Life. Users generally do not have extensive technical expertise. Nonetheless, Users are knowledgeable regarding their business tasks. Consequently, the overall pool of Users is considered to be sophisticated.

Specific Requirements

Reqt. ID#

Description

Type

Priority

Companions

1. System Architecture

REQT-1.01

Design, architect and build a system that will detect, count and tally the occupancy levels in certain areas within Second Life.

Logical

Mandatory

N/A

REQT-1.02

The areas for consideration include, but are not limited to:

  • Orientation Islands (all)
  • Help Islands (all)
  • Welcome Areas / Infohubs.

Type

Priority

Companions

REQT-1.03

Allow for a number of clients which can poll for this information and utilize it in various ways. Some such methods include, but are not limited to:

  • Text Displays
  • HUDs
  • Database/Warehousing Server
  • Other Occupancy Counter Systems.

Type

Priority

Companions

REQT-1.04

The system must be able to operate entirely in-world and not be dependent on any external systems for information/message routing, configurations.

Type

Priority

Companions

REQT-1.05

The system must continue to be operable and maintainable beyond the creator's support period or avatar lifespan.

Type

Priority

Companions

REQT-1.06

The system must be able to perform under potentially hostile conditions. For example: Parcels/Sims with

  • No Script
  • No Build/Rez
  • No Object Entry
  • 2 minute auto-return
  • etc.

Type

Priority

Companions

REQT-1.07

The system must be scalable to handle requests from a few to potentially several thousand Users.

Type

Priority

Companions

REQT-1.08

The system must operate autonomously.

Type

Priority

Companions

REQT-1.09

The system must be fault-tolerant.

Type

Priority

Companions

2. Collection Server

REQT-2.01

The collection server must be able to accommodate all inbound update metrics from remote sensors at a reasonable update rate.

Type

Priority

Companions

REQT-2.02

The collection server must be able to produce, upon request, all information in a format that permits transmission of said payload in a compact manner for rapid delivery.

Type

Priority

Companions

REQT-2.03

The collection server must be able to operate in a mode that is fault-tolerant. That is, temporary disruption of service to the the collection server or the simulator that is carrying the collection server, should not result in a stoppage of the entire system.

Type

Priority

Companions

REQT-2.04

The collection server must be able to provide trans-version service. That is, as parts of the system is being upgraded, the server must be able to parse incoming data as well as respond to requests for outbound data to different version endpoints.

Type

Priority

Companions

3. Relay Servers

REQT-3.01

The relay servers must be able to accommodate all information in a format that permits transmission of said payload in a compact manner for rapid delivery.

Type

Priority

Companions

REQT-3.02

The relay servers must be able to operate in a mode that is fault-tolerant. That is, temporary disruption of service to the the relay servers or the simulator that is carrying the relay servers, should not result in a stoppage of the entire system.

Type

Priority

Companions

REQT-3.03

The relay servers must have as "fresh" information as possible without placing undue load on the collection server, such that it minimizes the stale data.

Type

Priority

Companions

REQT-3.04

The relay servers must be able to provide trans-version service. That is, as parts of the system is being upgraded, the server must be able to parse incoming data as well as respond to requests for outbound data to different version endpoints.

Type

Priority

Companions

REQT-3.05

The relay servers must be able to recognize data requests from endpoints, and their client versions.

Type

Priority

Companions

REQT-3.06

The relay server must be able to provide notification to endpoint devices that require updated version in order continue functioning normally.

Type

Priority

Companions

REQT-3.07

The relay server must be able to provide an updated endpoint device to the requesting agent, where it is technically feasible, and not doing so will result in non-deterministic behavior.

Type

Priority

Companions

4. Sensors

REQT-4.01

The sensors must take measurements of the number of avatars/agents in a given locale and relay the information to the collection server on a periodic basis.

Type

Priority

Companions

REQT-4.02

The sensors must be able to distinguish more than 16 avatar/agents in a given locale (a hard limit in LSL).

Type

Priority

Companions

REQT-4.03

The sensors must be able to distinguish detected avatar/agents in the same group as the sensor is set to from avatar/agents not in the same group as the sensor and report those two metrics separately to the collection server.

Type

Priority

Companions

REQT-4.04

The sensors must employ techniques to ensure their longevity in the parcel/sims they occupy.

Type

Priority

Companions

REQT-4.05

The sensors must be non-intrusive and not detectable by residents as possible. That is, they should not be seen, or felt or otherwise interact with the environment or avatar/agents on the parcel/sim.

Type

Priority

Companions

5. Endpoint Devices

5a. Personal HUD Device

REQT-5a.01

The personal HUD device must be easy to use.

Type

Priority

Companions

REQT-5a.02

The personal HUD device must not occupy valuable screen space/

Type

Priority

Companions

REQT-5a.03

The personal HUD device must be able to operate in no-script regions.

Type

Priority

Companions

REQT-5a.04

The personal HUD device must employ techniques to not overload the system with repeated or frivolous requests.

Type

Priority

Companions

REQT-5a.05

The personal HUD device must display the data received from the Relay Server in a manner that is meaningful to the User.

Type

Priority

Companions

5b. Text Display Device

REQT-5b.01

The text display device must be able to operate autonomously.

Type

Priority

Companions

REQT-5b.02

The text display device must employ techniques to not overload the system with repeated or frivolous requests.

Type

Priority

Companions

REQT-5b.03

The text display device must display the data received from the Relay Server in a manner that is meaningful to the User.

Type

Priority

Companions

6. Product Distribution System

REQT-6.01

The product distribution system must be set in a conspicuous place, and be easy to find.

Type

Priority

Companions

REQT-6.02

The product distribution system must dispense the latest available endpoint device.

Type

Priority

Companions

REQT-6.03

The product distribution system must be able to receive incoming requests from relay servers to dispense the latest available endpoint device to the avatar key provided.

Type

Priority

Companions

7. Documentation and Maintenance

REQT-7.01

The HI/WA System must be well documented.

Type

Priority

Companions

REQT-7.02

The source code for all of the system components must be published and available.

Type

Priority

Companions

REQT-7.03

The source code must be well-documented for others to be able to understand the flow. "Self-documenting code" should be discouraged.

Type

Priority

Companions

Assumptions and Constraints

Assumptions

Num

Assumption Description

1

The regions to be monitored have scripts enabled at the Simulator level.

2

Where it is feasible or required, sensors will be placed on parcel/sims set to the Second Life Mentor group.

3

Only a "snapshot in time" view of the data is required for the moment.

Constraints

Num

Constraint Description

1

The in-world placement of system objects (sensors, servers, dispensers) will be on Linden-owned land, or "SL Mentor Friendly" private or group land. Where a system object (sensor) must cross private property, it must do so in a transient, low-impact manner.

2

The in-world placement of sensors and servers must be on low-lag, crash-free simulators to maintain a high degree of availability.

3

Where an object is prone to auto-return, efforts must be made to permit the object to stay on the parcel and may require LL intervention.

Appendices

Project Terminology

Terminology

Explanation

Agent

Often synonymous with "Resident." Agents are objects that represent an atomic concept of a Second Life "Resident." If Residents are the physical being, then agents are the virtual being represented by a "key" or "UUID" and their presence in a particular region, having an appearance (known as an "Avatar.")

Avatar

The virtual manifestation or visual appearance of a Second Life Resident.

HUD

An acronym for "Heads Up Display." It is an object or device that exhibits usefulness when attached to the User's screen.

Client

A device, or a system of devices which request and act upon the "service" requested from a "server."

LSL

An acronym for "Linden Scripting Language." It is the preferred programming language available to Residents in Second Life.

Resident

An account holder in the virtual world of "Second Life."

Sensor

A device, or a system of devices which detect and count the number of agents/avatars in a given locale. A sensor can be passive and stationary, or active and mobile.

Server

A device, or a system of devices whose purpose is to provide "service" to a periphery device known as a "client."

User

The target group of residents belonging to the "Second Life Mentor" group for whom this system is developed.

References

Document Title / Identifier

Publishing Organization

Description

LSL Wiki

rpgstats.com

Provides extensive documentation of the LSL (Linden Scripting Language) syntax.

Distribution List

Name

Department/Area Represented

Approve

Review

Inform

Blue Linden

VTeam / Linden Lab

X

Mia Linden

VTeam / Linden Lab

X

Amber Linden

VTeam / Linden Lab

X

Lexie Linden

VTeam / Linden Lab

X

George Linden

VTeam / Linden Lab

X

Version History

Version

Date

Author/Editor

Version/Revision Comments

0.9

August 30, 2008

Lum Pfohl

First draft released for publication and general review.

Lum Pfohl 13:58, 30 August 2008 (PST)

Lum's Quick Links
LumSelfPortrait.jpg
Click to Enlarge


Related topics

edit