Part 6 · Website and digital platform requirements
National Digital Platform
The operating system of the programme: architecture, six portals, role-permission matrix, security and privacy posture, non-functional requirements, integration feasibility and the phased build plan.
Platform scope and design principles
The national digital platform is not a website with a registration form — it is the operating system of the programme, running the entire lifecycle: institution registries, seat publication, university applications, allocations, student bookings, attendance tracking, completion verification, national dashboards, grievance intake and audit. Seven design principles govern it:
- Whole-lifecycle coverage — every state transition in the seat lifecycle is a platform transaction with an audit record.
- University-books, government-confirms — the booking choreography is enforced in workflow, not policy documents.
- Two languages, low bandwidth — Bangla and English interfaces; core functions usable on entry-level Android devices and slow connections; coordinator functions offline-tolerant with sync.
- No unexplained automated decisions — allocation and matching follow published, configurable rules; every output is explainable and reproducible.
- Privacy by architecture — student records, government records and public dashboards are separated data tiers with different access rules.
- Audit-first — immutable logs for every sensitive action; oversight access without operational edit rights.
- Build for the pilot, scale for the nation — phased build matching the implementation roadmap; no big-bang national deployment.
System architecture
The six portals
National Administration Portal
Institution registry management · verification review · placement-cycle setup · allocation-rule configuration · seat-request approval · national monitoring · complaint escalation · audit access · statistics generation · user and permission administration.
Government Institution Portal
Profile and facility management · seat requests with full specifications · coordinator naming · confirmation of placed students · attendance and progress recording · performance evaluation · completion verification · incident and capacity reporting.
University Portal
Profile management · student-record import and maintenance · eligibility identification · seat-browse and application · allocation tracking · student nomination and booking (with validation) · waiting-list management · progress monitoring · completion review · degree-requirement reports · cost tracking · university-level downloads.
Student Portal
Eligibility view · opportunity browse (university-approved placements) · preference submission · placement detail review · accept/decline within rules · instructions and training access · attendance and progress view · authorized requests and complaints · completion status · certificate download. Students cannot alter official bookings, allocations, attendance records or completion outcomes.
Receiving-Office Coordinator Portal
Assigned-student view · attendance confirmation · task assignment and review · progress recording · evaluation submission · absence and incident reporting · completion confirmation — designed for mixed technical experience, common mobile devices and intermittent connectivity.
Audit & Oversight Portal
Read-analytical access to allocation decisions, booking histories, seat utilization, cancellation patterns, attendance verification, completion records, complaint resolutions and unusual-activity flags — within legal access rules, with no operational edit rights.
Role-permission matrix (extract)
| Function | National admin | Govt office | University | Student | Coordinator | Auditor |
|---|---|---|---|---|---|---|
| Publish seats | approve | create | view | view | — | view |
| Approve seat requests | yes | request | — | — | — | view+reasons |
| Apply for allocation | view | — | yes | — | — | view |
| Nominate / book student | view | confirm | yes | preference only | — | view+log |
| Record attendance | view | view | view | view own | yes | view |
| Verify completion | view | yes | review | view own | input | view+sample |
| Issue certificate | view | — | yes (system-issued) | download | — | verify |
| Allocation rules config | yes | — | — | — | — | view |
| Grievance intake | escalate | respond | respond | file | report | view |
| Audit logs | view own actions | view own | view own | — | — | view all |
Security, privacy and data protection
Bangladesh has no comprehensive data-protection statute in force; a Personal Data Protection framework has been under consideration (status to be verified — the platform is designed to the stricter of CRPD-aligned principles and pending PDP drafts). Controls specified: encryption in transit and at rest; MFA for all administrative and coordinator accounts; least-privilege RBAC with quarterly recertification; immutable audit logs with no operational deletion path; segregated data tiers (public aggregates / institutional data / confidential student records / restricted government records); documented retention and disposal schedules; backup with tested recovery (RPO ≤ 24h, RTO ≤ 8h target); security testing before each phase gate; incident response with breach-notification procedure. Student data are shared with a receiving office strictly on a need-to-place basis, and government records never leave their custodian systems — students work on extracts and non-sensitive registers under MOU.
Non-functional requirements
| Requirement | Target | Reason |
|---|---|---|
| Availability (core booking windows) | 99.5% monthly | Allocation and confirmation windows are hard calendar events |
| Page weight for coordinator app | < 100 KB core views | Upazila-level connectivity realities |
| Offline tolerance (coordinator) | Attendance capture offline, sync on reconnect | Field offices with intermittent connectivity |
| Accessibility | WCAG 2.1 AA | Public-service obligation; CRPD context |
| Localization | Full Bangla + English parity | National programme; field-level usability |
| Concurrent load | 150,000 live placement records (CSV 16); 10× read amplification at peak | S3 scenario steady state |
| Verification latency | QR certificate verification < 2 s | NYSC-fraud lesson: verification must be effortless |
Integrations — feasibility and authorization
| Integration | Feasibility | Authorization dependency | Design posture |
|---|---|---|---|
| University student-information systems | Feasible with standards; heterogeneous estate | University-level agreements | Bulk import + API adapters; no forced single-vendor standard |
| Identity verification (NID-linked) | Technically feasible | Requires explicit legal authorization | Out of baseline; university-attested identity in pilot |
| BANBEIS statistics registers | Feasible | MoE/BANBEIS agreement | Aggregate exchange only |
| Government HR/staffing systems | Partially feasible | Ministry-level; not assumed | Not required for pilot; coordinator certification held in-platform |
| SMS/notification gateway | Feasible | Procurement | Included from PH-1 — placement notices are time-critical |
| e-GP / procurement systems | Not integrated | — | Deliberately excluded: observer-role only, no system access |
Build plan and acceptance criteria
Build phases: MVP (registries, seat lifecycle, applications, allocation, booking — the PH-1 pilot scope) → tracking layer (attendance, tasks, verification, certificates) → analytics layer (dashboards, national statistics, audit workbench) → scale hardening (load, multi-cycle scheduling). Acceptance criteria (extract): end-to-end seat lifecycle test with zero invalid state transitions; allocation runs reproducible from logged rules and seeds; booking validation rejects every prohibited double-booking case; coordinator app completes attendance flows under simulated offline conditions; QR verification works in < 2 s from a printed certificate; audit reconstruction of a randomly chosen placement reproduces every state change with actor, timestamp and reason; Bangla/English parity verified on all citizen-facing screens; WCAG 2.1 AA audit passed; penetration test findings at medium+ severity resolved before gate.
The platform is costed inside the university-funded baseline as an amortized consortium share (UFM-04: BDT 500M–1,000M build+run, per-capita Tk 1,667–3,333 at 300k scale; Tk 5,000–10,000 at entry scale — UFM-20). One-time setup (platform, legal drafting, pilot design, agreements) is Tk 2,000–5,000 crore (UFM-16). Vendor quotations would replace these planning figures in PH-0 procurement (GAP-23).