REQUIREMENT ENGINEERING REKAYASA PERANGKAT LUNAK LANJUT REQUIREMENT ENGINEERING Defri Kurniawan M.Kom

What’s Requirement? All project begin with a statement of requirements. Requirements are descriptions of how a software product should perform. “Sebuah spesifikasi kebutuhan adalah bagaimana tujuan harus sesuai dengan sistem yang diusulkan” (Anton96).

Definition by IEEE 610.12-1990 Standard What’s Requirement? Definition by IEEE 610.12-1990 Standard Suatu kondisi atau kemampuan yang dibutuhkan oleh seorang pengguna untuk memecahkan suatu masalah atau mencapai suatu tujuan Suatu kondisi atau kemampuan yang harus dipenuhi atau dimiliki oleh komponen sistem untuk memenuhi kontrak, standar, spesifikasi, atau dokumen resmi yang dikenakan lainnya, Suatu presentasi yang terdokumenkan dari suatu kondisi atau kemampuan sebagaimana pada poin (1) dan (2)

Requirement Engineering Requirements engineering adalah fase terdepan dari proses rekayasa perangkat lunak (software engineering), dimana software requirements (kebutuhan) dari user (pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan ditetapkan. Requirement Engineering berkaitan dengan menafsirkan dan memahami tujuan, kebutuhan, dan keyakinan dari pihak yang berkepentingan

Requirement Engineering Kebanyakan kegagalan pengembangan software disebabkan karena adanya: Ketidakkonsistenan (inconsistent), Ketidaklengkapan (incomplete), maupun Ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan)

Requirement Engineering Studi di The Standish Group mencatat bahwa prosentase akumulatif kegagalan sebuah proyek pengembangan software sebagian besar disebabkan oleh masalah requirements dan spesifikasinya [Standish-94].

Requirements Engineering Task Tugas-tugas yang dilakukan pada requirements engineering meluputi: Inception Elicitation Elaboration Negotiation Spesification and Validation

Requirements Engineering Task (lanj) Requirements engineering dimulai dengan: Inception yang mendefinisikan lingkup / scope dan sifat masalah yang akan dipecahkan. Elicitation yang membantu para pemangku kepentingan menentukan apa yang dibutuhkan. Elaboration dimana persyaratan dasar disempurnakan dan dimodifikasi. Negotiation dengan stakeholder dalam mendefinisikan masalah, apa yang menjadi prioritas, apa yang penting, kapan itu diperlukan?

Requirements Engineering Task (lanj) Akhirnya, masalah ditentukan (spesification) dalam beberapa cara dan kemudian ditinjau dan dievaluasi untuk memastikan (validation) bahwa pemahaman Anda tentang masalah dan pemahaman para pemangku kepentingan dari masalah sama

Inception Pada Inception project, kita membangun pemahaman dasar dari masalah, orang-orang yang menginginkan suatu solusi, sifat dari solusi yang diinginkan dan efektivitas komunikasi awal dan kolaborasi antara stakeholder lainnya dan tim software

Elicitation Adalah proses mengumpulkan dan memahami requirements dari user. Kadang masalah yang muncul berakar dari gap masalah knowledge domain (perbedaan disiplin ilmu yang dimiliki). Customer adalah expert pada domain yang software-nya ingin dikembangkan (domain specialist), di lain pihak sang pengembang (requirements analyst) adakalanya sama sekali buta terhadap knowledge domain tersebut Gap knowledge domain tersebut yang diharapkan bisa diatasi dengan adanya interaksi terus menerus dan berulang (iterasi) antara pengembang dan customer

Elaboration Informasi yang diperoleh dari pelanggan selama inception dan elictitation diperluas dan disempurnakan selama elaborasi. Tugas Elaboration berfokus pada pengembangan persyaratan model yang halus yang mengidentifikasi berbagai aspek fungsi software, perilaku, dan informasi.

Negotiation Adakalanya pelanggan dan pengguna meminta lebih dari yang bisa dicapai Pelanggan yang berbeda atau pengguna mengusulkan persyaratan yang bertentangan Negosiasi diperlukan untuk mendamaikan konflik Pelanggan, pengguna, pemangku kepentingan diminta untuk memperingkat persyaratan dan kemudian mendiskusikan konflik dalam prioritas

Specification Dalam konteks sistem berbasis komputer (dan perangkat lunak), term specification berarti hal yang berbeda untuk orang yang berbeda. Sebuah spesifikasi dapat menjadi dokumen tertulis, suatu kumpulan model grafis, model matematika formal, koleksi skenario penggunaan, prototipe, atau kombinasi dari ini.

Specification Setelah masalah berhasil dipahami, pengembang mendeskripsikannya dalam bentuk dokumen spesifikasi. Spesifikasi ini berisi tentang fitur dan fungsi yang diinginkan oleh customer, dan sama sekali tidak membahas bagaimana metode pengembangannya. IEEE mengeluarkan standard untuk dokumen spesifikasi requirements yang terkenal dengan nama IEEE Recommended Practice for Software Requirements Specifications [IEEE-830].

Validation Persyaratan validasi memeriksa spesifikasi untuk memastikan bahwa semua persyaratan perangkat lunak telah dinyatakan jelas; bahwa inkonsistensi, kelalaian, dan kesalahan telah terdeteksi dan dikoreksi; dan bahwa produk kerja sesuai dengan standar yang ditetapkan untuk proses, proyek, dan produk

Kenapa Requirement Engineering dibutuhkan? Requirements yang lemah/ tidak lengkap adalah sumber utama dari kegagalan (Standish95) 8000 projects, 350 US companies: 1/3 dari projek tidak pernah selesai dan 50% berhasil hanya sebagian

Kenapa Requirement Engineering dibutuhkan? Banyaknya masalah yang dirasakan terkait dengan spesifikasi kebutuhan (>50%) – (ESI96) 3800 organisasi di 17 negara eropa

Kenapa Requirement Engineering dibutuhkan? “Kebutuhan yang tidak mencukupi, tidak konsisten, tidak lengkap atau ambigu mempunyai dampak yang kritis terhadap kualitas hasil perangkat lunak tersebut” (Bell&Tayer76)

Kenapa Requirement Engineering dibutuhkan? “Keterlambatan koreksi dari kesalahan meningkatkan biaya sampai 200 kali lebih banyak selama proses requirement engineering” (Boehm81)

Types of Requirement User requirements System requirements Pernyataan dalam bahasa natural ditambah diagram dari layanan sistem yang sediakan dan kendala operasional. Ditulis untuk pelanggan. System requirements Sebuah dokumen terstruktur menetapkan deskripsi rinci dari fungsi sistem, layanan dan kendala operasional. Mendefinisikan apa yang harus dilaksanakan sehingga dapat menjadi bagian dari kontrak antara klien dan kontraktor * Software Engineering 7th ed, Ian Sommerville

Definitions and Specifications * Software Engineering 7th ed, Ian Sommerville

User Requirements Harus menjelaskan persyaratan fungsional dan non-fungsional sedemikian rupa bahwa mereka dimengerti oleh pengguna sistem yang tidak memiliki pengetahuan teknis rinci. Kebutuhan pengguna didefinisikan menggunakan bahasa alami, tabel dan diagram seperti ini dapat dipahami oleh semua pengguna. * Software Engineering 7th ed, Ian Sommerville

Problems with natural language Lack of clarity (kurang kejelasan) Presisi sulit tanpa membuat dokumen yang sulit untuk dibaca Requirements confusion (persyaratan membingungkan) Kebutuhan fungsional dan non-fungsional cenderung dicampur Requirements amalgamation (penggabungan persyaratan) Beberapa kebutuhan yang berbeda dinyatakan bersama-sama * Software Engineering 7th ed, Ian Sommerville

System Requirements Spesifikasi lebih rinci dari fungsi sistem, layanan dan batasan dibandingkan dengan user requirement System requirements dimaksudkan untuk menjadi dasar untuk merancang sistem. System requirements dapat dimasukkan ke dalam sistem kontrak System requirements dapat didefinisikan atau digambarkan menggunakan model sistem * Software Engineering 7th ed, Ian Sommerville

Functional and Non-Functional Requirements Functional Requirement (persyaratan fungsional) “Functional requirements define what the system or application will do” Non-functional Requirement (persyaratan non fungsional) “A software requirement that describes not what the software will do, but how the software will do it, for example software performance requirements, software external interface requirements, design constraints, and software quality attributes” IEEE Definition

Functional Requirements Describe functionality or system services. Depend on the type of software, expected users and the type of system where the software is used. Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail. Contoh: pada sistem informasi akademik Mahasiswa dapat melakukan input KRS. * Software Engineering 7th ed, Ian Sommerville

Non Functional Requirement (NFR) Persyaratan perangkat lunak yang menggambarkan bagaimana perangkat lunak akan melakukannya, misalnya, persyaratan kinerja perangkat lunak, persyaratan antarmuka eksternal perangkat lunak, dan atribut kualitas perangkat lunak. Persyaratan nonfungsional sulit untuk diuji oleh karena itu, mereka biasanya dievaluasi secara subyektif

Non-functional Requirements Examples Product requirement 8.1 The user interface for LIBSYS shall be implemented as simple HTML without frames or Java applets. Organisational requirement 9.3.2 The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95. External requirement 7.6.5 Sistem tidak akan mengungkapkan informasi pribadi apapun tentang pelanggan selain dari nama dan nomor referensi mereka kepada operator sistem. * Software Engineering 7th ed, Ian Sommerville

Requirements Measures * Software Engineering 7th ed, Ian Sommerville

Domain Requirements Persyaratan yang berasal dari domain aplikasi dari sistem dan yang mencerminkan karakteristik domain tersebut. Misalkan domain kesehatan dan pendidikan akan berbeda kebutuhannya * Software Engineering 7th ed, Ian Sommerville

Domain Requirements Berasal dari domain aplikasi dan menggambarkan karakteristik sistem dan fitur yang mencerminkan domain. Persyaratan domain menjadi persyaratan fungsional baru, kendala pada kebutuhan yang ada atau mendefinisikan komputasi tertentu. Jika persyaratan domain tidak puas, sistem mungkin tidak bisa dijalankan. * Software Engineering 7th ed, Ian Sommerville

Domain Requirements Problems Understandability Persyaratan disajikan dalam bahasa domain aplikasi Hal ini sering tidak dipahami oleh para insinyur perangkat lunak mengembangkan system Implicitness Spesialis domain memahami daerah baik sehingga mereka tidak berpikir untuk membuat persyaratan domain eksplisit. * Software Engineering 7th ed, Ian Sommerville

Requirements Completeness and Consistency Pada prinsipnya, persyaratan seharusnya lengkap dan konsisten. Complete Mereka harus mencakup deskripsi dari semua fasilitas yang diperlukan Consistent Seharusnya tidak ada konflik dan kontradiksi dalam deskripsi dari fasilitas sistem. * Software Engineering 7th ed, Ian Sommerville

Guidelines for Writing Requirements Menciptakan sebuah format standar dan menggunakannya untuk semua kebutuhan. Menggunakan bahasa dengan cara yang konsisten. Gunakan untuk persyaratan wajib, harus untuk kebutuhan yang diinginkan. Gunakan penyorotan teks untuk mengidentifikasi bagian penting dari kebutuhan. Hindari penggunaan jargon komputer. * Software Engineering 7th ed, Ian Sommerville

Problems with NL specification Ambiguity Pembaca dan penulis kebutuhan requirement harus menafsirkan kata-kata yang sama dengan cara yang sama. NL secara alami ambigu jadi ini sangat sulit. Over-flexibility Hal yang sama dapat dikatakan dalam sejumlah cara yang berbeda dalam spesifikasi Lack of modularisation Struktur NL tidak memadai untuk struktur persyaratan sistem * Software Engineering 7th ed, Ian Sommerville

Alternatives to NL specification * Software Engineering 7th ed, Ian Sommerville

The Requirements Document Dokumen persyaratan adalah pernyataan resmi dari apa yang dibutuhkan dari para pengembang sistem. Harus mencakup baik definisi dari kebutuhan pengguna dan spesifikasi persyaratan sistem. Hal ini bukan dokumen desain. Sejauh mungkin, harus mengatur APA yang sistem harus lakukan daripada CARA melakukannya * Software Engineering 7th ed, Ian Sommerville

Users of a Requirements Document * Software Engineering 7th ed, Ian Sommerville

IEEE Requirements Standard Mendefinisikan struktur generik untuk dokumen persyaratan yang harus dipakai untuk setiap sistem tertentu. Introduction. General description. Specific requirements. Appendices. Index. * Software Engineering 7th ed, Ian Sommerville

SRS Template