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

{| width="100%"
|-
|valign="top"|
<FONT size="+2"><B>DETAILED REQUIREMENTS</B></FONT><BR/>__NOTOC__
<div id="box">
==Help Island/Welcome Area Occupancy Counter System - Overview==
<div style="padding: 0.5em">
===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:
<P>&nbsp;1. Design, architect and build a system that will detect, count and tally the occupancy levels in certain areas within Second Life.</P>
<P>&nbsp;2. The areas for consideration include, but are not limited to: 
:* Orientation Islands (all)
:* Help Islands (all)
:* Welcome Areas / Infohubs.</P>
<P>&nbsp;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.</P>

===Project Out Of Scope===
The following is a list of items that are specifically excluded from this enhancement:
<P>&nbsp;1. Real-time info.</P>
<P>&nbsp;2. Resident names and personal metrics.</P>
<P>&nbsp;3. Data warehousing capabilities although external systems (under a separate project) can interface to it to gather limited info.</P>
</div></div>
<div id="box">
==User Characteristics==
<div style="padding: 0.5em">
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.
</div></div>
<div id="box">
==Specific Requirements==
<div style="padding: 0.5em">
{| width="100%"
|-
|valign="top" bgcolor="#CCCCCC"|
Reqt. ID#
|valign="top" bgcolor="#CCCCCC"|
Description
|valign="top" bgcolor="#CCCCCC"|
Type
|valign="top" bgcolor="#CCCCCC"|
Priority
|valign="top" bgcolor="#CCCCCC"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
1. System Architecture
|-
|valign="top"|
REQT-1.01
|valign="top"|
Design, architect and build a system that will detect, count and tally the occupancy levels in certain areas within Second Life.
|valign="top"|
Logical
|valign="top"|
Mandatory
|valign="top"|
N/A
|-
|valign="top"|
REQT-1.02
|valign="top"|
The areas for consideration include, but are not limited to:
* Orientation Islands (all)
* Help Islands (all)
* Welcome Areas / Infohubs.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.03
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.04
|valign="top"|
The system must be able to operate entirely in-world and not be dependent on any external systems for information/message routing, configurations.  
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.05
|valign="top"|
The system must continue to be operable and maintainable beyond the creator's support period or avatar lifespan.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.06
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.07
|valign="top"|
The system must be scalable to handle requests from a few to potentially several thousand Users.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.08
|valign="top"|
The system must operate autonomously.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-1.09
|valign="top"|
The system must be fault-tolerant.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
2. Collection Server
|-
|valign="top"|
REQT-2.01
|valign="top"|
The collection server must be able to accommodate all inbound update metrics from remote sensors at a reasonable update rate.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-2.02
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-2.03
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-2.04
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
3. Relay Servers
|-
|valign="top"|
REQT-3.01
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-3.02
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-3.03
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-3.04
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-3.05
|valign="top"|
The relay servers must be able to recognize data requests from endpoints, and their client versions.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-3.06
|valign="top"|
The relay server must be able to provide notification to endpoint devices that require updated version in order continue functioning normally.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-3.07
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
4. Sensors
|-
|valign="top"|
REQT-4.01
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-4.02
|valign="top"|
The sensors must be able to distinguish more than 16 avatar/agents in a given locale (a hard limit in LSL).
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-4.03
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-4.04
|valign="top"|
The sensors must employ techniques to ensure their longevity in the parcel/sims they occupy.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-4.05
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
5. Endpoint Devices
|-
|colspan="5" bgcolor="#EEEEEE"|
5a. Personal HUD Device
|-
|valign="top"|
REQT-5a.01
|valign="top"|
The personal HUD device must be easy to use.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-5a.02
|valign="top"|
The personal HUD device must not occupy valuable screen space/
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-5a.03
|valign="top"|
The personal HUD device must be able to operate in no-script regions.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-5a.04
|valign="top"|
The personal HUD device must employ techniques to not overload the system with repeated or frivolous requests.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-5a.05
|valign="top"|
The personal HUD device must display the data received from the Relay Server in a manner that is meaningful to the User.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#EEEEEE"|
5b. Text Display Device
|-
|valign="top"|
REQT-5b.01
|valign="top"|
The text display device must be able to operate autonomously.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-5b.02
|valign="top"|
The text display device must employ techniques to not overload the system with repeated or frivolous requests.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-5b.03
|valign="top"|
The text display device must display the data received from the Relay Server in a manner that is meaningful to the User.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
6. Product Distribution System
|-
|valign="top"|
REQT-6.01
|valign="top"|
The product distribution system must be set in a conspicuous place, and be easy to find.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-6.02
|valign="top"|
The product distribution system must dispense the latest available endpoint device.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-6.03
|valign="top"|
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.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|colspan="5" bgcolor="#DDDDDD"|
7. Documentation and Maintenance
|-
|valign="top"|
REQT-7.01
|valign="top"|
The HI/WA System must be well documented.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-7.02
|valign="top"|
The source code for all of the system components must be published and available.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|-
|valign="top"|
REQT-7.03
|valign="top"|
The source code must be well-documented for others to be able to understand the flow.  "Self-documenting code" should be discouraged.
|valign="top"|
Type
|valign="top"|
Priority
|valign="top"|
Companions
|}
</div></div>
<div id="box">
==Assumptions and Constraints==
<div style="padding: 0.5em">
===Assumptions===
{| width="100%"
|-
|valign="top" bgcolor="#CCCCCC"|
Num
|valign="top" bgcolor="#CCCCCC"|
Assumption Description
|-
|valign="top"|
1
|valign="top"|
The regions to be monitored have scripts enabled at the Simulator level.
|-
|valign="top"|
2
|valign="top"|
Where it is feasible or required, sensors will be placed on parcel/sims set to the Second Life Mentor group.
|-
|valign="top"|
3
|valign="top"|
Only a "snapshot in time" view of the data is required for the moment.
|}

===Constraints===
{| width="100%"
|-
|valign="top" bgcolor="#CCCCCC"|
Num
|valign="top" bgcolor="#CCCCCC"|
Constraint Description
|-
|valign="top"|
1
|valign="top"|
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.
|-
|valign="top"|
2
|valign="top"|
The in-world placement of sensors and servers must be on low-lag, crash-free simulators to maintain a high degree of availability.  
|-
|valign="top"|
3
|valign="top"|
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.
|}
</div></div>
<div id="box">
==Appendices==
<div style="padding: 0.5em">
===Project Terminology===
{| width="100%"
|-
|valign="top" bgcolor="#CCCCCC"|
Terminology
|valign="top" bgcolor="#CCCCCC"|
Explanation
|-
|valign="top"|
Agent
|valign="top"|
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.")
|-
|valign="top"|
Avatar
|valign="top"|
The virtual manifestation or visual appearance of a Second Life Resident.
|-
|valign="top"|
HUD
|valign="top"|
An acronym for "Heads Up Display."  It is an object or device that exhibits usefulness when attached to the User's screen.
|-
|valign="top"|
Client
|valign="top"|
A device, or a system of devices which request and act upon the "service" requested from a "server."
|-
|valign="top"|
LSL
|valign="top"|
An acronym for "Linden Scripting Language."  It is the preferred programming language available to Residents in Second Life.
|-
|valign="top"|
Resident
|valign="top"|
An account holder in the virtual world of "Second Life."
|-
|valign="top"|
Sensor
|valign="top"|
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.
|-
|valign="top"|
Server
|valign="top"|
A device, or a system of devices whose purpose is to provide "service" to a periphery device known as a "client."
|-
|valign="top"|
User
|valign="top"|
The target group of residents belonging to the "Second Life Mentor" group for whom this system is developed.
|}
===References===
{| width="100%"
|-
|valign="top" bgcolor="#CCCCCC"|
Document Title / Identifier
|valign="top" bgcolor="#CCCCCC"|
Publishing Organization
|valign="top" bgcolor="#CCCCCC"|
Description
|-
|valign="top"|
[http://rpgstats.com/wiki/index.php?title=Main_Page LSL Wiki]
|valign="top"|
rpgstats.com
|valign="top"|
Provides extensive documentation of the LSL (Linden Scripting Language) syntax.
|}
===Distribution List===
{| width="100%"
|-
|valign="top" bgcolor="#CCCCCC"|
Name
|valign="top" bgcolor="#CCCCCC"|
Department/Area Represented
|valign="top" bgcolor="#CCCCCC"|
Approve
|valign="top" bgcolor="#CCCCCC"|
Review
|valign="top" bgcolor="#CCCCCC"|
Inform
|-
|valign="top"|
Blue Linden
|valign="top"|
VTeam / Linden Lab
|valign="top" align="center"|

|valign="top" align="center"|

|valign="top" align="center"|
'''X'''
|-
|valign="top"|
Mia Linden
|valign="top"|
VTeam / Linden Lab
|valign="top" align="center"|

|valign="top" align="center"|

|valign="top" align="center"|
'''X'''
|-
|valign="top"|
Amber Linden
|valign="top"|
VTeam / Linden Lab
|valign="top" align="center"|

|valign="top" align="center"|

|valign="top" align="center"|
'''X'''
|-
|valign="top"|
Lexie Linden
|valign="top"|
VTeam / Linden Lab
|valign="top" align="center"|

|valign="top" align="center"|

|valign="top" align="center"|
'''X'''
|-
|valign="top"|
George Linden
|valign="top"|
VTeam / Linden Lab
|valign="top" align="center"|

|valign="top" align="center"|

|valign="top" align="center"|
'''X'''
|}
===Version History===
{| width="100%"
|-
|valign="top" bgcolor="#CCCCCC"|
Version
|valign="top" bgcolor="#CCCCCC"|
Date
|valign="top" bgcolor="#CCCCCC"|
Author/Editor
|valign="top" bgcolor="#CCCCCC"|
Version/Revision Comments
|-
|valign="top"|
0.9
|valign="top"|
August 30, 2008
|valign="top"|
[[User:Lum_Pfohl|Lum Pfohl]]
|valign="top"|
First draft released for publication and general review.
|}
</div></div>
[[User:Lum Pfohl|Lum Pfohl]] 13:58, 30 August 2008 (PST)
|valign="top" width="200 px"|
{{Lum's Quick Links}}
|}