KEBUTUHAN PERANGKAT LUNAK AKUNTANSI DESA

BERDASARKAN PERMENDAGRI NO 113 TAHUN 2014

Febry Eka Purwiantono (5215201006) & Muhammad Arqam (5215201014)

Falkutas Teknologi Informasi, Program Studi Pascasarjana Sistem Informasi

Institut Teknologi Sepuluh Nopember Surabaya
2015

ABSTRAK

Sistem akuntansi desa merupakan sebuah sistem yang dapat digunakan untuk melakukan
pengelolaan keungan desa secara efisien, efektif dan akuntabilitas. Membuat dan menentukan
kebutuhan perangkat lunak akuntansi desa merupakan sebuah kebutuhan pokok yang harus
dipenuhi dan dilakukan sebelum membuat sistem akuntansi desa. Dengan adanya
Permendagri No 113 Tahun 2014 Tentang Pedoman Pengelolaan Keuangan Desa dapat
menjadi acuan dalam pembuatan dan penentuan kebutuhan perangkat lunak akuntansi desa.
Pengambaran model menggunakan Unified Modeling Language (UML) dapat mempermudah
pembuatan sistem akuntansi desa dikemudian hari, selain itu Unified Modeling Language
(UML) juga dapat membantu penentuan kebutuhan perangkat lunak akuntansi desa yang
benar-benar dibutuhkan. Kebutuhan perangkat lunak akuntansi desa yang didapatkan nanti
berdasarkan analisa Permendagri No 113 Tahun 2014, stakeholder yang ada dan Unified
Modeling Language (UML) yang telah dibuat, sehingga hasilnya bisa akurat dan valid.

Kata Kunci : kebutuhan perangkat lunak, akuntansi desa, pemendagri, unified modeling
language (UML)
1. Pendahuluan

1.1 Latar Belakang

Desa merupakan sebuah institusi legal formal dalam pemerintahan nasional. Hal itu
tergambar dengan adanya kewenangan penuh bagi desa untuk menyelenggarakan rumah
tangganya sendiri. Kewenangan tersebut telah diatur oleh negara dalam beberapa runtutan
konstitusi secara hukum. Dalam Undang-Undang (UU) Nomor 5 Tahun 1979 Tentang
Pemerintahan Desa dan UU Nomor 32 Tahun 2004 Tentang Pemerintahan Daerah, dijelaskan
bahwa desa merupakan kesatuan masyarakat hukum yang berwenang untuk mengurus
kepentingan masyarakatnya sendiri.
Kewenangan untuk mengatur rumah tangga sendiri tersebut termasuk didalamnya
pengelolaan keuangan desa dalam rangka penyelenggaran pemerintahan. Hal itu dipertegas
dengan adanya keharusan untuk menyusun Anggaran Pendapatan Belanja Desa (APBD) yang
dijelaskan dalam Peraturan Menteri Dalam Negeri (Permendagri) No 113 Tahun 2014
Tentang Pedoman Pengelolaan Keuangan Desa. Dengan adanya kewenangan pengelolaan
keuangan tersebut, maka secara hukum Pemerintah Desa wajib untuk melaporkan kinerjanya
kepada Pemerintah dan masyarakat.
Permendagri No 113 Tahun 2014 Tentang Pedoman Pengelolaan Keuangan Desa dapat
dikelola dan dianalisa untuk mendapatkan kebutuhan perangkat lunak yang dapat menunjang
pembuatan sistem akuntansi desa. Sistem akuntansi desa sendiri dibuat untuk memudahkan
penguna dalam pengelolaan, penyusunan dan pembuatan laporan keuangan desa secara
fleksibel. Dengan adanya kebutuhan perangkat lunak akuntansi desa dapat mempercepat
pembuatan sistem akuntansi desa secara komputerisasi yang sebelumnya akuntansi desa
hanya dilakukan secara manual, sehingga pengelolaan keuangan desa dapat dilaksanakan
secara terbuka, efisien, efektif, akuntabilitas dan pasti berdasarkan nilai ekonomi yang ada.

1.2 Rumusan Masalah

Apa yang menjadi prioritas kebutuhan pengguna pada sistem akuntansi desa dan
bagaimana mengambarkan sistem akuntansi desa yang akan dibuat agar user friendly
merupakan rumusan masalah yang harus dipecahkan dalam pembuatan jurnal ini. Dengan
memecahkan rumusan masalah ini akan menjawab kebutuhan pengguna perangkat lunak
yang ada.
1.3 Tujuan

Tujuan dari pembuatan jurnal ini adalah menentukan kebutuhan perangkat lunak untuk
akuntansi desa berdasarkan Permendagri No 113 Tahun 2014 dan mengambarkannya
menggunakan Unified Modeling Language (UML), sehingga dapat memudahkan developer
dalam analisis dan pembuatan sistem akuntansi desa yang sebelumnya dilakukan secara
manual menjadi komputerisasi suatu saat nanti.

1.4 Paper Acuan

Ada 2 paper acuan dalam penelitian ini yaitu junal “User requirements modeling and
analysis of software-intensive system” dan “From use cases to classes: a way of building
object model with UML”. Jurnal “User requirements modeling and analysis of software-
intensive system” karangan dari Michel dos Santos Soaresa, Jos Vrancken dan Alexander
Verbraeckdari Universitas Federal de Uberlandia (Brazil) menjadi pendoman utama dalam
penyusunan jurnal ini. Jurnal ini membahas tentang analisa dan pemodelan kebutuhan
pengguna dari sistem perangkat lunak intensif menggunakan Unified Modeling Language
(UML) dan Systems Modeling Language (SysML), dimana komponen saling berinteraksi
dengan perangkat lunak, sehingga menjadi sebuah komponen yang penting. Sedangkan untuk
jurnal “From use cases to classes: a way of building object model with UML” dikarang oleh
Ying Liang dari Universitas Paisley (Inggris) membahas Unified Modeling Language (UML)
yang digunakan untuk mendesain objek dalam perancangan perangkat lunak. Adapun
Permendagri No 113 Tahun 2014 dijadikan landasan utama untuk analisa dan pembuatan
jurnal ini.

1.5 Metodologi Singkat

Menganalisa Permendagri No 113 Tahun 2014 untuk menemukan stakeholder yang ada
di sana dan mengambarkan tugas masing-masing stakeholder ke dalam Unified Modeling
Language (UML) untuk mendapatkan kebutuhan perangkat lunak akuntansi desa. Unified
Modeling Language (UML) digunakandalam jurnal ini karena Modeling Language (ML)
lainnya tidak selengkap dan semudah Unified Modeling Language (UML) untuk
memahaminya, contohnya Systems Modeling Language (SysML). Unified Modeling
Language (UML) sendiri terdiri dari beberapa diagram seperti Use Case Diagram, Activity
Diagram, Sequence Diagram dan diagram-diagram yang lain, tentunya lebih lengkap dan
sangat cocok untuk analisa dan mengambarkan sistem akuntansi desa yang akan dibuat.

2. Metodologi

2.1 Stakeholder

Menentukan Stakeholder berdasarkan Permendagri No 113 Tahun 2014 adalah langkah

awal untuk memulai pembuatan jurnal ini. Stakeholder wajib diketahui terlebih dahulu untuk
mengetahui alur dari sistem akuntansi desa berdasarkan tugas dari masing-masing
Stakeholder. Karena Stakeholder didapatkan dari hasil analisa Permendagri No 113 Tahun
2014, maka data yang didapatkan sangat valid. Di bawah ini adalah Stakeholder yang
berkepentingan dengan sistem akuntansi desa berdasarkan Permendagri No 113 Tahun 2014
Tentang Pedoman Pengelolaan Keuangan Desa :
a. Kepala Desa
b. Sekretaris Desa
c. Bendahara Desa
d. Pelaksana Kegiatan Desa
e. Kepala Seksi

2.2 Daftar Kebutuhan Pengguna

Berdasarkan Permendagri No 113 Tahun 2014 dan Stakeholder yang ada maka ditentukan
kebutuhan pengguna yang wajib ada dalam sistem akuntansi desa antara lain sebagai berikut :
a. Kepala Desa
- KD1 : Sistem diharapkan mampu mengesahkan Rencana Anggaran Biaya (RAB).
- KD2 : Sistem diharapkan mampu mengesahkan rincian angggaran biaya.
- KD3 : Sistem diharapkan mampu mengesahkan Surat Permintaan Pembayaran (SPP).
- KD4 : Sistem diharapkan mampu menampilkan dan mencetak laporan realisasi
Anggaran Pendapatan Belanja Desa (APBD) per semester.
- KD5 : Sistem diharapkan mampu menampilkan dan mencetak laporan
pertanggungjawaban realisasi Anggaran Pendapatan Belanja Desa (APBD).
b. Sekretaris Desa
- SD1 : Sistem diharapkan mampu memverifikasi Rencana Anggaran Biaya (RAB).
 - SD2 : Sistem diharapkan mampu memverifikasi Surat Permintaan Pembayaran (SPP).
- SD3 : Sistem diharapkan mampu membuat dan mencetak Pernyataan Tanggungjawab
Belanja (PTB).
- SD4 : Sistem diharapkan mampu memverifikasi bukti penerimaan dan pengeluaran.
c. Bendahara Desa
- BD1 : Sistem diharapkan mampu membuat data pendapatan dan pengeluaran.
- BD2 : Sistem diharapkan mampu mengklasifikasikan kategori pendapatan dan
kategori belanja.
- BD3 : Sistem diharapkan mampu membuat no rekening yang digunakan untuk
mensinkronkan proses perencanaan hingga pelaporan.
- BD4 :Sistem diharakan mampu melakukan perhitungan secara akurat.
- BD5 : Sistem diharapkan mampu membuat data kas umum.
- BD6 : Sistem diharapkan mampu menghitung data kas umum secara umum
- BD7 : Sistem diharapkan mampu membuat data buku bank desa.
- BD8 : Sistem diharapkan mampu menghitung daa buku bank desa secara akurat
- BD9 : Sistem diharapkan mampu membuat rincian anggaran biaya.
- BD10 : Sistem diharapkan mampu menampilkan dan mencetak laporan realisasi
pendapatan dan belanja desa.
- BD11 : Sistem diharapkan mampu menghitung sisa lebih perhitungan anggaran
(SILPA) secara akurat.
- BD12 : Sistem diharapkan mampu membuat laporan sisa lebih perhitungan anggaran
(SILPA).
- BD13 : Sistem diharapkan mampu membuat data pajak penghasilan.
- BD14 : Sistem diharapkan mampu menghitung data pajak penghasilan secara akurat.
d. Pelaksana Kegiatan Desa
- PKD1 : Sistem diharapkan mampu membuat dan mencetak Surat Permintaan
Pembayaran (SPP).
- PKD2 : Sistem diharapkan mampu membuat dan mencetak Rencana Anggaran Biaya
(RAB).
e. Kepala Seksi
- KS1 : Sistem diharapkan mampu melakukan kontrol atas pengeluaran beban anggaran
belanja kegiatan.
- KS2 : Sistem diharapkan mampu membuat dan mencetak dokumen anggaran atas
beban pengeluaran pelaksanaan kegiatan.
2.3 Unified Modeling Language (UML)

Unified Modeling Language (UML) adalah bahasa pemodelan untuk sistem atau
perangkat lunak yang berparadigma berorientasi objek. Pemodelan (modeling) sesungguhnya
digunakan untuk penyederhanaan permasalahan-permasalahan yang kompleks sedemikian
rupa sehingga lebih mudah dipelajari dan dipahami (Nugroho 2010:6). Membuat Unified
Modeling Language (UML) berdasarkan kebutuhan pengguna mampu menggambarkan
sistem akuntansi desa yang akan dibuat. Di bawah ini adalah beberapa diagram Unified
Modeling Language (UML) untuk sistem akuntansi desa yang akan dibuat :

2.3.1 Use Case Diagram

Use Case Diagram ialah model fungsional sebuah sistem yang menggunakan actor dan
use case (layanan) yang disediakan oleh sistem untuk penggunanya (Henderi, 2008). Pada
sistem akuntansi desa terdapat beberapa Use Case Diagram yang menggambarkan tugas dan
kemampuan beberapa Stakeholder untuk melakukan kegiatan-kegiatan tertentu yang
berhubungan dengan akuntansi desa seperti :
2.3.1.1 Use Case Diagram Rencana Anggaran Biaya (RAB) & Surat Permintaan
Pembayaran (SPP)

Gambar 2.1 Use Case Diagram RAB & SPP

2.3.1.2 Use Case Diagram Penatausahaan Keuangan Desa

Gambar 2.2 Use Case Diagram Penatausahaan Desa

2.3.2 Activity Diagram

Activity Diagram adalah diagram yang menggambarkan worlflow (aliran kerja) atau
aktivitas dari sebuah sistem atau proses bisnis (Umi Alfah, 2013). Ada puluhan Activity
Diagram pada sistem akuntansi desa ini jika merujuk dari analisa yang sudah dilakukan
sebelumnya, oleh sebab itu hanya beberapa Activity Diagram yang cukup penting saja yang
akan ditampilkan pada jurnal ini, tentunya berdasarkan kebutuhan pengguna yang ada. Di
bawah ini adalah Activity Diagram yang dimaksud :

2.3.2.1 Activity Diagram Rancangan Anggaran Biaya (RAB)

 Gambar 2.3Activity Diagram RAB
2.3.2.2 Activity Diagram Pernyataan Tanggungjawab Belanja (PTB)

Gambar 2.4 Activity Diagram PTB

2.3.2.3 Activity Diagram Pendapatan Desa

Gambar 2.5 Activity Diagram Pendapatan Desa

2.3.3 Class Diagram

Class Diagram digunakan untuk menampilkan kelas-kelas dan paket-paket di dalam

sistem, sehingga mampu memberikan gambaran sistem secara statis dan menampilkan relasi
di antara masing-masing kelas (Mohammad Rofiuddin, 2014). Pada sistem akuntansi desa ini
memiliki banyak Class Diagram, di bawah ini adalah salah satu contohnya diambil dari
beberapa laporan keuangan berdasarkan Permendagri No 113 Tahun 2014 :

2.3.3.1 Class Diagram Rancangan Anggaran Biaya (RAB)

Gambar 2.6 Class Diagram RAB

2.3.3.2 Class Diagram Surat Permintaan Pembayaran (SPP)

Gambar 2.7 Class Diagram SPP

2.3.3.3 Class Diagram Buku Kas Pembantu Pajak

Gambar 2.8 Class Diagram Buku Kas Pembantu

2.3.3.4 Class Diagram Pernyataan Tanggungjawab Belanja (PTB)

Gambar 2.9 Class Diagram PTB

2.3.4 State Chart Diagram

State Chart Diagram adalah suatu diagram yang menggambarkan daur hidup (behavior
pattern) dari sebuah objek, dari awal objek tersebut diinisialisasi sampai
dihancurkan. Menggambarkan transisi dan perubahan keadaan (dari satu state ke state
lainnya) suatu objek pada sistem sebagai akibat dari stimulans yang diterima (Asep
Saeopudin, 2013). Ada beberapa State Chart Diagram pada sistem akuntansi desa ini, tapi
karena beberapa State Chart Diagram memiliki kesamaan, maka diambil satu sampel untuk
ditampilkan yaitu State Chart Diagram Rencana Anggaran Biaya (RAB).

Gambar 2.10 State Chart Diagram RAB

3. Hasil

Hasil dari penelitian ini adalah kebutuhan pengguna perangkat lunak akuntansi desa
berdasarkan Permendagri No 113 Tahun 2014 yang diprioritaskan oleh pengguna. Kebutuhan
pengguna perangkat lunak akuntansi desa ini diklasifikasikan ke dalam 2 golongan
kebutuhan, yaitu kebutuhan fungsional dan kebutuhan non fungsional. Kebutuhan fungsional
adalah tindakan dasar yang harus dilakukan oleh perangkat lunak untuk menerima dan
memproses masukan dan menghasilkan keluaran. Sedangkan kebutuhan non fungsional
adalahspesifikasi secara kuantitatif yang harus dipenuhi oleh perangkat lunak. Adapun
klasifikasi kebutuhan pengguna perangkat lunak akuntansi desa, antara lain :

Tabel 3.1 Kebutuhan Kepala Desa

Id Nama Tipe
KD1 Mengesahkan rencana anggaran biaya Fungsional
KD2 Mengesahkan rincian anggaran biaya Fungsional
KD3 Mengesahkan surat permintaan pembayaran Fungsional
Menampilkan dan mencetak laporan realisasi anggaran
KD4 Fungsional
pendapatan dan belanja desa (APBDesa) per semester
Menampilkan dan mencetak laporan pertanggungjawaban
KD5 Fungsional
realisasi Anggaran Pendapatan Belanja Desa (APBD)

Tabel 3.2 Kebutuhan Sekretaris Desa

Id Nama Tipe
SD1 Verifikasi rencana anggaran biaya Fungsional
SD2 Verifikasi surat permintaan pembayaran Fungsional
Membuat dan mencetak Pernyataan Tanggungjawab
SD3 Fungsional
Belanja (PTB)
SD4 Verifikasi bukti penerimaan dan pengeluaran Fungsional

Tabel 3.3 Kebutuhan Bendahara Desa

Id Nama Tipe
BD1 Membuat data pendapatan dan pengeluaran Fungsional
 BD2 Verifikasi surat permintaan pembayaran Fungsional
BD3 Membuat no rekening Fungsional
BD4 Menghitung jumlah data pendapatan dan pengeluaran Non fungsional
BD5 Membuat kas umum Fungsional
BD6 Menghitung jumlah kas umum Non fungsional
BD7 Membuat data buku bank desa Fungsional
BD8 Menghitung data buku bank desa No Fungsional
BD9 Membuat rincian anggaran biaya Fungsional
Menampilkan dan mencetak laporan realisasi pendapatan
BD10 Fungsional
dan belanja desa
BD11 Membuat laporan sisa lebih perhitungan anggaran Fungsional
BD12 Menghitung sisa lebih perhitungan anggaran (SILPA) Non fungsional
BD13 Mampu membuat data pajak penghasilan Fungsional
BD14 Menghitung data pajak penghasilan secara akurat Non fungsional

Tabel 3.4 Kebutuhan Pelaksana Kegiatan Desa

Tabel 3.5 Kebutuhan Kepala Seksi

Id Nama Tipe
Controlling atas pengeluaran beban anggaran belanja
KS1 Non Fungsional
kegiatan
Membuat dokumen anggaran atas beban pengeluaran
KS2 Fungsional
pelaksanaan kegiatan

Id Nama Tipe
PKD1 Membuat surat permintaan pembayaran Fungsional
PKD2 Membuat rencana anggaran biaya Fungsional
4. Analisa

Hasil penelitian ini berupa pengklasifikasian kebutuhan pengguna perangkat lunak

akuntansi ke dalam kategori kebutuhan fungsional dan kebutuhan non fungsional.
Penggunaan tabel dalam klasifikasi kebutuhan pengguna, dimaksudkan untuk memperjelas
masing-masing kebutuhan dari stakeholder pengguna perangkat lunak akuntansi desa. Pada
tabel 1 kebutuhan kepala desa dapat dijelaskan bahwa KD1, KD2, KD3, KD4 dan KD5
digolongkan sebagai kebutuhan fungsional, karena sistem diharapkan mampu mengesahkan
rencana anggaran biaya, rincian anggaran biaya dan surat permintaan pembayaran serta
mampu menampilkan menampilkan dan mencetak laporan/pertanggungjawaban realisasi
anggaran pendapatan dan belanja desa (APBD) per semester.
Pada tabel 2 kebutuhan sekretaris desa dapat dijelaskan bahwa SD1, dan SD2
diklasifikasikan ke dalam golongan kebutuhan fungsional, karena sistem diharapkan mampu
memverifikasi rencana anggaran biaya, surat permintaan pembayaran. Sedangkan, pada SD3
dan SD4 diklasifikasikan ke dalam golongan kebutuhan non fungsional, karena sistem
diharapkan mampu menghitung tagihan atas APBD, dan jumlah kas di tangan dan di sistem.
Pada tabel 3 kebutuhan bendahara desa dapat dijelaskan bahwa BD1, BD2, BD3, BD 5, BD6,
BD7, BD9, BD10, BD11, dan BD13, karena sistem diharapkan mampu membuat data
laporan keuangan desa mulai dari proses membuat data pendapatan dan pengeluran desa
sampai dengan membuat data pajak penghasilan. Sedangkan, pada BD4, BD6, BD8, BD12,
dan BD14 diklasifikasikan ke dalam golongan kebutuhan non fungsional, karena sistem
diharapkan mampu menghitung jumlah data pendapatan dan pengeluaran, jumlah kas umum,
jumlah kas buku bank desa, jumlah sisa lebih perhitungan anggaran (SILPA), dan jumlah
pajak penghasilan yang akurat.
Pada tabel kebutuhan pelaksana kegiatan dapat dijelaskan bahwa PKD1 dan PKD2
diklasifikasikan ke dalam golongan kebutuhan fungsional, karena sistem diharapkan mampu
membuat rencana anggaran biaya, dan surat permintaan. Pada tabel 5 kebutuhan kepala seksi
dapat dijelaskan bahwa KS2 dapat diklasifikasikan ke dalam golongan kebutuhan fungsional,
karena sistem diharapkan mampu membuat dokumen anggaran atas beban pengeluaran
pelaksanaan kegiatan. Sedangkan, pada KS 1 dapat diklasifikasikan ke dalam golongan non
fungsional, karena sistem diharapkan mampu melakukan controlling atas pengeluaran beban
anggaran belanja kegiatan.

5. Diskusi

Dari hasil kebutuhan perangkat lunak akuntansi desa yang didapatkan, kemudian
didiskusikan dan dianalisa menggunakan beberapa karakteristik Software Reuqirement
Specification (SRS)menurut IEEE untuk mendapatkan kebutuhan perangkat lunak akuntansi
desa yang valid dan akurat. Di bawah ini adalah beberapa karakteristikSoftware Reuqirement
Specification (SRS)yang dimaksud :

5.1 Correct
 Correct mengartikan bahwa kebutuhan perangkat lunak akuntansi desa yang dibuat
menang terbukti kebenarannya, tapi menurut IEEE (1998) sendiri tidak ada teknik di dunia
ini dapat memastikankebenaran. Walaupun begitu, kebutuhan perangkat lunak akuntansi desa
yang telah dibuat dapat diyakini bahwa kebenarannya cukup valid karena kebutuhan
perangkat lunak itu sendiri didapatkan dari hasil analisa Permendagri No 113 Tahun 2014
dan Unified Modeling Language (UML)yang telah dibuat.

5.2 Unambiguity

Unambiguity atau ketidakambiguan merupakan sebuah karakteristik yang mengartikan

bahwa semua kebutuhan perangkat lunak akuntansi desa harus jelas, sehingga tidak membuat
para developer sistem akuntansi desa suatu saat nanti menjadi bingung pada saat
pengerjaannya. Jelas di dalam sistem akuntansi desa ini juga dapat diartikan bahwa setiap
permintaan untuk kebutuhan perangkat lunak akuntansi desa harus mempunyai satu
interpretasi atau hanya ada satu arti dalam satu kalimat.

5.3 Complete

Complete atau kelengkapan dalam sistem akuntansi desa juga perlu diperhatikan seperti
kebutuhan pengguna dan kebutuhan perangkat lunak akuntansi desa harus dilengkap dan ada.
Selain itu kelengkapan untuk model pengambaran sistem akuntansi desa (menggunakan
Unified Modeling Language (UML)) juga perlu diperhatikan seperti atribut pada Class
Diagram, pengambaran Use Case, alur kerja sistem yang digambarkan menggunakan Activity
Diagramdan sebagainya. Jika melihat dari hasil yang didapat, jurnal ini cukup lengkap
walaupun hanya sebagian dari diagram saja yang ditampilkan, karena pada dasarnya terdapat
puluhan diagram yang harus digambarkan pada sistem akuntansi desa ini.

5.4 Consistent

Kebutuhan perangkat lunak akuntansi desa yang dibuat harus Consitent (konsisten) agar
sistem akuntansi desa yang dibuat nantinya juga konsisten. Nilai-nilai kebutuhan perangkat
lunak harus tetap sama baik dalam karakteristik maupun spesifik kebutuhan perangkat lunak.
5.5 Verifiable

Verifiable atau dapat diverifikasi merupakan sebuah karakteristik Software Reuqirement

Specification (SRS) yang memiliki ciri bahwa kebutuhan perangkat lunak akuntansi desa
harus bisa diverifikasi kebenarannya, sehingga nantinya tidak akan terjadi kesalahan pada
saat pembuatan sistem akuntansi desa, karena sistem akuntansi desa sudah diverifikasi jauh-
jauh hari sebelum pembuatannya. Biasanya setiap kebutuhan perangkat lunak selalu dimulai
dengan dokumen atau hasil analisis yang bisa diperiksa. Permendagri No 113 Tahun 2014
juga bisa digunakan untuk memverifikasi kebutuhan perangkat lunak akuntansi desa ini agar
kebenarannya (Correct) juga teruji. Secara tak kasat mata ternyata Verifiable juga masih
berhubungan dengan Correct, sehingga dapat digaris bawahi bahwa karakteristik Software
Reuqirement Specification (SRS) masih saling berhubungan satu dengan yang lainnya untuk
menghasilkan sesuatu yang lebih baik.

5.6 Modifiable

Modifiable adalah karakteristik Software Reuqirement Specification (SRS) yang memiliki

untuk fleksibilitas yang tinggi yang membuat sistem akuntansi desa ini menjadi sangat
fleksibel karena mudah dimodifikasi dengan mudah. Untuk membuat kebutuhan perangkat
lunak yang menghasilkan sistem akuntansi desa yang Modifiable tentunya tidak mudah.
Ketelitian dan detail yang lengkap (Complete) menjadi bahan utama yang membuat sistem
akuntansi desa menjadi mudah dimodifikasi. Selain mudah dimodifikasi, sistem akuntansi
desa harus tetap konsisten (Consistent) agar proses dalam sistem tetap terjaga.

5.7 Traceable

Traceable di sini diartikan menjadi sesuatu yang dapat ditelusuri. Jika berbicara
mengenai sistem, maka sesuatu yang dapat ditelusuri dengan mudah, maka dapat
menyelesaikan masalah secara cepat dan akurat. Apabila sistem akuntansi desa yang dibuat
berdasarkan kebutuhan perangkat lunak yang ada mengalami kendala, tentunya akan sangat
mudah untuk menganalisa dan memperbaiki kendala yang ada.

6. Kesimpulan
 Kesimpulan yang dapat diambil dari hasil penelitian ini adalah sebagai berikut:
- Stakeholder pengguna perangkat lunak akuntansi desa ini adalah kepala desa, sekretaris
desa, bendahara desa, pelaksana kegiatan, dan kepala seksi.
- Setelah mendapatkan stakeholder pengguna perangkat lunak akuntansi desa, maka
dibuatkan daftar kebutuhan pengguna berdasarkan tanggung jawab yang tertuang dalam
Permendagri No 113 Tahun 2014.
- Daftar kebutuhan yang telah dibuat, selanjutnya didesain kebutuhan pengguna perangkat
lunak akuntansi desa dengan menggunakan Unified Modelling Language (UML).
- Hasil desain kebutuhan pengguna perangkat lunak akuntansi desa dengan menggunakan
Unified Modelling Language (UML), kemudian diklasifikasikan ke dalam golongan
kebutuhan fungsional dan kebutuhan non fungsional. Sehingga kebutuhan pengguna
perangkat lunak akuntansi desa dapat diperoleh secara spesifik.

7. Daftar Pustaka

Republik Indonesia. 2014. Peraturan Menteri Dalam Negeri Nomor 113 Tahun 2014. Menteri
Dalam Negeri Republik Indonesia, Jakarta.
Soares, Michel dS., JosVrancken,& Alexander Verbraeck, Oktober 2010. “User requirements
modeling and analysis of software-intensive systems”. Elsevier.
http://www.elsevier.com/locate/jss, 29 November 2015.
Liang, Ying, September 2002. “From use cases to classes: a way of building object model
with UML”. Elsevier. http://www.elsevier.com/locate/infsof. 29 November 2015.
Sularto, Lana., Wardoyo, & Tristyanti Yunitasari, Agustus 2014. “User Requirements
Analysis for Restaurant POS and Accounting Application Using Quality Function
Deployment”. Elsevier. http://www.sciencedirect.com, 29 November 2015.
Pahmi. BangPahmi, We Share Cause We Care.com.
http://www.bangpahmi.com/2015/04/pengertian-unified-modelling-language-uml-dan-
modelnya-menurut-pakar.html. Diakses pada tangga 28 November 2015.
Noval. Jelajah Ilmu Internet. http://www.jelajahinternet.com/2014/10/pengertian-use-case-
diagram-deskripsi.html. Diakses pada tanggal 28 November 2015.
Umi Alfah. UMIALFAH, I CAN, BECAUSE I THINK I CAN.
http://fatimahumi.blogspot.co.id/2014/03/uml-activity-diagram.html. Diakses pada
tanggal 28 November 2015.
Mohammad Rofiuddin. Belajar Bermanfaat bagi sesama...!!!We Are Moeslem...!!!.
http://mrofiuddin.blogspot.co.id/2011/11/pengertian-class-diagram.html. Diakses pada
tanggal 29 November 2015.
Asep Saepudin. Tugas Kuliah. http://tugas-kuliah-stmik.blogspot.co.id/2013/04/statechart-
diagram-uml.html. Diakses pada tanggal 29 November 2015.
Robert Japenga. MicroTools Inc. http://www.microtoolsinc.com/Howsrs.php. Diakses pada
tanggal 29 November 2015.