Functional Requirements
· The user needs to be able to create their own character and virtual facility within the simulation space. This includes character customization for their avatar, and the ability to construct the facility given certain parameters within the game. The character creation will occur on start up and the building of the facility will be the first learning module.
· The user needs to be able to buy and place equipment within their facility within a given budget, which is provided by the lesson module parameters. Placement and the types of equipment the user chooses will affect the state of the simulation as they experience further lesson modules.
· The user needs to be able to interact with computer controlled NPC, who will have state machine and path finding AI. The user can satisfy the demands of the NPC's and make decisions during conversations with them, both of which will affect their overall performance within the simulation.
· The user needs to be able to make decisions based on documents and other non-NPC contact within the simulation based on predetermined outcomes by the instructor. This includes hiring and terminating employees, and putting together an organizational hierarchy.
· The user needs to be able to direct NPC's, either employees or clients, to certain locations or to do certain actions, in order to satisfy the clients. This will affect the student's performance.
· In most of the learning modules, there will be a timer for the module, which will force the student to make decisions in real time. This will mimic the stressful nature of a career in Athletic Training Management.
· The instructor needs to be able to modify learning modules beyond the creation of the facility itself and the character creation. They need to be able to set up the text and dialogue trees for important NPC's , and to control a variety of parameters which control various aspects in the game.
· The instructor needs to be able to monitor student progress. They need to be able to see the student's training facility, what modules they have completed, how many times they have attempted a given modules, and what reason they may have failed.
· The instructor must be allowed to give their students specific feedback based on the students' performance. This requires the instructor be able to send messages to the student on a regular basis.

2. Performance and Non-Functional Requirements - Requirements that do not impact product functionality.
2.1 Process Requirements - requirements placed on the development process.
2.1.1 Standards Requirements
* No external development standards are required for the process.
2.1.2 Delivery Requirements
* Expected deadline for deployment is the end of April.
* Dr. Cernohous should be trained and familiar with the final iteration of the administrative interface (and able to teach subsequent administrative users).
2.1.3 Implementation Requirements
* We are limited to a large extent by what the Mono Virtual Machine has implemented as far existing code libraries.
* We are limited to using the object hierarchy implemented in the Unity3D engine.
* We can not use certain 'pro only' features of Unity3D that user's who pay for a Pro License can include (e.g. movie textures, asynchronous asset loading, post-processing effects, etc.)
2.2 Product Requirements - Requirements placed on the completed product.
2.2.1 Usability Requirements Restrictions caused by expected user base (e.g., nontechnical users, high turn-over rate, etc.)
* Turn-over rate will be relatively high as the simulator will be used in a class taught every semester. New students will have to begin learning the program quickly. There will be no 'expert users' (execpt in the case of Dr.Cernohous - see below).
* The average user is projected to be very non-technical with little experience in interfaces common for 3D simulation and manipulation.
o The learning curve must be controlled by both in-game tutorials and basic task teaching 'missions' (such as movement, manipulation, interaction with computer controlled characters, and GUI interaction) within the first module. More complex tasks (such as building clinics, evacuating crowds, and hiring and firing personel) must be explained clearly both in text form and visually through in-game walkthroughs.
o Action must either be as reversible as possible or the user should be allowed to try again with a clean slate. This ability is acceptable to Dr. Cernohous and the user will not be academically penalized for using this feature.
* Dr. Cernohous (and possible faculty working with/for him) will be provided another level of functionality within the simulator. Administrators will be able to create new content and edit existing content that will then be served to the end-users (students).
o This interface will necessarily have a steeper learning curve as control over scripting and meta information requires more control and input.
o Dr. Cernohous is by his own admission a non-technical user himself and, although the admin interface is lower priority than the students' interface and content, sufficient documentation and in-game help must be provided to bring him and any new administrative users up to speed quickly and correctly.
2.2.2 Performance Requirements - Restrictions caused by customer performance expectations (e.g., energy consumption, throughput capacity, runtime speed,, etc.)
* Performance of the deployment will be important to end users as:
o Some of the learning modules will be very time sensitive
o Simulations should inherently be responsive to users' actions
o Academic evaluation is tied to the usability of the simulation and that usability is tied to the responsiveness of the client (so end users will have serious vested interest in doing well).
* End user computers are projected to be most commonly laptops
o This provides us only so much processing power on the client side (no/low-power GPU, low memory)
* End users internet connections are expected to be of cable quality (connected and no dial-up)
o This allows us the option to stream content through a web browser plug-in and provide some client/server communication without significant loss of simulation performance.
2.2.3 Reliability Requirements
* Accurate information about student evaluation is key and proper communication of the evaluation is high priority
o Matching our evaluation algorithms of student performance to Dr. Cernohous evaluations of that same work must be done early and often. High-priority.
o Some amount of data-driven flexibility and administrative modifications of these algorithms should be included.
o Feedback to the students about their evaluation and performance should be clear and consistent. There should be no hidden penalties and grading criteria should be available at all times, mandatory on first viewing, clear, and complete.
* Students will be allowed a time window to complete modules and outages may prevent completion.
o This is expected to be handled on a non-game, class administrative level.
2.2.4 Maintenance Requirements
* Administrative systems that add content should allow for reversibility and backup of previous content. The file format used for content systems should be as human readable as possible.
* Full commenting and documentation should be provided for maintenance and further development by programmers that may be hired to extend the program.
2.3 External Requirements - Requirements that are neither process or product centered.
2.3.2 Cost Constraints
* Both development and deployment can reportedly be completed under Unity3D's standard free license (according to Unity Technologies' Caitlyn Meeks - see Appendix D).
* We have limited budget provided by Dr. Cernohous for hiring a 3D artist in order to create content for the lesson modules.
* We are expected to provide our own development environments and equipment for development.
o Open Issue: will NAU provide a server for both test and final deployment?
2.3.3 Other Constraints
* We are limited to a large extent by what the Mono Virtual Machine has implemented as far existing code libraries.
* We are limited to using the object hierarchy implemented in the Unity3D engine.
* We can not use certain 'pro only' features of Unity3D that user's who pay for a Pro License can include (e.g. movie textures, asynchronous asset loading, post-processing effects, etc.)
2.3.4 Inter-operability Requirements
* This product will be served (either by downloadable client or client sent through the Unity3D web browser plug-in) from an NAU computer, as such the product will have to be constrained to working within the NAU network, security, and operating system infrastructures.
o Open Issue: Can we harness existing servers within NAU (either at CEFNS or HHS) in order to serve the Unity3D framework or provide downloadable clients to users and (if needed) provide database services.
o Open Issue: Can we use the Unity3D framework to have the client communicate with a database on the server in order to save user information?
o Open Issue: Can we use the CAS system at NAU (Shibboleth CAS) in order to authenticate usrs and associate simulator accounts/clients with student information?
* If the web browser plug-in becomes the most feasible/usable method of serving the simulator to the users, the plug in will have to be compatible with most common web browsers (the responsibility for this can be shifted to the makers of Unity3D). However: a concern remains that if the plug-in is incompatible with the product, the users should be informed before the first lesson and provided a link to a (free) alternative browser that is compatible (this is the best solution available currently).
* Although Unity3D will dynamically lower rendering detail, there are still minimum requirements:
o On Windows, the Unity Web Player requires Windows 2000/XP/Vista/7.
o On Mac OS X, the Unity Web Player requires Mac OS X 10.3.9 or newer.
o (Current research indicates these are the minimum requirements for the downloadable client as well)