PENGANTAR REQUIREMENT DOCUMENT

Requirement tidak hanya ditulis oleh pembangun, tapi sebelumnya justru ditulis oleh klien yang memesan software. Klien menuliskan requirement dalam bentuk yang masih abstrak tentang kebutuhannya. Kemudian requirement tersebut diserahkan kepada tim pembangun. Saat sudah ada persetujuan pembangun pun kemudian menuliskan kemampuan sistem yang bisa dipahami oleh klien, inipun disebut requirement.

Definisi
Requirement adalah gambaran dari layanan (services) dan batasan bagi sistem yang akan dibangun. Atau requirement adalah pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem.
Requirement berfungsi ganda yaitu:
•Menjadi dasar penawaran suatu kontrak --> harus terbuka untuk masukan
•Menjadi dasar kontrak --> harus didefinisikan secara detil
Proses menemukan, menganalisis, mendokumentasikan dan pengujian layanan, layanan dan batasan tersebut disebut Requirement Engineering.

Pengumpulan requirement
_ Interviews : Memberi informasi yang terbaik,mahal
_ Questionnaires: Bagus jika banyak orang terlibat dan tersebar, respon
cenderung kurang baik
_ Observation: Akurat jika dilakukan dengan baik, mahal
_ Searching :Informasi terbatas, cenderung tidak menampilkan hal-hal yang mungkin jadi masalah.

Beberapa macam requirement
_ User requirement (kebutuhan pengguna)
• Pernyataan tentang layanan yang disediakan sistem dan tentang batasan batasan operasionalnya. Pernyataan ini dapat dilengkapi dengan gambar/diagram yang dapat dimengerti dengan mudah.

_ System requirement (kebutuhan sistem)
• Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.
_ A software design specification (spesifikasi rancangan PL)
• Gambaran abstrak dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil.

User Requirement
Menggambarkan functional dan non-functional req yang dapat dipahami oleh pengguna (user) yang tidak memiliki latar belakang teknis yang cukup. User requirement menjelaskan perilaku luar dari sistem, tidak secara teknis, karena itu perlu menggunakan bahasa alami, atau bahasa yang sederhana.
Masalah dalam menyiapkan user req adalah:
•Bahasa alami kadang tidak cukup untuk menjelaskan, atau membuat
dokumen jadi sulit dibaca
•Jenis-jenis req, kadang jadi sulit dibedakan
•Sering digabungkan menjadi satu kumpulan requirement saja
Dokumen kebutuhan (requirement document)
Dokumen kebutuhan merupakan pernyataan resmi dari apa yang dibutuhkan dari pembangun sistem, berisi definisi dan spesifikasi requirement dan bukan dokumen
desain. Sebisa mungkin berupa kumpulan dari APA yang harus dikerjakan sistem, BUKAN BAGAIMANA sistem mengerjakannya.
Dokumen kebutuhan sebaiknya memenuhi 6 hal berikut :
1. menjelaskan perilaku eksternal sistem
2. menjelaskan batasan pada implementasi
3. mudah diubah
4. sebagai alat referensi untuk pemelihara sistem
5. mencatat peringatan awal tentang siklus dari sistem
6. menjelaskan bagaimana sistem merespon hal-hal yang tidak biasa/normal
IEEE menyarankan standar struktur dari dokumen kebutuhan sebagai berikut :
1. introduction
1.1 purpose of the requirement document
1.2 scope of the product
1.3 definitions, acronyms and abbreviations
1.4 references
1.5 overview of the remainder of the document
2. General description
2.1 product perspective
2.2 product functions
2.3 user characteristics
2.4 general constrains
2.5 assumptions and depedencies
3. appendices
4. index
Sekalipun standar IEEE belumlah ideal tetapi telah memberikan masukan format dokumen yang cukup lengkap. Informasi yang dimasukkan ke dalam dokumen tergantung pada tipe software yang dibangun dan pendekatan yang digunakan untuk membangun software tersebut.
Struktur lain yang bisa digunakan adalah sebagai berikut :
1. Preface
2. Introduction
3. Glossary
4. User requirements definition
5. System architecture
6. System requirements specification
7. System models
8. System evolution
9. Appendices
10. Index
Kedua struktur sama baiknya dan salah satu dapat digunakan untuk menyusun dokumen kebutuhan.
Masalah yang mungkin terjadi dalam pendefinisian requirement adalah:
•Sulit mengantisipasi efek dari sistem baru terhadap organisasi
•Beda user, beda pula requirement dan prioritasnya – terpengaruh cara atau gaya
kerja
•End-user sistem, dan organisasi yang membiayai sistem berbeda requirement
•Prototype sering dibutuhkan untuk menjelaskan requirement
•Masalah perbedaan bahasa alami
Software system requirement sering dibedakan dalam 2 katagori yaitu Functional requirement, Non Functional requirement dan domain requirement
dengan masing-masing penjelasannya sebagai berikut:

1. Functional Requirement : Merupakan penjelasan tentang layanan yang perlu disediakan oleh sistem, bagaimana sistem menerima dan mengolah masukan, dan bagaimana system mengatasi situasi-situasi tertentu. Selain itu kadang-kadang juga secara jelas menentukan apa yang tidak dikerjakan oleh sistem.
Functional requirement menggambarkan system requirement secara detil seperti
input, output dan pengecualian yang berlaku. Contoh dalam kasus peminjaman buku di perpustakaan:
•Pengguna bisa mencari semua informasi tentang buku atau bisa memilih
salah satu dari informasi tentang buku
•Semua peminjam memiliki pengenal yang unik
•Sistem mampu catat transaksi peminjaman, pengembalian dan denda secara
lengkap
•Hari libur bisa di-set sejak awal, dan bisa menerima perubahan dengan
otoritas khusus
•Harus komplit ( kebutuhan layanan jelas dan lengkap) dan konsisten (tidak
kontradiksi dengan yang didefinisikan).
Masalah yang mungkin terjadi dalam menyusun functional requirement adalah:
1. Diintepretasikan/diartikan berbeda oleh user atau developer
2. Hasil intepretasi sering tidak menjawab kebutuhan klien
3. Untuk sistem yang besar, kelengkapan kebutuhan dan konsisten sulit dicapai karena kerumitan sistem
4. Perlu analisis yang dalam dan menyeluruh untuk mengurangi kesalahan

2. Non-functional Requirement:
Secara umum berisi batasan-batasan pada pelayanan atau fungsi yang disediakan oleh sistem. Termasuk di dalamnya adalah batasan waktu, batasan proses pembangunan, standar-standar tertentu.

Permodelan Analisis

Pemodelan Analisis
Pembahasan

Pada tingkat teknik, rekayasa perangkat lunak dimulai dengan serangkaian tugas pemodelan yang membawa kepada suatu spesifikasi lengkap dari persyaratan representasi dan representasi desain yang komprehensip bagi perangkat lunak yang dibangun.

a. Elemen Model Analisis
Model analisis harus dapat mencapai tiga sasaran utama yakni untuk :
• Menggambarkan apa yang dibutuhkan untuk pelanggan
• Membangun dasar bagi pembuatan desain perangkat lunak
• Membatasi serangkaian persyaratan yang dapat divalidasi begitu perangkat lunak dibangun.

Untuk mencapai sasaran tersebut dibuatlah model analisis yang berisi:
• Data Dictionary

   Penyimpanan yang berisi deskripsi dari semua obyek data yang dikonsumsi atau diproduksi oleh perangkat lunak.

• Entity Relationship Diagram (ERD)
   Menggambarkan hubungan antara obyek data.
• Data Flow Diagram (DFD)
   o Memberikan indikasi mengenai bagaiman data ditransformasi pada saat data bergerak melalui sistem
   o Menggambarkan fungsi-fungsi (dan sub fungsi) yang mentransformasikan aliran data.
• State Transition Diagram
   Menunjukkan bagaimana sistem bertingkah laku sebagai akibat dari kejadian eksternal.
• Control Specification (CSPEC)
   Informasi tambahan mengenai aspek kontrol dari perangkat lunak

b. Pemodelan Data

Pemodelan data merupakan sebuah tahapan dalam merancang sebuah sistem informasi. Pemodelan data berfokus pada data apa yang akan disimpan yang menggambarkan hubungan entara entiti set yang dibutuhkan oleh sebuah organisasi dalam pengelolaan data.
Untuk dapat menjawab tentang pemodelan data sebagai berikut : 

1. Bagaimana komposisi dari masing-masing obyek data dan atribut apa yang menggambarkab obyek tersebut?
2. Dimana obyek saat ini berada? 
3. Bagaimana hubungan antara masing-masing obyek data dan obyek lainnya? 
4. Bagaimana hubungan antara obyek dengan proses yang mentransformasikannya? Digunakan Entity Relational Diagram (ERD)  

1. Obyek Data, Atribut dan Hubungan 
Obyek Data Adalah representasi dari hamper semua informasi gabungan yang harus dipahami oleh perangkat lunak. Atribut Menentukan property suatu obyek data dan mengambil salah satu dari tiga karakteristik yang berbeda.
o Menamai sebuah contoh dari obyek data
o Menggambarkan contoh
o Membujat referensi ke contoh yang lain pada tabel yang lain.
Hubungan  Obyek data disambungkan satu dengan lainnya dengan berbagai macam cara.
 

2. Kardinalitas dan Modalitas Kardinalitas
Model data harus dapat merepresentasikan jumlah peristiwa dari obyek di dalam hubungan yang diberikan

• Satu ke satu (1:1)  Misalnya: seorang suami hanya dapat memiliki satu istri, dan seorang istri hanya mempunyai satu suami
• Satu ke banyak (1:N) Misalnya: seorang ibu dapat memiliki banyak anak, tetapi seorang anak hanya dapat memiliki satu ibu
• Banyak ke banyak (M:N) Misalnya: seorang paman dapat memiliki banyak keponakan, sementara itu seorang keponakan dapat memiliki banyak paman

Modalitas  Modalitas dari suatu hubungan adalah nol bila tidak ada kebutuhan eksplisit untuk hubungan yang  terjadi atau hubungan itu bersifat opsional. Modalitas bernilai satu jika suatu kejadian dari hubungan merupakan perintah.

Entity Relational Diagram
Pada mulanya digunakan untuk desain sistem database relational dan telah dikembangkan oleh yang lainnya. Serangkaian komponen utama diidentifikasikan untuk ERD: obyek data, atribut, hubungan dan berbagai tipe indicator. Tujuan utama dari ERD adalah untuk mewakili obyek data dan hubungan mereka.

c. Pemodelan Fungsional dan Aliran Informasi

Informasi ditransformasikan pada saat dia mengalir melalui sebuah sistem berbasis komputer. Sistem tersebut menerima input dengan berbagai cara dan menghasilkan suatu output. Akibatnya kita dapat menciptakan suatu model aliran bagi setiap sistem berbasis komputer tanpa melihat ukuran dan kompleksitasnya.
1. Diagram Aliran Data/ Data Flow Diagram (DFD)
Merupakan sebuah teknik grafis yang menggambarkan aliran informasi dan transformasi yang diaplikasikan pada saat data bergerak dari input menjadi output.   Dikenal juga dengan sebutan grafik aliran data atau buble chart.

Komponen-komponen DFD :

• Proses : menunjukkan apa yang dikerjakan oleh sistem. Setiap proses memiliki nama yang unik dan nomor yang ditempatkan dalam simbol.  
• External entity adalah di luar sistem, tetapi mereka merupakan salah satu bagian yang memberikan input data ke dalam sistem atau digunakan oleh output sistem 
• Data Flow  adalah tempat penyimpanan data 
• Data Store  : Proses dapat menempatkan data ke dalam data store atau mengambil / mendapatkan data store. Setiap data store mempunyai nama yang unik  External Entity  

Pemodelan Tingkah Laku :
Model prilaku menggambarkan bagaimana PL merespon event atau stimulan eksternal. Untuk model tersebut, anlisis harus melakukan langkah-langkah sebagai berikut :

• Evaluasi semua use-case untuk mendapatkan pemahaman menyeluruh tentang urutan interaksi di dalam sistem.
• Mengenali event yang mengendalikan urutan interaksi dan memahami bagaimana event mempunyai relasi terhadap objek spesifik.
• Membuat urutan untuk setiap use-case.
• Membangun state diagram untuk sistem.
• Review model behavioral untuk memverifikasi akurasi dan konsistensi

Mekanik dari analisis terstruktur
Dalam konteks pemodelan perilaku, dua karakter keadaan harus diperhatikan:

• Keadaan setiap class ketika sistem menjalankan fungsinya, dan
• Keadaan sistem ketika diobservasi dari luarsebagaimana sistem menjalankan fungsinya.

Keadaan class mengambil baik karakter aktif maupun pasif [CHA93].

• Sebuah keadaan pasif adalah status saat ini dari semua atribut objek.
• Keadaan aktif dari sebuah objek menggambarkan status saat ini pada objek tersebut ketika menjalankan transformasi atau proses. 

Kamus Data

Kamus data adalah suatu daftar data elemen yang terorganisir dengan definisi yang tetap dan sesuai dengan sistem, sehingga user dan analis sistem mempunyai pengertian yang sama tentang input, output, dan komponen data strore.    Kamus data ini sangat membantu analis sistem dalam mendefinisikan data yang mengalir di dalam sistem, sehingga pendefinisian data itu dapat dilakukan dengan lengkap dan terstruktur. Pembentukan kamus data dilaksanakan dalam tahap analisis dan perancangan suatu sistem.    Pada tahap analisis, kamus data merupakan alat komunikasi antara user dan analis sistem tentang data yang mengalir di dalam sistem, yaitu tentang data yang masuk ke sistem dan tentang informasi yang dibutuhkan oleh user. Sementara itu, pada tahap perancangan sistem kamus data digunakan untuk merancang input, laporan dan database.    Pembentukan kamus data didasarkan atas alur data yang terdapat pada DFD. Alur data pada DFD ini bersifat global, dalam arti hanya menunjukan nama alur datanya tanpa menunjukan struktur dari  

Metode Analisis Klasik

Model Proses Perangkat Lunak  Evolusioner

Model evolusioner adalah model iteratif. Model itu ditandai dengan tingkah laku yang memungkinkan perekayasa perangkat lunak mengembangkan versi perangkat lunak yang lebih lengkap sedikit demi sedikit.
 

Model Pertambahan

Model inkremental menggabungkan elemen-elemen model sekuensial linier dengan filosofi prototipe iteratif. Pada saat model pertambahan dipergunakan, pertambahan pertama sering merupakan produk inti (core product), yaitu sebuah model pertambahan yang dipergunakan, tetapi beberapa muka tambahan tetap tidak disampaikan. Produk inti tersebut dipergunakan oleh pelanggan (atau mengalami pengkajian lebih detail). Sebagai hasil dari pemakaian dan/atau evaluasi, maka dikembangkan rencana bagi pertambahan selanjutnya. Rencana tersebut menekankan modifikasi produk inti untuk secara lebih baik memenuhi kebutuhan para pelanggan dan penyampaian fitur serta fungsionalitas tambahan. Proses ini diulang mengikuti penyampaian setiap pertambahan sampai bisa menghasilkan produk yang lengkap.
Model proses pertambahan tersebut, seperti model prototipe dan pendekatan-pendekatan evolusioner yang lain, bersifat iteratif. Tetapi tidak seperti model prototipe, model pertambahan berfokus pada penyampaian produk operasional dalam setiap pertambahannya. Pertambahan awal ada di versi stripped down dari produk akhir, tetapi memberikan kemampuan untuk melayani pemakai dan juga menyediakan platform untuk evaluasi oleh pemakai.
 

Model Spiral

Model spiral yang pada awalnya diusulkan oleh Boehm adalah model proses perangkat lunak yang evolusioner yang merangkai sifat iteratif dari prototipe dengan cara kontrol dan aspek sistematis dari model sekuensial linier. Model itu berpotensi untuk pengambangan versi pertambahan perangkat lunak secara cepat.

• Model spiral dibagi menjadi sejumlah aktivitas kerangka kerja, disebut juga wilayah tugas, di antara tiga sampai enam wilayah tugas. Gambar 2.8. menggambarkan model spiral yang berisi enam wilayah tugas : Komunikasi pelanggan – tugas-tugas yang dibutuhkan untuk membangun komunikasi yang efektif di antara pengembang dan pelanggan
• Perencanaan – tugas-tugas yang dibutuhkan untuk mendefinisikan sumber-sumber daya, ketepatan waktu, dan proyek informasi lain yang berhubungan.
• Analisis risiko – tugas-tugas yang dibutuhkan untuk menaksir risiko-risiko, baik manajemen maupun teknis.
• Perekayasa – tugas-tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari aplikasi tersebut
• Konstruksi dan peluncuran – tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang (install) dan memberikan pelayanan kepada pemakai (contohnya pelatihan dan dokumentasi).
• Evaluasi pelanggan – tugas-tugas yang dibutuhkan untuk memperoleh umpan balik dari pelanggan dengan didasarkan pada evaluasi representasi perangkat lunak, yang dibuat selama masa perekayasaan, dan diimplementasikan selama masa pemasangan.

Ketika proses evolusioner ini mulai, tim rekayasa perangkat lunak bergerak searah jarum mengelilingi spiral tersebut dengan dimulai intinya. Lintasan pertama putaran spiral menghasilkan perkembangan dari spesifikasi produk; putaran spiral selanjutnya mungkin dipakai untuk mengembangkan sebuah prototipe, dan secara progresif mengembangkan versi perangkat lunak yang lebih canggih.
Tidak seperti model proses klasik yang berakhir pada saat perangkat lunak sudah disampaikan, model spiral bisa disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak komputer.
Model spiral menjadi sebuah pendekatan yang realistis bagi perkembangan sistem dan perangkat lunak skala besar. Karena perangkat lunak terus bekerja selama proses bergerak, pengembang dan pemakai memahami dan bereaksi lebih baik terhadap risiko dari setiap tingkat evolusioner. Model spiral menggunakan prototipe sebagai mekanisme pengurangan risiko.

Model Rakitan Komponen

Model rakitan komponen menggabungkan beberapa karakteristik model spiral. Model ini bersifat evolusioner, sehingga membutuhkan pendekatan iteratif untuk menciptakan perangkat lunak. Tetapi model rakitan komponen merangkai aplikasi dari komponen perangkat lunak sebelum dipaketkan (kadang-kadang disebut “kelas”).
Model rakitan komponen membawa kepada penggunaan kembali perangkat lunak, dan kegunaan kembali tersebut memberi sejumlah keuntungan yang bisa diukur pada perekayasa perangkat lunak.

Model perkembangan Konkuren

Model proses konkuren sering digunakan sebagai paradigma bagi pengembangan aplikasi klien/server. Sistem klien/server dirancang dari serangkaian komponen fungsional. Bila diaplikasikan kepada klien/server, model proses konkuren akan mendefinisikan aktivitas di dalam dua dimensi : dimensi sistem, dan dimensi komponen. Isu tingkat sistem ditujudengan menggunakan tiga aktivitas : desain, assembly, dan pemakaian. Dimensi komponen dituju dengan dua aktivitas : desain dan rea-lisasi. Konkuren dicapai dengan dua cara :

1. aktivitas sistem dan komponen yang berlangsung secara simultan dan dapat dimodelkan dengan menggunakan pendekatan orientasi keadaan yang digambarkan di atas;
2. aplikasi klien/server khusus diimplementasikan dengan banyak komponen di mana masing-masing bisa dirancang dan direalisasikan secara konkuren.

Kenyataannya model proses konkuren bisa diaplikasikan ke dalam semua tipe perkembangan perangkat lunak, dan memberikan gambaran akurat mengenai keadaan tertentu dari sebuah proyek.