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

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 Click to Enlarge My SL Stuff My User Profile Newbie Helper Kit Newbie Must Knows Troubleshooting LSL Goodies Build Goodies SL Trivia OpenSim Stuff External Wiki Contributions DMP1/DMS1 DMP1/DMS1 Programming Related topics Main Page Volunteer Portal The Tao VTeam Blog edit