ANALISIS KEBUTUHAN DAN SPESIFIKASI
4.2 SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK (SRS)
berpengalaman dapat mendeteksi sebagian besar fitur yang hilang ini dan menyarankannya kepada pelanggan untuk pertimbangan dan persetujuannya untuk dimasukkan ke dalam persyaratan. Berikut ini adalah dua contoh persyaratan yang tidak lengkap:
Contoh 4.5 Misalkan untuk studi kasus 4.1, salah satu panitera menyatakan sebagai berikut—Jika seorang mahasiswa memperoleh nilai rata-rata (IPK) kurang dari 6, maka orang tua mahasiswa harus diberitahu tentang kinerja yang disesalkan melalui (pos ) surat maupun melalui email. Namun, pada pemeriksaan semua persyaratan, ditemukan bahwa tidak ada ketentuan yang dapat digunakan untuk memasukkan alamat pos atau email orang tua mahasiswa ke dalam sistem. Fitur yang memungkinkan memasukkan id email dan alamat pos orang tua mahasiswa hilang, sehingga membuat persyaratan tidak lengkap.
Contoh 4.6 Dalam perangkat lunak otomatisasi pabrik kimia, misalkan salah satu persyaratannya adalah jika suhu internal reaktor melebihi 200C maka bel alarm harus dibunyikan. Namun, pada pemeriksaan semua persyaratan, ditemukan bahwa tidak ada ketentuan untuk mengatur ulang bel alarm setelah suhu diturunkan di salah satu persyaratan.
Ini jelas merupakan persyaratan yang tidak lengkap.
Dapatkah seorang analis mendeteksi semua masalah yang ada dalam persyaratan yang dikumpulkan?
Banyak inkonsistensi, anomali, dan ketidaklengkapan dapat dideteksi dengan mudah, sementara beberapa lainnya memerlukan studi yang terfokus pada persyaratan khusus.
Namun, beberapa masalah dalam persyaratan bisa sangat halus dan luput dari pandangan mata yang paling berpengalaman sekalipun. Banyak dari anomali dan inkonsistensi halus ini dapat dideteksi, jika persyaratan ditentukan dan dianalisis menggunakan metode formal.
Setelah sistem telah ditentukan secara formal, dapat secara sistematis (dan bahkan secara otomatis) dianalisis untuk menghilangkan semua masalah dari spesifikasi. Kita akan membahas konsep dasar spesifikasi sistem formal. Meskipun penggunaan teknik formal tidak tersebar luas, praktik saat ini adalah secara formal hanya menentukan bagian kritis keselamatan dari suatu sistem.
• Pengembang perangkat lunak: developer perangkat lunak mengacu pada dokumen SRS untuk memastikan bahwa mereka mengembangkan persis apa yang dibutuhkan oleh pelanggan.
• Insinyur uji: Teknisi uji menggunakan dokumen SRS untuk memahami fungsionalitas, dan berdasarkan ini, tulis kasus uji untuk memvalidasi kerjanya.
Mereka membutuhkan fungsionalitas yang diperlukan harus dijelaskan dengan jelas, dan data input dan output harus diidentifikasi dengan tepat.
• Penulis dokumentasi pengguna: Penulis dokumentasi pengguna perlu membaca dokumen SRS untuk memastikan bahwa mereka memahami fitur produk dengan cukup baik untuk dapat menulis manual pengguna.
• Manajer proyek: Manajer proyek mengacu pada dokumen SRS untuk memastikan bahwa mereka dapat memperkirakan biaya proyek dengan mudah dengan mengacu pada dokumen SRS dan berisi semua informasi yang diperlukan untuk merencanakan proyek.
• Insinyur pemeliharaan: Dokumen SRS membantu teknisi pemeliharaan memahami fungsionalitas yang didukung oleh sistem. Pengetahuan yang jelas tentang fungsionalitas dapat membantu mereka memahami desain dan kode.
Juga, pemahaman yang tepat tentang fungsionalitas yang didukung memungkinkan mereka untuk menentukan modifikasi spesifik pada fungsionalitas sistem yang diperlukan untuk tujuan tertentu.
Banyak insinyur perangkat lunak dalam sebuah proyek menganggap dokumen SRS sebagai dokumen referensi. Namun, seringkali lebih tepat untuk menganggap dokumen SRS sebagai dokumentasi kontrak antara tim pengembangan dan pelanggan. Bahkan, dokumen SRS dapat digunakan untuk menyelesaikan perselisihan antara developer dan pelanggan yang mungkin timbul di masa mendatang. Dokumen SRS bahkan dapat digunakan sebagai dokumen hukum untuk menyelesaikan perselisihan antara pelanggan dan developer di pengadilan.
Setelah pelanggan menyetujui dokumen SRS, tim pengembangan melanjutkan untuk mengembangkan perangkat lunak dan memastikan bahwa itu sesuai dengan semua persyaratan yang disebutkan dalam dokumen SRS.
Mengapa Menghabiskan Waktu dan Sumber Daya untuk Mengembangkan Dokumen SRS?
Dokumen SRS yang diformulasikan dengan baik menemukan berbagai penggunaan selain penggunaan utama yang dimaksudkan sebagai dasar untuk memulai pekerjaan pengembangan perangkat lunak. Fungsi penting dari dokumen SRS yang diformulasikan dengan baik adalah sebagai berikut:
• Membentuk kesepakatan antara pelanggan dan pengembang: Sebuah dokumen SRS yang baik menetapkan panggung bagi pelanggan untuk membentuk harapan mereka tentang perangkat lunak dan developer tentang apa yang diharapkan dari perangkat lunak.
• Mengurangi pengerjaan ulang di masa depan: Proses persiapan dokumen SRS memaksa para pemangku kepentingan untuk memikirkan semua persyaratan sebelum desain dan pengembangan berlangsung. Ini mengurangi desain ulang, pengodean ulang, dan pengujian ulang nanti. Tinjauan yang cermat terhadap dokumen SRS dapat mengungkapkan kelalaian, kesalahpahaman, dan inkonsistensi di awal siklus pengembangan.
• Memberikan dasar untuk memperkirakan biaya dan jadwal: Manajer proyek biasanya memperkirakan ukuran perangkat lunak dari analisis dokumen SRS.
Berdasarkan perkiraan ini mereka membuat perkiraan lain seperti upaya yang diperlukan untuk mengembangkan perangkat lunak dan total biaya
pengembangan. Dokumen SRS juga berfungsi sebagai dasar negosiasi harga dengan pelanggan. Manajer proyek juga menggunakan dokumen SRS untuk penjadwalan kerja.
• Menyediakan dasar untuk validasi dan verifikasi: Dokumen SRS menyediakan dasar yang dapat digunakan untuk memeriksa kepatuhan perangkat lunak yang dikembangkan. Ini juga digunakan oleh para insinyur pengujian untuk membuat rencana pengujian.
• Memfasilitasi perpanjangan masa depan: Dokumen SRS biasanya berfungsi sebagai dasar untuk merencanakan peningkatan di masa depan.
Sebelum kita membahas tentang cara menulis dokumen SRS, pertama-tama kita membahas karakteristik dokumen SRS yang baik dan perangkap yang harus dihindari secara sadar saat menulis dokumen SRS.
Ciri-ciri Dokumen SRS yang Baik
Keterampilan menulis dokumen SRS yang baik biasanya berasal dari pengalaman yang diperoleh dari menulis dokumen SRS untuk banyak proyek. Namun, analis harus menyadari kualitas yang diinginkan yang harus dimiliki setiap dokumen SRS yang baik. Praktik yang Direkomendasikan IEEE untuk Spesifikasi Persyaratan Perangkat Lunak[IEEE830] menjelaskan konten dan kualitas spesifikasi persyaratan perangkat lunak (SRS) yang baik. Beberapa kualitas yang diinginkan dari dokumen SRS adalah sebagai berikut:
• Ringkas: Dokumen SRS harus ringkas dan pada saat yang sama tidak ambigu, konsisten, dan lengkap. Deskripsi yang bertele-tele dan tidak relevan mengurangi keterbacaan dan juga meningkatkan kemungkinan kesalahan dalam dokumen.
• Implementasi-independen: SRS harus bebas dari desain dan keputusan implementasi kecuali keputusan tersebut mencerminkan persyaratan yang sebenarnya. Seharusnya hanya menentukan apa yang harus dilakukan sistem dan menahan diri untuk tidak menyatakan bagaimana melakukan ini. Ini berarti bahwa dokumen SRS harus menentukan perilaku sistem yang terlihat secara eksternal dan tidak membahas masalah implementasi. Tampilan ini dengan spesifikasi persyaratan yang ditulis, telah ditunjukkan pada Gambar 4.1. Perhatikan bahwa pada Gambar 4.1, dokumen SRS menjelaskan output yang dihasilkan untuk berbagai jenis input dan deskripsi pemrosesan yang diperlukan untuk menghasilkan output dari input (ditunjukkan dalam elips) dan kerja internal perangkat lunak tidak dibahas sama sekali .
• Traceable: Harus dimungkinkan untuk melacak kebutuhan spesifik ke elemen desain yang mengimplementasikannya dan sebaliknya. Demikian pula, harus dimungkinkan untuk melacak persyaratan ke segmen kode yang mengimplementasikannya dan kasus uji yang menguji persyaratan ini dan sebaliknya. Ketertelusuran juga penting untuk memverifikasi hasil fase sehubungan dengan fase sebelumnya dan untuk menganalisis dampak perubahan persyaratan pada elemen desain dan kode.
• Dapat dimodifikasi: Pelanggan sering mengubah persyaratan selama pengembangan pengembangan perangkat lunak karena berbagai alasan. Oleh karena itu, dalam praktiknya dokumen SRS mengalami beberapa kali revisi selama pengembangan perangkat lunak. Juga, dokumen SRS sering dimodifikasi setelah proyek selesai untuk mengakomodasi peningkatan dan evolusi di masa depan.
Untuk mengatasi perubahan persyaratan, dokumen SRS harus mudah dimodifikasi. Untuk ini, dokumen SRS harus terstruktur dengan baik. Dokumen yang terstruktur dengan baik mudah dipahami dan dimodifikasi. Penjabaran
kebutuhan yang tersebar di banyak tempat dalam dokumen SRS mungkin tidak salah—tetapi cenderung membuat kebutuhan sulit untuk dipahami dan juga setiap modifikasi pada kebutuhan akan menjadi sulit karena akan membutuhkan perubahan yang harus dilakukan dalam jumlah besar. tempat dalam dokumen.
• Identifikasi respons terhadap kejadian yang tidak diinginkan: Dokumen SRS harus membahas respons sistem terhadap berbagai kejadian yang tidak diinginkan dan kondisi luar biasa yang mungkin timbul.
• Dapat diverifikasi: Semua persyaratan sistem seperti yang didokumentasikan dalam dokumen SRS harus dapat diverifikasi. Ini berarti bahwa seharusnya memungkinkan untuk merancang kasus uji berdasarkan deskripsi fungsionalitas, apakah persyaratan telah dipenuhi atau tidak dalam suatu implementasi.
Persyaratan seperti "sistem harus ramah pengguna" tidak dapat diverifikasi. Di sisi lain, persyaratan—“Ketika nama buku dimasukkan, perangkat lunak harus menampilkan apakah buku tersebut tersedia untuk diterbitkan atau telah dipinjamkan” dapat diverifikasi. Setiap fitur dari sistem yang diperlukan yang tidak dapat diverifikasi harus dicantumkan secara terpisah di tujuan bagian implementasi dokumen SRS.
Dokumen SRS harus menjelaskan sistem yang akan dikembangkan sebagai kotak hitam, dan harus menentukan hanya perilaku sistem yang terlihat secara ekster nal. Untuk alasan ini, dokumen SRS juga disebut spesifikasi kotak hitam dari perangkat lunak yang sedang dikembangkan.
Gambar 4.1 Tampilan kotak hitam dari suatu sistem saat melakukan serangkaian fungsi.
Atribut Dokumen SRS Buruk
Dokumen SRS yang ditulis oleh pemula sering mengalami berbagai masalah. Seperti dibahas sebelumnya, masalah yang paling merusak adalah ketidaklengkapan, ambiguitas, dan kontradiksi. Ada banyak jenis masalah lain yang mungkin dialami oleh dokumen spesifikasi.
Dengan mengetahui masalah ini, seseorang dapat mencoba menghindarinya saat menulis dokumen SRS. Beberapa kategori masalah penting yang banyak dialami oleh dokumen SRS adalah sebagai berikut:
Over-spesifikasi: Ini terjadi ketika analis mencoba untuk mengatasi aspek "bagaimana"
dalam dokumen SRS. Misalnya, dalam masalah otomatisasi perpustakaan, seseorang tidak boleh menentukan apakah catatan keanggotaan perpustakaan perlu disimpan diindeks pada
nama depan anggota atau pada nomor identifikasi (ID) anggota perpustakaan. Spesifikasi yang berlebihan membatasi kebebasan desainer dalam mencapai solusi desain yang baik.
Referensi ke depan: Seseorang tidak boleh mengacu pada aspek-aspek yang akan dibahas lebih lanjut dalam dokumen SRS. Referensi ke depan sangat mengurangi keterbacaan spesifikasi.
Pemikiran angan-angan: Jenis masalah ini menyangkut deskripsi aspek-aspek yang akan sulit untuk diterapkan.
Kebisingan: Istilah kebisingan mengacu pada keberadaan materi yang tidak secara langsung relevan dengan proses pengembangan perangkat lunak. Sebagai contoh, dalam fungsi register pelanggan, misalkan analis menulis bahwa departemen pendaftaran pelanggan diawaki oleh pegawai yang melapor untuk bekerja antara jam 8 pagi dan 5 sore, 7 hari seminggu. Informasi ini dapat disebut noise karena hampir tidak ada gunanya bagi developer perangkat lunak dan akan mengacaukan dokumen SRS yang tidak perlu, mengalihkan perhatian dari poin-poin penting.
Beberapa “sins” lain dari dokumen SRS dapat didaftar dan digunakan untuk mencegah penulisan dokumen SRS yang buruk dan juga digunakan sebagai checklist untuk meninjau dokumen SRS.
Kategori Penting Persyaratan Pelanggan
Dokumen SRS yang baik, harus dengan benar mengkategorikan dan mengatur persyaratan ke dalam bagian yang berbeda [IEEE830]. Sesuai dengan pedoman IEEE 830, kategori penting dari kebutuhan pengguna adalah sebagai berikut. Dokumen SRS harus dengan jelas mendokumentasikan aspek-aspek perangkat lunak berikut ini:
• Persyaratan fungsional
• Persyaratan non-fungsional
o Kendala desain dan implementasi o Diperlukan antarmuka eksternal o Persyaratan non-fungsional lainnya
• Tujuan implementasi.
Persyaratan fungsional
Persyaratan fungsional menangkap fungsionalitas yang dibutuhkan oleh pengguna dari sistem. Mempertimbangkan perangkat lunak sama halnya dengan menawarkan satu set fungsi {fi} kepada pengguna. Fungsi-fungsi ini dapat dianggap mirip dengan fungsi matematika f : I → O, artinya suatu fungsi mengubah elemen (ii) dalam domain input (I) menjadi nilai (oi) pada output (O). Tampilan fungsional dari suatu sistem ditunjukkan secara skematis pada Gambar 4.1. Setiap fungsi fi dari sistem dapat dianggap membaca data tertentu ii, dan kemudian mentransformasikan satu set data input (ii) ke set data output yang sesuai (oi).
Persyaratan fungsional sistem, harus dengan jelas menggambarkan setiap fungsi yang akan didukung sistem bersama dengan kumpulan data input dan output yang sesuai.
Persyaratan non-fungsional
Persyaratan non-fungsional adalah kewajiban yang tidak dapat dinegosiasikan yang harus didukung oleh perangkat lunak. Persyaratan non-fungsional menangkap persyaratan pelanggan yang tidak dapat dinyatakan sebagai fungsi (yaitu, menerima data input dan menghasilkan data output). Persyaratan non-fungsional biasanya membahas aspek mengenai antarmuka eksternal, antarmuka pengguna, pemeliharaan, portabilitas, kegunaan, jumlah maksimum pengguna bersamaan, waktu, dan throughput (transaksi per detik, dll.).
Persyaratan non-fungsional dapat menjadi kritis dalam arti bahwa setiap kegagalan oleh perangkat lunak yang dikembangkan untuk mencapai beberapa tingkat minimum yang ditentukan dalam persyaratan ini dapat dianggap sebagai kegagalan dan membuat perangkat
lunak tidak dapat diterima oleh pelanggan. Standar IEEE 830 merekomendasikan bahwa dari berbagai persyaratan non-fungsional, antarmuka eksternal, dan batasan desain dan implementasi harus didokumentasikan dalam dua bagian yang berbeda. Persyaratan non- fungsional yang tersisa harus didokumentasikan kemudian di bagian dan ini harus mencakup persyaratan kinerja dan keamanan. Berikut merupakan berbagai kategori persyaratan nonfungsional yang dijelaskan dalam tiga bagian berbeda:
Kendala desain dan implementasi: Kendala desain dan implementasi adalah kategori penting dari persyaratan non-fungsional yang menjelaskan item atau masalah apa pun yang akan membatasi opsi yang tersedia bagi pengembang. Beberapa contoh kendala dapat berupa—kebijakan perusahaan atau peraturan yang perlu dihormati; keterbatasan perangkat keras; antarmuka dengan aplikasi lain; teknologi, alat, dan basis data khusus yang akan digunakan; protokol komunikasi khusus yang akan digunakan; pertimbangan keamanan;
konvensi desain atau standar pemrograman yang harus diikuti, dll. Pertimbangkan contoh kendala yang dapat dimasukkan dalam bagian ini—Oracle DBMS perlu digunakan karena ini akan memfasilitasi antarmuka yang mudah dengan aplikasi lain yang sudah beroperasi dalam organisasi.
Diperlukan antarmuka eksternal: Contoh antarmuka eksternal adalah— perangkat keras, perangkat lunak dan antarmuka komunikasi, antarmuka pengguna, format laporan, dll.
Untuk menentukan antarmuka pengguna, setiap antarmuka antara perangkat lunak dan pengguna harus dijelaskan. Deskripsi dapat mencakup contoh gambar layar, standar GUI atau panduan gaya apa pun yang harus diikuti, batasan tata letak layar, tombol dan fungsi standar (misalnya, bantuan) yang akan muncul di setiap layar, pintasan keyboard, standar tampilan pesan kesalahan, dan sebagainya. pada. Salah satu contoh persyaratan antarmuka peng guna dari suatu perangkat lunak dapat berupa perangkat lunak itu harus dapat digunakan oleh pekerja lantai pabrik yang bahkan mungkin tidak memiliki gelar sekolah menengah. Detail desain antarmuka pengguna seperti desain layar, struktur menu, diagram navig asi, dll. harus didokumentasikan dalam dokumen spesifikasi antarmuka pengguna yang terpisah.
Persyaratan non-fungsional lainnya: Bagian ini berisi deskripsi persyaratan non- fungsional yang bukan merupakan batasan desain dan juga bukan persyaratan antarmuka eksternal. Contoh penting adalah persyaratan kinerja seperti jumlah transaksi yang diselesaikan per unit waktu. Selain persyaratan kinerja, persyaratan non-fungsional lainnya yang akan dijelaskan di bagian ini mungkin termasuk masalah keandalan, keakurata n hasil, dan masalah keamanan.
Tujuan implementasi
Bagian 'tujuan implementasi' dari dokumen SRS menawarkan beberapa saran umum mengenai perangkat lunak yang akan dikembangkan. Ini tidak mengikat pengembang, dan mereka mungkin mempertimbangkan saran ini jika memungkinkan. Misalnya, developer dapat menggunakan saran ini saat memilih di antara solusi desain yang berbeda. Sebuah tujuan, berbeda dengan persyaratan fungsional dan non-fungsional, tidak diperiksa oleh pelanggan untuk kesesuaian pada saat pengujian penerimaan.
Tujuan dari bagian implementasi mungkin mendokumentasikan masalah seperti revisi yang lebih mudah pada fungsionalitas sistem yang mungkin diperlukan di masa mendatang, dukungan yang lebih mudah untuk perangkat baru yang akan didukung di masa mendatang, masalah penggunaan kembali, dll. Ini adalah item yang mungkin disimpan oleh developer dalam pikiran mereka selama pengembangan sehingga sistem yang dikembangkan dapat memenuhi beberapa aspek yang tidak diperlukan segera. Penting untuk diingat bahwa apa pun yang akan diuji oleh pengguna dan penerimaan sistem akan tergantung pada hasil tugas
ini, biasanya dianggap sebagai persyaratan yang harus dipenuhi oleh sistem dan bukan tujuan dan sebaliknya.
Bagaimana mengklasifikasikan berbagai jenis kebutuhan?
Kita harus jelas mengenai aspek persyaratan sistem yang harus didokumentasikan sebagai persyaratan fungsional, yang didokumentasikan sebagai persyaratan non-fungsional, dan yang didokumentasikan sebagai tujuan implementasi. Aspek yang dapat dinyatakan sebagai transformasi dari beberapa data input ke beberapa data output (yaitu, fungsi sistem) harus didokumentasikan sebagai persyaratan fungsional. Persyaratan lain yang kepatuhannya oleh sistem yang dikembangkan dapat diverifikasi dengan memeriksa sistem didokumentasikan sebagai persyaratan non-fungsional. Aspek yang kepatuhannya oleh sistem yang dikembangkan tidak perlu diverifikasi tetapi hanya dimasukkan sebagai saran kepada developer didokumentasikan sebagai tujuan implementasi.
Perbedaan antara persyaratan non-fungsional dan pedoman adalah sebagai berikut.
Persyaratan non-fungsional akan diuji kepatuhannya, sebelum produk yang dikembangkan diterima oleh pelanggan sedangkan pedoman, di sisi lain, adalah permintaan pelanggan yang diinginkan untuk dilakukan, tetapi tidak akan diuji selama penerimaan produk. Persyaratan fungsional membentuk dasar untuk sebagian besar desain dan metodologi pengujian. Oleh karena itu, kecuali jika persyaratan fungsional diidentifikasi dan didokumentasikan dengan benar, aktivitas desain dan pengujian tidak dapat dilakukan dengan memuaskan.
Persyaratan Fungsional
Untuk mendokumentasikan persyaratan fungsional suatu sistem, pertama-tama perlu dipelajari untuk mengidentifikasi fungsi tingkat tinggi dari sistem dengan membaca dokumentasi informal dari persyaratan yang dikumpulkan. Fungsi tingkat tinggi akan dipecah menjadi subpersyaratan yang lebih kecil. Setiap fungsi tingkat tinggi adalah contoh penggunaan sistem (use case) oleh pengguna dalam beberapa cara. Fungsi tingkat tinggi adalah fungsi yang digunakan pengguna untuk menyelesaikan pekerjaan yang bermanfaat.
Namun, definisi di atas bukanlah definisi fungsi tingkat tinggi yang sangat akurat.
Misalnya, seberapa bergunakah suatu pekerjaan yang harus dilakukan oleh sistem agar dapat disebut 'pekerjaan yang berguna'? Bisakah pencetakan laporan transaksi ATM saat penarikan uang dari ATM disebut pekerjaan yang bermanfaat? Pencetakan transaksi ATM tidak boleh dianggap sebagai persyaratan tingkat tinggi, karena pengguna tidak secara khusus meminta aktivitas ini. Tanda terima akan dicetak secara otomatis sebagai bagian dari fungsi penarikan uang. Biasanya, pengguna memanggil (meminta) layanan dari setiap persyaratan tingkat tinggi. Oleh karena itu dimungkinkan untuk memperlakukan tanda terima cetak sebagai bagian dari fungsi penarikan uang daripada memperlakukannya sebagai fungsi tingkat tinggi.
Oleh karena itu diperlukan bahwa untuk beberapa fungsi tingkat tinggi, kita mungkin harus memperdebatkan apakah kita ingin mempertimbangkannya sebagai fungsi tingkat tinggi atau tidak. Namun, akan menjadi mungkin untuk mengidentifikasi sebagian besar fungsi tingkat tinggi tanpa banyak kesulitan setelah mempraktikkan solusi untuk beberapa masalah latihan.
Setiap persyaratan tingkat tinggi biasanya melibatkan penerimaan beberapa data dari pengguna melalui antarmuka pengguna, mengubahnya menjadi respons yang diperlukan, dan kemudian menampilkan respons sistem dalam format yang tepat. Misalnya, dalam perangkat lunak otomatisasi perpustakaan, persyaratan fungsional tingkat tinggi mungkin berupa buku pencarian. Fungsi ini melibatkan penerimaan nama buku atau kumpulan kata kunci dari pengguna, menjalankan algoritme pencocokan pada daftar buku, dan akhirnya mengeluarkan buku yang cocok. Respons sistem yang dihasilkan dapat dalam beberapa bentuk, misalnya, tampilan pada terminal, hasil cetak, beberapa data yang ditransfer ke sistem lain, dll. Namun, dalam kasus yang menurun, persyaratan tingkat tinggi mungkin tidak melibatkan input data
apa pun ke sistem atau produksi hasil yang dapat ditampilkan. Misalnya, mungkin melibatkan menyalakan lampu, atau memulai motor dalam aplikasi tertanam.
Namun, definisi di atas bukanlah definisi fungsi tingkat tinggi yang sangat akurat.
Misalnya, seberapa bergunakah suatu pekerjaan yang harus dilakukan oleh sistem agar dapat disebut 'pekerjaan yang berguna'? Bisakah pencetakan laporan transaksi ATM saat penarikan uang dari ATM disebut pekerjaan yang bermanfaat? Pencetakan transaksi ATM tidak boleh dianggap sebagai persyaratan tingkat tinggi, karena pengguna tidak secara khusus meminta aktivitas ini. Tanda terima akan dicetak secara otomatis sebagai bagian dari fungsi penarikan uang. Biasanya, pengguna memanggil (meminta) layanan dari setiap persyaratan tingkat tinggi. Oleh karena itu dimungkinkan untuk memperlakukan tanda terima cetak sebagai bagian dari fungsi penarikan uang daripada memperlakukannya sebagai fungsi tingkat tinggi.
Oleh karena itu diperlukan bahwa untuk beberapa fungsi tingkat tinggi, kita mungkin harus memperdebatkan apakah kita ingin mempertimbangkannya sebagai fungsi tingkat tinggi atau tidak. Namun, akan menjadi mungkin untuk mengidentifikasi sebagian besar fungsi tingkat tinggi tanpa banyak kesulitan setelah mempraktikkan solusi untuk beberapa masalah latihan.
Setiap persyaratan tingkat tinggi biasanya melibatkan penerimaan beberapa data dari pengguna melalui antarmuka pengguna, mengubahnya menjadi respons yang diperlukan, dan kemudian menampilkan respons sistem dalam format yang tepat. Misalnya, dalam perangkat lunak otomatisasi perpustakaan, persyaratan fungsional tingkat tinggi mungkin berupa buku pencarian. Fungsi ini melibatkan penerimaan nama buku atau kumpulan kata kunci dari pengguna, menjalankan algoritme pencocokan pada daftar buku, dan akhirnya mengeluarkan buku yang cocok. Respons sistem yang dihasilkan dapat dalam beberapa bentuk, misalnya, tampilan pada terminal, hasil cetak, beberapa data yang ditransfer ke sistem lain, dll. Namun, dalam kasus yang menurun, persyaratan tingkat tinggi mungkin tidak melibatkan input data apa pun ke sistem atau produksi hasil yang dapat ditampilkan. Misalnya, mungkin melibatkan menyalakan lampu, atau memulai motor dalam aplikasi tertanam.
Apakah fungsi tingkat tinggi dari suatu sistem mirip dengan fungsi matematika?
Kita semua tahu bahwa fungsi matematika mengubah data input menjadi data output.
Fungsi tingkat tinggi mengubah data masukan tertentu menjadi data keluaran. Namun, kecuali untuk fungsi tingkat tinggi yang sangat sederhana, suatu fungsi jarang membaca semua data yang diperlukan sekaligus dan jarang mengeluarkan semua hasil dalam satu bidikan. Faktanya, fungsi tingkat tinggi biasanya melibatkan serangkaian interaksi antara sistem dan satu atau lebih pengguna. Contoh interaksi yang mungkin terjadi dalam persyaratan tingkat tinggi tunggal telah ditunjukkan pada Gambar 4.2. Pada Gambar 4.2, input pengguna telah diwakili oleh persegi panjang dan respon yang dihasilkan oleh sistem oleh lingkaran. Amati bahwa persegi panjang dan lingkaran bergantian dalam pelaksanaan fungsi tingkat tinggi tunggal sistem, menunjukkan serangkaian permintaan dari pengguna dan tanggapan yang sesuai dari sistem. Biasanya, ada beberapa input data awal oleh pengguna. Setelah menerima ini, sistem dapat menampilkan beberapa respons (disebut tindakan sistem). Berdasarkan ini, pengguna dapat memasukkan data lebih lanjut, dan seterusnya. Untuk fungsi tingkat tinggi apa pun, mungkin ada urutan atau skenario interaksi yang berbeda karena pengguna memilih opsi yang berbeda atau memasukkan item data yang berbeda.
Pada Gambar 4.2, skenario yang berbeda terjadi tergantung pada jumlah yang dimasukkan untuk penarikan. Skenario yang berbeda pada dasarnya adalah perilaku yang berbeda yang ditunjukkan oleh sistem untuk fungsi tingkat tinggi yang sama. Biasanya, setiap input pengguna dan tindakan sistem yang sesuai dapat dianggap sebagai sub-persyaratan dari persyaratan tingkat tinggi. Dengan demikian, setiap kebutuhan tingkat tinggi dapat terdiri dari beberapa sub-persyaratan.