R2 I4 REQ

From IGSTK

Release 2, Iteration 4 Requirements

These requirements have been gleaned from the meeting notes posted by Kevin Cleary and Kevin Gary the week after the April 11-13 meeting. Please edit/revise as needed. Our documented requirements process can give you guidance.

Iteration Requirements

Tracker Requirements

1. The tracker will not push data to other components. Instead, other components will request data from the tracker. This reflects a "top-down" approach to application control. (Confirmed)
2. The tracker component will maintain its own internal thread. This will allow special safety code to run at full speed without ever being blocked by the main application thread. (Deferred)
3. When requested for an update, the tracker will push data into an internal data area from which it can be accessed by other components. This allows for synchronization of multiple tools: a single update can be followed by access of tracker data from multiple components, and each component will get data that was generated at the same time point. (Confirmed)
4. The tracker state machine must be fully encapsulated and private to the tracker base class. This makes it impossible for derived classes to disrupt the state machine of the base class. (Confirmed)
5. State machine transitions in the tracker base class will drive actions in the derived classes via a protected internal interface. This provides state machine with complete control over which derived class methods are executed. (Confirmed)

Other facilities

1. The toolkit will provide platform-independent access the system real-time clock, and will provide an absolute time with millisecond precision. (Confirmed)

Iteration Action Items

Tracker

1. Tracker integration will occur by identifying the reusable aspects of the code provided by David Gobbi and moving it into the IGSTK framework directly.

Logging

1. This iteration will include the fist-generation native Logging implementation

Demo Application

1. This iteration will provide a version of the sample application that integrates the Aurora Tracker
2. This iteration will not provide an application that uses multiple trackers in one scene

Requirements to be uploaded to the BugTracker

Tracker:

REQ 06.02.13 (Style Guideline) The tracker component will have "top-down" approach to application control such that it will not push data to other components, but allow other components to request their desired data.

REQ 06.02.14 (Style Guideline) Upon a data request, the tracker component will push data into an internal data area from which it can be accessed by other components enabling the synchronization of multiple tools such that a single update can be followed by access of tracker data from multiple components, and each component will get data that was generated at the same time point.

REQ 06.02.15 (Style Guideline) The tracker component's state machine must be fully encapsulated and private to the tracker base class making it impossible for derived classes to disrupt the state machine of the base class.

REQ 06.02.16 (Style Guideline) State machine transitions in the base class of the tracker component will drive actions in the derived classes via a protected internal interface enabling the state machine to have complete control over which derived class methods are executed.

Other: (This is a global tool-kit Requirement)

REQ 04.02.03 (Design Guidelines) IGSTK will provide platform-independent access to the system real-time clock, and will provide an absolute time with millisecond precision.