System Requirements Document

1. Introduction

This document specifies the requirements for a web-based School Academic Information System (Sistem Informasi Akademik / SIA) to be developed for SMP Negeri 22 Makassar, a public junior high school in Makassar, South Sulawesi, Indonesia.

The system addresses the current condition at SMP Negeri 22 Makassar, where academic management is still largely conventional (manual): subject schedules are managed manually, causing teachers and students to be late in the teaching and learning process, and student grade data is still entered manually into books. The school currently only operates a web-based e-raport application to support teacher assessment, and the broader SIA has not yet been developed. Because the number of students at SMP Negeri 22 Makassar increases with every intake, academic management has become increasingly dense, and teachers require an online data storage medium so that data is safe in a database.

The purpose of the system is to (a) make it easier for educators to manage student biodata, subject data, and grades, and (b) allow students to access subject schedules, grades, activities, and biodata at any time and from any location, provided internet access is available.

Theoretical basis (as referenced in the source material):

• An information system is software used to process a collection of data from an institution or organization and to output it as information; it supports communication channels, transaction processing, signalling, and decision-making information.
• An academic information system is a system that provides information services related to academic data.
• Web-based technology enables institutions to obtain and provide needed information quickly, efficiently, and accurately, and can serve both internal school management and external promotion of the school's achievements.
• Developing this system was carried out using a prototyping model and evaluated against the ISO/IEC 25010 software quality standard.

2. System Overview

The delivered product is a web-based academic information system for a single school (SMP Negeri 22 Makassar). Its two primary functional audiences are educators (teachers) and students (peserta didik).

Core outcomes required of the system:

• Educators can manage student biodata, subject data, and student grades, and can see schedules and activities.
• Students can access their subject schedules, grades, activities, and biodata online at any time and from anywhere with internet access.
• Academic data is stored online in a database so that the data is safe and is no longer entered manually in books.
• School profile, student activities, and teacher content are published, supporting internal management and external promotion of the school.

Development and evaluation approach (as specified by the source):

• The system is built using the prototyping development model, comprising seven steps: (1) requirements analysis and data collection, (2) building the prototype, (3) prototype evaluation, (4) system coding, (5) system testing, (6) system evaluation, and (7) using the system. The prototype is evaluated by teachers, and if it does not match their expectations it is revised by repeating the previous steps.
• The system is evaluated against the ISO/IEC 25010 quality standard across eight aspects: Functional Suitability, Performance Efficiency, Reliability, Usability, Portability, Security, Maintainability, and Compatibility.
• Data analysis uses Guttman and Likert scales.

3. Functional Requirements

3.1 Academic Data Management (Educators)

• As a teacher (educator), I want to manage student biodata online, so that student personal records are accurate, centralized, and no longer held only in manual books.
• As a teacher (educator), I want to manage subject data (mata pelajaran), so that the list of subjects is maintained correctly in the system.
• As a teacher (educator), I want to input and manage student grades (nilai peserta didik), so that assessment results are recorded electronically.
• As a teacher (educator), I want to store student grade data in an online database, so that the data is safe and easily retrievable.
• As a teacher (educator), I want to manage subject schedules (jadwal mata pelajaran), so that schedules are no longer produced conventionally and teaching/learning begins on time.
• As a teacher (educator), I want to view student activities (kegiatan peserta didik), so that I can monitor student participation in school activities.
• As a teacher (educator), I want to view subject schedules, activities, and student grades, so that I have a single reference for the teaching and learning process.
• As a teacher (educator), I want to record student assessment through a web-based e-raport, so that the existing grading workflow is preserved and supported.
• As a teacher (educator), I want to manage both academic and non-academic administration data, so that school record-keeping is comprehensive.
• As an academic staff member managing the student academic field, I want to manage student academic data, so that administrative academic records are maintained accurately.

3.2 Academic Information Access (Students)

• As a student (peserta didik), I want to view the subject schedule (jadwal mata pelajaran), so that I know when and where my classes take place.
• As a student (peserta didik), I want to view my grades (nilai), so that I can track my academic progress.
• As a student (peserta didik), I want to view school activities (kegiatan), so that I stay informed about events in which I participate.
• As a student (peserta didik), I want to view my biodata, so that I can verify that my personal data is correct.
• As a student (peserta didik), I want to access this information anytime and anywhere as long as internet access is available, so that I am not restricted to on-site access.

3.3 School Content and Promotion

• As a visitor from the external community, I want to view the school profile (profil sekolah), so that I can learn about SMP Negeri 22 Makassar.
• As a visitor from the external community, I want to view student activities content (konten kegiatan siswa), so that I can see school life and participation.
• As a visitor from the external community, I want to view teacher content (konten guru), so that I can learn about the school's educators.
• As a school representative, I want to publish the school's achievements, so that the system can serve as a media for promoting and showcasing the school to the wider community.

3.4 Monitoring

• As a teacher or school leader, I want to monitor the development of students and teachers in the teaching and learning process, so that academic progress can be observed and evaluated.

3.5 Development Lifecycle Requirements (Prototyping Model)

• As a system developer, I want to perform requirements analysis and data collection (analisis kebutuhan dan pengumpulan data sistem), so that the system is built to exactly match the needs at SMP Negeri 22 Makassar and functions correctly there.
• As a system developer, I want to perform requirements analysis (analisis kebutuhan), so that the development process is on target and the system is well-functioning at SMP Negeri 22 Makassar.
• As a system developer, I want to build the prototype (membangun prototype), so that a tangible draft of the academic information system can be reviewed before full coding.
• As a system developer, I want to build the prototyping model (membangun prototyping), so that the iterative development cycle is established in accordance with the seven-step prototyping procedure.
• As a system developer, I want to perform prototype evaluation (evaluasi prototyping), so that teachers can confirm whether the built prototype already matches their wishes.
• As a teacher (evaluator), I want to evaluate the prototype and, if it does not match my expectations, have it revised by repeating the earlier prototyping steps, so that the resulting system meets the school's real needs.
• As a system developer, I want to proceed to the next step only when the prototype has been approved, so that the agreed design is the one that gets implemented.
• As a system developer, I want to perform system coding (pengkodean sistem), so that the agreed design is translated into the web programming language.
• As a system developer, I want to code the system using JavaScript, PHP, and MySQL, so that the web application runs with the specified stack.
• As a system developer, I want to perform system testing (menguji sistem), so that defects and non-functioning features are detected before deployment.
• As a system developer, I want to perform system evaluation (evaluasi sistem), so that the system's conformity to ISO/IEC 25010 is confirmed.
• As a system user at the school, I want to use the system (menggunakan sistem), so that academic information management benefits teachers and students in daily practice.

3.6 Institutional Context and Data Storage Requirements

• As a school that currently only has a web-based e-raport application, I want the e-raport capability retained while the new SIA is introduced, so that existing assessment support is not lost.
• As a school whose student academic data is still input manually into books, I want an online storage medium, so that the data is safe within a database.
• As a school where the SIA has not yet been developed and the current school information system contains only profile, student activities, and teacher content, I want a developed academic information system, so that the school has a functioning SIA.
• As a school in Makassar, South Sulawesi, whose student intake increases at every admission, I want academic management to scale with the growing student population, so that increasingly dense academic administration remains manageable.
• As a school whose academic management and grade input remain conventional, I want electronic management of schedules and grades, so that teachers and students are not delayed in the teaching and learning process.
• As a prospective parent considering SMP Negeri 22 Makassar, I want the school to be presented professionally through its information system, so that the school remains an attractive choice for my child's continued education.
• As a school that must meet a feasibility standard, I want the system to satisfy the ISO/IEC 25010 standard, so that the SIA is declared feasible for use at SMP Negeri 22 Makassar.

3.7 Usability and Instrument Measurement Requirements

• As a usability respondent (student), I want to answer the USE Questionnaire on a Likert scale, so that usability can be measured.
• As a usability respondent, I want to respond "Sangat setuju" (strongly agree, score 5), so that the highest usability rating can be recorded.
• As a usability respondent, I want to respond "Setuju" (agree, score 4), so that a positive usability rating can be recorded.
• As a usability respondent, I want to respond "Kurang setuju" (less agree, score 3), so that a neutral usability rating can be recorded.
• As a usability respondent, I want to respond "Tidak setuju" (disagree, score 2), so that a negative usability rating can be recorded.
• As a usability respondent, I want to respond "Sangat tidak setuju" (strongly disagree, score 1), so that the lowest usability rating can be recorded.
• As an evaluator, I want the classification of scores according to the Likert scale (Klafikasi skor menurut skala likert), so that each respondent answer maps to a defined score category.
• As an evaluator, I want the scores to be calculated using a conversion formula into a percentage score, so that a criterion for interpreting usability results is obtained.
• As an evaluator, I want a summary of respondent assessments on the usability aspect (Rangkuman Penilaian Responden pada Aspek Usability), so that the usability outcome can be interpreted.
• As an instrument validator, I want the research instrument validated across the aspects of instructions, content, and language using the Likert scale, so that the instruments used are valid.
• As a system expert assessor, I want to assess each of the 77 developed functions using the Guttman scale ("Ya"/"Tidak"), so that functional suitability can be determined.

3.8 Quality Evaluation Requirements (ISO/IEC 25010)

• As an evaluator, I want to evaluate functional suitability using the Guttman measurement scale, so that every function is confirmed to run as expected without error.
• As an evaluator, I want to evaluate the "kategori baik" (good category) outcome of functional suitability, so that the system's functional fitness is documented.
• As an evaluator, I want to evaluate usability using the USE Questionnaire and Likert scale, so that usability is confirmed in the very good (sangat baik) category.
• As an evaluator, I want to evaluate performance efficiency using GTmetrix with a page response time under 10 seconds, so that the performance efficiency result is in the good category.
• As an evaluator, I want to evaluate portability through cross-browser testing on desktop and iOS mobile using BrowserStack, so that the portability result is in the good category.
• As an evaluator, I want to evaluate security using ImmuniWeb, so that the security grade and threat level to data or information are documented.
• As an evaluator, I want to confirm the system meets the ISO/IEC 25010 testing standard across all eight aspects, so that the resulting academic information system is proven feasible for use at SMP Negeri 22 Makassar.

4. User Personas

• Teacher / Educator (Guru / Pendidik) — The primary internal operator and prototype evaluator. Manages student biodata, subjects, grades, and schedules; views activities; and confirms whether the built prototype matches the school's wishes. Needs efficient data entry and a reliable online store for grades.
• Student / Learner (Peserta Didik / Siswa) — The primary information consumer and usability respondent. Views subject schedules, grades, activities, and biodata, at any time and anywhere with internet access.
• Academic Staff (Staff Pengelola Bidang Akademik) — Manages student academic and non-academic administration data.
• School Principal (Kepala Sekolah) — Requirement source and oversight stakeholder; provides direction on the academic management model and confirms the conventional model currently in use. (Grouped with leadership monitoring; no separate administration module is implied by the source.)
• System Developer / Evaluator — Performs requirements analysis, builds and evaluates the prototype, codes, tests, evaluates, and deploys the system, and runs the ISO/IEC 25010 evaluations. (Active development-and-evaluation persona, not an end-user of the academic features.)
• Expert Validators / System Experts — Validate the research instruments and assess the developed functions using the Guttman scale.

Integration systems (existing e-raport) are treated as a system interaction, and the external community (including prospective parents) is treated as an outbound recipient of published school profile, activity, and achievement content — not as an authenticated persona.

5. Core User Flows

Flow A — Teacher manages academic data

1. Teacher accesses the web-based SIA.
2. Teacher selects the academic data area (biodata, subjects, grades, or schedules).
3. Teacher creates or updates the relevant record.
4. The record is saved to the online database and becomes available to the appropriate audience.
5. Teacher views the updated schedule/grade/activity information.

Flow B — Student accesses academic information

1. Student accesses the SIA with internet access, from any location.
2. Student opens the schedule, grades, activities, or biodata view.
3. The system displays the current information from the database.

Flow C — Prototype development and evaluation

1. Requirements are analyzed and data is collected from the school.
2. A prototype is built (membangun prototype / prototyping).
3. Teachers evaluate the prototype: if it matches expectations, development proceeds; if not, the prototype is revised by repeating the earlier steps.
4. The system is coded using the web programming stack (JavaScript, PHP, MySQL).
5. The system is tested and evaluated against ISO/IEC 25010.
6. The system is deployed and used at the school (menggunakan sistem).

Flow D — Community promotion view

1. An external community member reaches the school's web content.
2. The system displays the school profile, student activities, and teacher content.
3. The school's achievements are showcased publicly.

Flow E — Evaluation and scoring

1. A Likert-scale questionnaire (USE Questionnaire) is distributed to respondents, and each answer is assigned a score (5 to 1) according to the classification of scores.
2. Scores are converted to a percentage using the conversion formula.
3. Usability results are summarized in a summary of respondent assessments.
4. Functional suitability functions are assessed by system experts using Guttman ("Ya"/"Tidak").
5. Performance efficiency is measured with GTmetrix, portability with BrowserStack, and security with ImmuniWeb.

6. Visuals, Colors and Theme

Not specified by the source. Deriving restrained defaults appropriate to a public junior-high-school academic system:

• Theme: Clean, institutional, and legible — an "academic ledger" aesthetic prioritizing tables and readable data over decoration, reflecting the need for fast, low-friction access to schedules and grades.
• Palette: A calm, trustworthy institutional base — a primary blue (evoking education and reliability) with white/neutral gray surfaces for data tables, and a single accent color reserved for calls to action and highlights. Status cues for grades and schedules use restrained, accessible tones.
• Typography: A highly legible sans-serif for body and tabular data, with clearly differentiated headings, so that schedules and grade records remain readable on desktop and iOS mobile.
• Layout: Simple navigation separating the public school-content pages from the educator data-management and student information views.

7. Signature Design Concept

The signature concept is "The School Ledger Online" — the system presents academic information as a clear, dependable, always-available record. Schedules and grades are treated as first-class, tabular objects that load quickly and read cleanly, reinforcing the shift from manual bookkeeping to a safe, online database that students can trust at any time and from anywhere.

8. Interaction Model & Motion Direction

• Interaction model: Task-oriented and form/table driven. Educators work through structured data entry and editing; students work through direct look-up of schedules, grades, activities, and biodata. Navigation is shallow so that key information is reachable in a few steps.
• Motion direction: Minimal and functional. Motion is used only to confirm state changes (save confirmation, view transitions, load feedback). No decorative animation that would slow page response, consistent with the requirement that pages respond in under 10 seconds to preserve user attention.

9. Non-Functional Requirements

Requirements are expressed per the ISO/IEC 25010 quality characteristics used to evaluate the system:

• Functional Suitability — Every function designed for the system must run as expected without error. Feature completeness is measured as X = I/P, where I = number of features implemented and P = number of features designed; the result should approach 1 (0 ≤ x ≤ 1) to indicate that nearly all designed features were successfully implemented. Verified using the Guttman scale ("Ya"/"Tidak") across the 77 developed functions, assessed by two system experts. Result category: kategori baik (good).
• Usability — Measured using the USE Questionnaire with a Likert scale (5 = strongly agree / sangat setuju; 4 = agree / setuju; 3 = less agree / kurang setuju; 2 = disagree / tidak setuju; 1 = strongly disagree / sangat tidak setuju), with the percentage score = (total score / maximum score) × 100%. Tested with 30 student respondents and 30 question items. Result: 99%, category very good (sangat baik).
• Performance Efficiency — Page response time must be less than 10 seconds to maintain user attention (Nielsen). Measured using GTmetrix across all pages, chosen for stable and consistent analysis. Result category: good.
• Portability — The system must remain operable without loss of original functionality across different operating-system environments. Tested via cross-browser testing on desktop and iOS mobile using BrowserStack; across the three tested devices all indicators passed (score 3 / all successful). Result category: good.
• Security — Evaluated using ImmuniWeb (https://www.immuniweb.com/websec/). Achieved grade C, indicating that the threat to data or information security remains very low.
• Reliability — The system must operate consistently as an evaluated ISO/IEC 25010 characteristic.
• Maintainability — The system must be maintainable, supported by the prototyping development and coding process.
• Compatibility — The system must operate correctly across the different browser and device environments in which it is used.

Overall, the system must be proven feasible for use at SMP Negeri 22 Makassar in accordance with the ISO 25010 feasibility standard.

10. Tech Stack

As specified in the source material:

• Delivery: Web-based application (accessed via browser).
• Programming language (client-side): JavaScript.
• Server-side language: PHP (Hypertext Preprocessor).
• Database management system: MySQL.
• Evaluation/testing tools: GTmetrix (performance efficiency), BrowserStack (portability / cross-browser), ImmuniWeb WebSec (security), USE Questionnaire (usability), and Guttman/Likert scales (data analysis).

11. Assumptions and Constraints

• The system is developed specifically for a single institution, SMP Negeri 22 Makassar, and is declared feasible for use there.
• Development follows the prototyping model with seven steps: requirements analysis and data collection, building the prototype, prototype evaluation, system coding, system testing, system evaluation, and using the system. The prototype is revised iteratively until teachers approve it.
• Requirements were derived from interviews and online question-and-answer with teachers and students — notably with the school principal (Dr. Hj. Salmah, S.Pd., M.Pd.), who stated the academic management model already uses an internet-based (website) information system, and a biology teacher/academic staff member (Ibu Nurhaedah Majid, S.Pd.), who stated the school currently only has a web-based e-raport application and that some student academic data is still input manually in books.
• Some students did not yet know how to correctly use the school's information system, which motivated a simplified, accessible design.
• The school currently relies only on a web-based e-raport application, and some student academic data is still entered manually in books; this system complements and improves on that condition.
• SMP Negeri 22 Makassar is one of the state schools in Makassar, located in South Sulawesi, and is a chosen destination for prospective parents; its student intake increases at every admission, making academic management increasingly dense.
• Research data was collected using instrument techniques and analyzed using Guttman and Likert scales.
• Research instruments were validated by two expert validators (Andi Akram Muh. Risal, S.Pd., M.Kom. and Fhatiah Adiba, S.Pd., M.CS.) using 10 statements across 3 aspects: instructions (petunjuk), content (isi), and language (bahasa), answered with the Likert scale.
• Functional Suitability testing comprised 77 questions covering each developed function, assessed by two system experts using the Guttman scale.
• Usability testing was conducted with 30 student respondents using the USE Questionnaire.
• Users require internet access to use the system.
• Conformance is measured against ISO/IEC 25010 across all eight quality aspects.

• SIA (Sistem Informasi Akademik) — Academic Information System; a system providing information services related to academic data.
• SMP Negeri 22 Makassar — The public junior high school in Makassar, South Sulawesi, for which the system is developed.
• Peserta Didik / Siswa — Student / learner.
• Guru / Pendidik — Teacher / educator.
• Mata Pelajaran — Subject / course.
• Jadwal Mata Pelajaran — Subject schedule.
• Nilai — Grades / marks.
• Biodata — Personal data / student profile record.
• E-raport — The existing web-based application used to support teacher assessment of students.
• Analisis Kebutuhan — Requirements analysis; the first step of the prototyping model.
• Membangun Prototype / Prototyping — Building the prototype; the second step of the prototyping model.
• Evaluasi Prototyping — Prototype evaluation; the third step, in which teachers confirm whether the prototype matches their wishes.
• Pengkodean Sistem — System coding; translation of the agreed design into the web programming language.
• Menguji Sistem — System testing; verification of system behavior before deployment.
• Evaluasi Sistem — System evaluation; confirmation of conformity to the quality standard.
• Menggunakan Sistem — Using the system; the final step of the prototyping model.
• Prototyping Model — Iterative development model in which prototypes are built, evaluated by users, revised, coded, tested, and deployed.
• ISO/IEC 25010 — International software quality standard covering Functional Suitability, Performance Efficiency, Reliability, Usability, Portability, Security, Maintainability, and Compatibility.
• Feature Completeness (X = I/P) — Ratio of implemented features (I) to designed features (P), indicating functional suitability.
• Guttman Scale — Measurement scale producing decisive "Ya"/"Tidak" answers, used for functional suitability testing.
• Likert Scale — Measurement scale used for usability and instrument validation scoring; classification of scores: Sangat setuju (5), Setuju (4), Kurang setuju (3), Tidak setuju (2), Sangat tidak setuju (1).
• Kategori Baik — "Good" category; the interpretation band achieved for functional suitability and performance efficiency.
• Persentase Skor — Percentage score = (total score / maximum score) × 100%; the conversion formula used to interpret results.
• USE Questionnaire — Instrument used to measure system usability.
• GTmetrix — Tool used to measure performance efficiency and page response time.
• BrowserStack — Cross-browser testing tool used to measure portability.
• ImmuniWeb WebSec — Security testing service used to measure the system's security grade.