Requirements framework

Requirements for a production virtual classroom

A server specification is only one line in a virtual-classroom requirements document. A production service must also describe the lesson, the users, the network edge and the team that responds when a class goes wrong.

6 min read Reviewed July 1, 2026 4 primary & community sources

01 Teaching Roles, activities and class formats

02 Technology Browsers, network, media and integrations

03 Governance Identity, privacy, retention and accessibility

04 Operations Monitoring, support, recovery and ownership

A classroom succeeds only when all four requirement sets meet.

Executive brief

What matters

01
Write workload assumptions in concurrent meetings, participants and published media—not registered-user totals.
02
Include accessibility, identity and recording policy as acceptance criteria.
03
Set a measurable support and recovery model before launch.

Describe the teaching workload

Inventory lecture, seminar, tutorial, oral examination and office-hour patterns. For each, record maximum participants, typical webcams, screen sharing, breakout use, duration and whether recording is allowed. Separate peak concurrency from total enrolment. This becomes the basis for sizing and load tests.

Set client and network expectations

Publish supported browsers and mobile limitations, require working microphone permissions and define a pre-class check. The media path needs more than a loading web page: HTTPS, direct UDP where possible and TURN for restrictive networks. Campus and home-network tests should cover the real user population.

Make governance testable

Specify SSO groups, guest access, moderator assignment, retention periods, recording publication, deletion ownership and accessibility. BigBlueButton’s HTML5 client provides broad keyboard and screen-reader support, but the institution must still test its exact course content, integrations and assistive-technology combinations.

Define a service, not an installation

Name owners for platform, identity, LMS, network and classroom support. Monitor host resources and application health, document escalation and reserve maintenance windows. Acceptance should include a representative load test, failover or restore exercise, and an instructor-led pilot—not just a successful login.

Evidence base

Sources and further reading

We prefer project documentation and first-party product guidance. Community links are included where they reveal recurring operational questions rather than establish product guarantees.

Practical answers

Questions teams ask

What is the minimum BigBlueButton server?

Current BigBlueButton 3.0 production guidance starts with a clean Ubuntu 22.04 64-bit host, 8 CPU cores, 16 GB RAM, suitable storage, 250 Mbps symmetric bandwidth and required TCP/UDP reachability.

Is registered-user count useful for sizing?

Only indirectly. Peak concurrent meetings, participants, webcams, screen sharing and recording processing are much more useful.

What should an acceptance test include?

Representative classes, real identity and LMS flows, accessibility checks, restrictive-network clients, recording completion, monitoring alerts and a documented recovery exercise.

What matters

Describe the teaching workload

Set client and network expectations

Make governance testable

Define a service, not an installation

Sources and further reading

Questions teams ask

Related guides and infrastructure

How to size a BigBlueButton server

Planning for concurrent BigBlueButton meetings

BigBlueButton firewall ports and network prerequisites