SIPROKA FKUI

Fakultas Kedokteran Universitas Indonesia

Sistem Informasi Pengelolaan Program Kerja dan Anggaran FKUI

Requirements Management Plan

Version 1.1

SIPROKA FKUI Version: 1.1 Requirements Management Plan Date: 10.01.2007

Confidential FKUI, 2007

Revision History Date Version Description Author

02.10.2006 0.9 Perumusan Awal Aria Kekalih

22.11.2006 1.0 Revisi Aria Kekalih

10.01.2007 1.1 Revisi setelah presentasi Isnanto Nugroho



Table of Contents

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

2. Requirements Management 4 2.1 Organization, Responsibilities, and Interfaces 4 2.2 Contact Table 5

3. Requirements Artifacts 6 3.1 Artifact Description 6

3.1.1 Document Types 6 3.1.2 Requirement Types 7 3.1.3 Attributes 7 3.1.4 Attribute Values 9

3.2 Traceability 10 3.2.1 Traceability Criteria for Requirement Types 10 3.2.2 NEED to STRQ Traceability 11

3.3 Reports and Measures 11

4. Requirements Change Management 12 4.1 Change Request Processing and Approval 12



Requirements Management Plan

1. 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 pembuatan dokumen Requirement Management Plan ini adalah untuk mendefinisikan skema kebutuhan sistem dan atribut-atributnya. Dokumen perencanaan ini menggunakan pendekatan sistematis untuk melakukan pencarian, pengorganisasian dan dokumentasi kebutuhan sistem, yang dimaksudkan untuk menjembatani kesepakatan antara FKUI dengan tim konsultan pengembang dalam mengelola setiap perubahan kebutuhan sistem

1.2 Scope Ruang lingkup Requirement Management Plan ini hanya terbatas pada proyek sistem informasi manajemen keuangan .

1.3 Definitions, Acronyms, and Abbreviations Definisi dan singkatan yang terdapat dalam dokumen ini dapat dilihat pada dokumen Glossary.

1.4 References Kruchten, Philippe. 1999. The Rational Unified Process. Menlo Park, CA: Addison Wesley

Leffingwell, D. and Don Widrig. 2000. Managing Software Requirements. Menlo Park, CA: Addison Wesley.

Spence, I. and L. Probasco. 1998. Traceability Strategies for Managing Requirements with Use Cases. Cupertino, CA: Rational Software Corporation. Available at www.rational.net.

The ClassicsCD Change Management Plan. For access and information, consult with Xavier Sanchez-Tobar, Change Control Manager, at [email protected]

1.5 Overview Dokumen ini berisikan rincian khusus dan strategi untuk mengelola kebutuhan proyek Manajemen Keuangan FKUI. 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 berikut

Jabatan Tanggung Jawab Project manager Individu yang bertanggungjawab penuh atas keberlangsungan proyek. Manajer

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



Quality assurance (QA)

Fungsi dari Quality Assurance adalah sebagai pihak yang bertanggungjawab atas kepastian bahwa standar dari proyek telah dijalankan dengan benar serta melaporkan semua hasil pemantauan ke manajer proyek.

Developer Seseorang 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 leader Pemimpin 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.

Configuration manager

Manajer konfigurasi bertanggungjawab untuk menyusun strukur produk dalam manajemen perubahan, mendefinisikan dan mengalokasikan ruang kerja baik pengembang, dan melakukan integrasi. Manajer konfigurasi dan melaporkan hasil kegiatannva kepada manajer proyek.

Requirements specifier

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

Change Control Manager

Manajer ini berperan mengawasi perubahan-perubahan proses. Pekerjaan ini biasanya dimainkan oleh Configuration/Change Control Board(CCB) dan terdiri dari perwakilan semua kelompok, termasuk customer, developer, dan users. Didalam ukuran proyek kecil, seorang angota team, seperti Project Manager atau Software Architect, memegang peranan ini.

2.2 Contact Table

Role Name Title Organization Contact

customer (for beta testing)

Farian Staf divisi keuangan FKUI [email protected]

stakeholder Menaldi Rasmin

Dekan FKUI [email protected]

Boy Sabarguna Manajer Keuangan FKUI [email protected]

project manager Aria Kekalih Asisten Manajer IT FKUI [email protected]

quality assurance Ali Sungkar Manajer IT FKUI [email protected]

team leader Wahyono Sumardji

Senior Developer FKUI [email protected]

requirements specifier

M. Syafii Software Project Manager

FKUI [email protected]

Isnanto Nugroho

Senior Developer Consultant

Konsultante

administrator Budi Santoso IT director FKUI [email protected]

configuration Fajar DP Senior Software Konsultante [email protected]



manager Engineer

Nana Suryadigama

Senior Software Engineer

Konsultante [email protected]

change control manager

M.Yusuf FKUI [email protected]

3. Requirements Artifacts

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

3.1.1 Document Types

Tabel dibawah ini menggambarkan tipe-tipe dokumen yang akan dibuat dalam mengelola kebutuhan proyek Manajemen Keuangan FKUI.

Document Type Description Default Requirement Type

Stakeholder Requests (STR)

Kebutuhan utama stakeholders/pengguna Stakeholder Request (STRQ)

Vision (VIS) Kondisi atau kemampuan dari sistem yang akan ingin dibangun untuk mewujudkan keinginan stakeholder

Product Feature (FEAT), Need (NEED)

Use-Case Specification (UCS)

Deskripsi dan pengembangan use case, berisi tentang alur standar dan alternatif dari sebuah proses.

Use Case (UC)

Glossary (GLS) Digunakan untuk mencatat semua kosakata yang umum digunakan dalam seluruh dokumen

Glossary Term (TERM)

Supplementary Requirements Specification (SUP)

Menggambarkan kebutuhan system yang tidak dapat digambarkan dalam use case

Supplementary Requirement (SUPP)

Requirements Management Plan (RMP)

Menggambarkan kebutuhan danstrategi tertentu untuk pengelolaan dan pengembangan proyek



3.1.2 Requirement Types

Requirement Type Description Attributes

Stakeholder Request (STRQ)

Permintaan dari para stakeholder yang berasal dari analisa yang dilakukan kepada stakeholder

Priority , Status , Difficulty, Risk

Need (NEED) Kebutuhan sistem yang telah digabungkan antara permintaan dari stakeholder dan hasil analisis dari developer

Priority ,Origin, Current Solution, Proposed Solution

Feature (FEAT) Layanan yang seharusnya disediakanoleh sistem, yang secara langsung memenuhi kebutuhan stakeholder

Priority, Status, Difficulty, Stability,

Risk

Use Case (UC) Deskripsi perilaku sistem yang digambarkan dalam urutan tindakan. Sebuah use case seharusnya menghasilkan keluaran yang dapat dirasakan oleh seorang aktor


Risk, Affect Architect, Planner Iteration.

Glossary term (TERM) Istilah yang digunakan dalam kosakata umum proyek Manajemen Keuangan FKUI.

Ambiguity


Deskripsi kebutuhan yang tidak dapat digambarkan secara langsung oleh use case


Risk.

3.1.3 Attributes

Attribute Description Type List Values Requirement Type

High

Medium

Priority

Diatur oleh analis.

Menunjukkan prioritas pclanggan untuk mengimplementasikan kebutuhan.

Digunakan pada pengelolaan ruang lingkup dan menjelaskan prioritas pengembangan.

List

Low

FEAT, UC, SUPP, STRQ

Proposed

Approved

Status Disetting oleh analis dan quality assurance.

Menunjukkan batasan kebutuhan.

List

Incorporated




Digunakan dalam pengelolaan ruang lingkup dan menjelaskan status proyek.

Validated

High

Medium

Difficulty

Diatur oleh manajer pengembang.

Menunjukkan tingkatan usaha yang dikumpulkan dengan kebutuhan.

Digunakan dalam pengelolaan ruang lingkup dan nlenjelaskan prioritas pengembangan.

List

Low


High

Medium

Stability

Diatur oleh analis dan tim pengembangan.

Menunjukkan kemugkinan bahwa kebutuhan akan mengalami perubahan.

Digunakan untuk meningkatkan prioritas pengembangan dan untuk menlelaskan apakah informasi tambahan dibutuhkan.

List

Low

FEAT, SUPP

Current Solution Digunakan untuk menjelaskan asal sumber pertimbangan tambahan kebutuhan.

text n/a

NEED

Proposed Solution Untuk menjelaskan usulan-usulan tambahan kebutuhan pada saat pengembangan sistem.

text n/a

NEED

Planner Iteration. Proses perencanaan untuk mengevaluasi kebutuhan tambahan telah memenuhi keperluan.

text

n/a

NEED

Stakeholder

Origin

Origin (Asal) dari dari requirement type ini apakah berasal dari analisa stakeholder request atau dari analisis dari tim

List

Analysis

NEED

High

Medium Risk. Pertimbangan yang diambil mengenai risiko yang kan terjadi pada saat pengembangan Sistem.

List

Low

STRQ, FEAT, UC, SUPP



3.1.4 Attribute Values

Value Attribute Description

High Priority Sangat kritis untuk kesuksesan/ketahanan bisnisatau suatu order langsung dan investor atau pemegang kunci account.

Medium Priority Bermanfaat, menambah nilai kompetitif dan feature yang unik.

Low Priority Memungkinkan namun tidak terlalu membawa manfaat.

Proposed Status Diajukan oleh suatu permintaan stakeholder.

Approved Status Disetujui oleh manajer proyek dan atau penjamin kualitas

Incorporated Status Siap dijalankan.

Validated Status Diuji oleh penjamin kualitas.

High Difficulty Sangat sukar, misalnya untuk menyetujuinya sangat mahal dalam hal sumber daya ataupun uang. Seharusnya diserang dahulu atau ditolak/dibatalkan.

Medium Difficulty Sulit tetapi dapat dilakukan tanpa menanggung resiko. Seharusnya hanya dikerjakan setelah seluruh requirement yang tinggi dan sulit telah dipenuhi ataupun dibatalkan.

Low Difficulty Mudah. Bisa dipenuhi terakhir setelah semua yang penting diselesaikan.

High Stability Sepertinya akan berubah, atau hal ini masih terlihat sangat samar dan membutuhkan penjelasan lebih lanjut untuk dikerjakan..

Medium Stability Bisa berubah namun masih cukup stabil untuk memulai pekerjaan.

Low Stability Hampir dipastikan tidak berubah, dapat dipenuhi pada akhir proses.

Stakeholder Origin Berasal dari stakeholder (stakholder request)

Analysis Origin Berasal dari analisis tim

High Risk Membutuhkan waktu sangat lama dalam development dan secara

teknologi kurang dikuasai

Medium Risk Membutuhkan waktu sedang dalam development dan teknologi agak dikuasai

Low Risk Membutuhkan waktu singkat dalam development dan teknologi sangat dikuasai



3.2 Traceability Kita akan mengikuti strategi pelacakan seperti dibawah ini. Use case dan requirement supplemetary akan melacak hingga produk feature yang sejelas-jelasnya.

3.2.1 Traceability Criteria for Requirement Types

Requirement Type Guidelines Notes

Stakeholder Request (STRQ)

Satu atau lebih STRQ dapat memiliki trace ke satu NEED, namun juga bisa tidak memiliki trace jika dirasa perlu

Need (NEED) Satu NEED dapat di trace ke satu atau lebih STRQ, namun dapat juga tidak ada trace ke STRQ nya jika NEED tersebut berasal dari hasil analisis tim

Value dari attribute Origin menentukan asal dari NEED tersebut

Feature (FEAT) Setiap FEAT harus dapat ditrace ke satu atau lebih NEED

Gunakan query pada paket Coverage Analysis untuk memeriksa cakupannya.

Use Case (UC) Setiap kebutuhan use case harus ditelusuri ke kebutuhan FEAT.

Gunakan query pada paket coverage analisis untuk melakukan pemeriksaan.


Satu SUPP harus dapat di trace ke satu atau lebih FEAT

Stakeholder Request

Need

Feature

Use Case Supplementary



3.2.2 NEED to STRQ Traceability

Traceability NEED dan STRQ dapat digambarkan sebagai berikut. NEED dan STRQ merupakan himpunan yang saling beririsan. Need yang akan didapat berasal dari dua hal yaitu need yang berasal dari STRQ dan need yang berasal dari hasil analisis dari tim. Sedangkan STRQ yang tidak diteruskan berasal dari berbagai alasan antara lain adalah keputusan manajemen untuk meletakkan nya di luar scope dan lain lain.

3.3 Reports and Measures Reports are provided by RequisitePro saved views.

View Descriptions:

Query Name Description Package Benefit of View

All Features Seluruh fitur produk clan atributnya

Features and Vision Prioritas feature

All Need List seluruh need yang ada

Need Mengetahui semua need yang ada

All Glossary Terms

Seluruh istilah pada Glossary

Glossary Pencarian cepat ke Glossary

All Supplementary Requirements

Seluruh kebutuhan dari tipe kebutuhan Supplementary

Supplementary Reqts Prioritas non-functional requirement

All Use Cases Seluruh kebutuhan use-case

Use Cases Prioritas use-case

NEED STRQ

NEED yang berasal dari hasil analisa NEED yang

berasal dari STRQ

STRQ yang tidak diteruskan



Use Case Brief Descriptions

Keseluruhan use-case dan penjelasan singkatnya-

Use Cases Penjelasan-penjelasan use-case

Features Not Traced in Supplementary Specs

Daftar dari fitur yang tidak terhubung ke kebutuhan non functional

Coverage Analysis Laporan dari semua feature produk yang belum dijelaskan pada non-functional requirement.

Features Not Traced in Use Cases

Daftar feature yang tidak terkait dengan use-case

Coverage Analysis Laporan ke semua feature proruk yang belum dijelaskan pada sekelompok use-case.

Full Coverage Report

Pohon pelacakan keseluruh jalur.

Coverage Analysis Memperlihatkan seluruh hubungan yang sudah ada dalam proyek

Functional Requirements Coverage

Daftar hubungan fitur ke usecase

Coverage Analysis Menunjukkan hubungan yang ada untuk bagian fungsional dari sistem.

Supplementary Requirements Affected by Feature Changes

Daftar kebutuhan supplementary yang potensial dipengaruhi oleh perubahan feature produk

Impact Analysis Menunjukan kebutuhan sumplementari yang mungkin bisa mengubah feature dari produk.

Use Cases Impacted by Feature Changes

Daftar use case yang berpotensi berpengaruh dengan mengubah feature produk.

Impact Analysis Kesadaran perubahan fitur terhadap kebutuhan non functional.

4. Requirements Change Management

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.



Page 1


Stakeholder Requests

Version 1.1

SIPROKA FKUI Version: 1.1 Stakeholder Request Date: 07.01.2007


Page 2


02.10.2006 0.5 First Draft Aria Kekalih

22.10.2006 0.9 Revisi 1 Aria Kekalih

11.12.2006 1.0 Final Version sebelum presentasi Nana Suryadigama

07.01.2007 1.1 Revisi berdasarkan masukan yang didapat saat presentasi

Isnanto Nugroho



Page 3

Table of Contents

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

2. Establish Stakeholder or User Profile 4

3. Assessing the Problem 7

4. Understanding the User Environment 8

5. Recap for Understanding 8

6. Analyst’s Inputs on Stakeholder’s Problem (validate or invalidate assumptions) 9

7. Assessing Your Solution (if applicable) 9

8. Assessing the Opportunity 9

9. Assessing Reliability, Performance, and Support Needs 10 9.1 Other Requirements 11

10. Wrap –Up 11

11. Analyst’s Summary 12



Page 4

Stakeholder Requests 1. Introduction FKUI memiliki visi untuk menjadi fakultas kedokteran terkemuka Asia Pasifik 2010 mengupayakan efisiensi, sinkronisasi dan implementasi program kerja yang terencana dan akuntabel. Setelah perubahan status menjadi BHMN, strategi manajemen mengalami perubahan khususnya dalam hal kebijakan efisiensi pelaksanaan program kegiatan dan alokasi anggaran.

Dalam menyusun program kerja, FKUI melibatkan berbagai unit manajemen dan departemen. Banyaknya pihak yang terlibat dalam perencanaan kegiatan seharusnya tidak menjadi suatu hambatan yang memperlambat alur pengambilan keputusan strategis mengenai kegiatan yang akan dilaksanakan serta penggunaan anggaran. Oleh karena itu, diperlukan mekanisme pelaporan untuk proposal kegiatan yang masuk, penyesuaian kegiatan dengan rencana strategis dan kondisi keuangan, serta suatu rekapitulasi komprehensif mengenai laporan akhir seluruh kegiatan FKUI (pencapaian dan anggaran)

Untuk mencapai tujuan visi dan memenuhi kebutuhan FKUI berencana mengembangkan suatu Sistem Informasi Pengelolaan Program Kerja dan Anggaran

1.1 Purpose Tujuan dari penyusunan dokumen ini adalah untuk mengumpulkan dan menginventarisir seluruh kebutuhan dan permasalah yang dihadapi oleh para stakeholder. Sehingga didapat informasi komprehensif dan detail yang akan digunakan dalam membangun sistem informasi Pengelolaan Program Kerja dan Anggaran yang mampu mendukung mekanisme pelaporan; proposal kegiatan yang masuk, penyesuaian kegiatan dengan rencana strategis dan kondisi keuangan, serta suatu rekapitulasi mengenai laporan akhir seluruh kegiatan FKUI (pencapaian dan anggaran). Dengan adanya sistem informasi yang akan dikembangkan ini tentunya akan memperbaiki kondisi yang ada sekarang dan meningkatkan kinerja FKUI dalam mencapai visi yang telah di canangkan.

1.2 Scope Ruang lingkup proyek ini melibatkan lingkup manajemen internal FKUI dari dekan, wakil dekan, manajer dari delapan departemen yang ada, para staf dan sekretariat, serta pelaksana atau pengusul kegiatan seperti departemen, staf pengajar, administrasi, mahasiswa dan lain-lain. Pihak luar yang dapat mengaudit sistem ini hanyalah rektorat yang mengevaluasi kinerja dekan

1.3 Definitions, Acronyms, and Abbreviations Informasi mengenai ini tersedia di glossary proyek.

1.4 References Rencana Strategi FKUI 2006-2010

Laporan keuangan tahunan 2004

Standard Operational Prosedur penyusunan kegiatan dan anggaran FKUI.

Laporan pertanggung jawaban kegiatan departemen.

1.5 Overview Dokumen stakeholder request ini berisi mengenai profile, permasalahan dan kebutuhan yang diperlukan oleh stakeholder di FKUI.

2. Establish Stakeholder or User Profile Company / Industry: Fakultas Kedokteran Universitas Indonesia



Page 5

Name: dr. Menaldi Rasmin, Sp(K), FCCP Job Title: Dekan What are your key responsibilities? Salah satu pengambil keputusan persetujuan dalam

pembuatan sistem informasi Pengelolaan Program Kerja dan Anggaran.

What deliverables do you produce? Surat keputusan persetujuan. For whom? Proyek pengembangan sistem informasi Pengelolaan

Program Kerja dan Anggaran. How is success measured? Dengan tersedianya informasi mengenai laporan kegiatan

dan pengunaan dana secara akurat, lengkap, dan detail yang diselenggarakan oleh seluruh civitas akademi di FKUI.

What problems interfere with your success? Pengukuran tingkat effesiensi pengunaan anggaran dana dalam kegiatan yang telah dilakukan selama ini.

What, if any, trends make your job easier or harder? Adanya kemajuan teknologi informasi, maka dapat dibangun sistem informasi yang berbasis komputerisasi.

Company / Industry: Fakultas Kedokteran Universitas Indonesia Name: Dr. dr. Boy S. Sabarguna. MARS Job Title: Manajer Keuangan What are your key responsibilities? Penangung jawab dari proyek pengembangan sistem

informasi Pengelolaan Program Kerja dan Anggaran. What deliverables do you produce? Surat keputusan pengunaan dana pengembagan proyek. For whom? tim pengembangan proyek. How is success measured? Dengan terlaksananya proses pengajuan anggaran dana

kegiatan dan laporan pertanggung jawaban pengunaan dana yang lebih terkendali dan dapat diawasi secara transparan dalam waktu yang lebih singkat.

What problems interfere with your success? Bagaimana mengembangkan sistem dengan tepat waktu, sesuai biaya yang tersedia.

What, if any, trends make your job easier or harder? Tersedianya program pengembangan sistem informasi yang bersifat open source.

Company / Industry: Fakultas Kedokteran Universitas Indonesia Name: Farian Job Title: Bendahara Departmen Keuangan What are your key responsibilities? Penanggung jawab dalam pengelolaan dana sesuai

tingkat kebutuhan kegiatan. What deliverables do you produce? Laporan pengeluaran dana tahunan. For whom? Manajer Keuangan, Dekan. How is success measured? Tercapainya keseimbangan pengunaan dana kegiatan. What problems interfere with your success? Mendapatkan arsip-arsip laporan pengunaan dana yang

terukur secara seimbang dengan rencana program. What, if any, trends make your job easier or harder? Komputerisasi secara sistem mempermudah kinerja. Company / Industry: Fakultas Kedokteran Universitas Indonesia Name: Astrid S.A. Job Title: Akuntan Departmen Keuangan What are your key responsibilities? Membuat laporan keuangan dalam membentuk neraca

keuangan, baik yang bersifat bulanan, tahunan dari seluruh kegiatan maupun hanya perkegiatan.



Page 6

What deliverables do you produce? Lapoaran neraca keuangan. For whom? Manajer Keuangan, Dekan. How is success measured? Terpenuhinya suatu Neraca keuangan FKUI, yang sesuai

dengan laporan pertanggung jawaban seluruh kegiatan. What problems interfere with your success? Adanya masalah tertentu dalam kegiatan yang kurang

effesien dalam pembuatan neraca dan pelaporan kurang lengkapnya persyaratan Laporan pertanggungjawaban

What, if any, trends make your job easier or harder? Proses komputerisasi dengan sistem yang memeliki database yabng akurat dan terpecaya.

Company / Industry: Fakultas Kedokteran Universitas Indonesia Name: Asih Komara Job Title: Administrasi Departemen Keuangan What are your key responsibilities? Membuat surat –surat yang berhubungan dengan

pengunaan dana dan kegitaan, serta memastikan proposal dan laporan pertanggungjawaban yang diserahkan dari tim panitia.

What deliverables do you produce? Lembaran surat-surat kegiatan yang diselengarakan di FKUI.

For whom? Bagian Bendahara, Operasional. How is success measured? Tertatanya informasi yang cepat dan akurat untuk

mengetahui status dari proposal dan laporan pertanggung jawaban kegiatan.

What problems interfere with your success? Pengerjaan yang belum tersimpat dalam suatu database. What, if any, trends make your job easier or harder? Pengunaan sistem informasi yang terintegrasi dengan

datacenter. Company / Industry: Fakultas Kedokteran Universitas Indonesia Name: Mr. A Job Title: Sekretariat What are your key responsibilities? Melakukan koordinasi kinerja yang dilakerjakan di

departement keungan dalam pengunaan dana kegiatan. What deliverables do you produce? Memberikan sistem standard kerja selama ini, dan

laporan kesesuai setiap kegiatan dengan strategi yang telah ditetapkan.

For whom? Manajer Keuangan , dan staff lain di department keuangan.

How is success measured? Tersedianya informasi dan data dari aktifitas yang dikerjakan di departemnt keuangan.

What problems interfere with your success? Bagaimana meningkat kecepatan dalam memberikan laporan dari aktifitas

What, if any, trends make your job easier or harder? Pengunaan sistem informasi dengan database. Company / Industry: Fakultas Kedokteran Universitas Indonesia Name: Dr. Ali Sungkar, SpOG Job Title: Manajer TI What are your key responsibilities? Melakukan koordinasi dan penangungjawab operasional

dalam pengembagan sistem informasi keungan FKUI. What deliverables do you produce? Memberikan layanan-layanan yang berhubungan dengan



Page 7

pengembangan sistem informasi Pengelolaan Program Kerja dan Anggaran.

For whom? Penguna sistem. How is success measured? Sistem informasi berjalan sesuai dengan tepat waktu dan

menghasilkan ouput sesuai target yang ditetapkan. What problems interfere with your success? Bagaimana mengembankan sistem informasi dengan

tingkat effesien yang tinggi dan menghasilkan kinerja yang efektif dan memenuhi kebutuhan penguna.

What, if any, trends make your job easier or harder? Tersediannya program language, database yang bersifat open source dan konsultan IT yang memberikan dukungan yang kuat.

Company / Industry: Fakultas Kedokteran Universitas Indonesia Name: (Manajer Ditiap divisi) Job Title: Manajer divisi di FKUI What are your key responsibilities? Melakukan koordinasi dengan staff di divisi masing –

masing dalam pengajuan proposal kegiatan dan laporan pertanggungjawaban kegiatan.

What deliverables do you produce? Memberikan laporan pertanggung jawabab pengunaan dana kegiatan dari setiap proposal yang disetujui.

For whom? Department Keuangan. How is success measured? Tersedianya informasi yang cepat dari persetujuan

proposal yang diajukan dan besar pengunaan dana yang disetujui serta kelengakapan proposal dan laoran pertanggung jawaban kegiatan..

What problems interfere with your success? Bagaimana membuat proposal yang standard dan sesuai dengan program kerja sesuai visi FKUI.

What, if any, trends make your job easier or harder? Pengunaan sistem informasi dengan database.

3. Assessing the Problem

Masalah :

1. Belum terintegrasinya pendataan proposal kegiatan yang masuk, karena kegiatan yang ada sangat banyak dan melibatkan berbagai pihak

2. Terlambatnya proses penyetujuan anggaran karena birokrasi dan kurang efisiennya proses administrasi

3. Kurangnya informasi yang detail dan lengkap mengenai kegiatan yang telah disetujui anggarannya, telah dilaksanakan serta anggaran yang telah digunakan.

4. Sulit dalam melakukan evaluasi keuangan dan kinerja operasional tiap program kerja dalam waktu yang dibutuhkan.

5. Masih belum didapat parameter pengukuran dari kegiatan yang diselengarakan dengan tingkat kesesuai visi yang ditetapkan.

6. Adanya program kerja kegiatan yang bersifat ganda dikarena kurang koordinasi dengan berbagai department dengan rencana strategi yang telah disusun.

7. Masih kurangnya informasi yang dapat dengan cepat diperoleh mengenai kegiatan yang pernah dilakukan sebagai bahan referensi dalam penyusunan proposal kegiatan selanjutnya.

8. Tingkat kesiapan yang masih memiliki kompleksitas tinggi dalam memberikan laporan dari manjemen keuangan pada saat dilakukan proses audit.



Page 8

4. Understanding the User Environment Who are the users? Pimpinan fakultas, para manajer khususnya manajer

keuangan, staf fakultas, serta staf pengajar dan departemen.

What is their educational background? Bervariasi, minimal D3 What is their computer background? Telah familiar dengan pengunaan computer baik didapat

secara kursus maupun pelatihan yang ada. Are users experienced with this type of application? Saat ini pekerjaan dilakukan dengan menggunakan

berbasis windows, bisa dikatakan tidak mengunakan berbasis DOS.

Which platforms are in use? Pada dasarnya, sistem operasi yang berbasis interface seperti windows tidak sulit dipelajari.

What are your plans for future platforms? Web based yang terintgrasi menggunakan intranet fakultas

Which additional applications do you use that we need to interface with?

Inteface yang digunakan adalah diutamakan mengunakan program language yang bersifat open source dan dengan mudah dipelajari oleh setiap penguna.

What are your expectations for usability of the product?

Semua pihak yang terlibat mampu menggunakannya

What are your expectations for training time? Sesuai tingkat kesulitan dari tiap modul interface, namun disini untuk kesulitan tertinggi adalah 2 hari.

What kinds of hard copy and online documentation do you need?

Laporan rekapitulasi dan laporan keuangan harus tersedia secara online dengan otorisasi terbatas.

Persetujuan Proposal.

Laporan kegiatan terdahulu.

5. Recap for Understanding No Permasalahan Solusi yang diusulkan 1 Belum terintegrasinya pendataan proposal kegiatan yang masuk, karena

kegiatan yang ada sangat banyak dan melibatkan berbagai pihak Melakukan koordinasi yang intensif dari seluruh civitas akademi FKUI, terutama yang berkaitan langsung dalam pengembangan sistem informasi Pengelolaan Program Kerja dan Anggaran yang berbasis web dan memiliki database, serta mempunyai modul-modul layanan interface yang dibutuhan dari setiap penguna.

2 Terlambatnya proses penyetujuan anggaran karena birokrasi dan kurang efisiennya proses administrasi

s.d.a

3 Kurangnya informasi yang detail dan lengkap mengenai kegiatan yang telah disetujui anggarannya, telah dilaksanakan serta anggaran yang telah digunakan.

s.d.a



Page 9

4 Sulit dalam melakukan evaluasi keuangan dan kinerja operasional tiap program kerja dalam waktu yang dibutuhkan

s.d.a

5 Masih belum didapat parameter pengukuran dari kegiatan yang diselengarakan dengan tingkat kesesuai visi yang ditetapkan.

s.d.a

6 Adanya program kerja kegiatan yang bersifat ganda dikarena kuarang koordinasi dengan berbagai department dengan rencana strategi yang telah disusun.

s.d.a

7 Masih kurangnya informasi yang dapat dengan cepat diperoleh mengenai kegiatan yang pernah dilakukan sebagai bahan referensi dalam penyusunan proposal kegiatan selanjutnya.

s.d.a

8 Tingkat kesiapan yang masih memiliki komplesksitas tinggi dalam memberikan laporan dari manjemen keuangan pada saat dilakukan proses audit.

s.d.a

6. Analyst’s Inputs on Stakeholder’s Problem (validate or invalidate assumptions) Bagian ini menjelaskan problem-problem yang belum dibahas dan disebutkan pada bagian recap for understanding.

Pada bagian ini lebih difokuskan di tingkatan teknikal.

1. Browsers yang digunakan oleh penguna bisa saja bervariasi ini diperlukan standarisasi.

2. Kesalahan entri data oleh user, perlu dilakukan validasi yang ketat dalam sistem.

3. Adanya kemungkinan sharing password, perlu dilakukan tingkat sekuriti yang lebih terjamin.

4. Belum tersedianya infrastruktur di beberapa tempat, membutuhkan tambahan waktu dalam pengembangan.

5. Tingkat spesifikasi PC yang berbeda, perlu dilakukan stadarisasi hardware minimal.

6. Tingginya tingkat proses sistem di waktu-waktu tertentu, perlu dilakukan tes kesiapan uptime yang

maksimum.

7. Tersedianya tingkat kepercayaan yang tinggi dari setiap informasi dan data yang ada dalam database,

dimana diperlukan kebijakan authorisasi yang dapat melakukan modifikasi data (Update, Edit, Delete).

7. Assessing Your Solution (if applicable)

• Solusi yang diusulkan harus mampu memberikan kemudahan dalam perolehan data yang diperlukan secara real time, akurat dan dapat di integrasikan dengan sistem lainnya.

• Prioritas utama yang diberikan sistem ini adalam seluruh informasi yang berkaitan dengan pengunaan dana dan kegiatan yang diadakan di FKUI.

8. Assessing the Opportunity Who needs this application in your organization? Seperti yang telah dijelaskan sebelumnya, aplikasi ini dibutuhkan oleh Dekan , manajer keuangan, staff didepartment keuangan, seluruh manajer dan staffnya didepartament masing-masing yang terlibat dalan proses penyelergaraan kegiatan di FKUI. Dengan adanya sistem informasi Pengelolaan Program Kerja dan Anggaran maka kinerja, effesiensi, efektifitas di FKUI dapat tercapai sesuai visi dan misi.



Page 10

How many of these types of users would use the application? Sistem informasi Pengelolaan Program Kerja dan Anggaran yang akan diterapkan akan menganti proses manual yang dikerjakan dengan mengunakan microsoft office dengan pendataan yang decentralisasi menjadi data ceter namun dapat diakses oleh yang membutuhkan sesuai tingkatan. Bila dilakukan perhitungan secara prediksi system informasi ini akan digunakan kurang lebih diatas 30 penguna dengan tingkat uptime sistem mampu dijalankan selama 24 jam sehari dan 7 hari seminggu secara online terus menurus.

How would you value a successful solution?

Tersedianya data yang akurat , detail, lengkap dengan pengelolaan yang terintegrasi dalam memberikan layanan seluruh kegiatan di FKUI. Diharapkan mampu memberikan tingkat effesiensi dan flesibilitas dalam mendukung kegiatan di FKUI. Dengan adanya sistem informasi manjemen keuangan ini memberikan nilai tambah dari segi keprofesionalisme dalam organisasi dan kapabiltas serta responsibility dalam pengunaan dana di setiap kegiatan, menjadikan modal dalam mencapai visi yang ditetapkan.

9. Assessing Reliability, Performance, and Support Needs

What are your expectations for reliability?

Dibutuhkan sistem yang mampu memberikan layanan selama 24/7 secara online terus menerus, namun diutamakan pada jam kerja. Sehingga penguna dapat memanfaatkan seluruh data yang masuk menggunakan tingkat otoritas yang berbeda tergantung pengguna. Data yang telah masuk dapat ditampilkan secara real time oleh pihak yang yang memiliki otoritas

What are your expectations for performance?

Cepat dalam penyajian data yang dibutuhkan oleh penguna, dan kinerja aplikasi harus stabil dalam mendukung pengolahan informasi.

Will you support the product, or will others support it?

Ya , Sistem Informasi Pengelolaan Program Kerja dan Anggaran (SIPROKA) FKUI ini harus mendapat dukungan yang penuh dan kuat dari semua level manajemen FKUI. Dikarenakan sistem ini nantinya memiliki banyak parameter pengukur tingkat keberhasilan dari berbagai aktifitas kegiatan yang diselengarakan di civitas akademi FKUI.

Do you have special needs for support?

Secara khusus tidak, dukungan yang diberikan adalah komitment untuk penerapan SIPROKA ini sesuai kebutuhan yang telah ditetapkan, sehingga permasalahan yang dihadapi saat ini dapat diselesaikan dan visi dapat dicapai sesuai waktu yang ditergetkan.

What about maintenance and service access?

Terutama pada bagian perawatan server aplikasi dan database perlu dilakukan proses backup data secara berkala.

What are the security requirements?

Aplikasi ini harus aman dari kemungkinan terobos oleh pihak lain karena tingkat kepentingan data yang ada didalamnya sangat tinggi. Jaringan berupa jaringan secure

What are the installation and configuration requirements?

Instalasi bisa dilakukan dalam seluruh PC yang akan dilibatkan sebagai entry post sistem ini.



Page 11

What are the special licensing requirements?

Perijinan telah dilakukan dari awal, dimana hanya tempat tertentu yang akan dipasang PC dan aplikasi ini. Dan selebinya kan diutamakan pemilihan software yang bersifat opensource.

How will the software will be distributed?

Software ini akan didistirbusi hanya didistribusikan dikalangan internal FKUI.

What are the labelling and packaging requirements?

Harus menggunakan logo FKUI

9.1 Other Requirements

Which, if any, regulatory or environmental requirements or standards must be supported?

Yaitu pada saat implementasi terutama pada training untuk sosialisasi yang dilanjutkan pada tahapan sebenarnya. Disini dibutuhkan suatu regulasi dari pihak dekanat untuk memberikan kebijakan yang mengikat kepada semua department untuk menerapkan dan melaksanakan peraturan penyelengaran kegiatan sesuai proses bisnis/akademi FKUI (rencana strategi FKUI) yang telah dijalankan dengan mengunakan system informasi (SIPROKA). Standard yang telah ditetapkan dalam pengunaan SIPROKA harus benar-benar dijalankan secara disiplin.

Can you think of any other requirements we need to know about?

Pada dasarnya pengembangan Sistem Informasi Pengelolaan Program Kerja dan Anggaran (SIPROKA) FKUI ini dilakukan secara menyeluruh dan detail, tapi disini tidak menutup kemungkinan adanya perubahan requirement yang disebabkan oleh adanya perubahan-perubahan dari pihak rektorat, department pendidikan, pemerintah yang mengharuskan pihak FKUI melakukan penyesuai-penyesuaian. Informasi mengenai hal ini harus diketahui secepat mungkin dan perlu dilakukan analisa segera mungkin agar didapat kebutuhan dari manajemen perubahan yang harus dikerjakan kembali pada SIPROKA.

10. Wrap –Up

Are there any other questions I should be asking you?

If I need to ask follow-up questions, may I give you a call?

Would you be willing to participate in a requirements review?

Berdasarkan ketiga pertanyaan diatas, didapat konfimasi dan klarifikasi dari pihak FKUI atas kesedianya untuk tetap melakukan kerjasama yang baik selama ini dan terus meningkat kinerja hubungan kerja dengan tim pengembang SIPROKA. Pihak FKUI bersedia untuk memberikan informasi tambahan yang dirasa kurang dari kebutuhan informasi yang telah didapat sebelumnya, dalam menindak lanjuti hasil proses analisa yang telah dikerjakan oleh tim pengembang SIPROKA. Dibawah ini beberapa stakeholder yang dapat dihubungi:

No Nama Company Jabatan Phone Email

1 dr. Menaldi Rasmin,

Sp(K), FCCP FKUI Dekan 3101066 [email protected]

2 Dr. dr. Boy S.

Sabarguna. MARS FKUI Manajer Keuangan 3101066 [email protected]

3 Farian FKUI Bendahara Departmen

Keuangan 3101066 [email protected]



Page 12

4 Astrid S.A. FKUI Akuntan Departmen

Keuangan 3101066 [email protected]

5 Asih Komara FKUI Administrasi

Departemen Keuangan 3101066 [email protected]

6 Aria Kekalih MTI UI Tim Pengembang

(SIPROKA) [email protected]

7 Fajar Edisya Putera MTI UI Tim Pengembang


8 Isnanto Nugroho S MTI UI Tim Pengembang


9 Nana Suryadigama MTI UI Tim Pengembang


11. Analyst’s Summary Berikut merupakan hasil analisis kami

1. [ STRQ1 : Database Proposal yang Terintegrasi] Stakeholder merasa perlu suatu database proposal yang terintegrasi guna menyelesaikan masalah yang timbul karena proposal kegiatan sangat banyak dan beragam, sekaligus guna menghindari program kerja kegiatan yang ganda dan dapat juga digunakan sebagai bahan referensi untuk penyusunan proposal kegiatan selanjutnya.

2. [ STRQ2 : Proses Administrasi Pengajuan Proposal yang Efisien]

Stakeholder merasa perlu memiliki proses administrasi pengajuan proposal yang efisien, mereka saat ini merasa bahwa proses saat ini terlalu birokratif dan tidak efisien sehingga menyebabkan sering terlambatnya proses persetujuan proposal

3. [ STRQ3 : Sistem monitoring realisasi kegiatan]

Stakeholder merasa perlu untuk memiliki suatu sistem monitoring realisasi kegiatan baik dari aspekkinerja keuangan maupun operasional serta sistem yang dapat menampilkan informasi detail yang lengkap mengenai seluruh kegiatan yang ada dan statusnya

4. [ STRQ4 : Sistem monitoring kesesuaian kegiatan dengan visi]

Stakeholder merasa perlu memiliki suatu sistem untuk menyesuaikan antara rencana kegiatan dengan visi FKUI

5. [ STRQ5 : Sistem pelaporan guna kepentingan audit]

Stakeholder merasa perlu untuk memiliki sistem untuk dapat memberikan laporan saat dilakukan proses audit.



Page 13



Page 1


Vision

Version 1.1

SIPROKA FKUI Version: 1.1 Vision Date: 07.01.2007

Rahasia FKUI 2007

Page 2


02.10.2006 0.5 <1st increment> Aria Kekalih

22.10.2006 0.9 2nd Increment Aria Kekalih

11.12.2006 1.0 Revisi Aria Kekalih

07.01.2007 1.05 Revisi minor Nana Suryadigama

07.01.2007 1.1 Revisi berdasarkan presentasi Isnanto Nugroho


Rahasia FKUI 2007

Page 3

Table of Contents 1.1 Introduction 5 1.2 Purpose 5 1.3 Scope 5 1.4 Definitions, Acronyms, and Abbreviations 5 1.5 References 5 1.6 Overview 5

2. Positioning 6 2.1 Business Opportunity 6 2.2 Problem Statement 6 2.3 Product Position Statement 6

3. Stakeholder and User Descriptions 7 3.1 Market Demographics 7 3.2 Stakeholder Summary 7 3.3 User Summary 8 3.4 User Environment 9 3.5 Stakeholder Profiles 10

3.5.1 Pimpinan Fakultas 10 3.5.2 Divisi Keuangan FKUI 10 3.5.3 Divisi Keuangan FKUI 10

3.6 User Profiles 11 3.6.1 Panitia 11

3.7 Key Stakeholder or User Needs 11 3.8 Alternatives and Competition 12

4. Product Overview 12 4.1 Product Perspective 12 4.2 Summary of Capabilities 13 4.3 Assumptions and Dependencies 13 4.4 Cost and Pricing 13 4.5 Licensing and Installation 14

5. Product Features 14 Adanya aplikasi yang merekapitulasi seluruh kegiatan, proposal yang masuk dengan perbandingan neraca keuangan dan status yang lengkap. 14

6. Constraints 14

7. Quality Ranges Error! Bookmark not defined.

8. Other Product Requirements 14 8.1 Applicable Standards 14 8.2 System Requirements 15 8.3 Performance Requirements 15 8.4 Environmental Requirements 15

9. Documentation Requirements 15


Rahasia FKUI 2007

Page 4

9.1 User manual 15 9.2 On-line help 15 9.3 Installation Guide, Configuration dan ReadMe File 15 9.4 Labelling and Packaging 15

A Feature Attributes 15


Rahasia FKUI 2007

Page 5

Vision

1. Introduction Tujuan dibentuknya dokumen ini adalah untuk menjabarkan permasalahan yang akan diangkat dalam sistem informasi Pengelolaan Program Kerja dan Anggaran FKUI, mengumpulkan business requirement tingkat tinggi, kebutuhan user serta fitur dari sistem. Dokumen ini men garahkan pada kemampuan yang dibutuhkan stakeholder, target usernya serta bagaimana kebutuhan itu bisa muncul dan diakomodasi oleh sistem yang akan dikembangkan. Sistem informasi Pengelolaan Program Kerja dan Anggaran ini merupakan salah satu solusi untuk efektivitas operasional kerja dekanat, manajemen keuangan, manajemen proyek dalam pengelolaan persetujuan proposal program kerja, anggaran dan monitoringnya.

1.1 Purpose Sistem informasi pengelolaan program kerja dan anggaran FKUI ini dibentuk untuk menyesuaikan proposal dengan rencana strategis tahunan FKUI, memberikan laporan mengenai jumlah rancangan proposal kegiatan yang masuk, kegiatan yang sedang dilaksanakan, penyesuaian anggaran serta evaluasi pelaksanaan dan penggunaan anggaran tiap program kerja. Proses kerja ini dikelola terutama oleh divisi keuangan FKUI dengan persetujuan dari pimpinan fakultas dan koordinasi dari divisi-divisi lainnya. Pokok dari proses kerja ini adalah proses melihat keseluruhan rencana strategis tahunan FKUI dengan status proposal yang ada (monitoring), proses pendaftaran proposal kerja dalam database (Memasukkan proposal), proses persetujuan proposal kerja beserta anggarannya (Seleksi), serta proses kontrol laporan pertanggungjawaban setiap program kerja (Evaluasi).

1.2 Scope Sistem Mengumpulkan, menganalisa, dan menentukan kepentingan pimpinan dalam rangka membentuk system informasi Pengelolaan Program Kerja dan Anggaran FKUI yang mendukung mekanisme pelaporan untuk proposal kegiatan yang masuk, penyesuaian kegiatan dengan rencana strategis dan kondisi keuangan, serta suatu rekapitulasi komprehensif mengenai laporan akhir seluruh kegiatan FKUI (pencapaian dan anggaran). Ruang lingkup proyek ini melibatkan lingkup manajemen internal FKUI dari dekan, wakil dekan, manajer serta pelaksana atau pengusul kegiatan seperti departemen, staf pengajar, administrasi, mahasiswa dan lain-lain. Pihak luar yang dapat mengaudit system ini hanyalah rektorat yang mengevaluasi kinerja dekan

1.3 Definitions, Acronyms, and Abbreviations Daftar definisi dan singkatannya dapat dilihat di dokumen Sistem Informasi Pengelolaan Program Kerja dan Anggaran FKUI Glossay.doc

1.4 References Rencana Strategi FKUI 2006-2010

1. Laporan keuangan tahunan 2004

2. Standard Operational Prosedur penyusunan kegiatan dan anggaran FKUI.

3. Laporan pertanggung jawaban kegiatan departemen.

1.5 Overview Dokumen ini menjelaskan tentang business opportunity, target user yang akan dilibatkan, fitur-fitur yang ada di dalamnya, termasuk juga dokumentasi yang akan disediakan setelah proyek ini selesai. Secara garis besar akan dijelaskan mengenai gambaran biaya yang harus dikeluarkan.


Rahasia FKUI 2007

Page 6

FKUI terdiri dari divisi dan departemen. Setiap divisi dan departemen memiliki target pencapaian kinerja dengan indikator yang dapat diukyur seperti hal Balance Score Card dirumuskan dalam suatu Rencana Strategi Tahunan FKU yang dievaluasi setiap tahun. Divisi mengelola proses administrasi, sarana dan prasarana fakultas sehingga secara umum terdiri atas divisi keuangan, pendidikan, teknologi informasi, kemahasiswaan, SDM,dan fasilitas umum. Departemen bertanggungjawab atas proses pendidikan sesuai dengan cabang disiplin ilmu dari kedokteran yaitu departemen anatomi, bedah, anak, penyakit dalam dsb. Meski departemen memberikan laporan pertanggungjawaban kepada divisi pendidikan namun secara kinerja departemen memiliki otonomi untuk membuat program kerja tersendiri.

Proses kerja yang biasa dilakukan di FKUI adalah setiap program yang dilakukan harus berdasarkan proposal tertulis. Proposal harus diajukan walaupun kegiatan bersifat insidentil maupun rutin, karena menyangkut dengan rencana anggaran yang diajukan tiap kegiatan. Proposal diajukan oleh grup, divisi atau perorangan yang dalam pembahasan ini diterminologikan sebagai ”Panitia”. Panitia mengajukan proposal program kerja karena harus melaksanakan program kerja demi tercapainya target pencapaian kinerja yang dimiliki oleh setiap divisi atau departemen.

Disetujui atau tidaknya suatu kegiatan dianalisa berdasarkan kesesuaiannya dengan rencana strategis dan neraca keuangan FKUI. Keputusan dibuat oleh pimpinan fakultas, dan keuangan khususnya membutuhkan persetujuan dari manajer keuangan. Manajer keuangan pula yang bertanggung jawab memberikan laporan rekapitulasi penggunaan anggaran untuk setiap kegiatan yang telah dilakukan. Laporan rekapitulasi ini biasanya dievaluasi setiap tahun.

2. Positioning

2.1 Business Opportunity Efektivitas operasional dari perencanaan anggaran dan kegiatan memberikan peluang FKUI untuk lebih optimal dalam melakukan kegiatan dalam tiap tahun anggarannya. Kegiatan yang dilaksanakan bisa lebih banyak dan lebih efisien

2.2 Problem Statement

The problem of belum terintegrasinya pendataan proposal kegiatan yang masuk dan perencanaan anggaran kegiatan FKUI.

affects pengambilan keputusan oleh manajer keuangan FKUI jadi terlambat

the impact of which is terhambatnya atau tidak terlaksananya beberapa kegiatan, atau tidak meratanya pencapaian pelaksanaan program tiap divisi

a successful solution would be Adanya informasi yang real time mengenai seluruh kegiatan yang masuk, sedang atau telah dilaksanakan disertai perencanaan anggarannya

2.3 Product Position Statement [Produk ini akan sangat bermanfaat terutama bagi pimpinan fakultas dalam menganalisa perkembangan aktivitas yang berjalan disesuaikan dengan arus pengeluaran anggaran. Bagi pelaksana program, produk ini membantu sebatas mengetahuiperbandingan mengenai program lain yang sedah diusulkan atau telah dilaksanakan ]


Rahasia FKUI 2007

Page 7

For Pimpinan fakultas – Manajer Keuangan – Staf Divisi Keuangan

Who Sistem informasi ini ditujukan untuk :melayani kebutuhan informasi baik untuk pimpinan fakultas, para manajer, staf keuangan maupun khususnya kepada Panitia mengenai data program kerja yang harus dilaksanakan, proposal kegiatan yang masuk, kegiatan yang sudah disetujui dan dilaksanakan, serta penggunaan anggaran untuk setiap kegiatan

The (product name) Sistem informasi perencanaan program dan keuangan FKUI (SIPROKA)

That Agar dapat memberikan informasi secepatnya kepada pimpinan fakultas dan kepanitiaan yang terlibat mengenai program kerja yang belum atau sudah dilaksanakan, serta memberikan keputusan strategis bagi pimpinan fakultas dan manajer keuangan mengenai kegiatan yang akan diprioritaskan untuk disetujui proposalnya

Unlike Sistem office konvensional yang tidak terintegrasi, hanya mendata proposal yang masuk tanpa disesuaikan dengan kondisi anggaran dan keuangan

Our product Memadukan interface pendataan proposal masuk dengan rencana strategis, terintagrasi dengan data anggaran. aplikasi berdasarkan web-based dan otorisasi secara selektif sesuai dengan wewenang user

3. Stakeholder and User Descriptions

3.1 Market Demographics Aplikasi ini merupakan aplikasi internal yang tidak ditujukan untuk dipasarkan ke pihak ketiga

3.2 Stakeholder Summary

Name Description Responsibilities

Panitia Bisa berupa kelompok atau perorangan dari divisi atau departemen yang membentuk proposal kegiatan ( lengkap dengan data staf pelaksana, kegiatan dan anggaran)

Mengajukan proposal sesuai dengan rencana strategis tahunan FKUI dimana didalamya terdapat target pencapaian yang harus dikerjakan setiap divisi atau departemen

Panitia memasukkan data penting suatu proposal kegiatan ke dalam aplikasi

Memberikan laporan pertanggungjawaban apabila suatu kegiatan telah selesai dilaksanakan

Pimpinan Fakultas Adalah dekan dan wakil dekan yang mengkoor-dinasikan pelaksanaan realisasi pelaksanaan rencana strategis tahunan FKUI oleh setiap divisi dan

Menganalisa kesesuaian proposal suatu kegiatan dengan rencana strategis tahunan. Melakukan seleksi perlu aatu tidaknya disetujui suatu proposal kegiatan

Menyesuaikan proposal yang masuk dengan


Rahasia FKUI 2007

Page 8

departemen strategi tahunan

Meminta konfirmasi dari manajer divisi terkait mengenai pelaksanaan proposal suatu kegiatan

Meminta konfirmasi dari manajer keuangan mengenai jumlah anggaran yang dialokasikan untuk suatu kegiatan yang telah disetujui konsepnya

Memberikan persetujuan akhir mengenai akan dilaksanakannya suatu proposal kegiatan

Manajer Keuangan Merupakan kepala divisi keuangan yang berwewenang terhadap pengelolaan kondisi keuangan fakultas.

Memberikan keputusan akhir mengenai persetujuan suatu proposal kegiatan dikaitkan dengan jumlah anggaran. Suatu proposal yang distujui bisa dalam kondisi anggaran disetujui sepenuhnya atau hanya sebagian saja.

Manajer keuangan pula yang bertanggung jawab memberikan laporan rekapitulasi penggunaan anggaran untuk setiap kegiatan yang telah dilakukan. Laporan rekapitulasi ini biasanya dievaluasi pimpinan fakultas dan auditor eksternal setiap tahun

Manajer divisi Adalah manajer divisi pelaksana seperti SDM, pendidikan, IT, kemahasiswaan diluar manajer divisi keuangan

Memberikan konfirmasi kepada pimpinan fakultas akan kesesuaian suatu proposal dengan rencana strategis tahunan

3.3 User Summary

Name Description Stakeholder

Manajer keuangan

Adalah manajer divisi keuangan

Memberikan konfirmasi mengenai jumlah anggaran yang disetujui dalam suatu proposal kegiatan

Memberikan laporan rekapitulasi penggunaan anggaran untuk keseluruhan program kerja yang telah dilaksanakan setiap akhir tahunn

Akuntan Staf divisi keuangan yang menilai akuntabilitas suatu laporan pertanggungjawaban kegiatan khususnya dalam hal anggaran

Mencatat dan menilai bukti transaksi kelengkapan

Memberikan peringatan kepada panitia yang belum memberikan LPJ pada batas waktu

Memberikan peringatan kepada panitia yang belum lengkap persyaratan bukti transaksi dalam laporan pertanggungjawaban


Rahasia FKUI 2007

Page 9

Bendahara Staf divisi keuangan yang mencatat kondisi neraca dan arus uang masuk uang keluar dalam catatan keuangan fakultas

Mencatat cash flow (uang masuk-keluar) yang digunakan untuk penyelenggaraan suatu program kerja berdasarkan proposal yang telah disetujui

Memberikan konfirmasi kepada manajer keuangan mengenai jumlah anggaran untuk suatu kegiatan

Menyusun rekapitulasi laporan keuangan tahunan

3.4 User Environment Pengguna sistem aplikasi ini akan berada di lingkungan yang statis. Aplikasi akan dimasukkan ke dalam jaringan intranet FKUI (web-based) yang melibatkan seluruh divisi dan departemen. Setiap divisi dan departemen dapat memasukkan data penting proposal kegiatan melalui interface sistem aplikasi yang dapat diakses melalui PC di tempat masing-masing. PC ada di setiap unit pengguna dengan kepentingan penggunaan berbeda-beda sesuai dengan fungsi mereka dalam sistem ini.

Seluruh staf FKUI yang terlibat dalam perencanaan program kerja dan keuangan akan telibat dalam penggunaan produk ini. Oleh karena itu diharapkan produk ii dapat diselesaikan secepatnya ( Januari 2007)

Batasannya adalah system ini harus tidak tumpang tindih dengan system informasi yang akan dikelola secara terintegrasi oleh UI Pusat. Jadi system ini bersifat pelengkap, meskipun harus diselesaikan dalam waktu yang lebih cepat karena kepentingannya tinggi.


Rahasia FKUI 2007

Page 10

3.5 Stakeholder Profiles

3.5.1 Pimpinan Fakultas

Representative Dr Menaldi Rasmin

Description Dekan FKUI

Type Pimpinan tertinggi fakultas

Responsibilities Mengkoordinasikan seluruh program kerja setiap divisi dan departemen di FKUI untuk mencapai tujuan pencapaian yang disepakati dalam Renstra FKUI

Success Criteria Apabila seluruh kegiatan FKUI dapat terlaksana dengan baik denganmencapai target kinerja dan kesesuaian dengan perencanaan anggaran yang ada

Involvement Penanggungjawab, Narasumber dan executive desicion maker

Deliverables Berkas-berkas laporan yang terkait

Comments / Issues Stakeholder menginginkan pengerjaan system ini karena tingkat kerumitan pengambilan keptusan yang tinggi membutuhkan suatu aplikasi yang bersifat sebagai alat bantu

3.5.2 Divisi Keuangan FKUI

Representative Dr Boy Sabarguna

Description Manajer Keuangan FKUI

Type Ahli manajemen organisasi dan pengelola keuangan

Responsibilities Mengelola dan merencanakan penggunaan keuangan FKUI

Success Criteria Apabila seluruh kegiatan FKUI dapat terlaksana dengan baik dengan perencanaan anggaran yang ada

Involvement Terlibat sebagai analis seluruh informasi yang disediakan dalam system ini. Desicison support system

Deliverables Informasi yang telah dikumpulkan disajikan dalam bentuk table, grafik dan trend

Comments / Issues Stakeholder menginginkan pengerjaan system ini karena merasa kepentingan sudah mendesak, dan menunggu adanya system dari pusat sudah terlalu lama

3.5.3 Divisi Keuangan FKUI

Representative Dr. Ali Sungkar

Description Manajer Pengembangan dan Pelayanan Sistem Informasi FKUI

Type Pengelola

Responsibilities Mengelola dan merencanakan penggunaan keuangan FKUI

Success Criteria Apabila seluruh kegiatan FKUI dapat terlaksana dengan baik dengan dukungan fasilitas IT


Rahasia FKUI 2007

Page 11

Involvement Terlibat sebagai analis seluruh informasi yang disediakan dalam system ini. Desicison support system

Deliverables Informasi yang telah dikumpulkan disajikan dalam bentuk table, grafik dan trend

Comments / Issues Stakeholder menginginkan pengerjaan system ini karena merasa kepentingan sudah mendesak, dan menunggu adanya system dari pusat sudah terlalu lama

3.6 User Profiles

3.6.1 Panitia Representative Staf pengajar /Dosen

Description Penanggung jawab Pelaksana Modul Kurikulum atau kegiatan lain

Type Menguasai materi modul namun keterampilan teknik computer bervariasi

Responsibilities Bertanggung jawab dalam pembuatan laporan, pertanggungjawaban keuangan dan kegiatan

Success Criteria Dapat digunakannya system ini untuk memudahkan pengajuan proposal serta untuk laporan pertanggungjawaban

Involvement Pemakai terlibat dalam usaha ujicoba untuk menemukan aplikasi system yang terbaik.

Deliverables Proposal, laporan pertanggungjawaban

Comments / Issues Sistem tidak boleh tumpang tindih dengan aplikasi yang sudah ada

3.7 Key Stakeholder or User Needs

Need Priority Origin Current Solution Proposed Solutions

[NEED1 : Database Proposal yang Terintegrasi] Suatu database proposal yang terintegrasi guna menyelesaikan masalah yang timbul karena proposal kegiatan sangat banyak dan beragam, sekaligus guna menghindari program kerja kegiatan yang ganda dan dapat juga digunakan sebagai bahan referensi untuk penyusunan proposal kegiatan selanjutnya.

High Stakeholder Pelaporan dengan hardcopy

Intranet Web-based application


Rahasia FKUI 2007

Page 12

[NEED2 : Proses Administrasi Pengajuan Proposal yang Efisien] Proses administrasi pengajuan proposal yang efisien, mereka saat ini merasa bahwa proses saat ini terlalu birokratif dan tidak efisien sehingga menyebabkan sering terlambatnya proses persetujuan proposal

High Stakeholder Pelaporan dengan hardcopy


[NEED3 : Sistem monitoring realisasi kegiatan] Sistem monitoring realisasi kegiatan baik dari aspekkinerja keuangan maupun operasional serta sistem yang dapat menampilkan informasi detail yang lengkap mengenai seluruh kegiatan yang ada dan statusnya

Medium Stakeholder Pelaporan dengan hardcopy


[NEED4 : Proses Administrasi Penilaian LPJ yang Efisien] Sistem administrasi penilaian Laporan Pertanggungjawaban (LPJ) perlu diefisienkan supaya penilaian lebih objektif

Medium Developer Pelaporan dengan hardcopy


3.8 Alternatives and Competition Tidak ada competitor produk dalam hal ini, karena hanya dipakai untuk keperluan internal. Alternatif dari apolikasi ini adalah dengan menggunakan sistem pelaporan konvensional.

4. Product Overview

4.1 Product Perspective Sistem yang dibangun diberi nama sistem informasi pengelolaan program kerja dan keuangan FKUI (SIPROKA) yang mendukung mekanisme pelaporan untuk proposal kegiatan yang masuk, penyesuaian kegiatan dengan rencana strategis dan kondisi keuangan, serta suatu rekapitulasi komprehensif mengenai laporan akhir seluruh kegiatan FKUI (pencapaian dan anggaran). Aplikasi SIPROKA ini direncanakan berbasis web yang terintegrrasi dalam jaringan intranet FKUI.


Rahasia FKUI 2007

Page 13

4.2 Summary of Capabilities Table 4-1 Customer Support System

Customer Benefit Supporting Features

terintegrasinya pendataan proposal kegiatan yang masuk, karena kegiatan yang ada sangat banyak dan melibatkan berbagai pihak .

Adanya aplikasi entry untuk proposal kegiatan dengan format nama kegiatan , tujuan, waktu, tempat, kepanitiaan dan anggaran.

Terintegrasinya system perencanaan program dengan perencanaan Renstra tahunan FKUI, dikaitkan dengan anggaran dan pencapaian

Adanya aplikasi yang merekapitulasi seluruh kegiatan, proposal yang masuk dengan perbandingan neraca keuangan dan status yang lengkap

tersedianya informasi yang terintegrasi dan komprehensif mengenai kegiatan yang telah disetujui anggarannya, telah dilaksanakan serta anggaran yang telah digunakan

Adanya aplikasi yang mempermudah pelaporan pertanggungjawaban dan menampilkan database laporan hasil kegiatan serta anggaran yang terpakai

Pimpinan fakultas dan Manajer keuangan dapat mempelajari kinerja operasional dan penggunaan keuangan untuk tiap kegiatan dan memantau pelaksana program yang belum memberikan laporan

Adanya aplikasi supplementary yang bersifat time-series dan otomatis memperingatkan manajer apabila setelah deadline terdapat pelaksana program yang belum memberikan laporan

Pimpinan fakultas dapat merencanakan kegiatan yang strategis untuk kemajuan fakultas berdasarkan data kegiatan serta alokasi dananya

Adanya sistem informasi manajemen yang menampilkan rekapitulasi informasi berupa realisasi anggaran, serta trend yang bermanfaat untuk mendukung pengambilan keputusan strategis.

Panitia perlu mengetahui dengan cepat mengenai persetujuan proposal dan anggarannya.

Adanya aplikasi yang mendukung proses penyetujuan proposal kegiatan baik dari segi keselarasan dengan rencana strategis dan ketersediaan anggaran

4.3 Assumptions and Dependencies Aplikasi ini diperkirakan sangat tergantung dengan aplikasi yang sudah ada saat ini atau yang direncanakan pihak universitas akan segera dibuat. Kebutuhan yang mendesak membuat manajer keuangan FKUI membuat lebih dahulu system yang dapat digunakan.

Hal yang dapat menghambat pengembangan aplikasi ini adalah banyaknya aplikasi yang selama ini terlalu lama dikembangkan sehingga muncul asumsi di pihak stakeholder bahwa proses kerja di FKUI terlalu rumit untuk dibuat system informasinya. Oleh karena itu pengembangan system harus dilakukan secara incremental

4.4 Cost and Pricing Aspek pembiayaan diperlukan dalam tahap observasi dan perencanaan, analisa, desain aplikasi, implementasi serta pelatihan ke pihak user. ]


Rahasia FKUI 2007

Page 14

4.5 Licensing and Installation Lisensi hanya diberikan kepada internal FKUI yang terlibat

5. Product Features

1. [FEAT1 : Entry Data Proposal] Adanya aplikasi entry untuk proposal kegiatan dengan format nama kegiatan , tujuan, waktu, tempat, kepanitiaan dan anggaran yang disimpan dalam suatu database yang terintegrasi.

2. [FEAT2 : Laporan Rekapitulasi Status Proposal ]

Adanya aplikasi yang merekapitulasi seluruh kegiatan, proposal yang masuk dengan perbandingan neraca keuangan dan status yang lengkap.

3. [FEAT3 : Sistem pendukung proses seleksi proposal]

Adanya aplikasi yang mendukung proses seleksi proposal kegiatan baik dari segi keselarasan dengan rencana strategis (tahap I) dan ketersediaan anggaran (tahap II)

4. [FEAT4 : Entry Data LPJ]

Adanya aplikasi yang mempermudah pengumpulan Laporan Pertanggungjawaban (LPJ) kegiatan yang telah dilakukan dan anggaran yang terpakai

5. [FEAT5 : Pendukung Proses Penilaian LPJ]

Adanya aplikasi yang mempermudah proses penilaian Laporan Pertanggungjawaban (LPJ) baik dari segi indikator keberhasilan maupun realisasi anggaran.

6. [FEAT6 : Rekapitulasi Informasi Kegiatan]

Menampilkan database laporan hasil kegiatan serta anggaran yang terpakai dan sistem informasi manajemen yang menampilkan rekapitulasi informasi berupa realisasi anggaran, serta trend yang bermanfaat untuk mendukung pengambilan keputusan strategis

6. Constraints [SUPP15 Semua pengguna harus sudah terlatih sebelum sistem diimplementasikan. Mengingat sebagian pengguna adalah top level management, sebaiknya pelatihan dilakukan secara private]

[SUPP16 Sistem aplikasi versi 1.0 diselesaikan dalam waktu paling lambat 6 bulan ( Juli 2007)]

7. Other Product Requirements

7.1 Applicable Standards Sistem harus mampu dioperasikan dengan standar komunikasi TCP/IP, dengan operating system Windows atau Linux serta standar keamana dan kualitas sesuai dengan ISO 9006.


Rahasia FKUI 2007

Page 15

7.2 System Requirements Sistem membutuhkan jaringan intranet yang didukung system proteksi pada jaringan dan terminal entry data. Terminal entry data terdapat pada level pelaksana program. Sedangkan pada level pimpinan fakultas dan manajer terdapat terminal untuk OLAP analisa selain entry data. Diperlukan server untuk database, application dan client-server.

7.3 Performance Requirements Karena system ini membutuhkan response time yang tinggi maka jaringan intranet yang ada harus stabil dan kapasitas transfer rate tinggi. Bandwith jaringan yang ada minimal sebesar 2 MB dan hal ini sudah tersedia.

7.4 Environmental Requirements Tidak dibutuhkan spesifikasi khusus karena jaringan sudah terpelihara dalam sistem sebelumnya.

8. Documentation Requirements Dokumentasi dilakukan pada setiap tahap dan perubahan dalam pembuatan aplikasi ini.

8.1 User manual Software akan diberikan dalam bentuk paket. Untuk mengaktifkannya cukup dengan melakukan instalasi dengan mengikuti setiap petunjuk yang ditampilkan. Panduan lebih lanjut akan disertakan dalam dokumen teknis

8.2 On-line help On-line help merupakan dokumen user manual secara elektronik yang dapat dengan mudah diakses oleh user langsung dari system. System dilengkapi dengan online help yang mudah digunakan dan cukup lengkap.

8.3 Installation Guide, Configuration dan ReadMe File Disertakan dalam dokumen teknis

8.4 Labelling and Packaging Menggunakan logo FKUI

A Feature Attributes Berbagai penjelasan mengenai attribute yang digunakan telah dijelaskan pada Requirement management plan di bagian List Values


Rahasia FKUI 2007

Page 1


Use Case : Mengajukan Proposal Kegiatan Version 1.1

SIPROKA FKUI Version: 1.1 Use Case Specification : Mengajukan Proposal Kegiatan Date: 05.01.2007

Confidential FKUI, 2007 Page

2


22.10.2006 0.9 First Draft Nana Suryadigama

26.11.2006 1.0 Revisi minor pada alur use case Isnanto Nugroho

05.01.2007 1.1 Revisi format alur use case Isnanto Nugroho



3

Table of Contents 1. Use Case Name 4

1.1 Use Case Name 4 1.2 Brief Description 4

2. Basic Flow of Events 4

3. Alternative Flows 4 3.1 Validasi Username Gagal 4 3.2 Validasi Panitia Gagal 4 3.3 Save Indikator Keberhasilan Gagal 4 3.4 Upload Proposal Kegiatan Gagal 4 3.5 Pencetakan Tanda Bukti Gagal 5

4. Preconditions Error! Bookmark not defined. 4.1 Precondition One 5

5. Post Conditions 5 5.1 Post Condition One 5

6. Special Requirements 5

7. Additional Information 5



4

Use-Case Specification: Mengajukan Proposal Kegiatan

1. Use Case Name

1.1 Use Case Name Nama Use Case ini adalah : [UC1 : Mengajukan Proposal kegiatan]

1.2 Brief Description [UC1.1 Digunakan untuk mengajukan proposal kegiatan yang telah dibuat oleh Panitia ke dalam sistem]

2. Basic Flow of Events [UC1.2 Basic Flow] ini akan dijelaskan dengan format dua kolom :

Aktor System

1. Memasukkan User Name dan Password 2. Memilih akan berperan sebagai panitia untuk kegiatan yang mana

3. Memvalidasi user name dan password 4. Memvalidasi apakah benar user tsb

termasuk panitia kegiatan yang dipilih 5. Menampilkan layar pengajuan proposal 6. Meng-enter folder path proposal kegiatan (rencana kerja dan rencana anggaran)

7. Meng-input indikator keberhasilan untuk kegiatan (parameter dan targetnya)

8. Pilih Save 9. Men-save indikator keberhasilan 10. Meng-upload proposal kegiatan

(rencana kerja dan rencana anggaran) 11. Menampilkan di tanda bukti

penyerahan proposal di layar 12. Mencetak tanda bukti penyerahan

proposal

3. [UC1.3 Alternative Flows]

3.1 Validasi Username Gagal Pada langkah 3 jika validasi user name dan password gagal, maka sistem akan mengeluarkan pesan kesalahan dan user harus memasukkan kembali username dan password (kembali ke langkah 1)

3.2 Validasi Panitia Gagal Pada langkah 4 jika validasi panitia gagal, maka sistem akan mengeluarkan pesan kesalahan dan user harus memilih kembali panitia kegiatan yang akan diwakili (kembali ke langkah 2)

3.3 Save Indikator Keberhasilan Gagal Pada langkah 9 jika mensave indikator keberhasilan gagal, maka sistem akan mengeluarkan pesan kesalahan dan kembali ke langkah 5

3.4 Upload Proposal Kegiatan Gagal Pada langkah 10 jika upload proposal kegiatan gagal, maka sistem akan mengeluarkan pesan kesalahan dan



5

kembali ke langkah 5

3.5 Pencetakan Tanda Bukti Gagal Pada langkah 12 jika pencetakan tanda bukti gagal, maka sistem akan mengeluarkan pesan kesalahan dan kembali ke langkah 11

4. [UC1.4 Preconditions] Kondisi awal dari sebuah use case yang harus dicapai sebelum use case ini dapat dimulai

4.1 Precondition One Panitia telah selesai menyusun proposal kegiatan (rencana kerja dan rencana anggaran) dalam softcopy dalam suatu folder

5. [UC1.5 Post Conditions] Kondisi akhir dari sebuah use case adalah keadaan akhir ketika use case tersebut berakhir

5.1 Post Condition One Proposal kegiatan (rencana kerja dan rencana anggaran) serta indikator keberhasilan yang terkait telah tersimpan dengan baik dalam database

6. Special Requirements Tidak ada

7. Additional Information Tidak ada



1


Use-Case Specification: Seleksi Proposal Tahap I

Version 1.1

SIPROKA FKUI Version: 1.1 Use Case Specification : Seleksi Proposal Tahap I Date: 06.01.2007


2


02.10.2006 0.9 Create First Use Specification Nana Suryadigama


06.01.2007 1.1 Revisi setelah presentasi Isnanto Nugroho



3




3. Alternative Flows Error! Bookmark not defined. 3.1 Review Rencana Anggaran 4 3.2 Download Proposal Rencana Anggaran Gagal 5 3.3 Validasi Gagal 5 3.4 Download Proposal Rencana Kegiatan Gagal 5 3.5 Menyimpan Komentar Gagal 5

4. Preconditions 5 4.1 Precondition One 5






4

Use-Case Specification: Seleksi Proposal Tahap I

1. Use Case Name

1.1 Use Case Name Nama Use Case ini adalah : [UC2 : Seleksi Proposal Tahap I]

1.2 Brief Description [UC2.1 Proses ini digunakan oleh Dekan untuk melakukan seleksi proposal Tahap I untuk setiap proposal yang masuk dan telah disetujui Manajer Divisi. Seleksi Tahap I adalah seleksi rencana kegiatan untuk diselaraskan dengan rencana strategis/rencana jangka panjang FKUI]

2. Basic Flow of Events [UC2.2 Basic Flow] ini akan dijelaskan dengan format dua kolom :

Aktor System 1. Memasukkan user name dan password 2. Memvalidasi user name dan password 3. Menampilkan list seluruh proposal

dengan status disetujui Manajer Divisi 4. Memilih proposal kegiatan yang akan direview 5. Mendownload proposal kegiatan yang

dipilih 6. Mereview proposal kegiatan 7. Memasukkan komentar dan persetujuan/tidak dalam proposal dimaksud

8. Meng-klik Save 9. Menyimpan komentar dan persetujuan

kedalam database


3.1 Review Rencana Anggaran Jika pada langkah 3 dekan memutuskan akan melihat/mereview/atau mengkomentari rencana anggaran maka kelanjutan flow sistem adalah sebagai berikut

Aktor System DARI BASIC FLOW

3. Menampilkan list seluruh proposal dengan status disetujui Manajer Divisi

3.a Memilih proposal rencana anggaran yang akan direview

3.b Mendownload proposal rencana anggaran yang dipilih

3.c Mereview proposal rencana anggaran KEMBALI KE BASIC FLOW 7. Memasukkan komentar dan persetujuan/tidak dalam proposal dimaksud



5

3.2 Download Proposal Rencana Anggaran Gagal Jika download proposal rencana anggaran pada langkah 3.b gagal maka sistem akan menampilkan pesan kesalahan dan kembali pada langkah 3

3.3 Validasi Gagal Jika validas pada langkah 2 gagal, maka sistem akan meminta Aktor untuk melakukan validasi ulang dan Aktor harus kembali ke langkah 1

3.4 Download Proposal Rencana Kegiatan Gagal Jika download proposal rencana kegiatan pada langkah 5 gagal, maka sistem akan menampilkan pesan kesalahan dan kembali ke langkah 3

3.5 Menyimpan Komentar Gagal Jika menyimpan komentar pada langkah 9 gagal, maka akan menampilkan pesan kesalahan dan meminta Aktor untuk memasukkan kembali komentar (kembali ke langkah 7)

4. [UC2.4 Preconditions] Kondisi awal dari sebuah use case yang harus dicapai sebelum use case ini dapat dimulai

4.1 Precondition One Terdapat proposal kegiatan yang masuk dan telah disetujui oleh Manajer Divisi namun belum memiliki status seleksi tahap I

Aktor sudah siap dengan rencana strategis yang akan digunakan untuk mereview proposal ang masuk tersebut

5. [UC2.5 Post Conditions] Kondisi akhir dari sebuah use case adalah keadaan akhir ketika use case tersebut berakhir

5.1 Post Condition One Proposal yang telah disetujui Manajer Divisi memiliki status seleksi tahap I dan disimpan dalam database.

6. Special Requirements Tidak ada.

7. Additional Information Tidak ada..



1


Use-Case Specification: Seleksi Tahap II

Version 1.1

SIPROKA FKUI Version: 1.1 Use Case Specification : Seleksi Proposal Tahap II Date: 06.01.2007


2


02.10.2006 0.9 Use-Case Seleksi Tahap II Fajar


06.01.2007 1.1 Revisi format alur use case setelah presentasi

Isnanto Nugroho



3




3. Alternative Flows Error! Bookmark not defined. 3.1 Validasi Gagal 4 3.2 Download Proposal Rencana Anggaran Gagal 4 3.3 Menyimpan Komentar Gagal 4

4. Preconditions 5 4.1 Precondition One 5






4

Use-Case Specification: Seleksi Tahap II

1. Use Case Name

1.1 Use Case Name Nama Use Case ini adalah : [UC3 : Seleksi Proposal Tahap II]

1.2 Brief Description [UC3.1 Use-Case ini digunakan untuk menggambarkan proses seleksi proposal kegiatan yang berhubungan dengan dana yang dimiliki oleh bagian manajemen keuangan FKUI. Segala kegiatan yang akhirnya diputuskan akan menentukan berapa banyak dana yang akan disediakan oleh pihak manajemen FKUI, atau malah proposal kegiatan tersebut dibatalkan]

2. Basic Flow of Events

[UC3.2 Basic Flow] ini akan dijelaskan dengan format dua kolom :

Aktor System 1. Memasukkan user name dan password 2. Memvalidasi user name dan password 3. Menampilkan list seluruh proposal

yang telah disetujui dalam Seleksi Proposal Tahap I

4. Memilih proposal rencana anggaran yang akan direview

5. Mendownload proposal rencana anggaran yang dipilih

6. Mereview rencana anggaran 7. Memasukkan komentar/memilih respon untuk proposal dimaksud

8. Meng-klik Save 9. Menyimpan komentar dan respon di

dalam database



3.2 Download Proposal Rencana Anggaran Gagal Jika download proposal rencana kegiatan pada langkah 5 gagal, maka sistem akan menampilkan pesan kesalahan dan kembali ke langkah 3




5

4. UC3.4 Precondition Kondisi awal dari sebuah use case yang harus dicapai sebelum use case ini dapat dimulai

4.1 Precondition One Ada proposal kegiatan yang sudah lulus seleksi tahap I namun belum memiliki status seleksi tahap II

Aktor telah siap dengan rencana anggaran tahunan yang akan digunakan untuk mereview rencana anggaran proposal

5. UC3.5 Post Conditions Kondisi akhir dari sebuah use case adalah keadaan akhir ketika use case tersebut berakhir

5.1 Post Condition One Setiap proposal telah memiliki status seleksi tahap II yang tercatat dalam database.


7. Additional Information Tidak ada..



1

Sistem Informasi Program Kerja dan Anggaran FKUI Use-Case Specification: Menilai Kecukupan LPJ Indikator

Keberhasilan Version 1.1

SIPROKA FKUI Version: 1.1 Use Case Specification : Menilai Kecukupan LPJ Indikator Keberhasilan Date: 06.01.2007

Confidential FKUI, 2007 Page 2


02.10.2006 0.9 Dokumen awal Isnanto Nugroho

26.11.2006 1.0 Revisi minor terhadap alur use case Isnanto Nugroho







3. Alternative Flows 4 3.1 Validasi Gagal 4 3.2 Menampilkan Detail Kegiatan Gagal 4 3.3 Menyimpan Komentar Gagal 4


5. Post Conditions Error! Bookmark not defined. 5.1 Post Condition One 5





Use-Case Specification: Menilai Kecukupan LPJ Indikator Keberhasilan

1. Use Case Name

1.1 Use Case Name Nama Use Case ini adalah : [UC4 : Menilai Kecukupan LPJ Indikator Keberhasilan]

1.2 Brief Description [UC4.1 Use Case ini digunakan untuk menilai kecukupan realisasi suatu kegiatan dari sisi pencapaian indikator keberhasilan.]



Aktor System 1. Memasukkan user name dan password 2. Memvalidasi user name dan password 3. Menampilkan list seluruh kegiatan

yang sudah menyerahkan LPJ 4. Memilih kegiatan mana yang akan dinilai 5. Menampilkan detail kegiatan dan

indikator keberhasilan serta realisasi pencapaiannya

6. Mereview realisasi pencapaian kegiatan 7. Memasukkan komentar/memilih respon untuk laporan kegiatan dimaksud

8. Meng-klik Save 9. Menyimpan komentar dan respon di

dalam database



3.2 Menampilkan Detail Kegiatan Gagal Jika tampilan detail kegiatan dan realisasi pencapaian pada langkah 5 gagal, maka sistem akan menampilkan pesan kesalahan dan kembali ke langkah 3




4. UC4.4 Precondition

4.1 Precondition One Terdapat laporan kegiatan yang sudah masuk namun belum di nilai kecukupan dari aspek indikator keberhasilannya

5. UC4.5 Post Conditions

5.1 Post Condition One Laporan kegiatan LPJ yang masuk sekarang telah di nilai kecukupannya dari aspek indikator keberhasilan


7. Additional Information Tidak ada.



Sistem Informasi Pengelolaan Program Kerja dan Keuangan FKUI

Use-Case Specification: Menyerahkan Laporan Pertanggungjawaban Version 1.1

SIPROKA FKUI Version: 1.1 Use Case Specification : Menyerahkan Laporan Pertanggungjawaban Date: 06.01.2007


2


22.10.2006 0.9 Create First Use Specification Nana Suryadigama





3




3. Alternative Flows Error! Bookmark not defined. 3.1 Validasi Username Gagal 5 3.2 Validasi Panitia Gagal 5 3.3 Save Pencapaian Indikator Keberhasilan Gagal 5 3.4 Upload LPJ Gagal 5 3.5 Pencetakan Tanda Bukti Gagal 5


5. Post Conditions Error! Bookmark not defined. 5.1 LPJ Tersimpan Error! Bookmark not defined.





4

Use-Case Specification: Menyerahkan Laporan Pertanggungjawaban

1. Use Case Name

1.1 Use Case Name Nama Use Case ini adalah : [UC5 Menyerahkan Laporan Pertanggungjawaban]

1.2 Brief Description [UC5.1 Semua proposal kegiatan yang telah dilaksanakan harus menyerahkan laporan pertanggung jawaban sesuai waktu yang telah ditentukan. Fungsi ini digunakan untuk memenuhi evaluasi. Pihak panitia menyerahkan laporan pertanggungjawaban kepihak manajemen keuangan, dan pihak manajemen keuangan dapat memberikan peringatan kepada setiap panitia yang terlambat menyerhakan laporan maupun belum sama sekali. Pihak manjemen keuangan melakukan pengolahan setiap laporan keungan untuk dilakukan proses rekapitulasi di proses selanjutnya]



Aktor System 1. Memasukkan User Name dan Password 2. Memilih akan berperan sebagai panitia untuk kegiatan yang mana

3. Memvalidasi user name dan password 4. Memvalidasi apakah benar user tsb

termasuk panitia kegiatan yang dipilih 5. Menampilkan layar penyerahan LPJ 6. Meng-enter folder path laporan pertanggungjawaban (laporan realisasi kegiatan dan realisasi anggaran)

7. Meng-input pencapaian indikator keberhasilan untuk kegiatan

8. Pilih Save 9. Men-save pencapaian indikator

keberhasilan 10. Meng-upload laporan

pertanggungjawaban (laporan realisasi kegiatan dan realisasi anggaran)

11. Menampilkan di tanda bukti penyerahan LPJ di layar

12. Mencetak tanda bukti penyerahan proposal



5


3.1 Validasi Username Gagal Pada langkah 3 jika validasi user name dan password gagal, maka sistem akan mengeluarkan pesan kesalahan dan user harus memasukkan kembali username dan password (kembali ke langkah 1)

3.2 Validasi Panitia Gagal Pada langkah 4 jika validasi panitia gagal, maka sistem akan mengeluarkan pesan kesalahan dan user harus memilih kembali panitia kegiatan yang akan diwakili (kembali ke langkah 2)

3.3 Save Pencapaian Indikator Keberhasilan Gagal Pada langkah 9 jika mensave pencapaian indikator keberhasilan gagal, maka sistem akan mengeluarkan pesan kesalahan dan kembali ke langkah 5

3.4 Upload LPJ Gagal Pada langkah 10 jika upload laporan pertanggunjawaban gagal, maka sistem akan mengeluarkan pesan kesalahan dan kembali ke langkah 5

3.5 Pencetakan Tanda Bukti Gagal Pada langkah 12 jika pencetakan tanda bukti gagal, maka sistem akan mengeluarkan pesan kesalahan dan kembali ke langkah 11

4. UC5.4 Precondition Kondisi awal dari sebuah use case yang harus dicapai sebelum use case ini dapat dimulai

4.1 Precondition One Aktor telah menyiapkan softcopy laporan pertanggung jawaban (realisasi kegiatan dan realisasi anggaran) dalam suatu folder

5. UC5.5 Post Conditions Kondisi akhir dari sebuah use case adalah keadaan akhir ketika use case tersebut berakhir

5.1 Post Condition One Laporan Pertanggungjawaban kegiatan yang diajukan telah tersimpan dengan baik dalam database.

6. Special Requirements Tidak ada

7. Additional Information Tidak ada



1

Sistem Informasi Pengelolaan Anggaran dan Program Kerja FKUI

Supplementary Specification

Version 1.1

SIPROKA FKUI Version: 1.1 Supplementary Specification Date: 07.01.2007


2


23.11.2006 0.9 Pembuatan Pertama Isnanto Nugroho

05.12.2006 1.0 Revisi bds masukan Isnanto Nugroho

07.01.2007 1.05 Revisi minor Nana Suryadigama

07.01.2007 1.1 Revisi berdasarkan Presentasi Isnanto Nugroho



3

Table of Contents 1. Introduction 4

1.1 Purpose 4 1.2 Scope 4 1.3 Definitions, Acronyms and Abbreviations 4 1.4 Overview 4

2. Usability 4 2.1 Mudah Dipelajari dan Digunakan Error! Bookmark not defined. 2.2 Menggunakan Bahasa Indonesia yang baku Error! Bookmark not defined.

3. Reliability 4 3.1 Sistem Availability 4

4. Performance 4 4.1 Response Time 4 4.2 Processing Time 5 4.3 Kapasitas 5

5. Supportability 5 5.1 Coding Standard 5

6. Design Constraints 5 6.1 Bahasa Pemrograman 5 6.2 Sistem Operasi 5 6.3 Spreadsheet Anggaran 5 6.4 Database 5

7. Online User Documentation and Help System Requirements 5

8. Purchased Components 6

9. Interfaces 6 9.1 User Interfaces 6 9.2 Software Interfaces 6 9.3 Communications Interfaces 6

10. Licensing Requirements 6

11. Legal, Copyright and Other Notices 6



4

Supplementary Specification 1. Introduction

Dokumen ini menerangkan requirement non-fungsional dari sistem yang tidak ditemukan dalam Use Case Specification.

1.1 Purpose Tujuan dokumen ini adalah menjelaskan requirement non fungsional dari sistem Manajemen Keuangan FKUI

1.2 Scope Dokumen ini merupakan bagian dari dokumen requirement dari sistem Manajemen Keuangan FKUI di Fakultas Kedokteran Universitas Indonesia. Selain proyek tersebut, tidak ada proyek lain yang terkait dengan dokumen ini.

1.3 Definitions, Acronyms and Abbreviations Seluruh istilah yang ada dalam dokumen ini akan dijelaskan dalam Glossary.

1.4 Overview Dokumen ini terdiri dari beberapa bagian yaitu Introduction, functionality, usability, realibility, performance, supportability, constraints, help documentations, purchased components dan licensing requirements.

2. Usability

[SUPP1 User Interface Sistem harus mudah dipelajari dan digunakan]

Sistem harus dapat dipelajari dan digunakan dengan mudah oleh user. Rata-rata waktu pembelajaran tidak lebih dari 1 (satu) minggu, sedangkan jumlah input error pada sistem harus < 90% [SUPP2 User Interface Sistem harus menggunakan bahasa Indonesia sesuai KBBI]

Bahasa yang digunakan dalam antarmuka aistem menggunakan bahasa Indonesia yang baik dan benar yang baku sesuai dengan Kamus Besar Bahasa Indonesia (KBBI)

3. Reliability

3.1 Sistem Availability [SUPP3 sistem memiliki kemampuan uptime > 98%]

Sistem availability sistem harus >98% kecuali untuk kondisi yang dapat dikategorikan sebagai force majeure

4. Performance

4.1 Response Time [SUPP4 sistem memiliki kemampuan respone time < 10s.]

Response Time sistem harus kurang dari 10 detik



5

4.2 Processing Time [SUPP5 sistem memiliki kemampuan proses pelaporan (processing time) < 30s.]

Total waktu yang digunakan dalam pemrosesan data/laporan harus tidak lebih dari 30 detik.

4.3 Kapasitas [SUPP6 sistem dapat melayani minimal 10 user.]

Sistem harus dapat melayani sampai dengan 10 user dalam satu waktu tertentu (concurrent)

5. Supportability

5.1 Coding Standard

[SUPP7 Coding Standard]

Pengembangan coding sistem harus mengikuti suatu standar penulisan code tertentu yang terdokumentasikan sehingga memudahkan maintanance atau pengembangan selanjutnya.

6. Design Constraints

6.1 Bahasa Pemrograman [SUPP8 Bahasa Pemrograman Open Source]

Sistem harus dikembangkan dengan bahasa pemrograman berbasis open source dalam hal ini PHP, guna meminimalisasi biaya pengembangan yang diperlukan sekaligus juga mendukung Indonesia Go Open Source (IGOS)

6.2 Sistem Operasi [SUPP9 sistem server dijalankan di sistem operasi berbasis windows 2000.]

Sistem operasi yang digunakan dalam server harus menggunakan Windows 2000 atau versi di atasnya.

6.3 Spreadsheet Anggaran [SUPP10 sistem menggunakan spreadsheet yang kompatibel dengan MS.Excel 2003 keatas.]

File spreadsheet yang digunakan dalam sistem harus menggunakan file Microsoft Excel versi 2003 dan keatas

6.4 Database [SUPP11 Database yang digunakan berbasis open source..]

Database menggunakan MySQL yang juga berbasis open source sehingga meminimalisasi biaya pengembangan yang diperlukan sekaligus juga mendukung Indonesia Go Open Source (IGOS).

7. Online User Documentation and Help System Requirements Dokumentasi dan Help harus disediakan baik dalam bentuk hard maupun soft copy. Khusus untuk online help



6

system, perlu disediakan sebuah aplikasi help yang mampu mencari jawaban atas pertanyaan dengan keyword tertentu.

8. Purchased Components Tidak ada requirement yang diperlukan dalam aspek ini.

9. Interfaces

9.1 User Interfaces [SUPP12 User interface standard sesuai browser]

User Interface yang harus digunakan adalah user interface standar yang ada di Windows (desktop interface) atau sesuai dengan interface yang dapat ditampilkan di browser

9.2 Software Interfaces [SUPP13 sistem yang dikembangkan dapat diintegrasikan dengan sistem yang sudah ada]

Sistem harus mampu berinteraksi dengan seluruh komponen dari sistem FKUI eksisting

9.3 Communications Interfaces [SUPP14 sistem dapat diakses dengan mengunakan Wi-Fi.]

Sistem harus mampu berinteraksi dengan sistem lain di FKUI melalui jaringan LAN yang ada termasuk koneksi melalui Wi-Fi

10. Licensing Requirements Sistem tidak boleh digunakan untuk kepentingan selain kepentingan FKUI

11. Legal, Copyright and Other Notices Sistem ini hanya digunakan untuk internal dan tidak ditujukan untuk pihak ketiga.



7



1


Glossary

Version 1.1

SIPROKA FKUI Version: 1.1 Glossary Date: 07.01.2007


Page 2


25.10.2006 0.5 first draft Aria K

26.10.2006 0.9 Updates Aria K

06.12.2006 1.0 Revisi berdasarkan review Aria K

07.01.2007 1.1 Revisi berdasarkan presentasi Isnanto Nugroho



Page 3

Table of Contents 1. Introduction 4

1.1 Purpose 4 1.2 Scope 4

2. Definitions 4



Page 4

Glossary

1. Introduction

1.1 Purpose Dokumen ini berisikan kosakata teknis yang terkait dengan proyek.

1.2 Scope Dokumen ini mendefinisikan istilah-istilah yang spesifik bagi proyek

2. Definitions Dalam pembahasan ini terdapat beberapa terminology istilah yang perlu diberi batasan yaitu antara lain sebagai berikut :

2.1. [TERM1 Pimpinan Fakultas]

Dekan dibantu 2 orang wakil yang mengurus masalah akademis dan non akademis

2.2. [TERM2 Manajer]

Staf yang bertanggung jawab langsung kepada Wakil Dekan untuk mengurus hal-hal yang sifatnya utama dan strategis dalam penyelenggaraan kegiatan di Fakultas. Manajer bertanggung jawab atas 8 hal manajerial yaitu pendidikan, penelitian, teknologi informasi, mahasiswa dan alumni, keuangan, SDM, fasilitas, hukum dan kelembagaan

2.3. [TERM3 Rencana strategis]

suatu rencana program kegiatan yang akan dilaksanakan selama satu tahun. Rencana ini disusun bersama oleh pimpinan fakultas beserta manajer pada awal tahun.

2.4. [TERM4 Panitia]

Kepanitiaan yang dikepalai oleh seorang penanggung jawab. Kepanitiaan ini bertanggung jawab atas perencanaan dan pelaksanaan suatu program kegiatan. Pada tahap awal, pelaksana program mengajukan proposal suatu kegiatan, baik yang bersifat rutin maupun yang insidentil. Kegiatan rutin umumnya berkaitan dengan pendidikan dimana telah terstruktur dalam suatu kurikulum, atau kegiatan lain yang telah direncanakan dalam rencana strategis. Kegiatan insidentil adalah kegiatan yang dilaksanakan sewaktu-waktu sesuai kebutuhan. Panitia yang bertanggung jawab untuk satu kegiatan. Panitia dapat erdiri dari staf manajer, TU, departemen, staf pengajar maupun badan kegiatan mahasiswa

2.6. [TERM5 LPJ]

Laporan Pertanggunjawaban. Laporan yang diserahkan setiap panitia pelaksana program setiap akhir pelaksanaan kegiatan. Terdiri dari laporan pencapaian indikator keberhasilan dan penggunaan anggaran.



Page 5

Project Name : SIPROKA FKUI [Revision: 1.1000, Version Label ] FEAT : All Features

Requirement Type : Feature Requirement Type Printed by: NANA

Printed on : 08/01/2007 @ 11:25:52 AM Page: 1

Priority Status Difficulty Stability Risk

FEAT 1.. Entry data proposal High Proposed High High High

FEAT 2.. Laporan rekapitulasi status proposal

High Proposed Medium High High

FEAT 3.. Sistem pendukung proses seleksi proposal.

High Proposed High High High

FEAT 4. .Entry data LPJ High Proposed High High High

FEAT 5.. Pendukung proses penilaian LPJ.

Medium Proposed High Medium High

FEAT 6.. Rekapitulasi informasi kegiatan.

High Proposed High Medium High

Project Name : SIPROKA FKUI [Revision: 1.1000, Version Label ] NEED : All Need

Requoirement Type : Need Requirement Type Printed by: NANA


Priority Origin Current Solution Proposed Solution

NEED1... Database Proposal yang terintegrasi High Stakeholder

Pelaporan dengan hardcopy


NEED2... Proses Administrasi Pengajuan roposal yang Efisien High Stakeholder



NEED3.. Sistem monitoring realisasi kegiatan High Stakeholder



NEED4 .. Proses Administrasi Penilaian LPJ yang Efisien High Analysis



Project Name : SIPROKA FKUI [Revision: 1.1000, Version Label ] STRQ : All Stakeholder

Requirement Tupe : Stakeholder Request Requirement Type Printed by: ARIA


Priority Status Difficulty Risk

STRQ1… Database proposal yang terintegrasi High Approved High High

STRQ 2.. Proses administrasi yang efisien High Approved High High

STRQ 3.. Sistem monitoring realisasi kegiatan High Approved High High

STRQ 4.. Sistem monitoring kesesuaian kegiatan dengan visi

High Approved High High

STRQ 5.. Sistem pelaporan guna kepentingan audit High Approved High High

Project Name : SIPROKA FKUI [Revision: 1.1000, Version Label ] SUPP : All Supplementary

Requirement Tupe : Supplementary Requirement Type Printed by: ISNANTO


Priority Status Difficulty Stability Risk

SUPP1 User Interface Sistem harus mudah dipelajari dan digunakan

High Proposed Medium Medium Low

SUPP2 User Interface Sistem harus menggunakan bahasa Indonesia sesuai KBBI

Medium Proposed Medium Medium Low

SUPP3 Sistem memiliki kemampuan uptime

> 98% High Proposed Medium High High

SUPP4 Sistem memiliki kemampuan respone time < 10s.

Medium Proposed Medium High High

SUPP5 Sistem memiliki kemampuan proses pelaporan (processing time) < 30s High Proposed Medium High High

SUPP6 Sistem dapat melayani minimal 10 user

High Proposed Medium Medium Medium

SUPP7 Coding Standard Medium Proposed Medium Medium Medium

SUPP8 Bahasa Pemrograman Open Source High Proposed Medium Medium Medium

SUPP9 Sistem server dijalankan di sistem operasi berbasis windows 2000

High Proposed Medium High Medium

SUPP10 sistem menggunakan spreadsheet yang kompatibel dengan MS.Excel Medium Proposed Medium High High

SUPP11 Database yang digunakan berbasis open source High Proposed Medium High High

SUPP12 User interface standard sesuai browser High Proposed Medium High High

SUPP13 Sistem yang dikembangkan dapat diintegrasikan dengan sistem yang sudah ada

High Proposed Medium High High

SUPP14 Sistem dapat diakses dengan mengunakan Wi-Fi. High Proposed Medium High Medium

SUPP15 Semua pengguna harus sudah terlatih sebelum sistem diimplementasikan.

Medium Proposed Medium Medium Medium

SUPP16 Sistem aplikasi versi 1.0 diselesaikan dalam waktu paling lambat 6 bulan ( Juli 2007)

Medium Proposed Medium Medium Medium

Project Name : SIPROKA FKUI [Revision: 1.1000, Version Label ] SUPP : All Supplementary

Requirement Tupe : Use Case Requirement Type Printed by: ISNANTO


Priority Status Difficulty Risk

UC1 : Mengajukan Proposal Kegiatan High Proposed Medium Low

UC2 : Seleksi Proposal Tahap I Medium Proposed Medium Low

UC3 : Seleksi Proposal Tahap II High Proposed Medium High

UC4 : Menilai Kecukupan LPJ Indikator Keberhasilan Medium Proposed Medium High

UC5 : Menyerahkan Laporan Pertanggungjawaban High Proposed Medium High

UC6 : Melihat informasi proposal kegiatan High Proposed Medium Medium

UC7 : Menyetujui Proposal Medium Proposed Medium Medium

UC8 : Menilai Kecukupan LPJ Keuangan High Proposed Medium Medium

UC9 : Merekapitulasi Realisasi Anggaran High Proposed Medium Medium

UC10 : Mengevaluasi Kinerja Keuangan Medium Proposed Medium High

Project Name : SIPROKA FKUI [Revision: 1.1000, Version Label:] STRQ-NEED: STRQ to NEED STRQ to NEED Printed by: NANA


NEED1 . Database Proposal yang Terintegrasi

NEED2 . Proses Administrasi Pengajuan roposal yang Efisien

NEED3.. Sistem monitoring realisasi kegiatan

NEED4 .. Proses Administrasi Penilaian LPJ yang Efisien

STRQ1 . Database Proposal yang Terintegrasi

��

STRQ2 . Proses Administrasi yang Efisien

�

STRQ3 . Sistem monitoring realisasi kegiatan

STRQ4 . Sistem monitoring kesesuaian kegiatan dengan visi

STRQ5 . Sistem pelaporan guna kepentingan audit

Project Name : SIPROKA FKUI [Revision: 1.1000, Version Label:] NEED-FEAT : NEED to Features

Need to Features Printed by: ARIA


FEAT 1.. Entry Data Proposal

FEAT 2.. Laporan Rekapitulasi Status Proposal

FEAT 3.. Sistem pendukung proses seleksi proposal

FEAT 4.. Entry Data LPJ

FEAT 5.. Pendukung Proses Penilaian LPJ

FEAT6 .. Rekapitulasi Informasi Kegiatan

NEED1 . Database Proposal yang Terintegrasi

� �

NEED2 . Proses Administrasi Pengajuan Proposal yang Efisien

�

NEED3 . Sistem monitoring realisasi kegiatan

�

NEED4 . Proses Administrasi Penilaian LPJ yang Efisien

�

Project Name : SIPROKA FKUI [Revision: 1.1000, Version Label:] UC-FEAT : Use Case to Features

Use Case to Features Printed by : NANA








UC 1. Mengajukan…… ��

UC 2. Seleksi ………… �

UC 3. Seleksi ………… �

UC 4. Menilai i…………. �

UC 5. Menyerahkan…… �

UC 6. Melihat…… �

UC 7. Menyetujui…….. �

UC 8. Menilai………… �

UC 9. Merekap……… �

UC 10. Mengevaluasi.. �

Project Name : SIPROKA FKUI [Revision: 1.1000, Version Label UC-FEAT : Use Case to Supplementary

Use Case to Supplementary Printed by: NANA








SUPP1 User Interface sistem harus mudah dipelajari dan digunakan

� �

SUPP2 User Interface Sistem harus menggunakan bahasa Indonesia sesuai KBBI

�

SUPP3 Sistem memiliki kemampuan uptime > 98%

�

SUPP4 Sistem memiliki kemampuan respone

�

SUPP5 Sistem memiliki kemampuan proses pelaporan (processing time) < 30s

�

SUPP6 Sistem dapat melayani minimal 10 user �

SUPP7 Coding Standard

�

SUPP8 Bahasa Pemrograman Open Source �

SUPP9 Sistem server dijalankan di sistem operasi berbasis windows 2000 �

SUPP10 Sistem menggunakan spreadsheet yang kompatibel dengan MS.Excel 2003 keatas.

�

Project Name : SIPROKA FKUI [Revision: 1.1000, Version Label UC-FEAT : Use Case to Supplementary

Use Case to Supplementary Printed by: NANA


SUPP11 Database yang digunakan berbasis open source

SUPP12 User interface standard sesuai browser

SUPP13 Sistem yang dikembangkan dapat diintegrasikan dengan sistem yang sudah ada

SUPP14 Sistem dapat diakses dengan mengunakan Wi-Fi.

SUPP15 Semua pengguna harus sudah terlatih sebelum sistem diimplementasikan.

SUPP16 Sistem aplikasi versi 1.0 diselesaikan dalam waktu paling lambat 6 bulan ( Juli 2007)

Page 2

SIPROKA FKUI

Documents

Transcript of SIPROKA FKUI