tugas besar pendekatan terstruktur tel u_aplikasi pemeriksaan pasien_kelompok 58
DESCRIPTION
Tugas kuliahTRANSCRIPT
DOKUMENTASI ANALISIS DAN PERANCANGAN PERANGKAT LUNAK
(PENDEKATAN TERSTRUKTUR)
Pemeriksaan Pasien
untuk:
Dokter
Dipersiapkan oleh:
Group 58
Syafaatul Udhma Nugraha
Mohamad Wahyudi Putra
Serevina Naibaho
Muhammad Hamdan
Program Studi Teknik IndustriFakultas Rekayasa Industri
Telkom University
2015
DAFTAR PERUBAHANRevisi Deskripsi
A
B
C
D
E
F
G
INDEXTGL
- A B C D E F G
Ditulis oleh
Diperiksa oleh
Disetujui oleh
Daftar Halaman Perubahan
Halaman Revisi Halaman Revisi
Daftar Isi1. Pendahuluan..........................................................................................................................................................5
1.1 Tujuan Penulisan Dokumen......................................................................................................................51.2 Lingkup Masalah.......................................................................................................................................51.3 Definisi, Istilah dan Singkatan.................................................................................................................51.4 Aturan Penomoran....................................................................................................................................51.5 Referensi...................................................................................................................................................51.6 Deskripsi umum Dokumen (Ikhtisar)........................................................................................................5
2 Deskripsi Umum Perangkat Lunak...................................................................................................................52.1 Deskripsi Umum Sistem...........................................................................................................................52.2 Fungsi Produk...........................................................................................................................................52.3 Karakteristik Pengguna.............................................................................................................................52.4 Batasan......................................................................................................................................................52.5 Lingkungan Operasi..................................................................................................................................6
3 Deskripsi Umum Kebutuhan.............................................................................................................................63.1 Kebutuhan antarmuka eksternal................................................................................................................6
3.1.1 Antarmuka pemakai..........................................................................................................................63.1.2 Antarmuka perangkat keras...............................................................................................................63.1.3 Antarmuka perangkat lunak..............................................................................................................63.1.4 Antarmuka komunikasi.....................................................................................................................6
3.2 Deskripsi Fungsional.................................................................................................................................63.2.1 Context Diagram...............................................................................................................................6
3.2.1.1 DFD Level 1..................................................................................................................................63.3 Data Requirement.....................................................................................................................................7
3.3.1 E-R diagram......................................................................................................................................73.4 Non Functional Requirement....................................................................................................................73.5 Batasan Perancangan.................................................................................................................................83.6 Kerunutan (traceability)............................................................................................................................8
3.6.1 Data Store vs E-R..............................................................................................................................83.7 Ringkasan Kebutuhan...............................................................................................................................8
3.7.1 Functional Requirement Summary...................................................................................................83.7.2 Non Functional Requirement Summary............................................................................................8
4 Deskripsi Perancangan Global..........................................................................................................................94.1 Rancangan Lingkungan Implementasi......................................................................................................94.2 Deskripsi Data...........................................................................................................................................9
4.2.1 Definisi Domain/Type.......................................................................................................................94.2.2 Conceptual Data Model.....................................................................................................................94.2.3 Physical Data Model.........................................................................................................................94.2.4 Daftar Tabel Aplikasi........................................................................................................................9
4.3 Dekomposisi Fungsional Modul.............................................................................................................105 Deskripsi Perancangan Rinci..........................................................................................................................10
5.1 Deskripsi Rinci Tabel..............................................................................................................................105.1.1 Tabel <Nama..>...............................................................................................................................105.1.2 Tabel <Nama>.................................................................................................................................11
5.2 Deskripsi Fungsional secara Rinci..........................................................................................................115.2.1 Spesifikasi Fungsi/Proses <nama fungsi 1>....................................................................................115.2.2 Spesifikasi Fungsi/Proses <nama fungsi 2>....................................................................................11
5.3 Dekomposisi Fisik Modul.......................................................................................................................115.4 Matriks Kerunutan..................................................................................................................................12
Setelah Daftar Isi Boleh ada Daftar Tabel dan Daftar Gambar
1. Pendahuluan
1.1 Tujuan Penulisan Dokumen
Tujuan dokumen ini dibuat unutk melihat bagaimana elemen-elemen dari aplikasi ini terhubung atau berinteraksi
dengan pihak penggun, atau bisa disebut interaksi antara sistem dan user :
1. Sistem menyediakan dan menentukan apa yang harus diinputkan oleh user, yang harapannya dapat
memudahkan dalam merekap rekam medis pasien oleh asisten dokter
2. User terdiri dari 3 pihak, yaitu pasien, asisten dokter dan dokter. Pasien merupakan sumber data yang
akan diinputkan oleh asisten dokter, lalu sistem akan merekam data pasien yang nantinya akan
digunakan oleh keperluan dokter untuk pemeriksaan
1.2 Lingkup Masalah
Aplikasi Pemeriksaan Pasein adalah sebuah sistem yang dirancang untuk memudahkan asisten dalam merekap
rekam medis pasien, yang selanjutnya data akan digunakan oleh dokter untuk melakukan pemeriksaan. Alur
proses pada sistem ini, pasien – asisten dokter – sistem – dokter.
1.3 Definisi, Istilah dan Singkatan
Asisten dokter / Administrasi
karyawan yang bekerja berdampingan bersama dokter
User
merupakan pihak klinik
Softwere
perangkat lunak yang dalam hal ini suatu program
1.4 Aturan Penomoran
Aturan penomoran pada penulisan ini menggunakan angka pada setiap bab, sub bab dan sub-sub bab lainnya.
Contoh :
Bab 1 Pendahuluan
1.1. Latar Belakang
1.1.2 Data
1.5 Referensi
Referensi yang digunakan untuk menyusun tulisan ini diantaranya adalah :
File bentuk PDF, yang merupakan pedomana untuk menggunakan atau mengoprasikan softwere atau
aplikasi pemeriksaan pasien
Buku pegangan matakuliah APSI, Introdusction to system analysis & design method 7th oleh jeffrey L.
Whitten dan Lonnie Bentley.
1.6 Deskripsi umum Dokumen (Ikhtisar)
Bab I. Pendahuluan
Pada bab ini berisi uraian mengenai tujuan penulisan dokumen, lingkup masalah, definisi, istilah dan singkatan,
aturan penomoran, referensi, dan deskripsi umum dokumen (ikhtisar)
Bab II. Deskripsi Umum Perangkat Lunak
Pada bab ini berisi mengenai deskripsi umum sistem, fungsi produk, karakteristik pengguna, batasan, dan
lingkupan operasi
Bab III Deskripsi Umum Kebutuhan
Pada bab ini berisi kebutuhan antarmuka eksternal, deskripsi fungsional, data requirement, non functional
requirement, batasan perancangan, kerunutan (traceability), dan ringkasan kebutuhan
Bab IV Deskripsi Perancangan Global
Pada bab ini berisi mengenai rancangan lingkungan implementasi, deskripsi data dan dekomposisi fungsional
modul
Bab V Deskripai Perancangan Rinci
Pada bab ini berisi tentang deskripsi rinci tabel, deskripsi fungsional secara rinci, dekomposisi fisik modul dan
matriks kerunutan
2 Deskripsi Umum Perangkat Lunak
2.1 Deskripsi Umum Sistem
Form Biodata Pasien
Keluhan penyakit
No.Antri Pasien
Kartu ID Pasien
Update Data Pasien
Data Obat Pasien
Diagnosis Pemeriksaan
Keluahan Pasien
Resep Obat Pasien
Kartu Status Pasien
1
Aplikasi Pemeriksaan Pasien
Dokter
Administrasi
Pasien
Gambar diatas merupakan deskripsi umum dasi sistem aplikasi Pemeriksaan Pasien yang akan digunakan.
Terdapat 3 Entitas yang berhubungann dengan aplikasi Pemeriksaan Pasien, yaitu Dokter, Adimistrasi, dan
Pasien. Cara Kerja dimulai dari Pasien yang menginputkan biodata diri dan juga keluhan penyakit yang
dirasakan oleh bagian administrasi yang akan disimpan pada database aplikasi Pemeriksaan Pasien, yang
kemudian dari data tersebut pasien akan mendapatkan Kartu ID pasien dan juga nomer antrian untuk dilakukan
pemeriksaan. Setelah itu ketika nomer antrian tiba, pasien masuk ke ruang pemeriksaan yang kemudian
dilakukan pemeriksaan oleh dokter berdasarkan keluhan yang dirasakan pasien. Kemudian dokter memberikan
diagnosis hasil pemeriksaan terhadap pasien. Kemudian dokter menginputksan resep obat untuk pasien dan
kemudian diproses oleh admistrasi untuk dilanjutkan pencetakan kartu status pasien setelah melakuakan
pemeriksaan. Pasien yang sudah dilakuakan pemeriksaan menuju kembali ke admistrasi untuk melakuakan
pengambilan kartu status pasien dan pasien dapat mendapati penyakit yang dialami oleh pasien.
2.2 Fungsi Produk
Menu pada aplikasi ini terdiri atas Menu Utama dan Sub Menu. Terdapat 4 Menu Utama yang terdiri atas:
a. Menu Data Diri Pasien
Pada menu data diri pasien terdapat 8 sub menu yaitu nama, alamat, umur, kelamin, agama, status,
nama orang tua, no. telfon yang akan disi dengan biodata diri dari pasien yang yang melakukan
pemeriksaan.
b. Menu Status Pasien
Pada menu status pasien terdapat 6 sub menu yaitu anamnesa, pemeriksaan, Lab-USG, Photo, Diagnosa
dan resep yang akan diisi oleh dokter ketika telah melakukan pemeriksaan terhadap pasien
c. Menu Pencarian
Pada menu pencarian terdapat 5 sub menu yaitu nama, alamat, umur, nama orang tua dan telfon. Menu
ini digunakan untuk pasien yang sudah pernah melakukan pemeriksaan sebelumnya yang sudah pernah
mengisi biodata pasien. Dapat dilakukan pencarian data diri pasien oleh administrasi dengan
memasukan nama atau alamat atau umur atau nama orang tua tau no mer telefon dari pasien.
d. Menu Control Panel
Pada menu control panel terapat 8 sub menu yaitu show, hide, edit profile, show toolbar, cetak kartu
status, laporan resep, lap daftar pasien dan keluar. Menu ini adalah bagian untuk melakukan pencetakan
hasil pemeriksaan dan kartu status pasien seta juga untuk pengeditan data pasien yang dilakukan oleh
bagian administrasi.
2.3 Karakteristik Pengguna
Kategori Pengguna Tugas Hak Akses ke aplikasi
Administrasi Input data diri Pasien Admin Login
Update Resep Pasien Edit Database Pasien
Update Status Data Pasien Pencetakan Keseluruhan data Pasien
User/Pasien Mencari hal Terkait Dirinya Adm Search ID Pasien
Pencetakan Kartu ID Pasien
Pencetakan Kartu Status Pasien
2.4 Batasan
Batasan yang terdapat pada sistem ini adalah spesifikasi minimal :
1. Komputer P2-500Mhz ,identik atau lebih.
2. Memory RAM 128Mb atau lebih
3. Layar dengan resolusi 1024x768 atau lebih
4. Ms windows 98, Me, XP, atau Vista
5. Ms office terutama ms access tahun 97, 2000, 2002(XP), 2003, 2007(belum di tes)
6. Penggunan printer
2.5 Lingkungan Operasi
Aplikasi Client server ini akan berfungsi dengan spesifikasi :
Server : Administrasi
Client : PAsien
OS : Windows
DBMS :
3 Deskripsi Umum Kebutuhan
3.1 Kebutuhan antarmuka eksternal
Aplikasi ini hanya dijalankan oleh orang/bagian yang berkepentingan dan memiliki wewenang untuk melakukan
penggunakan aplikasi ini seperi login dan update data yang hanya dapat dilakukan oleh bagian administrasi dan
dokter
3.1.1 Antarmuka pemakai
Aplikasi ini hanya berjalan pada perangkat komputer atau PC yang memiliki atau memakai operating system
windows, maka dari itu penghubung antara aplikasi dengan pemakai yaitu seperangkat komputer lengkap dengan
accessories (keyboard, ` mouse)
3.1.2 Antarmuka perangkat keras
Hanya diisi jika perlu perangkat keras khusus, misalnya CARD XXX, CABLE XYZ
3.1.3 Antarmuka perangkat lunak
Hanya diisi jika PL memakai interface (berupa PL), misalnya API Windows.
3.1.4 Antarmuka komunikasi
Hanya diisi jika PL beroperasi di jaringan dan membutuhkan alat komunikasi khusus, misalnya RS232.
3.2 Deskripsi Fungsional
3.2.1 Context Diagram
Input Data
ID PasienNomor Urut
Data Pasien
Input Jadwal Pasien
Input Jadwal Kosong
Daftar Pasien
PasienAsisten Dokter
Dokter
1
Sistem Pemeriksaan Pasien
Terdapat 3 entitas yang berinteraksi dengan aplikasi yang pertama adalah pasien yang hak penggunaannya
adalah pengisi biodata diri yang dilakukan oleh administrasi kemudian pasien mendapatkan ID pasien beserta
kartu pasien dan nomer urut antrian pemeriksaan. Yang kedua adalah dokter yang bertugas melakukan
pemeriksaan dan menginputkan jadwal pemeriksaan. Yang ketiga adalah asisten dokter/adminsitrasi yang
bertugas untuk menginputkan biodata diri pasien dan update data pasien serta menginutkan jadwal pasien.
3.2.1.1 DFD Level 1
Input Data Pasien
Data Pasien
Data Pasien
Input Jadwal PasienJadwal Pasien
Input Jadwal Kosong
Jadwal Kosong
Jadwal Dokter Jadwal Pasien
Asisten Dokter
Pasien
Dokter
1
Kelola Jadwal Pasien
2
Kelola Jadwal Kosong
3
Kelola Data Pasien
1 Data Jadwal Pasien
2 Data Jadwal Kosong
3 Data Pasien
3.2.1.2 DFD Level 2
Data Pasien
Input Data Pasien Mendaftarkan Data Pasien
Data PasienKartu Pasien
Pasien
1
Proses Pasien Baru
2
Pencetakan ID
1 Data Pasien
Data Jadwal Pemeriksaan
Data Pasien Data Jadwal KosongAsisten 1
Jadwal Pasien1 Jadwal Kosong
Data Pemeriksaan
Input Jadwal Kosong
Jadwal pasien
Jadwal Kosong Dokter
Input Jadwal Kosong Untuk Pasien
Dokter
1
Input Jadwal Kosong
2
Input Jadwal Pasien
1 Jadwal Kosong
3.3 Data Requirement
Data yang dibutuhkan dalam sistem aplikasi Pemeriksaan Pasien adalah
Dokter : NIP, Jadwal Pemeriksaan, Hasil Pemeriksaan
Asisten/Administrasi : NIP, Data Nama Obat, Daftar harga Obat, Biaya Pemeriksaan
Pasien : Biodata Diri, Keluhan Penyakit
3.3.1 E-R diagram
Gambar E-R diagram yang benar-benar konseptual, dengan VISIO. Minimal ada nama Entity, Relasi dan Key
(Skema relasi). Sudah dijelaskan apa bedanya E-R konseptual dengan Conceptual Data Model pada Case
Tools, karena E-R diagram ini tidak mungkin digambar dengan Case Tools. Keterbatasan CASE Tools biasanya
adalah:
- tidak mungkin mempunyai relasi dengan atribut non-key
- tidak mungkin mempunyai relasi bukan biner (terner, dan lebih tinggi)
sehingga akibatnya, relasi dijadikan “entity”. Kenapa E-R konseptual disarankan untuk digambar, adalah
karena E-R ini sebenarnya lebih mencerminkan abstraksi perancang
3.4 Non Functional Requirement
Uraikan dengan ringkas kebutuhan non fungsional dalam tabel sebagai berikut. Isilah Kolom Requirement
dengan kalimat yang jelas dan kelak dapat ditest untuk dipenuhi. SRS-NO adalah nomor requirement yang
harus ditelusuri pada saat test. Tuliskan N/A bila Not Applicable..
SRS-Id Parameter Requirement
SRS-NF-001 Availability
Aplikasi beroperasi selama 24 jam,
namun pemakaian hanya dapat
digunakan sesuai jam operasional. Jam
praktik dokter yang sudah ditentukan.
SRS-NF-002 ReliabilityPersentase aplikasi tidak boleh gagal
adalah sebesar 99%.
SRS-NF-003 ErgonomyAplikasi nyaman untuk digunakan oleh
user (Administrasi dan Dokter)
SRS-NF-004 Portability Aplikasi digunakan Komputer atau PC
SRS-NF-005 Memory Aplikasi memiliki kapasitas 15 MB
SRS-NF-006 Response timeAplikasi mampu menampilkan hasil
dalam 1 detik
SRS-NF-007 Safety Single Sign On
SRS-NF-008 Security
Aplikasi hanya dapat diakses oleh bagian
administrasi dan dokter yang bertugas
pada waktu operasional dan ditempat
praktik
Others 1: Bahasa
komunikasi
Misalnya : semua tanya jawab harus dalam
bahasa Indonesia
Setiap layar harus mengandung logo PT Pos
Indonesia
Catatan :
Availability : ketersediaan aplikasi, misalnya harus terus menerus beroperasi 7 hari perminggu, 24 jam per
haritanpa gagal
Reliability : keandalan, misalnya tidak pernah boleh gagal(atau kegagalan yang ditolerir adalah …%) sehingga
harus dipikirkan fault tolerant architecture. Biasanya hanya perlu untuk Critical Application yang jika gagal
akan berakibat fatal.
Ergonomy : kenyamanan pakai bagi pengguna
Portability : kemudahan untuk dibawa dan dioperasikan ke mesin/sistem operasi/platform yang lain
Memory : jika perhitungan kapasitas memori internal kritis (misalnya untuk SW yang harus dijadikan CHIPS
dan ukurannya harus kecil
Response time : Batasan waktu yang harus dipenuhi. Sangat penting untuk aplikasi Real Time. Contoh:
“Aaplikasi harus mampu menampilkan hasil dalam 4 detik”, atau “ATM harus menarik kembali kartu yang
tidak diambil dalam waktu 3 menit”
Safety: yang menyangkut keselamatan manusia, misalnya untuk SW yang dipakai pada sistem kontrol di pabrik
Security : aspek keamanan yang harus dipenuhi.
3.5 Batasan Perancangan
Batasan perancangan pada software ini adalah hanya dapat digunakan untuk
pemeriksaan dokter umum dan belum sampai khusus untuk dokter spesialis
3.6 Kerunutan (traceability)
Diisi dengan tabel yang berisi traceability dari hasil analisis. Gunanya untuk menilai apakah hasil analisis
“runut” dan lojik. Untuik sementara, baru didefinisikan Data-store versus E-R.
3.6.1 Data Store vs E-R
Mapping data store pada DFD dengan Entity - Relasi
Data Store Entity Relasi
3.7 Ringkasan Kebutuhan
Bab ini berisi ringkasan semua “Requirement item”. Requirement item ini mencerminkan semua hal yang harus
dipenuhi, dan nantinya akan menjadi arahan untuk tahapan testing, karena pada dasarnya, semua requirement
harus dapat ditest supaya dapat dibuktikan dipenuhi. Dibagi menjadi dua bagian: functional dan non functional
3.7.1 Functional Requirement Summary
SRS-Id Description
3.7.2 Non Functional Requirement Summary
SRS-Id Description
4 Deskripsi Perancangan Global
4.1 Rancangan Lingkungan Implementasi
Sebutkan Operating system, DBMS, development tools, filing system, bahasa pemrograman yang dipakai
4.2 Deskripsi Data
Berisi deskripsi tabel-tabel basis data jika aplikasi berbasis data. Awali dengan daftar tabel basisdata dan
deskripsi isinya. Untuk setiap tabel, harus mengandung Nama tabel, jenisnya, Volume, laju, primary key,
constraint integrity dengan tabel lain( jika ada). Volume dan laju harus mimimal mengandung angka kira-kira.
Boleh berasal dari “dumb” dari database yang digunakan.
4.2.1 Definisi Domain/Type
Sebutkan nama domain (type terdefinisi) yang anda rancang pada aplikasi ini dengan mengisi tabel sebagai
berikut
Domain name Power Designer Type (mis)
Rupiah NUM …
4.2.2 Conceptual Data Model
Gambar ini diambil dari Case Tools. . Hasilnya diprint di bagian ini
4.2.3 Physical Data Model
Jika ada, Gambar ini adalah hasil generate diambil dari Case Tools. Gunanya supaya nantinya langsung
diterjemahkan menjadi tabel atau bahkan mungkin dipakai untuk membangkitkan tabel secara otomatis.
4.2.4 Daftar Tabel Aplikasi
.Awali dengan daftar tabel basisdata, primary key dan deskripsi isinya.
Nama Tabel Primary key Data Store E/R Deskripsi isi
Untuk setiap tabel, buatlah deskripsi rincinya pada Sub-bab Deskripsi Rinci Tabel
4.3 Dekomposisi Fungsional Modul
Berisi dekomposisi “lojik” dari modul. Minimal berisi tabulasi dengan kolom: Modul, Proses, Keterangan.
Kolom keterangan hanya diisi jika proses tidak tergambarkan dalam DFD. Misalnya untuk proses-proses yang
mewakili suatu library umum
Tabel. XXX. Input-Proses-Output
No. Fungsi diturunkan dari semua hal yang harus diprogram :
- Bubble DFD yang tidak didekomposisi lagi.
- Proses-proses yang “membungkus” proses lain (misalnya menjadi Menu)
Setelah IPO ini, setiap fungsi akan dibuat detailnya. Pada bagian berikutnya
Konvensi : setiap bubble harus menjadi fungsi saja. Jika “menghilang” dan tidak akan diprogram, maka akan
ditulis di bagian keterangan (misalnya Menu yang akan diprogram dengan Editor VB dan tidak lagi ditulis
kodenya, maka pada keterangan akan ditulis :”Ditangani oleh VB”
Disarankan agar penomoran fungsi dibuat hirarkhis, sehingga jika dijadikan menu akan sekaligus merupakan
Function Tree
No.Fungsi Fungsi/Proses Tabel/Data
Input
Tabel /Data
Output
Keterangan
Untuk setiap nomor fungsi, buatlah spesifikasi rincinya pada Deskripsi rancangan Rinci
5 Deskripsi Perancangan Rinci
5.1 Deskripsi Rinci Tabel
Setiap tabel pada rancangan global, dirinci satu per satu
5.1.1 Tabel <Nama..>
Identifikasi/Nama : ………..
Deskripsi Isi : ……..
Primary Key : ………….
Id Field Deskripsi Tipe & length Boleh
NULL
Default Keterangan
Id_master CHAR(8) NO
Id_ref Refer ke t_ref
Catatan : kolom “Boleh NULL” berisi “NO” artinya tidak boleh kosong, berisi “YES” artinya boleh NULL
5.1.2 Tabel <Nama>
Buat seperti di atas
5.2 Deskripsi Fungsional secara Rinci
Setiap Fungsi pada rancangan global, dirinci satu per satu
5.2.1 Spesifikasi Fungsi/Proses <nama fungsi 1>
Identifikasi/Nama : ……..
Deskripsi Isi : ……..
Jenis : Form Entry columnar/Tabular/Master-Detail
Report Columnar/tabular/Master-Detail
Form berisi dialog/button saja
Proses tanpa layar
Tabel input :
Tabel output :
Query : (diisi jika query cukup rumit)
Layar Utama :
Gambarkan layar dan percabangan ke layar lain function key/pilihan yang dilakukan)
Jika layar mengandung filed dan label, gambarkanlah pada posisi nya, supaya siap
dikoding. Jika ada zoning/frame, gambarkan pula an jelaskan pada spesifikasi Objek pada
layar
Algoritma : (diisi jika algoritma cukup kompleks)
Layout Report : (diisi jika fungsi menghasilkan report)
5.2.2 Spesifikasi Fungsi/Proses <nama fungsi 2>
Untuk setiap fungsi, buat detailnya seperti di atas
5.3 Dekomposisi Fisik Modul
Berisi dekomposisi “fisik” dari modul. Minimal berisi tabulasi dengan kolom: Sub Aplikasi, Modul, Nama File,
Input, Output. Sub Aplikasi biasanya dibuat per pengguna. Dibuat per modul
Berisi struktur direktori dan pengumpulan fungsi menjadi file. Minimal berisi tabulasi dengan kolom: Modul,
Proses, Keterangan. Kolom keterangan hanya diisi jika proses tidak tergambarkan dalam DFD. Misalnya untuk
proses-proses yang mewakili suatu library umum
Nama Direktori Nama File Nama Modul Nama Fungsi Keterangan
5.4 Matriks Kerunutan
Pada bagian ini, diisi dengan tabel, yang memungkinkan pembaca untuk menelusuri keterkaitan perancangan
terhadap spesifikasi kebutuhan.
OK
Objek
Diisi dengan tabel yang berisi traceability dari SRS dengan nomor CSU
SRS-Id No. Fungsi Keterangan
LAMPIRAN