Requirements Management Plan

STMIK MULTI DATA PALEMBANG

ANALISIS DAN PERANCANGAN CUSTOMER RELATIONSHIP MANAGEMENT BERBASIS SMS GATEWAY

Requirements Management PlanVersion

: - TIDAK ADA NAMA PERUSAHAAN

- JUDUL KURANG SPESIFIK

[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]

[To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]

Revision History

DateVersionDescriptionAuthor

04/05/20111.0Perumusan AwalRosita Sari

Silvia Atista

Tantri Maria

Windy Kwan

Table of Contents

21.Introduction

1.1Purpose21.2Scope21.3Definitions, Acronyms, and Abbreviations21.4References21.5Overview22.Requirements Management22.1Organization, Responsibilities, and Interfaces22.2Tools, Environment, and Infrastructure23.The Requirements Management Program23.1Requirements Identification23.2Traceability23.2.1Criteria for 23.3Attributes23.3.1Attributes for 23.4Reports and Measures23.5Requirements Change Management23.5.1Change Request Processing and Approval23.5.2Change Control Board (CCB)23.5.3Project Baselines23.6Workflows and Activities24.Milestones25.Training and Resources2

Requirements Management Plan1. Introduction

Dokumen ini berisi panduan yang akan digunakan oleh proyek untuk memberikan gambaran mengenai standard requirement documents, requirement types, requirement attributes, dan traceability. Dokumen ini juga mendefinisikan strategi umum untuk pengaturan requirement dan berfungsi sebagai sumber dokumen utama bagi semua partisipan dalam proyek ini.1.1 Purpose

Tujuan dari rancangan dokumen ini adalah untuk melaksanakan dan mendokumentasikan pendekatan sistematis untuk mendapatkan, Mengorganisasikan kebutuhan Sistem Informasi Berbasis SMS Gateway pada CV. EMPAT SERANGKAI. Dokumen ini juga melaksanakan dan memelihara perjanjian antara pelanggan dan tim proyek pada perubahan sistem.CV TIDAK BOLEH ADA TITIK.1.2 Scope

Dokumen ini menyediakan lingkup manajemen perencanaan kebutuhan dari proyek. Dokumen perencanaan ini adalah pendekatan lingkup manajemen, peran dan tanggung jawab pihak-pihak yang terkait dengan lingkup proyek, pengendalian perubahan lingkup. Setiap komunikasi proyek yang berkaitan dengan lingkup proyek harus mematuhi lingkup manajemen perencanaan ini.

1.3 Definitions, Acronyms, and Abbreviations

Definisi dan singkatan yang terdapat dalam dokumen ini dapat dilihat pada dokumen Glossary.

1.4 References

Spence, I. and L. Probasco. 1998. Traceability Strategies for Managing Requirements with Use Cases.

Cupertino, CA: Rational Software Corporation. Available at www.rational.net.1.5 Overview

Dokumen ini berisikan rincian khusus dan strategi untuk mengelola kebutuhan proyek peracangan Customer Relationship Management berbasis SMS Gateway . Dokumen ini menjelaskan bagaimana kebutuhan ditata dan dicatat dalam proyek ini. Dokumen ini menjelaskan proses pengelolaan perubahan kebutuhan-kebutuhan yang ada. Dijelaskan juga workflow dan rangkaian aktifitas yang berhubungan dengan pengontrolan kebutuhan proyek.2. Requirements Management

2.1 Organization, Responsibilities, and Interfaces

Organisasi proyek untuk melakukan pengembangan aplikasi sistem informasi ini adalah sebagai berikutJabatanTanggung Jawab

Project

managerIndividu yang bertanggungjawab penuh atas keberlangsungan proyek. Manajer

proyek harus memastikan penjadwalan aktifitas, pengalokasikan dan penyelesaiannya sesuai dengan jadwal proyek, anggaran dan kebutuhan kualitas.

DeveloperSeseorang yang bertanggung jawab untuk mengembangkan fungsionalitas yang dibutuhkan sesuai dengan standar dan prosedur proyek. Tennasuk didalamnya aktifitas untuk melakukan pengumpulan kebutuhan, analisa dan perancangan, implementasi dan pengujian.

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.

Requirements

specifierSeseorang yang bertugas untuk menyusun spesifikasi dari bagian fungsionalitas sistem dengan menggambarkan aspek kebutuhan tersebut ke dalam satu atau lebih usecase. Requirement specifier juga bertanggungjawab untuk mempaketkan usecase, menjaga integritas dari paket tersebut.

2.2 Tools, Environment, and Infrastructure

Development Tools

1. Microsoft Visual Basic.NET

2. MySQL Server untuk memanage databaseSPESIFIKASI TOOLS YANG KURANG DETAIL3. The Requirements Management Program

3.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.Artifact

(Document Type)Traceability ItemDescription

Stakeholder Requests (STR)Stakeholder Request (STRQ)Kebutuhan utama stakeholders/pengguna

Vision (VIS)Stakeholder Need (NEED)

Feature (FEAT)Kondisi atau kemampuan dari sistem yang akan ingin

dibangun untuk mewujudkan keinginan stakeholder

Use-Case ModelUse Case (UC)Deskripsi dan pengembangan use case, berisi tentang

alur standar dan alternatif dari sebuah proses.

Glossary (GLS)Glossary Term (TERM)Digunakan untuk mencatat semua kosakata yang

umum digunakan dalam seluruh dokumen

Supplementary Specification (SS)Supplementary Requirement (SUPP)Menggambarkan kebutuhan system yang tidak dapat

digambarkan dalam use case

Requirements

Management Plan

(RMP)Requirements Management Plan

(RMP)Menggambarkan kebutuhan danstrategi tertentu untuk

pengelolaan dan pengembangan proyek

3.2 Traceability

Setiap fitur yang disetujui harus memiliki hubungan pada salah satu usecase atau supplementary

requirement seperti gambar berikut ini.

3.2.1 Traceability Criteria for Requirement Types

3.3 Attributes

3.3.1 Attributes for

Benefit

CriticalIni harus dilakukan dengan tugas utama dari sistem, fungsi dasarnya, fungsi untuk yang sedang dikembangkan. Jika hilang maka sistem gagal untuk memenuhi misi utamanya. Mereka mengarah kepada desain arsitektur dan cenderung menjadi kasus paling sering digunakan dieksekusi.

ImportantIni harus dilakukan dengan dukungan fungsi sistem, seperti kompilasi data statistik, pembuatan laporan, pengawasan, dan pengujian fungsi. Jika mereka hilang sistem masih bisa (untuk sementara waktu) memenuhi misi fundamentalnya, tapi dengan kualitas pelayanan terdegradasi.

UsefulIni adalah "kenyamanan" fitur, tidak berhubungan dengan misi utama sistem tapi yang membantu dalam penggunaan atau posisi pasar.

Effort

Perkiraan hari upaya untuk menerapkan persyaratan.

Misalnya Hal ini dapat kategori seperti Rendah, Sedang, Tinggi. Misalnya Rendah = 20 hari.

Dalam mendefinisikan Usaha, itu harus jelas yang terindikasi overhead (manajemen usaha, usaha pengujian, persyaratan usaha dll) dimasukkan ke dalam estimasi.Risk

Pertimbangan yang diambil mengenai risiko yang akan terjadi pada saat pengembangan system.KURANG JELASNYA RESIKO.StabilityDitetapkan oleh analis dan tim pengembangan, ini menunjukkan kemungkinan bahwa kebutuhan akan mengalami perubahan. Digunakan untuk meningkatkan prioritas pengembangan dan untuk menjelaskan apakah informasi tambahan dibutuhkan atau tidak.3.4 Requirements Change Management

3.4.1 Change Request Processing and Approval

Setiap permintaan perubahan nomor yang ingin diajukan oleh stakeholder, namun perubahan yang

dinginkan tersebut harus dituangkan ke dalam dokumen tertulis, menggambarkan detail perubahan,

alasan dan dampak dari perubahan yang diinginkan. Dokumen permohonan perubahan tersebut

selanjutnva harus disetujui oleh sponsor. Setelah mendapat persetujuan dari sponsor maka

dokumen tersebut harus diperiksa oleh manajer proyek (kepada CCB) untuk dilihat cakupan

perubahannva.

Permohonan perubahan harus dimasukkan ke dalam Rational ClearQuest untuk diperiksa oleh

Change Control Board (CCB). CCB dikepalai oleh Project Manager dan akan diselenggarakan pertemuan berkala untuk mengevaluasi seluruh perubahan yang diminta, kepada kebutuhan dengan

menggunakan integrasi Rational ClearQuest RequisitePro.

CCB akan mengaudit setiap permintaan perubahan; kemudian akan menandai permohonan

perubahan tersebut dengan status diterima (accepted), membutuhkan informasi lebih lanjut (need

more info) dan ditolak (rejected). Jika cakupan perubahan yang diminta masih terhitung on budget,

on schedule dan masih berada data scope proyek maka akan segera ditindaklanjuti oleh

pengembang untuk memenuhi perubahan tersebut. Namun jika temyata cakupan perubahan tersebut

besar, tidak on budget dan tidak on schedule maka akan diadakan pertemuan antara stakeholder

dengan pihak pengembang untuk pembicaraan lebih lanjut berkenaan dengan rencana perubahan

tersebut, sementara untuk perubahan yang diluar dari scope proyek akan diabaikan. Detail

dokumentasi terdapat pada Change Management.3.4.2 Change Control Board (CCB)

Anggota CCB dikepalai oleh project Manager. Setelah change request disetujui,

diadakan project change feasibility meeting, project change acceptance meeting, dan project change implementation.4. Milestones

Setiap permintaan perubahan dokumen perencanaan manajemen kebutuhan diajukan oleh stakeholder, Namun perubahan yang dinginkan tersebut harus dituangkan ke dalam dokumen tertulis, menggambarkan setiap detail perubahan, alasan dan dampak dari perubahan yang diinginkan.

5. Training and ResourcesProduct perangkat lunak:

1. Dalam pengembanganya perangkat lunak yang kami sajikan mengunakan sistem Sms Gateway dengan software yang digunakan MS. Word, Visual basic dengan database sql server 2005.

2. Perangkat lunak yang nantinya di kembangkan dapat membantu proses meningkatkan hubungan dengan pelanggan yang lebih baik.

Personil traning:

1. Team proyek harus memahami konsep E-Commerce dan pengolahan kebutuhan sistem yang baik.APA YANG BERHUBUNGAN DENGAN E-COMMERCE2. Team proyek memerlukan pelatihan dalam menjalin kerja sama serta pelatihan dalam bidang masing-masing apabila pengalam diangap kurang.

NOTE: BANYAK FORMAT TULISAN YANG BERBEDA.Stakeholder Request

Feature

Use Case

Supplementary

PAGE