Software Requirements

Software Requirements
Software Requirements - adopted & adapted from I. Sommerville, 2004

Software Requirements - adopted & adapted from I. Sommerville, 2004
Tujuan 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

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

Rekayasa 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

Apa 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

Requirements abstraction (Davis)

Tipe 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

Pembaca Requirements Software Requirements - adopted & adapted from I. Sommerville, 2004

Definisi dan spesifikasi

Requirement 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

Kebutuhan 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

The 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

Contoh 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

Ketidak 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

Kelengkapan dan konsistensi requirement
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 Dalam kenyataan, untuk projek berukuran besar dan kompleks, tidak mungkin kelengkapan dan konsistensi tercapai sepeuhnya Salah satu penyebabnya adalah kesalahan dalam menulis persyaratan untuk projek besar dan kompleks mudah sekali terjadi. Sebab lainnya adalah pemangku kepentingan (stakeholders) yang berbeda dapat memiliki kebutuhan yang berbeda, atau bahkan bertentangan satu sama lain Software Requirements - adopted & adapted from I. Sommerville, 2004

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

Klasifikasi 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

Tipe Non-functional requirement

Contoh 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

Goals 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

Contoh 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

Pengukuran kebutuhan Software Requirements - adopted & adapted from I. Sommerville, 2004

Interaksi 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

Domain 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

Library 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

Train protection system
Perlambatan kereta dihitung sebagai berikut : Dtrain = Dcontrol + Dgradient where Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of 9.81ms2 /alpha are known for different types of train. Software Requirements - adopted & adapted from I. Sommerville, 2004

Masalah 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

User 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

Problems 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

LIBSYS requirement 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. Software Requirements - adopted & adapted from I. Sommerville, 2004

Editor grid requirement
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. Software Requirements - adopted & adapted from I. Sommerville, 2004

Requirement 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

Structured presentation

Guidelines 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

System 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

Requirements 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

Problems 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

Alternatives to NL specification

Structured 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

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

Form-based node specification

Tabular 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

Tabular specification

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

Sequence 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

Sequence diagram of ATM withdrawal

IEEE 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

Key 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

Key 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

Software Requirements

Presentasi serupa

Presentasi berjudul: "Software Requirements"— Transcript presentasi:

Presentasi serupa

Tentang proyek

Tanggapan

Masuk

Otorisasi melalui jaringan sosial:

Software Requirements

Presentasi serupa

Presentasi berjudul: "Software Requirements"— Transcript presentasi:

Presentasi serupa

Tentang proyek

Tanggapan