Anda di halaman 1dari 88

Fakultas Kedokteran Universitas Indonesia

Sistem Informasi Pengelolaan Program Kerja


dan Anggaran FKUI
Requirements Management Plan
Version 1.1

SIPROKA FKUI
Requirements Management Plan

Date

Version:
1.1
Date: 10.01.2007

Revision History
Description

Version

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

Confidential

FKUI, 2007

Page 2

SIPROKA FKUI
Requirements Management Plan

Version:
1.1
Date: 10.01.2007

Table of Contents
1.

2.

3.

Introduction

1.1
1.2
1.3
1.4
1.5

4
4
4
4
4

Requirements Management

2.1
2.2

4
5

Organization, Responsibilities, and Interfaces


Contact Table

Requirements Artifacts
3.1

3.2
3.3
4.

Purpose
Scope
Definitions, Acronyms, and Abbreviations
References
Overview

Artifact Description
3.1.1
Document Types
3.1.2
Requirement Types
3.1.3
Attributes
3.1.4
Attribute Values
Traceability
3.2.1
Traceability Criteria for Requirement Types
3.2.2
NEED to STRQ Traceability
Reports and Measures

6
6
7
7
9
10
10
11
11

Requirements Change Management

12

4.1

12

Change Request Processing and Approval

Confidential

FKUI, 2007

Page 3

SIPROKA FKUI
Requirements Management Plan

Version:
1.1
Date: 10.01.2007

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 SanchezTobar, Change Control Manager, at xtobar@classicscd.com
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
Project
manager

Confidential

Tanggung Jawab
Individu yang bertanggungjawab penuh atas keberlangsungan proyek. Manajer
proyek harus memastikan penjadwalan aktifitas, pengalokasikan dan
penyelesaiannya sesuai dengan jadwal proyek, anggaran dan kebutuhan
kualitas.
FKUI, 2007

Page 4

SIPROKA FKUI
Requirements Management Plan

Quality
assurance
(QA)
Developer

Team leader

Configuration
manager
Requirements
specifier

Change
Control
Manager

Version:
1.1
Date: 10.01.2007

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

farian@fk.ui.ac.id

stakeholder

Menaldi
Rasmin

Dekan

FKUI

menaldi@fk.ui.ac.id

Boy Sabarguna

Manajer Keuangan

FKUI

sabarguna@fk.ui.ac.id

project manager

Aria Kekalih

Asisten Manajer IT

FKUI

aria@fk.ui.ac.id

quality assurance

Ali Sungkar

Manajer IT

FKUI

alisungkar@fk.ui.ac.id

team leader

Wahyono
Sumardji

Senior Developer

FKUI

bocah@fk.ui.ac.id

requirements
specifier

M. Syafii

Software Project
Manager

FKUI

syafii@fk.ui.ac.id

Isnanto
Nugroho

Senior Developer
Consultant

Konsultante

administrator

Budi Santoso

IT director

FKUI

budisan@fk.ui.ac.id

configuration

Fajar DP

Senior Software

Konsultante

bebas888@yahoo.com

Confidential

FKUI, 2007

Page 5

SIPROKA FKUI
Requirements Management Plan

Version:
1.1
Date: 10.01.2007

manager

Engineer
Nana
Suryadigama

change control
manager

Senior Software
Engineer

M.Yusuf

Konsultante

Satjau04@yahoo.com

FKUI

yusuf@fk.ui.ac.id

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
Menggambarkan kebutuhan system yang tidak dapat
digambarkan dalam use case

Glossary Term (TERM)

Supplementary
Requirements
Specification
(SUP)
Requirements
Management Plan
(RMP)

Confidential

Supplementary
Requirement (SUPP)

Menggambarkan kebutuhan danstrategi tertentu untuk


pengelolaan dan pengembangan proyek

FKUI, 2007

Page 6

SIPROKA FKUI
Requirements Management Plan

Version:
1.1
Date: 10.01.2007

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
Layanan yang seharusnya
disediakanoleh sistem, yang secara
langsung memenuhi kebutuhan
stakeholder
Deskripsi perilaku sistem yang
digambarkan dalam urutan
tindakan.
Sebuah use case seharusnya
menghasilkan keluaran yang dapat
dirasakan oleh seorang aktor
Istilah yang digunakan dalam
kosakata umum proyek Manajemen
Keuangan FKUI.
Deskripsi kebutuhan yang tidak dapat
digambarkan secara langsung oleh
use case

Priority ,Origin, Current Solution,


Proposed Solution

Feature (FEAT)

Use Case (UC)

Glossary term (TERM)


Supplementary
Requirement (SUPP)

Priority, Status, Difficulty, Stability,


Risk
Priority, Status, Difficulty, Stability,
Risk, Affect Architect, Planner
Iteration.

Ambiguity
Priority, Status, Difficulty, Stability,
Risk.

3.1.3 Attributes
Attribute

Description

Type

List Values

Requirement
Type

Diatur oleh analis.

Priority

Menunjukkan prioritas
pclanggan untuk
mengimplementasikan kebutuhan.
Digunakan pada pengelolaan ruang
lingkup dan menjelaskan prioritas
pengembangan.

High

List
Medium

FEAT, UC,
SUPP, STRQ

Low
Status

Disetting oleh analis


dan quality assurance.
Menunjukkan batasan
kebutuhan.

Confidential

FKUI, 2007

List

Proposed
Approved

FEAT, UC,
SUPP, STRQ

Incorporated

Page 7

SIPROKA FKUI
Requirements Management Plan

Version:
1.1
Date: 10.01.2007

Digunakan dalam
pengelolaan ruang
lingkup dan
menjelaskan status
proyek.
Validated

Difficulty

Diatur oleh manajer pengembang.

High

Menunjukkan
tingkatan usaha yang
dikumpulkan dengan
kebutuhan.

Medium

Digunakan dalam
pengelolaan ruang
lingkup dan
nlenjelaskan prioritas
pengembangan.

Low
High

Diatur oleh analis dan tim


pengembangan.
Stability

Menunjukkan kemugkinan
bahwa kebutuhan akan
mengalami perubahan.

Medium
List

Digunakan untuk meningkatkan


prioritas pengembangan dan untuk
menlelaskan apakah informasi
tambahan dibutuhkan.
Current Solution

Digunakan untuk menjelaskan


asal sumber pertimbangan
tambahan kebutuhan.

Untuk menjelaskan usulanProposed Solution usulan tambahan kebutuhan


pada saat pengembangan sistem.
Planner Iteration.

Origin

Risk.

Confidential

Proses perencanaan untuk


mengevaluasi kebutuhan
tambahan telah memenuhi
keperluan.
Origin (Asal) dari dari
requirement type ini apakah
berasal dari analisa stakeholder
request atau dari analisis dari
tim
Pertimbangan yang diambil
mengenai risiko yang kan terjadi
pada saat pengembangan
Sistem.

FKUI, 2007

FEAT, UC,
SUPP, STRQ

List

FEAT, SUPP

Low
text

text

n/a

n/a

text

NEED

NEED

NEED
n/a
Stakeholder

List

NEED
Analysis
High

List

Medium

STRQ, FEAT,
UC, SUPP

Low

Page 8

SIPROKA FKUI
Requirements Management Plan

Version:
1.1
Date: 10.01.2007

3.1.4 Attribute Values

Value
High
Medium
Low

Priority Sangat kritis untuk kesuksesan/ketahanan bisnisatau suatu order langsung


dan investor atau pemegang kunci account.
Priority Bermanfaat, menambah nilai kompetitif dan feature yang unik.
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

Medium
Low

Sangat sukar, misalnya untuk menyetujuinya sangat mahal dalam hal


Difficulty sumber daya ataupun uang. Seharusnya diserang dahulu atau
ditolak/dibatalkan.
Sulit tetapi dapat dilakukan tanpa menanggung resiko. Seharusnya hanya
Difficulty dikerjakan setelah seluruh requirement yang tinggi dan sulit telah
dipenuhi ataupun dibatalkan.
Mudah. Bisa dipenuhi terakhir setelah semua yang penting
Difficulty
diselesaikan.

Medium

Stability Sepertinya akan berubah, atau hal ini masih terlihat sangat samar dan
membutuhkan penjelasan lebih lanjut untuk dikerjakan..
Stability Bisa berubah namun masih cukup stabil untuk memulai pekerjaan.

Low

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

High

Stakeholder

Origin

Berasal dari stakeholder (stakholder request)

Analysis

Origin

Berasal dari analisis tim

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

High

Confidential

Description

Attribute

FKUI, 2007

Page 9

SIPROKA FKUI
Requirements Management Plan

Version:
1.1
Date: 10.01.2007

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

Stakeholder Request

Need

Feature

Use Case

Supplementary

3.2.1 Traceability Criteria for Requirement Types


Requirement Type

Guidelines

Stakeholder Request
(STRQ)

Satu atau lebih STRQ dapat


memiliki trace ke satu NEED,
namun juga bisa tidak memiliki
trace jika dirasa perlu
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

Need (NEED)

Notes

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.

Supplementary
Requirement (SUPP)

Satu SUPP harus dapat di trace ke


satu atau lebih FEAT

Confidential

FKUI, 2007

Page 10

SIPROKA FKUI
Requirements Management Plan

Version:
1.1
Date: 10.01.2007

3.2.2 NEED to STRQ Traceability

STRQ

NEED

STRQ yang
tidak
diteruskan
NEED yang
berasal dari
STRQ

NEED yang
berasal dari
hasil analisa

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

Confidential

FKUI, 2007

Page 11

SIPROKA FKUI
Requirements Management Plan

Version:
1.1
Date: 10.01.2007

Use Case Brief


Descriptions

Keseluruhan usecase dan


penjelasan
singkatnya -

Use Cases

Penjelasan-penjelasan use-case

Features Not
Traced in
Supplementary
Specs

Coverage Analysis

Laporan dari semua feature produk


yang belum dijelaskan pada nonfunctional requirement.

Features Not
Traced in Use
Cases

Daftar dari fitur


yang tidak
terhubung ke
kebutuhan non
functional
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
Daftar use case
yang berpotensi
berpengaruh
dengan mengubah
feature produk.

Impact Analysis

Menunjukan kebutuhan
sumplementari yang mungkin bisa
mengubah feature dari produk.

Impact Analysis

Kesadaran perubahan fitur


terhadap kebutuhan non functional.

Use Cases
Impacted by
Feature Changes

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
Confidential

FKUI, 2007

Page 12

SIPROKA FKUI
Requirements Management Plan

Version:
1.1
Date: 10.01.2007

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.

Confidential

FKUI, 2007

Page 13

Fakultas Kedokteran Universitas Indonesia

Sistem Informasi Pengelolaan Program Kerja dan


Anggaran FKUI

Stakeholder Requests
Version 1.1

Confidential

FKUI, 2007

Page 1

SIPROKA FKUI
Stakeholder Request

Date

Version:
1.1
Date: 07.01.2007

Version

Revision History
Description

Author

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

Confidential

FKUI, 2007

Page 2

SIPROKA FKUI
Stakeholder Request

Version:
1.1
Date: 07.01.2007

Table of Contents
1.

Introduction

1.1
1.2
1.3
1.4
1.5

4
4
4
4
4

Purpose
Scope
Definitions, Acronyms, and Abbreviations
References
Overview

2.

Establish Stakeholder or User Profile

3.

Assessing the Problem

4.

Understanding the User Environment

5.

Recap for Understanding

6.

Analysts Inputs on Stakeholders Problem (validate or invalidate assumptions)

7.

Assessing Your Solution (if applicable)

8.

Assessing the Opportunity

9.

Assessing Reliability, Performance, and Support Needs

10

9.1 Other Requirements

11

10.

Wrap Up

11

11.

Analysts Summary

12

Confidential

FKUI, 2007

Page 3

SIPROKA FKUI
Stakeholder Request

Version:
1.1
Date: 07.01.2007

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:
Confidential

Fakultas Kedokteran Universitas Indonesia


FKUI, 2007

Page 4

SIPROKA FKUI
Stakeholder Request

Version:
1.1
Date: 07.01.2007

Name:
Job Title:
What are your key responsibilities?
What deliverables do you produce?
For whom?
How is success measured?

What problems interfere with your success?


What, if any, trends make your job easier or harder?

Company / Industry:
Name:
Job Title:
What are your key responsibilities?
What deliverables do you produce?
For whom?
How is success measured?

What problems interfere with your success?


What, if any, trends make your job easier or harder?

Company / Industry:
Name:
Job Title:
What are your key responsibilities?
What deliverables do you produce?
For whom?
How is success measured?
What problems interfere with your success?
What, if any, trends make your job easier or harder?
Company / Industry:
Name:
Job Title:
What are your key responsibilities?

Confidential

dr. Menaldi Rasmin, Sp(K), FCCP


Dekan
Salah satu pengambil keputusan persetujuan dalam
pembuatan sistem informasi Pengelolaan Program Kerja
dan Anggaran.
Surat keputusan persetujuan.
Proyek pengembangan sistem informasi Pengelolaan
Program Kerja dan Anggaran.
Dengan tersedianya informasi mengenai laporan kegiatan
dan pengunaan dana secara akurat, lengkap, dan detail
yang diselenggarakan oleh seluruh civitas akademi di
FKUI.
Pengukuran tingkat effesiensi pengunaan anggaran dana
dalam kegiatan yang telah dilakukan selama ini.
Adanya kemajuan teknologi informasi, maka dapat
dibangun sistem informasi yang berbasis komputerisasi.
Fakultas Kedokteran Universitas Indonesia
Dr. dr. Boy S. Sabarguna. MARS
Manajer Keuangan
Penangung jawab dari proyek pengembangan sistem
informasi Pengelolaan Program Kerja dan Anggaran.
Surat keputusan pengunaan dana pengembagan proyek.
tim pengembangan proyek.
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.
Bagaimana mengembangkan sistem dengan tepat waktu,
sesuai biaya yang tersedia.
Tersedianya program pengembangan sistem informasi
yang bersifat open source.
Fakultas Kedokteran Universitas Indonesia
Farian
Bendahara Departmen Keuangan
Penanggung jawab dalam pengelolaan dana sesuai
tingkat kebutuhan kegiatan.
Laporan pengeluaran dana tahunan.
Manajer Keuangan, Dekan.
Tercapainya keseimbangan pengunaan dana kegiatan.
Mendapatkan arsip-arsip laporan pengunaan dana yang
terukur secara seimbang dengan rencana program.
Komputerisasi secara sistem mempermudah kinerja.
Fakultas Kedokteran Universitas Indonesia
Astrid S.A.
Akuntan Departmen Keuangan
Membuat laporan keuangan dalam membentuk neraca
keuangan, baik yang bersifat bulanan, tahunan dari
seluruh kegiatan maupun hanya perkegiatan.

FKUI, 2007

Page 5

SIPROKA FKUI
Stakeholder Request

Version:
1.1
Date: 07.01.2007

What deliverables do you produce?


For whom?
How is success measured?
What problems interfere with your success?
What, if any, trends make your job easier or harder?

Company / Industry:
Name:
Job Title:
What are your key responsibilities?

What deliverables do you produce?


For whom?
How is success measured?
What problems interfere with your success?
What, if any, trends make your job easier or harder?

Company / Industry:
Name:
Job Title:
What are your key responsibilities?
What deliverables do you produce?
For whom?
How is success measured?
What problems interfere with your success?
What, if any, trends make your job easier or harder?

Company / Industry:
Name:
Job Title:
What are your key responsibilities?
What deliverables do you produce?
Confidential

Lapoaran neraca keuangan.


Manajer Keuangan, Dekan.
Terpenuhinya suatu Neraca keuangan FKUI, yang sesuai
dengan laporan pertanggung jawaban seluruh kegiatan.
Adanya masalah tertentu dalam kegiatan yang kurang
effesien dalam pembuatan neraca dan pelaporan kurang
lengkapnya persyaratan Laporan pertanggungjawaban
Proses komputerisasi dengan sistem yang memeliki
database yabng akurat dan terpecaya.
Fakultas Kedokteran Universitas Indonesia
Asih Komara
Administrasi Departemen Keuangan
Membuat surat surat yang berhubungan dengan
pengunaan dana dan kegitaan, serta memastikan proposal
dan laporan pertanggungjawaban yang diserahkan dari
tim panitia.
Lembaran surat-surat kegiatan yang diselengarakan di
FKUI.
Bagian Bendahara, Operasional.
Tertatanya informasi yang cepat dan akurat untuk
mengetahui status dari proposal dan laporan pertanggung
jawaban kegiatan.
Pengerjaan yang belum tersimpat dalam suatu database.
Pengunaan sistem informasi yang terintegrasi dengan
datacenter.
Fakultas Kedokteran Universitas Indonesia
Mr. A
Sekretariat
Melakukan koordinasi kinerja yang dilakerjakan di
departement keungan dalam pengunaan dana kegiatan.
Memberikan sistem standard kerja selama ini, dan
laporan kesesuai setiap kegiatan dengan strategi yang
telah ditetapkan.
Manajer Keuangan , dan staff lain di department
keuangan.
Tersedianya informasi dan data dari aktifitas yang
dikerjakan di departemnt keuangan.
Bagaimana meningkat kecepatan dalam memberikan
laporan dari aktifitas
Pengunaan sistem informasi dengan database.

Fakultas Kedokteran Universitas Indonesia


Dr. Ali Sungkar, SpOG
Manajer TI
Melakukan koordinasi dan penangungjawab operasional
dalam pengembagan sistem informasi keungan FKUI.
Memberikan layanan-layanan yang berhubungan dengan
FKUI, 2007

Page 6

SIPROKA FKUI
Stakeholder Request

Version:
1.1
Date: 07.01.2007

For whom?
How is success measured?
What problems interfere with your success?
What, if any, trends make your job easier or harder?

Company / Industry:
Name:
Job Title:
What are your key responsibilities?
What deliverables do you produce?
For whom?
How is success measured?

What problems interfere with your success?


What, if any, trends make your job easier or harder?

pengembangan sistem informasi Pengelolaan Program


Kerja dan Anggaran.
Penguna sistem.
Sistem informasi berjalan sesuai dengan tepat waktu dan
menghasilkan ouput sesuai target yang ditetapkan.
Bagaimana mengembankan sistem informasi dengan
tingkat effesien yang tinggi dan menghasilkan kinerja
yang efektif dan memenuhi kebutuhan penguna.
Tersediannya program language, database yang bersifat
open source dan konsultan IT yang memberikan
dukungan yang kuat.
Fakultas Kedokteran Universitas Indonesia
(Manajer Ditiap divisi)
Manajer divisi di FKUI
Melakukan koordinasi dengan staff di divisi masing
masing dalam pengajuan proposal kegiatan dan laporan
pertanggungjawaban kegiatan.
Memberikan laporan pertanggung jawabab pengunaan
dana kegiatan dari setiap proposal yang disetujui.
Department Keuangan.
Tersedianya informasi yang cepat dari persetujuan
proposal yang diajukan dan besar pengunaan dana yang
disetujui serta kelengakapan proposal dan laoran
pertanggung jawaban kegiatan..
Bagaimana membuat proposal yang standard dan sesuai
dengan program kerja sesuai visi FKUI.
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.

Confidential

FKUI, 2007

Page 7

SIPROKA FKUI
Stakeholder Request

Version:
1.1
Date: 07.01.2007

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?


What is their computer background?

Bervariasi, minimal D3
Telah familiar dengan pengunaan computer baik didapat
secara kursus maupun pelatihan yang ada.
Saat ini pekerjaan dilakukan dengan menggunakan
berbasis windows, bisa dikatakan tidak mengunakan
berbasis DOS.
Pada dasarnya, sistem operasi yang berbasis interface
seperti windows tidak sulit dipelajari.
Web based yang terintgrasi menggunakan intranet
fakultas
Inteface yang digunakan adalah diutamakan mengunakan
program language yang bersifat open source dan dengan
mudah dipelajari oleh setiap penguna.

Are users experienced with this type of application?


Which platforms are in use?
What are your plans for future platforms?
Which additional applications do you use that we need to
interface with?
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
1

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

Terlambatnya proses penyetujuan anggaran karena birokrasi dan


kurang efisiennya proses administrasi
Kurangnya informasi yang detail dan lengkap mengenai kegiatan yang
telah disetujui anggarannya, telah dilaksanakan serta anggaran yang
telah digunakan.

Confidential

FKUI, 2007

Solusi yang diusulkan


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.
s.d.a
s.d.a

Page 8

SIPROKA FKUI
Stakeholder Request

4
5
6
7
8

Version:
1.1
Date: 07.01.2007

Sulit dalam melakukan evaluasi keuangan dan kinerja operasional tiap


program kerja dalam waktu yang dibutuhkan
Masih belum didapat parameter pengukuran dari kegiatan yang
diselengarakan dengan tingkat kesesuai visi yang ditetapkan.
Adanya program kerja kegiatan yang bersifat ganda dikarena kuarang
koordinasi dengan berbagai department dengan rencana strategi yang
telah disusun.
Masih kurangnya informasi yang dapat dengan cepat diperoleh
mengenai kegiatan yang pernah dilakukan sebagai bahan referensi
dalam penyusunan proposal kegiatan selanjutnya.

s.d.a

Tingkat kesiapan yang masih memiliki komplesksitas tinggi dalam


memberikan laporan dari manjemen keuangan pada saat dilakukan
proses audit.

s.d.a

s.d.a
s.d.a
s.d.a

6. Analysts Inputs on Stakeholders 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.
Confidential

FKUI, 2007

Page 9

SIPROKA FKUI
Stakeholder Request

Version:
1.1
Date: 07.01.2007

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?
berkala.

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

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

FKUI, 2007

Page 10

SIPROKA FKUI
Stakeholder Request

Version:
1.1
Date: 07.01.2007

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
1
2
3

Nama
dr. Menaldi Rasmin,
Sp(K), FCCP
Dr. dr. Boy S.
Sabarguna. MARS
Farian

Confidential

Company
FKUI
FKUI
FKUI

Jabatan
Dekan
Manajer Keuangan
Bendahara Departmen
Keuangan

FKUI, 2007

Phone

Email

3101066

menaldi@fk.ui.ac.id

3101066

sabarguna@fk.ui.ac.id

3101066

farian@fk.ui.ac.id

Page 11

SIPROKA FKUI
Stakeholder Request

Version:
1.1
Date: 07.01.2007

Astrid S.A.

FKUI

Asih Komara

FKUI

Aria Kekalih

MTI UI

Fajar Edisya Putera

MTI UI

Isnanto Nugroho S

MTI UI

Nana Suryadigama

MTI UI

Akuntan Departmen
Keuangan
Administrasi
Departemen Keuangan
Tim Pengembang
(SIPROKA)
Tim Pengembang
(SIPROKA)
Tim Pengembang
(SIPROKA)
Tim Pengembang
(SIPROKA)

3101066

astrid@fk.ui.ac.id

3101066

komara@fk.ui.ac.id
aria@fk.ui.ac.id
bebas888@yahoo.com
isna199@yahoo.com
satjau04@yahoo.com

11. Analysts 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.

Confidential

FKUI, 2007

Page 12

SIPROKA FKUI
Stakeholder Request

Confidential

Version:
1.1
Date: 07.01.2007

FKUI, 2007

Page 13

Fakultas Kedokteran Universitas Indonesia

Sistem Informasi Pengelolaan Program Kerja


dan Anggaran FKUI
Vision
Version 1.1

Confidential

FKUI, 2007

Page 1

SIPROKA FKUI
Vision

Date

Version:
1.1
Date: 07.01.2007

Version

Revision History
Description

st

Author

02.10.2006

0.5

<1 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 2

SIPROKA FKUI
Vision

1.1
1.2
1.3
1.4
1.5
1.6
2.

3.

5
5
5
5
5
5
6

2.1
2.2
2.3

Business Opportunity
Problem Statement
Product Position Statement

6
6
6

Stakeholder and User Descriptions

3.6
3.7
3.8

5.

Table of Contents

Introduction
Purpose
Scope
Definitions, Acronyms, and Abbreviations
References
Overview

Positioning

3.1
3.2
3.3
3.4
3.5

4.

Version:
1.1
Date: 07.01.2007

Market Demographics
Stakeholder Summary
User Summary
User Environment
Stakeholder Profiles
3.5.1
Pimpinan Fakultas
3.5.2
Divisi Keuangan FKUI
3.5.3
Divisi Keuangan FKUI
User Profiles
3.6.1
Panitia
Key Stakeholder or User Needs
Alternatives and Competition

7
7
8
9
10
10
10
10
11
11
11
12

Product Overview

12

4.1
4.2
4.3
4.4
4.5

12
13
13
13
14

Product Perspective
Summary of Capabilities
Assumptions and Dependencies
Cost and Pricing
Licensing and Installation

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

8.

Other Product Requirements

14

8.1
8.2
8.3
8.4

14
15
15
15

9.

Error! Bookmark not defined.

Applicable Standards
System Requirements
Performance Requirements
Environmental Requirements

Documentation Requirements

Rahasia

15
FKUI 2007

Page 3

SIPROKA FKUI
Vision

9.1
9.2
9.3
9.4
A

Version:
1.1
Date: 07.01.2007

User manual
On-line help
Installation Guide, Configuration dan ReadMe File
Labelling and Packaging

Feature Attributes

Rahasia

15
15
15
15
15

FKUI 2007

Page 4

SIPROKA FKUI
Vision

Version:
1.1
Date: 07.01.2007

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 5

SIPROKA FKUI
Vision

Version:
1.1
Date: 07.01.2007

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 6

SIPROKA FKUI
Vision

Version:
1.1
Date: 07.01.2007

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
Panitia

Pimpinan Fakultas

Rahasia

Description

Responsibilities

Bisa berupa kelompok atau


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

Adalah dekan dan wakil


dekan
yang mengkoordinasikan
pelaksanaan
realisasi
pelaksanaan
rencana strategis tahunan
FKUI oleh setiap divisi dan
FKUI 2007

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
Menganalisa kesesuaian proposal suatu
kegiatan dengan rencana strategis tahunan.
Melakukan seleksi perlu aatu tidaknya
disetujui suatu proposal kegiatan
Menyesuaikan proposal yang masuk dengan
Page 7

SIPROKA FKUI
Vision

Version:
1.1
Date: 07.01.2007

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
Manajer
keuangan

Description

Stakeholder

Adalah
manajer
keuangan

divisi

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

Rahasia

Staf divisi keuangan yang


menilai akuntabilitas suatu
laporan pertanggungjawaban
kegiatan khususnya dalam hal
anggaran

FKUI 2007

Mencatat dan
kelengkapan

menilai

bukti

transaksi

Memberikan peringatan kepada panitia yang


belum memberikan LPJ pada batas waktu
Memberikan peringatan kepada panitia yang
belum lengkap persyaratan bukti transaksi
dalam laporan pertanggungjawaban
Page 8

SIPROKA FKUI
Vision

Bendahara

Version:
1.1
Date: 07.01.2007

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
tahunan

rekapitulasi

laporan

keuangan

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 9

SIPROKA FKUI
Vision

Version:
1.1
Date: 07.01.2007

3.5 Stakeholder Profiles


3.5.1

3.5.2

3.5.3

Rahasia

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

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

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

FKUI 2007

Page 10

SIPROKA FKUI
Vision

Version:
1.1
Date: 07.01.2007

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 11

SIPROKA FKUI
Vision

[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
[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
[NEED4 : Proses Administrasi
Penilaian LPJ yang Efisien]
Sistem administrasi penilaian
Laporan Pertanggungjawaban
(LPJ) perlu diefisienkan supaya
penilaian lebih objektif

Version:
1.1
Date: 07.01.2007

High

Stakeholder

Pelaporan dengan
hardcopy

Intranet Web-based
application

Medium

Stakeholder

Pelaporan
dengan
hardcopy

Intranet Webbased application

Medium

Developer

Pelaporan
dengan
hardcopy

Intranet Webbased application

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 12

SIPROKA FKUI
Vision

Version:
1.1
Date: 07.01.2007

4.2 Summary of Capabilities


Table 4-1
Customer Benefit
terintegrasinya pendataan proposal
kegiatan yang masuk, karena kegiatan
yang ada sangat banyak dan
melibatkan berbagai pihak
.
Terintegrasinya system perencanaan
program dengan perencanaan Renstra
tahunan FKUI, dikaitkan dengan
anggaran dan pencapaian
tersedianya informasi yang
terintegrasi dan komprehensif
mengenai kegiatan yang telah
disetujui anggarannya, telah
dilaksanakan serta anggaran yang
telah digunakan
Pimpinan fakultas dan Manajer
keuangan dapat mempelajari kinerja
operasional dan penggunaan
keuangan untuk tiap kegiatan dan
memantau pelaksana program yang
belum memberikan laporan
Pimpinan fakultas dapat
merencanakan kegiatan yang strategis
untuk kemajuan fakultas berdasarkan
data kegiatan serta alokasi dananya
Panitia perlu mengetahui dengan
cepat mengenai persetujuan proposal
dan anggarannya.

Customer Support System


Supporting Features
Adanya aplikasi entry untuk proposal
kegiatan dengan format nama kegiatan ,
tujuan, waktu, tempat, kepanitiaan dan
anggaran.
Adanya aplikasi yang merekapitulasi
seluruh kegiatan, proposal yang masuk
dengan perbandingan neraca keuangan
dan status yang lengkap
Adanya aplikasi yang mempermudah
pelaporan pertanggungjawaban dan
menampilkan database laporan hasil
kegiatan serta anggaran yang terpakai
Adanya aplikasi supplementary yang
bersifat time-series dan otomatis
memperingatkan manajer apabila setelah
deadline terdapat pelaksana program yang
belum memberikan laporan
Adanya sistem informasi manajemen yang
menampilkan rekapitulasi informasi
berupa realisasi anggaran, serta trend yang
bermanfaat untuk mendukung
pengambilan keputusan strategis.
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 13

SIPROKA FKUI
Vision

Version:
1.1
Date: 07.01.2007

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 14

SIPROKA FKUI
Vision

Version:
1.1
Date: 07.01.2007

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

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

Feature Attributes

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

Rahasia

FKUI 2007

Page 15

Fakultas Kedokteran Universitas Indonesia

Sistem Informasi Pengelolaan Program Kerja dan


Anggaran FKUI

Use Case : Mengajukan Proposal Kegiatan


Version 1.1

Rahasia

FKUI 2007

Page 1

SIPROKA FKUI
Use Case Specification : Mengajukan Proposal Kegiatan

Date

Version

Version:
1.1
Date: 05.01.2007

Revision History
Description

Author

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

Confidential

FKUI, 2007

Page 2

SIPROKA FKUI
Use Case Specification : Mengajukan Proposal Kegiatan

Version:
1.1
Date: 05.01.2007

Table of Contents
1.

Use Case Name

1.1
1.2

4
4

Use Case Name


Brief Description

2.

Basic Flow of Events

3.

Alternative Flows

3.1
3.2
3.3
3.4
3.5

4
4
4
4
5

4.

Error! Bookmark not defined.

Preconditions
4.1

5.

Validasi Username Gagal


Validasi Panitia Gagal
Save Indikator Keberhasilan Gagal
Upload Proposal Kegiatan Gagal
Pencetakan Tanda Bukti Gagal

Precondition One

Post Conditions

5.1

Post Condition One

6.

Special Requirements

7.

Additional Information

Confidential

FKUI, 2007

Page 3

SIPROKA FKUI
Use Case Specification : Mengajukan Proposal Kegiatan

Version:
1.1
Date: 05.01.2007

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
1. Memasukkan User Name dan Password
2. Memilih akan berperan sebagai panitia untuk
kegiatan yang mana

System

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
Confidential

FKUI, 2007

Page 4

SIPROKA FKUI
Use Case Specification : Mengajukan Proposal Kegiatan

Version:
1.1
Date: 05.01.2007

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

Confidential

FKUI, 2007

Page 5

Fakultas Kedokteran Universitas Indonesia

Sistem Informasi Pengelolaan Program Kerja dan


Anggaran FKUI
Use-Case Specification: Seleksi Proposal Tahap I

Version 1.1

Confidential

FKUI, 2007

Page 1

SIPROKA FKUI
Use Case Specification : Seleksi Proposal Tahap I

Date

Version

Version:
1.1
Date: 06.01.2007

Revision History
Description

Author

02.10.2006

0.9

Create First Use Specification

Nana Suryadigama

26.11.2006

1.0

Revisi minor pada alur use case

Isnanto Nugroho

06.01.2007

1.1

Revisi setelah presentasi

Isnanto Nugroho

Confidential

FKUI, 2007

Page 2

SIPROKA FKUI
Use Case Specification : Seleksi Proposal Tahap I

Version:
1.1
Date: 06.01.2007

Table of Contents
1.

Use Case Name

1.1
1.2

4
4

Use Case Name


Brief Description

2.

Basic Flow of Events

3.

Alternative Flows
3.1
3.2
3.3
3.4
3.5

4.

5.

4
Error! Bookmark not defined.

Review Rencana Anggaran


Download Proposal Rencana Anggaran Gagal
Validasi Gagal
Download Proposal Rencana Kegiatan Gagal
Menyimpan Komentar Gagal

4
5
5
5
5

Preconditions

4.1

Precondition One

Post Conditions

5.1

Post Condition One

6.

Special Requirements

7.

Additional Information

Confidential

FKUI, 2007

Page 3

SIPROKA FKUI
Use Case Specification : Seleksi Proposal Tahap I

Version:
1.1
Date: 06.01.2007

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
1. Memasukkan user name dan password

System
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. [UC2.3 Alternative Flows]


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
Confidential

FKUI, 2007

Page 4

SIPROKA FKUI
Use Case Specification : Seleksi Proposal Tahap I

Version:
1.1
Date: 06.01.2007

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

Confidential

FKUI, 2007

Page 5

Fakultas Kedokteran Universitas Indonesia

Sistem Informasi Pengelolaan Program Kerja dan


Anggaran FKUI
Use-Case Specification: Seleksi Tahap II
Version 1.1

Confidential

FKUI, 2007

Page 1

SIPROKA FKUI
Use Case Specification : Seleksi Proposal Tahap II

Date

Version

Version:
1.1
Date: 06.01.2007

Revision History
Description

Author

02.10.2006

0.9

Use-Case Seleksi Tahap II

Fajar

26.11.2006

1.0

Revisi minor pada alur use case

Isnanto Nugroho

06.01.2007

1.1

Revisi format alur use case setelah


presentasi

Isnanto Nugroho

Confidential

FKUI, 2007

Page 2

SIPROKA FKUI
Use Case Specification : Seleksi Proposal Tahap II

Version:
1.1
Date: 06.01.2007

Table of Contents
1.

Use Case Name

1.1
1.2

4
4

Use Case Name


Brief Description

2.

Basic Flow of Events

3.

Alternative Flows
3.1
3.2
3.3

4.

5.

4
Error! Bookmark not defined.

Validasi Gagal
Download Proposal Rencana Anggaran Gagal
Menyimpan Komentar Gagal

4
4
4

Preconditions

4.1

Precondition One

Post Conditions

5.1

Post Condition One

6.

Special Requirements

7.

Additional Information

Confidential

FKUI, 2007

Page 3

SIPROKA FKUI
Use Case Specification : Seleksi Proposal Tahap II

Version:
1.1
Date: 06.01.2007

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
1. Memasukkan user name dan password

System
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. [UC3.3 Alternative Flows]


3.1 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.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
3.3 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)

Confidential

FKUI, 2007

Page 4

SIPROKA FKUI
Use Case Specification : Seleksi Proposal Tahap II

Version:
1.1
Date: 06.01.2007

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.

6. Special Requirements
Tidak ada.

7. Additional Information
Tidak ada..

Confidential

FKUI, 2007

Page 5

Fakultas Kedokteran Universitas Indonesia

Sistem Informasi Program Kerja dan Anggaran FKUI

Use-Case Specification: Menilai Kecukupan LPJ Indikator


Keberhasilan
Version 1.1

Confidential

FKUI, 2007

Page 1

SIPROKA FKUI
Use Case Specification : Menilai Kecukupan LPJ Indikator Keberhasilan

Date

Version

Revision History
Description

Version:
1.1
Date: 06.01.2007

Author

02.10.2006

0.9

Dokumen awal

Isnanto Nugroho

26.11.2006

1.0

Revisi minor terhadap alur use case

Isnanto Nugroho

06.01.2007

1.1

Revisi format alur use case

Isnanto Nugroho

Confidential

FKUI, 2007

Page 2

SIPROKA FKUI
Use Case Specification : Menilai Kecukupan LPJ Indikator Keberhasilan

Version:
1.1
Date: 06.01.2007

Table of Contents
1.

Use Case Name

1.1
1.2

4
4

Use Case Name


Brief Description

2.

Basic Flow of Events

3.

Alternative Flows

3.1
3.2
3.3

4
4
4

4.

Error! Bookmark not defined.

Preconditions
4.1

5.

Validasi Gagal
Menampilkan Detail Kegiatan Gagal
Menyimpan Komentar Gagal

Precondition One

5
Error! Bookmark not defined.

Post Conditions
5.1

Post Condition One

6.

Special Requirements

7.

Additional Information

Confidential

FKUI, 2007

Page 3

SIPROKA FKUI
Use Case Specification : Menilai Kecukupan LPJ Indikator Keberhasilan

Version:
1.1
Date: 06.01.2007

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

2. Basic Flow of Events


[UC4.2 Basic Flow] ini akan dijelaskan dengan format dua kolom :
Aktor
1. Memasukkan user name dan password

System
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. [UC4.3 Alternative Flows]


3.1 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.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
3.3 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)

Confidential

FKUI, 2007

Page 4

SIPROKA FKUI
Use Case Specification : Menilai Kecukupan LPJ Indikator Keberhasilan

Version:
1.1
Date: 06.01.2007

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

6. Special Requirements
Tidak ada.

7. Additional Information
Tidak ada.

Confidential

FKUI, 2007

Page 5

Fakultas Kedokteran Universitas Indonesia

Sistem Informasi Pengelolaan Program Kerja dan


Keuangan FKUI

Use-Case Specification: Menyerahkan Laporan Pertanggungjawaban


Version 1.1

Confidential

FKUI, 2007

Page 1

SIPROKA FKUI
Use Case Specification : Menyerahkan Laporan Pertanggungjawaban

Date

Version

Revision History
Description

Version:
1.1
Date: 06.01.2007

Author

22.10.2006

0.9

Create First Use Specification

Nana Suryadigama

26.11.2006

1.0

Revisi minor pada alur use case

Isnanto Nugroho

06.01.2007

1.1

Revisi format alur use case

Isnanto Nugroho

Confidential

FKUI, 2007

Page 2

SIPROKA FKUI
Use Case Specification : Menyerahkan Laporan Pertanggungjawaban

Version:
1.1
Date: 06.01.2007

Table of Contents
1.

Use Case Name

1.1
1.2

4
4

Use Case Name


Brief Description

2.

Basic Flow of Events

3.

Alternative Flows
3.1
3.2
3.3
3.4
3.5

4.

4
Error! Bookmark not defined.

Validasi Username Gagal


Validasi Panitia Gagal
Save Pencapaian Indikator Keberhasilan Gagal
Upload LPJ Gagal
Pencetakan Tanda Bukti Gagal

Error! Bookmark not defined.

Preconditions
4.1

5
5
5
5
5

Precondition One

Post Conditions

Error! Bookmark not defined.

5.1

LPJ Tersimpan

Error! Bookmark not defined.

6.

Special Requirements

7.

Additional Information

5.

Confidential

FKUI, 2007

Page 3

SIPROKA FKUI
Use Case Specification : Menyerahkan Laporan Pertanggungjawaban

Version:
1.1
Date: 06.01.2007

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]

2. Basic Flow of Events


[UC5.2 Basic Flow] ini akan dijelaskan dengan format dua kolom :
Aktor
1. Memasukkan User Name dan Password
2. Memilih akan berperan sebagai panitia untuk
kegiatan yang mana

System

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

Confidential

FKUI, 2007

Page 4

SIPROKA FKUI
Use Case Specification : Menyerahkan Laporan Pertanggungjawaban

Version:
1.1
Date: 06.01.2007

3. [UC5.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 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

Confidential

FKUI, 2007

Page 5

Fakultas Kedokteran Universitas Indonesia

Sistem Informasi Pengelolaan Anggaran dan Program


Kerja FKUI
Supplementary Specification
Version 1.1

Confidential

FKUI, 2007

Page 1

SIPROKA FKUI
Supplementary Specification

Date

Version:
1.1
Date: 07.01.2007

Version

Revision History
Description

Author

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

Confidential

FKUI, 2007

Page 2

SIPROKA FKUI
Supplementary Specification

Version:
1.1
Date: 07.01.2007

Table of Contents
1.

2.

Introduction

1.1
1.2
1.3
1.4

4
4
4
4

Usability
2.1
2.2

3.

4.

5.

6.

Purpose
Scope
Definitions, Acronyms and Abbreviations
Overview

Mudah Dipelajari dan Digunakan


Menggunakan Bahasa Indonesia yang baku

Error! Bookmark not defined.


Error! Bookmark not defined.

Reliability

3.1

Sistem Availability

Performance

4.1
4.2
4.3

4
5
5

Response Time
Processing Time
Kapasitas

Supportability

5.1

Coding Standard

Design Constraints

6.1
6.2
6.3
6.4

5
5
5
5

Bahasa Pemrograman
Sistem Operasi
Spreadsheet Anggaran
Database

7.

Online User Documentation and Help System Requirements

8.

Purchased Components

9.

Interfaces

9.1
9.2
9.3

6
6
6

User Interfaces
Software Interfaces
Communications Interfaces

10.

Licensing Requirements

11.

Legal, Copyright and Other Notices

Confidential

FKUI, 2007

Page 3

SIPROKA FKUI
Supplementary Specification

Version:
1.1
Date: 07.01.2007

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

Confidential

FKUI, 2007

Page 4

SIPROKA FKUI
Supplementary Specification

Version:
1.1
Date: 07.01.2007

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
terdokumentasikan sehingga memudahkan maintanance atau pengembangan selanjutnya.

tertentu

yang

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
Confidential

FKUI, 2007

Page 5

SIPROKA FKUI
Supplementary Specification

Version:
1.1
Date: 07.01.2007

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.

Confidential

FKUI, 2007

Page 6

SIPROKA FKUI
Supplementary Specification

Confidential

Version:
1.1
Date: 07.01.2007

FKUI, 2007

Page 7

Fakultas Kedokteran Universitas Indonesia

Sistem Informasi Pengelolaan Program Kerja dan


Anggaran FKUI
Glossary
Version 1.1

Confidential

FKUI, 2007

Page 1

SIPROKA FKUI
Glossary

Date

Version:
1.1
Date: 07.01.2007

Version

Revision History
Description

Author

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

Confidential

FKUI, 2007

Page 2

SIPROKA FKUI
Glossary

Version:
1.1
Date: 07.01.2007

Table of Contents
1.

2.

Introduction

1.1
1.2

4
4

Purpose
Scope

Definitions

Confidential

FKUI, 2007

Page 3

SIPROKA FKUI
Glossary

Version:
1.1
Date: 07.01.2007

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.

Confidential

FKUI, 2007

Page 4

SIPROKA FKUI
Glossary

Confidential

Version:
1.1
Date: 07.01.2007

FKUI, 2007

Page 5

FEAT : All Features

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


Requirement Type : Feature Requirement Type

Printed by: NANA

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

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

High

Page: 1

NEED : All Need

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


Requoirement Type : Need Requirement Type

Printed by: NANA

Priority
NEED1... Database Proposal yang terintegrasi

NEED2... Proses Administrasi Pengajuan roposal


yang Efisien

Origin

Current Solution

High

Stakeholder

Pelaporan dengan
hardcopy

Intranet Webbased application

High

Stakeholder

Pelaporan dengan
hardcopy

Intranet Webbased application

High

Stakeholder

Pelaporan dengan
hardcopy

Intranet Webbased application

High

Analysis

Pelaporan dengan
hardcopy

Intranet Webbased application

NEED3.. Sistem monitoring realisasi kegiatan

NEED4 .. Proses Administrasi Penilaian LPJ yang


Efisien

Printed on : 08/01/2007 @ 11:03:18 AM

Proposed Solution

Page: 1

STRQ : All Stakeholder

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


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
STRQ 5.. Sistem pelaporan guna kepentingan audit

High

Approved

High

High

High

Approved

High

High

Printed on : 08/01/2007 @ 11:10:07 AM

Page: 1

SUPP : All Supplementary

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


Requirement Tupe : Supplementary Requirement Type

Printed by: ISNANTO

Priority
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

Status

Difficulty

Stability

Risk

High

Proposed

Medium

Medium

Low

Medium

Proposed

Medium

Medium

Low

High

Proposed

Medium

High

High

Medium

Proposed

Medium

High

High

time < 10s.


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

Proposed

Medium

Medium

High

Proposed

Medium

Medium

SUPP9 Sistem server dijalankan di sistem


operasi berbasis windows 2000

High

Proposed

Medium

High

SUPP10 sistem menggunakan spreadsheet


yang kompatibel dengan MS.Excel

Medium

Proposed

Medium

High

High

Proposed

Medium

High

High

Proposed

Medium

High

High

Proposed

Medium

High

High

Proposed

Medium

High

Medium

Proposed

Medium

Medium

Medium

Proposed

Medium

Medium

respone

SUPP7 Coding Standard


SUPP8 Bahasa Pemrograman Open Source

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

Medium
Medium
Medium
Medium

High
High
High

High

Medium

Medium

Medium

lambat 6 bulan ( Juli 2007)

Printed on : 08/01/2007 @ 11:15:32 AM

Page: 1

SUPP : All Supplementary

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


Requirement Tupe : Use Case Requirement Type

Printed by: ISNANTO

Priority
UC1 : Mengajukan Proposal Kegiatan
UC2 : Seleksi Proposal Tahap I
UC3 : Seleksi Proposal Tahap II
UC4 : Menilai Kecukupan LPJ Indikator
Keberhasilan
UC5 : Menyerahkan Laporan
Pertanggungjawaban
UC6 : Melihat informasi proposal kegiatan
UC7 : Menyetujui Proposal
UC8 : Menilai Kecukupan LPJ Keuangan
UC9 : Merekapitulasi Realisasi Anggaran
UC10 : Mengevaluasi Kinerja Keuangan

Printed on : 08/01/2007 @ 11:16:35 AM

Status

Difficulty

Risk

High

Proposed

Medium

Low

Medium

Proposed

Medium

Low

High

Proposed

Medium

High

Medium

Proposed

Medium

High

High

Proposed

Medium

High

High

Proposed

Medium

Medium

Proposed

Medium

High

Proposed

Medium

High

Proposed

Medium

Medium

Proposed

Medium

Medium
Medium
Medium
Medium

High

Page: 1

STRQ-NEED: STRQ to NEED

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


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

Printed on : 08/01/2007 @ 11:19:25 AM

Page: 1

NEED-FEAT : NEED to Features

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

Need to Features

Printed by: ARIA

FEAT 1..
Entry
Data
Proposal

FEAT 2..
Laporan
Rekapitulas
i Status
Proposal

FEAT 3..
Sistem
pendukung
proses
seleksi
proposal

FEAT 4..
Entry Data
LPJ

FEAT 5..
Pendukung
Proses
Penilaian
LPJ

FEAT6 ..
Rekapitulas
i 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

Printed on : 08/01/2007 @ 11:33:44 AM

Page: 1

UC-FEAT : Use Case to Features

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


Use Case to Features

Printed by : NANA

FEAT 1..
Entry
Data
Proposal

FEAT 2..
Laporan
Rekapitul
asi
Status
Proposal

FEAT 3..
Sistem
pendukung
proses
seleksi
proposal

FEAT 4..
Entry Data
LPJ

FEAT 5..
Pendukung
Proses
Penilaian
LPJ

FEAT6 ..
Rekapitulasi
Informasi
Kegiatan

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

Printed on : 08/01/2007 @ 11:36:47 AM

Page: 1

UC-FEAT : Use Case to Supplementary

Project Name : SIPROKA FKUI [Revision: 1.1000, Version Label


Use Case to Supplementary

Printed by: NANA

FEAT 1..
Entry
Data
Proposal

FEAT 2..
Laporan
Rekapitulas
i Status
Proposal

FEAT 3..
Sistem
pendukung
proses
seleksi
proposal

FEAT 4..
Entry Data
LPJ

FEAT 5..
Pendukung
Proses
Penilaian
LPJ

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.

Printed on : 08/01/2007 @ 11:40:17 AM

Page: 1

FEAT6 ..
Rekapitulas
i Informasi
Kegiatan

Project Name : SIPROKA FKUI [Revision: 1.1000, Version Label


Use Case to Supplementary

UC-FEAT : 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)

Printed on : 08/01/2007 @ 11:40:17 AM

Page: 12
Page