Pemahaman lengkap mengenai persyaratan perangkat lunak sangat penting bagi keberhasilan usaha pengembangan perangkat lunak. Tidak peduli bagaimana perangkat lunak di rancang atau dikodekan, program yang dianalisis dan ditentukan secara tidak baik akan mengecewakan pemakainya dan akan membawa kegagalan bagi pengembangannya. Tugas analisis merupakan sebuah proses penemuan, perbaikan, pemodelan, dan spesifikasi. Ruang lingkup perangkat lunak, yang secara mendasar dikembangkan oleh perekayasa sustem dan diperbaiki selama perencanaan proyek perangkat lunak, diperbaiki secara detail. Model – model data yang dibutuhkan, aliran control dan informasi, dan tingkah laku operasional diciptakan. Pemecahan alternatife dianalisis dan dialokasikan ke berbagai elemen perangkat lunak.

Baik pengembang maupun pelanggan melakukan peran aktif dalam analisis persyaratan dan spesifikasi, tetapi hal itu sebenarnya tidak benar. Muatan atau isi komunikasi yang berlangsung sangat tinggi. Kemungkinan untuk terjadinya kesalahan interpretasi dan kesalahan informasi sangat besar. Ambiguitasnya pun sangat mungkin.

11.1 ANALISIS PERSYARATAN
Analisis persyaratan adalah sebuah tugas rekayasa perangkat lunak yang menjembatani jurang antara alokasi. Perangkat lunak tingkat sistem dan perancangan perangkat lunak (Gambar 11.1). Analisis persyaratan memungkinkan perekayasa system menentukan fungsi dan kinerja perangkat lunak, menunjukkan interface perangkat lunak dengan elemen – elemen system yang lain, dan membangun batasan yang harus dipenuhi oleh perangkat lunak. Analaisi persyaratan perangkat lunak mengijinkan perekayasa perangkat lunak (dlm peran ini sering disebut analisis) utk memperhalus alokasi perangkat lunak dan membangun model – model data fungsional, dan domain tingkah laku yang akan di proses oleh perangkat lunak. Analisis persyaratan memberikan model – model yang akan diterjemahkan ke dalam data, arsitektur, interface, dan desain procedural kepada perancang perangkat lunak. Akhirnya, spesifikasi persyaratan memberikan cara kepada pengembang dan pelanggan untuk menilai kualitas perangkat lunak yang telah di bangun.

ANALISIS DAN KESENJANGAN ANTARA REKAYASA SISTEM DAN DESAIN PERANGKAT LUNAKA
Analisis persyaratan perangkat lunak dapat dibagi menjadi 5 area kerja :
• Pengenalan masalah
• Evaluasi dan Sintesis
• Pemodelan
• Spesifikasi
• Kajian

Pada awalnya, analisis mempelajari spesifikasi system (bila ada) dan rencana proyek peangkat lunak. Penting untuk memahami perangkat lunak dalam suatu konteks system dan mengkaji ruang lingkup perangkat lunak yang telah digunakan untuk memunculkan estimasi perencanaan. Selanjutnya, adalah membangun komunikasi untuk analisis untuk menjamin pengenalan masalah. Tujuan analisis adalah mengenali elemen masalah dasar seperti dirasakan oleh pemakai / pelanggan.

Sintesis evaluasi dan pemecahan masalah adalah area mayor selanjutnya dari kerja analisis. Analisis harus membatasi semua objek data yang dapat di observasi secara eksternal, mengevaluasi aliran dan muatan informasi; mendefinisikan dan menguraikan semua fungsi perangkat lunak; memahami tingkah laku perangkat lunak dalam konteks kejadian yang mempengaruhi system; membangun karakteristik interface system; dan menemukan batasan desain tambahan. Masing – masing dari tugas tersebut berfungsi untuk menjelaskan masalah sehingga pendekatan atau penyelesaian keseluruhan dapat disintesis.

Sebagai contoh, pemasok besar suku cadang kendaraan bermotor membutuhkan system control inventaris. Analisis mendapatkan bahwa masalah yang berhubungan dengan system manual yang ada meliputi :

  • Ketidakmampuan untuk dengan cepat memperoleh status suatu komponen
  • Dua atau tiga hari berkali – kali memperbaharui suatu file kartu
  • Pemesanan kembali secara bertingkat kepada penjual yang sama karena tidak ada cara untuk menghubungkan para penjual dengan komponen dan sebagainya.

Sekali masalah di identifikasi, maka analisis menentukan informasi apa yang akan dihasilkan oleh system baru dan data apa yang akan diberikan kepada system. ¹Misalnya pelanggan menginginkan laporan harian yang menunjukkan suku cadang yang diambil dari inventaris dari beberapa jumlah suku cadang yang sama yang masih ada. Pelanggan menunjukkan bahwa petugas inventaris akan mencatat nomor identifikasi dari masing – masing suku cadang pada saat suku cadang tersebut keluar dari area inventarisasi.

Setelah mengevaluasi masalah yang ada dan juga informasi yang diperlukan (input – output), analis akan mulai mensintesa satu penyelesaian atau lebih. Untuk memulainya, data, fungsi – fungsi pemrosesan, dan tingkah laku system, di definisikan secara detail. Sekali informasi itu dibangun, maka arsitektur dasar pengimplementasian dipertimbangkan. Pendekatan klien / server tampaknya akan sesuai, tetapi apakah kebutuhan pemakai / pelanggan untuk hubungan itu dibenarkan? Proses evaluasi dan sintesis berlangsung sampai analisis dan pelanggan yakin bahwa perangkat lunak dapat ditentukan untuk langkah – langkah pengembangan selanjutnya.

Melalui sintesis analisis dan evaluasi, focus utama analisis adalah pada “apa” (what), bukan “bagaimana” (how). Data apakah yang diproduksi dan konsumsi, batasan apakah yang dipakai?

Selama aktifitas sintesis evaluasi dan solusi, analis menciptakan model – model system untuk lebih memahami aliran data dan control, operasi behavioral dan pemrosesan fungsional, serta muatan informasi. Model tersebut berfungsi sebagai pondasi bagi desain perangkat lunak dan sebagai dasar untuk membuat spesifikasi perangkat lunak.

Penting untuk diperhatikan bahwa spesifikasi lengkap tidak mungkin diperoleh pada tingkat ini. Pelanggan akan menjadi tidak yakin terhadap apa yang sebenarnya dibutuhkannya. Pengembang pun akan menjadi tidak yakin bahwa sebuah pendekatan khusus akan dapat dengan tepat mengerjakan fungsi dan kinerja. Karena alas an tersebut dan yang lainnya, pendekatan alternative pada analisis persyaratan, yang disebut juga prototyping, dapat dilakukan (Bab.2). Prototyping akan dibahas dibagian akhir bab ini.

11.2 TEKNIK KOMUNIKASI

Analisis persyaratan perangkat lunak selalu dimulai dengan komunikasi antara dua bagian atau lebih. Seorang pelanggan memiliki masalah yang dapat di pertanggung jawabkan melalui pemecahan berbasis komputer. Pengembang merespon permintaan bantuan (help) dari pelanggan. Komunikasi sudah dimulai. Tetapi sperti ditulis sebelumnya, jalan dari komunikasi ke pemahaman kadang – kadang penuh dengan lobang.

11.2.1 MENGAWALI PROSES

Teknis analisis paling umum digunakan utnuk menjembatani jurang komunikasi antara pelanggan dan pengembang dan sekaligus untuk memulai proses komunikasi, adalah dengan melakukan pertemuan pendahuluan atau wawancara. Pertemuan pertama antara perekayasa perangkat lunak (analis) dengan pelanggan dapat disamakan dengan kakunya kencan pertama antara dua remaja. Keduanya tidak tahu apa yang akan mereka katakana atau tanyakan; keduanya merasa mengkhawatirkan yang mereka katakana akan disalah artikan; keduanya berpikir kemana arah mereka (keduanya memiliki pengharapan yang sangat berbeda); keduanya ingin pertemuan itu segera berakhir; tetapi pada saat yang sama, keduanya ingin berhasil.

Akan tetapi, komunikasi harus diawali. Gause dan Weinberg [GAU89] menyarankan agar analis memulainya dengan mengajukan pertanyaan – pertanyaan bebas konteks, yaitu serangkaian pertanyaan yang akan mengarah kepada pemahaman yang mendasar atas masalah, orang yang menginginkan penyelesaian, sifat penyelesaian yang dinginkan, dan efektivitas pertemuan pertama itu sendiri. Rangkaian pertama dari pernyataan bebas konteks berfokus pada pelanggan, tujuan keseluruhan, dan keuntungan. Sebagai contoh, analis dapat bertanya :

¤ Siapa dibalik permintaan untuk pekerjaan ini ?
¤ Siapa yang akan menggunakan pemecahan ini ?
¤ Apa keuntungan ekonomi dari pemecahan yang berhasil ?
¤ Apakah ada sumber lain untuk pemecahan yang anda inginkan ?

Rangkaian pertanyaan berikutnya memungkinkan analis mendapatkan pemahaman yang lebih baik mengenai masalah dan pelanggan, untuk menyatakan persepsinya terhadap suatu pemecahan :

  • Bagaimana anda akan menandai output yang baik yang akan didapatkan oleh pemecahan yang berhasil ?
  • Masalah apakah yang akan diselesaikan oleh pemecahan ini ?
  • Dapatkah anda memperlihatkan kepada saya (atau menjelaskan) lingkungan dimana pemecahan tersebut akan digunakan ?
  • Adakah masalah atau batasan kinerja yang khusus yang akan mempengaruhi cara pemecahan tersebut didekati?
  • Rangkaian pertanyaan yang terakhir berfokus pada efektivitas pertemuan. Gause dan Weinberg [GAU89] membuat pertanyaan – pertanyaan mengusulkan daftar berikut ini :
  • Apakah anda adalah orang yang tepat untuk menjawab pertanyaan – pertanyaan ini ? apakah jawaban anda bersifat resmi ?
  • Apakah pertanyaan saya ini bersifat relevan dengan masalah yang anda hadapi ?
  • Apakah anda mengajukan terlalu banyak pertanyaan ?
  • Apakah ada orang lain yang dapat memberikan informasi tambahan ?
  • Apakah ada hal lain yang harus saya tanyakan kepada anda ?

Pertanyaan – pertanyaan tersebut (dan lainnya) akan membantu anda “memecahkan es” dan mengawali komunikasi yang perlu untuk berhasilnya analisis. Tetapi format pertemuan Tanya jawab bukan merupakan pendekatan yang sudah berhasil. Pada dasarnya, sesi Q&A seharusnya digunakan hanya pada pertemuan pertama dan kemudian diganti dengan format pertemuan yang mengkombinasikan elemen – elemen pemecahan masalah, negoisasi, dan spesifikasi. Pendekatan terhadap pertemuan – pertemuan tipe tersebut akan dibahas pada bagian selanjutnya.

11.2.2 Teknik Spesifikasi Aplikasi yang Terfasilitasi
Pelanggan dan pengembang perangkat lunak, tanpa mereka sadari, sering memiliki mind set “kita dan mereka”. Kedua konstituen tersebut bukannya bekerja sebagai tim, tetapi malah membatasi “daerah kekuasaan” mereka sendiri dan berkomunikasi melalui serangkaian memo, surat resmi, dokumen, dan sesi tanya jawab. Sejarah menunjukkan bahwa pendekatan tersebut tidak bekerja dengan baik. Kesalahpahaman, hilangnya informasi penting, dan hubungan kerja yang berhasil tidak pernah dapat terjalin.

Karena masalah itulah maka sejumlah peneliti independen mengembangkan pendekatan time – oriented untuk mengumpulkan kebutuhan yang di aplikasikan selama masa awal analisis dan spesifikasi. Disebut facilitated application specification techniques (FAST), pendekatan itu mendorong munculnya tim gabungan antara pelanggan dan pengembang yang bekerja yang bekerja bersama untuk mengidentifikasi masalah, mengusulkan elemen pemecahan, menegoisasi pendekatan yang berbeda, dan mengkhususkan rangkaian persyaratan pemecahan awal [ZAH90]. Sekarang FAST digunakan terutama oleh masyarakat system informasi, walau teknik tersebut juga menawarkan potensi untuk komunikasi yang berkembang pada semua jenis aplikasi.

Banyak pendekatan yang berbeda terhadap FAST telah diusulkan. Masing – masing pendekatan menggunakan scenario yang sangat berbeda, tetapi semuanya menerapkan beberapa variasi tuntunan dasar berikut ini :

  • Peretemuan dilakukan di sisi netral dan dihadiri baik oleh pengembang maupun pelanggan.
  • Aturan main untuk persiapan dan partisipasi dibuat.
  • Sebuah agenda yang cukup formal diusulkan untuk mencakupkan semua hal penting tetapi tidak terlalu formal agar dapat mengalirkan gagasan bebas.
  • Seorang fasilisator (dapat dari pelanggan, pengembang, atau orang luar) untuk mengontrol pertemuan.
  • Sebuah “mekanisme definisi” (dapat merupakan sebuah lembar kerja, diagram flip, stiker dinding, atau papan tembok) digunakan.
  • Tujuannya adalah untuk mengidentifikasi masalah, mengusulkan elemen pemecahan, menegoisasikan pendekatan yang berbeda, dan mengkhususkan rangkaian persyaratan pemecahan awal dalam suatu atmofsir yang kondusif terhadap pencapaian tujuan.

Untuk memahami secara lebih baik terhadap aliran kejadian pada saat mereka bertemu dalam pertemuan FAST tertentu, disajikan scenario pendek yang menjadi garis besar bagi urutan kejadian yang mengarrah kepada pertemuan, yang terjadi selama pertemuan, dan mengikuti perttemuan tersebut.

Pertemuan awal antara pengembang dan pelanggan (subbab 11.2.1) terjadi dan pertanyaan dan jawaban dasar akan membantu untuk membangun ruang lingkup masalah dan persepsi keseluruhan dari suatu pemecahan. Sebelum pertemuan awal tersebut, pengembang dan pelanggan menulis “permintaan produk” sebanyak satu atau dua halaman. Tempat pertemuan, waktu dan tanggal untuk FAST ditentukan, fasilitator dipilih. Perwakilan baik dari organisasi pengembang maupun organisasi pelanggan di undang untuk dating. Permintaan produk di edarkan ke semua undangan sebelum tanggal pertemuan.

Sambil mengkaji permintaan sebelum dimulainya pertemuan tersebut, masing – masing peserta FAST diminta untuk membuat daftar objek yang merupakan bagian dari lingkungan yang mengelilingi system, objek lain yang dihasilkan oleh system, dan objek yang dihasilkan oleh system untuk melakukan fungsi – fungsinya. Sebagai tambahan, masing – masing peserta diminta membuat daftar yang lain mengenai pelayanan (proses dan fungsi) yang memanipulasi atau berinteraksi dengan objek. Akhirnya, daftar mengenai batasan (misalnya, biaya ukuran, berat) dan criteria kerja (misalnya, kecepatan, akurasi) juga dikembangkan. Para peserta diberitahu bahwa daftar tersebut tidak perlu sempurna, tetapi diharapkan dapat mencerminkan persepsi masing – masing orang terhadap system yang ada.

Sebagai contoh, diasumsikan bahwa tim FAST yang bekerja untuk perusahaan produk konsumen telah memberikan deskripsi produk sebagai berikut :

Penelitian kami menunjukkan bahwa pasar untuk system keamanan rumah berkembang pada laju 40 persen per tahun. Kami ignin memasuki pasar tersebut dengan membangun sebuah system keamanan rumah berbasis mikroprosesor yang akan melindungi dari dan atau mengenali berbagai situasi yang tidak di inginkan, sperti pemasukan illegal, api, banjir, dan lain sebagainya. Produk tersebut secara tentative disebut Safe Home dan akan menggunakan sensor sesuai untuk mendeteksi setiap keadaan, dapat deprogram oleh pemilik rumah, dan akan secara otomatis menelpon sebuah agen pemonitor jika berhasil mendeteksi suatu keadaan.

Pada dasarnya, lebih banyak lagi informasi yang akan diberikan pada tahap ini. Akan tetapi, sekalipun ada informasi tambahan, ambiguitas akan tetap ada, penghilangan tetap saja aka nada, dan kesalahan (error) tetap akan terjadi. Untuk saat ini, deskripsi produk tersebut cukup memadai.
Tim FAST terdiri dari perwakilan dari bagian pemasaran, rekayasa perangkat lunak, rekayasa perangkat keras, dan pemanufakturan. Seorang fasilitator dari luar akan digunakan.

Masing – masing person pada tim FAST (Gambar 11.2) mengembangkan daftar tersebut. Objek yang digambarkan untuk Safe Home dapat meliputi detector asap, sensor pintu dan jendela, detector gerakan, sebuah alarm, sebuah kejadian (sebuah sensor yang telah diaktivasi), sebuah panel control, display, nomor telepon, panggilan telepon, dan sebagainya. Daftar layanan dapat meliputi setting alarm, pemonitoran sensor, pemencetan nomor telepon, pemograman control panel, dan pembacaan display (perhatikan bahwa layanan bertindak menurut objek). Dengan cara yang sama, masing – masing undangan FAST akan mengembangkan daftar batasan (misalnya, system harus memiliki biaya pembuatan kurang dari $200, harus user friendly, dan harus berinterface langsung dengan sambungan telepon standar) serta criteria kinerja (misalnya, sebuah kejadian sensor harus dikenali dalam waktu satu detik; skema prioritas kejadian harus di implementasikan).

Pada saat pertemuan dimulai, topic pertama diskusi adalah kebutuhan akan justifikasi untuk produk baru – setiap orang harus setuju bahwa pengembangan produk (atau akuisisi) dijustifikasi. Sekali persetujuan dibuat, masing – masing partisipan menyajikan daftar mereka yang akan digunakan untuk diskusi. Daftar tersebut dapat ditempel di dinding ruangan dengan menggunakan sembarang kertas yang besar, atau dengan kertas lainnya, atau ditulis pada papan. Idealnya, masing – masing entri daftar harus dapat dimanipulasi secara terpisah sehingga daftar tersebut dapat digabungkan, dihapus, dan dapat ditambah. Pada tahap ini kritik dan debat tidak diperbolehkan.

Setelah daftar individual disajikan dalam satu area topic, maka kelompok kemudian membuat daftar gabungan. Daftar gabungan akan mengurangu entri yang acak dan menambahkan gagasan baru yang muncul selama presentasi, tetapi tidak akan menghapus apapun. Setelah daftar gabungan untuk semua topic dari semua area dibuat, diskusi – dipimpin oleh fasilitator. Daftar gabungan tersebut kemudian dipersingkat, diperpanjang, atau dirumuskan lagi hingga dapat secara tepat mencerminkan produk / system yang akan dikembangkan. Sasaran akan mengembangkan daftar konsesus pada setiap area topic (objek, pelayanan, batasan, dan kinerja). Daftar tersebut kemudian dikesampingkan pada kegiatan selanjutnya.

Begitu daftar consensus telah dilengkapi, tim tersebut terbagi ke dalam subtim yang lebih kecil; masing – masing bekerja untuk mengembangkan sebuah spesifikasi-mini untuk satu entri atau lebih pada setiap daftar. Spesifikasi-mini adalah suatu tambahan dari kata atau frase yang dimasukkan pada daftar. Misalnya, Spesifikasi-mini untuk control panel objek Safe Home dapat berupa :
 Dipasang di dinding,
 Ukurannya kira – kira 9×5 inci,
 Berisi 12 papan ketik dan kunci khusus,
 Berisi display LCD dari bentuk yang diperlihatkan pada sket [tidak ada disini],
 Semua interaksi pelanggan terjadi melalui kunci yang digunakan untuk mengaktifkan dan mematikan system,
 Perangkat lunak untuk memberikan panduan interaksi, echo, dll yang dihubungkan ke semua sensor.

Masing – masing subtim kemudian menyajikan spesifikasi mininya ke semua undangan FAST untuk di diskusikan. Penambahan, penghapusan, dan penambahan lebih jauh lagi dilakukan. Dalam banyak kasus, pengembangan spesifikasi mini akan membuka objek, pelayanan, batasan, atau persyaratan kinerja baru yang akan ditambahkan ke daftar orisinil. Selama diskusi, tim dapat memunculkan suatu masalah yang tidak dapat dipecahkan selama pertemuan. Daftar masalah dikumpulkan agar gagasan – gagasan tersebut dapat di tindak lanjuti kemudian.

Setelah spesifikasi mini ini dilengkapi, masing – masing undangan FAST membuat daftar kinerja validasi untuk produk / system dan menyajikan adfatar tersebut kepada tim. Daftar konsensus mengenai criteria validasi kemudian dibuat. Akhirnya, satu partisipan atau lebih (atau orang luar) diberi tugas untuk menulis draft spesifikasi lengkap dengan menggunakan semua input dari pertemuan FAST.

FAST bukanlah obat bagi masalah yang dihadapi dalam pengumpulan awal berbagai persyaratan, tetapi pendekatan tim memberikan keuntungan dari banyak sudut pandang, diskusi sesaat, dan penyaringan, serta merupakan langkah maju yang konkrit ke arah pengembangan spesifikasi.

11.2.3 Penyebaran Fungsi Kualitas
Penyebaran fungsi kualitas / Quality Function Deployment (QFD) adalah teknik manajemen kualitas yang menerjemahkan kebutuhan pelanggan ke dalam persyaratan teknis bagi perangkat lunak. Pertama kali dikembangkan di Jepang dan pertama kali digunakan di Kobe Shipyar of Mitsubishi Heavy Industries, Ltd. Pada awal tahun 1970-an, QFD “berkonsentrasi pada pemaksimalan kepuasan pelanggan” [ZUL92]. Untuk melakukannya, QFD menekankan pemahaman mengenai apa yang berharga bagi pelanggan dan kemudian menyebarkannya ke seluruh proses rekayasa.
QFD mengidentifikasi tiga tipe persyaratan [ZUL92] :
Persyaratan Normal. Sasaran dan tujuan dinyatakan bagi sebuah produk atau system selama pertemuan dengan pelanggan. Bila persyaratan ini ada, maka pelanggan akan menjadi puas. Contoh persyaratan normal adalah tipe tampilan grafis yang diminta, fungsi system spesifik, dan tingkat kinerja yang didefinisikan.

Persyaratan yang diharapkan. Persyaratan ini implicit terhadap produk atau system dan sangat fundamental sehingga pelanggan tidak menyatakannya secara eksplisit. Ketidakhadirannya akan menyebabkan ketidakpuasan yang mendalam. Contoh persyaratan yang diharapkan adalah mudahnya interaksi manusia dengan mesin, reabilitas dan kebenaran operasional keseluruhan, dan mudahnya instalasi perangkat lunak.

Exciting requirement. Persyaratan ini sangat diharapkan oleh pelanggan dan terbukti sangat memuaskan bila ada. Misalnya, perangkat lunak pengolah kata diharapkan dengan fitur standar. Produk yang disampaikan berisi sejumlah kemampuan layout halaman yang sangat menyenangkan dan tidak terduga.

Dalam kenyataan, QFD melingkupi seluruh proses rekayasa [AKA90]. Tetapi banyak konsep QFD dapat diaplikasikan ke dalam masalah komunikasi pelanggan yang dihadapi oleh perekayasa perangkat lunak selama tahap awal analisis persyaratan. Kami menyajikan sebuah kajian hanya dari konsep – konsep ini (disesuaikan untuk perangkat lunak computer) pada paragraph selanjutnya.

Dalam pertemuan dengan pelanggan, penyebaran fungsi digunakan untuk menentukan nilai dari masing – masing fungsi yang dibutuhkan bagi system. Penyebaran informasi mengidentifikasi baik objek data maupun event yang harus diambil dan dihasilkan oleh system. Keduanya diikatkan pada fungsi. Terakhir penyebaran tugas menguji tingkah laku system atau produk dalam konteks lingkungannya. Analisis nilai dilakukan untuk menentukan prioritas relative dari persyaratan yang ditentukan selama masing – masing dari tiga penyebaran tersebut.

QFD menggunakan wawancara dan observasi pelanggan, survai, dan pengujian data historis (misalnya, pelaporan masalah) sebagai data kasar bagi aktivitas pengumpulan persyaratan. Data – data itu kemudian diterjemahkan ke dalam table persyaratan – disebut consumer’s voice table – yang dikaji dengan pelanggan. Berbagai diagram, metrics, dan metode evaluasi kemudian digunakan untuk menyarikan persyaratan yang diharapkan dan untuk mendapatkan kebutuhan yang sangad diharapkan (exciting requirement) [BOS91].

11.3 PRINSIP – PRINSIP ANALISIS
Lebih dari dua decade terakhir, para peneliti mengidentifikasi masalah – masalah analisis dan penyebab – penyebabnya, serta mengembangkan berbagai notasi pemodelan dan serangkaian penelitian yang sesuai untuk menanggulanginya. Masing – masing metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional :

  1. Dominan informasi dari suatu masalah harus direpresentasikan dan dipahami.
  2. Fungsi – fungsi yang akan dilakukan oleh perangkat lunak harus di definisikan.
  3. Tingkah laku perangkat lunak (sebagai suatu urutan kejadian eksternal) harus diwakilkan.
  4. Model – model yang menggambarkan informasi, fungsi, dan tingkah laku harus dipecah – pecah dalam suatu cara yang membongkar suatu detail dalam bentuk lapisan (atau hirarki).
  5. Proses analisis harus bergerak dari informasi dasar ke detail implementasi.

Dengan mengaplikasikan prinsip – prinsip tersebut, analis mendekati suatu masalah secara sistematis. Domain informasi diuji sehingga fungsi itu dapat di pahami secara lebih lengkap. Model – model digunakan sehingga karakteristik fungsi dan tingkah laku dapat dikomunikasikan dengan cara yang rapi. Pembagian diterapkan untuk mengurangi keruwetan. Pandanagan esensial dan implementasi dari perangkat lunak diperlukan untuk mengakomodasi batasan logis yang dibebankan oleh persyaratan pemrosesan dan batasan fisik yang dibebankan oleh elemen system yang lain.
Sebagai tambahan untuk prinsip analisis operasional tersebut, Davis [DAV95a] mengusulkan serangkaian5 prinsip panduan untuk “rekayasa persyaratan”:

  • Mengembangkan prototype yang memungkinkan seorang pemakai memahami bagaimana interaksi manusia dengan mesin terjadi. Karena persepsi mengenai kualitas prangkat lunak sering di dasarkan pada persepsi “friendliness” interface, maka prototyping (dan terasi yang dihasilkan) sangatlah dianjurkan.
  • Merekam asal dan alas an untuk setiap persyaratan. Hal ini merupakan langkah pertama dalam membangun kemampuan penelusuran kembali ke pelanggan.
  • Menggunakan pandangan persyaratan bertingkat. Pembangunan data, fungsional, dan model tingkah laku member perekayasa perangkat lunak tiga pandangan berbeda. Hal ini mengurangi kemungkinan bahwa inkonsistensi akan diketahui.
  • Memprioritaskan persyaratan. Batas waktu yang tegas dapat menghalangi implementasi setiap persyaratan perangkat lunak. Bila model proses inkremental (Bab2) diaplikasikan, maka persyaratan yang disampaikan dalam inkremental pertama harus di identifikasi.
  • Berusaha mengurangi ambiguitas. Karena sebagian besar persyaratan di gambarkan dalam bahasa natural, kemungkinan untuk terjadinya ambiguitas selalu ada. Penggunaan kajian teknis formal merupakan satu – satunya cara untuk mengurangi ambiguitas tersebut.

Perekayasa perangkat lunak yang mempercayai prinsip tersebut akan dapat lebih mengembangkan spesifikasi perangkat lunak yang kemudian akan menjadi dasar yang kuat bagi desain.

11.3.1 Domain Informasi
Semua aplikasi perangkat lunak secara kolektif dapat disebut data processing. Menarik bahwa istilah itu berisi sebuah kunci ke pemahaman terhadap persyaratan perangkat lunak. Perangkat lunak dibangun untuk memproses data, menstraformasi data dari bentuk yang satu kebentuk yang lain, yaitu untuk menerima input, memanipulasinya dengan berbagai cara, dan menghasilkan output. Pernyataan mendasar dari sasaran ini benar bila kita membangun perangkat lunak batch untuk system daftar gaji atau perangkat lunak real-time embedded untuk mengontrol aliran bahan bakar ke mesin kendaraan bermotor.

Tetapi sangat penting untuk dicatat bahwa perangkat lunak juga memproses event. Event mewakili banyak aspek dari control system dan tidak lebih daripada data Boolean – baik on atau off, true or false, there or not there. Sebagai contoh, sensor tekanan mendeteksi bahwa tekanan melampaui batas nilai aman dan mengirimkan sebuah sinyal alarm ke monitoring perangkat lunak. Sinyal alarm tersebut merupakan suatu event yang mengontrol tingkah laku system. Dengan demikian, data (bilangan, karakter, citra, suara, dll) dan control (kejadian), keduanya ada pada domain informasi dari suatu masalah.

Prinsip analisis operasional yang pertama membutuhkan suatu pengujian domain informasi. Domain informasi berisi tiga pandangan yang berbeda dari data dan control ketika masing – masing dip roses oleh program computer :
1) Muatan dan hubungan informasi
2) Aliran informasi,
3) Struktur informasi.

Untuk benar – benar memahami domain informasi, masing – masing dari pandangan tersebut harus diperhatikan.
Muatan Informasi mewakili data dan objek control individual yang terdiri dari beberapa kumpulan informasi yang lebih besar yang di transformasikan oleh perangkat lunak. Misalnya, objek data paycheck merupakan sebuah gabungan dari sejumlah data yang penting : nama pembayar, jumlah bersih yang dibayarkan, pembayaran keseluruhan, potongan, dan seterusnya. Demikianlah, muatan dari paycheck ditentukan oleh atribut – atribut yang dibutuhkan untuk membuatnya. Dengan cara yang sama, muatan dari suatu objek control yang disebut status system dapat dibatasi oleh sebuah string dari banyak bit. Masing – masing bit mewakili jenis informasi yang berbeda yang menunjukkan apakah perangkat tertentu itu on-line atau off-line.

Objek data dan control dapat dihubungkan dengan objek data dan control lainnya. Sebagai contoh, objek data paycheck memiliki satu hubungan atau lebih dengan objek timecard, employee, bank dan lain – lain. Selama analisis domain informasi, hubungan – hubungan itu harus ditetapkan.

Aliran informasi mewakili cara dimana data dan kontrol berubah pada saat masing – masing bergerak melalui sebuah system. Spereti diperlihatkan pada Gambar 11.3, objek input ditransformasikan ke informasi intermediate ( data dan atau control), dan lebih jauh lagi ditransformasikan ke output. Sepanjang jalur transformasi tersebut, informasi tambahan dapat dimunculkan dari penyimpanan data yang ada (seperti, file disket atau memory buffer). Transformasi yang diaplikasikan merupakan fungsi atau subfungsi yang harus dilakukan oleh sebuah program. Data dan control yang bergerak diantara dua (fungsi) transformasi menentukan interface dari masing” fungsi.

Struktur informasi mewakili organisasi internal dari berbagai jenis data dan control. Apakah jenis data akan diorganisasi sebagai sebuah table n-dimensi atau sebagai sebuah struktur pohon hirarki? Dalam konteks struktur, informasi apa yang dihubungkan dengan informasi lain? Apakah semua informasi di isikan ke dalam sebuah struktur tunggal atau akan digunakan struktur yang berbeda? Bagaimana informasi dalam suatu struktur informasi berhubungan dengan informasi pada struktur yang lain? Pertanyaan – pertanyaan tersebut dijawab dengan suatu penilaian struktur informasi. Harus dicatat juga bahwa struktur data, konsep yang berhubungan yang akan di diskusikan pada buku ini, mengacu pada perancangan dan implementasi informasi.

11.3.2 Pemodelan
Kita menciptakan model untuk memperoleh pemahaman yang lebih baik mengenai entitas actual yang akan dibangun. Bila entitas tersebut berupa sebuah bentuk fisik (bangunan, pesawat, mesin), kita dapat membangun model yang identik dalam bentuk dan potongan, tetapi dalam skala yang lebih kecil. Tetapi bila entitas yang akan dibangun adalah perangkat lunak, maka model harus memakai bentuk yang berbeda. Model harus dapat memodelkan informasi yang di transformasikan oleh perangkat lunak, fungsi (dan subfungsi) yang memungkinkan transformasi terjadi, dan tingkah laku system pada saat transformasi terjadi.

Selama analisis persyaratan perangkat lunak, kita menciptakan model system yang akan dibuat. Model tersebut berfokus pada apa yang harus dilakukan oleh system, bukan pada bagaimana system melakukannya. Dalam beberapa kasus, model yang kita buat menggunakan notasi grafis yang menggambarkan informasi, pemrosesan, tingkah laku system, dan karakteristik lain sebagai symbol yang berbeda dan dapat dikenali. Bagian lain dari model dapat benar – benar tekstual. Informasi deskriptif dapat diberikan dengan menggunakan bahasa natural atau bahasa khusus untuk menggambarkan persyaratannya.

Prinsip analisis operasional kedua dan ketiga mengharuskan kita membangun model fungsi dan tingkah laku :
Model fungsional. Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat lunak harus melakukan paling tidak tiga fungsi genetic: input, pemrosesan, dan output. Pada saat model fungsional dari suatu aplikasi dibuat, perekayasa perangkat lunak memfokuskan dri pada fungsi – fungsi masalah khusus. Model fungsi dimulai dengan sebuah model tingkat konteks tunggal (yakni nama perangkat lunak yang akan dibuat). Dengan serangkaian iterasi , maka lebih banyak lagi detail fungsional diberikan, smapai seluruh rancangan dari semua fungsionalitas system terwakili.

Model tingkah laku. Sebagian besar perangkat lunak merespon kejadian – kejadian dari dunia luar. Karakteristik stimulus-respon ini membentuk dasar dari model tingkah laku. Program computer selalu ada dalam pernyataan – suatu mode tingkah laku yang dapat di obeservasi secara eksternal (misalnya, penungguan, penghitungan, pencetakan, polling) yang diubah hanya pada saat beberapa event berlangsung. Contohnya, perangkat lunak akan tetap berada dalam wait state sampai (1) jam internal menunjukkan bahwa beberapa interval waktu telah berlalu, (2) satu event eksternal (misalnya, pergerakan mouse) menyebabkan suatu interupsi, atau (3) sebuah system eksternal member sinyal kepada perangkat lunak agar bergerak dengan beberapa cara. Model tingkah laku menciptakan representasi pernyataan – pernyataan perangkat lunak dan event – event yang menyebabkan perangkat lunak mengubah pernyataan.

Model yang diciptakan selama analisis persyaratan melayani sejumlah peran penting :

  • Model membantu analisis dalam memahami informasi, fungsi, dan tingkah laku suatu system, sehingga membuat tugas analisis persyaratan menjadi lebih mudah dan lebih sistematis.
  • Model menjadi titik focus bagi kajian sehingga merupakan kunci bagi penetuan kelengkapan, konsistensi, dan akurasi dari spesifikasi.
  • Model menjadi dasar bagi pengerjaan desain, member perancang suatu representasi esensial dari perrangkat lunak yang dapat diterjemahkan ke dalam suatu konteks implementasi.

11.3.3 Pembagian
Masalah sering menjadi terlalu luas atau terlalu rumit untuk dipahami sebagai salah satu kesatuan. Karena itulah kita cenderung membagi masalah seperti itu ke dalam bagian – bagian sehingga dapat dipahami dengan mudah dan kemudian membangun interface antara bagian – bagian tersebut, sehingga keseluruhan fungsi dapat dilakukan. Prinsip analisis operasional keempat menyatakan bahwa domain informasi, fungsional, dan tingkah laku perangkat lunak tidak dapat dibagi – bagi. Secara konseptual, kita membangun sebuah representasi hirarki dari informasi atau fungsi dan kemudian membagi elemen bagiang paling atas (1) mengekpos detail pertambahan dengan bergerak secara vertical dalam hirarki (2). Mendekomposisi masalah dengan bergerak secara horizontal dalam hirarki.

Persyaratan untuk perangkat lunak Safe Home dapat dianalisis dengan pembagian domain informasi, fungsional, dan tingkah laku produk. Untuk mengilustrasikannya, domain fungsional dari masalah tersebut akan di bagi – bagi. Gambar 11.5 mengilustrasikan dekomposisi horizontal dari perangkat lunak Safe Home. Masalah dibagi dengan mengahadirkan fungsi perangkat lunak Safe home konstituen, menggerakkannya secara horizontal dalam hirarki fungsi. Tiag fungsi mayor dicatat pada tingkat pertama hirarki.

Subfungsi yang sesuai dengan fungsi Safe Home mayor dapat diuji dengan mengekpos detail secara vertical pada hirarki, seperti di tunjukkan pada gambar 11.6. dengan menggerakkannya ke arah bawah sepanjang jalur tunggal di bawah sensor monitor fungsi, pembagian terjadi secara vertical untul memperlihatkan pertambahan tingkat detail fungsional.

Pendekatan pembagian yang telah di aplikasikan pada fungsi – fungsi Safe-home juga dapat di aplikasikan padadomain informasi dan kelakuan system akan memberikan wawasan tambahan ke dalam persyaratan system. Pada saat masalah di bagi – bagi, interface di antara system – system ditarik. Data dan control yang bergerak melewati suatu interface harus dibatasi untuk input yang diperlukan untuk melakukan fungsi yang dinyatakan dan outputyang diperlukan oleh elemen fungsi atau system yang lain.

11.3.4 Pandangan Esensial dan Implementasi
Pandangan esensial persyaratan perangkat lunak menyajikan fungsi yang akan dikerjakan dan informasi yang akan diproses tanpa melihat detail implementasinya. Sebagai contoh, pandangan esensial dari fungsi Safe Home read sensor status tidak tergantung pada bentuk fisik dari data atau tipe sensor yang digunakan. Pada dasarnya, dapat diperdebatkan bahwa read status akan menjadi nama yang lebih sesuai bagi fungsi tsb, karena fungsi itu tidak mengabaikan detail mekanisme input keseluruhan. Dengan cara yang sama, sebuah model data esensial dari item data phone number (diimplikasikan oleh fungsi dial phone number) dpt di representasikan pada tahap ini tanpa menghiraukan struktur data yang utama (bila ada) yang digunakan untuk mengimplementasi item data.

Pandangan implementasi dari persyaratan menyajikan manifestasi dunia nyata dari pemrosesan fungsi – fungsi dan struktur informasi. Perangkat input Safe Home merupakan sebuah sensor perimeter. Sensor tsb mendeteksi masukan ilegal dengan “mengendus” adanya break dalam sebuah rangkaian listrik. Analisis harus mengenali batasan yang dikenakan oleh elemen system yang diberlakukan oleh elemen (sensor) system sebelumnya dan mempertimbangkan pandangan implementasi fungsi dan informasi bila pandangan semacam itu sesuai.

11.4 PROTOTYPING PERANGKAT LUNAK
Analisis harus dilakukan tanpa mengabaikan pardigma rekayasa perangkat lunak yang di aplikasikan; tetapi bentuk yang di ambil oleh analisis akan bermacam – macam. Dalam situasi yang lain, dilakukan pengumpulan persyaratan (melalui FAST, QFD, atau teknik “cuci otak” yang lain [JOR89], pengaplikasian prinsip analisis, dan penyusunan model perangkat lunak yang akan di bangun yang disebut prototype, untuk penilaian pelanggan dan pengembang.

11.4.1 Pemilihan Pendekatan Prototyping
Paradigma protyping dapat terbatas atau tidak terbatas. Pendekatan terbatas sering disebut throwaway prototyping. Dengan menggunakan pendekatan tsb, prototype melulu sebagai sebuah demonstrasi kasar dari persyaratan. Pendekatan tidak terbatas, yang disebut juga evolutionary prototyping, menggunakan prototype sebagai bagian pertama dari aktivitas analisis yang akan diteruskan kedalam desain dan kontruksi. Prototipe perangkat lunak merupakan evolusi pertama dari system yang diselesaikan.

Secara umum, sembarang aplikasi yang menciptakan tampilan visual yang dinamis, berinteraksi erat dengan pemakai manusia, atau membutuhkan algoritma atau pemrosesan kombinatorial yang harus dikembangkan dalam sebuah gaya evolusioner, adalah calon untuk prototyping

11.4.2 Metode dan peranti prototyping
Supaya prototyping perangkat lunak efektif, maka harus dikembangkan suatu prototype dengan cepat sehingga pelanggan dapat menilai hasil dan perubahan yang di rekomendasi. Untuk melakukan prototyping secara cepat, ada tiga kelas metode dan peranti generic: teknik generasi keempat, komponen perangkat lunak reusable, spesifikasi formal, dan lingkungan prototyping.

Teknik Generasi Keempat (4GT). Teknik generasi keempat meliputi suatu array yang luas dari query database dan bahasa pelaporan, program dan generator aplikasi, serta bahasa nonprocedural. Karena 4GT memungkinkan perekayasa perangkat lunak memunculkan kode yang dapat dieksekusi dengan cepat, maka 4GT ideal untuk prototyping yang cepat.
Komponen Perangkat Lunak Reusable. Pendektan lain ke rapid prototyping adalah dengan memasang, bukan membangun, prototype dengan menggunakan serangkaian komponen perangkat lunak yang ada.Pada setiap kasus, komponen perangkat lunak harus dirancang dengan cara terntentu sehingga memungkinkannya untuk dipakai kembali tanpa harus mempunyai pengetahuan yang mendetail mengenai kerja internalnya. Perlu di catat bahwa sebuah produk perangkat lunak yabg ada dapat digunakan sebagai sebuah prototype bagi produk kompetitif yang “baru dan telah dikembangkan”. Dengan cara tertentu, hal tsb merupakan suatu bentuk dari reusabilitas untuk prototyping perangkat lunak.

Lingkungan Prototyping dan Spesifikasi Formal. Selama dua decade terakhir, sejumlah bahasa spesifikasi formal dan peranti telah dikembangkan sebagai pengganti bagi teknik spesifikasi bahasa natural. Sekarang pengembang bahasa formal itu berada dalam proses pengembangan lingkungan interaktif yang (1) memungkinkan seorang analisis untuk secara interaktif menciptakan spesifikasi system atau perangkat lunak yang berdasarkan pada bahasa, (2) memanggil peranti otomatis yang menerjemahkan spesifikasi berdasarkan bahasa kedalam kode yang dapat di eksekusi, dan (3) memungkinkan pelanggan untuk menggunakan kode prototype yang dapat di eksekusi untuk menyaring persyaratan – persyaratan formal.