Panduan Penulisan

Spesifikasi Kebutuhan Perangkat Lunak (SKPL)

1. Pendahuluan
Dokumen ini akan berisi penjelasan pemakaian dokumen Spesifikasi Kebutuhan
Perangkat Lunak (SKPL) atau Software Requirement Specification (SRS). Untuk penamaan
dokumen ini selanjutnya akan digunakan istilah SKPL. Isi dari dokumen ini sebagian besar
adalah terjemahan dari dokumen IEEE Std 830-1993.

1.1 Lingkup Persoalan

Dokumen ini digunakan untuk acuan dalam menulis SKPL. Akan diberikan juga beberapa
outline dari SKPL.
Dokumen ini dibuat untuk membantu membuat spesifikasi perangkat lunak yang akan
dikembangkan.

2. Referensi
IEEE Std 830-1993, IEEE Recommended Practice for Software Requirement Specifications.
IEEE Std 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology (ANSI).

3. Definisi
Definisi dari istilah yang akan digunakan pada dokumen ini dibuat berdasarkan hasil terjemahan
dari IEEE Std 610.12-1990.

3.1 Kontrak
Adalah suatu dokumen legal yang disetujui oleh pelanggan dan pengembang. Dalam kontrak
akan disertai dengan kebutuhan teknis, organisasi, biaya dan jadwal pengerjaan produk. Kontrak
dapat berisi informasi yang berguna, misalnya komitmen dan harapan dari organisasi yang
terlibat.

3.2 Pelanggan
Adalah orang atau organisasi yang membayar produk, dan biasanya (tidak harus) ia yang akan
memutuskan kebutuhannya.

3.3 Pengembang
Adalah orang yang menghasilkan produk untuk pelanggan.

3.4 Pengguna
Adalah orang yang akan langsung menjalankan atau menggunakan produk. Pengguna dan
pelanggan umumnya adalah orang yang sama.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 1

4. Pertimbangan Pembuatan SKPL yang Baik
Beberapa hal yang harus diperhatikan dalam pembuatan SKPL adalah:
1. Sifat dari SKPL
1. Lingkungan SKPL
1. Karakteristik SKPL yang baik
1. Persiapan SKPL
1. Evolusi SKPL
1. Prototipe SKPL
1. Pemasukan Rancangan pada SKPL
1. Pemasukan kebutuhan proyek pada SKPL

4.1 Sifat dari SKPL

SKPL adalah spesifikasi dari suatu produk/program yang melakukan suatu fungsi tertentu
pada lingkungan tertentu. SKPL dapat dibuat oleh wakil dari pengembang atau wakil dari
pelanggan. Sebaiknya SKPL dibuat bersama-sama oleh pengembang dan pelanggan.
Penulis SKPL harus memperhatikan hal-hal berikut:
1. Fungsionalitas - Untuk apa suatu perangkat lunak dibuat.
1. Antar muka eksternal (External Interface) - Bagaimana perangkat lunak berinteraksi dengan
pengguna, perangkat keras sistem, perangkat keras di luar sistem dan perangkat lunak lain.
1. Performansi - Bagaimana kecepatannya, ketersediaannya (availability), waktu tanggap
(response time), waktu recovery dari berbagai fungsi perangkat lunak.
1. Atribut - Bagaimana tingkat portabilitas, tingkat kebenaran (correctness), tingkat
pemeliharaan (maintainability), keamanannya.
1. Batasan perancangan - Apakah diperlukan suatu standar, bahasa yang khusus, kebijaksanaan
integritas basisdata, batasan sumberdaya, lingkungan operasi, dan lain-lain.

Penulis SKPL harus menghindari kebutuhan perancangan atau kebutuhan proyek dalam SKPL.

4.2 Lingkungan SKPL

Karena SKPL akan memainkan peranan penting dalam proses pengembangan perangkat lunak,
penulis SKPL harus secara berhati-hati dalam memainkan peranannya. Jadi suatu dokumen
SKPL harus memenui syarat-syarat berikut:
1. Mendefinisikan kebutuhan perangkat lunak dengan benar. Kebutuhan perangkat lunak
muncul karena ada pekerjaan yang harus diselesaikan atau karena ada karakteristik khusus
dari projek.
1. Tidak menjelaskan rancangan atau implementasi dengan rinci. Penjelasan tersebut tidak
diperlukan karena bagi pengguna hal tersebut lebih teknis dan tidak perlu.
1. Tidak memaksakan penambahan suatu batasan dari perangkat lunak.

4.3 Karakteristik SKPL yang baik

Karakterisitk SKPL yang baik adalah sebagai berikut:
1. Benar
Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 2
1. Tidak ambigu
1. Lengkap
1. Konsisten
1. Terurut berdasarkan kepentingannya atau kestabilannya
1. Dapat diverifikasi
1. Dapat dimodifikasi
1. Dapat ditelusuri (traceable)

4.3.1 Benar
SKPL dianggap benar jika dan hanya jika setiap kebutuhan yang telah ditetapkan telah
tercantum dalam dokumen. Tidak ada alat (tool) atau prosedur yang dapat digunakan untuk
menjamin kebenaran.

4.3.2 Tidak ambigu

SKPL tidak ambigu jika dan hanya jika setiap kebutuhan yang ditetapkan hanya memiliki
satu interpretasi. Minimum kebutuhan dari setiap karakteristik produk akhir dijelaskan dalam
satu istilah yang unik. Jika istilah tersebut memiliki banyak arti, pada harus diberikan penjelasan.
Jadi SKPL tidak boleh membingungkan baik bagi pembuat ataupun yang akan menggunakannya.

4.3.2.1 Kelemahan Bahasa Manusia

Kebutuhan sering ditulis dalam bahasa manusia (misalnya bahasa Indonesia atau bahasa
Inggris). Bahasa manusia ini sering tidak jelas (ambigu). Bahasa yang digunakan dalam SKPL
harus didiskusikan oleh pihak lain yang independen untuk mengindentifikasi ketidakjelasan
dalam pemakaian bahasa.

4.3.2.2 Bahasa Spesifikasi Kebutuhan

Salah satu cara untuk menghilangkan keraguan dalam penulisan bahasa ini, adalah dengan
menuliskan SKPL dengan suatu bahasa spesifikasi kebutuhan yang khusus. Pemroses bahasanya
akan dapat mendeteksi kesalahan leksikal, sintaks atau semantik.
Kelemahan dalam menggunakan bahasa tersebut adalah waktu yang panjang untuk
mempelajarinya. Juga banyak pengguna non teknis akan kesulitan. Bahasa spesifikasi kebutuhan
ini cenderung akan lebih dapat digunakan pada kebutuhan khusus, dan sistem tertentu.

4.3.2.3 Alat Presentasi

Secara umum, kebutuhan metode dan bahasa serta alat pendukungnya, akan dibagi
menjadi tiga kategori, yaitu objek, proses dan perilaku (behaviour).
Pendekatan berbasis objek akan mengorganisasikan kebutuhan dalam bentuk objek-objek
dengan atribut dan pelayanan (fungsi) yang dimiliki dari setiap objek.
Pendekatan berbasis proses akan mengatur kebutuhan menjadi fungsi-fungsi hirarki yang
saling berkomunikasi melalui suatu jalur aliran data.
Pendekatan berbasis perilaku menjelaskan perilaku eksternal dari sistem dalam suatu
pendekatan abstrak (dengan predikat kalkulus), fungsi matematika atau mesin status.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 3

Tingkat kebergunaan dalam pemakaian suatu tools dan metode mungkin berguna dalam
menyiapkan SKPL tergantung pada ukuran dan kompleksitas dari program. Dalam
menggunakan berbagai pendekatan ini akan lebih baik untuk membentuk deskripsi bahasa alami,
dengan demikian pelanggan yang tidak biasa dengan notasi tersebut akan tetap dapat mengerti
SKPL.

4.3.3 Lengkap
SKPL adalah lengkap jika dan hanya jika sudah melibatkan elemen-elemen berikut:
1. Semua kebutuhan-kebutuhan penting sudah tercakup (fungsionalitas, performansi, batasan
perancangan, atribut atau antar muka eksternal).
1. Semua definisi masukan pada berbagai kondisi sudah terpenuhi
1. Referensi yang lengkap dari setiap gambar, tabel dan diagram pada SKPL, dan disertai
dengan semua istilah yang digunakan dan unit yang digunakan sebagai pengukuran (bila ada).
Penggunaan istilah ‘TBD’ atau ‘To Be Defined’ atau ‘Sedang dalam pengembangan’
menunjukkan SKPL yang tidak lengkap. Tetapi bagaimana pun istilah tersebut sering harus
digunakan. Pada kasus tersebut harus disertai dengan penjelasan yang menyertai pernyataan
tersebut (misalnya kenapa suatu jawaban belum ditemukan), sehingga situasi tersebut akan dapat
diselesaikan. Selain itu perlu didefinisikan cara menghilangkan pernyataan tersebut, dengan
memberikan juga siapa yang bertanggung jawab, dan kapan harus sudah dihilangkan.

4.3.4 Konsisten
Dalam hal ini konsisten berhubungan dengan konsistensi internal. Jika suatu SKPL tidak
mengacu ke dokumen lain yang sifatnya memiliki tingkat lebih tinggi, maka SKPL tersebut tidak
benar.

4.3.4.1 Konsistensi Internal

Suatu dokumen tidak konsisten secara internal jika dan hanya jika tidak ada kebutuhan yang
konflik. Ada tiga tipe yang dapat menyebabkan konflik dalam SKPL:
1. Karakteristik yang ditentukan pada objek nyata mungkin konflik. Misalnya:
1.1. Suatu kebutuhan format laporan keluaran mungkin dijelaskan sebagai tabel, tetapi
pada pada kebutuhan lain berbentuk tekstual.
1.2. Suatu kebutuhan mungkin menyatakan suatu hal yang bertentangan dengan
pernyataan lain
2. Kemungkinan ada konflik logika antara dua aksi, misalnya:
2.1. Suatu kebutuhan mungkin menetapkan bahwa program harus menjumlah dua
masukan dan kebutuhan lain mungkin menentukan harus dikali.
2.2. Suatu kebutuhan menyatakan bahwa suatu status A akan mengikuti status B, tetapi
pernyataan lain menyatakan status B yang akan mengikuti A.
3. Dua atau lebih kebutuhan mungkin dapat dijelaskan dengan objek dunia nyata yang sama,
tetapi karena kebutuhannya berbeda, sebaiknya menggunakan istilah yang berbeda.
Misalnya suatu program yang meminta masukan dari pengguna mungkin disebut sebagai
prompt, tetapi pada kebutuhan lain mungkin disebut membaca masukan dari pengguna.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 4

4.3.5 Pengurutan berdasarkan kepentingannya/kestabilannya
Suatu SKPL diurutkan berdasarkan tingkat kepentingan/kestabilan dari setiap
kebutuhannya. Hal tersebut dapat diberikan suatu tanda untuk menunjukkan kepentingan atau
kestabilannya. Umumnya semua kebutuhan yang berhubungan dengan produk perangkat lunak
tidak memiliki kepentingan yang sama. Beberapa kebutuhan mungkin bersifat harus, khususnya
untuk aplikasi yang kritis, sementara yang lain bersifat sebaiknya.
Setiap kebutuhan dalam SKPL harus diidentifikasi agar perbedaan ini jelas dan eksplisit.
Pengenalan kebutuhan yang ada dengan cara berikut mungkin akan dapat membantu:
1. Pelanggan harus memberikan pemikiran yang rinci terhadap kebutuhannya, yang sering akan
memperjelas setiap asumsi yang sebelumnya tersembunyi.
1. Pengembang harus melakukan perancangan yang benar dan bersungguh-sungguh melakukan
usaha yang sesuai dengan levelnya pada bagian yang berbeda dari perangkat lunak.

4.3.5.1 Tingkat Kestabilan

Suatu metode untuk mengenali kebutuhan adalah dengan menggunakan dimensi
kestabilan. Kestabilan dapat dinyatakan dalam jumlah perubahan yang diharapkan pada setiap
kebutuhan yang berdasarkan pada pengalaman atau pengetahuan akan kejadian yang akan datang
yang mungkin dapat berakibat pada organisasi, fungsi , orang yang didukung oleh sistem
perangkat lunak.

4.3.5.2 Tingkat Keperluan (Degree of Necessity)

Cara lain untuk mengurutkan kebutuhan adalah dengan membedakan kelas kebutuhan
sebagai bersifat perlu, kondisional dan opsional.
1. Sifat Perlu menunjukkan bahwa perangkat lunak tidak akan diterima jika kebutuhan-
kebutuhan tidak disetujui secara tidak jelas
1. Sifat Kondisional menunjukkan bahwa kebutuhan-kebutuhan ini akan memperbaiki produk
perangkat lunak, dan tidak akan diterima jika tidak ada.
1. Sifat Opsional menunjukkan kelompok fungsi yang mungkin berguna atau mungkin tidak.
Pengembang akan mendapat kesempatan untuk mengajukan sesuatu yang melebihi SKPL.

4.3.6 Dapat diverifikasi

Suatu SKPL disebut dapat diverfikasi, jika dan hanya jika setiap kebutuhan sudah
terverifikasi. Suatu kebutuhan dapat diverifikasi jika dan hanya jika ada suatu proses yang efektif
untuk mmeriksa apakah suatu produk perangkat lunak sudah memenuhi kebutuhan. Jadi secara
umum, kebutuhan yang ambigu tidak dapat diverifikasi.
Kebutuhan yang tidak dapat diverifikasi termasuk pernyataan seperti “bekerja dengan
baik”, “interaksi manusia yang baik” atau “biasanya terjadi”. Kebutuhan-kebutuhan ini tidak
dapat diverikasi karena hampir tidak mungkin mendefinisikan istilah baik, atau biasanya.
Pernyataan “program jangan pernah masuk ke pengulangan yanag tidak terbatas” juga tidak dapat
diverifikasi, karena pengujian kualitas ini secara teori tidak mungkin.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 5

 Contoh pernyataan yang dapat diverifikasi: “Keluaran program harus diproduksi dalam 20
detik dan harus diproduksi lagi selama 30 detik”. Statement tersebut dapat diverifikasi kaena
penggunaan istilah dan kuantitas yang terukur.

4.3.7 Dapat dimodifikasi

SKPL dapat dimodifikasi, jika dan hanya jika strukturnya memungkinkan setiap
perubahan terhadap kebutuhan dapat dibuat dibuat secara mudah, lengkap dan konsisten, dengan
tetap mempertahankan struktur. Kemampuan dapat dimodifikasi umumnya menghendaki SKPL
yang,
1. memiliki organisasi yang mudah digunakan dengan daftar isi, indeks dan cross-reference.
1. tidak ada duplikasi yang tidak perlu. Jadi suatu kebutuhan tidak perlu muncul lebih dari satu
tempat di SKPL
1. Setiap kebutuhan sebaiknya dinyatakan secara terpisah.
Duplikasi sendiri bukanlah suatu kesalahan, tetapi adalah sumber terjadinya kesalahan. Duplikasi
dapat membantu membuat SKPL menjadi lebih mudah dibaca, tetapi masalah muncul jika ada
proses terhadap duplikasi dokumen. Misalnya jika suatu kebutuhan diubah hanya pada satu
dokumen, akan menyebabkan tidak konsisten. Jika memang diperlukan duplikasi, SKPL harus
menyertakan cross-reference yang membuatnya dapat dimodifikasi.

4.3.8 Dapat ditelusuri (traceable)

SKPL dapat ditelusuri jika asal dari kebutuhan sudah jelas dan memberikan fasilitas untu
mereferensi setiap kebutuhan dalam pengembangan masa depan dan perbaikan dokumen. Dua
tipe kemampuan penelusuran dibutuhkan.
1. Dapat ditelusuri ke belakang (Backward Traceability) atau ke tahapan sebelumnya. Hal ini
tergantung pada setiap kebutuhan yang mereferensi ke sumber pada dokumen sebelumnya.
1. Dapat ditelusuri ke depan (Forward Traceability) atau semua dokumen yang dihasilkan
setelah SKPL. Hal ini tergantung pada setiap kebutuhan dalam SKL memiliki nomor yang
khas (nomor referensi).
Penelusuran ke depan dari SKPL akan sangat penting ketika produk perangkat lunak memasuki
fase operasi dan perawatan. Saat dokumen perancangan dan kode program di modifikasi, adalah
penting untuk memastikan bahwa semua kebutuhan akan terkait dengan modifikasi tersebut.

4.4 Persiapan Bersama SKPL

Dalam proses pengembangan perangkat lunak mula-mula harus disepakati perjanjian
antara pengembang dan pelanggan tentang apa yang harus dilakukan oleh perangkat lunak.
Perjanjian ini, dalam bentuk SKPL, harus dipersiapkan bersama. Hal ini penting karena biasanya
baik pelanggan ataupun pengembang itdak dapat menulis SKPL sendiri.
1. Pelanggan biasanya tidak mengerti proses perancangan dan pengembangan yang cukup
untuk menulis SKPL
1. Pengembang biasanya tidak mengerti masalah pelanggan untuk menentukan setiap
kebutuhan.
Karena itu pelanggan dan pengembang harus bekerja sama mengembangkan SKPL.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 6

 Situasi khusus mungkin terjadi jika sistem dan perangkat lunak dibuat secara bersama.
Maka fungsioalitas, antar muka, performansi dan batasan lain dari perangkat lunak tidak
terdefinisi sebelumnya, tetapi terdefinisi secra bersama-sama, dan biasanya ini adalah
memerlukan negosiasi. Kasus ini akan lebih sulit, tapi tetap harus memperhatikan hal-hal yang
sudah dituliskan di 4.3. Jadi secara khusus, SKPL yang tidak sesuai dengan kebutuhan adalah
SKPL yang tidak benar.

4.5 Evolusi SKPL

SKPL dapat berevolusi seperti juga pada pengembangan perangkat lunak. Karena
mungkin tidak mungkin untuk men-spesifikasi-kan secara rinci pada saat proyek dimulai.
Perubahan-perubahan tambahan diperlukan untuk efisiensi, menutupi kelemahan-kelemahan atau
ketidakakuratan pada SKPL. Dua pemikiran dalam proses ini adalah sebagai berikut:
1. Kebutuhan harus dispesifikasikan secara lengkap. Bila belum lengkap harus dicatat.
1. Proses perubahan formal dapat dimulai untuk mengidentifikasi, mengendalikan, menelusuri
dan melaporkan setiap perubahan.

4.6 Prototipe SKPL

Prototipe sering digunakan selama fase kebutuhan dalam proyek. Banyak tool yang sudah
tersedia untuk membuat prototipe, yang hanya menampilkan beberapa aspek karakteristik dari
sistem. Prototipe ini biasanya dibuat dengan sangat cepat dan mudah. Prototipe akan berguna
karena tiga alasan:
1. pelanggan biasanya lebi mudah melihat prototipe daripada membaca SKPL. Jadi kadang-
kadang prototipe dapat memberikan masukan dengan cepat
1. Prototipe menampilkan aspek yang tidak terantisipasi dalam melihat perilaku sistem. Jadi
kadang-kadang tidak hanya memberikan jawaban tetapi juga menimbulkan pertanyaan baru.
Hal ini akan membantu pelengkapan SKPL
1. SKPL yang menggunakan teknik prototipe akan cenderung mengalami perubahan sealma
pengembangan, sehingga mengurangi waktu pengembangan.

4.7 Pemasukan Rancangan pada SKPL

Suatu kebutuhan mendefinisikan fungsi yang terlihat dari sistem. Suatu rancangan
menjelaskan tentang subkomponen dari sistem atau antarmukanya dengan komponen lain.
Penulis SKPL harus secara jelas membedakan antara pengenalan batasan rancangan. Jadi setiap
kebutuhan dalam SKPL akan membatasi setiap alternatif perencanaan. Tetapi hal ini bukan
berarti setiap kebutuhan sudah dirancang.
SKPL harus menentukan fungsi-fungsi yang akan dilakukan terhadap suatu data untuk
memberikan suatu hasil pada seseorang. SKPL harus memfokuskan pada layanan yang
dilakukan. SKPL seharusnya tidak menspesifikasikan item rancangan sebagai berikut:
1. Pembagian perangkat lunak menjadi modul-modul
1. Pengalokasian suatu fungsi dari modul-modul
1. Penjelasan aliran informasi antar bagian dari program
1. Pemilihan struktur data

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 7

Pada kasus khusus, beberapa kebutuhan akan membatasi rancangan secara tegas. Misalnya
kebutuhan akan keamanan atau keselamatan mungkin dapat dirancang secara langsung ke
perancangan untuk memenuhi kebutuhan:
1. Pemisahan fungsi dan modul
1. Hanya mengijinkan komunikasi antar area dalam program
1. Pemeriksaan integritas data untuk variabel kritis
Contoh batasan perancangan yang baik adalah kebutuhan fisik, kebutuhan performansi, standard
pengembangan perangkat lunak dan standard jaminan kualitas perangkat lunak.
Jadi kebutuhan harus dinyatakan dari sudut pandang eksternal. Jika menggunakan model ini
untuk mengilustrasikan kebutuhan, ingat bahwa model hanya menyatakan perilaku eksternal, dan
tidak menspesifikasikan perancangan.

4.8 Pemasukan kebutuhan proyek pada SKPL

SKPL seharusnya menyelesaikan persoalan hasil jadi perangkat lunak, bukan proses
untuk menghasilkannya. Kebutuhan proyek mewakili pengertian antara pelanggan dan
pengembang tentang masalah kontrak yang berhubungan dengan produksi perangkat lunak dan
sebaiknya tidak diikut sertakan dalam SKPL. Hal-hal yang diperahtikan antara lain:
1. Biaya
1. Jadwal penyerahan
1. Aturan pelaporan
1. Metode Pengembangan Perangkat Lunak
1. Jaminan Kualitas
1. Kriteria Validasi dan Verifikasi
1. Aturan penerimaan (acceptance procedure).
Kebutuhan proyek akan ditentukan pada dokumen lain, umumnya dalam dokumen perencanaan
pengembangan perangkat lunak, perencanaan jaminan kualitas atau statement of work.

5. Bagian-bagian SKPL
Bagian-bagian penting dari SKPL adalah sebagai berikut:

Daftar Isi
1. Pendahuluan
1.1 Tujuan
1.2 Lingkup Masalah
1.3 Definisi, Akronim dan Singkatan
1.4 Referensi
1.5 Deskripsi umum (Overview)

2. Deskripsi Keseluruhan
2.1 Perspektif produk
2.2 Fungsi Produk
2.3 Karakteristik Pengguna
2.4 Batasan-batasan
Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 8
 2.5 Asumsi dan Ketergantungan

3. Kebutuhan khusus (penjelasan ada di lampiran A)

Lampiran
Indeks

5.1 Pendahuluan
Pendahuluan dari SKPL harus memberikan gambaran umum dari seluruh SKPL. Dan harus berisi
bagian-bagian berikut:
1.1 Tujuan
1.2 Lingkup Masalah
1.3 Definisi, Akronim dan Singkatan
1.4 Referensi
1.5 Deskripsi umum (Overview)

5.1.1 Tujuan
Bagian ini harus menunjukkan tujuan SKPL, dan juga menentukan siapa yang akan
menggunakan SKPL ini.

5.1.2 Lingkup Masalah

Bagian ini harus:
1. Mengidentifikasi produk perangkat lunak berdasarkan nama (misalnya DBMS yang
digunakan, Report Generator, dan lain-lain).
1. Menjelaskan apa yang akan dilakukan dan tidak dilakukan (bila perlu) oleh perangkat lunak
1. Penjelasan aplikasi yang ditentukan termasukan keuntungan, dan tujuan
1. Konsisten dengan spesifikasi sistem yang diberikan (jika ada)

5.1.3 Definisi, akronim dan singkatan

Harus memberikan penjelasan terhadap semua definisi, akronim dan singkat yang digunakan
untuk menginterpretasikan SKPL. Informasi ini dibagi dengan mereferensikan satu atau lebih
lampiran dalam SKPL atau referensi ke dokumen lain.

5.1.4 Referensi
Bagian ini harus memberikan:
1. Daftar lengkap dari dokumen yang direferensikan
1. Identifikasi dari setiap dokumen berdasarkan judul, nomor laporan, tanggal dan penerbit
1. sumber-sumber referensi yang didapat

5.1.5 Deskripsi Umum

Bagian ini menjelaskan apa isi SKPL, dan bagaimana organisasi SKPL.
Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 9
5.2 Deskripsi Umum
Bagian ini menjelaskan faktor-faktor umum yang berakibat pada produk dan kebutuhannya.
Bagian ini tidak memberikan kebutuhan rinci, hanya latar belakang dari kebutuhan tersebut yang
akan dibuat lebih rinci di bagian 3. Dengan organisasi ini diharapkan hasilnya lebih mudah
dimengerti. Bagian ini terdiri dari
2.1 Perspektif produk
2.2 Fungsi Produk
2.3 Karakteristik Pengguna
2.4 Batasan-batasan
2.5 Asumsi dan Ketergantungan

5.2.1 Perspektif produk

Bagian ini akan memberikan penjelasan perspektif produk dengan produk yang terkait.
Jika produk tidak tergantung maka harus juga dinyatakan di sini. Jika SKPL mendefinisikan
produk sebagai komponen sistem yang lebih besar (hal ini sering terjadi), maka bagian ini harus
menghubungkan dengan kebutuhan dari sistem yang lebih besar ini hingga fungsionalitas dari
perangkat lunak dan harus mengindentifikasikan antarmuka antara sistem dan perangkat lunak.
Suatu diagram blok dapat menunjukkan komponen utama dari sistem yang lebih besar,
interkoneksi dan antarmuka eksternal.
Bagian ini harus menjelaskan bagaimana perangkat lunak akan beroperasi dalam berbagai
batasan. Bagian ini biasanya melibatkan:
1. Antarmuka Sistem
1. Antarmuka Pemakai
1. Antarmuka Perangkat Keras
1. Antarmuka Perangkat Lunak
1. Antarmuka Komunikasi
1. Batasan Memori
1. Operasi
1. Kebutuhan adaptasi lokasi

5.2.1.1 Antarmuka Sistem

Bagian in akan menampilkan antaramuka sistem dan mengidentifikasi fungsionalitas dari
perangkat lunak untuk mencapai kebutuhan sistem dan deskripsi antarmuka untuk mencocokkan
sistem.

5.2.1.2 Antarmuka Pemakai

Bagian ini akan berisi hal-hal berikut:
1. Karakteristik logis dari setiap antarmuka antara produk perangkat lunak dan penggunanya.
Hal ini akan melibatkan karakteristik konfigurasi (misalnya format layar yang diperlukan,
tataletak window, isi laporan/menu atau ketersediaan kunci khusus) untuk memenuhi
kebutuhan sistem.
1. Semua aspek optimisasi antarmuka dengan orang yang akan menggunakan sistem. Bagian ini
mungkin hanya berisi daftar yang harus dan tidak akan dilakukan oleh sistem bagi sudut
Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 10
 pandang pengguna. Misalnya kebutuhan untuk pemilihan pesan yang singkat atau panjang.
Seperti kebutuhan lain, kebutuhan ini harus dapat di verifikasi. Misalnya kalimat “seorang
pegawai berpengalaman dapat melakukan X dalam Z menit setelah 1 jam training” akan lebih
baik daripada hanya mendefinisikan “Seorang pegawai berpengalaman dapat melakukan X”.

5.2.1.3 Antarmuka Perangkat Keras

Bagian ini akan menjelaskan karakteristik logis dari setiap antarmuka antara produk
perangkat lunak dan komponen perangkat keras dari sistem. Bagian ini akan melibatkan
karakteristik konfigurasi (jumlah port, jumlah instruksi, dll). Antarmuka ini juga melibatkan hal-
hal seperti perangkat pendukung, dan bagaimana peralatan tersebut menjadi pendukung, dan
protokol.

5.2.1.4 Antarmuka Perangkat Lunak

Bagian ini menspesifikasikan penggunaan produk perangkat lunak lain (misalnya sistem
manajemen basisdata, sistem operasi atau paket matematik) dan antarmuka dengan sistem
aplikasi lain (sebagai contoh hubungan antara sistem account receivable dan sistem General
Ledger). Untuk setiap perangkat lunak yang dibutuhkan, harus disertai dengan:
1. Nama
1. Mnemonic
1. Nomor spesifikasi
1. Nomor Versi
1. Sumber
Untuk setiap antarmuka, harus disertai dengan hal-hal berikut:
1. Diskusi dari kegunaan antarmuka perangkat lunak dan hubungannya dengan produk
perangkat lunak
1. Definisi dari antarmuka dalam bentuk isi pesan dan formatnya. Adalah tidak perlu untuk
merinci antarmuka yang sudah terdokumentasi dengan baik, jadi sebaiknya yang dilakukan
adalah dengan melakukan referensi terhadap dokumennya.

5.2.1.5 Antarmuka Komunikasi

Bagian ini harus menspesifikasikan berbagai antarmuka untuk komunikasi, seperti
protokol jaringan lokal, dll

5.2.1.6 Batasan Memori

Bagian ini menspesifikasikan setiap karakteristik dan batasan memori primer dan
sekunder

5.2.1.7 Operasi
Bagian ini menentukan operasi normal dan operasi khusus yang dibutuhkan oleh
pengguna seperti misalnya:
1. Berbagai variasi mode operasi dalam organisasi pengguna, misalnya operasi yang bersifat
user-initiated (inisiatif dari pengguna)
1. Periode operasi interaktif dan periode operasi yang tidak diinginkan
Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 11
1. Fungsi pendukung pemrosesan data
1. Operasi backup dan recovery

5.2.1.8 Kebutuhan adaptasi lokasi

Bagian ini dapat berisi:
1. Pendefinisian kebutuhan untuk setiap data atau urutan inisialisasi yang tergantung pada lokasi
yang diberikan, misi atau mode operasi (misalnya batasan keselamatan, dll).
1. Menspesifikasikan lokasi atau ciri yang berhubungan dengan misi yang harus dimodifikasi
untuk mengadaptasi perangkat lunak terhadap suatu instalasi yang khusus.

5.2.2 Fungsi Produk

Pada bagian ini SKPL akan memberikan kesimpulan dari fungsi yang umum yang akan
dilakukan oleh perangkat lunak. Sebagai contoh SKPL untuk program akuntansi dapat
menggunakan bagian ini untuk menjelaskan perawatan akunting dari pengguna, pernyataan
pengguna dan persiapan invoice tanpa menyebutkan rincian dari fungsi yang membutuhkan.
Kadang-kadang kesimpulan dari fungsi yang diperlukan untuk bagian ini dapat diambil
secara langsung dari bagian spesifikasi yang lebih tinggi (jika ada) yang akan mengalokasikan
fungsi khusus dari produk perangkat lunak. Perhatikan bahwa untuk alasan kejelasan:
1. Fungsi harus diorganisasikan dengan suatu cara sehingga daftar fungsi dapat dimengerti oleh
pengguna atau orang lain yang membaca dokumen pertama kali
1. Metode tekstual dan grafik dapat digunakan untuk menunjukkan fungsi yang berbeda dan
keterhubungannya. Diagram ini tidak ditujukan untuk menunjukkan perancangan produk
tetapi juga menunjukkan hubungan logik antar variabel.

5.2.3 Karakteristik Pengguna

Bagian ini akan menjelaskan karakteristik umum yang diinginkan terhadap pengguna
produk termasuk tingkat pendidikan, pengalaman dan keahlian teknis tertentu. Bagian ini
sebaiknya tidak digunakan untuk menyatakan kebutuhan yang spesifik tetapi lebih kepada alasan
mengapa kebutuhan tersebut diperlukan.

5.2.4 Batasan-batasan
Bagian SPKL ini berisi deskripsi umum dari item lain yang akan membatasi pilihan
pengembangan. Hal-hal tersebut antara lain:
1. Kebijaksanaan umum
1. Keterbatasan perangkat keras
1. Antar muka ke aplikasi lain
1. Operasi paralel
1. Fungsi audit
1. Fungsi kendali
1. Kebutuhan bahasa tingkat tinggi
1. Protokol sinyal komunikasi (misalnya XON-XOFF, ACK, NACK).
1. Kebutuhan keandalan
1. Tingkat kritis dari aplikasi
Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 12
1. Masalah keamanan dan keselamatan

5.2.5 Asumsi dan Ketergantungan

Bagian ini akan menampilkan daftar faktor yang akan berakibat pada kebutuhan yang
telah ditentukan oleh SKPL. Faktor-faktor ini bukan pembatasan perancangan perangkat lunak,
tetapi lebih kepada perubahan-perubahan yang dapat berakibat pada kebutuhan dari SKPL.
Sebagai contoh asumsi bahwa suatu sistem operasi akan tersedia pada suatu perangkat keras dari
produk perangkat lunak. Jika sistem operasi tidak ada maka SKPL harus diubah karena hal
tersebut.

5.2.6 Pembagian Kebutuhan

Bagian dari SKPL ini akan mengidentifikasi kebutuhan yang ditunda hingga versi berikutnya dari
sistem.

5.3 Kebutuhan Khusus

Bagian SKPL ini harus berisi semua kebutuhan perangkat lunak hingga pada tingkat rinci
yang memungkin pengembang untuk merancang sistem, untuk memenuhi kebutuhan-kebutuhan
itu dan juga bagi penguji untuk menguji sistem terhadap kebutuhan. Pada bagian ini, setiap
kebutuhan yang telah ditetapkan harus menyadari secara eksternal oleh pengguna, opoerator atau
sistem eksternal lain. Kebutuhan ini harus melibatkan deskripsi minimum dari setiap masukan ke
sistem, setiap keluaran dari sistem dan semua fungsi yang dilakukan oleh sistem untuk merespons
terhadap masukan (stimulus) dan keluaran (respon) dari sistem dan semua fungsi dilakukan oleh
sistem sebagai respon terhadap masukan/keluaran. Karena bagian ini merupakan bagian yang
paling besar dan bagian penting dari SKPL. Prinsip-prinsip yang digunakan:
1. Kebutuhan khusus harus dinyatakan sesuai dengan karakteristiknya
1. Kebutuhan khusus harus di-cross-reference-kan dengan dokumen sebelumnya yang
berhubungan
1. Semua kebutuhan harus dapat diidentifikasi secara unik.
1. Perhatian lebih harus diberikan untuk mengorganisasikan kebutuhan hingga memaksimalkan
readability.
Sebelum melihat cara mengatur kebutuhan yang akan beguna untuk mengerit item-item yang ada
pada kebutuhan

5.3.1 Antar muka eksternal

Bagian ini akan memberikan penjelasan rinci terhadap semua masukan dan keluaran dari sistem
perangkat lunak. Bagian ini akan mendukung deskripsi antarmuka di 5.2, dan jangan melakukan
pengulangan informasi disini.
Akan juga dilibatkan isi dan format sebagai berikut:
1. Nama item
1. Deskripsi penggunaan
1. sumber masukan atau tujuan keluaran
1. Jangkauan yang diterima, kebenaran atau toleransi.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 13

1. Unit pengukuran
1. Pewaktuan (timing)
1. Keterhubungan dengan masukan/keluaran lain
1. format/organisasi layar
1. format/organisasi window
1. format data
1. format perintah
1. Pesan-pesan akhir

5.3.2 Fungsi-fungsi
Kebutuhan fungsional harus mendefinisikan aksi dasar yang harus diambil oleh perangkat
lunak untuk menerima dan memproses masukan dan menghasilkan keluaran. Hal ini umumnya
dinyatakan dengan kata ‘akan’. Misalnya, sistem akan...
Bagian yang terlibat
1. Validasir masukan
1. Urutan operasi yang pasti
1. Respon terhadap situasi abnormal termasuk kejadian overflow, fasilitas komunikasi atau
penanganan kesalahan dan recovery.
1. Efek pada parameter
1. Keterhubungan dari keluaran ke masukan, termasuk urutan masukan/keluaran, atau formula
untuk konversi masukan ke keluaran.
Dapat dilakukan juga pembagian kebutuhan fungsional menjadi sub fungsional aau sub proses.
Hal ini tidak berarti bahwa perancangan perangkat lunak akan dibagi dengan cara seperti itu.

5.3.3 Kebutuhan perfomansi

Bagian ini harus menspesifikasikan baik kebutuhan numerik statik/dinamik yang terletak
pada interaksi perangkat lunak atau pada interaksi manusia dengan perangkat lunak secara
keseluruhan. Kebutuhan numerik statis mungkin melibatkan:
1. Jumlah terminal yang didukung
1. Jumlah pengguna simultan yang didukung
1. Jumlah dan tipe informasi yang ditangani
Kebutuhan numerik statik sering diidentifikasi pada bagian terpisah ayng disebut
kapasitas.
Kebutuhan numerik dinamik mungkin dapat melibatkan, sebagai contoh, jumlah transaksi
dan tugas dan jumlah hdata yang akan diproses selama jangka waktu tertentu, baik kondisi
normal atau kondisi beban puncak.
Semua kebutuhan ini harus dinyatakan dalam istilah yang dapat diukur. Contohnya,
kalimat “95 % transaksi harus diproses dalam 1 detik”, akan lebih baik daripada kalimat
“operator mungkin tidak harus menunggu transaksi akan selesai.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 14

5.3.4 Kebutuhan Basisdata logik
Kebutuhan ini harus menspesifikasi kebutuhan logis untuk setiap informasi yang
diletakkan ke basisdata, antara lain:
1. Tipe informasi yang digunakan oleh berbagai fungsi
1. Frekuensi pemakaian
1. Kemampuan pengaksesan
1. Entitas data dan keterhubungannya
1. Batasan integritas
1. kebutuhan pemakaian data

5.3.5 Batasan perancangan

Bagian ini akan menspesifikasikan batasan perancangan yang akan dihasilkan oleh
standar lain, keterbatasan perangkat keras, dan lain-lain

5.3.5.1 Pemenuhan Standard

Bagian ini akan menspesifikasikan kebutuhan yang diturunkan dari standar yang ada atau
aturan, antara lain:
1. Format laporan
1. Penamaan data
1. Aturan akunting
1. Penelusuran audit
Sebagai contoh, bagian in dapat menentukan kebutuhan perangkat lunak untuk menelusuri
aktivitas pemrosesan. Penelusuran ini diperlukan untuk suatu aplikasi agar sesuai dengan
peraturan minimum dan standar keuangan. Kebutuhan penelusuran audit, sebagai contoh,
menyatakan bahwa semua perubahan harus dicatat pada suatu file khusus untuk penelusuran
dengan isi sebelum dan sesudah dilakukan.

5.3.6 Aturan sistem perangkat Lunak

Ada sejumlah atribut perangkat lunak yang dapat ditampilkan sebagai kebutuhan. Adalah penting
bahwa atribut yang diinginkan harus dispesifikasi sehingga hasilnya dapat diverifikasi. Item-item
berikut akan memberikan contoh kecil.

5.3.6.1 Keandalan
Bagian ini akan menspesifikasi faktor yang dibutuhkan untuk membentuk keandalan
sistem pada saat diterimakan.

5.3.6.2 Ketersediaan.
Bagian ini akan berisi faktor untuk menjamin tingkat ketersediaan seluruh sistem seperti
checkpoint, recovery dan restart.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 15

5.3.6.3 Keamanan
Bagian ini berisi faktor untuk memproteksi perangkat lunak dari akses yang mendadak
atau akses yang merusak, mengubah, dll. Kebutuhan yang spesifik termasuk hal-hal berikut:
1. Penggunakan teknik kriptografi
1. Menyimpan data log/history
1. Memberikan suatu fungsi ke modul-modul yang berbeda
1. Membatasi komunikasi antara suatu area dalam program
1. Memeriksa integritas data untuk nilai-nilai kritis

5.3.6.4 Tingkat perawatan (Maintainability)

Bagian ini akan menentukan atribut dari perangkat lunak yang berhubungan dengan
kemudahan perawatan dari perangkat lunak tersebut. Ada beberapa kebutuhan untuk modularitas,
antar muak, kompleksitas, dan lain-lain.

5.3.6.5 Portabilitas
Atribut dari perangkat lunak yang berhubungan dengan kemudahan porting perangkat
lunak ke mesin lain/perangkat operasi lain. Hal-hal yang harus diperhatikan:
1. Persentase komponen yang berisi kode yang independent
1. Persentase komponen yang tergantung pada host
1. Penggunaan bahasa yang portabilitasnya terbukti
1. Penggunaan suatu kompilator/bahasa
1. Penggunan suatu sistem operasi

5.3.7 Pengorganisasian kebutuhan khusus

Untuk setiap sistem (kecuali yang sangat sederhana) kebutuhan rinci cenderung menjadi
luas. Untuk alasan ini, direkomendasikan cara-cara yang hati-hati dalam mengorganisasikan agar
mudah dimengerti. Umumnya tidak ada organisasi yang optimal pada seluruh sistem. Perbedaan
kelompok sistem cendreung akan melibatkan mereka ke organisasi kebutuhan yang berbda
dengan baigan 3 dari SKPL. Beberapa dari organisasi ini dijelaskan sebagai berikut:

5.3.7.1 Mode sistem

Beberapa sistem berlakuk agak berbeda tergantung pada mode operasi. Sebagai contoh
sistem kendali mungkin memiliki sekumpulan fungsi yang berbeda tergantung modenya
(training, normal atau berbahaya). Dengan mengorganisasikan bagian ini dengan mode, gunakan
outline seperti di lampiran. Pemilihan bergantung pada apakah antar muka dan performansi
tergantung pada model.

5.3.7.2 Kelompok pengguna

Beberapa sistem membuthkan fungsi yang berbeda terhadap kelompok yang berbda dari
pengguna. Sebagai contoh sistem elevator melibatkan umum (pengguna elevator), pekerjan
maintenance dan pemadam kebakaran. Jika menggunakan bagian ini sebagai kelas gunakan
lampian A.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 16

5.3.7.3 Objek
Objek adalah entitas dunia yang memiliki hubungan dnegan sistem. Sebagai contoh
sistem monitoring pasien, objek termasuk pasien, perawat, sensor, runang, doketr, obat, dll. Pada
seitap obejk memiliki atribut dan fungsi.

5.3.7.4 Feature
Suatu feature adalah pelayanan yang dinginkan secara eksternal oleh sistem yang
membutuhkan serangkaian masukan yang memberi efek terhadap hasil. Sebagai contoh pada
sistem telpon, feature-nya adalah hubungan lokal, call forwarding dan conference call. Setiap
feature umumnya dijelaskan dalam pasangan stimulus-response. Jika digunakan bagian ini,
gunakan outline di bagian 5 dari lampiran A.

5.3.7.5 Stimulus
Beberapa sistem akan lebih baik diorganisasikan berdasarkan stimulus. Misalnya
fungsi0fungsi sistem pendaratan pesawat udar mungkin diorganisasikan menjadi bagian loss of
power, wind shear, sudden change in roll, vertical velocity excessive, dll. Jika diorganisasikan
sebagai stimulus, gunakan outline di lampiran A bagian 6.

5.3.7.6 Respons
Beberapa sistem dapat diorganisasikan dengan menejlaskan semua fungsi dalam
mendukung pembangkitan respons. Misalnya fungsi sistem personil dapat diorganisasikan
menjadi bagian-bagian yang berhubungan dengan semua fungsi yang diasosiasikan dengan
pembangkitan cek pembayaran, fungsi-fungsi yang berhubungan daftar pegawai, dll. Gunakan
A.6 di lampiran.

5.3.7.7 Hirarki fungsional

Jika tidak ada skema di atas yang terbukti berguna, fungsionalitas keseluruhan dapat
diorganisasikan menjadi fungsi hirarki dengan masukan, keluaran dan akses data internal. DFD
dan kamus data dapat digunakan untuk menunjukkan keterhubungan antara fungsi dan data.
Gunakan A.7 di lampiran A.

5.3.8 Komentar Tambahan

Pada SKPL yang menggunakan lebih dari satu teknik organisasi dapat menggunakan
teknik di 5.3.7.7. pada kasus tersebut dengan mengorganisasikan kebutuhan spesifik untuk hirarki
ganda, dihubungkan dengan kebutuhan spesifik dari sistem. Bagian A.8 dari lampiran A
digunakan organisasi dengan mengkombinasikan user class dan feature. Kebutuhan tambahan
dapat diletakan dalam bagian yang berbeda dalam SKPL.
Banyak notas, metode dan dukungan alat yang otomatis untuk membantu dokumentasi
kebutuhan. Umumnya kegunaannya adalah fungsi dari organisasi. Sebagai contoh, jika
diorganisasikan dengan mode, finite state machine, atau stat chart mungkin dapat berguna. Jika
diorganisasikan sebagai objek, OOA mungkin dapat membatnu. Jika diorganisasikan sebagia
feature, urutan stimulus-respones mungkin akan berguna. Ketika mengorganisasikan hirarki
fungsional, dfd dan kamus data sudah terbukti dapat membantu. Bagian kebutuhan fungsionalitas
dari lampiran A, bagian A1 s/d A8 dapat dijelaskan dalam suatu bahasa kalimat, pseudo code, dll.
Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 17
5.4 Informasi tambahan
Dukungan informasi yang membuat SKPL mudah digunakan, antara lain:
1. Daftar isi
1. Index
1. Lampiran

5.4.1 Daftar isi dan Index

Daftar isi dan index adalah cukup penting dan harus mengikuti standard yang ada.

5.4.2 Lampiran-lampiran
Lampiran tidak selalu menjadi bagian dari spesifikasi kebutuhan aktual dan tidak harus perlu.
Lampiran dapat berisi:
1. contoh format masukan/keluaran, deskripsi analisa biaya, hasil survey
1. dukungan informasi yang membantu SKPL.
1. Deskripsi dari masalah yang dipecahkanoleh perangkat lunak.
1. Instruksi khusus, dan media yang cocok untuk pengamatan, dan kebutuhan lain.
Jika disertakan lampiran, SKPL harus secara eksplisit menegaskan apakah lampiran ini adalah
bagian dari kebutuhan.

Panduan Penulisan SKPL/RPL-Terapan/Bayu Hendradjaya 18

 Lampiran A
A.1 Template SKPL bagian 3 diorganisasikan oleh mode : Versi 1
3. Kebutuhan Khusus
3.1. Kebutuhan antarmuka eksternal
3.1.1. Antarmuka pemakai
3.1.2. Antarmuka perangkat keras
3.1.3. Antarmuka perangkat lunak
3.1.4. Antarmuka komunikasi
3.2. Kebutuhan fungsional
3.2.1. Mode 1
3.2.1.1. Kebutuhan fungsionlitas 11.1
3.2.1.2. ...
3.2.1.3. ...
3.2.1.4. kebutuhan fungsionlitas 1.n
3.2.2. Mode 2
3.2.2.1. Kebutuhan fungsionlitas 11.1
3.2.2.2. ...
3.2.2.3. ...
3.2.2.4. kebutuhan fungsionlitas 1.n
3.2.3. Mode ...
3.2.4. Mode m
3.2.5. ..
3.3. Kebutuhan performansi
3.4. Batasan perancangan
3.5. Atribut sistem perangkat lunak
3.6. Kebutuhan lain

A.2 Template SKPL bagian 3 diorganisasikan oleh mode : Versi 2

3. Kebutuhan Khusus
3.1. Kebutuhan fungsional
3.1.1. Mode 1
3.1.1.1. Antarmuka eksternal
3.1.1.1.1. Antarmuka pemakai
3.1.1.1.2. Antarmuka perangkat keras
3.1.1.1.3. Antarmuka perangkat lunak
3.1.1.1.4. Antarmuka komunikasi
3.1.1.2. Kebutuhan fungsionlitas 1.1
3.1.1.2.1. Kebutuhan fungsionalitas 1
3.1.1.2.2. ....
3.1.1.2.3. ....
3.1.1.2.4. kebutuhan fungsionlitas n
3.1.1.3. Performansi
3.1.2. Mode 2
3.1.3. .....
 3.1.4. ....
3.1.5. Mode n
3.2. Batasan perancangan
3.3. Atribut sistem perangkat lunak
3.4. Kebutuhan lain

A.3 Template SKPL bagian 3 diorganisasikan dengan kelas pengguna

3. Kebutuhan Khusus
3.1. Kebutuhan antarmuka eksternal
3.1.1. Antarmuka pemakai
3.1.2. Antarmuka perangkat keras
3.1.3. Antarmuka perangkat lunak
3.1.4. Antarmuka komunikasi
3.2. Kebutuhan fungsional
3.2.1. User class 1
3.2.1.1. Kebutuhan fungsionlitas 11.1
3.2.1.2. ...
3.2.1.3. ...
3.2.1.4. kebutuhan fungsionlitas 1.n
3.2.2. User class 2
3.2.2.1. Kebutuhan fungsionlitas 11.1
3.2.2.2. ...
3.2.2.3. ...
3.2.2.4. kebutuhan fungsionlitas 1.n
3.2.3. User class....
3.2.4. User class n
3.3. Kebutuhan performansi
3.4. Batasan perancangan
3.5. Atribut sistem perangkat lunak
3.6. Kebutuhan lain

A.4 Template SKPL bagian 3 diorganisasikan sebagai objek.

3. Kebutuhan Khusus
3.1. Kebutuhan antarmuka eksternal
3.1.1. Antarmuka pemakai
3.1.2. Antarmuka perangkat keras
3.1.3. Antarmuka perangkat lunak
3.1.4. Antarmuka komunikasi
3.2. Kelas/objek
3.2.1. kelas/objek 1
3.2.1.1. atribut (langsung/tidak langsung)
3.2.1.1.1. atribut 1
3.2.1.1.2. atribut 2
3.2.1.1.3. ....
 3.2.1.1.4. ...
3.2.1.1.5. atribut n
3.2.1.2. fungsi-fungsi (service, metode, langsung /tidak
langsung)
3.2.1.2.1. kebutuhan fungsional 1.1
3.2.1.2.2. kebutuhan fungsional 1.2
3.2.1.2.3. ...
3.2.1.2.4. kebutuhan fungsional 1.m
3.2.1.3. Pesan (komunikasi yang diterima/dikirim)
3.2.2. class objek 2
3.2.3. .....
3.2.4. class objek p
3.3. Kebutuhan performansi
3.4. Batasan perancangan
3.5. Atribut sistem perangkat lunak
3.6. Kebutuhan lain

A.5 Template SKPL bagian 3 diorganisasikan sebagai feature

3. Kebutuhan Khusus
3.1. Kebutuhan antarmuka eksternal
3.1.1. Antarmuka pemakai
3.1.2. Antarmuka perangkat keras
3.1.3. Antarmuka perangkat lunak
3.1.4. Antarmuka komunikasi
3.2. Feature System
3.2.1. Sistem feature 1
3.2.1.1. Pendahuluan / guna dari purpose
3.2.1.2. urutan stimulus/response
3.2.1.3. kebutuhan fungsional yang berhubungan
3.2.1.3.1. Kebutuhan fungsional 1
3.2.1.3.2. .....
3.2.1.3.3. ...
3.2.1.3.4. Kebutuhan fungsional n
3.2.1.4. Pesan (komunikasi yang diterima/dikirim)
3.2.2. Sistem feature 2
3.2.3.
3.2.4. Sistem feature m
3.3. Kebutuhan performansi
3.4. Batasan perancangan
3.5. Atribut sistem perangkat lunak
3.6. Kebutuhan lain
A.6 Template SKPL bagian 3 diorganisasikan sebagai stimulus
3. Kebutuhan Khusus
3.1. Kebutuhan antarmuka eksternal
3.1.1. Antarmuka pemakai
3.1.2. Antarmuka perangkat keras
3.1.3. Antarmuka perangkat lunak
3.1.4. Antarmuka komunikasi
3.2. Kebutuhan fungsionalitas
3.2.1. stimulus 1
3.2.1.1. Kebutuhan fungsional 1.1
3.2.1.2. ....
3.2.1.3. ....
3.2.1.4. Kebutuhan fungsional 1.1
3.2.2. stimulus 2
3.2.3. ....
3.2.4. ...
3.2.5. stimulus m
3.3. Kebutuhan performansi
3.4. Batasan perancangan
3.5. Atribut sistem perangkat lunak
3.6. Kebutuhan lain

A.7 Template SKPL bagian 3 diorganisasikan sebagai hirarki fungsional

3. Kebutuhan Khusus
3.1. Kebutuhan antarmuka eksternal
3.1.1. Antarmuka pemakai
3.1.2. Antarmuka perangkat keras
3.1.3. Antarmuka perangkat lunak
3.1.4. Antarmuka komunikasi
3.2. Kebutuhan fungsionalitas
3.2.1. aliran informasi
3.2.1.1. DFD 1
3.2.1.1.1. Entitas data
3.2.1.1.2. proses
3.2.1.1.3. topologi
3.2.1.2. DFD 2
3.2.1.2.1. Entitas data
3.2.1.2.2. proses
3.2.1.2.3. topologi
3.2.1.3. ....
3.2.1.4. DFD n

3.2.2. Deskripsi proses

3.2.2.1. Proses 1
3.2.2.1.1. Entitas data masukan
3.2.2.1.2. Algoritma atau Formula dari proses
 3.2.2.1.3. entitas data terlibat
3.2.2.2. Proses 2
3.2.2.2.1. ...
3.2.2.2.2. ...
3.2.2.3. ....
3.2.2.4. Proses n
3.2.3. Spesifikasi konstruksi data
3.2.3.1. Konstruksi 1
3.2.3.1.1. Tipe record
3.2.3.1.2. field-field
3.2.3.2. ...
3.2.3.3. Konstruksi n
3.2.4. Kamus data
3.2.4.1. Elemen data 1
3.2.4.1.1. Nama
3.2.4.1.2. Representasi
3.2.4.1.3. Unit/format
3.2.4.1.4. presisi /keakuratan
3.2.4.1.5. Range
3.2.4.2. elemen data 2
3.2.4.3. .....
3.2.4.4. elemen data n
3.3. Kebutuhan performansi
3.4. Batasan perancangan
3.5. Atribut sistem perangkat lunak
3.6. Kebutuhan lain

A.8 Template SKPL bagian 3 diorganisasikan untuk organisasi ganda

3. Kebutuhan Khusus
3.1. Kebutuhan antarmuka eksternal
3.1.1. Antarmuka pemakai
3.1.2. Antarmuka perangkat keras
3.1.3. Antarmuka perangkat lunak
3.1.4. Antarmuka komunikasi
3.2. Kebutuhan fungsionalitas
3.2.1. User class 1
3.2.1.1. Feature 1.1
3.2.1.1.1. Introduksi dan pengenalan feature
3.2.1.1.2. Urutan stimulus/response
3.2.1.1.3. kebutuhan fungsionalias yang terhubung
3.2.1.2. feature 1.2
3.2.1.3. ....
3.2.1.4. ....
3.2.2. User class 2
3.2.3. ...
 3.2.4. ....
3.2.5. User c.lass n
3.3. Kebutuhan performansi
3.4. Batasan perancangan
3.5. Atribut sistem perangkat lunak
3.6. Kebutuhan lain