Software Requirement Disiapkan oleh Umi Proboyekti, S.Kom, MLIS by jhs20192

VIEWS: 201 PAGES: 8

									Rekayasa Perangkat Lunak Teknik Informatika UKDW




                                                       Software Requirement
                                  Disiapkan oleh: Umi Proboyekti, S.Kom, MLIS
Pengantar
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.



                                               1
Rekayasa Perangkat Lunak Teknik Informatika UKDW



    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.


Ketiga jenis requirement tersebut diperlukan dalam pembangunan software karena
masing-masing memberi pengertian ke pihak yang berbeda kepentingan. Pembaca
dari ketiga requirement tersebut bisa dijelaskan dengan gambar 1.

                                                     Manager klien
                                                     end-user sistem
             User requirement                        staff ahli klien
                                                     manager developer
                                                     arsitek sistem

                                                      End-user sistem
       System requirement                             staff ahli klien
                                                      arsitek sistem
                                                      tim developer

                                                      Staff ahli klien
   Software specification                             arsitek sistem
                                                      tim developer

                     Gambar 1: jenis requirement dan pembacanya


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



                                               2
Rekayasa Perangkat Lunak Teknik Informatika UKDW



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




                                               3
Rekayasa Perangkat Lunak Teknik Informatika UKDW




                  Gambar 2: Cakupan dari Non-Functional requirement


Karena berkaitan dengan kebutuhan sistem secara keseluruhan,maka kegagalan
memenuhi kebutuhan jenis ini berakibat pada sistem secara keseluruhan. Contoh
kebutuhan jenis ini adalah kecepatan akses, keamanan data, besarnya kapasitas
penyimpanan yang diperlukan, privasi masing-masing profil /account, bahasa
pemrograman yang digunakan, sistem operasi yang digunakan.
Sesuai dengan gambar 2 di atas, non functional requirement dibagi menjadi 3 tipe
yaitu:
    1. Product req. berkaitan dengan kehandalan, kecepatan, kemudahan
         digunakan, kapasitas memori yang dibutuhkan dan efisiensi sistem
    2. Organisational req. berkaitan dengan standar, bahasa pemrograman dan
         metode rancangan yang digunakan.
    3. External req. berkaitan dengan masalah etika penggunaan, interoperabilitas
         dengan sistem lain, legalitas, dan privasi.
3. Domain requirement:
    Berasal dari domain aplikasi sistem. Misalnya karena masalah hak cipta maka
    beberapa dokumen dalam perpustakaan tidak boleh diakses oleh orang lain yang
    tidak berhak.


User Requirement
Menggambarkan functional dan non-functional req yang dapat dipahami oleh
pengguna (user) yang tidak memiliki latar belakang teknis yang cukup. User



                                               4
Rekayasa Perangkat Lunak Teknik Informatika UKDW



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
Contoh penggunaan bahasa alami: pengguna perpustakaan dapat mencari informasi
tentang pustaka melalui form pencarian dengan mengetikkan kata kunci yang
merupakan kata kunci dari judul buku, nama pengarang atau nama penerbit.
Untuk mengurangi kesalahpahaman ketika menulis user req. berikut ini beberapa
petunjuk yang bisa diikuti:
    1. buatlah format yang standar untuk penulisan. Format ini untuk mengurangi
        hal-hal yang tidak perlu dan mudah untuk diperiksa kembali.
    2. menggunakan bahasa yang konsisten, istilah-istilah yang konsisten sehinga
        muda dikuti.
    3. gunakan style seperti cetak miring, cetak tebal untuk memberi kesan penting
        untuk beberapa istilah atau penjelasan.
    4. hindari istilah-istilah teknis komputer yang tidak dimengerti oleh user. Jika
        terpaksa menggunakan, buatlah daftar istilah dan artinya sehingga mudah
        diikuti oleh user.


System Requirement
Merupakan deskripsi sistem yang lebih detil dari user requirement (jadi masih berisi
functional dan non functional req). Req ini bisa berlaku sebagai kontrak
pembangunan sistem dan isa terdiri dari macam model sistem seperti model object
atau model data-flow.
System req. menyatakan apa yang harus dikerjakan sistem, dan bukan bagaimana
sistem diimplementasikan. Untuk itu bahasa yang lebih spesifik dan bersifat teknis
dapat digunakan, seperti misalnya PDL (Program Description Language) seperti
contoh pada gambar 2. PDL digunakan untuk menggambarkan kebutuhan secara
operasional dan sifatnya sangat dekat dengan implementasi program.




                                               5
Rekayasa Perangkat Lunak Teknik Informatika UKDW




 Class ATM {
         //declaration here
         public state void main(string args[]) throws InvalidCard {
                  try {
                  thisCard.read(); //may throw InvalidCard exception
                  pin = KeyPad.readPin(); attempts =1;
                  while ( IthisCard.pin.equals(pin)& attempts <4)
                            { pin = Keypad.readPin (); attempts = attempts+1;
                            }
                            if (IthisCard.pin.equals(pin))
                                      throw new InvalidCard (“Bad Pin”);
                  thisBalance=thisCard.getBalance();
                  do { Screen.prompt(“Please select a service”);
                            service = Screen.touchkey();
                            switch(service){
                                      case Service.withdrawalWithReceipt:
                                                receiptRequired = true;
                                      case Service.withdrawalNoReceipt:
                                                amount = KeyPad.readAmount();
                                                if (amount > thisBalance)
                                                { Screen.printmsg(“Balance insufficient”);
                                                    break;
                                                }
                                                Dispenser.deliver(amount);
                                                newbalance= thisBalance-amount;
                                                if(receiptRequired)
                                                          Receipt.print(amount, newBalance);
                                                          break;
                                       // other service descriptions here
                                      default: break;
                            }
                  }
                  while(service !=Service.quit);
                  thisCard.returnToUser(“Please take your card”);
         }
         catch(InvalidCard e)
         { Screen.printmsg (“Invalid card or PIN”);
         }
         //other exception handling here
   }//main()
 }//ATM

               Gambar 3: Contoh PDL menjelaskan salah satu fungsi ATM


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.
Pengguna dari dokumen kebutuhan adalah pihak-pihak yang dijelaskan pada
Gambar 4 yang menjelaskan pihak pengguna dokumen dan kepentingannya
dengan dokumen tersebut.




                                                    6
Rekayasa Perangkat Lunak Teknik Informatika UKDW




                    Gambar 4: Pengguna dari dokumen requirement
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



                                               7
Rekayasa Perangkat Lunak Teknik Informatika UKDW



    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. Specific requirement covering functional, non-functional and interface
          requirements. This is obviously the most substantial part of the document but
          because of the wide variability in organisationa practice, it is not appropriate
          to define standard structure for this section. The requirements may document
          external interfaces, describe syste functionality and performancce, specify
          logical database requirements, dsign constraints, emergent system properties
          and quality characteristics.
    4. appendices
    5. 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.


Diadaptasi dari:
Sommerville, Ian. "Software Engineering" .6th . Addison Wesley. 2001




                                               8

								
To top