REQUIREMENTS MANAGEMENT PLAN PADA EXTREME PROGRAMMING

Nama :WindaKelas :06PNMNIM :1000864732Alamat blog :ludovika88.wordpress.com

ABSTRAK

Metodologi pengembangan perangkat lunak yang berkembang saat ini telah beralih ke metodologi yang lebih sederhana. Metodologi yang dikenal sebagai agile methods ini mengutamakan fleksibilitas terhadap perubahan-perubahan yang terjadi selama pengembangan. Bahkan perubahan ataupun penambahan pada saat fase terakhir pun teratasi apabila menggunakan metodologi ini. Salah satu yang paling popuper yaitu eXtreme Programming. Metodologi ini memiliki keunikan yang sebenarnya juga bisa menjadi kelemahannya, yaitu tanpa dokumentasi formal. . Makalah ini akan mencoba memasukkan dokumentasi sederhana pada extreme programming sebagai requirements management. Selanjutnya menjelaskan tentang peran peran unit dalam requirement management plan serta proses proses yang terjadi

Kata kunci : eXtreme Programming, requirements managemen plan.

2

BAB 1PENDAHULUAN

1.1 Latar belakangManagement requirement planing tidak lain merupakan konsep manajemen produksi yang berbicara mengenai cara tepat perencanaan kebutuhan barang dalam berproduksi. Management requirement planing dalam keberadaannya memanfaatkan kemampuan komputer untuk menyimpan dan mengolah data yang berguna dalam operasionalisasi aktifitas perusahaan. Management requirement planing mampu mengkoordinasikan berbagai fungsi dalam perusahaan manufaktur seperti teknik, produksi, dan pengadaan. Dari karenanya, Management requirement planing menarik tidak hanya menunjang decision making tetapi juga total perannya mendukung aktifitas perusahaan.Pada dasarnya Management requirement planing terdiri dari jadwal induk produksi, dan catatan persediaan. Berdasarkan informasi dari jadwal induk produksi diketahui permintaan suatu produk akhir. Lantas, dengan mengetahui komponen yang membentuk Produk akhir, status persediaan, waktu tenggang untuk memesan bahan maupun merakit komponen disusun suatu perencanaan kebutuhan dari komponen yang diperlukan. Output Management requirement planing tidak lain berbentuk jadwal pesanan pembelian komponen kepada supplier atau bagian produksi dalam pengerjaan perakitan komponen tertentu. Product explosion demikian terjadi karena demand produk akhir di pecah ke dalam demand dari berbagai komponen produk tersbut.

1.2 Ruang LingkupRuang lingkup penelitian meliputi pengenalan terhadap metode baru yaitu Extreme Programming serta pengenalan terhadap requirement management plan dan peran orang orang yang terlibat dalam proses requirement management plan tersebut.

1.3 tujuan dan manfaat1.3.1 tujuan

tujuan dari requirement management Menetapkan dan menjaga kesepakatan dengan customer dan stakeholder

lain tentang apa yang harus dilakukan oleh system Untuk memberikan pemahaman yang lebih baik kepada pengembang

system tentang kebutuhan system Menetapkan batasan system Untuk menyediakan dasar perencanaan teknis Untuk menyediakan dasar perkiraan biaya dan waktu pengembangan

system Untuk mendefinisikan user interface system

3

1.3.2 Manfaat Manfaat dari requirement management plan antara lain Dengan requirement management plan dapat lebih merencanakan sasaran

management yang akan dilakukan Dengan requirement management plan dapat lebih mudah menganalisa

permasalahan yang terjadi Dapat lebih memahami kebutuhan dari user Dapat membangun system yang tepat

4

BAB 2LANDASAN TEORI

Kontoya (2000) menjelaskan bahwa model dari aktifitas proses rekayasa requirement secara garis besar antara lain:

1. Requirement Elicitation Requirement dari sistem ditemukan, digali dengan cara melakukan konsultasi dengan stakeholder dari dokumentasi sistem pengetahuan di bidangnya (domain knowledge) dari studi pasar. Nama lain dari proses ini adalah pencarian/pengembilan requirement ( requirement acquisition) ataupun penemuan/pencarian requirement (requirement discovery)

2. Analisa requirement dan negosiasiRequirement dianalisa dengan detail dan dari berbagai stakeholder ditemukan negosiasi untuk memutuskan requirement mana yang dapat diterima. Proses ini diperlukan karena tidak dapat dihindari adanya konflik antara requirement dari berbagai sumber yang berbeda. Informasi yang tidak lengkap ataupun pengungkapan requirementnya tidak sesuai dengan angaran atau biaya yang tersedia (untuk pengembangan sistem).kadang kala diperlukan fleksibilitas pada requirement dan negosiasi untuk menentukan dan memutuskan kumpulan requirement yang disepakati (pada sistem)

3. Requirement dokumentasiRequirement yang telah disepakati didokumentasikan dengan tingkat kedetailan yang wajar dan layak. Secara umum diperlukan dokumen requirement yang dapat dimengerti oleh semua stakeholder ini berarti juga bahwa requirement harus didokumentasikan dengan bahasa yang baik, mudah dimengerti dan dengan bantuan diagram diagram

4. requirement validationperlu dilakukan pengecekan yang cukup baik untuk konsistensi dan kelengkapan requirement. Proses ini diajukan untuk menemukan, mengidentifikasi masalah pada dokumentasi requirement sebelum digunakan sebagai dasar bagi pengembangan sistem.

Isye (2002), mendefinisikan pengertian requirement managament sebagai pendekatan systematic untuk mendapatkan, mengorganisasi, mendokumentasikan dan mengatur perubahan requirement aplikasi software selain itu Requirement management juga memastikan Software developer akan memecahkan permasalahan yang tepat dan membangun system yang tepat pula

5

BAB 3PEMBAHASAN

3.1 Pengertian Requirement managementRequirement management merupakan pendekatan systematic untuk mendapatkan, mengorganisasi, mendokumentasikan dan mengatur perubahan requirement aplikasi software.Requirement management untuk memastikan Software developer akan memecahkan permasalahan yang tepat dan membangun system yang tepat pula.Proses requirements engineering bukanlah merupakan hal yang mudah. Seorangsystem analyst, project manager, atau siapapun yang memegang peran project champion harus mengumpulkan berbagai requirement dari para stakeholder, menganalisarequirement tersebut, mengkomunikasikasikannya dengan para programmer, serta menyelesaikan konflik yang terjadi antar berbagai requirement yang ada.Seringkali project champion ini harus bekerja di luar kantor untuk bertemu dengan para stakeholder. Hal ini terutama terjadi pada kasus proyek software development dimana organisasi pengembang berbeda dengan organisasi yang pada akhirnya akanmenggunakan perangkat lunak tersebut.

3.2 EXTREME PROGRAMMING

Extreme Programming (XP) adalah metode pengembangan perangkat lunak yang ringan dan termasuk salah satu agile methods yang dipelopori oleh Kent Beck, Ron Jeffries, dan Ward Cunningham. XP merupakan agile methods yang paling banyak digunakan dan menjadi sebuah pendekatan yang sangat terkenal. Sasaran XP adalah tim yang dibentuk berukuran antara kecil sampai medium saja, tidak perlu menggunakan sebuah tim yang besar. Hal ini dimaksudkan untuk menghadapi requirements yang tidak jelas maupun terjadinya perubahan-perubahan requirements yang sangat cepat.XP sebagai sebuah metode yang dinamis diperlihatkan dalam empat values yang dimilikinya dan keempatnya merupakan dasar-dasar yang diperlukan dalam XP. Kent Beck menyatakan bahwa tujuan jangka pendek individu sering berbenturan dengan tujuan sosial jangka panjang. Karena itu dibuatlah values yang menjadi aturan, hukuman, dan juga penghargaan. Keempat values tersebut adalah :

1. Komunikasi (Communication)2. Kesederhanaan (Simplicity)3. Umpan Balik (Feedback)4. Keberanian (Courage)

6

Sebagai sebuah metodologi untuk mengembangkan peragkat lunak XP tentu memiliki siklus hidup. Siklus hidup pada XP ini terdapat lima fase yaitu :1. Exploration Phase2. Planning Phase3. Iteration to Release Phase4. Productionizing Phase5. Maintenance Phase6. Death Phase

3.3 Persyaratan Manajemen Organisasi dan Tanggung JawabYang paling bertanggung jawab atas Kebutuhan Manajemen dalam Electronic Records Archives terletak pada Program Direktur (PD). Program direktur mewakili tanggung jawab untuk persyaratan persyaratan management ke lapangan. Peran utama dalam management requirement adalah : Requirements Officer, Configuration Management (CM) Specialist, Development Contractor, Engineering Review Board (ERB), Configuration Control Board (CCB), Users/Subject Matter Experts (SMEs), Quality Management (QM) Team, Team leader Risk Officer (RO). Configuration manager Requirements specifier

3.3.1 Requirements OfficerPersyaratan Officer yang bertanggung jawab untuk memastikan bahwa kegiatan Persyaratan Manajemen dilakukan seperti yang dijelaskan dalam rencana ini. Persyaratan Officer yang bertanggung jawab atas pemeliharaan dan pelaksanaan rencana ini. Persyaratan Officer juga bertanggung jawab untuk semua persyaratan yang terkait dengan masalah, rekomendasi, dan jaminan bahwa persyaratan tersebut terpenuhi. Persyaratan Officer bertanggung jawab untuk memastikan bahwa semua menerima persyaratan waktu respon. Persyaratan Officer yang dipilih untuk Electronic Records Archives memiliki pengalaman dan keahlian yang diperlukan untuk menjalankan tugas sebagai Persyaratan Manajemen yang dijelaskan dalam rencana ini.

7

3.3.2 Configuration Management (CM) SpecialistSpesialis Configuration Management yang bertanggung jawab untuk menjaga semua yang dikontrol sesuai dengan prosedur di Electronic Records Archives Konfigurasi Rencana Pengelolaan (CMP).

3.3.3 Development ContractorDevelopment Contractor merupakan Seseorang yang bertanggung jawab untuk mengembangkan fungsionalitas yang dibutuhkan sesuai dengan standard prosedur proyek. Termasuk didalmnya aktifitas utnuk melakukan pengumpulan kebutuhan, analisa dan perancangan, implementasi dan pengujian.. Berdasarkan persyaratan yang disampaikan kepada pengembangan oleh kontraktor Electronic Records Archives Program Management Office, perkembangan lebih lanjut akan memperbaiki persyaratan untuk menentukan fungsional, data, dan sistem persyaratan. Pengembangan kontraktor akan memberikan akhir persyaratan dalam bentuk Sistem Persyaratan Spesifikasi untuk sistem, dan akan memimpin sebuah Tinjau Persyaratan Sistem untuk persyaratan fungsional. Sebagai bagian dari System Requirements Review, pengembangan kontraktor akan bertanggung jawab untuk memastikan traceability ke tingkat persyaratan yang lebih tinggi.

3.3.4 Engineering Review Board (ERB)Engineering Review Board yang akan melaksanakan perannya dalam kaitannya dengan persyaratan perubahan dalam cara yang ditetapkan dalam Configuration Management Plan. Misi dari Engineering Review Board adalah untuk melakukan evaluasi teknis pada semua Masalah Laporan, Kebutuhan Ganti Proposal, menyarankan penambahan, modifikasi atau revisi ke Electronic Records Archives program dasar dan mendukung produk sebelum bekerja.

3.3.5 Configuration Control Board (CCB)Configuration Control Board yang melakukan perannya dalam kaitannya dengan persyaratan perubahan dalam cara yang ditetapkan dalam Configuration Management Plan. Electronic Records Archives Configuration Control Board yang bertanggung jawab atas semua perubahan ke Fungsional, dialokasikan, Produk, dan Produksi dasar.

3.3.6 Users/Subject Matter Experts (SMEs)User dan Users/Subject Matter Experts memberikan masukan pada definisi persyaratan melalui proses partisipasi dalam Integrated Product Teams (IPTs), pengguna konferensi, dan persyaratan lainnya yang berkaitan dengan mengumpulkan kegiatan. User dan Users/Subject Matter Experts umumnya menentukan kebutuhan bisnis karena keahlian mereka dalam proses bisnis, sedangkan Electronic Records Archives Program Management Office menterjemahkan dan mendefinisikan kinerja dan persyaratan teknis.

8

3.3.7 Quality Management (QM) TeamPersyaratan audit dalam team Quality Management dalam mutu yang ditetapkan dalam quality management team. Quality Management akan membantu dalam menentukan kriteria evaluasi untuk persyaratan dan pengujian spesifikasi, persyaratan evaluasi terhadap kriteria evaluasi, memastikan proses perbaikan dilaksanakan dan didokumentasikan, berpartisipasi dalam Configuration Control Board, dan memastikan personil partisipasi dan setuju terhadap persyaratan alokasi.

3.3.8 Team leaderPemimpin tim adalah penghubung antara pihak manajemen dan pengembang. Pemimpin tim bertanggungjawab untuk memastikan bahwa setiap aktifitas dilakukan dan dimonitor sampai penyelesaiannya. Pemimpin tim juga bertanggungjawab untuk memastikan bahwa staf pengembang mengikuti standar proyek dan sesuai dengan jadwal proyek

3.3.9 Risk Officer (RO)Seluruh risiko persyaratan dan pengelolaan proses pembangunan, harus diidentifikasi, dikelola dan ditetapkan di Electronic Records Archives Risk Management Plan (RKM). Persyaratan yang terkait dengan resiko harus dilaporkan kepada Electronic Records Archives Risk Officer

3.3.10 Trainingsetiap individu Mengisi peran dalam menerima pelatihan yang berkaitan dengan peran yang ditetapkan dalam Electronic Records Archives Kebutuhan Pelatihan Assesment (Tra) dan Rencana Pelatihan Program Management Office.

3.3.11 Configuration managerManajer konfigurasi bertanggungjawab untuk menyusun struktur produk dalam manajemen perubahan, mendefinisikan dan mengalokasikan ruang kerja bagi pengembang, dan melakukan integrasi. Manajer konfigurasi harus melaporkan hasil kegitannya kepada manajer proyek

3.3.12 Requirements specifierSeseeorang gyang bertugas utnuk menyusun spesifikasi dari bagian fungsionalitas system dengan menggambarkan aspek kebutuhan tersebut ke dalam satu atau lebih use case. Requirement specifier juga bertanggungjawab untuk mempaketkan usecase, menjaga integritas dari paket tersebut.

3.4 The Requirements Management Program3.4.1 Requirements Identification

Bagian ini menggambarkan tentang artifact (dokumen, tipe kebutuhan dan atribut kebutuhan) dan mendefinisikan bagaimana artifact tersebut diberi nama, ditandai, dan diberi nomor.

9

3.5 Requirements Change Management3.5.1 Change Request Processing and Approval

Setiap permintaan perubahan yang diajukan oleh stakeholder, maka perubahan ynag diinginkan tersebut harus dituangkan ke dalam dokumen tertulis, berisikan detail perubahan, alasan dan dampak dari perubahanYang diinginkan, Dokumen permohonan perubahan tersebut selanjutnya harus disetujui oleh sponsor. Setelah mendapat persetujuan dari sponsor maka dokumen tersebut harus diperiksa oleh manajer proyek (kepala Configuration Control Board) untuk dilihat cakupan perubahannya Configuration Control Board akan mengaudit setiap permintaan perubahan, kemudian akan menandai permohonan perubahan tersebut dengan status diterima (accepted), membutuhkan tindak lanjut (need more info) dan ditolak (rejected). Jika cakupan perubahan yang diminta masih terhitung on budget, on schedule dan masih berada dalam scope proyek maka akan segera ditindaklanjuti oleh pengembang untuk memenuhi perubahan tersebut. Namun jika ternyata cakupan perubahan tersebut besar, tidak on budget dan tidak on schedule maka aka diadakan pertemuan antara stakeholder dengan pihak pengembang untuk pembicaraan lebih lanjut berkenaan dengan rencana perubahan tersebut, sementara untuk perubahan yang diluar scope proyek akan diabaikan. Detail dokumentasi terdapat pada Change Management Plan.

3.5.2 Change Control Board (CCB)Permohonan perubahan harus dimasukkan ke dalam Rational ClearQuest

untuk dievaluasi oleh Change Central Board ( CCB). Configuration Control Board beranggotakan tim pelaksana proyek, dikepalai oleh Pak Sugiharto dan akan diselenggarakan pertemuan berkala untuk mengevaluasi seluruh perubahan yang diminta kepada kebutuhan dengan menggunakan integrasi Rational ClearQuest RequisitePro.

3.5.3 Project BaselinesProyek ini melalui 4 tahapan utama yaitu : Inception, Elaboration,

Construction, and Transition. Untuk setiap akhir iterasi tahapan dideliver dokumentas.

3.6 Concept Exploration Phase Requirements ManagementTahap eksplorasi konsep Persyaratan Manajemen melibatkan pendatangan dan

pengembangan dari persyaratan untuk tingkat detail yang diperlukan untuk digunakan oleh kontraktor pembangunan sebagai dasar untuk tawaran pada Request for Proposal.

10

3.7 Concept Exploration Phase Requirements Development Process

Gambar 3.7 Concept Exploration Phase Requirements Development High-Level Steps

3.7.1 Vision DevelopmentVisi pembangunan adalah proses pengembangan konsensus yang melihat

dari cakupan Electronic Records Archives program ini. Ini mencakup keseluruhan visi dan misi untuk tujuan sistem. Ini adalah tingkat tertinggi-persyaratan yang terkait dengan dokumen, yang menyatakan maksud dan tujuan dari sistem di highlevel syarat-syarat yang memenuhi kebutuhan dan tujuan dari agen.

Visi Electronic Records Archives untuk dikembangkan dengan menggunakan pendekatan two-track. Pada track pertama, konsep Pernyataan visi dikembangkan berdasarkan pada pemahaman tentang sistem oleh Electronic Records Archives Program Management Office. Pernyataan visi ini telah digunakan untuk kedua awal konsep pembangunan dan sebagai masukan pada track kedua dari visi pembangunan. Secara paralel, track kedua dari visi pembangunan yang dilakukan oleh kepemimpinan tim untuk memperbaiki konsep dan visi untuk menciptakan "buy-in" Electronic Records Archives untuk program ini. Akhir pernyataan visi yang telah disetujui oleh Archivist dari Amerika Serikat.

3.7.2 Concept of Operations Development (ConOps)Dokumen Electronic Records Archives Concept of Operations (ConOps)

merupakan salah satu produk dari konsep tahap eksplorasi. Suatu konsep pembangunan Integrated Product Team menciptakan ConOps dokumen. The ConOps menggambarkan karakteristik sistem dari sudut pandang pengguna.

11

3.7.3 Concept Exploration Phase Requirements Development ActivitiesConcept exploration phase requirements development adalah kegiatan

yang berulang. Serangkaian langkah ini dilakukan untuk memperoleh awal persyaratan. Setelah melalui siklus yang sama denganlangkah-langkah yang digunakan untuk terus memperbaiki persyaratan ke titik yang diperlukan untuk dimasukkan dengan Request for Proposal.

Langkah-langkah berikut merupakan siklus persyaratan pembangunan : Prepare for cycle, Elicit requirements, Analyze requirements, Formalize requirements, and Validate and Verify requirements.

3.7.3.1 Prepare for CycleDalam persiapan untuk setiap siklus persyaratan dari evolusi , berikut

langkah-langkah yang harus diambil. Menetapkan tujuan dari siklus

penerimaan kriteria untuk setiap siklus harus dikenal dengan pasti. Untuk contoh, kriteria untuk siklus mungkin untuk memetakan masing-masing syarat tertentu perlu usaha atau tujuan. Artinya, setiap kebutuhan harus traceable ke pernyataan di Mission Needs Statement atau ke salah satu tujuan dari Rencana Strategis.

Menentukan teknik untuk mengumpulkan siklusTeknik untuk mengumpulkan atau memperbaiki persyaratan yang ditetapkan untuk setiap siklus. Teknik ini termasuk brainstorming Tingkat Integrated Product Team untuk menggunakan persyaratan tingkat 0 dan tingkat 1, penciptaan dan penggunaan kasus dekomposisi, Object Oriented Analysis, pengguna konferensi, wawancara, dan kuesioner untuk upaya persyaratan perbaikan.

Mengidentifikasi stakeholders/participantsKunci stakeholder diidentifikasi untuk tiap tiap cycle dari requirement gathering. Hal ini termasuk mengidentifikasi kegiatan kedatangan peserta.

3.7.3.2 Elicit RequirementsPersyaratan dikumpulkan atau disempurnakan dengan menggunakan

teknik yang ditetapkan selama "persiapan".

3.7.3.3 Analyze RequirementsPersyaratan kandidat yang akan dianalisis untuk membentuk persyaratan

informal. Persyaratan yang dibuat harus konsisten dan detail.

12

3.7.3.4 Formalize RequirementsPersyaratan yang ditempatkan di RequisitePro requirement management

tool. Traceability matrices didefinisikan atau diperbarui.

3.7.3.5 Verify and Validate RequirementsRequirements Document yang diverifikasi dan divalidasi oleh para

stakeholder melalui pemeriksaan dan wawancara untuk memastikan bahwa ia memenuhi tujuan yang telah ditetapkan dalam siklus.

3.7.3.6 Concept Exploration Phase Requirements ReviewKetika National Archives and Records Administration dan Electronic

Records Archives Program Management Office percaya persyaratan telah mencapai tingkat yang sesuai untuk penyertaan dengan Electronic Records Archives Meminta Proposal , berikut ini tambahan kegiatan yang dilakukan dalam persiapan untuk Requirements Review

3.7.3.7 Concept Exploration Phase Requirements Baselinemenjelaskan dasar fungsional dan kinerja persyaratan desain dan kendala

entitas Electronic Records Archives secara keseluruhan. Program ini terdiri dari persyaratan yang ditetapkan di bawah persetujuan konfigurasi kontrol, menjelaskan suatu sistem yang menentukan spesifikasi fungsional dan kinerja sistem persyaratan, tinggi persyaratan sistem interface, sistem kendala teknis, dan kualifikasi yang diperlukan untuk memastikan pencapaian setiap kebutuhan. Fungsional dasar yang dihasilkan dari konsep eksplorasi didefinisikan sebagai tahap akhir dari Concept Exploration Phase Requirements Baseline.

3.8 Concept Exploration Phase Requirements Development Cyclesrequirements activities merupakan persyaratan untuk kegiatan yang diberikan

dalam Electronic Records Archives Program Rencana pengelolaan (PMP). Bagian berikut ini memberikan pendekatan untuk persyaratan pembangunan yang digunakan selama pelaksanaan rencana ini. Memodifikasi pendekatan ini dapat dibuat jika diperlukan selama kegiatan “Prepare for Cycle” pembangunan untuk setiap siklus

Konsep eksplorasi Kebutuhan Pengembangan proses terdiri dari tiga Iterasi persyaratan pembangunan, antara lain:• Tingkat 0 Kebutuhan Pembangunan iteration, • Tingkat 1 Kebutuhan Pembangunan iteration, dan • Kebutuhan perbaikan iteration.

13

3.8.1 Level 0 Requirements Development IterationTingkat the 0 persyaratan pendatangan berdasarkan masukan dari para

anggota persyaratan Integrated Product Team, serta review dokumen dan wawancara dengan senior staf National Archives and Records Administration. Persyaratan Officer dilakukan analisis dan langkah-langkah formalisasi, verifikasi dan validasi dilakukan oleh persyaratan Integrated Product Team.

3.8.2 Level 1 Requirements Development IterationDi Level 1 persyaratan pendatangan telah dicapai oleh kombinasi

brainstorming dan meninjau bahan baku dari tahap Tingkat 0. ini dilakukan oleh persyaratan Integrated Product Team, dan melibatkan pengguna dari sistem dan UKM.

3.8.3 Requirements Refinement IterationRequirements refinement (final iteration) telah disempurnakan oleh

persyaratan berbasis Tingkat 1. pada pembuatan use case dilakukan pencarian yang lebih lanjut dan persyaratan yang baru. Program Management Office staf Electronic Records Archives yang dibuat dengan menggunakan kasus yang telah diajukan ke grup terdiri dari anggota dari Committee on Archival Requirements ditambah dengan additional Subject Matter Expert ,untuk analisa,komentar dan validasi. Committee on Archival Requirements dengan Subject Matter Expert komentar mengenai use case itu kemudian digunakan untuk memperbaiki persyaratan, atau menciptakan syarat-syarat baru.

3.9 Concept Exploration Phase Requirements Traceability and Allocationpersyaratan traceability terdiri dari:

Traceability antara National Archives and Records Administration Tujuan Strategis dan tingginya tingkat kebutuhan, Traceability antara menggunakan kasus dan tingginya tingkat kebutuhan, dan

Traceability persyaratan tingkat high level "parent" dan persyaratan. lower level "children"

requirements activities selama tahap konsep eksplorasi terdiri dari requirement alicitation, dank arena itu ketentuan ini diharapkan dapat berubah. Sejak Integrated Product Team dan use case merupakan sumber untuk mayoritas Konsep tahap eksplorasi persyaratan.

14

3.10 Concept Development Phase Requirements ManagementNational Archives and Records Administration akan memberikan penghargaan

kontrak kepada dua Kontraktor Pembangunan yang akan menganalisa secara independen dan persyaratan yang diberikan kepada mereka oleh Electronic Records Archives Program Management Office. Pengembangan masing-masing Kontraktor akan menghasilkan sebuah sistem desain, berisi decomposed persyaratan mereka. National Archives and Records Administration akan meninjau desain kontraktor, dan memilih salah satu kontraktor untuk mengembangkan sistem Electronic Records Archives.

Pengembangan konsep Persyaratan Manajemen Proses, menggambarkan langkah-langkah proses Konsep Persyaratan Manajemen Pembangunan.

Gambar 3.10 Concept Development Requirements Management Process

3.10.1 Provide Baselined Requirements to Development ContractorsElectronic Records Archives Program Management Office menyediakan

baselined persyaratan Pengembangan Kontraktor untuk digunakan sebagai dasar kontraktor untuk persyaratan dekomposisi dan usaha desain.

15

3.10.2 Contractor Requirement AnalysisPersyaratan yang diberikan kepada Kontraktor Pembangunan oleh

Electronic Records Archives Program Management Office lebih disempurnakan oleh para kontraktor ke tingkat yang diperlukan untuk merancang sistem Electronic Records Archives dan pelaksanaannya. Setiap Pembangunan Kontraktor bertanggung jawab untuk menyampaikan hasil analisis persyaratan sistem mereka dalam bentuk Spesifikasi Persyaratan Sistem (SyRS) dalam format traceability dan kriteria yang ditetapkan dalam dokumen ini.requirement akan dialokasikan untuk pembangunan akan menambahkan dalam SyRSs berdasarkan petunjuk yang diberikan pada Requirements Document.

3.10.3 System Requirements Review (SRR)Tujuan System Requirements Review adalah untuk memastikan

kecukupan Pengembangan Kontraktor usaha untuk memfokuskan pada sistem kelengkapan persyaratan dalam hal identifikasi, definisi, dan penentuan awal kearah kemajuan dan Pengembangan Kontraktor sistem teknik pengelolaan usaha.

Beberapa kriteria yang dapat digunakan untuk persyaratan evaluasi meliputi:• Traceability untuk kebutuhan akuisisi, • Konsistensi dengan kebutuhan akuisisi,• Testability, • Kelayakan dari sistem arsitektur, dan • Kelayakan operasi dan pemeliharaan.

3.10.4 Electronic Records Archives Program Management Office Reviews Requirements and Provides Feedback

Setelah System Requirements Review, ketika Kontraktor Pembangunan kembali bekerja terhadap desain mereka, maka Electronic Records Archives Program Management Office sekaligus meninjau dan menganalisa persyaratan yang diberikan di System Requirements Review.

3.10.5 Development Contractors Produce System Design DocumentsPengembangan Kontraktor membuat desain dari sistem baselined

persyaratan yang diberikan Program Management Office oleh Electronic Records Archives, analisis persyaratan mereka sendiri dan umpan balik yang diberikan oleh Electronic Records Archives Program Management Office pengembangan dari kontraktor System Requirements Review, dan hasil dari usaha ini merupakan system design dokumen(SDDs).

16

3.10.6 System Design Reviews (SDRs)Pengembangan Kontraktor akan mempresentasikan system design

dokumen ke Electronic Records Archives Program Management Office di Desain Sistem Review (SDRs). Tujuan Desain Sistem Review adalah untuk memastikan bahwa Electronic Records Archives Program Management Office dan Pengembangan Kontraktor sependapat bahwa desain sistem yang diusulkan memenuhi fungsi dasar dan persyaratan kinerja.

3.10.7 Development Contractor SelectedBerdasarkan pemeriksaan dan analisis dari System Design Document yang

diajukan oleh Kontraktor Pembangunan, National Archives and Records Administration akan memilih salah satu Kontraktor Pembangunan untuk mengembangkan Electronic Records Archives sistem.

3.11 Initial Production Phase Requirements ManagementSetelah persetujuan dari sdd oleh Electronic Records Archives Program

Management Office, Development Contractor mengembangkan sistem dalam lima kenaikan.

3.11.1 Increment Requirements ManagementKenaikan System Requirements Review dekat dengan awal setiap

kenaikan. Kenaikan System Requirements Review dilakukan bila sistem fungsional persyaratan telah dialokasikan untuk kenaikan tersebut.

Tujuan kenaikan System Requirements Review adalah untuk memastikan kecukupan Pengembangan dari Kontraktor usaha di fokus pada kelengkapan persyaratan sistem mereka dalam hal identifikasi, definisi, dan penentuan awal ke arah kemajuan dan Pengembangan Kontraktor sistem manajemen usaha untuk ditetapkan kenaikannya.

3.11.2 Release Requirements ManagementUntuk setiap pengeluaran, berikut persyaratan yang terkait dengan

kegiatan terjadi: mengalokasikan baselined persyaratan pengeluaran dan menganalisa persyaratan

pengeluaran, Produksi System Requirements Specification untuk pengeluaran Melaksanakan System Requirements Review Mengubah control pengeluaran

17

Gambar 3.11.2 Release Requirements Management Process

3.11.2.1 Allocate Baselined Requirements to ReleasePada awal pengeluaran, Electronic Records Archives Program

Management Office dan Pengembangan Kontraktor kerja bersama-sama menentukan persyaratan untuk mengalokasikan ke pengeluaran berdasarkan fungsi yang dilaksanakan.

3.11.2.2 Decomposition/Development of Release RequirementsBerdasarkan Pembangunan Kontraktor dari persyaratan analisis,

kontraktor akan melakukan dekomposisi persyaratan yang diperlukan jika ditemukan keperluannya. Dalam hal kehilangan requirement maka pengembangan kontraktor mengembangkan persyaratan yang diperlukan.

3.11.2.3 Produce System Requirements Specification (SyRS) for the Release

Development Contractor bertanggung jawab untuk persyaratan yang tercakup oleh pengeluaran System Requirements Specification ke perangkat keras, perangkat lunak, operasional dan komponen system mereka sebagai bagian dari pengeluaran System Requirements Specification

3.11.2.4 System Requirements Review (SRR) for ReleaseDevelopment Contractor menyajikan sebuah pengeluaran Produce System

Requirements Specification ke Electronic Records Archives Program Management Office untuk persetujuan pengeluaran System Requirements Review.

18

Electronic Records Archives Program Management Office mengevaluasi Pengembangan Kontraktor dari pengeluaran System Requirements Specification dan menentukan penerimaannya. Berdasarkan pada penerimaan System Requirements Specification, hal hal yang akan terjadi antara lain :

Jika pengeluaran System Requirements Specification dapat diterima, maka Electronic Records Archives Program Management Office akan menyetujui System Requirements Specification dan persyaratan akan re-baselined jika diperlukan.

Jika pengeluaran System Requirements Specification tidak diterima, maka Electronic Records Archives Program Management Office akan menolak ijin untuk memulai pengembangan peningkatan. Pengembangan Kontraktor harus memperbaiki kekurangan yang diidentifikasi oleh Electronic Records Archives Program Management Office, dan menghasilkan revisi System Requirements Specification.

3.11.2.5 Release Change Controlrequirements Change Management process untuk tiap perubahan

requirement diidentifikasi selama pengeluaran yang bergantung pada apakah syarat-syarat yang diusulkan akan berdampak pada perubahan jadwal atau biaya dari keluaran. Pengembangan Kontraktor akan bertanggung jawab untuk melaksanakan proses Configuration Management. Bagian Pembangunan Kontraktor dari proses configuration management harus menyertakan Kontraktor Pembangunan Configuration Control Board. Electronic Records Archives Program Management Office Contracting Officer Representative (COR) akan memiliki bagian di pembangunan kontraktor Configuration Control Board.Bagian ini menentukan apakah perubahan ini cenderung berdampak proyek jadwal atau biaya. Perubahan yang tidak diharapkan seperti dampak lingkup, jadwal, atau biaya dapat disetujui oleh Kontraktor Pembangunan dari Configuration Control Board. Perubahan yang diharapkan dapat berdampak lingkup, jadwal, biaya atau harus dirujuk ke Electronic Records Archives Program Management Office Configuration Control Board untuk diperiksa dan disetujui sebagai oleh Configuration Management Plan.

National Archives and Records Administration akan menginformasikan Pengembangan Kontraktor dari keputusan Electronic Records Archives Configuration Control Board dan Pengembangan Kontraktor akan memperbarui persyaratan yang ditetapkan untuk mencerminkan Electronic Records Archives Configuration Control Board dari keputusan.

Pengembangan Kontraktor akan bertanggung jawab untuk menjaga melengkapi persyaratan traceability selama proses pengeluaran.Pengembangan Kontraktor akan diperlukan untuk menjaga traceability, dalam hal ini, "sumber" adalah baselined persyaratan yang diberikan kepada Kontraktor pembangunan oleh Electronic Records Archives Program Management Office, atau setelah persyaratan baselined.

19

3.11.3 Initial Production Phase Status ReportingPersyaratan Officer yang akan menyediakan kebutuhan yang berhubungan

dengan data, diperlukan untuk generasi yang berisi laporan sebagai berikut : Cakupan kebutuhan Kebutuhan pertanyaan Kebutuhan menilai perubahan Kebutuhan review penyelesaian akhir Kebutuhan review penyelesaian tepat waktu System cakupan dan Cakupan software desain

3.12 Requirements Management Process ReviewsPersyaratan Manajemen Proses Review meliputi ulasan berikut:

Management Review, Requirements Management Quality Management Review, and Independent Verification and Validation Review.

3.12.1 Management ReviewRequirements Management activities akan diperiksa secara teratur. Jadwal

dan kegiatan yang terkendali ini ada pada Program Management Plan

3.12.2 Requirements Management Quality Management ReviewQuality Management Plan yang menggambarkan audit dari persyaratan

dan Persyaratan kegiatan Manajemen.

3.13 Requirements Acceptance CriteriaSetiap kebutuhan Electronic Records Archives akan diperiksa untuk memastikan

bahwa Electronic Records Archives memenuhi kriteria sebagai berikut:.

Apakah valid ? Apakah persyaratan yang berbeda dan mewakili identitas yang diperlukan?

Apakah dapat diuji? Setiap kebutuhan harus dapat diverifikasi oleh pengujian atau melalui analisis.

Apakah traceable? Setiap kebutuhan harus traceable untuk kebutuhan lain. Apakah jelas? Syarat harus dimengerti tanpa penjelasan lebih lanjut atau

pengetahuan. Apakah ia independen? Persyaratan jangan "tumpang tindih," mereka harus

atomik. Apakah itu layak? Apakah mungkin untuk dilaksanakan?

20

3.14 Resources for Requirements ManagementSumber daya yang dialokasikan untuk kebutuhan pengelolaan usaha sebagaimana

tercantum dalam Program Management Plan sebagai berikut:

Integrated Product Team yang digunakan untuk mengembangkan dan memfalidasi persyaratan;

Electronic Records Archives Program Management Office yang memberikan dukungan untuk persiapan atau pengumpulan dokumen kepada Integrated Product Team dan menbuat use case.

Requirements Management tool digunakan oleh Requirements Officer.

3.15 Tools for Requirements ManagementPersyaratan Manajemen efektif harus didukung oleh alat yang telah ditetapkan.

Pedoman Pengembangan system National Archives and Records Administration menjelaskan proses untuk mengevaluasi produk.

Requirement management tool harus: Memanfaatkan database Memberikan kapasitas penomoran Memberikan kapasitas nama yang berbeda Memberikan pandangan yang berbeda dari requirement Memberikan prioritas skema Menyediakan traceability matrices

3.16 Plan MaintenanceRencana akan diperbarui sesuai dengan kebutuhan saat ini untuk mempertahankan

dan mencukupi kebutuhan dari setiap kegiatan.

21

BAB 4PENUTUP

4.1 KesimpulanMaka dapat dikatakan requirement management plan merupakan suatu

deskripsi yang menjabarkan bagaimana proses requirement terjadi serta mengenalkan kepada kita akan peran dan fungsi dari tiap unit yang terlibat dalam requirement management plan.selain itu juga membahas tentang garis besar penambahan fase requirements management pada eXtreme Programming sangat membantu untuk lebih menstrukturkan metode ini. Requirements Management yang disisipkan terutama difokuskan dalam hal dokumentasi. Pendokumentasian pada eXtreme Programming ini tidak akan mengganggu proses secara keseluruhan karena dilaksanakan secara paralel dengan planning phase.

4.2 saranorang orang yang berperan dalam requirement management harus lebih

optimal dalam tanggung jawabnya masing masing agar setiap perencanaan dapat tertata dengan baik dan dapat berjalan sesuai dengan waktunya atau sesuai dengan yang telah ditentukan

22

DAFTAR PUSTAKA

Adib (2003), penerapan design pattern untuk implementasi alat Bantu, http://rambutan.sourceforge.net/files/rambutan-paper.pdf

Adrianto (2009), requirement management pada extreme programming,

http://adrianto.ruangkopi.com/eii2009/fullpaper/REQUIREMENTS_MANAGEMENT_PADA_EXTREME_PROGRAMMING.doc

Isye (2009), Requirement management,http://dosen.stiki.ac.id/eva/RPL/Bhn%20Ajar/Requirement%20Management.ppt

23

CURRICULUM VITAE

Nama : Winda

Tempat,Tanggal Lahir : Jakarta 06 mei 1988

Jenis Kelamin : Wanita

Status : Belum Menikah

Kewarganegaraan : Indonesia

Alamat : Jl. KH. Syahdan Gang keluarga no.D5

Palmerah Jakarta Barat 11480

No. HP : 0818-828-408

Agama : katolik

Email : w_inz_cool@yahoo.com

Pendidikan Formal

SD (1994 – 2000) : SDN no.1

SMP (2000 – 2003) : SMP setya budi

SMA (2003 – 2006) : SMA santo petrus

University (2006 – Sekarang) : Binus university

24