Understanding Software Requirements

Slide1Software RequirementsSoftware Requirements - adopted & adapted from I. Sommerville, 2004

Slide2Tujuan• Memperkenalkan konsep kebutuhan sistem dan user • Menjelaskan kebutuhan fungsional dan non fungsional • Menjelaskan bagaimana kebutuhan perangkat lunak di organisasikan pada dokumentasi perangkat lunak Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide3Topik• Functional and non-functional requirements • User requirements • System requirements • Interface specification • The software requirements document Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide4Rekayasa Kebutuhan• Proses memberikan layanan mengenai apa yang dibutuhkan customer dari sebuah sistem dan semua kendalanya ketika dioperasikan dan dikembangkan • Kebutuhan adalah deskripsi dari layanan sistem dan kendalanya yang dihasilkan selama proses rekayasa kebutuhan Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide5Apa itu kebutuhan ?• Abstraksi High-level dari sebuah layanan dan kendala atau batasan sistem sampai dengan kebutuhan fungsional matematis • Kebutuhan yang tidak dapat dihindari melayani fungsi sebagai berikut : – dasar Bid contract ( Open interpretation ) – Dasar dari isi kontrak itu sendiri ( detail ) – Statement diatas dapat disebut requirement Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide6Requirements abstraction (Davis)Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide7Tipe dari Requirement• User requirements – Persyaratan pengguna adalah pernyataan, biasanya dalam bahasa natural (mis. Bahasa Inggris, Indonesia, dsb.) dan dapat ditambahkan diagram, tentang layanan yang diharapkan untuk disediakan oleh sistem dan tentang batasan operasi sistem tersebut • System requirements – Persyaratan sistem menjelaskan fungsi-fungsi sistem, layanan-layanan sistem, dan batasan operasional sistem secara rinci. Dokumen persyaratan sistem (kadang-kadang disebut dengan spesifikasi fungsional) seharusnya tepat dan teliti. Dia semestinya mendefinisikan secara pasti apa yang akan diimplementasikan. Dia bisa menjadi bagian dari kontrak antara pembeli sistem dan pengembang sistem. Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide8Pembaca RequirementsSoftware Requirements - adopted & adapted from I. Sommerville, 2004

Slide9Definisi dan spesifikasiSoftware Requirements - adopted & adapted from I. Sommerville, 2004

Slide10Requirement fungsional dan non fungsional• Persyaratan Fungsional – pernyataan-pernyataan tentang layanan yang harus disediakan sistem, bagaimana seharusnya sistem bereaksi terhadap masukan tertentu, dan bagaimana seharusnya sistem berperilaku dalam situasi- situasi tertentu. Pada beberapa kasus, pernyataan fungsional dapat juga menyatakan secara eksplisit apa yang  tidak  seharusnya dikerjakan oleh sistem. • Persyaratan Non-fungsional – Ini adalah batasan-batasan (constraints) pada layanan atau fungsi yang disediakan oleh sistem. Mereke meliputi batasan waktu (timing constraints), batasan pada proses pengembangan dan standar yang digunakan. Persyaratan non-fungsional sering berlaku pada sistem secara keseluruhan. Mereka tidak biasanya hanya berlaku pada fitur atau layanan tertentu secara individu. • Persyaratan Domain – Ini adalah persyaratan yang berasal dari domain aplikasi dari sistem dan mencerminkan karakteristik dan batasan-batasan domain tersebut. Ketika dijabarkan, persyaratan domain dapat berupa persyaratan fungsional ataupun persyaratan non-fungsional. Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide11Kebutuhan fungsional• Menjelaskan fungsionalitas atau layanan sistem • Tergantung dari tipe software,user yang diharapkan dan tipe dari sistem dimana software akan digunakan • Fungsional user requirement dapat berupa statement high level tapi fungsional sistem requirement harus dijabarkan layanan dari sistem tersebut secara detail Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide12The LIBSYS system ( user requirement)• Sistem perpustakaan yang menyediakan interface ke beberapa database artikel pada perpustakaan lain. • User dapat melakukan pencarian, download dan cetak artikel tersebut untuk belajar personal Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide13Contoh system functional requirements• User  harus  bisa  melakukan  search  pada  beberapa kelompok  database  atau  memilih  salah  satu  nya. • Sistem  harus  menyediakan  “appropriate  viewers”  untuk user  ketika  membaca  document  pada  media penyimpan  document • Setiap  order  harus  dialokasikan  sebuah  Unique identifier  (  ORDER_ID)  dimana  user  akan  mampu  untuk mengkopi  ke  account   media  penyimpanan  user Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide14Ketidak tepatan requirement• Masalah muncul ketika kebutuhan tidak dijabarkan secara tepat • Kebutuhan yang bersifat ambigu di interprestasikan berbeda antara pengembang dan pengguna • Lihat kata pada slide 13 =‘appropriate viewers’ – Keinginan user- Viewer untuk beberapa macam dokumen – Interprestasi Developer – hanya menyediakan text viewer yang menunjukkan isi dari dokument Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide15Kelengkapan dan konsistensirequirement • Pada prinsipnya, spesifikasi persyaratan fungsional seharusnya lengkap dan konsisten. • Kelengkapan ( completeness )  berarti seluruh layanan yang dibutuhkan pengguna harus didefinisikan. • Konsistensi ( consistency ) bermakna persyaratan-persyaratan tidak boleh memiliki definisi-definisi yang kontradiktif. • Pengaruh banyaknya stakeholders dapat menyebabkan permasalahan ini muncul Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide16Non-functional requirements• Persyaratan non-ungsional adalah persyaratan yang tidak secara langsung terkait dengan fungsi-fungsi tertentu yang dimiliki oleh sistem. • Persyaratan ini mendefinisikan properti dan batasan sistem, misalnya reliability , waktu respon, dan persyaratan kapasitas penyimpanan. • Persyaratan proses juga dapat dispesifikasikan untuk mengharuskan sistem CASE, bahasa pemrograman, atau metode pengembangan tertentu. • Persyaratan non-fungsional bisa lebih kritis daripada persyaratan fungsional. Sebagai contoh, persyaratan keselamatan ( safety ) tertentu pada sistem control pesawat terbang. Jika persyaratan ini tidak dipenuhi, sistem tidak dapat atau tidak boleh digunakan. Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide17Klasifikasi Non-functional• Product requirements – Requirement yang menspesifikasikan perilaku produk harus berjalan dengan syarat tertentu e.g kecepatan exekusi, reliabily dsb • Organisational requirements – Requirement yang memiliki konsekuensi terhadap aturan dan prosedur organsasi .e.g SOP, implementasi , dsb • External requirements – Requirement yang muncul karena faktor dari external sistem dan proses pengembangannya e.g Sistem harus beroperasi sesuai hukum ,dsb Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide18Tipe Non-functional requirementSoftware Requirements - adopted & adapted from I. Sommerville, 2004

Slide19Contoh Non-functional requirements• Product requirement – Interface user pada LIBSYS harus dapat diimplemntasikan dengan HTLM tanpa frames atau java Applets • Organisational requirement – Proses pengembangan sistem dan dokumen yang harus memenuhi proses dan pengembangan yang didefiniskan pada • External requirement – Sistem harus tidak membuka seluruh informasi personal tentang customers selain nama dan nomor referensi untuk operator sistem Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide20Goals dan requirements• Nong-functional requirement mungkin akan sangat sulit untuk dinyatakan secara tepat dan requirement yang tidak tepat akan sangat sulit untuk di verifikasi • Goal – Maksud dari user secara umum    ex: kemudahan penggunaan • Verifiable non-functional requirement – Pernyataan yang menggunakan pengukuran tertentu yang dapat di tes secara obyektif • Goals sangat membantu pengembang ketika user menyampaikan maksud dari sistem user Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide21Contoh• A  system  goal – Sistem  harus  mudah  untuk  digunakan  dengan  metode/penguna  yang  sudah umum  dan  di  organsiasikan  sehingga  kesalahan  pengguna  dapat diminimalisasikan • A  verifiable  non-functional  requirement – Pengguna  yang  sudah  umum  harus  mampu  untuk  menggunakan  semua  fungsi sistem  setelah  menempu  2  jam  pelatihan.  Setelah  pelatihan,  jumlah  rata-rata kesalahan  yang  dialami  user  harus  tidak  lebih  dari  2  kesalahan  per  hari Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide22Pengukuran kebutuhanSoftware Requirements - adopted & adapted from I. Sommerville, 2004

Slide23Interaksi requirement• Konflik antara perbedaan requirement non-fungsional pada sebuah sistem yang kompleks • Spacecraft system – Untuk mengurangi beban, jumlah dari chips harus diminimalisasikan – Untuk mengurangi konsumsi daya, chips yang hemat daya harus digunakan – Menggunakan low power chips artinya harus memperbanyak jumlah chip . Mana requirement yang lebih kritikal ? Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide24Domain requirements• Diturunkan dari aplikasi domain dan menyjelaskan karakteristik dan fitur yang merefleksikan domain • Domain requirement akan menjadi fungsional requirement yang baru, kendala pada requirement yang existing atau mendefinisikan komputasi yang spesifik • Jika domain requirement tidak dipenuhi, sistem mungkin tidak dapat bekerja Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide25Library system domain requirements• Harus  ada  user  interface  standar  pada  semua  database yang  harus  mengacu  pada  standar  Z39.50 • Karena  ada  aturan  copyright,  dokument  harus  dihapus segera  setelah  di  ambil.  Tergantung  pada  kebutuhan user,  dokumen  ini  akan  di  cetak,  yang  akan  mem- forward  user  untuk  menggunakan  network  printer  di LAN Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide26Train protection system• Perlambatan  kereta  dihitung  sebagai  berikut  : D train   =  D control   +  D gradient where  D gradient  is  9.81ms 2  *  compensated gradient/alpha  and  where  the  values  of  9.81ms 2 /alpha  are  known  for  different  types  of  train. Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide27Masalah Domain requirements• Understandability – Requirement di ekspresikan dengan bahasa domain tersebut berada – Tidak dipahami oleh pengembang dari sistem • Implicitness – Domain spesialis memahami area tersebut secara detail sehingga tidak berpikir untuk membuat domain requirement lebih explicit Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide28User requirements• Harus menjelaskan fungsional dan non fungsional requirement dengan cara tertentu yang membuat pengguna sistem paham meski tidak memiliki pengetahuan bidang tersebut secara detail • User requirement didefinsikan menggunakan bahasa naturalm tabel, dan diagram yang mudah dipahami oleh semua Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide29Problems with natural language• Ketidak jelasan – Kejelasan sangat sulit tanpa harus membuat dokument sangat sulit untuk dipahami • Requirements confusion – Fungsional dan non fungsional requirement sering tercampur Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide30LIBSYS requirementSoftware Requirements - adopted & adapted from I. Sommerville, 2004 4..5   LIBSYS shall provide a financial accounting system that maintains records of all payments made by users of the system. System managers may configure this system so that regular users may receive discounted rates.

Slide31Editor grid requirementSoftware Requirements - adopted & adapted from I. Sommerville, 2004 2.6 Grid facilities  To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.

Slide32Requirement problems• Database requirement termasuk didalamnya konseptual dan informasi yang detail – Menjelaskan konsep dari accountung system yang termasuk dalam libsys – Juga termasuk didalamnya detail dari manager yang mampu mengkonfigurasi sistem yang harusnya tidak perlu pada level ini • Grid requirement mixes three different kinds of requirement – Conceptual functional requirement (the need for a grid); – Non-functional requirement (grid units); – Non-functional UI requirement (grid switching). Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide33Structured presentationSoftware Requirements - adopted & adapted from I. Sommerville, 2004

Slide34Guidelines for writing requirements• Temukan format standar dan gunakan pada semua requirement • Gunakan bahasa dengan konsisten. Gunakan ‘harus’ untuk requirement yang vital , sebaiknya untuk kebutuhan yang diinginkan • Text highlite untuk indentifikasi bagian kunci dari requrement • Hindari penggunakan jargon komputer Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide35System requirements• Spesifikasi yang lebih detail dari fungsi dan layanan sistem, juga hambatan dari user requirement • Dimaksudkan untuk menjadi dasar desain sistem • Mungkin Tergabung dalam kontrak • Sistem requirement mungkin dapat di ilustrasikan menggunakan sistem model Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide36Requirements and design• Prinsipnya, requirement harus menjabarkan apa yang sistem harus lakukan dan desain harus menjelaskan bagaimana sistem tersebut bekerja • Prakteknya, requirement dan desain tidak dapat dipisahkan – Arsitektur sistem didesain berdasar struktur dari requirement – Penggunakan desain spesifik mungkin diambil dari requirement domain Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide37Problems with NL specification• Ambiguity – The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult. • Over-flexibility – The same thing may be said in a number of different ways in the specification. • Lack of modularisation – NL structures are inadequate to structure system requirements. Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide38Alternatives to NL specificationSoftware Requirements - adopted & adapted from I. Sommerville, 2004

Slide39Structured language specifications• Kebebeasan penulis requirement dibatasi oleh template yang ditetapkan pada requirement • Semua requirement dituliskan dengan menggunakan standard • Terminologi yang digunakan dibatasi Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide40Form-based specifications• Mendefinisikan fungsi atau entitas • Deskripsi input dan darimana mereka berasal • Deskripsi output dan kemana output tersebut pergi • Efek samping ( jika ada ) pada fungsi Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide41Form-based node specificationSoftware Requirements - adopted & adapted from I. Sommerville, 2004

Slide42Tabular specification• Sebagai suplement dari NL • Berguna ketika kita mendefinisikan jumlah dari alternatif yang mungkin ada sebuah action Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide43Tabular specificationSoftware Requirements - adopted & adapted from I. Sommerville, 2004

Slide44Graphical models• Berguna ketika kita ingin menunjukkan tingkat berubahan dari beberapa actions Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide45Sequence diagrams• Menunjukkan urutan dari event yang berjalan selama user berinteraksi dengan sistme • Membaca dari atas keb awah untuk melihat urutan dari actions • Cash withdrawal dari mesin ATM – Validate card; – Handle request; – Complete transaction. Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide46Sequence diagram of ATM withdrawalSoftware Requirements - adopted & adapted from I. Sommerville, 2004

Slide47IEEE requirements standard• Defines a generic structure for a requirements document that must be instantiated for each specific system. – Introduction. – General description. – Specific requirements. – Appendices. – Index. Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide48Key points• Requirements set out what the system should do and define constraints on its operation and implementation. • Functional requirements set out services the system should provide. • Non-functional requirements constrain the system being developed or the development process. • User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams. Software Requirements - adopted & adapted from I. Sommerville, 2004

Slide49Key points• System requirements are intended to communicate the functions that the system should provide. • A software requirements document is an agreed statement of the system requirements. • The IEEE standard is a useful starting point for defining more detailed specific requirements standards. Software Requirements - adopted & adapted from I. Sommerville, 2004