User Requirements for Immersive Emergency Management Training Platforms

Requirements Gathering Methodology

The XRisis requirements gathering process employed user-centric design approaches combining conventional video conferencing sessions with collaborative immersive virtual world meetings, enabling humanitarian professionals to experience spatial collaboration capabilities firsthand whilst articulating their training needs. Nuwa team members participated in Action Contre la Faim's Cross Knowledge e-learning modules and observed four three-hour Emergency Preparedness Response Plan design sessions between Paris facilitators and humanitarian aid workers in Yemen, building deep familiarity with organisational processes, terminology, and operational constraints before proposing technical solutions. Weekly requirements sessions alternated between Microsoft Teams video calls and Mozilla Hubs immersive environments, with the immersive sessions proving invaluable as Action Contre la Faim team members experienced virtual collaboration for the first time, enabling tangible conversations about wireframed mock-ups and rudimentary environment prototypes illustrating potential capabilities.

The design team showcased early proof-of-concept implementations including AI-powered "Mentor Maud" avatar demonstrating conversational agent potential, interactive React applications visualising user experience flows, and collaborative virtual world features (presentations, video content, 3D objects, six-degrees-of-freedom navigation) enabling two-way dialogue between technical and domain expert teams. This iterative approach validated user-centric design methodology by maintaining continuous stakeholder engagement throughout requirements definition rather than upfront specification followed by disconnected implementation.

Core Functional Requirements

Twenty-two requirements emerged from collaborative sessions, categorised as functional (capabilities the system must provide) and non-functional (quality attributes the system must exhibit). Critical show-blocker requirements include: user authentication supporting secure access control (FR-0009), multi-synchronised scenes enabling real-time state sharing across distributed participants (FR-0002), video conferencing integration connecting users across digital scenes via Rainbow CPaaS (FR-0003), user type management supporting Administrator, Simulation Designer, Facilitator, and Participant roles with appropriate permission boundaries (FR-0006a), free movement and interaction enabling 6-degrees-of-freedom navigation and object manipulation within virtual scenes (FR-0016), and centralised 2D-3D element storage providing cloud-based asset management (FR-0012).

Must-have requirements include: avatar and scene selection enabling managed persona choices (FR-0001), participant user role assignment supporting Country Director, Programme Heads, Support Heads, and Manager positions reflecting organisational structures (FR-0006b, FR-0010), external media notifications enabling delivery of PDFs, audio files, videos, and images as scenario injects (FR-0005), low-bandwidth and reconnection support ensuring accessibility from resource-constrained locations with variable internet connectivity (NFR-0005), real-time countdown timer displaying phase and task time remaining (FR-0022), and application lifecycle management handling instantiation, operation, and graceful shutdown (NFR-0003).

Should-have requirements include: scenario lifecycle visualisation showing current scenario time as days elapsed since initial shock (FR-0004), simulated emergency country map displaying scenario geography and affected regions (FR-0011), preloading of scenes from cloud onto personal devices enabling offline or low-connectivity operation (NFR-0001), extended reality orchestration system implementing connections between orchestrators and external connectors (NFR-0004), facilitator observation and playback enabling fly-on-wall monitoring and session recording for subsequent review (FR-0020), avatar-based video calls using avatars rather than real video feeds via CPaaS integration (FR-0021), and learning outcomes capture through integration with Action Contre la Faim's Monitoring, Evaluation, Accountability and Learning framework (FR-0017).

Could-have requirements include: external file management integration connecting with SharePoint or Google Drive organisational systems (FR-0008), LLM-based call transcription and summarisation providing automatic documentation (NFR-0002), and tech literacy accessibility ensuring system usability regardless of user technical sophistication or computer processing power (FR-0019).

Three-Pilot Structure Definition

Requirements gathering validated three distinct pilot configurations addressing different emergency management cycle phases with specific learning objectives and technical capabilities. Pilot 1 (Pre-Deployment Humanitarian Refresher) aims to enhance team preparedness in shared immersive space by offering scenario library for emergency lifecycle management induction training ensuring base knowledge acquisition for optimal crisis response. Pilot 2 (Country Office Emergency Preparedness Response Plan Strategy and Design Workshop Training) designs platform for Senior Management Team training on leading, running, and designing EPRPs with headquarters during strategy design workshops, facilitating remote testing and updating of operational plans and procedures. Pilot 3 (Global Metaverse Emergency Simulation Exercises) designs platform for inter-country emergency response simulations assessing capacity for remote and in-situ emergency plan implementation and coordination across multiple organisational actors including UN instances and local country offices.

This three-tier structure progresses from individual knowledge building through collaborative planning to complex multi-stakeholder coordination, with each pilot building upon capabilities and content developed in previous phases whilst introducing additional complexity aligned with advancing learner competencies and organisational readiness requirements.

Technology Stack Decisions

Requirements analysis informed technology stack selection prioritising: Mozilla Hubs as base framework providing open-source WebXR capabilities with proven scalability and community support; Rainbow CPaaS integration for enterprise-grade communication reliability essential for professional training delivery; ConvAI for conversational non-playing characters supplementing CORTEX2 CoVA capabilities; Ready Player Me for avatar customisation enabling diverse representation; and AWS infrastructure supporting centralised storage, database services, and distributed system coordination across European data centre regions.

The stack balances capability requirements against deployment constraints including accessibility from 3G-plus smartphones through desktop computers to VR head-mounted displays, compatibility with variable network connectivity prevalent in humanitarian field locations, and integration with existing organisational systems minimising disruption to established workflows.

Validation Planning Integration

Requirements definition directly informed validation planning by establishing clear success criteria against which platform implementation would be assessed. Each requirement specified usage across three pilots, priority level (show-blocker, must-have, should-have, could-have), affected user types (simulation designer, facilitator, participant), hardware and software specifications, and relationships to other requirements creating dependency mapping essential for implementation sequencing. This structured approach enabled traceability from initial user needs through technical specifications to implementation decisions and eventual validation testing, ensuring development remained grounded in genuine operational requirements rather than drifting toward technically interesting but operationally marginal capabilities.

Conclusion

The user requirements gathering process successfully validated proposed three-pilot structure whilst generating detailed technical specifications enabling focused Phase 2 implementation. The user-centric design methodology proved essential for bridging between humanitarian domain expertise and technical platform development, with immersive prototyping sessions transforming abstract possibilities into tangible experiential understanding guiding requirement articulation. The resulting requirements framework provided foundation for successful CORTEX2 technology integration and platform validation with operational users, demonstrating the value of substantial upfront investment in collaborative requirements definition before committing to implementation approaches.