Teknik Informatika S1 Software Requirement Engineering Requirement Classification
Disusun Oleh: Egia Rosi Subhiyakto, M.Kom, M.CS Teknik Informatika UDINUS
[email protected] +6285740278021
SILABUS MATA KULIAH 1. Requirement Engineering 2. Requirement Elicitation 3. Specification of Requirement Models 4. Requirement Prioritization 5. Requirement Interdependencies: State of the Art and Future 6. Impact Analysis 7. Requirement Negotiation 8. Quality Assurance in Requirement Engineering
SOFTWARE REQUIREMENT ENGINEERING 1. Requirement Classification
2. Kapan kita memodelkan kebutuhan? 3. Skenario dasar Requirement Engineering 4. Peran Stakeholders dalam Requirement Engineering 5. Perbedaan Levels dalam kebutuhan
6. Mengelola kebutuhan
Pengertian Requirement A condition or capability needed by a user to solve a problem or achieve an objective.
IEEE 610.12-1990 Standard
Pengertian Requirement A condition or capability needed by a user to solve a
problem or achieve an objective.
Kondisi atau kapabilitas yang dibutuhkan oleh pengguna untuk menyelesaikan masalah atau mendapatkan tujuan
IEEE 610.12-1990 Standard
Pengertian Requirement Engineering “Requirement
Engineering
adalah
Proses
dimana
persyaratan untuk produk perangkat lunak dikumpulkan, dianalisis, didokumentasikan, dan dikelola di seluruh siklus hidup rekayasa perangkat lunak”.
Requirement Classifications
Functional versus Non Functional
Requirement Classifications Functional versus Non Functional 1.
Kebutuhan fungsional Menunjukkan What the system should do.
Menunjukkan fasilitas apa yang dibutuhkan serta
aktivitas apa saja yang terjadi dalam sistem baru.
Requirement Classifications Functional versus Non Functional 1.
Kebutuhan fungsional Kebutuhan fungsional mencakup: * Fungsi deskripsi kebutuhan * Laporan baik hardcopy maupun softcopy * Updating dan query online * Penyimpanan data, pencarian kembali dan transfer data
Requirement Classifications Functional versus Non Functional 1. Kebutuhan fungsional
Contoh: dalam sistem informasi akademik
Mahasiswa dapat melakukan input KRS
Requirement Classifications Functional versus Non Functional 1.
Kebutuhan Non fungsional Kebutuhan yang mencakup: * Waktu respon * Rata-rata waktu untuk kegagalan * Kebutuhan keamanan * Akses untuk pengguna yang tidak punya hak
Requirement Classifications Functional versus Non Functional 1. Kebutuhan Non fungsional Contoh: Website harus easy to access, easy to use, easy to understand dan menjamin keamanan data member dari orang yang tidak bertanggungjawab.
Requirement Classifications Functional versus Non Functional
Functional Requirements What the system should do
Non functional Requirements Constraints on the types of
solutions that will meet the functional requirements e.g. Accuracy, Performance, Security, and Modifiability
Requirement Classifications Primary requirements – elicited from stakeholders
Requirement Classifications Primary requirements – elicited from stakeholders
Requirements yang didapatkan langsung dari client/ pihak yang berkepentingan.
Requirement Classifications Derived requirements – derived from primary requirements
Requirement Classifications Derived requirements – derived from primary requirements
Diperoleh dari kebutuhan primer sebelumnya, biasanya bersifat turunan/ tambahan secara detail dari kebutuhan primer yang ada
Requirement Classifications Other Classifications, e.g.
Role based requirements
Contoh: Customer requirements, IT requirements, system
requirements, and security requirements
Requirement Engineering Process Requirements engineering melibatkan semua siklus hiduo
aktivitas yang berhubungan dengan kebutuhan.
Meliputi: Gathering Mengumpulkan data kebutuhan
Documenting Dokumentasi Managing
requirements
Mengatur/
kebutuhan yang sudah dikumpulkan
memanage
Skenario dasar Requirement Engineering The “User” point of view Actor C
Requirements Collection
Actor A
Actor B
Setiap aktor mempunyai perspektif/ pandangan yang berbeda bagaimana menggunakan sistem
Skenario dasar Requirement Engineering
Actor C
The “User” point of view System
Requirements Collection
Actor A
Scenario 1
Actor B
Setiap aktor mempunyai perspektif/ pandangan yang berbeda bagaimana menggunakan sistem
Actor A
Scenario Actor B
Menggambarkan bagaimana setiap aktor harus seperti apa berinteraksi dengan sistem
Peran Stakeholders dalam Requirement Engineering In essence, requirements engineering aims to transform potentially
incomplete,
inconsistent
and
conflicting
stakeholder goals into a complete set of high quality
requirements.
Typical stakeholders Product Managers, Termasuk user dan administrator dari sisi klien.
Software team members dari sisi pembuat software.
Requirements Engineering Salah
satu
masalah
Engineering
adalah
inkonsistensi
yang
utama
dalam
mengelola dihasilkan
Requirement
berbagai dari
jenis
requirements
elicitation, modeling, specification, and prioritization activities.
Requirements Engineering Inkonsistensi menjadi sangat jelas ketika ada beberapa pemangku kepentingan dan sudut pandang
Karena
para
pemangku
kepentingan
yang
berbeda
memiliki berbagai cara untuk mengekspresikan diri mereka dan pendapat yang berbeda serta memiliki
prioritas.
Requirements Engineering Keberhasilan proyek rekayasa kebutuhan tergantung pada
analisis
yang
akurat
dari
perspektif
untuk
ketidaklengkapan dan inkonsistensi.
Kebutuhan perlu dinegosiasikan dan divalidasi sebelum mereka didokumentasikan dan pengembang berkomitmen
untuk menerapkannya
Different Levels of Requirements Strategic Management
Tactical Management
Operational Management
Requirements at organizational level
*Business strategy *Competitiveness *Technology * Marketing *Economic value of the product
* Planned benefits of the product
* Tradeoff between technology-push and market-pull
Requirements at product level
* Packaging requirements for a specific release * Product architectures
* Resource management *Implementation of a specific release
*Change management * Requirements volatility e.g. whether a particular requirement is subject to a syntactic or semantic change
Requirements at project level
*Project planning *Feasibility study *Recruiting people
* Project *Validation in terms of management which requirements * Quality control will go to the next release
Requirements Management 1. Requirements Elicitation, Specification and Modeling 2. Prioritization 3. Requirements Dependencies and Impact Analysis
4. Requirements Negotiation 5. Quality Assurance
Requirements Management Requirements Elicitation, Specification and Modeling
Ini
melibatkan
kepentingan,
memahami
memunculkan
kebutuhan
kebutuhan,
mengumpulkan mereka dalam repositori.
para
pemangku
pemodelan
dan
Requirements Management 2. Prioritization
Kegiatan
ini
menyelesaikan
membantu
konflik
manajer
(di
mana
proyek
dengan
pelanggan
dan
pengembang berkolaborasi pada prioritas kebutuhan), rencana pengiriman bertahap, dan membuat keputusan
yang diperlukan.
Requirements Management 3. Requirements Dependencies and Impact Analysis
Hal ini penting untuk mengakui bahwa perubahan kebutuhan dan ini secara signifikan dapat mempengaruhi proyek software.
Requirements Management 4. Requirements Negotiation Rekayasa kebutuhan dasarnya adalah komunikasi dan proses
negosiasi kompleks yang melibatkan pelanggan, desainer, manajer proyek dan pengelola. Orang-orang, atau pemangku kepentingan, yang terlibat dalam proses bertanggung jawab untuk memutuskan apa yang harus dilakukan, kapan melakukannya, informasi apa
yang dibutuhkan, dan apa alat yang perlu digunakan.
Requirements Management 5. Quality Assurance
Tujuannya adalah untuk memastikan bahwa kebutuhan kualitas tinggi dicatat dalam dokumen spesifikasi.
Tujuan dari jaminan kualitas adalah untuk menetapkan tingkat yang wajar dan realistis saat menyusun dan
mengelola persyaratan.
TERIMA KASIH
