Requirement Classification

Slides:



Advertisements
Presentasi serupa
CHAPTER 7 Pengembangan Sistem
Advertisements

ANALISIS SISTEM.
Tahapan information engineering
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
TIB15 - ANALISIS & DESAIN BERORIENTASI OBJEK
REKAYASA PERANGKAT LUNAK
Requirement.
Managing Software Requirements (manajemen kebutuhan perangkat lunak)
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
RENCANA PENGEMBANGAN PERANGKAT LUNAK (RPPL)
Manajemen Proyek.
Analisis Kebutuhan PERANGKAT LUNAK
THE REQUIREMENTS ANALYSIS PHASE
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 1 Slide 1 Review Software Engineering.
10 documentation.
ANALISIS DAN PERANCANGAN SISTEM (APS)
FASE PERENCANAAN MPSI – sesi 4.
METODOLOGI MANAJEMEN PROYEK
Model Proses Perangkat Lunak
SE2423 Rekayasa Perangkat Lunak
Review Rekayasa Perangkat Lunak
Analisis Perancangan Berbasis Objek
Pengelolaan Proyek Sistem Informasi
REQUIREMENT ENGINEERING Bab - 1
Engineering and Managing Software Requirements
System Development Life Cycle (SDLC)
Professional documents
Apakah “Praktek”? Praktek adalah sejumlah konsep, prinsip, metode dan tools that yang harus dimiliki ketika software direncanakan dan dikembangkan. Dia.
FASE PERENCANAAN MPSI – sesi 4.
FASE INISIALISASI MPSI sesi 3.
Pengumpulan Kebutuhan dan Dokumentasi
Anna dara andriana., M.kom
FASE INISIALISASI MPSI sesi 3.
Rekayasa Perangkat Lunak
Pertemuan 03 Materi : Buku Wajib & Sumber Materi :
4 Managing Software Requirement Analisis Kebutuhan
SE2423 Rekayasa Perangkat Lunak
SISTEM INFORMASI PEMASARAN
MANPRO-M13: MUTU PROYEK SISTEM
Pendahuluan Software Requirement Engineering (SRE)
Teknik Informatika S1 Rekayasa Perangkat Lunak Requirement Engineering
Persyaratan Rekayasa Proses
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS
Rekayasa Perangkat Lunak Dosen : Citra Noviyasari, S.Si, MT
R.S. Pressman & Associates, Inc
Software Engineering by Pressman
Disusun Oleh: Defri Kurniawan, M.Kom Teknik Informatika UDINUS
Metode Pengembangan Arsitektur
Rekayasa Kebutuhan Software
Analisis Kebutuhan.
FASE ANALISIS.
Anna dara andriana., M.kom
Materi Rekayasa Perangkat Lunak
FASE INISIALISASI MPSI sesi 3.
REKAYASA PERANGKAT LUNAK
Review Rekayasa Perangkat Lunak
Analisa [Kebutuhan] Sistem
Membangun Sistem Informasi ERP
Membangun Sistem Informasi ERP
Review Rekayasa Perangkat Lunak
Information System Analysis and Design
Review Rekayasa Perangkat Lunak
Hanya digunakan di lingkungan Universtias
REQUIREMENT ENGINEERING
Analisis Persyaratan Perangkat Lunak dan Spesifikasi
FASE INISIALISASI MPSI sesi 3.
Framework TOGAF SI402 Arsitektur Enterprise Pertemuan #9
FASE INISIALISASI MPSI sesi 3.
Manajemen Proyek.
Transcript presentasi:

Requirement Classification Teknik Informatika S1 - UDINUS Defri Kurniawan, M.Kom

Materi-materi SRE No Materi 1 Pendahuluan dan Kontrak Kuliah SRE 2 Requirement Classification 3 Requirement Elicitation 4 Specification of Requirement Models 5 Requirement Prioritization 6 Requirement Interdependencies 7 Impact Analysis 8 Requirement Negotiation 9 Quality Assurance

Requirement Classification Content Konten: Review: Requirement & Requirement Engineering Requirement Classification Waktu Pemodelan Kebutuhan Skenario Dasar Requirement Engineering Peran Stakeholders Dalam Requirement Engineering Perbedaan Levels Dalam kebutuhan Mengelola kebutuhan

Refrensi Aybuke Aurum, Claes Wohlin (Eds.), “Engineering and Managing Software Requirements”, Springer

What’s Requirement All projects begin with a statement of requirements. Requirements are descriptions of how a software product should perform.

What’s requirement Definition by IEEE 610.12-1990 Standard A condition or capability needed by a user to solve a problem or achieve an objective A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents, A documented representation of a condition or capability as in (1) or (2).

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)

What’s Requirement “Sesuatu pada produk yang harus dilakukan atau sebuah kualitas yang harus dimiliki produk tersebut” (Robertson99). “Sebuah spesifikasi kebutuhan adalah bagaimana tujuan harus sesuai dengan sistem yang diusulkan” (Anton96).

What’s Requirement Engineering Proses dimana persyaratan untuk produk perangkat lunak dikumpulkan, dianalisis, didokumentasikan, dan dikelola di seluruh siklus hidup rekayasa perangkat lunak

Requirement Classification Functional versus Non Functional Requirements

Requirement Classification 1. Kebutuhan Fungsional Menunjukkan What the system should do. Menunjukkan fasilitas apa yang dibutuhkan serta aktivitas apa saja yang terjadi dalam sistem baru.

Requirement Classification 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 Classification 1. Kebutuhan Fungsional Contoh: pada sistem informasi akademik Mahasiswa dapat melakukan input KRS.

Requirement Classification 2. Kebutuhan Non Fungsional Kebutuhan Non fungsional merupakan batasan pada jenis solusi yang akan memenuhi kebutuhan fungsional mencakup: akurasi, kinerja, keamanan dan modifiability.

Requirement Classification 2. 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 Classification Goal, Domain, Product, Design Level Requirements

Requirement Classification 1. Goal level requirements Goal level requirements – related to business goals Contoh: Dalam pembuatan website perusahaan ditambahkan requirement untuk promosi produk mereka, seperti mengirimkan email promosi otomatis ke member (Subscribe system).

Requirement Classification 2. Domain level requirements Domain level requirements – related to problem area Contoh: Misalkan domain kesehatan dan pendidikan akan berbeda kebutuhannya.

Requirement Classification 3. Product level requirements Product level requirements – related to the product Contoh: software yang dibuat harus compatible semua platform seperti windows, linux, unix, dll..

Requirement Classification 4. Design level requirements Design level requirements – what to build Contoh: Design tampilan harus bisa dimengerti user awam (novice user).

Requirement Classification Primary Requirements versus Derived Requirements

Requirement Classification 1. Primary requirements Primary requirements – elicited from stakeholders Requirements yang didapatkan langsung dari client / pihak yang berkepentingan.

Requirement Classification 2. Derived requirements Derived requirements – derived from primary requirements Diperoleh dari kebutuhan primer sebelumnya, biasanya bersifat turunan/ tambahan secara detail dari kebutuhan primer yang ada

Requirement Classification Product Requirements versus Process Requirements

Requirement Classification Product requirements VS Process requirements Product requirements: Business need Process requirements: How people will interact with the system

Requirement Classification Other Classifications, e.g. Role based requirements Contoh: Customer requirements, IT requirements, system requirements, and security requirements

Requirement Classification

Requirement Engineering Process Requirements engineering melibatkan semua siklus hidup aktivitas yang berhubungan dengan kebutuhan. Meliputi: Gathering  Mengumpulkan data kebutuhan Documenting  Dokumentasi Managing requirements  Mengatur/ mengelola kebutuhan yang sudah dikumpulkan

Kapan kita memodelkan kebutuhan?

Waktu Pemodelan Kebutuhan

Skenario Dasar Requirement Engineering Setiap aktor mempunyai perspektif/ pandangan yang berbeda bagaimana menggunakan sistem

Skenario Dasar Requirement Engineering Menggambarkan bagaimana setiap aktor harus seperti apa berinteraksi dengan sistem

Peran Stakeholders Dalam Requirement Engineering Pada intinya, requirement engineering bertujuan untuk mengubah segala potensi yang tidak lengkap, tidak konsisten dan konflik tujuan dari stakeholder ke dalam sekumpulan kebutuhan yang berkualitas tinggi yang lengkap

Peran Stakeholders Dalam Requirement Engineering Typical stakeholders Product Managers, termasuk user dan administrator dari sisi klien. Software team members dari sisi pembuat software.

Requirement Engineering Salah satu masalah utama dalam Requirement Engineering adalah mengelola berbagai jenis inkonsistensi yang dihasilkan dari requirements elicitation, modeling, specification, and prioritization activities.

Requirement 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.

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

Different Levels of Requirement Tim Management Senior dalam organisasi mungkin mempunyai tujuan yang strategis dan tujuan jangka panjang Tujuan dan strategi dalam level organisasi mempunyai dampak yang tidak bisa dianggap enteng yang berpengaruh kepada produk organisasi yang seharusnya dibangun

Different Levels of Requirement Kebutuhan dalam produk perangkat lunak harus disesuaikan dengan tujuan bisnis dari pembangunan perangkat lunak organisasi Bagaimana menyeimbangkan kepentingan customer dan kepentingan developer? Product management harus memastikan bahwa kebutuhan sesuai dengan tujuan dari produk tersebut

Different Levels of Requirement Kebutuhan di level produk harus dikemas ke dalam bagian yang spesifik dari proyek atau rilis software tersebut. Kebutuhan di level projek meliputi perencanaan, manajemen resiko, anggaran belanja, dan biaya.

Requirements Management Requirements Elicitation, Specification and Modeling Prioritization Requirements Dependencies and Impact Analysis Requirements Negotiation Quality Assurance

Requirements Management 1. Requirements Elicitation, Specification and Modeling Ini melibatkan memahami kebutuhan para pemangku kepentingan, memunculkan kebutuhan, pemodelan dan mengumpulkan mereka dalam repositori.

Requirements Management 2. Prioritization Kegiatan ini membantu manajer proyek dengan menyelesaikan konflik (dimana 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.

New Trends in Requirements Engineering Perbaikan teknologi di pasar global berkaitan erat dengan lingkungan bisnis. Konsep baru seperti Enterprise Systems, E-Business dan Telecommunications telah menyebabkan tren baru dalam penelitian bagi para peneliti dan praktisi.

New Trends in Requirements Engineering Trend baru menyebabkan perubahan pada: Ketrampilan yang dibutuhkan Teknologi yang digunakan Requirement engineering bukan lagi pekerjaan front-end (tradisional) pada siklus pengembangan PL

TERIMA KASIH

TUGAS INDIVIDU Presentasikan salah satu teknik requirement elicitation Deskripsikan dan beri contoh teknik requirement elicitation yang dipilih tersebut di pertemuan ke-3 dan ke-4 Waktu presentasi 5-10 menit (1 pertemuan 10 orang) Cantumkan referensi/ daftar pustaka Urutan maju dan pemilihan teknik random Kirimkan file presentasi (ppt) ke email defri.kurniawan@dsn.dinus.ac.id paling lambat hari Selasa, tanggal 14 Maret 2017 jam 23:58 wib

TUGAS KELOMPOK 1. Questionnaires 2. Task Analysis 3. Domain Analysis 4. Introspection 5. Repertory Grids 6. Card Sorting 7. Laddering 8. Group Work 9. Brainstorming 10. Joint Application Development 11. Requirements Workshops 12. Ethnography 13. Observation 14. Protocol Analysis 15. Apprenticing 16. Prototyping 17. Goal Based Approach 18. Scenarios 19. Viewpoints 20. Interviews