KONSEP DAN PRINSIP ANALISIS

   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.

1. Analisis Kebutuhan Perangkat Lunak

   

- Analisis Persyaratan

Data Domain Model :

• Menetapkan objek data
• Menggambarkan atribut data
• Menetapkan hubungan data

PRINSIP ANALISA 2

Fungsi Model :

• Mengidentifikasi fungsi yang (dapat) merubah objek data
• Mengindikasikan berapa data yang melalui system
• Mewakili data produsen dan konsumen

PRINSIP ANALISA 3

Model Kebiasaan :

• Mengindikasikan states yang berbeda dari system
• Menetapkan kejadian yang mungkin menyebabkan perubahan pada state

PRINSIP ANALISA 4

Partisi Model :

• Menyaring setiap model untuk mewakili level yang lebih rendah dari abstraksi

o   Menyaring objek data

o   Membuat hirarki fungsi

o   Mewakili kebiasaan pada tingkatan yang berbeda tiap detil

• Membuat partisi horizontal dan vertikal

PRINSIP ANALISA 5 :

Intisari :

• Memulai focus intisari masalah tanpa memperhatikan rincian implementasi

BEBERAPA PRINSIP YANG DIKEMUKAKAN DAVIS :

• Mengerti masalah sebelum kita memulai menciptakan model analisa
• Membangun protipe yang memungkinkan pelanggan untuk mengerti bagaimana pelanggan mengerti interaksi manusia dan mesin dapat terjadi
• Mencatat hal-hal yang baru dan alasan untuk setiap kebutuhan
• Menggunakan gambaran bertingkat setiap kebutuhan
•  Memprioritaskan kebutuhan
• Bekerja untuk menghilangkan keragu-raguan

MODEL ANALISA :

BEHAVIORAL MODEL

KAJIAN SPESIFIKASI : 

Kajian dari suatu spesifikasi persyaratan perangkat lunak dilakukan baik oleh pelanggan maupun pengembang perangkat lunak dan harus dilakukan dengan sangat hati-hati.

Kajian ini akan memastikan bahwa spesifikasi sudah lengkap, konsisten dan akurat. Untuk itu, pertanyaan-pertanyaan di bawah ini dapat diajukan :

•  Apakah tujuan dan sasaran yang dinyatakan bagi perangkat lunak tetap konsisten dengan tujuan dan sasaran system ?
• Apakah interface penting ke semua elemen system sudah digambarkan ?
• Apakan aliran informasi dan struktur didefinisikan dengan tepat bagi domain masalah ?
• Apakah diagram jelas ? dapatkah masing-masing berdiri sendiri tanpa teks pendamping ?
• Apakah fungsi mayor tetap ada dalam ruang lingkup, dan sudahkan digambarkan dengan tepat ?
• Apakah tingkah laku perangkat lunak konsisten dengan informasi yang harus diprosesnya dengan fungsi yang harus dilakukannya /
• Apakah batasan desain realistis ?
• Apakah resiko teknologis pengembangan sudah dipertimbangkan ?
• Apakah criteria validasi dinyatakan secara detail ? Apakah criteria itu tepat untuk menggambarkan sebuah system yang berhasil ?
• Apakah ada inkonsistensi, penghilangan atau redundancy ?
• Apakah kontak dengan pelanggan sudah lengkap ?
• Apakah pemakai sudah mengkaji manual pemakai permulaan atau prototype ?
• Bagaimana estimasi perencanaan mempengaruhi ?

 

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.

- 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.

- 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.

- 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].

4. Pinsip-prinsip Analasis
   Masing-masing metode analisis memiliki titik pandang yang unik. Tetapi semua metode analisis dihubungkan oleh serangkaian prinsip operasional:

1. Domain informasi dari suatu masalah harus direpresentasikan dan dipahami.
2. Fungsi-fungsi yang akan dilakukan oleh perangkat lunak harus didefinisikan.
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.
5. Proses analisis harus bergerak dari informasi dasar ke detail implementasi.
6. Dengan mengaplikasikan prinsip-prinsip tersebut, analis mendekati suatu masalah secarasistematis. Domain informasi diuji sehingga fungsi itu dapat dipahami secara lebih lengkap. Model-model digunakan sehingga karakteristik fungsi dan tingkah laku dapat dikomunikasikan dengan cara yang rapi. Pembagian diterapkan untuk mengurangi keruwetan. Pandangan esensial dan implementasi dari perangkat lunak diperlukan untuk mengakomodasi batasan logis yang dibebankan oleh persyaratan pemrosesan dan batasan fisik yang dibebankan oleh elemen sistem yang lain. Perekayasa perangkat lunak yang mempercayai prinsip tersebut akan dapat lebih mengembangkan spesifikasi perangkat lunak yang kemudian akan menjadi dasar yang kuat bagi desain.

- Domain Informasi

- Pemodelan

Model dalam perangkat lunak harus dapat memodelkan informasi yang ditransformasikan oleh perangkat lunak, fungsi (dan subfungsi) yang memungkinkan transformasi terjadi, dan tingkah laku sistem pada saat transformasi terjadi.

Dalam beberapa kasus, model yang kita buat menggunakan notasi grafis yang menggambarkan informasi, pemrosesan, tingkah laku sistem, dan karakteristik lain sebagai simbol yang berbeda dan dapat dikenali. Informasi deskriptif dapat diberikan dengan menggunakan bahasa natural atau bahasa khusus untuk menggambarkan persyaratannya.

Prinsip analisis operasional mengharuskan kita membangun model fungsi dan tingkah laku, yaitu:

  Model fungsional: Perangkat lunak mentransformasi informasi, dan untuk melakukannya, perangkat lunak harus melakukan paling tidak tiga fungsi genetik: input, pemrosesan, dan output. Pada saat model fungsional dari suatu aplikasi dibuat, perekayasa perangkat lunak memfokuskan diri 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, sampai seluruh rancangan dari semua fungsionalitas sistem

terwakili.

  Model tingkah laku: Sebagian besar perangkat lunak merespon kejadiankejadian

dari dunia luar. Karakteristik stimulus-respon ini membentuk

dasar dari model tingkah laku. 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 analis dalam memahami informasi, fungsi, dan tingkah

laku suatu sistem, sehingga membuat tugas analisis persyaratan menjadi

lebih mudah dan lebih sistematis.

- Model menjadi titik fokus bagi kajian sehingga merupakan kunci bagi

penentuan kelengkapan, konsistensi, dan akurasi dari spesifikasi.

- Model menjadi dasar bagi pengerjaan desain, memberi perancang suatu

representasi esensial dari perangkat lunak yang dapat diterjemahkan ke

dalam suatu konteks implementasi.

Meskipun metode pemodelan yang digunakan sering menjadi masalah preferensi

personal atau organisasional, aktivitas pemodelan adalah dasar bagi kerja analisis

yang baik.

 4. Prototyping Perangkat Lunak

   - Prototyping Perangkat

   Analisis harus dilakukan tanpa mengabaikan paradigma rekayasa perangkat lunak yang di aplikasikan; tetapi bentuk yang diambil oleh analisis akan bermacam- macam. Dalam banyak kasus sangat mungkin untuk mengaplikasikan prinsip operasional dan menarik sebuah model perangkat lunak yang melaluinya sebuah desain dapat dikembangkan, pengaplikasian prinsip analisis dan penyusunan model perangkat lunak yang akan dibangun yang disebut prototype untuk penilaian pelanggan danpengembang.

  - Pemilihan prototyping

    Paradigma prototyping terbatas dan tidak terbatas. Pendekatan terbatas sering disebut : throw away prototyping. Dengan menggunakn pendekatan tersebut, prototyping sebagai sebuah demonstrasi kasar dari sebuah persyaratan.Kemudian prototype dikesampingkan dan perangkat lunak direkayasa dengan menggunakan suatu paradigma yang berbeda.Pendekatan tidak terabatas sering disebut evolusionary prototyping,menggunakan prototyping sebagai bagian utama dari aktivitas analisis yang akan diteruskan ke dalam desain dan konstruksi.

  - Metode dan Peranti Prototyping

    Agar prototyping perangkat lunak efektif, maka harus dikembangkan suatu prototype dengan cepat sehingga pelanggan dengan dapat menilai hasil dan perubahan yang di rekomendasikan. Untuk melakukan prototyping dengan tepat ad tiga kelas metode dan peranti generik, teknik generasi keempat komponen perangkat lunak reusable, spesifikasi normal,dan lingkungan prototyping.

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.

 a. 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

  b. 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.

Sumber:

-http://webcache.googleusercontent.com/search?q=cache:fnqWPXmDauUJ:www.smknperkapalan.net/ebook/view.php%3Ffile%3DMeteri%2BVEDC/Semester%2B3/rekayasa%2Bsistem%2Boperasi/Pert%2B1/Modul/ModulTeori/Bab%2B3%2BKONSEP%2BDAN%2BPRINSIP%2BANALISIS.doc+&cd=3&hl=id&ct=clnk

-http://bintanggalaksi26.blogspot.co.id/2012/06/materi-konsep-dan-prinsip-analisis.html

-https://indrahimessi.wordpress.com/2010/12/21/konsep-dan-prinsip-analisis-rpl/

-http://putriptiwi.blogspot.co.id/2013/06/prinsip-dan-konsep-analisa.html