Functional and Non-Functional Requirements
This page defines the full requirement set for the IFRC Virtual Situation Room (VSR): source ingestion, agent-orchestrated
report generation, analyst and operations delivery views, admin controls, and the quality constraints required for dependable
humanitarian decision support.
Partner Background and Project Goals
Partner Introduction
The International Federation of Red Cross and Red Crescent Societies (IFRC) coordinates humanitarian response across
complex emergencies where teams need fast, reliable, and explainable information. The Virtual Situation Room (VSR) was
developed as an AI-assisted reporting environment to support this operational need.
IFRC and National Society teams operate under severe time pressure during active crises, and reporting often depends on
assembling fragmented evidence from multiple external sources. This project was delivered with Microsoft support for the
IFRC VSR initiative.
Problem Statement
In fast-moving humanitarian crises, analysts spend excessive time collecting fragmented context from multiple sources.
This delays evidence-based decisions and creates a trade-off between speed and report quality at the point where both are
most critical. Manual synthesis increases turnaround time for crisis briefs, and rushed synthesis can reduce structure,
consistency, and traceability when teams need reliable outputs with low cognitive load.
Project Goals
Primary Goals
The primary goals are to deliver a source-grounded reporting pipeline that converts ingested crisis evidence into
structured report outputs, to expose report sections, references, and confidence context through stable API contracts,
and to reduce analyst turnaround time while preserving transparency and traceability of generated content.
Secondary Goals
The secondary goals are to provide role-appropriate delivery views for analyst depth and operations-oriented summaries,
to provide protected admin workflows for crisis lifecycle, ingestion, and orchestration actions, and to improve
readability and navigation so core insights remain accessible under high-pressure use.
Requirement Gathering Method
We used a mixed requirements process combining stakeholder context, workflow analysis, user-facing evaluation, and engineering
validation. This allowed us to capture both operational needs and implementation constraints before finalizing priorities.
Stakeholder Discussions and Workflow Review
Partner context and existing crisis workflows highlighted recurring delivery pressure on analysts, inconsistent source
consolidation, and the need for clearer role-specific outputs.
- Need for faster and more consistent crisis reporting.
- Need for source-grounded outputs with traceable references and confidence context.
- Need for distinct analyst-depth and operations-summary delivery views.
Design Evaluation and Iterative Improvement
Targeted interface evaluation and iteration revealed that information density, navigation flow, and actionability needed to
be addressed alongside backend reporting correctness.
- Analyst workflows required clearer hierarchy for dense report content.
- Operations workflows required concise, action-oriented summaries.
- Map/context views required better readability and integration with report data.
Iterative Validation with Engineering Evidence
Implementation and testing feedback were used as requirement inputs, not just verification outputs. Integration issues such as
key-format mismatch, text sanitization artifacts, and auth-boundary handling directly informed functional and non-functional
requirements for API stability, reliability, and secure operations.
Core Requirements Identified
- A staged, source-grounded report pipeline producing structured sections, references, and confidence context.
- Dual audience outputs: analyst view for depth and operations view for rapid actionability.
- Protected admin controls for crisis lifecycle, ingestion, and orchestration actions.
- Stable API contracts with resilient parsing and text sanitization across delivery views.
- Traceable persistence of source snapshots and generated report artifacts for reproducibility.
| Method |
Participants |
Data Captured |
How Findings Were Used |
| Operational workflow review |
Project team and partner context documents |
Current analyst pain points: fragmented sources, pressure to deliver quickly, and consistency requirements |
Established core product direction around source-grounded, structured, faster report generation. |
| Architecture and interface decomposition |
Engineering team |
Layer boundaries across frontend, Django API, orchestrator, ingestion, chatbot, and persistence |
Defined API contract, permission, orchestration, and storage requirements. |
| Implementation and integration feedback |
Backend and frontend delivery workstreams |
Real integration issues such as payload key mismatch and text encoding artefacts |
Added requirements for tolerant parsing, sanitisation, and stable retrieval contracts. |
| Targeted UI evaluation and iteration |
Volunteer and analyst role studies |
Navigation clarity, readability, map usability, and actionability gaps |
Refined role-specific interaction requirements and acceptance checks. |
Project Vision and Stakeholders
Vision Statement
Deliver a reliable VSR platform that turns multi-source crisis data into transparent, role-appropriate intelligence through
a structured pipeline, stable service interfaces, and clear analyst and operations outputs.
| Stakeholder |
Need |
Priority |
| IFRC analysts |
Structured, reference-backed analysis with confidence and evidence-gap context. |
High |
| Operations users and volunteers |
Action-oriented summaries and map/context views that support rapid triage decisions. |
High |
| IFRC GO maintainers and admins |
Protected crisis and orchestration controls with clear operational visibility. |
High |
| Engineering and platform maintainers |
Manageable staged pipeline, stable contracts, and traceable persistence across services. |
Medium |
Functional Requirements
Functional requirements are grouped by implementation priority so scope decisions remain explicit across design, engineering,
and evaluation.
MUST HAVE
All generated outputs shall follow the IFRC Analytical Framework so needs, risks, and response capacities are assessed in
a coherent and comparable way across emergencies.
Access to configuration, ingestion, analytical views, and approval actions shall be role-based and aligned with operational
responsibilities.
The platform shall provide distinct analyst and volunteer/operations experiences to reduce overload and support task-focused
interaction under pressure.
Admin users shall be able to execute crisis lifecycle controls including crisis creation, ingestion triggering, report
orchestration, and controlled deletion workflows.
SHOULD HAVE
Data extraction should be driven by approved source links and detailed retrieval instructions, with iterative prompt
refinement to improve consistency and precision.
Prompt configurations should be versioned and periodically assessed to verify they continue to produce relevant and reliable
evidence.
The system should provide comparison of recent report runs so analysts can identify what has changed across updates.
Map and crisis-context utilities should support country resolution and geospatial context views used in operational
interpretation.
COULD HAVE
Conversational access to persisted report outputs could be provided as an optional enhancement once core reporting and
governance workflows are stable.
WON'T HAVE
A mandatory multi-stage verification gate with required human sign-off for every published output
| ID |
Priority |
Requirement |
Acceptance Criteria |
| R-M1 |
Must |
Ingest humanitarian data from configured sources and generate structured crisis reports with sections, references, confidence, and evidence-gap outputs. |
For a selected crisis, the pipeline persists report artefacts and they are retrievable through report endpoints. |
| R-M2 |
Must |
Expose dual delivery views from the same report run: analyst depth view and operations-focused summary view. |
Dashboard routes and API consumers can load both views for the same metric/property context. |
| R-M3 |
Must |
Provide protected admin workflows for crisis creation, ingestion triggers, orchestrator runs, and deletion actions. |
Admin-only endpoints are permission-guarded and return expected responses; unauthorized access is rejected. |
| R-S1 |
Should |
Expose map and crisis-context utilities for country resolution and geospatial overlays. |
Map routes can fetch country-linked context and render available layer data through dedicated endpoints. |
| R-S2 |
Should |
Provide comparative insight across report runs through metadata and "What's New" style retrieval. |
At least two report runs for a crisis can be compared through existing report retrieval interfaces. |
| R-C1 |
Could |
Offer conversational access to persisted report content through a separate chatbot service. |
Chatbot responses remain aligned with stored report artefacts rather than ad-hoc generation outside pipeline outputs. |
| R-W1 |
Won't |
Fully automated decision publication with no human-admin oversight for crisis lifecycle operations. |
Admin-triggered and permission-guarded controls remain required for ingestion and orchestration actions. |
Non-Functional Requirements
These requirements define the quality baseline for performance, reliability, usability, cost envelope, and maintainability.
MUST HAVE
The platform shall remain usable at 500 kbps or higher, load emergency summary and key metrics within five seconds on a
standard 3G-level connection, and keep common interactions below two seconds.
Core functionality shall maintain 99.9% uptime during active emergencies and degrade gracefully when a non-critical
component or single data source fails.
A first-time user in a high-stress scenario shall be able to find critical information such as summary and affected areas
within 30 seconds.
SHOULD HAVE
The architecture should support up to 500 concurrent users during major emergencies without significant degradation of core
response workflows.
End-to-end report generation should complete within 15 minutes for the agreed benchmark run profile.
The system should maintain modular stage boundaries and stable API contracts so debugging and incremental extension remain
manageable.
COULD HAVE
Benchmark runs could be constrained to a budget envelope of approximately 1,000,000 input tokens and 30,000 output tokens
on GPT-4o as a cost-control requirement.
WON'T HAVE
Offline caching and offline search are not included as mandatory non-functional requirements in this iteration.
| ID |
Priority |
Category |
Requirement |
Verification |
| NF-M1 |
Must |
Performance and responsiveness |
Long-running ingestion and orchestrator requests must not block the web UI. |
Trigger endpoints return accepted responses and complete asynchronously while UI remains responsive. |
| NF-M2 |
Must |
Security and access control |
Admin actions must be protected with role checks, session auth, and CSRF-safe request flow. |
Permission tests confirm admin-only endpoints are inaccessible to unauthorized users. |
| NF-M3 |
Must |
Reliability and data integrity |
Generated outputs must remain parseable and robust against key-format variance and text encoding artefacts. |
Regression checks pass for sanitisation and tolerant parsing across historical and newly generated outputs. |
| NF-S1 |
Should |
Maintainability |
Pipeline stages and API contracts should stay modular and explicit for debugging and iterative extension. |
Stage-level components and endpoint groups remain independently testable with clear boundaries. |
| NF-S2 |
Should |
Generation performance |
For each orchestrator report run, end-to-end generation time should be recorded from trigger to report availability.
|
Execute an orchestrator run for a selected crisis/metric/property and log start and completion timestamps; pass when
run duration is captured and reported.
|
| NF-C2 |
Could |
Token usage budget (cost proxy) |
A benchmark report run on GPT-4o should remain within an expected envelope of approximately 1,000,000 input tokens and
30,000 output tokens.
|
Validate token counts and cost from Azure Foundry usage/cost metrics for benchmark runs.
|
| NF-C1 |
Could |
Deployment portability |
Services should remain deployable as separable frontend and backend components. |
Deployment scripts and configuration support independent service rollout and update cycles. |
Personas and Use Cases
How the Personas Were Created
Persona creation was grounded in the HCI evaluation cycle and converted observed behavior into role-specific requirement
priorities. The scenario basis was a simulated high-pressure Myanmar earthquake response context with one BRCS volunteer
user and one IFRC information analyst. Timed observation and structured questionnaires were used to capture friction points
and workflow needs, and these findings were synthesized into two personas representing analyst-depth and
operations-actionability needs. The persona outputs were then mapped to use cases and final functional/non-functional priorities.
Persona Context for Requirements
The two personas represent the primary user groups identified during HCI evaluation. Persona 1 captures analyst needs for
structured, source-grounded information and confidence context, while Persona 2 captures operations needs for concise,
actionable outputs and faster navigation.
Persona 1
Figure 1: Persona 1 represents an analyst user who needs structured, source-grounded information and
confidence context to prepare reliable crisis briefings under time pressure.
Persona 2
Figure 2: Persona 2 represents an operations-facing user who prioritizes concise, actionable outputs and
rapid navigation so response actions can be triaged quickly.
Primary Use Case Contexts
The Virtual Situation Room is used across three core operational contexts: analytical reporting, operational action planning,
and protected platform administration.
Analyst reporting workflow
Analysts access the dashboard to review generated sections, references, metadata, confidence indicators, and changes between
report runs. The goal is to transform multi-source evidence into a structured, briefable crisis assessment.
Operations coordination workflow
Operations users access the operations-facing summary and map-linked context to prioritize immediate actions. This use case
emphasizes speed, clarity, and relevance over deep analytical detail.
Administrative control workflow
Admin users create and manage crisis records, trigger ingestion and report orchestration, and monitor asynchronous job status.
This keeps lifecycle control protected while enabling predictable report refresh and recovery workflows.
| Use Case ID |
Actor |
Description |
Related Requirements |
| UC-01 |
Analyst |
Retrieve crisis analysis, references, metadata, and confidence context for report briefings. |
Framework-based analysis; prompt quality process; report-run comparison; maintainable stage/API boundaries. |
| UC-02 |
Operations user |
Consume operations-focused summaries and map-linked context to prioritize immediate response actions. |
Role-specific experiences; map/context utilities; low-latency interaction and rapid information discovery. |
| UC-03 |
Admin |
Create crisis events, trigger ingestion/orchestration, and monitor job status through protected workflows. |
Role-based access control; admin lifecycle controls; high availability and graceful degradation. |
| UC-04 |
Any authenticated consumer |
Query persisted report outputs consistently across dashboard, detail, and chatbot delivery interfaces. |
Stable retrieval outputs; modular contracts; optional chatbot as could-have enhancement. |