Requirement Work Plan - Kelompok 7 - 18208002

Requirement Work Plan

Angela Sistem Informasi aKademik (ASIK)

Sistem Informasi Akademik untuk SMA St. Angela Bandung

Disusun oleh:

Kelompok K1-G07

Vania Rahma Ginting / 18208002

Anthony Nirwana / 18208021

Antonia Riani Kalisa / 18208024

Satriyo Pramono / 18208025

Sekolah Teknik Elektro dan Informatika - Institut Teknologi Bandung

Jl. Ganesha 10, Bandung 40132

Daftar Isi

1. Tujuan.......................................................................................................................................52. Deskripsi Dokumen..................................................................................................................53. Organisasi.................................................................................................................................6

3.1 Struktur Organisasi..........................................................................................................63.2 Peran dan Tanggung Jawab terhadap Kebutuhan............................................................73.3 Jadwal Kerja....................................................................................................................73.4 Sumber Daya...................................................................................................................83.5 Biaya................................................................................................................................83.6 Kakas, Teknik, dan Metode.............................................................................................8

4. Penyimpanan Kebutuhan..........................................................................................................94.1 Dokumen Kebutuhan.......................................................................................................94.2 Tipe Kebutuhan...............................................................................................................94.3 Atribut Kebutuhan.........................................................................................................114.4 Requirements Traceability Matrix.................................................................................11

5. Rencana Manajemen Resiko..................................................................................................135.1 Tujuan............................................................................................................................135.2 Strategi Manajemen Resiko...........................................................................................135.3 Tanggung Jawab dan Akuntabilitas..............................................................................14

6. Requirements Acceptance Plan..............................................................................................156.1 Tujuan............................................................................................................................156.2 Tanggung Jawab dalam Requirements Acceptance......................................................166.3 Kriteria Requirements Acceptance................................................................................166.4 Jadwal Requirements Acceptance.................................................................................17

7. Requirements Management Metrics Plan...............................................................................177.1 Tujuan............................................................................................................................177.2 Tujuan Manajemen Kebutuhan.....................................................................................177.3 KPI Manajemen Kebutuhan..........................................................................................18

Sekolah Teknik Elektro dan Informatika ITB Halaman 2 dari 21Template dokumen ini dan informasi yang dimilikinya adalah milik STEI ITB dan bersifat rahasia. Dilarang mereproduksi dokumen ini tanpa diketahui oleh STEI ITB.

Daftar Tabel

Tabel 1. Kebutuhan dan Penanggung Jawab................................................................................7Tabel 2. Jadwal Kerja...................................................................................................................7Tabel 3. Estimasi Biaya................................................................................................................8Tabel 4. Requirement Attribute Table........................................................................................11Tabel 5. Requirement Traceability Matrix.................................................................................12Tabel 6. Daftar Tanggung Jawab dan Akuntabilitas..................................................................13Tabel 7. Daftar Resiko................................................................................................................14Tabel 8. Tanggung Jawab dalam Requirements Acceptance......................................................15Tabel 9. Jadwal Requirements Acceptance................................................................................16Tabel 10. Key Performance Indicator........................................................................................17


Daftar Gambar

Gambar 1. Struktur Organisasi SMA Santa Angela.....................................................................6Gambar 2. Struktur Pengerjaan Proyek........................................................................................6


1. Tujuan

Tujuan dari dokumen Requirement Work Plan adalah untuk mendeskripsikan rencana kerja

yang mengatur pembagian resource, kegiatan, dan proses yang akan dilakukan oleh Business

Analyst selama fase requirement di dalam proyek ASIK, serta resiko yang mungkin

ditimbulkan dari pengimplementasian ASIK di lingkungan sebenarnya. Dokumen ini

membantu BA melihat pekerjaan mana saja yang harus diselesaikan, siapa yang bertanggung

jawab, bagaimana requirement/kebutuhan tadi bisa ditelusuri, diukur dan dispesifikasikan

untuk ASIK.

2. Deskripsi Dokumen

Isi dari dokumen RWP adalah sebagai berikut :

- BAB 1 menerangkan tujuan dibuatnya dokumen Requirement Work Plan.

- BAB 2 menjelaskan inti dari tiap-tiap bab dalam dokumen

- BAB 3 menerangkan hubungan organisasi dan requirement, termasuk di dalamnya struktur

organisasi, Requirement Roles and Responsibilities, Requirement Schedule, Requirements

Resourcing, Budget, Tools, Techniques, and Methodologies.

- BAB 4 mendeskripsikan requirement, berupa Requirements Artifacts, Requirements Types,

Requirements Attributes, dan Requirements Traceability.

- BAB 5 membahas tentang rencana manajemen resiko, meliputi Risk Management

Strategy, Responsibility and Accountability, dan Risk List.

- BAB 6 berisi tentang bagaimana sebuah requirement dapat diterima oleh stakeholder. Metode

yang sering digunakan adalah Requirement Acceptance Plan, yang mencakup Requirements

Acceptance Responsibilities, Requirements Acceptance Criteria, dan Requirements

Acceptance Schedule.

- BAB 7 menerangkan Requirements Management Metrics Plan, yaitu metode-metode yang

digunakan untuk manajemen kebutuhan, seperti Requirement Management Goals dan

Requirements Management KPIs.


3. Organisasi

3.1 Struktur Organisasi

Struktur organisasi di sekolah Santa Angela Bandung adalah :

Gambar 1. Struktur Organisasi SMA Santa Angela

Struktur dalam pengerjaan rekayasa kebutuhan adalah :

Gambar 2. Struktur Pengerjaan Proyek


3.2 Peran dan Tanggung Jawab terhadap Kebutuhan

Berikut pembagian peran dan tanggung jawab terhadap requirement :

Tabel 1. Kebutuhan dan Penanggung JawabNo Kebutuhan Penanggung Jawab

1. Pengaturan Data Siswa Satriyo Pramono

2 Pemasukan Nilai Vania Rahma Ginting

3 Pengaturan nilai siswa Anthony Nirwana

4 Pencetakan transkrip Antonia Kalisa

3.3 Jadwal Kerja

Jadwal kerja dalam pembangunan sistem adalah :

Tabel 2. Jadwal KerjaN

o

Fase Iterasi Aktivitas Tanggal

Mulai

Tanggal

Selesai

Estimasi

sumber

daya

1 requirement 1 Menganalisis proses

bisnis, menenetukan

requirement dari

stakeholder

7 Okt 2010 20 November

2010

4

2 design 2 Memodelkan solusi

untuk setiap

requirement

21 Okt 2010 20 November

2010

4

3 implementation 3 Mengimplemetasikan model yang telah dibuat

Belum bisa dipastikan

Rentang waktu 4 bulan

6

4 testing 4 Memverifikasi integritas internalsistem ASIK lalumengintegrasikan ke sitem eksternal


Rentang waktu 2 bulan

8

maintanance 5 Melakukan perawatan danperbaikan padasistem, bila perlu.


Sesuai kontrak

2


3.4 Sumber Daya

Sumber Daya Manusia yang diperlukan dalam pengerjaan dan pengelolaan kebutuhan menjadi

sebuh sistem adalah sebagai berikut :

- Business Analyst : berperan sebagai pengontrol proses pembangunan proyek, agar tetap

sesuai dengan jalurnya (kebutuhan, skenario uji coba, dll)

- Tim Programmer : bertugas membuat sistem (code-nya), serta men-deploy sistem yang telah

dibuat ke lingkungan aslinya dan melakukan penyesuaian dengan lingkungan implementasi.

- Stakeholder : sebagai sumber requirement dan klarifikator sistem

Sumber daya lain yang dibutuhkan adalah server dengan kapasistas kuantitas dan kualitas yang

memadai serta peng-upgrade-an jaringan internet bila perlu (disesuaikan dengan kebutuhan).

3.5 Biaya

Estimasi biaya yang dikeluarkan untuk pengembangan sistem adalah sebagai berikut :

Tabel 3. Estimasi Biaya

3.6 Kakas, Teknik, dan Metode

Metode yang digunakan untuk memudahkan pengelolaan kebutuhan adalah Requirement

Management Metrics. Metric digunakan untuk membantu menganalisis kualitas dari suatu

requirement, dan agar mendapatkan requirement yang benar, kemudian mengidentifikasi

alasan terukur untuk software re-engineering.


4. Penyimpanan Kebutuhan

4.1 Dokumen Kebutuhan

Dokumen kebutuhan yang menjadi bagian dari proyek adalah Business Requirement

Document, Business Use Case Document, System Use Case Document, dan Requirement Work

Plan (dokumen ini sendiri).

Business Requirement Document (BRD) berisi identifikasi proses bisnis yang terjadi di

organisasi dan fungsionalitas sistem. Business Use Case Document menerangkan lebih lanjut

dari BRD yaitu bagian fungsi-fungsi yang ada pada proses bisnis nyata serta pelaku (user)

yang berkaitan dengan fungsi-fungsi tersebut. System Use Case Document menerangkan

bagian use case sistem yang sudah berada pada lingkup solusi, yaitu use case pada ASIK.

Sama seperti Business Use Case Document, System Use Case Document juga berisi fungsi-

fungsi serta pelaku yang berhubungan dengan fungsi tersebut, namun perbedaannya adalah

lingkup dari use case tersebut. Yang terakhir adalah Requirement Work Plan, berisi rencana

kerja yang mengatur pembagian resource, kegiatan, dan proses yang akan dilakukan oleh

Business Analyst selama fase requirement di dalam proyek ASIK, serta resiko yang mungkin

ditimbulkan dari pengimplementasian ASIK di lingkungan sebenarnya

4.2 Tipe Kebutuhan

Tiap-tiap requirement harus memenuhi FURPS+ sebagai berikut:

A. Functionality

Kebutuhan fungsional ASIK adalah memungkinkan guru untuk menginput nilai siswa, tanpa

perlu melibatkan tim validator. Tugas tim validator hanyalah mengecek kebenaran data dan

mengambil keputusan seperti pembagian kelas, pemilihan jurusan, dan lain-lain. Pihak-pihak

akademik lain, seperti kepala sekolah, wali kelas, dan tim kurikulum hanya dapat melihat data-

data seluruh siswa untuk dijadikan bahan pertimbangan keberlangsungan kegiatan belajar

mengajar. Selain itu, ASIK juga memungkinkan siswa melihat nilai dan statistik masing-

masing secara bebas, begitu pula dengan orangtua masing-masing. Untuk penjelasan lebih

lanjut, bisa mengacu ke dokumen System Use Case Description.

B. Usability


Berkenaan dengan user ASIK yang dititikberatkan pada guru-guru mata pelajaran, maka user

interface ASIK harus disesuaikan dengan rata-rata tingkat kemampuan penggunaan komputer

guru-guru SMA. Oleh karena itu, user interface harus simpel dan mudah penggunaannya.

C. Reliability

Sistem ASIK harus reliable saat dioperasikan, dengan total downtime harian tidak boleh

melebihi 1 jam selama rush hours, yaitu dari jam 07.00 – 14.00.

D. Performance

Stress Requirements : ASIK akan digunakan oleh banyak user, yaitu guru-guru, petugas tata

usaha, murid-murid, dan orang tuanya. Oleh kareng itu, sistem ini harus ditempatkan di server

yang kuat dan dapat mendukung banyak user yang mengakses record secara bersamaan.

Response-time Requirements : Penggunaan ASIK akan diidominasi oleh proses permintaan

untuk melihat data-data. Untuk permintaan semacam ini, response time yang cepat bukan

merupakan kebutuhan utama. Untuk itu, kami membatasi waktu respon maksimal yang

diperbolehkan adalah 0,001 detik.

Throughput Requirements : Kembali mengacu ke stress requirement, ASIK adalah sistem yang

harus memiliki ketahanan untuk diakses oleh banyak user. Untuk mendukung hal ini, ASIK

harus dapat memproses permintaan nilai dari 100 orang/detik.

E. Supportability

Mengacu kepada kemampuan untuk memonitor dan memelihara sistem, melingkupi test,

konfigurasi, instalasi, dan upgrade sistem. Pengembangan ASIK sendiri hanya sampai tahap

analisis requirement dan design, sehingga tahap testing dan maintanance tidak dilakukan.

Namun ada kemungkinan untuk implementasi sistem, jika diminta.

F. Plus (+) : batasan tambahan sistem, yaitu :

■ Design requirements.

■ Implementation requirements: batasan saat konstruksi sistem, yaitu platform, coding

language, dan standards.

■ Interface requirements: kemampuan untuk berinteraksi dengan sistem eksternal (protocol,

format, dsb)

■ Physical requirements: berkaitan dengan hardware, seperti ukuran, temperatur, bahan, dll

■ Legal,compliance, regulatory, dan copyright requirements


4.3 Atribut Kebutuhan

Requirement Atribute Table (RAT) digunakan untuk mendokumentasi atribut requirement,

seperti penanggungjawab, prioritas, dll. Dengan adanya RAT, team member lebih mudah

menentukan status dan prioritas requirement. Dalam penggunaannya, RAT merupakan

komplemen dari Requirement Traceability Matrix (RTM).

Adapun RAT dari sistem ini adalah :

Tabel 4. Requirement Attribute TableNo Req Tanggal

DibuatPenanggung

JawabStatus Metode

verifikasiEffort Prioritas Stabilitas

FR-001 7 Okt 2010 Satriyo Pramono

Approved structured walkthrough

medium

medium high

FR-002 7 Okt 2010 Vania Rahma

Ginting

Approved structured

walkthrough

mediu

m

high high

FR-003 7 Okt 2010 Anthony Nirwana


high high medium

FR-004 7 Okt 2010 Antonia Kalisa


medium medium high

4.4 Requirements Traceability Matrix

Requirement Traceability Matrix (RTM) adalah tabel yang digunakan untuk melacak tiap

requirement ke proses bisnis (backward) dan ke artifak, event, item yang dihasilkan (forward).

Berikut RTM dari sistem :


Tabel 5. Requirement Traceability MatrixNo Req No Resiko Use case

sistemUse case bisnis No Func

ReqSubsystem Element Perancangan Code/Tabel/GUI Test Case Iterasi

RQ-001 RS-001RS-002RS-003RS-007

SUC-001 “Pengaturan Data Siswa”

BUC-001“Melihat Data Siswa”BUC-006“Mengatur Data Siswa”

FR-001 Penyimpanan ke database data siswa

Class Specification:*

Source Code:*

** ***

RQ-002 RS-002RS-003RS-007

SUC-002“Pemasukan Nilai Siswa”

BUC-001“Melihat Data Siswa”BUC-002“Memasukkan nilai siswa”

FR-002 Penyimpanan ke database nilai siswa


Source Code:*

** ***

RQ-003 RS-001RS-002RS-003RS-007

SUC-003 “Pengaturan Nilai Siswa”

BUC-003“Melihat Nilai Siswa”BUC-004 “Mengatur Nilai Siswa”

FR-003 Penyimpanan ke database nilai siswa


Source Code:*

** ***

RQ-004 RS-001RS-002RS-007

SUC-004“Pencetakan Transkrip”

BUC-003“Melihat Nilai Siswa”BUC-005 “Mencetak Transkrip”

FR-004 Pencetakan Transkrip


Source Code:*

** ***

Ket:

*) coding tidak dilakukan

**) tidak ada dokumentasi test case, hanya ada standards dan guidelines, mengacu ke dokumen Business Requirement Document

***) iterasi tidak dapat ditentukan


5. Rencana Manajemen Resiko

5.1 Tujuan

Tujuan pembuatan Rencana Manajemen Resiko adalah untuk memetakan resiko yang mungkin

terjadi, melakukan estimasi efektivitas, dan membuat rencana bagaimana cara merespon resiko

tersebut agar bisa ditanggulangi nantinya.

5.2 Strategi Manajemen Resiko

Strategi manajemen resiko merupakan pendekatan yang digunakan untuk identifikasi, analisis,

dan memberikan prioritas terhadap resiko. Status resiko dan strategi antisipasi adalah dua hal

yang menjadi perhatian utama dalam manajemen resiko.

Status resiko dapat dikelompokkan sebagai berikut :

- E (Extremely High Risk) : tidak bisa diterima jika terjadi, organisasi harus

memperhitungkan apakah aktivitas harus dihilangkan / dimodifikasi

- H (High Risk) : sering terjadi, harus mendapat perhatian khusus

- M (Moderate Risk) : kadang-kadang terjadi, bisa ditanggulangi

- L (Low Risk) : jarang terjadi

Strategi yang dapat diterapkan adalah :

- AVOID : menghindari aktivitas yang dapat menimbulkan resiko

- TRANSFER : memberikan resiko ke pihak ketiga

- ACCEPT : menerima tiap loss atau benefit ketika resiko terjadi

- MITIGATE : mengurangi kemungkinan terjadinya resiko, misalnya

dengan delivering software incrementally, sehingga kesalahan dapat ditanggulangi dengan

segera dan mengurangi effort untuk iterasi.

5.3 Tanggung Jawab dan Akuntabilitas

Pembagian resiko dan penanggungjawabnya adalah seperti tabel di bawah ini :

Tabel 6. Daftar Tanggung Jawab dan Akuntabilitas

No Risk ID Responsibility

1 RS-001 Vania Rahma G

2 RS-002 Anthony Nirwana

3 RS-003 Antonia Riani Kalisa

4 RS-004 Vania Rahma G

5 RS-005 Satriyo Pramono

6 RS-006 Anthony Nirwana

7 RS-007 Antonia Riani Kalisa

8 RS-008 Satriyo Pramono

5.4 Daftar Resiko

Bagian ini berisi daftar resiko proyek beserta statusnya, seperti digambarkan dalam tabel

berikut :

Tabel 7. Daftar Resiko

Risk ID Types of Risk Description Status

RS-001 Electricity failure Apabila terjadi kegagalan listrik (misalnya mati lampu), maka server akan mati juga sehingga data-datanya tidak dapat diakses.

M

RS-002 Security Apabila ID dan password diketahui orang lain yang tidak berwenang, maka data-data (seperti biodata dan nilai siswa) dapat diketahui dan bahkan bisa diubah.

M

RS-003 Human Error Apabila terjadi kesalahan penginputan data, baik biodata maupun nilai siswa, maka akurasi data tidak terjamin.

H

RS-004 Scope Changes Apabila pihak stakeholder menginginkan ekspansi sistem, maka biaya dan waktu yang dibutuhkan juga bertambah.

M


RS-005 Budgeting Pengimplementasian sistem membutuhkan biaya, dengan ROI setelah 6 bulan. Bisa saja terjadi perubahan iklim ekonomi yang menyebabkan waktu ROI tidak tercapai.

L

RS-006 Database Failure Data-data di ASIK semua tersimpan di dalam server database. Apabila terjadi kerusakan pada database, berupa kerusakan hardware (komputer server) atau kerusakan logic pada database maka data tidak dapat diakses. Metode preventif untuk resiko ini adalah dengan melakukan recovery database secara teratur, terutama saat aliran input data sedang deras.

H

RS-007 Government/Authority Regulation

Apabila ada perubahan kebijakan atau regulasi yang bersifat terpusat (misalnya perubahan standar dari Departemen Pendidikan Nasional), maka mungkin saja sistem tidak akan sesuai lagi untuk diimplementasikan dan harus segera diubah dan disesuaikan dengan kebijakan atau regulasi yang baru.

L

RS-008 Network Problems Kualitas jaringan yang kurang memenuhi standar kebutuhan memungkinkan adanya data yang hilang saat akan disimpan pada database server.

M

6. Requirements Acceptance Plan

6.1 Tujuan

Tujuan dari Requirements Acceptance Plan adalah merencanakan bagaimana requirement

dapat diterima melalui serangkaian aktivitas yang harus dijalankan. Hal-hal yang

digarisbawahi dalam hal ini adalah :

● Penentuan ruang lingkup requirement

● Requirements elicitation

● Penentuan prioritas requirement

● Pengujian requirements

● Penentuan acceptance case

● Proses penyetujuan requirement

● Final acceptance


6.2 Tanggung Jawab dalam Requirements Acceptance

Resource yang dibutuhkan dalam Requirement Acceptance Plan (RAP) adalah :

Tabel 8. Tanggung Jawab dalam Requirements Acceptance

Resource Type Responsibilities Name

Project

Manager

- berkomunikasi dengan stakeholder mengenai bentuk dan lingkup RAP

- mengadakan persetujuan mengenai kriteria sebuah requirement dapat diterima

Vania Rahma Ginting

Business

Analyst

- mendeskripsikan test plan - Antonia Riani Kalisa- Satriyo Pramono- Anthony Nirwana

Test Leader - memastikan bahwa test plan telah tersedia untuk semua user

- memastikan bahwa proses testing dilaksanakan sesuai dengan waktu yang telah disepakati

Boedi Santoso

Testers - mengeksekusi test scripts/cases

- memastikan bahwa sistem dapat diterima

- mendokumentasikan hasil test

petugas tata usaha, guru, tim validator

6.3 Kriteria Requirements Acceptance

Kriteria yang akan digunakan untuk menentukan apakah deliverable proyek dapat diterima

adalah :

- Fungsionalitas sistem lengkap dan hasilnya dapat diterima oleh stakeholder.

- Kinerja sistem baik, dalam hal ini berarti non functional requirement terpenuhi.

- Dokumentasi sistem tersedia dan lengkap.

- Keamanan sistem terjaga dan tidak mungkin terjadi penyalahgunaan penggunaan.


6.4 Jadwal Requirements Acceptance

Jadwal untuk Requirements Acceptance adalah sebagai berikut :

Tabel 9. Jadwal Requirements Acceptance

Activity Lead Responsibility Date

Mengidentifikasi dan

memilih testers

Vania Rahma G 18 November 2010

Membuat standar dan

guidelines untuk test

scenarios dan

scripts/cases

Antonia Riani Kalisa 19 November 2010

Memastikan tiap orang-

orang yang

berkepentingan dapat

mengikuti testing

- pengujian sistem

tidak dilakukan

Mereview standar dan

guidelines

scenarios/scripts dari

segi akurasi,

kelengkapan, dan

urutan

Satriyo Pramono

Anthony Nirwana

20 November 2010

Memastikan konfigurasi

lingkungan testing

- pengujian sistem

tidak dilakukan

Melakukan testing

requirement

- pengujian sistem

tidak dilakukan

7. Requirements Management Metrics Plan

7.1 Tujuan


Tujuan dari Reqirement Management Metrics Plan adalah mengukur proses analisis,

mendeskripsikan kebutuhan dan melakukan monitoring dengan pengunaan metric tertentu.

7.2 Tujuan Manajemen Kebutuhan

Tujuan dari penggunaan metrics dalam Requirement Management adalah memudahkan BA

menganalisis kualitas dan kuantitas dari suatu requirement dengan ukuran yang pasti, tidak

berdasar feeling/persepsi semata, dan agar mendapatkan requirement yang benar, kemudian

mengidentifikasi alasan terukur untuk software re-engineering bila diperlukan. Penggunaan

metrics juga memudahkan menentukan goal yang spesifik dan terukur pasti.

7.3 KPI Manajemen Kebutuhan

Key Performance Indicator (KPI) merupakan indikator keberhasilan sebuah use case, meliputi

deskripsi, tujuan, analisis, dan penanggungjawab, seperti dideskripsikan di tabel berikut:

Tabel 10. Key Performance Indicator

No Key Performance Indicator

1 KPI untuk ‘Pengaturan Data

Siswa’

Deskripsi Indikator pengukuran adalah ketepatan data yang ada di

database dengan data siswa sesungguhnya harus 100%.

Tujuan Pengukuran perlu dilakukan untuk melihat keberhasilan

pengimplemetasian use case di sistem akademik.

Analisis Apabila ketepatan tidak sempurna ( <100% ), berarti ada

kesalahan input data dari petugas Tata Usaha.

Tanggung Jawab Satriyo Pramono

2 KPI untuk ‘Pemasukan Nilai’

Deskripsi Indikator pengukuran adalah rentang waktu yang dibutuhkan

dari ulangan dilaksanakan sampai nilai-nilai ulangan masuk ke

database komputer. Cara pengukurannya dengan melakukan

penghitungan rentang waktu dari saat ulangan dilaksanakan

hingga nilai ada di database.



Analisis Rentang waktu menjadi paramater keberhasilan use case.

Semakin kecil interval, semakin baik peran user dalam

penggunaan sistem.

Tanggung Jawab Vania Rahma G


3 KPI untuk ‘Pengaturan Nilai’

Deskripsi Indikator pengukurannya adalah tim validator dapat melakukan

proses melihat nilai di dalam database, kemudian dapat

mengecek kebenarannya dengan buku nilai. Jika ada perbedaan,

tim validator bisa melakukan perubahan entri langsung.

Tujuan Pengukuran indikator perlu dilakukan untuk memastikan

performa pengaturan nilai di ASIK berjalan sesuai permintaan.

Analisis Apabila tim validator tidak dapat melakukan salah satu/semua

fitur berikut :

-lihat nilai

-tambah/hapus

-ubah entri nilai di sistem

maka performa Pengaturan Nilai dianggap tidak berfungsi dan

harus diperbaiki.

Tanggung Jawab Anthony Nirwana

4 KPI untuk ‘Pencetakan

Transkrip’

Deskripsi Indikator pengukurannya adalah kecocokan transkrip nilai yang

hendak diprint dengan output dari pencetakan tersebut.

Dikatakan berhasil apabila kecocokan pencetakan di atas 95%.



Analisis Apabila ternyata presentase kecocokan berada di bawah 95%,

maka perlu dilakukan maintenance terhadap program dan

hardware, berupa printer.

Tanggung Jawab Antonia Riani Kalisa


Daftar referensi

http://media.wiley.com/product_ancillary/01/07821360/DOWNLOAD/Checklist%20of%20CPR.pdf

http://www.uservices.umn.edu/pmo/docs/Test/TEMPLATE_UAT_Plan.doc

http://www.lbjsc.txstate.edu/caso/soc/forms/contentParagraph/03/text_files/file1/RiskAssessmentM.pdf


http://www.uservices.umn.edu/pmo/docs/Test/TEMPLATE_UAT_Plan.doc



Documents

Requirement Work Plan - Kelompok 7 - 18208002