Pengertian Requirement

2.1 Pengertian Requirement

Defini Requirement Menurut (Dorf, 1990) yaitu : Sebuah requirement yakni sebuah kemampuan yang harus dimiliki dari suatu software. Kemampuan ini sanggup ditujukan untuk memecahkan suatu permasalahan ataupun diharapkan untuk memenuhi ketentuan-ketentuan tertentu (seperti standar tertentu, keputusan manajemen, ataupun alasan-alasan politis).

Kumpulan dari aneka macam requirement dipakai dalam aneka macam aspek dalam pengembangan sebuah sistem. Dalam tahap perancangan, requirement dipakai untuk menentukan aneka macam fitur yang akan ada di dalam sistem. Pada penghujung sebuah development effort, himpunan requirement ini dipakai untuk melaksanakan validation & verification untuk memastikan perangkat lunak yang telah dibentuk memang sesuai dengan yang diinginkan. Bahkan selagi pengembangan berjalan, himpunan requirement ini terus dimodifikasi untuk menyesuaikannya dengan aneka macam kebutuhan para stakeholder serta tenggat waktu dan dana yang tersedia. Secara luas, software systems requirements engineering (RE) yakni proses untuk menemukan suatu himpunan requirement yang tepat sehingga suatu perangkat lunak sanggup memenuhi kegunaannya. Proses ini dilakukan dengan cara mengenali para stakeholder serta kebutuhan mereka serta mendokumentasikannya di dalam bentuk yang sanggup dipakai untuk analisa, komunikasi, dan implementasi yang mengikutinya (Nuse,2000).

Definisi dari requirement (Zave, 1997) yakni citra dari layanan (services) dan batasan bagi sistem yang akan dibangun. Atau requirement yakni pernyataan/gambaran pelayanan yang disediakan oleh sistem, batasan-batasan dari sistem dan bisa juga berupa definisi matematis fungsi-fungsi sistem. 

Proses menemukan, menganalisis, mendokumentasikan dan pengujian layanan-layanan dan batasan tersebut disebut Requirement Engineering.

Requirement berfungsi ganda yaitu:

• Menjadi dasar penawaran suatu kontrak : harus terbuka untuk masukan.
• Menjadi dasar kontrak : harus didefinisikan secara detil.

2.2 Metode Pengumpulan Requirement

Pengumpulan requirement bertujuan untuk melaksanakan survey terhadap impian pemakai dan menjelaskan sistem informasi yang ideal. 

Ada 7 metode pengumpulan requirement, yaitu : 

Tanya jawab (interviews)

1. Bagaimana metode itu dipakai :

• Pemilihan potential interviewees.
• Membuat perjanjian terhadap potential interviewees.
• Menyiapkan struktur pertanyaan yang lengkap dan jelas.
• Memilih orang yang diinterview secara langsung dan merekamnya.

2. Keuntungan metode :

• Pewawancara sanggup mengukur respon melalui pertanyaan dan menyesuaikannya sesuai situasi yang terjadi.
• Baik untuk permasalahan yang tidak terstruktur.
• Menunjukkan kesan interviewer secara pribadi.
• Memunculkan respons yang tinggi semenjak penyusunan pertemuan.

3. Kerugian metode :

• Membutuhkan waktu dan biaya yang tidak sedikit.
• Membutuhkan pembinaan dan pengalaman khusus dari pewawancara.
• Sulit membandingkan laporan wawancara alasannya yakni subyektivitas alamiah.

Kuesioner

1. Bagaimana metode ini dilakukan : 

• Mendeain dengan memakai standar kuesioner.
• Kuesioner dikirimkan ke lingkungan kerja end-users.
• Struktur respon diringkas dalam statistik distribusi.

2. Keuntungan metode :

• Murah dan cepat dari pada interview.
• Tidak membutuhkan investigator yang terlatih (hanya satu hebat yang dibutuhkan untuk mendesain kuesioner untuk end-user yang terpilih).
• Mudah untuk mensintesis hasil semenjak pembuatan kuesioner.
• Dapat meminimalkan biaya untuk semua end-user.

3. Kerugian metode : 

• Tidak sanggup membuat pertanyaan yang spesifik bagi end-user.
• Analis melibatkan kesan sehingga tidak sanggup menampakkan pribadi 
• end-user.
• Tanggapan yang rendah alasannya yakni tidak adanya dorongan yang besar lengan berkuasa untuk 
• mengembalikan kuesioner.
• Tidak sanggup menyesuaikan pertanyaan ke end-user secara spesifik.

Observasi

1. Bagaimana metode itu dipakai :

• Secara langsung seorang analis mengunjungi lokasi pengamatan.
• Analis merekam kejadian dalam lokasi pengamatan, termasuk volumen dan pengolahan lembar kerja.

2. Keuntungan metode :

• Mendapatkan fakta records daripada pendapat (opinion).
• Tidak membutuhkan konstruksi pertanyaan.
• Tidak menganggu atau menyembunyikan sesuatu (end-users tidak mengetahui bahwa mereka sedang diamati).
• Analis tidak bergantung pada klarifikasi verbal dari end-users.

3. Kerugian metode :

• Jika terlihat, analis mungkin mengubah operasi (end-user merasa diamati).
• Dalam jangka panjang, fakta yang diperoleh dalam satu observasi mungkin tidak tepat (representative) dalam kondisi harian atau mingguan.
• Membutuhkan pengalaman dan kehlian khusus dari analis.

Prosedur analisis

1. Bagaimana metode itu dipakai :

1. Dengan mekanisme operasi sanggup mempelajari dan mengidentifikasikan pedoman dokumen kunci melalui sistem informasi, yaitu dengan data flow diagram (DFD).
2. Setiap pedoman dokumen kunci menjelaskan mekanisme operasi sistem.
3. Melalui observasi, analis mempelajari kenyataan daripada mendeskripsikan volume distribusi (tinggi, rendah, sedang) dan apa yang selanjutnya dikerjakan terhadap salinan dari dokumen aslinya.

2. Keuntungan metode : 

• Evaluasi mekanisme sanggup dikerjakan dengan campur tangan (interferences) yang minimal dan tidak menghipnotis operasi pemakai.
• Prosedur pedoman sanggup dapat menjadi sebuah struktur checklist untuk melaksanakan observasi.

3. Kerugian metode : 

• Prosedure mungkin tidak lengkap dan tidak -up to date lagi.
• Mempelajari skema pedoman dokumen membutuhkan waktu dan keahlian analis.

Pengamatan dokumen 

1. Bagaimana metode itu dipakai : 

• Mengidentifikasikan dokumen utama dan laporan (physical data flow diagram).
• Mengumpulkan salinan dokumen faktual dan laporan.
• Setiap dokumen atau laporan, dipakai untuk record data, mencakup field (ukuran dan tipe), frekuensi penggunaan dan struktur kodingnya (coding structure).

2. Keuntungan metode : 

• Meminimalkan interupsi dari fungsi operasionalnya.
• Permulaan elemen kamus data.
• Seringkali, sanggup mempertimbangkan modifikasi major procedural.

3. Kerugian metode :

• Membutuhkan waktu yang cukup (terdapat organisasi bisnis yang mengalami kebanjiran dokumen dan laporan).

Sampling

Sampling sanggup membantu mengurangi waktu dan biaya. Perlu kecermatan untuk menentukan sample dari populasi, sehingga membutuhkan keahlian statistik supaya 

tidak mengalami kegagalan atau ancaman. 

2.3 Jenis Requirement dan Pembacanya

Requirement sanggup dibedakan menjadi tiga jenis, yaitu : 

User requirement (kebutuhan pengguna) Pernyataan perihal layanan yang disediakan sistem dan perihal batasanbatasan operasionalnya. Pernyataan ini sanggup dilengkapi dengan gambar/diagram yang sanggup dimengerti dengan mudah.

System requirement (kebutuhan sistem

Sekumpulan layanan/kemampuan sistem dan batasan-batasannya yang ditulis secara detil. System requirement document sering disebut functional specification (spesifikasi fungsional), harus menjelaskan dengan tepat dan detil. Ini bisa berlaku sebagai kontrak antara klien dan pembangun.

Software design specification (spesifikasi rancangan PL) 

Gambaran ajaib dari rancangan software yang menjadi dasar bagi perancangan dan implementasi yang lebih detil. Ketiga jenis requirement tersebut diharapkan dalam pembangunan software alasannya yakni masing-masing memberi pengertian ke pihak yang berbeda kepentingan. Pembaca dari ketiga requirement tersebut bisa dijelaskan dengan gambar 1.

2.4 Kategori Requirement

Software system requirement sering dibedakan dalam 3 kategori yaitu

Functional requirement, Non Functional requirement dan Domain requirement dengan masing-masing penjelasannya sebagai berikut:

Functional Requirement : 

Merupakan klarifikasi perihal layanan yang perlu disediakan oleh sistem, bagaimana sistem mendapatkan dan mengolah masukan, dan bagaimana sistem mengatasi situasi-situasi tertentu. Selain itu adakala juga secara terang menentukan apa yang tidak dikerjakan oleh sistem.

Functional requirement menggambarkan system requirement secara detil ibarat input, output dan pengecualian yang berlaku. Contoh dalam kasus peminjaman buku di perpustakaan: 

Pengguna bisa mencari semua informasi perihal buku atau bisa menentukan salah satu dari informasi perihal buku. 

• Semua peminjam mempunyai pengenal yang unik. 
• Sistem bisa catat transaksi peminjaman, pengembalian dan denda secara lengkap. 
• Hari libur bisa di-set semenjak awal, dan bisa mendapatkan perubahan dengan otoritas khusus. 
• Harus komplit ( kebutuhan layanan terang dan lengkap) dan konsisten (tidak pertentangan dengan yang didefinisikan). 

Masalah yang mungkin terjadi dalam menyusun functional requirement adalah: 

• Diintepretasikan/diartikan berbeda oleh user atau developer. 
• Hasil intepretasi sering tidak menjawab kebutuhan klien. 
• Untuk sistem yang besar, kelengkapan kebutuhan dan konsisten sulit dicapai 
• karena kerumitan sistem. 
• Perlu analisis yang dalam dan menyeluruh untuk mengurangi kesalahan. 

Non-functional Requirement : 

Secara umum berisi batasan-batasan pada pelayanan atau fungsi yang disediakan oleh sistem. Termasuk di dalamnya yakni batasan waktu, batasan proses pembangunan, standar-standar tertentu. Karena berkaitan dengan kebutuhan sistem secara keseluruhan,maka kegagalan memenuhi kebutuhan jenis ini berakibat pada sistem secara keseluruhan. Contoh kebutuhan jenis ini yakni kecepatan akses, keamanan data, besarnya kapasitas penyimpanan yang diperlukan, privasi masing-masing profil /account, bahasa pemrograman yang digunakan, sistem operasi yang digunakan.

Non functional requirement dibagi menjadi 3 tipe yaitu: 

Product requirement 

Berkaitan dengan kehandalan, kecepatan, fasilitas digunakan, kapasitas memori yang dibutuhkan dan efisiensi sistem. 

Organisational requirement 

Berkaitan dengan standar, bahasa pemrograman dan metode rancangan yang digunakan. 

External requirement 

Berkaitan dengan dilema etika penggunaan, interoperabilitas dengan sistem lain, legalitas, dan privasi.

Domain requirement : 

Berasal dari domain aplikasi sistem. Misalnya alasannya yakni dilema hak cipta maka beberapa dokumen dalam perpustakaan dilarang diakses oleh orang lain yang tidak berhak. 

2.5 Key activity

Elicitation 

Pada tahap ini dikumpulkan aneka macam requirement dari para stakeholder [Pres01]. Seorang pelanggan mempunyai dilema yang sanggup ditangani oleh solusi berbasis komputer. Tantangan ini ditanggapi oleh seorang pengembang. Di sinilah komunikasi dimulai antara pelanggan, pengembang, dan calon pengguna dari sistem yang akan dibuat. Namun istilah elicitation agak diperdebatkan. Ada yang menganalogikannya dengan ibarat yang dilakukan oleh para arkeolog dikala mengumpulkan runtuhan-runtuhan di situs purbakala [Leff00]. Ada yang memperlihatkan istilah requirements capture alasannya yakni dilakukan terutama dengan mengumpulkan fakta-fakta [Benn00]. Bahkan [Gudg00] menyatakan bahwa requirement bekerjsama dibentuk ketimbang didapatkan (elicitated). Walau yang terakhir ini nampaknya “lain sendiri”, argumen ini sanggup diterima untuk pengembangan software yang sama sekali gres maupun untuk software-software permainan (games) yang terkadang permasalahan yang akan dipecahkan oleh game tersebut cenderung tidak bekerjasama dengan solusinya ataupun bekerjsama dilema yang ada berasal dari bab marketing2. Sejalan dengan proses RE secara keseluruhan, tujuan dari requirements elicitation yakni [Gudg00] :

1. Untuk mengetahui dilema apa saja yang perlu dipecahkan dan mengenali perbatasan-perbatasan sistem (system boundaries).· Untuk mengenali siapa saja para stakeholder.
2. Untuk mengenali tujuan dari sistem; yaitu sasaran-sararan yang harus dicapainya.

2.5.1 Teknik pengumpulan Requirement

• Dalam [Nuse00] disebutkan beberapa jenis teknik pengumpulan requirement:Traditional techniques merupakan aneka macam cara pengumpulan data. Cara-cara ini termasuk kuesioner, survey, wawancara, serta analisis dari aneka macam dokumentasi yang ada ibarat struktur organisasi, petunjuk pelaksanaan (juklak) serta manual-manual dari sistem yang sudah ada.
• Group elicitation techniques bertujuan untuk menyebarkan dan mendapatkan persetujuan stakeholder, sementara memanfaatkan dinamika kelompok untuk memperoleh pengertian yang lebih mendalam. Cara-cara ini termasuk brainstorming dan focus group, juga aneka macam workshop RAD/JAD (workshop untuk membangun sebuah konsensus dengan memakai seorang fasilitator yang netral).
• Prototyping techniques membuat suatu implementasi parsial dari software yang akan dibangun untuk membantu para pengembang, pengguna, serta pelanggan untuk lebih mengerti aneka macam requirement sistem [Leff00]. Digunakan untuk mendapatkan umpan-balik yang cepat dari para stakeholder [Davi92], teknik ini juga sanggup digabungkan dengan aneka macam teknik yang lain, ibarat contohnya dipakai di dalam sebuah program group elicitation ataupun sebagai basis dari sebuah kuesioner.
• Model-driven techniques menempatkan suatu model khusus dari jenis informasi yang akan dikumpulkan untuk dipakai sebagai pedoman proses elicitation. Termasuk di antaranya yakni goal based methods ibarat KAOS [Lams98] dan [Chun00] dan juga cara-cara berbasis skenario ibarat CREWS [Maid96].
• Cognitive techniques termasuk serangkaian cara yang semulanya dikembangkan untuk knowledge acquisistion untuk dipakai di knowledge-based systems [Shaw96]. Teknik-teknik ini termasuk protocol analysis (di mana spesialis melaksanakan sebuah kiprah sembari mengutarakan pikiran-pikirannya), laddering (menggunakan aneka macam investigasi untuk mendapatkan struktur dan isi dari pengetahuan stakeholder), card sorting (meminta para stakeholder untuk menysun kartu-kartu secara berkelompok, di mana setiap kartu tertera nama sebuah domain entity), dan repertory grids (membuat sebuah attribute matrix for entities di mana para stakeholder diminta untuk mengisi matriks tersebut).
• Contextual techniques muncul pada tahun 1990-an sebagai sebuah pilihan di luar traditional maupun cognitive techniques [Gogu94]. Termasuk di antaranya penggunaan teknik etnografis ibarat pengamatan terhadap para peserta. Juga termasuk ethnomethodogy dan analisis percakapan, yang keduanya memakai analisis terinci untuk mengenali pola-pola dalam percakapan dan interaksi [Vill99]. 
• Dalam kegiatan requirements elicitation, ada baiknya untuk mengkategorikan aneka macam requirement yang ditemukan. Suatu requirement sanggup diklasifikasi sebagai functional requirement, non-functional requirement, maupun constraints [Grad92]. Sedangkan [Koto98] menyampaikan bahwa suatu requirement sanggup diklasifikasikan menjadi very general requirements, functional requirements, implementation requirements, performance requirements, dan usability requirements. 
• Namun nyatanya penjabaran (atau cara-cara pengkategorian lainnya) requirement ini tidak mutlak diperlukan; penjabaran requirement ditujukan terutama untuk menuntun proses elicitation. Hal ini perlu diwaspadai alasannya yakni gara-gara para anggota tim tidak sanggup oke akan penjabaran dari sekumpulan requirement, maka development effort dari sebuah perusahaan Fortune 500 mengalami stagnasi [Leff00]. Terjebaknya mereka di dalam dilema semantik ini merupakan salah satu contoh dari analysis paralysis [Whit99]. 

Analyze

Sebuah model yakni perwakilan dari benda lain yang mempunyai rincian yang cukup untuk membantu penyelesaian tugas-tugas tertentu [Benn00]. Data modeling bertujuan untuk mendapatkan pengertian dari pemrosesan serta pengaturan informasi. Behavioral modeling memodelkan aneka macam sikap dari para stakeholder serta aneka macam sistem lain yang bekerjasama dengannya. Domain modeling menyediakan suatu bentuk ajaib dari dunia kawasan beroperasinya sistem yang akan dibuat. Model-model yang dihasilkan dalam tahap ini ditujukan untuk analisa terhadap aneka macam requirement yang ada. Para stakeholder berunding untuk mendapatkan suatu himpunan requirement tamat yang akan dipakai untuk tahap pengembangan selanjutnya. 

Menurut [Koto98] sehabis selesainya tahap idealnya ini akan berlaku

1. Berbagai requirement dari masing-masing stakeholder tidak bertentangan.
2. Informasi di dalam semua requirement harus lengkap.
3. Berbagai requirement yang ada harus selaras dengan anggaran yang dimiliki. 

Walaupun dengan adanya batasan-batasan tersebut, seluruh requirement sebaiknya gampang diubah ataupun disesuaikan. 

Spesification 

Tahap ini yakni penulisan dari requirements document, yang terkadang disebut dokumen Software Requirements Specification (SRS). Menurut [Hen80], dokumen ini sebaiknya:

1. Hanya memutuskan sikap sistem sebagaimana terlihat dari luar
2. Menetapkan batasan-batasan (constraints) yang diberikan kepada implementasinya.
3. Mudah diubah.
4. Berguna sebagai alat referensi untuk pemeliharaan sistem.· Memuat citra akan siklus kehidupan sistem di masa yang akan datang.

Untuk meningkatkan readability, beberapa standar dokumentasi SRS telah dikembangkan. Namun berdasarkan [Kov99], serangkaian standar dan template apabila berdiri sendiri tidak sanggup dipakai sebagai cara yang mandraguna untuk memberi struktur bagi sekumpulan requirement; tetapi struktur yang dipakai haruslah dikembangkan sendiri-sendiri tergantung dari dilema yang sedang ditangani. Masalah standarisasi notasi dan pendokumentasian requirement membuat pendekatan sistematis terhadap RE menjadi sulit. [McDe94] memperlihatkan sebuah daftar mudah ciri-ciri yang dinginkan pada sebuah requirements document:

• Unambigous. Idealnya, hanya ada satu interpretasi terhadap sebuah requirements document.
• Complete. Semua aspek yang bersangkutan haruslah dijelaskan secara lengkap di dalam requirements document.
• Consistent. Tidak ada pernyataan yang bertentangan dalam requirements document.
• Verifiable. Setelah sebuah sistem diimplementasikan, sebaiknya sanggup dipastikan bahwa sistem tersebut memenuhi requirement awal.
• Validatable. Suatu requirement sebaiknya sanggup diperiksa oleh pelanggan untuk memastikan bahwa requirement tersebut memang memenuhi kebutuhannya.
• Modifiable. Perubahan sebaiknya gampang dilakukan dan efek dari perubahan ini terhadap bagian-bagian lain sebaiknya minimal.
• Understandable. Semua stakeholder sebaiknya sanggup mengerti requirement ibarat ditetapkan di dalam dokumen.
• Testable. Semua requirement sebaiknya cukup kuantitatif untuk dipakai sebagai titik tolak pengujian sistem.
• Traceable. Harus dimungkinkan adanya pengacuan (reference) antar aneka macam bab di dokumen requirement ataupun ke bagian-bagian lain dari proses pembuatan perangkat lunak. 

Validation & Verification 

Dalam tahap ini, dokumen dari tahap sebelumnya diperiksa biar memenuhi kriteriakriteria sebagai berikut [Koto98]:

1. Lengkap.
2. Konsisten.
3. Tunduk pada keputusan-keputusan yang diambil pada tahap requirements analysis.

Apabila ada requirement yang tidak memenuhi kriteria-kriteria tersebut, mungkin ada baiknya bagi proses RE untuk kembali ke tahap-tahap sebelumnya. Beberapa contoh dilema requirement yang terungkap pada tahap validasi antara lain [Koto98]:

• Kurang/tidak cocok dengan bakuan-bakuan kualitas.
• Kata-kata yang dipakai kurang baik sehingga requirement menjadi ambigu.
• Berbagai kesalahan yang terdapat pada model-model baik – model system ataupun model permasalahan yang hendak dipecahkan.· Pertentangan antar requirement yang tidak ditemukan pada tahap analisis.

BAB 3

PEMBAHASAN

3.1 Major Steps in Requirement Management Process

Proses Requirement Management Terdiri dari beberapa langkah utama :

• Membuat requirements management plan
• Mendata kebutuhan 
• Mengembangkan Vision document
• Membuat usecase 
• Supplementary specification
• Membuat test case dari usecase 
• Membuat test case dari supplementary specification
• Merancang sistem 

3.2 Requirement Management Plan

1. Requirement Management Plan merupakan bab dari perencanaan administrasi project. 
2. Secara umum, Requirement Management bertujuan untuk memastikan pengguna dan pengembang mempunyai pemahaman yang sama perihal kebutuhan-kebutuhan apa saja yang harus ada.
3. Requirement Management Plan mendokumentasikan bagaimana mencapai tujuan tersebut.

3.3 7 Tips For Successful Requirement management

Tips untuk Requirement management yaitu :

Tip #1 – Stay Connected

Ada 2 bab yang harus terhubung. Pertama, hubungan dalam suatu tim, yang termasuk didalamnya analisis, project managers, developers, testers, product manager, stakeholders, dan customers. Kedua yakni hubungan antar kebutuhan – kebutuhan dan lainnya, ibarat use cases, test cases, tasks, dan user documentation.

Tip #2 – Take Action Now 

Jangan menunggu proses menjadi sempurna, melaksanakan sesuatu akan lebih baik daripada tidak mengerjakan apapun. Mulai dari hal yang kecil, identifikasi beberapa kebutuhan critical (yang kritis), dengan demikian anda sanggup berguru lebih banyak mengenai kebutuhan customer dan secara kontinu dalam meningkatkan dan memperluas solusi yang diberikan kepada customer.

Tip #3 – Don’t Reinvent the Wheel 

Ada banyak template dan sumber yang sanggup digunakan.

Tip #4 – Eliminate Ambiguity 

Requirement management yang berhasil dimulai dari penulisan requirement yang baik. Penulisan requirement yang baik tidak memakai kata – kata yang bersifat ambigu dan membingungkan, sehingga tidak gampang untuk dimengerti.

Tip #5 – Reconnect with Your Customers 

Anda tidak perlu menjadi seorang pakar untuk menangkap bunyi para customer. Anda hanya perlu bekerja sesuai dengan kebutuhan customer. Requirement management yang sukses harus mencakup komunikasi yang konstan dengan customer, sehingga melalui bunyi customer, manager sanggup mengetahui apa yang bekerjsama dibutuhkan oleh mereka.

 Tip #6 – Prioritize Objectively 

Memprioritaskan customer.

Tip #7 – Minimize Overhead 

Pilih alat yang benar untuk menuntaskan pekerjaan. jika anda bekerja dalam tim kecil, anda sanggup melaksanakan pembahasan perkembangan produk dengan memakai whiteboard, task cards, dan pertemuan tatap muka untuk mengatur kebutuhan. Alat – alat yang dipakai harus sanggup mengurangi pengeluaran yang tidak perlu.

3.4 Requirement Management Plan Template

1.Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions, Acronyms, and Abbreviations 1.4 References 1.5 Overview 

2.Requirements Management

2.1 Organization, Responsibilities, and Interfaces 

2.2 Tools, Environment, and Infrastructure 

3.The Requirements Management Program

3.1 Requirements Identification 

3.2 Traceability 3.2.1 Criteria for <traceability item> 

3.3 Attributes 3.3.1 Attributes for <traceability item> 

3.4 Reports and Measures 

3.5 Requirements Change Management 3.5.1 Change Request Processing and Approval 3.5.2 Change Control Board (CCB) 3.5.3 Project Baselines 

3.6 Workflows and Activities

4. Milestones

5. Training and Resources

3.5 Document Requirement

Kegunaan dokumen requirement :

• — Fase awal , sebagai pedoman pada studi kelayakan 
• — Fase desain, sebagai pedoman untuk pemodelan desain (proses, data, interface)
• — Fase Coding & Testing, sebagai pedoman untuk membuat test skenario / uji coba 
• — Fase Deployment, sebagai pedoman untuk membuat buku manual ( untuk proses berikutnya maupun menuliskan kemampuan PL)

3.6 Documenting and Analyzing Requirements

Dokumentasi konsep kebutuhan dengan alat sbb: 

• Use cases 
• Decision tables 
• Requirements tables 

Analisa kebutuhan untuk menuntaskan permasalahan: 

• Missing requirements 
• Conflicting requirements 
• Infeasible requirements 
• Overlapping requirements 
• Ambiguous requirements 

Formalisasi kebutuhan: 

Dokumen yang memformalisasi kebutuhan · Dikomunikasikan ke stakeholders pada steering body

3.6.1 Requirement document

• Dokumen kebutuhan merupakan pernyataan resmi dari apa yang dibutuhkan dari pembangun sistem, berisi definisi dan spesifikasi requirement dan bukan dokumen desain. 
• Sebisa mungkin berupa kumpulan dari apa yang harus dikerjakan sistem, bukan bagaimana sistem mengerjakannya.
• pihak-pihak yang dijelaskan pada Gambar 3 yang menjelaskan pihak pengguna dokumen dan kepentingannya dengan dokumen tersebut.

Dokumen kebutuhan sebaiknya memenuhi 6 hal berikut :

• Menjelaskan sikap eksternal system
• Menjelaskan batasan pada implementasi
• Mudah diubah
• Sebagai alat referensi untuk pemelihara system
• Mencatat peringatan awal perihal siklus dari system
• Menjelaskan bagaimana sistem merespon hal-hal yang tidak biasa/normal

3.7 Macam-Macam pekerjaan Requirement Engineering (RE)

Ada beberapa pekerjaan RE yang bisa dilakukan untuk memperoleh RE sesuai dengan penerapan yang ada didalam proses software requirement management :

Business analysis, Menganalisa context dari bisnis yang akan dikembangkan sistemnya. Terdiri atas beberapa proses : Analyze the customer organization’s business enterprise, Analyze the competitor organizations, Analyze current and potential/planned marketplace, Analyze critical technologies, Analyze current and intended future user communitie, Analyze the stake holder, dan Develop a business case

Visioning, Bersama stakeholder menghasilkan visi dari sistem gres yang akan dikembangkan. Mulai dari menentukan misi, dilema dalam bisnis dan kesempatan, kebutuhan dari stakeholder, tujuaan serta fungsionalitas selain itu juga batasan-batasannya.

Requirements Identification, Mengidentifikasikan requirement yang potensial. Prosesnya terdiri atas identify sources of requirement,elicit needs, goals, desires, and requirement, gather potential requirement, invent new requirement transform stakeholder desires, expectation, and needs into informal, textual, potential requirement.

Requirements Reuse Mengunakan ulang semua atau sebagian requirement yang sudah ada. Melibatakan beberapa proses yaitu mengidentifikasikan requiremen yang potensial untuk di reusable, mengevaluasi requirement yang relevan, menyesuaikan requirement agas sesuai dengan kebutuhan, mengunakan requirement yang telah disesuaikan.

Requirement Analysis, tim RE menganalisa requirement yang telah diidentifikasi dan requirement yang dipakai kembali. Pekerjaan yang harus dilakukan yakni Study, categorize, decompose and organize , model, quantify, refine, prioritize, justify, and trace each requirement, transform informal tekstual requirement, negotiate the prioritization of requirement, verify, transform potential raw requirement, ensure the requirement well unsterstood.

Requirement Prototyping, Menciptakan RE Prototypes, mencakup pembuatan satu atau lebih prototype, mengevaluasinya, dan mengunakan prototype tersebut.

Requirement Spesification, Membuat dan mempublikasi requirement yang telah dianalisa dan divalidasi dalam bentuk dokumen, langkah-langkahnya mencakup membuat dokumen, mendistribusikannya serta memperbaiki jika terdapat feedback terhadap dokumen tersebut.

Requirement Management, Mengelola semua kebutuhan, mencakup Record and store the requirement, control acess (CRUD) the requirement, negotiate with stakeholder, report the status, dan trace the requirement.

Requirement Validation, Memvalidasi kebenaran dari requirement yang telah dianalisa bersama dengan stakeholder dan melaksanakan koreksi yang diperlukan. Meliputi identify a stakeholder to validate the requirement, ensure these stakeholder validate the correctness of the requirement, iterate to fix requirement problem, certify an acceptable requirement.

Terdapat tiga pekerjaan yang secara teknik dan logika dipunyai oleh bidang lain, namun sangat kritikal terhadap kesuksesan RE, yakni Scope Management, Requirement Verification , Requirement Configuration Control. 

SUMBER;

https://www.blogger.com/blogger.g?blogID=4590033009607805970#editor/target=post;postID=4839105640892286577

Share this post