03 — Modules / Subsystems

There are two sources, and they do not split the system the same way:

Rule: for "what functions exist", use the BA structure. For channels (apps, portal), finance, e-document, AI and integration, the proposal is the only source, and those areas are still open (see §C below and 11-open-questions-and-known-issues.md).

See also 12-use-cases.md. The team's use cases use a third, more detailed taxonomy (35 modules such as ADM, REG, FIN, SCH = scholarships, ATH, SAFE), with a mapping to the codes below. For behaviour (who does what, in which order), the use cases are the primary source.

A. BA module structure (primary)

The draw.io file has two module pages, Sub Module-วิทยาลัย and Sub Module-โรงเรียน, plus an overview page module whose root is "ระบบการจัดการบริหารการศึกษา" and shows only the 8 university modules. (The earlier image combined both branches under "ระบบบริหารข้อมูลภาพรวมทุกหน่วยงานภายใต้ TNSU".) The two branches:

• UNI: ระบบบริหารการศึกษาระดับมหาวิทยาลัย (university level, 17 campuses), 8 modules
• SS: ระบบบริหารโรงเรียนกีฬาและนักเรียนประจำ (sports and boarding schools, 13 schools), 15 modules

The codes UNI-xx and SS-xx (and sub-codes like UNI-04.6) are our convention for referencing these modules in docs, tickets and code. They are not on the BA chart. The chart numbers each branch from 1.

In the source file, UNI 1–6 are green (#d5e8d4) while UNI 7–8 and all SS modules are pink (#f8cecc). The file has no legend, so the meaning is still [unknown] (e.g. agreed vs. draft, or phase). Ask the BA.

UNI — University level

SS — Sports schools and boarding students

\* On the chart these are numbered 8.3, 14.3 and 15.3 a second time (duplicate numbers). We renumbered them to .4 here.

Observations about the BA structure

• Asymmetry between the branches. Sports, dorm, health, nutrition, roll call, leave and discipline exist only under SS. Fees, instructor evaluation and alumni exist only under UNI. The proposal implies both levels share athletes, dorm, finance and the executive dashboard. Whether this asymmetry is intended is [unknown].
• Shared concepts implemented twice. Admission, registry, curriculum, timetable and assessment appear in both branches with different depth (UNI has prerequisites, study plans, registration rounds and GPAX; SS has homerooms, lesson plans and promotion). Design implication [inferred]: shared core entities (person, org unit, academic year/term, course, timetable, assessment) with level-specific rules, rather than two separate systems.
• System-level settings live inside UNI-01 (fees, academic year, user permissions). They probably need to be central for both branches [inferred].
• Requests appear as UNI-03.3 (student requests), UNI-06.7 (grade correction), SS-07 (leave/exit) and SS-14.3 (parent confirmation). A generic request/approval engine fits [inferred].

A2. Organisation structure (BA draw.io page "โครงสร้างหน่วยงานของระบบ")

flowchart TD
  U[มหาวิทยาลัยการกีฬาแห่งชาติ] --> C[วิทยาเขต 1…17]
  U --> S[โรงเรียน 1…13]
  C --> F[คณะ]
  F --> M[สาขา]
  M --> P[หลักสูตร]
  S --> G[ระดับชั้น]
  G --> T[ชนิดกีฬา]

• University branch: campus → faculty → major (สาขา) → curriculum (หลักสูตร). Faculties hang under each campus.
• Sports-school branch: school → grade level (ระดับชั้น) → sport type (ชนิดกีฬา). Sport type sits under the grade level, so a school's students are organised by grade and then by sport.
• This is the org-unit tree for data scoping and permissions (see 13-role-matrix.md).

A3. Curriculum list (BA draw.io page "หลักสูตร")

The real programmes, grouped by degree and faculty. Three faculties offer programmes.

• 9 programmes in total: 5 bachelor's, 2 master's, 2 doctoral. The diagram lists the English and Thai names of the same graduate programme as two lines; they are paired here [inferred].
• Graduate programmes exist, so the use-case module GRAD (ป.โท/ป.เอก) is real scope.
• The faculties in the proposal's mockups (บริหารธุรกิจ, สหเวชศาสตร์) were sample data and are not in this list.
• Not stated: which campuses offer which programmes, and whether some programmes are also offered with a different curriculum year.

A4. BA process flows

The draw.io file has two flows; they are written out in 05-workflows.md (§15 and §16) and rendered in ba-drawio.md.

B. Mapping: proposal subsystems ↔ BA modules

Proposal §6.1 (delivery-scope list) → proposal codes: 1→TNSU-10, 2→TNSU-11, 3→admission in TNSU-01/02, 4→rest of TNSU-01/02, 5→TNSU-03, 6→TNSU-04, 7→TNSU-05, 8→TNSU-06/07/08, 9 and 10→TNSU-09, 11→notifications and AI bot, 12→TNSU-12 plus security.

C. Open scope gaps (to confirm with BA and client)

1. Finance at both levels: payment gateway, receipts, กยศ., scholarships. These are in the proposal but missing from the BA chart.
2. e-Document, e-Signature and DGA.
3. AI analytics and AI bot.
4. Student mobile app and student web portal, and which BA functions they expose.
5. University-level executive dashboard (SS-15 covers schools only, but the mockups show a university-wide dashboard).
6. Athletes, dorms and health for university students.
7. ~~Integration with legacy E-Education~~: not needed. There is no legacy system (confirmed 2026-10-30).
8. Central administration: org units (17 + 13), audit log, cross-unit roles.
9. Meaning of the green/pink colours on the chart.