Abstract  —  State  universities  have  work  units  that  are interrelated  with  business  processes  from  one  unit  to  another  and the  main  business  process  is  the  academic  business  process  which covers  the  entire  student  lecture  process.  Academic  information system  serves  help  the  work  of  users  to  achieve  the  goals  that  are done  in  the  academic  field  by  utilizing  information  technology.  In developing the system, it is necessary to analyze the requirements of the  system  which  produces  practical  documentation,  namely  the Software  Requirement  Specification  (SRS).  SRS  is  an  official document  containing  what  must  be  implemented  in  the  system. UNSRAT already has an academic information system but does not yet have the original SRS document. The purpose of this research is to  create  SRS  documentation  so  that  it  becomes  a  reference  for developers  in  developing  the  system.  This  research  methodology refers  to  the  combined  concept  of  SRS  documentation,  namely IEEE,  ACM,  and  KOMINFO.  This  research  produces  software requirement  specification  documentation  from  the  academic information  system  of  Sam  Ratulangi  University  based  on  3 standard templates IEEE, ACM, and KOMINFO.
Keywords — Academic  Information  System;  ACM;  IEEE; KOMINFO; Software Requirement Specification.
Abstrak  —  Perguruan  tinggi  negeri  memiliki  unit  kerja  yang saling  terkait  proses  bisnisnya  dari  unit  satu  dengan  unit  yang lain  dan  proses  bisnis  yang  utama  ialah  proses  bisnis  akademik yang  meliputi  seluruh  proses  perkuliahan  mahasiswa.  Sistem informasi  akademik  berfungsi  untuk  membantu  pekerjaan  para pengguna  mencapai  tujuan  yang  dikerjakan  dalam  bidang akademik  dengan  memanfaatkan  teknologi  informasi.  Dalam pengembangan  sistem  tersebut  dibutuhkan  analisis  terhadap kebutuhan  dari  sistem  yang  menghasilkan  dokumentasi  yang praktis  yaitu Software  Requirement  Specification (SRS).  SRS merupakan  dokumen  resmi  berisi  apa  yang  harus  diterapkan dalam  sistem.  UNSRAT  sudah  memiliki  sistem  informasi akademik  namun  belum  memiliki  dokumen  SRS  yang original . Tujuan penelitian ini untuk membuat dokumentasi SRS sehingga menjadi  acuan developer dalam  mengembangkan  sistem. Metodologi  penelitian  ini  mengacu  pada  gabungan  konsep dokumentasi SRS yaitu IEEE, ACM, dan KOMINFO. Penelitian ini menghasilkan dokumentasi software requirement specification dari  sistem  informasi  akademik  Universitas  Sam  Ratulangi dengan  menggunakan  3  standar  template  IEEE,  ACM,  dan KOMINFO.
Kata  kunci —  ACM;  IEEE;  KOMINFO;  Sistem  Informasi Akademik; Software Requirement Specification .

## I. P ENDAHULUAN
Perguruan  tinggi  negeri  memiliki  unit  kerja  yang  saling terkait proses bisnisnya dari satu unit dengan yang lain, seperti unit  keuangan,  sumber  daya  manusia,  kemahasiswaan, perpustakaan,  manajemen  sarana  dan  prasarana,  dan sebagainya.  Dalam  memenuhi  kebutuhan  yang  sesuai  dengan unit, maka diperlukan sebuah sistem yang dapat menghasilkan informasi  yang  akurat  dan  transparan  serta  membuat  proses lebih  mudah  dilakukan.  Dari  banyaknya  proses  bisnis  di seluruh  universitas,  yang  paling  penting  ialah  proses  bisnis akademik.  Proses  bisnis  akademik  dimulai  dari  proses pendaftaran, belajar mengajar, sampai proses kelulusan. Untuk menjalankan  proses-proses  tersebut  maka  diperlukan  sebuah sistem  informasi  akademik  sehinga  dapat  mempermudah proses saat dilakukan [1].
Sistem  informasi  akademik  berfungsi  untuk  membantu pekerjaan para pengguna mencapai tujuan aktifitas yang akan mereka kerjakan dalam bidang akademik. Dalam mengembangkan  sebuah  software  ada  beberapa  tahapan umum  yang  harus  dilalui  yaitu planning , analisis , design , coding , testing ,  dan  implementasi.  Pada  tahap  analisis, developer melakukan  analisa  terhadap  kebutuhan software yang  akan  dibuat  berdasarkan  data  maupun  informasi  yang diperoleh.  Dalam  proses  analisa  ini,  akan  dihasilkan  sebuah dokumentasi yang disebut Software Requirement Specification (SRS).  SRS  adalah  dokumen  resmi  berisi  apa  yang  harus diterapkan oleh developer dalam software yang akan dibangun [2].
Universitas  Sam  Ratulangi  Manado  (UNSRAT)  sudah memiliki sebuah sistem informasi manajemen akademik untuk pelaksanaan administrasi pendidikan, dengan output dokumen berupa KRS (kartu rencana studi), KHS (kartu hasil studi), dan Transkrip nilai dan sistem informasi lain yang dibutuhkan [3]. Namun UNSRAT belum memiliki dokumen template software requirement  specification yang original ,  maka  dari  itu  tujuan dari penelitian ini untuk membuat dokumen template original software requirement specification UNSRAT dengan menggabungkan template dari  IEEE,  ACM,  dan  KOMINFO maupun  melakukan  wawancara.  Penelitian  ini  menggunakan metode  penelitian  kualitatif  yang  sering  disebut  metode naturalistik  karena  penelitian tidak  mengganggu  keadaan  dari sistem informasi akademik yang sedang berjalan [4].

## Software Requirement Specification Academic Information System of Sam Ratulangi University
Software Requirement Specification Sistem Informasi Akademik Universitas Sam Ratulangi
Christina Rawis 1) , Stanley D. S. Karouw 2) , Sherwin R. U. A. Sompie 3)
Dept. of Electrical Engineering, Sam Ratulangi University Manado, Kampus Bahu St., 95115, Indonesia E-mail: ch.rawis11@gmail.com 1) , stanley.karouw@unsrat.ac.id 2) , aldo@unsrat.ac.id 3 )
Received: 26 May 2021; revised: 2 July 2021; accepted: 2 July 2021

## A. Penelitian Terkait
1) Penelitian oleh Kharisma Dharma Pertiwi, dan Yudhi Kurniawan.  2016.  Spesifikasi  Kebutuhan  Perangkat Lunak  Sistem  Informasi  Akademik  Universitas  Ma Chung  Malang.  Penelitian  ini  membuat  sebuah dokumentasi  SRS  dari  sistem  informasi  akademik Universitas  Ma  Chung  sesuai  kebutuhan  dan  perilaku user dengan mengikuti standar internasional ISO/IE/IEEE 29148-2911. Perbedaannya penelitian ini dibuat karena sistem belum berjalan secara efisien dan efektif [1].
2) Penelitian  oleh  Yudhi  Kurniawan,  dan  Yuswanto. 2019. Software  Requirement Sistem  Informasi Akuntansi  Berbasis  Akrual  Sesuai  Dengan  Standar Akuntansi Pemerintahan (SAP). Penelitian ini bertujuan membuat software requirement specification dari  sistem  informasi  akuntansi  pemerintah  daerah yang mematuhi standard IEEE 830-1998 yang berbasis akrual [5].
3) Penelitian  oleh  Nur  Hadi  Waryanto.  2012. Software Requirements  Specification Sinapra  Berbasis  Sistem Informasi  Terpadu.  Penelitian  ini  membuat software requirements  specification SINAPRA  sebagai  acuan teknis untuk developer dalam mengembangkan sistem dengan menggunakan model WSU-TC CptS 322 [6].
4) Penelitian  oleh  Khurin  In  Noviarani,  dan  Farid Sukman.  2019. Software  Requirement  Specification Untuk Aplikasi Rekomendasi Ijin Penelitian. Penelitian ini membuat software requirement specification dari  aplikasi  rekomendasi  ijin  penelitian sehingga  dapat  membantu  dan  mempercepat  proses pelayanan dalam  proses  penerbitan  surat  rekomendasi [7].

## B. Sistem Informasi Akademik
Menurut  Restama  ,  sistem  informasi  akademik  merupakan aplikasi atau website yang dibuat untuk memenuhi kebutuhan akademik  dari  para  penggunanya  yang  tersedia  dalam  segala bentuk informasi yang dapat diakses kapanpun dan dimanapun melalui internet [8].
Bisa  ditarik  kesimpulan  bahwa  sistem  informasi  akademik adalah  aplikasi  atau website yang  memberikan  informasi berupa  data  yang  berhubungan  dengan  aktivitas  akademik yang bisa diakses menggunakan internet.

## C. Software Requirement Specification
Menurut Sommerville , Software Requirement Specification adalah  dokumen  resmi  berisi  apa  yang  harus  diterapkan  oleh developer dalam software yang dibangun. Software requirement specification adalah dokumen spesifikasi kebutuhan  dari  sebuah  aplikasi  yang  akan  dibangun.  Dengan adanya dokumen ini lebih memudahkan para developer dalam membangun sebuah software [2].
Software  requirement  specification bersifat modifiable ,
yang berarti struktur dan gaya SRS dapat dimodifikasi selama struktur yang ada dibuat lebih mudah, dibuat sepenuhnya dan perubahan  dilakukan  secara  konsisten.  SRS  yang  telah dimodifikasi biasanya harus:
1. Dibuat  secara  teratur  sehingga  mudah  digunakan (biasanya  menggunakan table  of  content , index ,  dan explicit cross referencing ) 2. Tidak berlebihan
3. Menyatakan requirement secara  terpisah  atau  tidak tercampur dengan requirement yang lain.
Redundancy bukanlah  sebuah  kesalahan,  namun  dapat menyebabkan  kesalahan  yaitu  ketidakkonsistenan  SRS.  Jika redundancy dibutuhkan,  pembuat  SRS  harus  menyertakan cross references untuk membuatnya dapat dimodifikasi [9].

## D. CD (Context Diagram)
Context diagram atau CD yaitu diagram yang menggambarkan sistem secara keseluruhan dengan penggambaran  semua external  entity dan  aliran  data  untuk input -proses- output dapat terlihat jelas.
Context  diagram hanya  menggunakan  3  simbol  yaitu simbol external  entity ,  simbol data  flow ,  dan  simbol process [10].

## E. DFD (Data Flow Diagram)
Data  flow  diagram atau  diagram  arus  data  merupakan gambaran  simbol-simbol  yang  menunjukkan  suatu  model aliran  informasi  atau  proses  data  dari  sistem  yang  bergerak dari input ke output maupun  tempat  penyimpanan  data.  DFD digambarkan dalam bentuk hirarki, yang dimulai dari level 0. Level 0 menggambarkan sistem secara menyeluruh sedangkan level  berikutnya  menggambarkan  proses  dari  level  0  secara detail .  Dalam  DFD  terdapat  4  simbol  yang  mempunyai fungsinya masing-masing, yaitu:
1) External Entity atau biasa disebut Terminator, yaitu yang berada  diluar  sistem  tetapi  memiliki  interaksi  dengan  sistem. Terminator  terbagi  atas  2  jenis  yaitu:  Terminator  Sumber, yaitu  yang  menjadi  sumber;  dan  Terminator  Tujuan,  yaitu yang  menjadi  tujuan  data.  Terminator  dalam  DFD  berupa orang, sekelompok orang, organisasi, dan sebagainya.
2) Process (proses),  digunakan  untuk  mengolah  data yang  akan  berubah  dari input menjadi output .  Proses mempunyai  nama  yang  akan  menjelaskan  kegiatan  apa yang sedang/akan dilakukan.
3) Data  Store ,  digunakan  untuk  menunjukkan  tempat penyimpanan data.
4) Data  Flow ,  berupa  anak  panah  yang  menunjukkan  arah dari data masukan ataupun proses dari sistem [11].

## F. UML (Unified Modelling Language)
Unified  Modelling  Language adalah  sebuah  model  untuk memvisualisasikan  perancangan  dan  hasil  analisa  dari  sebuah sistem [12].

## II. M ETODE

## A. Waktu dan Tempat Penelitian
Penelitian  ini  dilakukan  di  Universitas  Sam  Ratulangi, Fakultas  Teknik,  Jurusan  Elektro,  Program  Studi  Teknik Informatika.  Penelitian  ini dilaksanakan  mulai  bulan  Februari 2020 sampai Mei 2021.

## B. Kerangka Penelitian
Dalam  kerangka  penelitian  menunjukkan  tentang  apa  saja tahapan yang akan dilakukan dalam penelitian ini. Pada tabel I dituliskan  apa  saja  masukan,  proses,  dan  keluaran  yang  akan dicapai dalam penelitian ini.

## C. Teknik Pengambilan Data

## 1) Studi Literatur
Studi  literature  dilakukan  untuk  mendapatkan template SRS  menurut  standar  yang  ditetapkan  oleh
IEEE, ACM, dan KOMINFO.
2) Kuesioner
Kuesioner disebarkan kepada developer sistem. Sifat SRS yang modifiable , maka kuesioner dilakukan dengan tujuan  memisahkan template apa  saja  yang  akan digunakan  dan  yang  tidak  akan  digunakan  dalam dokumentasi  sehingga  tidak  ada  komponen template yang  memiliki  maksud  yang  sama  dalam  1  dokumen SRS.  Kuesioner  tersebut  berisi  tentang  identitas developer dan template hasil gabungan.

## Teknik Analisa Kuesioner
Dalam  penelitian  ini  untuk  menghitung  hasil  dari kuesioner menggunakan skala likert. Dengan persamaan (1)  :
* T Pn (1)
TABEL I. KERANGKA PENELITIAN
Mengacu  pada  persamaan  (1)  dimana  T  adalah  total jumlah  responden  dan  Pn  adalah  pilihan  angka  skor likert.
Berikut interval penilaian dari hasil perhitungan: Indeks 0% - 19.99%    : Sangat Tidak Perlu Indeks 20% - 39.99%    : Tidak Perlu Indeks 40% - 59.99%    : Mungkin Perlu Indeks 60% - 79.99%    : Perlu Indeks 80% - 100%     : Sangat Perlu
3) Wawancara Wawancara dilakukan kepada developer mengenai isi dari dokumen SRS.

## D. Model Penelitian
Dapat dilihat dalam tabel II, penelitian menggunakan model template dari gabungan 3 sumber yaitu dari IEEE, ACM, dan KEMKOMINFO.  Penggabungan template dilakukan  untuk menghindari template yang sama dan menambahkan template yang tidak ada pada sumber yang lain.
Model  penelitian  ini  memiliki  7  bagian  besar  hasil gabungan dari ke 3 sumber template sebelumnya.
TABEL II.
MODEL PENELITIAN

## III. H ASIL DAN P EMBAHASAN
Hasil  yang  diperoleh  dari  penelitian  ini  adalah  dokumen Software  Requirement  Specification  original dari  Sistem Informasi Akademik UNSRAT. Tahapan pembuatan dokumen SRS sebagai berikut:
A. Hasil Template Dari Pembagian Kuesioner
Hasil template dari   pembagian   kuesioner   kepada   9 developer diatas  sebagai  berikut:  1)  Halaman Cover ;  2) Introduction yang  terdiri  dari Purpose , Scope , Definitions , Acronyms , and  Abbreviations , References ,  dan Overview ;  3) Overall  Description yang  terdiri  dari Product  Perspective , Product  Functions , User  Characteristic , Constraints ,  dan Apportioning Of Requirements ; 4) Specific Requirements yang terdiri  dari External  Interfaces , Functions , Logical  Database , Design  Constraints , Software  System  Attributes , Additional Comments ;  5)  Kebutuhan  Non  Fungsional;  6) Supporting Information yang terdiri dari Table Of Contents And Index dan Appendixes .

## B. Hasil Dokumen Software Requirement Specification Sistem Informasi Akademik UNSRAT
Gambar  1  menunjukan  tentang  daftar  isi  dari  dokumen SRS.
1) Introduction
a. Purpose
Dokumen  ini  berisikan  penjelasan  mengenai spesifikasi kebutuhan perangkat lunak (SKPL) atau biasa disebut software  requirement  specification (SRS). Tujuan  dari  dokumen  SRS  ini  adalah  memberikan gambaran  yang  spesifik  dari  kebutuhan software yang dalam  hal  ini  adalah  sistem  informasi  akademik UNSRAT.  Spesifikasi-spesifikasi  yang  termasuk  dalam dokumen  ini  adalah  perangkat  keras,  perangkat  lunak, maupun  hal-hal  non  fungsional,  serta  memberikan penjelasan  mengenai  pengembangan software maupun fungsi  dari software ini.  Pembuatan  dokumen  ini ditujukan kepada developer yang  akan mengembangkan software ini untuk kedepannya.
b. Scope
Nama software dari  Sistem  Informasi  Akademik UNSRAT adalah Inspire . Sistem dapat membantu proses akademik  dalam  perkuliahan  di  Universitas  Sam Ratulangi.  Keuntungan  dari software ini  yaitu  kegiatan akademik bisa dilakukan secara online dalam 1 aplikasi, dengan tampilan yang user friendly , dan lebih responsive dari aplikasi yang sebelumnya.

## c. Definitions, Acronyms, and Abbreviations
Singkatan  dan  kepanjangan  adalah  sebagai  berikut IEEE  ( Institute  of  Electrical  and  Electronics Engineer ); ACM ( Association for Computing Machinery ); KOMINFO ( Komunikasi dan Informatika );
Gambar 1. Table Of Contents
SRS  (Software  Requirements  Specification);  SIA (Sistem  Informasi  Akademik);  UNSRAT  (Universitas Sam    Ratulangi);  KHS  (Kartu  Hasil  Studi);  KRS (Kartu  Rencana  Studi);  RDBMS  (Relational  Data Base  Management  System);  DO  (Drop  Out);  SKS (Satuan  Kredit  Semester);  NIM  (Nomor  Induk Mahasiswa);  IPK  (Indeks  Prestasi  Kumulatif);  IPS (Indeks Prestasi Semester).
d. References
1. IEEE  Std  830-1998.  (1998).  IEEE Recommended Practice  for  Software  Requirement  Spesifications.  New York:  The  Institute  of  Electrical  and  Electronics Engineers, Inc .
2. Goshen  S,  Torbochkin  L,  dan  Lainnya.  (2009). Software Requirements Spesification for ACM SIGSOFT Newsletter  Content  Management  &  Generation  System- II.
3. KOMINFO
e. Overview
Urutan  penulisan  dalam  SRS  ini  diurutkan menurut fitur yang ada. Penulisan dokumen SRS ini dimulai dari introduction berisikan tentang gambaran dari SRS, yang terbagi  atas purpose , scope , definitions acronyms and abbreviations , references ,  dan overview .  Selanjutnya adalah overall  description berisikan  tentang  penjelasan umum  tentang  SIA,  yang  terbagi  atas product perspective , product  functions , user  characteristic ,
constraints , dan apportioning of requirements . Kemudian  dilanjutkan  oleh specific  requirement berisikan  tentang  penjelasan  fitur  dengan  rinci,  yang terbagi  atas external  interfaces , functions , logical database , design constraint , software  system  attributes , dan additional  comment .  Bagian  yang  terakhir  ada supporting information yang berisikan appendixes .
2) Overall Description a. Product Perspective A. User Interfaces
1. Tampilan Awal
Gambar  2  menunjukkan  tampilan  awal  dari aplikasi  sistem  informasi  akademik  UNSRAT. Pengguna  mengisi  username  dan  password  lalu tekan login untuk masuk pada sistem.
2. Tampilan Beranda
Gambar  3  menunjukkan  tampilan  beranda  dari aplikasi  sistem  informasi  akademik  UNSRAT. Pengguna  memilih  fitur  yang  akan  digunakan. Kebutuhan  tentang  akademik terdapat  pada  menu perkuliahan yang ada pada sidebar.
3. Tampilan KRS
Gambar  4  menunjukkan  tampilan  KRS  dari aplikasi  sistem  informasi  akademik  UNSRAT. Dokumen  dibuat  tidak  pada  saat  mengontrak matakuliah  sehingga  pilihan  untuk  mengontrak matakuliah  tidak  ditampilkan.  Pada  bagian  kanan tampilan  terdapat button berwarna  biru  untuk mencetak KRS.
4. Tampilan Persetujuan KRS
Gambar  5  menunjukkan  tampilan  persetujuan KRS  dosen  dari  sistem  informasi  akademik UNSRAT.  Dokumen  dibuat  tidak  pada  saat mengontrak  matakuliah  sehingga  status  KRS  sudah disetujui oleh dosen pembimbing.
5. Tampilan KHS
Gambar  6  menunjukkan  tampilan  KHS  dari aplikasi  sistem  informasi  akademik  UNSRAT. Pengguna  memilih  semester  untuk  dapat  melihat KHS pada semester yang dipilih. Pada bagian kanan tampilan  terdapat button berwarna  biru  untuk mencetak KHS.
6. Tampilan Pengisian KHS
Gambar  7  menunjukkan  tampilan  pengisian  nilai untuk dosen dari aplikasi sistem informasi akademik UNSRAT.  Pengguna  memilih  semester  untuk melihat  kelas  yang  diampu  dan  mengisi  nilai  pada kelas yang dipilih. Pada bagian kanan tampilan
Gambar 2. Tampilan Awal
Gambar 3. Tampilan Beranda
Gambar 4. Tampilan KRS
terdapat button Aksi  yang  berisi  Isi  Nilai,  DPNA Excel, Buat DPNA PDF, dan TTD DPNA.
Gambar 8 menunjukkan tampilan pengisian nilai.
Setelah pengguna mengklik button isi nilai dibagian kanan matakuliah, sistem akan menunjukkan nama- nama  mahasiswa  yang  mengontrak  kelas  tersebut dan dosen bisa mengisi nilai mahasiswa.
7. Tampilan Transkrip
Gambar  9  menunjukkan  tampilan  transkrip  dari aplikasi sistem  informasi  akademik  UNSRAT.  Pada bagian  kanan  tampilan  terdapat button berwarna biru untuk mencetak transkrip.

## B. Hardware Interfaces
1. Server, merupakan  suatu  sistem  komputer  yang berfungsi  sebagai  tempat  penyimpanan  data. Data  yang  disimpan  pada  server  berupa informasi  dan  beragam  jenis  dokumen  yang kompleks.
Gambar 5. Tampilan Persetujuan KRS
Gambar 6. Tampilan KHS
Gambar 7. Tampilan Pengisian Nilai
2. PC  atau personal  computer, berfungsi  sebagai tempat  menginput  dan  mengolah  data  sehingga menghasilkan output berupa data/informasi yang sesuai perintah.
C. Software Interfaces Software interfaces adalah sebagai berikut:
1. Sistem Informasi (server) Nama    : Linux
Sumber  : linux.org
2. Bahasa Pemrograman
Nama    :PHP dengan plugin CodeIgniter
Sumber  : codeigniter.com
3. RDBMS
Nama    : MySQLyog
Sumber  : webyog.com
4. Server
Nama    : Apache
Sumber  : apache.org
Gambar 8. Tampilan Pengisian Nilai 2
Gambar 9. Tampilan Transkrip
Gambar 10. Communication Interfaces

## D. Communication Interfaces
Gambar  10  menunjukkan  alur  komunikasi  sistem informasi  akademik.  Pertama user melakukan request pada server lalu server memberikan feedback sesuai dengan  permintaan  dari user .  Tapi  ketika  permintaan yang  diminta user disimpan  di database maka server akan  me request ke database dan database akan memberikan feedback kepada user sesuai dengan yang direquest.
b. Product Functions
1. FE-KRS  :  Fungsi  dari  KRS  yaitu  kontrak matakuliah secara online .
2. FE-KHS  :  Fungsi  dari  KHS  yaitu  menunjukkan nilai semester tertentu.
3. FE-Transkrip: Fungsi   dari Transkrip  yaitu menunjukkan nilai keseluruhan dari semester 1.
c. User Characteristic
Dalam  sistem  informasi  akademik,  karakteristik masing-masing user sebagai berikut:
1. Dosen, mampu memanfaatkan alat elektronik ( handphone dan  laptop)  untuk  mengakses  SIA.
Dosen  juga  dapat  melakukan  pengisian  nilai  dan dapat menyetujui susunan matakuliah yang akan
Gambar 11. Context Diagram
Gambar 12. DFD Level 0
dikontrak oleh mahasiswa.
2. Mahasiswa, mampu memanfaatkan alat elektronik ( handphone dan  laptop)  untuk  mengakses  SIA. Mahasiswa  juga  dapat  melihat  matakuliah, melihat nilai persemester, mengontrak matakuliah,  dan  mencetak  KRS,  KHS,  maupun Transkrip.

## d. Constraints
Batasan-batasan dalam  pengembangan   sistem informasi akademik sebagai berikut:
1. Untuk  mengakses  sistem  informasi  akademik harus terkoneksi internet.
2. Hanya untuk proses akademik UNSRAT.
3. Pencetakkan KRS dibatasi hanya bisa mencetak   KRS  pada  semester  yang  sedang dijalani.
4. User dibatasi  hanya  bisa  melihat  akunnya sendiri.
e. Data Flow Diagram (DFD)
Gambar  11  menunjukkan context  diagram dari sistem  informasi  akademik  UNSRAT  untuk  fitur  KRS, KHS,  dan  Transkrip.  Terdapat  2 external  entity atau terminator dalam sistem ini yaitu Dosen dan Mahasiswa. Interaksi  mahasiswa  ke  sistem  yaitu  memberikan  data diri  dan  mengontrak  KRS,  lalu  sistem  meneruskan permintaan persetujuan KRS dari mahasiswa bimbingan ke  dosen  pembimbing.  Lalu  sistem  akan  mengirimkan output KRS  kepada  mahasiswa.  Kemudian  sistem mengirimkan  daftar  mahasiswa  yang  mengontrak matakuliah yang diampu oleh dosen.
Gambar 13. DFD Level 1 Proses 1
Gambar 14.  DFD Level 1 Proses 2
Lalu sistem memberikan output KRS kepada mahasiswa yang  telah  disetujui  oleh  dosen  pembimbing  akademik. Pada  akhir  semester  dosen  akan  meng input nilai  dari mahasiswa  yang  telah  mengikuti  perkuliahan  sesuai daftar  mahasiswa  yang  mengontrak  matakuliah  dari dosen  tersebut.  Kemudian  sistem  akan  memberikan output kepada mahasiswa dalam bentuk KHS untuk nilai persemester dan Transkrip untuk nilai semua matakuliah tiap semester.
Gambar  12  menunjukkan  DFD  Level  0  yang berarti  rincian  dari  diagram  sebelumnya.  Masih  dengan external  entity yang  sama  yaitu  Dosen  dan  Mahasiswa. Pada  level  0  ini  terdapat  3  proses  yaitu  1.0  Kontrak Matakuliah,  2.0 Input Nilai  Mahasiswa,  3.0  Laporan Nilai  Semua  Semester.  Pada  proses  yang  pertama ditunjukkan  mahasiswa  mengontrak  matakuliah  setelah itu,  mahasiswa  diwajibkan  mengirim  permintaan persetujuan  KRS  untuk  dosen  pembimbing  akademik. Lalu  sistem  akan  mengirimkan  permintaan  tersebut  ke dosen  pembimbing  akademik  dari  mahasiswa.  Ketika KRS  disetujui,  maka  sistem  akan  menyimpan  KRS  dari mahasiswa di data store dan sistem mengirim output
Gambar 15.  DFD Level 1 Proses 3
Gambar 16. Activity Diagram Login
berupa  KRS  kepada  mahasiswa.  Pada  proses  yang kedua,  sistem  mengirim  daftar  mahasiswa  yang mengontrak matakuliah yang diampu dosen tersebut dan dosen meng input nilai dari mahasiswa yang telah selesai mengikuti  perkuliahan  selama  1  semester.  Dan  sistem menyimpan nilai mahasiswa yang telah di input tersebut, lalu  sistem  mengirim output kepada  mahasiswa  berupa KHS. Pada proses yang terakhir, sistem mengambil nilai mahasiswa  yang  ada  pada data  store lalu  mengirim output kepada  mahasiswa  berupa  Transkrip  yang  berisi nilai  mahasiswa  dari  semester  awal  sampai  semester yang terbaru.
Gambar  13  menunjukkan  diagram  rinci  dari proses  1  yang  ada  pada  DFD  level  0.  Proses  yang terdapat  dalam  diagram  ini  yaitu  1.1  Matakuliah  Yang Dikontrak,  1.2  Persetujuan  KRS,  1.3  Cetak  KRS.  Pada proses  yang  pertama  yaitu  matakuliah  yang  dikontrak, sama  seperti  diagram  yang  sebelumnya,  mahasiswa memilih matakuliah yang akan dikontrak sesuai semester lalu  mengirim  permintaan  persetujuan  kepada  dosen pembimbing      akademik.  Dosen  menyetujui  lalu  KRS tersebut tersimpan dalam data store dan mahasiswa akan menerima output dari proses tersebut berupa KRS. Pada proses  yang  terakhir  yaitu  cetak  KRS.  Sistem  akan mengambil  KRS  milik  mahasiswa  yang  tersimpan  di data store dan mencetaknya.
Gambar 14 menunjukkan diagram rinci dari proses
Gambar 17. Activity Diagram Mengontrak Matakuliah
2  yang  ada  pada  DFD  level  0.  Pada  diagram  rinci  ini terdapat 3 proses yaitu 2.1 Laporan Nilai Mahasiswa, 2.2 Kartu Hasil Studi, 2.3 Cetak KHS. Proses yang pertama, dosen  meng input nilai  mahasiswa  ke  sistem,  dan  akan disimpan  di data  store nilai  mahasiswa  yang  telah di input .  Pada  proses  selanjutnya,  nilai  mahasiswa  akan diambil  dari data  store dan  sistem  akan    mengirim output kepada  mahasiswa  berupa  Kartu  Hasil  Studi. Proses  yang  terakhir  yaitu  cetak  KHS,  nilai  mahasiswa diambil dari data store dan dicetak.
Gambar  15  menunjukkan  diagram  rinci  dari proses 3 yang ada pada DFD level 0. Pada diagram rinci ini  terdapat  2  proses  yaitu  3.1  Lihat  Transkrip  dan  3.2 Cetak  Transkrip.  Pada  proses  yang  pertama,  nilai mahasiswa diambil dari data store Nilai Mahasiswa dan sistem  memberikan output berupa  Transkrip  yang  berisi semua nilai matakuliah tiap semester kepada mahasiswa. Dan  proses  yang  terakhir,  nilai  mahasiswa  diambil  dari data store berupa Transkrip dan mencetaknya.
f. Apportioning Of Requirements
1. Aplikasi diharapkan dapat dikembangkan ke mobile application.
2. Penambahan fitur untuk pengajuan DO.
3. Penambahan fitur untuk disertasi pendidikan S3.
3) Specific Requirements
a. KRS A. External Interfaces
a. To-Be System
1. Login
Pada gambar 16 ditunjukkan proses bagaimana
Gambar 18. Activity Diagram Persetujuan KRS
user  login ke  dalam  sistem.  Pertama user melakukan login dengan  mengetikkan username dan password kemudian  sistem mengecek apakah akun  sudah  terdaftar  atau  tidak,  jika  Tidak  maka sistem  akan  mengembalikan  ke  halaman Login .
Jika Ya maka  sistem akan menampilkan halaman Beranda.
2. Mengontrak Matakuliah (Mahasiswa) Pada  gambar  17  ditunjukkan proses  bagaimana user akan  mengontrak        matakuliah.    Pertama
user membuka        menu  perkuliahan  kemudian user membuka  menu  KRS,  lalu  sistem  akan menampilkan  tampilan  KRS.  User  memilih matakuliah yang akan dikontrak. Setelah memilih matakuliah,  sistem  akan  memberitahu  apabila kelas  yang  diambil  dalam  keadaan  penuh  atau tidak.  Jika  kelas  yang  dipilih  dalam  keadaan penuh,  maka sistem akan mengembalikan user ke tampilan  awal  KRS  agar user bisa  memilih  kelas yang  lain  yang  tidak  penuh.  Apabila  kelas  yang diambil  tidak  penuh,  sistem  akan  menunjukkan tampilan  KRS  dengan  matakuliah  yang  telah dikontrak. Setelah itu user akan mengajukan KRS ke dosen pembimbing akademik. Jika dosen tidak menyetujui  KRS,  maka user akan    mengontrak kembali.  Apabila  dosen  menyetujui  KRS,  maka proses mengontrak matakuliah sudah selesai.
3. Persetujuan KRS (Dosen)
Pada  gambar  18  ditunjukkan  proses  persetujuan KRS    dari  dosen  untuk  mahasiswa  bimbingan akademik.  Pertama  dosen  membuka  menu bimbingan akademik. Setelah itu membuka menu persetujuan  KRS.  Sistem  akan  menunjukkan daftar mahasiswa bimbingan akademik dari dosen tersebut.  Dosen  dapat  melihat,  menyetujui  atau menolak  KRS  yang  diajukan  oleh  mahasiswa. Feedback yang  diberikan  oleh  dosen  akan direkam didalam sistem kemudian akan diterus-
Gambar 19. Activity Diagram Logout
Gambar  20. Activity Diagram Melihat KHS
-kan ke mahasiswa. 4. Logout Pada gambar 19 ditunjukkan proses bagaimana user  logout dari  sistem.  Pertama user akan  menekan  button  untuk  logout.  Sistem  akan mengeluarkan  akun user dari  dalam  sistem. Kemudian  sistem  akan  menampilkan  tampilan login.
B. Function
1. Sistem  harus  bisa  menampilkan  kelas  yang dikontrak mahasiswa
2. Sistem  harus  bisa  menyimpan  yang  dikontrak oleh mahasiswa
3. Sistem  harus  bisa  membuat  KRS  bisa  diajukan kepada  dosen  pembimbing  akademik  dan dicetak.
4. Sistem  harus  bisa  membuat  KRS  bisa  diubah selama  belum  melakukan  pengajuan  kepada dosen pembimbing
C. Logical Database Logical database dari KRS berisi: NIM
Gambar  21. Activity Diagram Input Nilai
Gambar  22. Activity Diagram Melihat Transkrip
mahasiswa,  Daftar nama mahasiswa yang mengontrak  kelas, Angkatan, Program studi, Data persetujuan  dosen,  Daftar  matakuliah,  Daftar kelas,  Jumlah  SKS,  Sifat  matakuliah  wajib  atau pilihan,  Tanggal  pengajuan  KRS,    Semester, Nama  dosen  pembimbing  akademik,  Nilai  IP semester  sebelumnya,  Nama  dosen  pengampu matakuliah.
b. KHS A. External Interfaces
a. To-Be System
1. Melihat KHS (Mahasiswa)
Pada gambar 20 ditunjukkan proses bagaimana  mahasiswa  melihat  KHS.  Pertama mahasiswa  membuka  menu  perkuliahan,  dan membuka menu KHS. Sistem akan menampilkan tampilan  menu  KHS.  Setelah  itu  mahasiswa memilih semester untuk melihat KHS, kemudian sistem  menampilkan  KHS  berdasarkan  semester yang dipilih.
2. Input Nilai (Dosen)
Pada gambar 21 ditunjukkan proses bagaimana  dosen  melakukan  input  nilai  KHS. Pertama dosen membuka menu perkuliahan, dan membuka  menu  pengisian  nilai.  Sistem  akan menampilkan  tampilan  pengisian  nilai.  Setelah itu dosen memilih semester. Jika dosen memiliki hak  untuk  mengisi  nilai  maka  sistem  akan menampilkan  tampilan  untuk  mengisi  nilai.  Jika tidak  maka  dosen  hanya  bisa  melihat  nilai  kelas matakuliah  yang  diampu.  Kemudian  dosen menekan button unduh DPNA, jika DPNA sudah dibuat  maka  sistem  akan  menampilkan  tampilan untuk  melihat  DPNA.  Jika  DPNA  belum  dibuat maka  sistem  menampilkan  tampilan  untuk membuat DPNA. Kemudian dosen bisa menandatangani  DPNA  dengan  menekan  button TTD  DPNA  dan  sistem  akan  menampilkan QRCode  untuk  TTD.  Setelah  itu  dosen  dapat mengunduh DPNA.

## B. Function
1. Sistem harus bisa menampilkan nilai
2. Sistem harus bisa mencetak KHS
3. Sistem harus bisa memilih semester
4. Untuk  dosen,  sistem  harus  bisa  melihat  nilai mahasiswa  yang  mengontrak  kelas  yang diampu

## C. Logical Database
Logical  database dari  KHS  berisi:  NIM
mahasiswa, Nama mahasiswa, Angkatan, Program  studi,  Semester,  Nama  matakuliah, Jumlah SKS, Nilai matakuliah, Kode kelas, Nilai IPK, Nilai IPS.
c. Transkrip
A. External Interfaces
a. To-Be System
1. Melihat Transkrip (Mahasiswa) Pada gambar 22 ditunjukkan proses bagaimana mahasiswa melihat Transkrip. Pertama mahasiswa membuka menu perkuliahan, dan membuka menu Transkrip.  Sistem  akan  menampilkan  tampilan Transkrip.

## B. Functions
1. Sistem  harus  bisa  menunjukkan  matakuliah perbaikan
2. Sistem  harus  bisa  menampilkan  nilai  dari
seluruh semester 3. Sistem harus bisa mencetak transkrip
4. Sistem  harus  bisa  mengambil  nilai matakuliah dari KHS

## C. Logical Database
Logical  database dari  Transkrip  berisi:  NIM mahasiswa,  Nama  mahasiswa,  Tempat  /  tanggal lahir, Program studi, Semester, Nama matakuliah, Jumlah  SKS,  Kode  kelas,  Nilai  IPK,  Total  SKS, Total SKS lulus.

## D. Design Constraint
a. Standard Compliance
1. Panduan Akademik

## E. Software System Attributes
a. Reliability Sistem hanya
bisa beroperasi jika terkoneksikan  dengan  internet. Traffic SIA berbeda  dengan traffic sistem  yang  lain  sehingga traffic dari  sistem  lain  tidak  akan  mengganggu jalannya SIA.
b. Availability Kesiapan  dari  SIA  saat  digunakan  adalah baik, responsive  sesuai  dengan  permintaan user .
Apabila  akan  melakukan  transaksi  data  dengan database ,  maka  proses  akan  dilakukan  dengan cara  antrian  dimana  yang  paling  pertama me request akan  dijawab  dahulu,  kemudian  yang lain mengikuti.
c. Security
Keamanan  dari  sistem  baik,  namun  masih bergantung pada user . Apabila user menggunakan password yang  lemah  maka  mudah  diretas, namun  jika  menggunakan password yang  sesuai dengan ketentuan maka akan sulit diretas.
d. Maintainability
Struktur  yang  sederhana  membuat  sistem mudah  untuk  dipelihara  sehingga  saat  akan melakukan  pengembangan  penambahan  modular tidak akan mengganggu modul yang sudah ada.
e. Portability
Sistem  yang  berbasis website membuat  sistem dapat diakses dari mana saja dengan menggunakan link.
F. Additional Comments
1. User Behavior
Format-format  yang  sudah  ditentukan  oleh sistem harus ditaati oleh user , karena sistem tidak akan  menerima  format  lain  selain  yang  sudah ditentukan.
4) Supporting Information
a. Appendixes
1. Panduan untuk menggunakan fitur KRS pada inspire :
https://inspire.unsrat.ac.id/panduan/portal/krs/
2. Panduan untuk menggunakan fitur KHS pada inspire : https://inspire.unsrat.ac.id/panduan/portal/khs/
3. Panduan untuk menggunakan fitur Transkrip pada inspire : https://inspire.unsrat.ac.id/panduan/portal/transkri p/
4. Panduan untuk menggunakan fitur Pengisian Nilai untuk  dosen  pada inspire : https://inspire.unsrat.ac.id/panduan/portal/pengisi an-nilai/
5. Panduan untuk menggunakan fitur Persetujuan KRS untuk dosen pada inspire : https://inspire.unsrat.ac.id/panduan/portal/persetuj uan-krs/

## IV. K ESIMPULAN DAN S ARAN
Berdasarkan  penelitian  yang  telah  dilakukan,  maka  dapat ditarik kesimpulan bahwa dokumentasi Software Requirement Specification Sistem  Informasi  Akademik  UNSRAT  dibuat menggunakan  gabungan  dari  3 template SRS.  Beberapa komponen template dari  IEEE,  ACM,  dan  KOMINFO memiliki  maksud  yang  sama  namun  hanya  menggunakan bahasa  yang  berbeda.  Dokumen  SRS  juga  dapat  digunakan untuk keperluan pengembangan selanjutnya oleh developer . Setelah  melakukan  penelitian  ini  juga,  maka  yang  dapat disarankan  untuk  penelitian  selanjutnya  yaitu  SRS  dapat dikembangkan  lagi  dengan  mencakup  seluruh  fitur  yang  ada didalam sistem.

## V. K UTIPAN
[1] K. D. Pertiwi and Y. Kurniawan, “Spesifikasi Kebutuhan Perangkat
Lunak Sistem Informasi Akademik Universitas Ma Chung Malang,” Simetris  J. Tek. Mesin, Elektro dan Ilmu Komput. , vol. 7, no. 2, p. 627, 2016, doi: 10.24176/simet.v7i2.775.
[2] I. Sommerville, SOFTWARE ENGINEERING 9th ed. , 9th ed. 2011.
[3]
Universitas Sam Ratulangi, PERATURAN REKTOR UNIVERSITAS SAM RATULANGI Nomor 01 Tahun 2019 . Manado, 2019.
[4] Prof.  Dr.  Sugiyono, Metode  Penelitian  Pendidikan  (Pendekatan Kuantitatif, Kualitatif, dan R&D) . Bandung: ALFABETA, 2015.
[5] Y.  Kurniawan  and  -  Yuswanto,  “Pengembangan  Program  Sistem Informasi  Akuntansi  Berbasis  Akrual  Sesuai  dengan  Standar Akuntansi  Pemerintahan  (SAP),” J.  Nas.  Pendidik.  Tek.  Inform. , vol. 5, no. 1, p. 40, 2016, doi: 10.23887/janapati.v5i1.9916.
[6] N.  H.  Waryanto,  “Software  Requirements  Specification  SINAPRA Berbasis Sistem Informasi Terpadu,” vol. 7, p. 10, 2012.
[7] K. Noviariani and F. Sukmana, “Software requirement spesification untuk  aplikasi  rekomendasi  ijin  penelitian,”  vol.  04,  pp.  148–155,
2019.
[8] A.  S.  Dzihni,  R.  Andreswari,  and  M.  A.  Hasibuan,  “Business process analysis and academic information system audit of helpdesk application  using  genetic  algorithms  a  process  mining  approach,” Procedia  Comput.  Sci. ,  vol.  161,  pp.  903–909,  2019,  doi: 10.1016/j.procs.2019.11.198.
[9] S. Engineering and S. Committee, IEEE recommended practice for software requirements specifications , vol. 1998. 2011.
[10] Rita  Afyenni,  “Perancangan  Data  Flow  Diagram  untuk  Sistem Informasi  Sekolah  (Studi  Kasus  Pada  SMA  Pembangunan Laboratorium UNP),” Teknoif , vol. 2, no. 1, pp. 35–39, 2014.
[11] B. A. Herlambang and V. A. V. Setyawati, “Perancangan Data Flow Diagram  Sistem  Pakar  Penentuan  Kebutuhan  Gizi  Bagi  Individu Normal  Berbasis  Web,” J.  Inform.  UPGRIS ,  vol.  1,  pp.  78–85, 2015.
[12] Haviluddin,  “Memahami  Penggunaan  UML  (  Unified  Modelling Language  ),” Memahami  Pengguna.  UML  (Unified  Model.  Lang. ,
vol. 6, no. 1, pp. 1–15, 2011, [Online].
Available: https://informatikamulawarman.files.wordpress.com/2011/10/01- jurnal-informatika-mulawarman-feb-2011.pdf.
Christina Rawis , lahir di Kota Manado, Sulawesi  Utara  pada  tanggal  11  April 1998.  Penulis  tinggal  di  Pinaling  jaga III, Kecamatan Amurang
Timur,
Kabupaten  Minahasa  Selatan,  Sulawesi Utara.
Penulis mulai menempuh pendidikan  di  TK  GMIM  Syalom Sentrum  Amurang  (2003).  Setelah  itu penulis  melanjutkan  pendidikan  di  SD GMIM  Amurang  (2004-2010).  Setelah itu penulis melanjutkan pendidikan di SMP Negeri 1 Amurang (2010-2013).  Kemudian  penulis  melanjutkan  pendidikan  di SMA  Kristen  2  Binsus  Tomohon  (2013-2016).  Setelah  itu  di tahun 2016, penulis melanjutkan pendidikan di Program Studi S-1  Teknik  Informatika,  Jurusan  Teknik  Elektro,  Fakultas Teknik,  Universitas  Sam  Ratulangi  Manado.  Selama perkuliahan  penulis  tergabung  dalam  organisasi-organisasi kemahasiswaan  yaitu  Himpunan  Mahasiswa  Elektro  (HME). Penulis  menyelesaikan  studi  di  Program  Studi  Teknik Informatika,  Jurusan  Teknik  Elektro,  Fakultas  Teknik, Universitas Sam Ratulangi Manado dengan menyandang gelar Sarjana Komputer (S. Kom).