Requirements Engineering 110313

Implementasi dan Analisis Goal-Based Requirement
Analysis Method(GBRAM) dengan Studi Kasus: Sistem

Informasi Apotek Ananda
Tugas Akhir
diajukan untuk memenuhi salah satu syarat
memperoleh gelar sarjana
dari Program Studi Sarjana Teknik Informatika
Universitas Telkom
1103130218
ALVIN KHAIR
Program Studi Sarjana Teknik Informatika
Fakultas Informatika
Universitas Telkom
Bandung
2017
i
LEMBAR PERNYATAAN
ii
LEMBAR PENGESAHAN
Implementasi dan Analisis Goal-Based Requirement Analysis Method(GBRAM)
dengan Studi Kasus: Sistem Informasi Apotek Ananda
Implementation and Analysis Goal-Based Requirement Analysis

Method(GBRAM) on Case Study: Ananda Pharmacy Information System
1103130218
ALVIN KHAIR
Tugas akhir ini telah diterima dan disahkan untuk memenuhi sebagian syarat memperoleh
Gelar pada Program Studi Sarjana Teknik Informasika
Fakultas Informatika
Universitas Telkom
Bandung, XX XX XXX
Menyetujui
Pembimbing 1 Pembimbing 2
Dana Sulistyo Kusumo S.T., M.T., Nungki Selviandro S.Kom., M.Kom

Ph.D.
02780291-1 14881402-1
Ketua Program Studi
Moch. Arif Bijaksana. Ph.D.

03650312-4
iii
ABSTRAK
Requirements Engineering (RE) berkaitan dengan memproduksi satu set
spesifikasi untuk system perangkat lunak yang memuaskan stakeholder dan dapat di
implementasikan, digunakan dan dikelola menggunakan alternatif ini. RE sangat
penting untuk keberhasilan sebuah sistem atau proyek. Keberhasilan suatu sistem juga
ditentukan oleh stakeholders yang terlibat, karena semua kebutuhan yang diperlukan
pada sistem berasal dari apa yang stakeholders inginkan. Sering kali stakeholders
kesulitan dalam menyampaikan apa yang mereka inginkan dalam pengembangan
sistem. Terkadang, stakeholder tidak mengerti mengenai kebutuhan mereka sendiri.
Sebuah SRS sering kali digunakan untuk menjadi acuan atau sebuah kontrak dalam
pengembangan sistem yang telah disepakati. Ketika stakeholders kurang mengerti
mengenai spesifikasi ini, dokumen SRS dapat menjadi sebuah beban. Pada penelitian
ini, metode berbasis goal akan digunakan untuk membantu stakeholders dalam
menyampaikan kebutuhannya. Dengan menggunakan Goal-Based Requirements
Analysis Method (GBRAM), peneliti dapat menganalisa kebutuhan dari stakeholders
melalui informasi yang didapat. Penelitian ini menggunakan studi kasus Sistem
Informasi Apotek Ananda. Penelitian ini diharapkan dapat membuat stakeholder lebih
mengerti mengenai tujuan dan kebutuhan mereka serta peneliti dapat meyakinkan
stakeholders mengenai kebutuhan mereka dengan dokumen yang lebih mudah untuk
mereka mengerti.
Kata Kunci: Requirements Engineering(RE), Goal-Based Requirements Analysis

Method (GBRAM), Stakeholders, Software Requierements Spesification (SRS)
iv
ABSTRACT
Requirements Engineering (RE) is associated with the creation of a set of
spesifications for software system that satisfy stakeholders and can be implemented,
used, and managed using this alternative. RE is crucial for the success of a system or a
project. The success of a system is also determined by the involvement of stakeholders,
as all the needs that required on the system that come from what the stakeholders want.
Stakeholders often distress on conveying what they want for their system development.
Sometimes, stakeholders don’t understand about their own requirements. A SRS often
used for reference or a contract on an agreed system. When stakeholders do not
completely understand about the specification, SRS document could be a problem. In
this study, goal-based method will be used for helping stakeholders to convey their
needs. With Goal-Based Requirements Analysis Method (GBRAM), the researcher
able to analyse their requirements of the information obatained. This study using a
study case about Ananda Pharmay Information System. This study is expected able to
make stakeholders understand about their goals and needs that researchers able to
convince stakeholders about their requirements with a better document that they could
understand.
Keywords: Requirements Engineering(RE), Goal-Based Requirements Analysis

Method (GBRAM), Stakeholders, Software Requierements Spesification (SRS)
v
LEMBAR PERSEMBAHAN
vi
KATA PENGANTAR
vii
DAFTAR ISI
LEMBAR PERNYATAAN ...................................................................................................... ii
LEMBAR PENGESAHAN ......................................................................................................iii
ABSTRAK ................................................................................................................................iv
ABSTRACT.............................................................................................................................. v
LEMBAR PERSEMBAHAN ...................................................................................................vi
KATA PENGANTAR ............................................................................................................. vii
DAFTAR GAMBAR .................................................................................................................x
DAFTAR TABEL.....................................................................................................................xi
DAFTAR ISTILAH ................................................................................................................. xii
1. PENDAHULUAN ............................................................................................................ 1
1.1. Latar Belakang............................................................................................................ 1
1.2. Perumusan Masalah .................................................................................................... 2
1.3. Tujuan......................................................................................................................... 2
1.4. Metodologi Penelitian ................................................................................................ 3
1.5. Sistematika Penulisan ................................................................................................. 3
2. TINJAUAN PUSTAKA ................................................................................................... 5
2.1. Requirement Engineering (RE) .................................................................................. 5
2.2. Goal Oriented Requirement Engineering (GORE) ..................................................... 5
2.3. Goal-Based Requirement Analysis Method (GBRAM) ............................................. 6
2.3.1. Goal Analysis ...................................................................................................... 7
2.3.2. Goal Refinement ................................................................................................. 8
2.4. User Acceptance Test (UAT) ................................................................................... 10
3. METODOLOGI PENELITIAN ...................................................................................... 11
3.1. Analisa Kebutuhan ................................................................................................... 11
3.1.1. Explore .............................................................................................................. 11
3.1.2. Identify .............................................................................................................. 13
3.1.3. Organize ............................................................................................................ 16
3.1.4. Refine ................................................................................................................ 18
3.1.5. Elaboration ........................................................................................................ 20
3.1.6. Operationalize ................................................................................................... 21
viii
3.2. Implementasi dan Pengujian Perangkat Lunak ........................................................ 23
4. ANALISIS HASIL .......................................................................................................... 27
4.1. Hasil Implementasi ................................................................................................... 27
4.2. Manfaat tiap proses................................................................................................... 30
4.3. Kelebihan dan Kekurangan ...................................................................................... 30
4.4. Validasi Analisis....................................................................................................... 31
5. KESIMPULAN ............................................................................................................... 32
5.1. Kesimpulan ............................................................................................................... 32
LAMPIRAN............................................................................................................................ 35
Lampiran 1. Wawancara dengan Pemilik Apotek Ananda ................................................. 35
Lampiran 2. Form Validasi Dokumen ................................................................................ 37
Lampiran 3. Goal Schema................................................................................................... 38
Lampiran 4. Operational Schema........................................................................................ 59
Lampiran 5. User Acceptance Test (UAT) ......................................................................... 70
Lampiran 6. Spesifikasi Kebutuhan Perangkat Lunak (SKPL) Sistem Informasi Apotek
Ananda .............................................................................................................................. 104
ix
DAFTAR GAMBAR
Gambar 1. Aktivitas GBRAM .................................................................................................. 7
Gambar 2. Flowchart Metodologi Penelitian .......................................................................... 11
Gambar 3. Workflow Apotek Ananda .................................................................................... 12
Gambar 4. Hasil Goal Dependency......................................................................................... 18
Gambar 5. Contoh Goal Schema ............................................................................................ 21
Gambar 6. Contoh Action Schema ......................................................................................... 22
Gambar 7. Skenario Kelola Stok Opname .............................................................................. 23
Gambar 8. Halaman Stok Barang ........................................................................................... 24
Gambar 9. Halaman Daftar Barang Masuk ............................................................................. 24
Gambar 10. Halaman Input Barang Masuk ............................................................................ 25
Gambar 11. Halaman Detail Barang Masuk ........................................................................... 25
Gambar 12. Halaman Daftar Stok Opname ............................................................................ 25
Gambar 13. Halaman Input Stok Opname .............................................................................. 26
Gambar 14. Goal Topography Pemesanan ............................................................................. 27
Gambar 15. Goal Topography Stok Barang............................................................................ 28
Gambar 16. Goal Topography SDM ....................................................................................... 28
Gambar 17. Goal Topography Master .................................................................................... 29
Gambar 18. Goal Topography Penjualan ................................................................................ 29
x
DAFTAR TABEL
Tabel 1. Tabel Goals ............................................................................................................... 14
Tabel 2. Tabel Goals 2 ............................................................................................................ 16
Tabel 3. Tabel Tipe Goals ....................................................................................................... 17
xi
DAFTAR ISTILAH
xii
1. PENDAHULUAN
1.1. Latar Belakang
Requirements Engineering(RE) merupakan proses dalam mendefinisikan
kebutuhan suatu perangkat lunak dari stakeholders dan lingkungan sistem yang
akan dibangun. Requirements analysist dan Requirements specification adalah
salah satu aktivitas yang paling menantang dan rawan atas kesalahan dalam proses
perangkat lunak. Faktor penting dalam kesuksesan sebuah proyek adalah bahwa
developer tidak hanya mengerti apa yang mereka bangun, tetapi kenapa mereka
membangun sistem yang telah diberikan.
Pendekatan tradisional dari proses requirements analysis focus terhadap
tahapan memperoleh sebuah software requirements specification(SRS).
Stakeholders sering kali menyampaikan pemahaman yang jelas tentang apa yang
akan dilakukan oleh sistem yang diinginkan dan sering kali merubah pemikiran
mereka mengenai fungsionalitas yang harus dimiliki oleh sistem. Stakeholders
sering sekali mengalami kesulitan dalam menjelaskan requirements. Stakeholders
lebih memahami tujuan-tujuan dasar yang ingin mereka capai daripada
fungsionalitas apa yang harus dimiliki oleh sistem tersebut. Sebuah SRS seringkali
digunakan sebagai sebuah kontrak dengan stakeholders. Ketika stakeholders
kurang mengerti mengenai spesifikasi ini, dokumen SRS dapat menjadi sebuah
beban. Dikarenakan dokumen SRS adalah dokumen yang dapat digunakan untuk
perjanjian, lebih baik jika dokumen tersebut dapat disajikan dengan cara yang dapat
mereka ikuti dan mengerti.
Dengan memusatkan perhatian pada tujuan (goals) dapat memudahkan
stakeholders dalam berkomunikasi menggunakan language-based concept yang
mana dapat membuat mereka nyaman. Oleh Karena itu, penting untuk
memanfaatkan dan memahami struktur goals dari informasi yang diberikan oleh
stakeholder menjadi sebuah requirements. Goal-Based Requirements Analysis
Method (GBRAM) dapat digunakan untuk mendapatkan informasi dan tujuan dari
stakeholder untuk menjadi sebuah requirements. GBRAM adalah metode yang
1
dibuat untuk membantu peneliti dalam mengumpulkan informasi sumber-sumber
yang telah dikumpulkan menjadi sebuah goals yang nantinya akan diubah menjadi
requirements. Penelitian ini akan mengambil studi kasus pada pembuatan Sistem Informasi
Apotek Ananda. Apotek Ananda adalah sebuah terminal distribusi obat perbekalan farmasi
yang dikelola oleh bapak Indra Nura. Salah satu tujuan dibuatnya sistem ini adalah untuk
memperbaiki pengelolaan barang yang ada pada Apotek Ananda.
1.2. Perumusan Masalah

Berdasarkan Latar Belakang, maka masalah yang dapat dirumuskan yaitu,
1. Bagaimana cara mengimplementasi Goal-Based Requirements Analysis

Method (GBRAM) dengan studi kasus: Sistem Informasi Apotek Ananda
2. Bagaimana cara validasi dari hasil implementasi Goal-Based
Requirements Analysis Method (GBRAM) dengan studi kasus: Sistem
Informasi Apotek Ananda
1.3. Tujuan
1. Menghasilkan hasil analisis dari implementasi Goal-Based Requirements
Analysis Method (GBRAM) dengan studi kasus: Sistem Informasi Apotek
Ananda.
2. Mengetahui cara validasi dari hasil analisis dari implementasi Goal-Based
Requirements Analysis Method (GBRAM) dengan studi kasus: Sistem
Informasi Apotek Ananda.
2
1.4. Metodologi Penelitian
Metodologi yang digunakan untuk penulisan Tugas Akhir ini yaitu:
1. Analisa Kebutuhan
Bagian ini akan mengimplementasikan metode Goal-Based Requirements
Analysis Method(GBRAM) dimulai dari aktivitas Goal Analysis yang
memiliki tahan Identify, Explore, Organize dan aktivitas Goal Refinement
yang memiliki tahapan Refine, Elaboration dan Operationalize.
2. Validasi Kebutuhan
Setelah melakukan semua aktivitas pada GBRAM, hasil implemntasi
GBRAM pada Apotek Ananda akan divalidasi oleh pihak Apotek
Ananada.
3. Implementasi dan Pengujian Sistem
Setelah hasil implementasi telah divalidasi oleh pihak Apotek Ananda,
maka selanjutnya adalah implementasi dari sistem yang telah disetujui.
Setelah sistem telah selesai, maka sistem akan diujicoba kepada para
stakeholders dengan menggunakan User Acceptance Test (UAT).
1.5. Sistematika Penulisan

Sistematika penulisan yang digunakan untuk penulisan Tugas Akhir ini yaitu:
1. PENDAHULUAN
Bab ini menjelaskan tugas akhir secara umum meliputi latar belakang
masalah, perumusan masalah, tujuan, metodologi penelitian dan
sistematika penulisan.
2. TINJAUAN PUSTAKA
Bab ini berisi tentang teori-teori penunjang yang digunakan untuk
penyelesaian penelitian Tugas Akhir.
3. METODOLOGI PENELITIAN
Bab ini berisi gambaran umum atau tahap-tahap penyelesaian tugas akhir
berdasarkan literatur dan pola pikir yang dimiliki oleh peneliti dan
3
rancangan dari sistem yang akan dibuat berkaitan dengan solusi
permasalahan yang diangkat pada penelitian ini.
4. ANALISIS HASIL
Bab ini berisi hasil dari anlisis implementasi Goal-Based Requirements
Analysis Method (GBRAM) dengan studi kasus: Sistem Informasi Apotek
Ananda.
5. KESIMPULAN DAN SARAN
Bab ini berisi kesimpulan dari seluruh hasil analisis implementasi Goal-
Based Requirements Analysis Method (GBRAM) dengan studi kasus:
Sistem Informasi Apotek Ananda.
4
2. TINJAUAN PUSTAKA
2.1. Requirement Engineering (RE)
Requirement Engineeering (RE) merupakan proses dalam mendefinisikan dan
mendokumentasi kan kebutuhan dari suatu perangkat lunak dari stakeholder dan
lingkungan sistem yang akan dibangun. RE merupakan hal yang sangat penting
dalam proses pembangunan perangkat lunak, karena untuk membangun suatu
perangkat lunak dibutuhkan sebuah dokumentasi yang kompleks dan baik
mengenai perangkat lunak ya ng akan dibangun. Tanpa requirements yang jelas,
hasil dari perangkat lunak tentu saja tidak akan menghasilkan sebuah perangkat
lunak yang bagus.
2.2. Goal Oriented Requirement Engineering (GORE)

Goal Oriented Requirements Engineering (GORE) adalah sebuah metode
pendekatan pada Requirement Engineeing(RE) yang berdasarkan pada indentifikasi
tujuan (Goals) sebuah system dan transformasi goals tersebut menjadi sebuah
kebutuhan (requirements). GORE menekankan pada kenapa goal-goal tertentu
sangat dibutuhkan, bagaimana caranya goal tersebut dapat di capai dan siapa yang
bertanggung jawab untuk sistem tersebut dan siapa saja lingkungan dari system
tersebut. GORE mempunyai beberapa manfaat yang salah satunya adalah [1]:
• Dari Goals, seseorang dapat secara sistematis memperoleh persyaratan dan
object model.
• Goals memberikan alasan untuk persyaratan.
• Goal Formalization dapat membuktikan jika proses refinement menghasilkan
hal yang benar dan lengkap.
• The Goal Refinement Structure dapat menunjukkan struktur yang dapat
dipahami yang membantu dalam pembuatan Software Requirements Document.
5
2.3. Goal-Based Requirement Analysis Method (GBRAM)
GBRAM adalah salah satu metode dari GORE yang menekankan pada fase
Goal Analysis dan Goal Refinement. GBRAM dikembangkan untuk merespon
kekurangan dalam teknik identifikasi goal pada metode-metode GORE lainnya.
Goal Analysis adalah aktivitas awal dalam GBRAM yang fokus terhadap analisis
goalnya. Berikut adalah hal inti yang dibahas pada Goal Analysis [15]:
• Explore
• Identify
• Organize
Goal Refinement bisa dibilang juga Goal Evolution, adalah aktivitas akhir dari
GBRAM yang fokus terhadap pematangan goalnya. Aktivitas ini juga dapat
dilakukan ketika stakeholder ingin mengganti goalnya. Berikut adalah hal inti
yang dibahas pada Goal Refinement:
• Refine
• Elaborate
• Operationalize
Untuk lebih lengkapnya, berikut alur mengenai metode GBRAM yang dapat
dilihat di gambar berikut:
6
2.3.1. Goal Analysis
Proses ini lebih tertuju kepada penyusunan dan klasifikasi goals dari eksplorasi
sumber-sumber yang ada.
Gambar 1. Aktivitas GBRAM
2.3.1.1. Identifying Goals

Tahapan ini akan menganalisa informasi dari sumber-sumber yang didapat,
setelah itu akan menidentifikasi goals yang ada. Analisa Goal dapat bersumber
dari wawancara, workflow dan informasi yang textual. Untuk mendapatkan poin
goal yang diingin kan, kita dapat melihat dari kata-kata dari informasi yang ada.
Kata- kata ini adalah kata yang memiliki makna untuk dapat
melakukan/mewujudkan sesuatu.
2.3.1.2. Identifying Stakeholders

Untuk menidentifikasi stakeholder bisa dilihat dari siapa yang bertanggung
jawab, merasakan hasil atas goal nya. Stakeholder bisa jadi agent dan agent juga
bisa jadi sebagai stakeholder.
7
2.3.1.3. Identifying Agents
Agent bertanggung jawab untuk memastikan goals yang diinginkan berjalan
dan tercapai.
2.3.1.4. Organization and Classification of Goals

Organizational Goal mengharuskan pengurangan Goals yang memiliki
maksud yang sama. Classification Goal melibatkan sebuah perbandingan goal
yang sesuai dengan target mereka sendiri yaitu Achievement Goals dan
Maintenance Goals
2.3.1.5. Eliminating Redundancies and Reconcilling Synonymous Goals

Sebuah goal dikatakan sama artinya jika mereka memiliki maksud yang sama
kepada stakeholder yang berbeda-beda dengan menggunakan terminologi yang
berbeda-beda.
2.3.1.6. Classifying Goals

Sebuah Maintenance Goal telah pasti selama kondisi dari target goalnya itu
masih dalam keadaan stabil(True), jadi bisa dibilang Maintenance Goal itu akan
selalu berjalan. Sebuah Achievement Goal telah pasti ketika goalnya telah
berhasil dicapai.
2.3.2. Goal Refinement

Proses ini bisa juga dibilang sebagai Goal Evolution. Ketika Stakeholder
memiliki goal yang baru ataupun tidak, proses ini akan menganalisa goal yang
telah di analisis sebelumnya menjadi lebih detail lagi.
2.3.2.1. Specifying Goal Obstacles

Goal Obstacles adalah suatu hal yang dapat menghambat dan menghentikan
suatu goal untuk tercapai. Obstacles dapat diketahui dari menganalisa dari suatu
kalimat. Obstacles bisa diidentifikasi melalui pertanyaan: “What other goal or
condition does this goal depend on?”
8
2.3.2.2. Constructing Scenarios
Scenarios adalah artefak paling kreatif dari proses analisis dan memainkan
peran utama dalam menemukan goal dan begitu juga dengan system requirement.
Dengan adanya scenario, dapat menemukan sebuah goals yang tersembunyi
ataupun obstacles. Scenarios diidentifikasi dengan mempertimbangkan goal dan
goal obstacles terdahulu untuk menentukan kenapa dan dalam kondisi apa sebuah
goal dapat berhasil maupun gagal.
2.3.2.3. Identifying Constraints

Constraints merupakan sebuah requirement yang harus dilaksanakan atau ada
untuk mencapai goal yang diinginkan. Constraints dapat diidentifikasikan melalui
relasi ketergantungan dan beberapa point kata seperti during, before, after.
2.3.2.4. Operationalization of Goals into Requirements

Setelah semua tahapan telah dilakukan, saatnya mengkonversi semua goal
beserta obstacles, constraints, dll menjadi Goal Schema dan Software Requirements
Documents.
Goal Schema adalah proses menspesifikasikan antara goal dan agentsnya.

Point dari Goal Schema itu sendiri adalah:
• Goal(Name): Tujuan yang harus dicapai.
• Type(Name): Tipe dari goalnya (Achievement / Maintenance).
• Description(Text): Deskripsi dari goal.
• Action(Name): Nama operasi (Function) dari goal tersebut.
• Agent(Name): Yang bertugas dalam menjalankan goal.
• Stakeholder(s)(Name(s)): yang menerima hasil dari goal
• Constraints(Items): Objective yang harus dicapai.
• Obstracles(Items): hal yang menghambat pencapaian suatu goal.
• Precondition(Condition): kondisi sebelum goal di capai.
9
• Postcondition(Condition): kondisi setelah goal di capai.
2.4. User Acceptance Test (UAT)

User Acceptance Test (UAT) adalah suatu sarana formal dimana
perusahaan memastikan bahwa sistem yang dibuat benar-benar akan memenuhi
persyaratan pengguna yang essensial. Tujuan dari UAT adalah memeriksa
perangkat lunak terhadap kebutuhan bisnis. Hal ini dilakukan oleh pengguna
akhir yang sudah familiar dengan kebutuhan bisnis. UAT merupakan semacam
black-box testing dimana dua pengguna atau lebih akan terlibat. Pengujian UAT
dilakukan oleh pengguna dan pengelola aplikasi.
10
3. METODOLOGI PENELITIAN
Pada bab ini, peneliti akan menjelaskan alur penelitian menggunakan metode
GBRAM. Penelitian ini melibatkan Apotek Ananda sebagai pihak klien yang
nantinya akan membantu dalam pengumpulan data. Pengumpulan data yang
dilakukan dengan cara wawancara dan diagram workflow. Diagram alur dibawah
ini merupakan langkah-langkah yang dilakukan pada penelitian tugas akhir ini
dapat digambarkan sebagai berikut:
Gambar 2. Flowchart Metodologi Penelitian
Adapun kegiatan yang akan dilakukan dalam penelitian ini dibagi dalam beberapa
tahap sebagai berikut.
3.1. Analisa Kebutuhan

3.1.1. Explore
Tahapan Explore ini adalah tahapan awal dari Goal Analysis. Pada
tahapan ini, peneliti melakukan sebuah eksplorasi kepada apotek Ananda. Ada
beberapa cara peneliti melakukan eksplorasi pada studi kasus ini yaitu
wawancara dan mempelajari workflownya. Hasil wawancara dapat dilihat pada
lampiran dan berikut adalah workflow dari Apotek Ananda:
11
Gambar 3. Workflow Apotek Ananda
Berdasarkan hasil wawancara dan workflow dari apotek Ananda, maka

menghasilkan beberapa modul yaitu:
a. Pemesanan (ORD): Modul yang digunakan untuk proses Pemesanan

Barang.
b. Stok Barang (INV): Modul yang digunakan dalam proses Stok Barang
c. Sumber Daya Manusia (SDM): Modul yang mengola pegawai.
d. Master Data (MST): Modul yang dapat menyimpan data-data Barang,
PBF (Pedagang Besar Farmasi)
e. Penjualan (SLS): Modul untuk proses penjualan.
Pada bagian selanjutnya akan dijelaskan cara untuk mendapatkan goals dari
data yang telah dapat beserta agents dan stakeholder yang bersangkutan. Untuk
data yang digunakan, peneliti akan menggunakan contoh dari modul Stok
Barang.
12
3.1.2. Identify
Setelah mendapatkan informasi melalui tahap explore, saatnya untuk
mengetahui goal-goal yang ada beserta stakeholders dan agents. Berikut adalah
poin-poin yang dapat dilakukan untuk identifikasi goals, yaitu:
a. Penulisan nama goal berdasarkan standar penulisan yang diawali dengan

kata kerja.
b. Kata kunci seperti track, monitor, provide, supply, find out, know, avoid,
ensure, keep, satisfy, complete, allocate, increase, speedup. Improve, make
dan achieve adalah poin yang berguna dalam pemilihan goals.
c. Goals juga bisa diidentifikasi dengan cara mempertimbangkan
kemungkinan rintangan pada goal-goal yang sebelumnya
d. Harus terlebih dahulu berusaha memahami tujuan dan wewenang dari
stakeholder’s sebelum berkonsentrasi pada sistem actual sehingga
requirements sistem dapat ditentukan secara memadai.
e. Goals dapat ditentukan dengan mempertimbangkan obstacles dan
contraintsnya.
f. Goals dapat ditemukan atau tidaknya dengan mempertimbangkan
ketergantungan dari goals terdahulu.
Dari hasil tahapan explore, diketahui bahwa Stok Barang:
• Melakukan pemasukan barang pemesanan hampir setiap hari.

• Stok Barang akan berubah setelah terjadinya pemasukan barang atau proses
penjualan (pengeluaran barang).
• Stok Opname diperlukan
Peneliti menggunakan poin-poin yang telah dijelaskan untuk

mengidentifikasi sebuah goal, seperti contoh pada poin b. Peneliti
menggunakan kata kunci monitor, dikarenakan Stok Barang harus sering
dipantau keadaanya sehingga dapat memperlancar pada proses penjualan.
Peneliti juga mengguanakan poin d dan mengacu pada pernyataan dari pemilik
13
apotek Ananda yaitu, “Menanggulangi kendala kami pada selisih barang
dan juga mempermudah kami dalam proses pengolahan barang yang ada
pada Apotek Ananda”. Dari pernyataan tesebut diketahui bahwa apotek
Ananda ingin memperbaiki pengolahan barang agar tidak terjadi selish barang.
Pada statement diatas diketahui bahwa apotek Ananda bertujuan untuk
memperbaiki proses Stok Opname mereka.
Setelah menganalisa informasi yang ada dengan menggunakan poin-

poin untuk mengidentifikasi goals, maka telah didapat goals untuk modul Stok
Barang:
Tabel 1. Tabel Goals
Nomor Goal Nama Goal

G1 Memonitor Perubahan Jumlah Barang
G2 Memonitor Barang Pesanan yang masuk
G3 Memonitor Barang yang terjual
G4 Membuat Stok Opname lebih mudah untuk dilakukan
Setelah mengidentifikasi goals, saatnya mengidentifikasi stakeholders dan

agents. Berikut adalah poin-poin yang dapat dilakukan untuk identifikasi
stakeholders, yaitu:
a. Suatu Goal dapat mengaitkan beberapa Stakeholder.

b. Setiap perwakilan yang berpengaruh dalam pencapaian goal dapat disebut
stakeholder.
c. Orang yang mewakili perusahaan dalam permintaan sistem ataupun
memiliki peran dalam Analisanya dapat disebut stakeholder.
Berikut adalah poin-poin yang dapat dilakukan untuk identifikasi agents,

yaitu:
14
a. Setidaknya ada satu agent yang bertanggung jawab untuk penyelesaian
goal tersebut.
b. Agent yang berbeda dapat bertanggung jawab untuk penyelesaian goal
yang sama di waktu yang berbeda.
c. Agent bisa sebagai sistem, organisasi ataupun orang.
Dari informasi yang telah dikumpulan, diketahui bahwa Apotek Ananda

memiliki lima modul dan memiliki tiga stakeholders, yaitu: pemilik, apoteker
dan kasir. Agents dapat berupa entitas maupun sistem. Peneliti menggunakan
sistem yang digunakan untuk menjadi agents dan menggunkan kode tersendiri
untuk mengetahui agentsnya, yaitu:
• Master Data (MST)

• Pemesanan (ORD)
• Barang Masuk (IN)
• Stok Barang (ORD)
• Penjualan (SLS)
• Sumber Daya Manusia (SDM)
Untuk identifikasinya kita akan gunakan contoh pada Goal 1(G1). Stok
Barang dapat diketahui oleh pemilik dan apoteker. Pemilik perlu mengetahui
agar dapat mengatur pemesanan barang dan apotek perlu mengetahui agar dapat
membuat resep obat. Kedua peran ini dapat kita kaitkan pada poin b pada
identifikasi stakeholder. Perubahan jumlah barang tidak dapat dimonitor jika
tidak dimonitori langsung oleh pemilik dan apoteker.
Untuk mengidentifikasi agentnya, disini peneliti menggunakan poin c.

Diketahui bahwa sistem ini memerlukan lima modul yang salah satunya adalah
Stok Barang. Untuk G1 peneliti menggunakan Modul Penjualan, dikarenakan
diperlukannya data penjualan agar Stok Barang dapat berkurang. Setelah
melakukan tahapan Identify maka, tahapan ini akan menghasilkan goals beserta
stakeholders dan agentsnya, berikut adalah hasil tahapannya:
15
Tabel 2. Tabel Goals 2
Nomor Nama Goal Stakeholder Agents

Goal
G1 Memonitor Perubahan Jumlah Barang Pemilik, Apoteker INV, SLS
G2 Memonitor Barang Pesanan yang Pemilik INV
masuk
G3 Memonitor Barang yang terjual Pemilik INV, SLS
G4 Membuat Stok Opname lebih mudah Pemilik INV
untuk dilakukan
3.1.3. Organize
Pada tahap ini, goals akan diklasifikasikan menjadi maintenance dan
achievement goals. Setelah diklasifikasikan goals akan di urutkan berdasarkan
ketergantungannya yang nantinya akan menghasilkan sebuah goal topography.
Untuk mengklasifikasikannya, berikut adalah poin-poin yang dapat dilakukan
untuk mengidentifikasi Achievement Goals, yaitu:
a. Perlu mengetahui apakah pencapaian goal ini bersifat mandiri?

b. Perlu mengetahui apakah pencapaian goal ini bergantung kepada
penyelesaian goal lain?
c. Achievement Goals dapat diidentifikasi dengan menggunakan kata kunci
seperti make, improved, speed up, increase, satisfied, completed, allocated,
etc.
d. Achievement goal relatif bersifat mandiri.
Berikut adalah poin-poin yang dapat dilakukan untuk mengidentifikasi

Maintenance Goals, yaitu:
a. Perlu mengetahui apakah goal ini memastikan bahwa kondisi dari goal itu
bersifat true?
16
b. Maintenance goal cenderung dioperasionalkan sebagai tindakan yang
mencegah kondisi-kondisi tertentu tidak tercapai dalam sistem.
c. Maintenance Goals dapat diidentifikasi dengan menggunakan kata kunci
seperti keep, ensure, avoid, know, monitor, track, provide, supply, etc.
Pada tahapan ini, peneliti banyak menggunakan poin c dalam menentukan

jenis goal. Sebagai contoh: pada G4(Membuat Stok Opname lebih mudah untuk
dilakukan), dapat kita lihat bahwa kata kerja make berada dalam klasifikasi
Achievement goal dan pada G2(Memonitor Barang Pesanan yang masuk)
bahwa kata kerja monitor merupakan Maintenance Goal. Berikut adalah hasil
klasifikasi Goal untuk modul stok barang:
Tabel 3. Tabel Tipe Goals
Nomor Nama Goal Tipe Goal

Goal
G1 Memonitor Perubahan Jumlah Barang Maintenance
G2 Memonitor Barang Pesanan yang Maintenance
masuk
G3 Memonitor Barang yang terjual Maintenance
G4 Membuat Stok Opname lebih mudah Achievement
untuk dilakukan
Setelah Goals Telah di klasifikasikan, saatnya mengurutkan goal tersebuat

berdasarkan ketergantungannya, goal dependency memiliki tiga macam, yaitu:
a. Predence dependency: Ketergantungan antara G1 dan G2, bahwa G1 harus

diselesaikan sebelum menuju G2.
b. Contract dependency: Ketergantungan antara G1 dan G2, bahwa G2 harus
tercapai jika G1 muncul.
17
c. Agent dependency: Ketergantungan antara G1 dan G2, bahwa agent yang
bertanggung jawab atas G1 harus menyelesaikan G1 terlebih dahulu sebelum
agent yang bertanggung jawab atas G2 menyelesaikan G2.
Berikut adalah poin-poin yang dapat ditanyakan dalam identifikasi goals

dependency:
a. Goals apa yang menjadi syarat untuk goal ini?

b. Goals apa yang harus mengikuti goal ini?
c. Goals apa yang harus diselesaikan jika goal ini sudah tercapai?
Untuk contoh, bisa dilihat pada G1 dan G4. Untuk dapat melakukan Stok Opname,
Stok Barang harus pada kondisi terbaru, jika tidak pastinya Hasil Stok Opname menjadi
tidak benar. Sehingga ketergantugan dari kedua Goal ini adalah G1 < G2.
Setelah goal dependency telah diidentifikasi, maka akan terbentuknya goal

topography, berikut gambarnya:
Gambar 4. Hasil Goal Dependency
3.1.4. Refine
Tahapan ini sudah memasuki Goal Refinement. Pada tahapan ini goals yang
sudah dikalsifikasikan akan dilanjutkan dengan menidentifikasi obstacle, scenario dan
constraints.
Berikut adalah poin-poin yang dapat diakukan untuk mengidentifikasi

obstacles:
a. Kalimat yang mengilustrasikan kondisi yang dapat menghambat pencapaian

suatu goal.
b. Bisa juga ilustrasi dimana suatu goal yang sedang dihambat oleh goal lain.
18
c. Agent yang gagal dalam mencapai goal dapat diidentifikasikan obstacle.
d. Obstacle juga dapat muncul ketika suatu goal yang memiliki kontrak dengan
goal lain gagal.
Peneliti akan mengambil contoh pada G4(Membuat Stok Opname lebih mudah
untuk dilakukan). Banyak hal yang dapat menyebabkan kegagalan dalam keberhasilan
suatu goal. Contohnya pada G4: salah satu obstaclenya adalah Tidak terjadinya
perubahan jumlah barang pada Stok Barang atau Tidak dapat memonitor Stok
Opname. Dua contoh diatas berdasarkan dari poin-poin yang telah dijelaskan.
Setelah mengetahui obstacles dari G4, akan diidentifikasi alasan atau scenario
dari obstacles yang telah didapat. Berikut adalah poin-poin yang dapat diakukan untuk
mengidentifikasi scenario:
a. Mempertanyakan dan mempertimbangkan suatu goal, apa yang terjadi jika

goal tidak tercapai
b. Apa situasi yang dapat mengakibatkan hambatan-hambatan dalam
pencapaian goal?
c. Mempertanyakan mengapa goal yang inginkan tidak tercapai.
Poin-poin diatas mempertanyakan alasan dari suatu goal tidak berhasil, sama
serperti Tidak dapat memonitor Stok Opname, dengan menggunakan poin c, maka
Stok Opname tidak dapat dimonitor dikarenakan tidak memiliki ID untuk
membedakan setiap kegiatan stok opname.
Setelah mengetahui obstacles dan scenario dari goal yang dituju, saatnya
menidentifikasi constraints. Berikut adalah poin-poin yang dapat diakukan untuk
mengidentifikasi constraints:
a. Mempertanyakan apakah pernyataan ini menentukan beberapa requirements

yang harus dipenuhi?
b. Mencari penghubung temporal seperti: during, before, after.
c. Mencari pernyataan yang dapat membatasi tercapainya sebuah goal.
19
Jika scenario lebih menjelaskan alasan mengapa suatu goal tidak dapat tercapai,
maka constraint akan menjelaskan hal-hal yang dapat membuat suatu goal tercapai
dengan baik. Constraint dapat diidentifikasi dengan menggunakan poin-poin diatas.
Hal yang dapat membuat G4 tercapai adalah memiliki ID tersendiri setelah
melakukan proses stok opname, mengetahui penyebab selisih barang pada proses
opname. Sesuai dengan poin c, memiliki ID tersendiri setelah melakukan proses
stok adalah hal yang dapat menghambat keberhasilan suatu goal jika tidak dilakukan.
3.1.5. Elaboration
Tujuan dari Refinement adalah untuk mempertegas hasil yang telah didapat,
sehingga pada tahapan ini, hasil Analisa yang telah didapat akan dilihat lagi apakah
terdapat goals yang tersembunyi. Goals ini dapat diketahui dengan melihat hasil pada
tahapan refinement.
Setelah kita melakukan tahapan refinement, diketahui bahwa G4 memiliki

obstacles yaitu Tidak dapat memonitor Stok Opname, hal ini membantu peneliti
dalam menemukan sebuah goals yang tersembunyi.
Setelah goal baru telah diketahui, maka analisa akan kembali lagi ke tahapan identify.
20
3.1.6. Operationalize
Setelah semua tahapan telah dilakukan, saatnya merangkumnya menjadi sebuah
Goal Schema ditambah dengan adanya Operational Schema yang nantinya akan
digunakan untuk membuat Software Spesification Document (SRS). Berikut adalah
contoh dari Goal Schema yang selengkapnya bisa dilihat di lampiran:
Gambar 5. Contoh Goal Schema
Goal Schema diatas menjelaskan kebutuhan yang dapat digunakan pada SKPL,
untuk functional requirement peneliti dapat melihat pada action yang ada pada
Operational Schema, berikut adalah Operational Schema dari Goal Schema yang
bersangkutan:
21
Gambar 6. Contoh Action Schema
Dari hasil schema yang telah dibuat, peneliti dapat merubah schema ini
kedalam SRS. Action Schema merupakan fungsionalitas yang dapat digunakan pada
sistem. Seperti pada gambar diatas kita dapat membuat fungsi stok opname, dimana
data input yang harus digunakan telah dijelaskan pada Action Schema.
22
Gambar 7. Skenario Kelola Stok Opname
Jika dilihat pada gambar diatas, action yang dijelaskan pada Goal schema dapat
digunakan pada SRS.
3.2. Implementasi dan Pengujian Perangkat Lunak

Setelah peneliti telah melakukan implementasi metode GBRAM dan menghasilkan
Goal Schema dan Software Spesification Document (SRS). Saatnya untuk melakukan
proses develop Sistem Informasi Apotek Ananda. Pengimplementasian Sistem
dilakukan berdasarkan SRS yang telah dibuat. Fungsionalitas yang dibangun juga
mengikuti dari dokumen SRS yang telah ada. Pada tahap ini peneliti akan memberikan
contoh sistem berdasarkan goal yang telah dilakukan. Berdasarkan goal yang telah
dianalisis, goal tersebut masuk kedalam modul Stok Barang. Berikut adalah penjelasan
23
dari Modul Stok Barang pada Stok Barang, untuk selengkapnya dapat dilihat pada
lampiran.
Gambar 8. Halaman Stok Barang
Gambar diatas menunjukkan menu untuk memonitor stok barang. Sesuai

dengan G1 (Memonitor Perubahan Jumlah Barang), menu stok barang ini dapat
memantau perubahan stok barang, jumlah stok barang akan berubah setiap kali ada
barang yang masuk ataupun barang yang terjual.
Gambar 9. Halaman Daftar Barang Masuk
24
Gambar 10. Halaman Input Barang Masuk
Gambar 11. Halaman Detail Barang Masuk
Pada Gambar-gambar diatas menunjukkan submodul untuk melakukan proses

barang masuk, dimana pada menu ini sesuai dengan G2 (Memonitor Barang Pesanan
yang masuk
) pengguna dapat memonitor kegiatan barang masuk.
Gambar 12. Halaman Daftar Stok Opname
25
Gambar 13. Halaman Input Stok Opname
Gambar diatas menunjukkan submodul untuk melakukan proses stok opname.

sesuai pada G4 (Membuat Stok Opname lebih mudah untuk dilakukan) dan G5
(Memonitor Stok Opname), submodul ini dapat melakukan pengecekan barang melalui
sistem, sistem akan mengetahui apakah jumlah barang pada sistem sama dengan
jumlah barang pada kondisi yang sebenarnya dan juga dengan informasi itu pengguna
dapat mengecek langsung apakah selisih barang tersebut dikarenakan hilang,
kadaluarsa atau rusak.
26
4. ANALISIS HASIL
Pada bab ini, peniliti akan menjelaskan hasil analisanya dari implementasi Goal-
Based Requirements Analysis Method (GBRAM). Hasil analisa akan dijelaskan
berdasarkan tiap tahap dalam GBRAM, manfaat dari setiap proses, kelebihan dan
kekurangan dari GBRAM. Pada bab ini juga akan dijelaskan cara peneliti dalam
memvalidasi hasil dari implementasi GBRAM. Berikut penjelasannya:
4.1. Hasil Implementasi

Dari implementasi yang telah dilakukan, peneliti telah menemukan lima modul
yaitu:
a. Pemesanan (ORD):
Modul Pemesanan memiliki dua Goals dengan Pemilik sebagai
stakeholdernya dan INV, ORD dan MST sebagai agentsnya. Dari modul
ini terbentuklah goal topography dengan sebagai berikut:
Gambar 14. Goal Topography Pemesanan
b. Stok Barang (INV):

Modul Stok Barang memiliki lima Goals dengan Pemilik dan Apoteker
sebagai stakeholdernya dan INV, SLS, ORD dan MST sebagai
agentsnya. Dari modul ini terbentuklah goal topography dengan sebagai
berikut:
27
Gambar 15. Goal Topography Stok Barang
c. Sumber Daya Manusia (SDM):

Modul SDM memiliki tiga Goals dengan Pemilik sebagai
stakeholdernya dan SDM sebagai agentsnya. Dari modul ini
terbentuklah goal topography dengan sebagai berikut:
Gambar 16. Goal Topography SDM
d. Master Data (MST):

Modul Master Data memiliki empat Goals dengan Pemilik sebagai
stakeholdernya dan MST sebagai agentsnya. Dari modul ini
terbentuklah goal topography dengan sebagai berikut:
28
Gambar 17. Goal Topography Master
e. Penjualan (SLS)
Modul Penjualan memiliki tiga Goals dengan Apoteker dan Kasir
sebagai stakeholdernya dan SLS dan MST sebagai agentsnya. Dari
modul ini terbentuklah goal topography dengan sebagai berikut:
Gambar 18. Goal Topography Penjualan
29
4.2. Manfaat tiap proses
Setelah menjalani tiap proses dari metode GBRAM, peneliti menemukan
manfaat dari adanya tiap proses tersebut, yaitu:
• Explore : Peneliti dapat lebih mudah melakukan

pengumpulan data, Karena informasi yang dapat dikumpulkan dari
Stakeholders dapat berupa dokumen-dokumen maupun wawancara.
• Identify : Dengan adanya Goals, peneliti dapat lebih
mudah dalam merancang sistem beserta fungsionalitasnya.
• Organize : Peneliti dapat mengetahui kriteria goals.
• Refine : Peneliti dapat mengetahui apa yang menyebabkan
suatu hal yang dapat menghambat dan mempercepat pencapaian goal.
• Elaboration : Peneliti dapat menemukan goal-goal yang tersembunyi.
• Operationalize : Mempermudah peneliti dalam mengembangkan sistem,
Karena didukung oleh Goal Schema beserta dengan Operational
Schema. Dengan ini, proses dari analisa GBRAM menuju SRS dapat
lebih mudah.
4.3. Kelebihan dan Kekurangan

Peneliti menemukan beberapa kelebihan dan kekurangan dari hasil
melakukan implementasi GBRAM, yaitu:
• Kelebihan :
o Metode ini mempermudah peneliti dan juga Stakeholders dalam
berkomunikasi dan mengerti atas requirements yang diinginkan.
o Peneliti juga dapat membantu stakeholders yang tidak mengerti
sepenuhnya atas requirements yang mereka inginkan.
o Metode ini menyediakan saran bersifat menentukan untuk
menganalisa goals yang belum diketahui oleh stakeholders.
30
• Kekurangan : Metode ini sangat cocok untuk menemukan functional
requirements, tapi metode ini belum memadai dan membuktikan dalam
penentuan nonfunctional requirements.
4.4. Validasi Analisis

Untuk mencapai keberhasilan dalam penelitian ini, dibutuhkan validasi dari
stakeholders untuk mengetahui apakah mereka telah menyetujui goals yang telah
dibuat berdasarkan pengumpulan data sebelumnya dan sistem yang telah sesuai
dengan harapan mereka. Pada kasus ini, peneliti melakukan validasi kepada para
stakeholders dengan cara menunjukkan langsung hasil dokumen yang telah dibuat.
Dokumen yang diberikan kepada stakeholders ada tiga yaitu dokumen
Requirements, dokumen Goal Schema dan dokumen User Acceptance Test(UAT).
Dokumen Requirements adalah hasil dari requirements dari permintaan

stakeholders dimana dokumen ini menjelaskan modul-modul yang diinginkan.
Dokumen Goal Schema adalah hasil dari implementasi GBRAM, dimana dokumen
ini mendeskripsikan semua Goals yang telah dibuat. User Acceptance Test(UAT)
digunakan untuk validasi apakah sistem yang telah dibuat telah sesuai dengan
requirements yang diinginkan. Semua dokumen dapat dilihat pada lampiran beserta
form validasi dokumen yang telah ditanda tangani oleh para Stakeholders.
31
5. KESIMPULAN
5.1. Kesimpulan
Berdasarkan penelitian yang telah dilakukan maka kesimpulan yang dapat diambil
adalah
1. Implementasi GBRAM pada Sistem Informasi Apotek Ananda menghasilkan

total 17 goals dengan 5 modul yaitu: Master, Pemesanan, Stok Barang,
Penjualan dan Sumber Daya Manusia.
2. Agents yang terlibat dalam pencapaian goals adalah: MST, ORD, INS, INV,
SDM, SLS, RCP
3. Stakeholders yang terlibat dalam pencapaian goals adalah: Pemilik, Kasir dan
Apoteker
4. Pengimplementasian GBRAM membuat stakeholders lebih mudah dalam
memaparkan apa yang mereka inginkan terhadapa sistem mereka.
5. Stakeholders juga dapat lebih mudah dalam memvalidasi hasil analisa dari
peneliti karena hasil dari GBRAM sendiri yaitu Goal Schema menggunakan
Bahasa yang mudah dimengerti oleh para stakeholders.
6. Setiap tahapan dari GBRAM membantu peneliti dalam menganalisa goal dan
mencari alternatif jika goal tersebut tidak terjadi.
7. GBRAM menyediakan saran bersifat menentukan untuk menganalisa goals
yang belum diketahui oleh stakeholders.
8. GBRAM sangat cocok dalam membantu peneliti dalam menentukan functional
requirements.
9. GBRAM belum bisa memadai dan membuktikan dalam menentukan
nonfunctional requirements.
32
DAFTAR PUSTAKA
[1] J. Bano, N. Hundewale and S. Aljahdali, "Goal Oriented Requirements Engineering- A

Review," 24th International Conference on Computers and Their Applications in
Industry and Engineering, 2011.
[2] A. I. Anton, "Goal-Based Requirement Analysis," Proceedings of the Second

International Conference on, 1996.
[3] A. Lapouchnian, "Goal-Oriented Requirements Engineering: An Overview of the

Current Research," University of Toronto, 2005.
[4] T. Kelly and R. Weaver, "The Goal Structuring Notation - A Safety Argument Notation,"
Proceedings of the dependable systems and networks 2004 workshop on assurance
cases, 2004.
[5] C. Ponsard, R. Darimont and A. Michot, "Combining Models, Diagrams and Tables for
Efficient Requirements Engineering: Lessons Learned form the Industry," INFORSID,
2015.
[6] F. Adikara, B. Sitohang and B. Hendradjaya, "Penerapan Goal Oriented Requirements

Engineering(GORE) Model (Studi Kasus : Pengembangan Sistem Informasi Penjaminan
Mutu Dosen (SIPMD) Pada Institusi Pendidikan Tinggi)," SESINDO 2013 , 2013.
[7] I. M. Shofi and E. K. Budiarjo, "Klasifikasi Metode Goal Oriented Requirement

Engineering (GORE) dan Kemungkinan Untuk Mengembangkan Aplikasi
Kepemerintahan," Semantik 1.1, 2011.
[8] L. K. Mazuryk, P. v. Eck and R. Wieringa, "A Survey of Requirements Engineering

Methods for Pervasive Services," 2006.
[9] S. Chawla and S. Srivatava, "Goal oriented Requirement Analysis for Web
Applications," International Journal of Modeling and Optimization 2.3 , p. 192, 2012.
[10] K. Oshiro, K. Watahiki and M. Saeki, "Goal-Oriented Idea Generation Method for
Requirements Elicitation," RE, pp. 363-364, 2003.
[11] A. v. Lamsweerde, "Goal-Oriented Requirements Engineering: A Guided Tour,"

Proceedings. Fifth IEEE International Symposium on, pp. 249-262, 2001.
[12] M. Bolton, "User Acceptance Testing – A Context-Driven Perspective," SOFTWARE

QUALITY CONFERENCE, p. 535, 2007.
33
[13] A. I. Anton, Goal Identification and Refinement in the Specification of Software-Based
Information Systems, Atlanta, 1997.
[14] F. Ervianti, Requirement Engineering Management Tools (REMT) untuk Pengembangan

Integrated Distance Education Application (IDEA) Telkom University, Bandung, 2016.
[15] H. Kaiya, H. Horai and M. Saeki, "AGORA: Attributed Goal-Oriented Requirements

Analysis Method," Requirements Engineering, 2002. Proceedings. IEEE Joint
International Conference on, pp. 13-22, 2002.
[16] M. U. Bokhari and S. T. Siddiqui, "Metrics for Requirements Engineering and

Automated Requirements Tools," Proceedings of the 5th National Conference, 2011.
[17] A. I. Anton, Goal Identification and Refinement in the Specification of Software-Based

Information Systems, Atlanta: Thesis, Georgia Institute of Technology, 1997.
[18] R. Goel and N. Gupta, Survey on Acceptance Testing Technique, New Delhi, INDIA:
International Association of Scientific Innovation and Researach (IA SIR), 2014.
[19] M. Bano and D. Zowghi, "Users’ Involvement in Requirements Engineering and System
Success," 978-1-4799-1011-3/13/$31.00 c, 2013.
34
LAMPIRAN
Lampiran 1. Wawancara dengan Pemilik Apotek Ananda
35
36
Lampiran 2. Form Validasi Dokumen
37
Lampiran 3. Goal Schema
GOAL SCHEMA
GS 1:
Goal : Mengetahui Barang-Barang yang harus dipesan
Type : Maintenance
Description : User akan mengetahui apa saja yang harus dipesan sebelum
melakukan pemesanan
Action: Notif Pesanan
Agents: Pemesanan, Stok Barang
Stakeholder: Permilik
Constraints:
1. Barang yang ingin dipesan harus sudah terdaftar di sistem.

2. Jumlah Barang pada sistem harus lebih sedikit dari jumlah
minimal barang
3. Sistem harus menampilkan notifikasi mengenai barang yang harus
dipesan.
Obstacles:
1. Tidak Mengetahui barang-barang yang harus segera dipesan.

2. Tidak dapat memesan barang.
PreConditions:
1. Barang sudah terdaftar di sistem

2. PBF sudah diketahui sebelum memesan barang
PostConditions:
1. Barang-barang yang ingin dipesan sudah diketahui
38
SubGoal: Menyediakan Dokumentasi Data Pemesanan
GS 2:
Goal: Menyediakan Dokumentasi Data Pemesanan
Type: Maintenance
Description: Setiap Pemesanan Barang akan disimpan berdasarkan Kode IDnya
Action: KelolaPemesanan
Agent: Pemesanan
Stakeholder: Pemilik
Constraints:
1. Setiap pemesanan barang harus memiliki kode ID.
Obstacles:
1. Tidak mengetahui dokumentasi data pemesanan

2. Tidak dapat memesan barang.
PreConditions:
1. Barang telah terdaftar di sistem

2. Telah melakukan pemesanan barang
PostConditions:
1. Dokumentasi pemesanan barang telah tersedia
SubGoals:
39
GS 3:
Goal: Memonitor Perubahan Jumlah Barang
Type: Maintenance
Description: Stok Barang pada sistem akan menyesuaikan dengan stok barang asli
sesuai dengan barang masuk dan yang terjual.
Action: StokBarang
Agents: Stok Barang, Penjualan
Stakeholders: Pemilik, Apoteker
Constraints:
1. Data Pemasukkan Barang dan Data Penjualan Barang terbaru

sudah masuk kedalam sistem
Obstacles:
1. Perubahan jumlah barang tidak terjadi.

2. Pemesanan barang terganggu.
3. Dapat terjadi kekosongan barang ketika membuat resep obat.
40
PreConditions:
1. Detail Barang sudah terdaftar disistem
PostConditions:
1. Perubahan jumlah barang dapat dimonitor
SubGoals:
1. Membuat Stok Opname lebih mudah untuk dilakukan
GS 4:
Goal: Membuat Stok Opname lebih mudah untuk dilakukan
Type: Achievement
Description: Sistem mempermudah user dalam melakukan proses Stok Opname
Action: Stok Opname
Agent: Stok Barang
Constraints:
1. Proses kalkulasi pada Stok Barang harus benar

2. Setiap Stok Opname memiliki kode ID
41
3. Dapat mengetahui keadaan selisih barang
Obstacles:
1. Tidak dapat melakukan Stok Opname

2. Tidak dapat memonitor Stok Opname
PreConditions:
1. Detail Barang sudah terdaftar disistem
PostConditions:
1. Telah melakukan Stok Opname
SubGoals: Memonitor Stok Opname
GS 5:
Goal: Memonitor Barang Pesanan yang Masuk
Type: Maintenance
Description: Dapat mengetahui barang pesanan apa saja yang masuk ke dalam stok
barang
42
Action: BarangMasuk
Agents: Stok Barang, Pemesanan
Constraints:
1. Mengetahui tanggal barang masuk

2. Memiliki ID untuk setiap pemasukan barang
3. Mengetahui ID Pemesanan
Obstacles:
1. Tidak dapat memonitor barang pesanan yang masuk

2. Perubahan jumlah Stock Barang terganggu
PreConditions:
1. Telah melakukan pesanan barang
PostConditions:
1. Barang pesanan telah masuk
SubGoals:
GS 6:
43
Goal: Memonitor Barang yang Terjual
Type: Maintenance
Description: Dapat mengetahui barang apa saja yang keluar dari dalam stok barang
Action: Transaksi
Agent: Penjualan, Stok Barang
Stakeholder: Pegawai
Constraints:
1. Mengetahui tanggal barang terjual

2. Memiliki ID untuk setiap penjualan barang
Obstacles:
1. Tidak dapat memonitor barang yang terjual

2. Perubahan jumlah Stock Barang terganggu
PreConditions:
1. Telah melakukan proses penjualan barang
PostConditions:
1. Barang yang terjual dapat dimonitor
SubGoals:
44
45
GS 7:
Goal: Memonitor Stok Opname
Type: Maintenance
Description: User dapat memonitor Stok Opname yang telah dilakukannya
Action: StokOpname
Agent: Stok Barang
Constraints:
1. Setiap Stok Opname memiliki Kode ID

2. Memiliki tanggal Stok Opname
Obstacles:
1. Tidak dapat memonitor Stok Opname
PreConditions:
1. Telah melakukan Stok Opname
PostConditions:
1. Stok Opname dapat dimonitor
SubGoals:
46
GS 8:
Goal: Menyediakan Dokumentasi Resep Obat
Type: Maintenance
Description: Setiap resep obat yang dibuat akan didokumentasi
Action: KelolaResep
Agent: Resep
Stakeholder: Apoteker
Constraints:
1. Sistem Pembuatan Resep dilengkapi dengan kode ID

2. Memiliki nama dokter dan pasien
3. Memiliki keterangan obat
Obstacles:
1. Resep tidak terdokumentasi dengan baik

2. Proses Transaksi terganggu
3. Jumlah Barang pada Stok Barang tidak berubah
PreConditions:
1. Memiliki detail resep yang ingin dibuat

2. Data barang terdaftar di sistem
PostConditions:
1. Resep terdokumentasi dengan baik
SubGoals: Memonitor Penjualan Resep dan Barang
47
GS 9:
Goal: Membuat Dokumentasi Transaksi Penjualan Lebih Mudah
Type: Achievement
Description: User akan lebih mudah dalam mendokumentasikan penjualannya.
Action: Transaksi
Agent: Penjualan
Stakeholder: Pemilik, Kasir
Constraints:
1. Jumlah barang pada stok barang sudah diperbarui.

2. Sistem harus mengkalkulasikan transaksi dengan benar.
3. Mengetahui resep yang dapat dijual.
Obstacles:
1. Proses Dokumentasi Transaksi menjadi terganggu.

2. Perubahan jumlah barang tidak akan berubah.
PreConditions:
1. Stock Barang tersedia.
PostConditions:
1. Dokumentasi Transaksi menjadi lebih mudah
48
SubGoals: Menyediakan Dokumentasi Resep Obat
GS 10:
Goal: Mengalokasi Barang yang akan dijual
Type: Achievement
Description: Sistem akan mengatur tata letak barang-barang di apotek ananda
Action: AlokasiBarang
Agent: Penjualan
Stakeholder: Pemilik, Kasir
Constraints:
1. Setiap slot tempat harus mempunyai ID.
Obstacles:
1. Tidak dapat melakukan pengalokasian barang.
PreConditions:
49
1. Data barang telah tersedia di sistem.
PostConditions:
1. Barang telah dialokasikan.
SubGoals:
GS 11:
Goal: Menyimpan Data Diri Pegawai
Type: Achievement
Description: Mengelola Data Diri Pegawai
Action: PengaturanPegawai
Agent: SumberDayaManusia
50
Constraints:
1. Data diri harus lengkap
Obstacles:
1. Data Pegawai tidak tersimpan
PreConditions:
1. Rincian data pegawai telah diketahui
PostConditions:
1. Data telah tersimpan
SubGoals:
51
GS 12:
Goal: Mengetahui Peran Pegawai
Type: Maintenance
Description: Dapat mengetahui setiap deskripsi pekerjaan setiap pegawai
Action: Jobdesk
Constraints:
1. Data Peran diketahui.
Obstacles:
1. Tidak mengetahui peran pegawai
PreConditions:
1. Dapat mengakses sistem
PostConditions:
1. Jobdesk pegawai telah diketahui
SubGoals: Menyimpan Data Diri Pegawai
52
GS 13:
Goal: Mengalokasikan Akes Menu Pegawai dengan bebas
Type: Achievement
Description: Pemilik dapat mengatur menu apa saja yang dapat diakses oleh
pegawainya pada sistem
Action: PemetaanMenu
Constraints:
1. Pegawai harus memiliki Akun

2. Semua pilihan menu dapat diakses
Obstacles:
1. Tidak dapat mengalokasi menu untuk pegawai

2. Tidak dapat mengakses sistem
PreConditions:
1. Jobdesk yang diinginkan telah diketahui
PostConditions:
53
1. Alokasi menu berhasil
SubGoals:
GS 14:
Goal: Melengkapi Data Barang
Type: Achievement
Description: Pemilik dapat melengkapi data-data master barang untuk digunakan

pada menu-menu yang lain
Action: MasterBarang
Agent: DataMaster
Stakeholder: Pemesanan, Penjualan, Stok Barang, Resep
Constraints:
1. Data diisi dengan lengkap

2. Memiliki kode barang
Obstacles:
54
1. Data Barang tidak dapat terlengkapi
PreConditions:
1. Mengetahui data yang ingin disimpan
PostConditions:
1. Data telah dilengkapi
SubGoals:
55
GS 15:
Goal: Melengkapi Data PBF (Pedagang Besar Farmasi)
Type: Achievement
Description: Pemilik dapat melengkapi data-data master PBF untuk digunakan pada
menu-menu yang lain
Action: MasterPbf
Agent: DataMaster
Constraints:
Obstacles:
PreConditions:
PostConditions:
SubGoals:
56
GS 16:
Goal: Melengkapi Data Kategori
Type: Achievement
Description: Pemilik dapat melengkapi data-data master Kategori untuk digunakan

Action: MasterKategori
Agent: DataMaster
Constraints:
Obstacles:
PreConditions:
PostConditions:
SubGoals:
57
GS 17:
Goal: Melengkapi Data Satuan
Type: Achievement
Description: Pemilik dapat melengkapi data-data master Satuan untuk digunakan

Action: MasterSatuan
Agent: DataMaster
Constraints:
Obstacles:
PreConditions:
PostConditions:
SubGoals:
58
Lampiran 4. Operational Schema
ACTION DEFINITION
ACTION GS 1:
Action NotifPesanan
Agent: Pemesanan, Stok Barang
Read:
1. Barang,
2. Jumlah Barang
3. Minimal Jumlah Barang
Changes: Daftar Barang yang harus dipesan
Assumes:
1. Jumlah Barang kurang dari Jumlah Minimal Barang
Result: Barang dipesan
End NotifPesanan
59
ACTION GS 2:
Action KelolaPemesanan
Agent: Pemesanan
Read:
1. Barang
2. Pbf
3. Jumlah Barang
4. Harga Barang
5. Discount
6. PPN
7. Total Harga
Changes: Data Pemesanan
Assumes:
1. PBF telah diketahui

2. PBF memiliki stok barang yang tersedia
Result: Data Pemesanan telah tersimpan.
End
60
ACTION GS 3:
Action StokBarang
Agent: Stok Barang
Read:
1. Barang
2. Satuan
3. Kategori
4. Jumlah Barang Masuk
5. Jumlah Barang Keluar
6. Stok Barang
Changes:
Assumes: Telah melakukan pemasukkan barang masuk dan barang keluar
Result: Jumlah barang pada stok barang akan berubah
End
61
ACTION GS 4:
Action StokOpname
Agent: Stok Barang
Read:
1. Barang
2. Jumlah Barang di sistem
3. Jumlah Barang pada keadaan yang sebenarnya
4. Keterangan
Changes: Status Barang
62
Assumes:
Result: Status Barang akan diketahui
End
ACTION GS 5:
Action BarangMasuk
Agent: Stok Barang, Pemesanan
Read:
1. Barang
2. Jumlah Barang
Changes: Data Barang Masuk, Stok Barang
Assumes: Barang Pesanan telah datang
Result: Dapat mengetahui kapan barang yang baru datang dimasukkan dan
akan berintegrasi dengan stok barang
End
ACTION GS 6:
Action Transaksi
Agent: Penjualan, Stok Barang
Read:
63
1. Barang / Resep
2. Jumlah Barang
3. Hargae
Changes: Stok Barang, Data Transaksi
Assumes: Barang telah terjual
Result: Dapat mengetahui kapan barang yang terjual dan stok barang
berkurang
End
ACTION GS 8:
Action KelolaResep
Agent: Resep
Read:
1. Barang
2. Jumlah Barang yang digunakan
3. Nama Pasien
4. Nama Dokter
5. Keterangan
Changes: Resep Obat
Assumes: Jumlah takaran obat dan jenisnya telah diketahui
Result: Resep Obat yang telah dibuat dapat dilihat dokumentasinya
End
64
ACTION GS 10:
Action AlokasiBarang
Agent: Penjualan
Read:
1. Slot Tempat
2. Nama Barang
Changes: Slot Tempat terisi
Assumes: Slot tempat telah disesuaikan dengan keadaan barang
Result: Barang-barang telah dialokasi ke slot tempat yang telah ditentukan
End
ACTION GS 11:
Action PengaturanPegawai
Read:
1. Nama Pegawai
2. Alamat
3. TTL
4. Kontak No
5. Pendidikan
Changes: Data Diri
Assumes: Semua Data Diri telah diketahui
65
Result: Data Diri Pegawai telah dimasukkan kedalam sistem
End
ACTION GS 12:
Action AturMenu
Read:
1. Nama Peran
2. Keterangan
3. Menu yang dapat diakses
Changes: Data Jobdesk
Assumes: Jobdesk sesuai dengan keadaan perusahaan
Result: Data-data jobdesk diketahui
End
ACTION GS 13:
Action PemetaanPengguna
Read:
1. Nama Jobdesk
2. Nama Pegawai
66
Changes: Data Jobdesk
Assumes: Minimal satu orang memiliki satu jobdesk
Result: Pemetaan Tugas telah dilakukan
End
ACTION GS 14:
Action MasterBarang
Agent: DataMaster
Read:
1. Nama Barang
2. KodeBarang
3. Kategori
4. Satuan
5. Minimal Kuantitas
6. Harga Barang
Changes: Data Barang
Assumes: Penentuan kode barang telah ditentukan sebelumnya
Result: Data Barang telah tersimpan
End
67
ACTION GS 15:
Action MasterPbf
Agent: DataMaster
Read:
1. Nama Pbf
2. Alamat Pbf
3. Kontak Pbf
4. Nama Pegawai Pbf
5. Kontak Pegawai Pbf
Changes: Data Pbf
Assumes:
Result: Data Pbf telah tersimpan
End
ACTION GS 16:
Action MasterSatuan
Agent: DataSatuan
Read:
1. Nama Satuan
2. Singkatan Satuan
Changes: Data Satuan
Assumes:
Result: Data Satuan telah tersimpan
68
End
ACTION GS 17:
Action MasterKategori
Agent: DataKategori
Read:
1. Nama Kategori
Changes: Data Kategori
Assumes:
Result: Data Kategori telah tersimpan
End
69
Lampiran 5. User Acceptance Test (UAT)
Berikut hasil dari User Acceptance Test yang telah dilakukan:
DOKUMENTASI USER ACCEPTANCE TEST

Nama Proyek Sistem Informasi Apotek Ananda
Studi Kasus Apotek Ananda
Penyedia Layanan Fakultas Informatika
Manager Proyek Alvin Khair
Tanggal Dokumen 3 Juli 2017
1. Kelola Akun
1.1. Input Data Akun
Deskripsi Prosedur Pengujian Data Input Benar Hasil yang Hasil Hasil Diuji Kesimpu
diharapkan Aktual Pengujian Oleh lan
Pembuata • Login sebagai • Nama Awal: Data yang Akun telah Sesuai Pemilik Valid
n Akun Pemilik / Admin Indra dimasukkan akan dibuat
untuk • Pilih Sub Modul • Nama Akhir: tersimpan di dengan
mengakse Master Akun Nura database dan username:
s sistem • Pilih Tambah Akun • Username: dapat melakukan indranura
• Submit Form indranura login ke sistem
• Alamat:
Perumahan
Rakyat No 20
• Telepon:0812
7106580
• Email:
indranura@g
mail.com
• Password:1nd
ra4nanda
• Gambar
70
• Jenis
Kelamin:
Laki-Laki
1.2. Edit Data Akun

Deskripsi Prosedur Pengujian Data Input Hasil yang Hasil Hasil Diuji Kesimpu
diharapkan Aktuan Pengujian Oleh lan
Pembuat • Login sebagai • Nama Awal: Data yang Akun telah Sesuai Pemilik Valid
an Akun Pemilik / Admin Dina Lusia dimasukkan akan diubah
untuk • Pilih Sub Modul • Nama Akhir: tersimpan di dengan
mengaks Master Akun Syam database dan username:
es sistem • Pilih Tambah Akun • Username: dapat melakukan dinasyam
• Submit Form dinasyam login ke sistem
• Alamat:
Perumahan
Rakyat No 80
• Telepon:0812
7126480
• Email:
dinasyam@g
mail.com
• Password:
Dina_Syam
• Gambar
• Jenis
Kelamin:
Perempuan
71
1.3. Hapus Data Akun
Deskripsi Prosedur Pengujian Data Input Hasil yang Hasil Diuji Oleh Hasil Kesimpu
diharapkan Aktual Pengujian lan
Penghap • Login sebagai Tombol Hapus Akun terhapus Akun Pemilik Sesuai Valid
usan Pemilik / dari system dan dengan
Akun Admin tidak bisa username:
dari • Pilih Sub melakukan login dinalusiasy
sistem Modul Master ke system dengan am
Akun akun yang terhapus
• Pilih Hapus bersangkutan dan tidak
pada Akun dapat
yang digunakan
diinginkan
1.4. Tampilkan Daftar Akun

Menampi • Login sebagai Tomboh Submodul Sistem Menampil Pemilik Sesuai Valid
lkan Pemilik / menampilkan kan daftar
Akun- Admin akun-akun yang akun yang
akun • Pilih Sub telah dibuat telah
yang Modul Master dibuat
telah Akun
tersimpa
n di
database
72
2. Kelola Peran
2.1. Input Data Peran
Deskripsi Prosedur Data Input Hasil yang Hasil Aktual Diuji Oleh Hasil Kesimpula
Pengujian diharapkan Pengujian n
Mengatur • Login sebagai • Nama Data yang Peran Apoteker Pemilik Sesuai Valid
Peran yang Pemilik / Akun: dimasukkan telah
dimiliki Akun Admin Dina akan ditambahkan ke
agara dapat • Pilih Sub Lusia tersimpan di akun dinasyam
mengakses Modul Syam database dan
menu-menu Pengguna • Peran: dapat
yang telah Peran Apoteker mengakses
disediakan • Pilih Tambah menu yang
• Submit Form sesuai
2.2. Edit Data Peran
Mengubah • Login sebagai • Nama Data yang Peran akun Pemilik Sesuai Valid
Peran yang Pemilik / Admin Akun: Dina dimasukkan dinasyam
dimiliki Akun • Pilih Sub Modul Lusia Syam akan telah
agara dapat Pengguna Peran • Peran: Kasir tersimpan di diganti
mengakses • Pilih Edit database dan menjadi
menu-menu • Submit Form dapat Kasir
yang telah mengakses
disediakan menu yang
sesuai
73
2.3. Hapus Data Peran
Menghapus • Login sebagai Tombol Hapus Akun yang Akun Pemilik Sesuai Valid
Peran yang Pemilik / Admin dipilih tidak dinasyam
dimiliki Akun • Pilih Sub Modul memiliki tidak
Pengguna Peran peran lagi memiliki
• Pilih Hapus peran
2.4. Tampilkan Daftar Pengguna Peran

Menampilkan • Login sebagai Tomboh Sistem Menampil Pemilik Sesuai Valid
Akun-akun yang Pemilik / Submodul menampilka kan akun
telah memiliki Admin n akun-akun yang
peran • Pilih Sub yang telah memiliki
Modul memiliki peran
Pengguna peran
Peran
3. Atur Menu Peran
3.1. Edit Menu Peran
Mengatur menu- • Login sebagai • Menu: Stok Data yang Peran Pemilik Sesuai Valid
menu yang Pemilik / Barang dimasukkan Apoteker
dapat diakses Admin • Menu: akan dapat
oleh peran yang • Pilih Sub Resep Obat tersimpan di mengakses
diinginkan Modul Atur • Peran: database dan menu stok
Peran Apoteker dapat barang dan
• Pilih peran mengakses resep obat
yang menu yang
diinginkan dipilih
• Memilih menu
• Submit Form
74
3.2. Hapus Menu Peran
Menghapus • Login sebagai • Menu: Stok Data yang Peran Pemilik Sesuai Valid
menu-menu Pemilik / Barang dipilih akan Apoteker
yang dapat Admin • Menu: terhapus di tidak dapat
diakses oleh • Pilih Sub Resep Obat database dan mengakses
peran yang Modul Atur • Peran: menu tidak menu stok
diinginkan Peran Apoteker dapat di barang dan
• Pilih hapus di akses resep obat
peran yang
diinginkan
• Memilih menu
• Submit Form
3.3. Tampilkan Daftar Peran

Menampilkan • Login sebagai Menampilka Menampila Pemilik Sesuai Valid
Daftar Peran Pemilik / n Daftar k semua
Admin Peran daftar
• Pilih Sub peran
Modul Atur
Peran
75
4. Resep Obat
4.1. Input Data Resep Obat
Pembuatan Resep • Login • Tanggal Data yang Resep Apoteker Sesuai Valid
Obat menggunakan akun Resep: diinput akan telah
yang memiliki 07/03/2017 menghasilka dibuat
akses ke menu • Nama n satu ID dengan ID
yang bersangkutan Dokter: Dr Resep dan AARSP20
• Pilih Sub Modul Fernando akan 1707031
Resep Obat • Nama tersimpan di
• Pilih Tambah Pasien: database,
• Submit Form Rayhan dan akan

Ramadhan bisa
• Keterangan: digunakan
Testing pada
• Nama transaksi
Barang [1]:
Paracetamol
mg 100
• Jumlah [1]:
5
• Nama
Barang [2]:
Sacch Lactis
q.s
• Jumlah [2]:2
76
4.2. Edit Data Resep Obat
Pembuatan Resep • Login • Tanggal Data yang Resep Apoteker Sesuai Valid
Obat menggunakan akun Resep: diinput akan dengan ID
yang memiliki 07/03/2017 menghasilka AARSP20
akses ke menu • Nama n satu ID 1707031
yang bersangkutan Dokter: Dr Resep dan telah
• Pilih Sub Modul Fernando akan diubah
Resep Obat • Nama tersimpan di
• Pilih Edit pada Pasien: A. database,
resep yang dituju Rayhan dan akan
• Submit Form Ramadhan bisa
• Keterangan: digunakan
Testing Edit pada
• Nama transaksi
Barang [1]:
Paracetamol
mg 100
• Jumlah [1]:
10
• Nama
Barang[2]:S
acch Lactis
q.s
• Jumlah[2]:5
77
4.3. Hapus Data Resep Obat
Penghapusan • Login • Tombol Data yang Resep Apoteker Sesuai Valid
Resep Obat menggunakan Hapus dipilih akan dengan ID
akun yang terhapus di AARSP20
memiliki database dan 1707031
akses ke menu tidak dapat telah
yang di akses dihapus
bersangkutan
• Pilih Sub
Modul Resep
Obat
• Pilih hapus di
resep yang
diinginkan
4.4. Tampilkan Daftar Resep Obat

Melihat Daftar • Login • Tombol Melihat Menampila Apoteker Sesuai Valid
Resep Obat menggunaka Hapus Daftar Resep k daftar
n akun yang Obat Resep
memiliki dengan ID
akses ke yang
menu yang berbeda
bersangkuta
n
• Pilih Sub
Modul
Resep Obat
78
4.5. Tampilkan Detail Resep
Melihat Detail • Login ID Resep: Melihat Setelah Apoteker Sesuai Valid
Resep Obat menggunaka AARSP20170703 Detail Resep memilih
berdasarkan ID n akun yang 1 Obat ID
memiliki berdasarkan AARSP20
akses ke ID 1707031,
menu yang sistem
bersangkuta menampilk
n an resep
• Pilih Sub yang telah
Modul dibuat
Resep Obat
• Pilih Resep
yang
diinginkan
5. Transaksi
5.1. Input Data Transaksi
Melakukan proses • Login • Cara Data yang Transaksi Kasir Sesuai Valid
transaksi menggunakan Pembayaran diinput akan telah
akun yang : CASH menghasilka dibuat
memiliki akses ke • Tanggal n satu ID dengan ID
menu yang Transaksi: Transaksi AATRX20
bersangkutan 07/03/2017 dan akan 1707031
• Pilih Sub Modul • Nama tersimpan di
Transaksi Barang: database
• Pilih Tambah Panadol
• Submit Form Merah box
79
• Jumlah
Barang: 2
• Harga:
72.000
• Discount: 0
• Total Harga:
72.000
• ID Resep:
AARSP201
707031
• Harga
Resep:
100.000
• Discount:
10%
• Total Resep:
90.000
5.2. Edit Data Transaksi

Melakukan • Login • Cara Data yang Transaksi Kasir Sesuai Valid
pengubahan pada menggunakan Pembayaran diinput akan dengan ID
proses transaksi akun yang : CASH menghasilka AATRX20
yang telah memiliki akses ke • Tanggal n satu ID 1707031
dilakukan menu yang Transaksi: Transaksi telah
bersangkutan 07/03/2017 dan akan diubah
• Pilih Sub Modul • Nama tersimpan di
Transaksi Barang: database
• Pilih Edit pada Panadol
Kode Transaksi Merah box
yang diinginkan • Jumlah
• Submit Form Barang: 2

• Harga:
72.000
80
• Discount: 0
• Total Harga:
72.000
• ID Resep:
AARSP201
707031
• Harga
Resep:
100.000
• Discount:
10%
• Total Resep:
90.000
5.3. Hapus Data Transaksi

Melakukan • Login Tombol Hapus Transaksi Transaksi Kasir Sesuai Valid
penghapusan pada menggunakan akan dengan ID
proses transaksi akun yang terhapus dari AATRX20
yang telah memiliki akses ke Database 1707031
dilakukan menu yang telah
bersangkutan dihapus
• Pilih Sub Modul
Transaksi
• Pilih Hapus pada
Kode Transaksi
yang diinginkan
81
5.4. Tampilkan Daftar Transaksi
Menampilkan • Login Menampilka Menampil Kasir Sesuai Valid
Daftar Transaksi menggunakan n Daftar kan daftar
yang telah dibuat akun yang Transaksi transaksi
memiliki akses ke yang telah dengan ID
menu yang dibuat yang
bersangkutan berbeda-
• Pilih Sub Modul beda
Transaksi
5.5. Tampilkan Detail Transaksi

Menampilkan • Login ID Transaksi: Menampilka Menampil Kasir Sesuai Valid
Detail Transaksi menggunakan AATRX2017070 n Detail kan Detail
yang telah dibuat akun yang 31 Transaksi Transaksi
memiliki akses ke yang telah dengan ID
menu yang dibuat AATRX20
bersangkutan beradasarkan 1707031
• Pilih Sub Modul ID
Transaksi
• Pilih pada Kode
Transaksi yang
diinginkan
82
6. Alokasi Barang
6.1. Input Data Alokasi Barang
Melakukan proses • Login • Kode RAK: Data yang Kode A1 Kasir Sesuai Valid
alokasi barang yang menggunakan A1 diinput akan telah
akan dijual akun yang • Nama menghasilka ditambahk
memiliki akses ke Barang [1]: n satu ID an kedalam
menu yang Amoxilin Alokasi dan database
bersangkutan • Nama akan
• Pilih Sub Modul Barang [2]: tersimpan di
Alokasi Barang Albumin database
• Pilih Tambah • Nama
• Submit Form Barang [3]:
Acarbose
6.2. Edit Data Alokasi Barang

Mengedit data • Login • Kode Data yang Barang Kasir Sesuai Valid
alokasi barang yang menggunakan Tempat: A1 diinput akan pada Kode
akan dijual akun yang • Nama menghasilka A1 telah
memiliki akses ke Barang[1]: n satu ID diubah
menu yang Amoxilin Alokasi dan kedalam
bersangkutan • Nama akan database
• Pilih Sub Modul Barang[2]: tersimpan di
Alokasi Barang Albumin database
• Pilih Edit pada ID
yang diinginkan
• Submit Form
83
6.3. Hapus Data Alokasi Barang
Mengedit data • Login Tombol Hapus Data Alokasi Kode A1 Kasir Sesuai Valid
alokasi barang yang menggunakan akan telah
akan dijual akun yang terhapus dari dihapus
memiliki akses ke database dari
menu yang database
bersangkutan
• Pilih Sub Modul
Alokasi Barang
ID yang
diinginkan
6.4. Tampilkan Daftar Alokasi Barang

Menampilkan daftar • Login Menampilka Menampil Kasir Sesuai Valid
alokasi yang telah menggunakan n daftar kan daftar
dibuat akun yang alokasi yang kode
memiliki akses ke telah dibuat alokasi
menu yang barang
bersangkutan
• Pilih Sub Modul
Alokasi Barang
84
6.5. Tampilkan Detail Alokasi Barang
Menampilkan detail • Login ID Tempat: A1 Menampilka Menampil Kasir Sesuai Valid
alokasi yang telah menggunakan n detail kan
dibuat berdasarkan akun yang alokasi yang barang-
ID memiliki akses ke telah dibuat barang
menu yang berdasarkan yang ada
bersangkutan ID pada kode
• Pilih Sub Modul A1
Alokasi Barang
• Pilih ID Alokasi
7. Pemesanan
7.1. Input Data Pemesanan
Melakukan proses • Login • Nama PBF: Data yang Menyimpa Pemilik Sesuai Valid
pemesanan barang menggunakan Bio Farma diinput akan n pesanan
akun yang • Tanggal menghasilka dengan ID
memiliki akses ke Pemesanan: n satu ID AARSP20
menu yang 07/03/2017 Pemesanan 1707031
bersangkutan • Nama dan akan
Pemesanan Amoxilin database
• Pilih Tambah • Jumlah
• Submit Form Pesanan[1]:
10
• Harga
Pesanan[1]:
12000
85
• Total Harga
Pesanan[1]:
120000
• Discount[1]:
5%
• Total
Discount[1]:
6000
• Harga
Setelah
Discount[1]:
114000
• PPN10%[1]
:11400
• Total
Harga[1]:12
5400
7.2. Edit Data Pemesanan

Mengubah • Login • Nama PBF: Data yang Mengubah Pemilik Sesuai Valid
pemesanan barang menggunakan Bio Farma diinput akan isi pesanan
yang telah akun yang • Tanggal diubah pada dengan ID
dilakukan memiliki akses ke Pemesanan: ID AARSP20
menu yang 07/03/2017 Pemesanan 1707031
bersangkutan • Nama dan akan
Pemesanan Panadol database
• Pilih Tambah Merah
• Submit Form • Jumlah
Pesanan[1]:
5
86
• Harga
Pesanan[1]:
20000
• Total Harga
Pesanan[1]:
100000
• Discount[1]:
5%
• Total
Discount[1]:
5000
• Harga
Setelah
Discount[1]:
95000
• PPN10%[1]
:9500
• Total
Harga[1]:10
4500
87
7.3. Hapus Data Pemesanan
Menghapus • Login • Tombol Pemesanan Menghapu Pemilik Sesuai Valid
pemesanan barang menggunakan Hapus telah s pesanan
yang telah akun yang terhapus dari dengan ID
dilakukan memiliki akses ke database AARSP20
menu yang 1707031
bersangkutan
• Pilih Sub Modul
Pemesanan
pemesanan yang
telah dibuat
• Submit Form
7.4. Tampilkan Daftar Pemesanan

Menampilkan daftar • Login Menampilka Menampil Pemilik Sesuai Valid
pemesanan barang menggunakan n daftar kan daftar
yang telah akun yang pemesanan pesanan
tersimpan di memiliki akses ke barang yang dengan ID
database menu yang telah yang
bersangkutan tersimpan di berbeda
• Pilih Sub Modul database
Pemesanan
7.5. Tampilkan Detail Pemesanan

Menampilkan detail • Login ID PEmesanan: Menampilka Menampil Pemilik Sesuai Valid
pemesanan barang menggunakan AARSP20170703 n detail kan detail
akun yang 1 pemesanan pesanan
88
berdasarkan ID memiliki akses ke barang dengan ID
Pemesanan barang menu yang berdasarkan AARSP20
bersangkutan ID 1707031
• Pilih Sub Modul Pemesanan
Pemesanan barang
• Pilih ID
Pemesanan
8. Notifikasi Pemesanan
Menampilkan • Login Menampilka Menampil Pemilik Sesuai Valid
Daftar Barang yang menggunakan n Daftar kan
harus dipesan jika akun yang Barang yang barang-
jumlah barang memiliki akses ke harus barang
kurang dari jumlah menu yang dipesan jika dikarenaka
minimal barang bersangkutan jumlah na jumlah
• Pilih Sub Modul barang pada
Notif Pemesanan kurang dari sistem
jumlah kurang dari
minimal jumlah
barang minimal
89
9. Barang Masuk
9.1. Input Data Barang Masuk
Melakukan proses • Login • Tanggal Data yang Barang- Pemilik Sesuai Valid
pemasukan barang menggunakan Stock In: diinput akan barang
masuk berdasarkan akun yang 07/05/2017 menghasilka berhasil
ID Pemesanan memiliki akses ke • Nama Pbf: n satu ID masuk
Barang menu yang Bio Farma Barang kedalam
bersangkutan • Nama Masuk dan sistem dan
• Pilih Sub Modul Barang[1]: akan stok
Barang Masuk Panadol tersimpan di barang
• Pilih ID Merah database dengan ID
Pemesanan yang • Jumlah AAINBF
belom di Stock In[1]: M2017070
masukkan 5 3
• Submit Form
9.2. Edit Data Barang Masuk

Melakukan • Login • Tanggal Data yang Barang- Pemilik Sesuai Valid
pengubahan pada menggunakan Stock In: diubah akan barang
proses pemasukan akun yang 07/05/2017 menghasilka berhasil
barang masuk memiliki akses ke • Nama Pbf: n satu ID diubah
menu yang Bio Farma Barang kedalam
bersangkutan • Nama Masuk dan sistem dan
• Pilih Sub Modul Barang[1]: akan stok
Barang Masuk Panadol tersimpan di barang
• Pilih Edit di ID Hijau database dengan ID
Barang Masuk • Jumlah AAINBF
yang ingin diubah Stock In[1]: M2017070
• Submit Form 10 3
90
9.3. Hapus Data Barang Masuk
Melakukan • Login • Tombol Data ID Pemilik Sesuai Valid
penghapusan pada menggunakan Hapus terhapus dari AAINBF
pemasukan barang akun yang Database M2017070
masuk memiliki akses 3 berhasil
ke menu yang dihapus
bersangkutan dan jumlah
• Pilih Sub barang
Modul Barang pada stok
Masuk barang
• Pilih Hapus akan
pada ID Barang berkurang
Masuk yang
ingin diubah
• Submit Form
9.4. Tampilkan Daftar Barang Masuk

barang yang telah menggunakan n daftar kan daftar
masuk akun yang barang yang barang-
memiliki akses telah masuk barang
ke menu yang masuk
bersangkutan berdasarka
• Pilih Sub n ID
Modul Barang
Masuk
91
9.5. Tampilkan Detail Barang Masuk
Menampilkan detail • Login ID Brg Masuk: Menampilka Menampil Pemilik Sesuai Valid
barang yang telah menggunakan AAINBIF201707 n detail kan barang
masuk berdasarkan akun yang 03 barang yang yang telah
ID memiliki akses telah masuk dimasukka
ke menu yang berdasarkan n dengan
bersangkutan ID ID
• Pilih Sub AAINBF
Modul Barang M2017070
Masuk 3
• Pilih ID Barang
Masuk
10. Stok Barang

Menampilkan Detail • Login Menampilka Menampil Pemilik Sesuai Valid
Barang menggunakan n Detail kan
akun yang Barang seluruh
memiliki akses detail
ke menu yang barang
bersangkutan yang telah
• Pilih Sub terdaftar
Modul Stok pada
Barang sistem
92
11. Stok Opname
11.1. Input Data Stok Opname
Melakukan proses • Login • Judul: Stock Data yang Menyimpa Pemilik Sesuai Valid
Stock Opname untuk menggunakan Opname A diinput akan n data stok
membedakan jumlah akun yang • Tanggal: menghasilka opname
barang pada system memiliki akses 07/03/2017 n satu ID dengan ID
dan kondisi yang ke menu yang • Nama Stock AAOPN20
sebenarnya bersangkutan Barang[1]: Opname dan 1707031
• Pilih Sub Amoxilin akan dan dengan
Modul Stock • Jumlah di tersimpan di judul:
Opname sistem[1]:10 database Stock
• Pilih tambah • Jumlah Opname A
• Submit Form Asli[1]: 10

• Status[1]:
Sama
• Keterangan[
1]:Aman
11.2. Edit Data Stok Opname

Melakukan • Login • Judul: Stock Data yang Mengubah Pemilik Sesuai Valid
pengubahan data menggunakan Opname A diinput akan data stok
Stock Opname akun yang • Tanggal: menghasilka opname
memiliki akses 07/03/2017 n satu ID dengan ID
ke menu yang • Nama Stock AAOPN20
bersangkutan Barang[1]: Opname dan 1707031
• Pilih Sub Amoxilin akan dan dengan
Modul Stock • Jumlah di tersimpan di judul:
Opname sistem[1]:5 database Stock
• Pilih edit ID • Jumlah Opname A
Stock Opname Asli[1]: 10
93
• Submit Form • Status[1]:
Tidak Sama
• Keterangan[
1]:Kadaluar
sa
11.3. Hapus Data Stok Opname

Melakukan • Login Data yang Menghapu Pemilik Sesuai Valid
pengubahan data menggunakan dihapus akan s Data
Stock Opname akun yang terhapus dari Stok
memiliki akses database Opname
ke menu yang dengan ID
bersangkutan AAOPN20
• Pilih Sub 1707031
Modul Stock
Opname
• Pilih hapus ID
Stock Opname
11.4. Tampilkan Daftar Stok Opname

stock opname yang menggunakan n daftar kan daftar
telah dibuat akun yang stock stok
memiliki akses opname opname
ke menu yang yang telah yang telah
bersangkutan dibuat dilakukan
• Pilih Sub
Modul Stock
Opname
94
11.5. Tampilkan Detail Stok Opname
Menampilkan detail • Login ID Stok Opname: Menampilka Menampil Pemilik Sesuai Valid
stock opname yang menggunakan AAOPN2017070 n detail kan detail
telah dibuat akun yang 31 stock stok
berdasarkan ID memiliki akses opname opname ID
ke menu yang yang telah AAOPN20
bersangkutan dibuat 1707031
• Pilih Sub berdasarkan
Modul Stock ID
Opname
• Pilih ID Stock
Opname
12. Master Satuan

12.1. Input Data Satuan
Melakukan Input • Login • Nama Data yang Satuan: Pemilik Sesuai Valid
Data Master Satuan, menggunakan Satuan: Box diinput akan Box telah
yang dapat digunakan akun yang • Singkatan tersimpan di tersimpan
untuk memilih satuan memiliki akses Satuan: Box database di database
pada menu barang ke menu yang
bersangkutan
• Pilih Sub
Modul Master
Satuan
• Pilih tambah
• Submit Form
95
12.2. Edit Data Satuan
Melakukan • Login • Nama Data yang Satuan: Pemilik Sesuai Valid
pengubahan Input menggunakan Satuan: diinput akan Box telah
Data Master Satuan, akun yang Tablet tersimpan di diubah
yang dapat digunakan memiliki akses • Singkatan database menjadi
untuk memilih satuan ke menu yang Satuan: tbt Tablet
pada menu barang bersangkutan pada
• Pilih Sub database
Modul Master
Satuan
• Pilih Edit pada
satuan yang
diinginkan
• Submit Form
12.3. Hapus Data Satuan

Melakukan • Login • Tombol Satuan akan Satuan: Pemilik Sesuai Valid
penghapusan Input menggunakan Hapus terhapus dari Tablet
Data Master Satuan akun yang database telah
memiliki akses dihapus
ke menu yang dari
bersangkutan database
• Pilih Sub
Modul Master
Satuan
• Pilih Hapus
96
12.4. Tampilkan Daftar Satuan
Menampilkan Daftar • Login Menampilka Menampil Pemilik Sesuai Valid
Satuan yang menggunakan n Daftar kan Daftar
tersimpan di database akun yang Satuan yang Satuan
memiliki akses tersimpan di yang
ke menu yang database tersimpan
bersangkutan di database
• Pilih Sub
Modul Master
Satuan
13. Master PBF

13.1. Input Data PBF
Melakukan Input • Login • Nama Pbf: Data yang PBF Pemilik Sesuai Valid
Data Master Pbf, menggunakan Bio Farma diinput akan dengan
yang dapat digunakan akun yang • Kode Pbf: tersimpan di kode BIF
untuk memilih pbf memiliki akses BIF database telah
pada menu barang ke menu yang • Alamat Pbf: dimasukka
bersangkutan Jl.Yos n kedalam
• Pilih Sub sudarso no database
Modul Master IIB
Pbf • Telepon
• Pilih tambah Pbf: 0711-
• Submit Form 710352
• Nama
Pegawai
PBF:
Rahmat B
97
• Telepon
Pegawai:
0817710928
13.2. Edit Data PBF

Melakukan • Login • Nama Pbf: Data yang PBF Pemilik Sesuai Valid
pengubahan pada menggunakan Bio Farma diinput akan dengan
Input Data Master akun yang • Kode Pbf: tersimpan di kode BIF
Pbf memiliki akses BFM database telah
ke menu yang • Alamat Pbf: diubah
bersangkutan Jl.Yos menjadi
• Pilih Sub Sudarso no BFM
Modul Master IIB beserta
Pbf • Telepon detail
• Pilih Edit pada Pbf: 0711- barang
Pbf yang 710351 yang lain
diinginkan • Nama di database
• Submit Form Pegawai

PBF:
Rahmat A
• Telepon
Pegawai:
0817710927
98
13.3. Hapus Data PBF
Melakukan • Login • Tombol Pbf akan Kode BFM Pemilik Sesuai Valid
penghapusan Input menggunakan Hapus terhapus dari telah
Data Master Pbf akun yang database terhapus
memiliki akses dari
ke menu yang Database
bersangkutan
• Pilih Sub
Modul Master
Pbf
• Pilih Hapus
13.4. Tampilkan Daftar PBF

Pbf yang tersimpan di menggunakan n Daftar Pbf kan daftar
database akun yang yang PBF yang
memiliki akses tersimpan di telah
ke menu yang database dibuat
bersangkutan
• Pilih Sub
Modul Master
Pbf
14. Master Barang

14.1. Input Data Barang
Melakukan Input • Login • Nama Data yang Barang : Pemilik Sesuai Valid
Data Master Barang, menggunakan Barang: diinput akan Panadol
akun yang Hijau telah
99
yang dapat digunakan memiliki akses Panadol tersimpan di tersimpan
pada berbagai menu ke menu yang Hijau database di
bersangkutan • Kode databases
• Pilih Sub Barang:
Modul Master PNH
Barang • Satuan
• Pilih tambah Baran: Box
• Submit Form • Kategori
Barang:
Tablet
• Minimal
Barang: 10
• Harga:
80000
14.2. Edit Data Barang

Melakukan • Login • Nama Data yang Barang: Pemilik Sesuai Valid
perubahan pada Input menggunakan Barang: diinput akan Panadol
Data Master Barang, akun yang Panadol tersimpan di Hijau
yang dapat digunakan memiliki akses Hijau database dengan
pada berbagai menu ke menu yang • Kode kode PNH
bersangkutan Barang: telah
• Pilih Sub PND diubah
Modul Master • Satuan menjadi
Barang Baran: Box PND
• Pilih edit pada • Kategori
barang yang Barang:
diinginkan Tablet
• Submit Form • Minimal
Barang: 15
• Harga:
80000
100
14.3. Hapus Data Barang
Melakukan • Login • Tombol Barang akan Barang : Pemilik Sesuai Valid
penghapusan Input menggunakan Hapus terhapus dari Panadol
Data Master Barang akun yang database Hijau telah
memiliki akses dihapus
ke menu yang dari
bersangkutan database
• Pilih Sub
Modul Master
Barang
• Pilih Hapus
14.4. Tampilkan Daftar Barang

Barang yang menggunakan n Daftar kan daftar
tersimpan di database akun yang Barang yang barang
memiliki akses tersimpan di yang telah
bersangkutan
• Pilih Sub
Modul Master
Barang
101
15. Master Kategori
15.1. Input Data Kategori
Melakukan Input • Login • Nama Data yang Kategori: Pemilik Sesuai Valid
Data Master menggunakan Kategori: diinput akan Tablet
Kategori, yang dapat akun yang Tablet tersimpan di telah
digunakan pada memiliki akses database tersimpan
berbagai menu ke menu yang di database
bersangkutan
• Pilih Sub
Modul Master
Kategori
• Pilih tambah
• Submit Form
15.2. Edit Data Kategori

Melakukan Input • Login • Nama Data yang Kategori: Pemilik Sesuai Valid
Data Master menggunakan Kategori: diinput akan Tablet
Kategori, yang dapat akun yang Obat Suntik tersimpan di telah
digunakan pada memiliki akses database diubah
berbagai menu ke menu yang dengan
bersangkutan Obat
• Pilih Sub Suntik dan
Modul Master tersimpan
Kategori di database
• Pilih Edit Pada
Kategori
• Submit Form
102
15.3. Hapus Data Kategori
Melakukan • Login • Tombol Barang akan Kategori: Pemilik Sesuai Valid
penghapusan Input menggunakan Hapus terhapus dari Obat
Data Master Kategori akun yang database Suntik
memiliki akses telah
ke menu yang tersimpan
bersangkutan di database
• Pilih Sub
Modul Master
Kategori
• Pilih Hapus
15.4. Tampilkan Daftar Kategori

Kategori yang menggunakan n Daftar kan semua
tersimpan di database akun yang Barang yang kategori
memiliki akses tersimpan di yang telah
bersangkutan
• Pilih Sub
Modul Master
Kategori
103
Lampiran 6. Spesifikasi Kebutuhan Perangkat Lunak (SKPL) Sistem Informasi
Apotek Ananda
Dokumen SKPL dapat dilihat pada tautan berikut: http://bit.ly/SKPLAnanda
104

Requirements Engineering 110313

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Requirements Engineering 110313

Diunggah oleh

Hak Cipta:

Format Tersedia

Implementasi dan Analisis Goal-Based Requirement

Analysis Method(GBRAM) dengan Studi Kasus: Sistem

diajukan untuk memenuhi salah satu syarat

memperoleh gelar sarjana

dari Program Studi Sarjana Teknik Informatika

Program Studi Sarjana Teknik Informatika

Implementation and Analysis Goal-Based Requirement Analysis

Gelar pada Program Studi Sarjana Teknik Informasika

Dana Sulistyo Kusumo S.T., M.T., Nungki Selviandro S.Kom., M.Kom

Ketua Program Studi

Moch. Arif Bijaksana. Ph.D.

Kata Kunci: Requirements Engineering(RE), Goal-Based Requirements Analysis

Keywords: Requirements Engineering(RE), Goal-Based Requirements Analysis

1.2. Perumusan Masalah

1. Bagaimana cara mengimplementasi Goal-Based Requirements Analysis

1.5. Sistematika Penulisan

2.2. Goal Oriented Requirement Engineering (GORE)

Gambar 1. Aktivitas GBRAM

2.3.1.1. Identifying Goals

2.3.1.2. Identifying Stakeholders

2.3.1.4. Organization and Classification of Goals

2.3.1.5. Eliminating Redundancies and Reconcilling Synonymous Goals

2.3.1.6. Classifying Goals

2.3.2. Goal Refinement

2.3.2.1. Specifying Goal Obstacles

2.3.2.3. Identifying Constraints

2.3.2.4. Operationalization of Goals into Requirements

Goal Schema adalah proses menspesifikasikan antara goal dan agentsnya.

2.4. User Acceptance Test (UAT)

Gambar 2. Flowchart Metodologi Penelitian

3.1. Analisa Kebutuhan

Berdasarkan hasil wawancara dan workflow dari apotek Ananda, maka

a. Pemesanan (ORD): Modul yang digunakan untuk proses Pemesanan

a. Penulisan nama goal berdasarkan standar penulisan yang diawali dengan

Dari hasil tahapan explore, diketahui bahwa Stok Barang:

• Melakukan pemasukan barang pemesanan hampir setiap hari.

Peneliti menggunakan poin-poin yang telah dijelaskan untuk

Setelah menganalisa informasi yang ada dengan menggunakan poin-

Tabel 1. Tabel Goals

Nomor Goal Nama Goal

Setelah mengidentifikasi goals, saatnya mengidentifikasi stakeholders dan

a. Suatu Goal dapat mengaitkan beberapa Stakeholder.

Berikut adalah poin-poin yang dapat dilakukan untuk identifikasi agents,

Dari informasi yang telah dikumpulan, diketahui bahwa Apotek Ananda

• Master Data (MST)

Untuk mengidentifikasi agentnya, disini peneliti menggunakan poin c.

Nomor Nama Goal Stakeholder Agents

a. Perlu mengetahui apakah pencapaian goal ini bersifat mandiri?

Berikut adalah poin-poin yang dapat dilakukan untuk mengidentifikasi

Pada tahapan ini, peneliti banyak menggunakan poin c dalam menentukan

Tabel 3. Tabel Tipe Goals

Nomor Nama Goal Tipe Goal

Setelah Goals Telah di klasifikasikan, saatnya mengurutkan goal tersebuat

a. Predence dependency: Ketergantungan antara G1 dan G2, bahwa G1 harus

Berikut adalah poin-poin yang dapat ditanyakan dalam identifikasi goals

a. Goals apa yang menjadi syarat untuk goal ini?

Setelah goal dependency telah diidentifikasi, maka akan terbentuknya goal

Gambar 4. Hasil Goal Dependency

Berikut adalah poin-poin yang dapat diakukan untuk mengidentifikasi

a. Kalimat yang mengilustrasikan kondisi yang dapat menghambat pencapaian

a. Mempertanyakan dan mempertimbangkan suatu goal, apa yang terjadi jika

a. Mempertanyakan apakah pernyataan ini menentukan beberapa requirements

Setelah kita melakukan tahapan refinement, diketahui bahwa G4 memiliki

Gambar 5. Contoh Goal Schema