2 Requirements Management Plan

Requirements Management Plan
Version 0.8
Confidential © 2000 The Great Idea 1

Project Name: Sistem Informasi Puskesmas Version: 0.8 Author:
Requirements Management Plan Creation Date: 1-Des-2018
File: 416867029.doc Published Date:
Revision History
Date Version Description Author
21-Feb-2000 0.1 Initial Session Feedback Applied Stephen Smart (sls)
(Rational Software)
26-Feb-2000 0.2 Follow-up interview feedback applied sls
7-Mar-2000 0.3 Added Issues, Assumptions, Biz Rules, and initial trace sls
model
9-Mar-2000 0.4 First crack at all requirement attributes sls
17-Mar-2000 0.5 Revised requirement attributes sls
22-Mar-2000 0.6 Added Design Requirements and extension list. sls
24-Mar-2000 0.7 First Draft Proof sls
26-Mar-2000 0.8 Revisions from internal review sls

Table of Contents
1. INTRODUCTION 5
1.1 PURPOSE 5
1.2 SCOPE 5
1.3 COLLABORATORS 5
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS 5
1.5 REFERENCES 7
1.6 OVERVIEW 8
2. REQUIREMENT ARTIFACTS AND REQUIREMENT TYPES 9
Table 2-1 Document based Requirement Artifacts and Types 9
Table 2-2 Database Only Requirement Types 10
3. REQUIREMENT ATTRIBUTES 11
3.1 REQUIREMENT ATTRIBUTES FOR IMPACTED GROUP(IG) 11
3.2 REQUIREMENT ATTRIBUTES FOR STAKEHOLDER(STK) 11
3.3 REQUIREMENT ATTRIBUTES FOR STAKEHOLDER NEED(NEED) 11
3.4 REQUIREMENT ATTRIBUTES FOR FEATURE(FEAT) 11
Table 3-1 Status attribute values for FEAT requirement type. 12
Table 3-2 Benefit attribute values for FEAT requirement type. 12
Figure 3-2 Percent engineering hours by phase. [2] 13
Table 3-3 Coordination Complexity attribute values for FEAT requirement type. 14
Table 3-4 Architectual Impact attribut values for FEAT requirement type. 14
Table 3-5 Development Risk Scoping Matrix. [2] 15
Table 3-6 Stability attribute values for FEAT requirement type. 15
Table 3-7 Business Process Impact values for FEAT requirement type. 15
3.5 REQUIREMENT ATTRIBUTES FOR ACTOR(ACTOR) 16
3.6 REQUIREMENT ATTRIBUTES FOR USE-CASE(UC) 16
3.7 REQUIREMENT ATTRIBUTES FOR USE-CASE DETAIL(UCDR) 16
Table 3-8 Location attribute values for UCDR requirement type. 16
Table 3-9 Stability attribute values for UCDR requirement type. 17
3.8 REQUIREMENT ATTRIBUTES FOR SUPPLEMENTAL(SUPP) 18
Table 3-10 Stability attribute values for SUPP requirement type. 18
3.9 REQUIREMENT ATTRIBUTES FOR DESIGN(DE) 19
Table 3-11 Type attribute values for DE requirement type. 19
Table 3-12 Status attribute values for DE requirement type 19
3.10 REQUIREMENT ATTRIBUTES FOR TEST PLAN(TPR) 20
Table 3-13 Status attribute values for TPR requirement type. 20
3.11 REQUIREMENT ATTRIBUTES FOR TEST(TR) 20
Table 3-14 Status attribute values for TR requirement type. 21
3.12 REQUIREMENT ATTRIBUTES FOR ISSUE(ISS) 21
Table 3-15 Status attribute values for ISS requirement type. 21
3.13 REQUIREMENT ATTRIBUTES FOR ASSUMPTION(ASM) 21
Table 3-16 Status attribute values for ASM requirement type. 21
3.14 REQUIREMENT ATTRIBUTES FOR TERM(TERM) 21
Table 3-17 Status attribute values for TERM requirement type. 22
3.15 REQUIREMENT ATTRIBUTES FOR BUSINESS RULE(BR) 22
Table 3-18 Status attribute values for BR requirement type. 22
4. TRACABILITY CRITERIA 23
FIGURE 4-1 REQUIREMENTS TRACABILITY DIAGRAM 23
4.1 CRITERIA FOR IMPACTED GROUP 24

4.2 CRITERIA FOR STAKEHOLDER 24
4.3 CRITERIA FOR STAKEHOLDER NEED REQUIREMENTS 24
4.4 CRITERIA FOR PRODUCT FEATURE REQUIREMENTS 24
4.5 CRITERIA FOR USE-CASE REQUIREMENTS 24
4.6 CRITERIA FOR ACTOR REQUIREMENTS 24
4.7 CRITERIA FOR USE-CASE DETAIL REQUIREMENTS 25
4.8 CRITERIA FOR SUPPLEMENTAL REQUIREMENTS 25
4.9 CRITERIA FOR DESIGN ELEMENT REQUIREMENTS 25
4.10 CRITERIA FOR TEST PLAN REQUIREMENTS 25
4.11 CRITERIA FOR TEST REQUIREMENTS 25
4.12 CRITERIA FOR ISSUE REQUIREMENTS 25
4.13 CRITERIA FOR GLOSSARY REQUIREMENTS 25
4.14 CRITERIA FOR ASSUMPTION REQUIREMENTS 25
4.15 CRITERIA FOR BUSINESS RULE REQUIREMENTS 26
4.16 CRITERIA FOR SUPPORTING DOCUMENT REQUIREMENTS 26
5. RATIONAL REQUISITEPRO VIEWS 26
5.1 SCOPING VIEW, SEE TARGET RELEASE IN 3.4 26
6. RATIONAL REQUISITEPRO EXTENSIONS 26
6.1 CALCULATE FEATURE DEPENDENCY COUNT 26
6.2 CALCULATE REQUIREMENT LEVEL COUNTER 26
6.3 CALCULATE TECHNOLOGY RISK 26
6.4 TRACE CHECK THE REQUIREMENTS 26
6.5 DO A PARETO CHECK ON STAKEHOLDER NEEDS 26
6.6 CREATE SODA DOCUMENT FOR UCMS 26
APPENDIX 1: TECHNOLOGY RISK ASSESSMENT 27
Appendix 2: Tracability Diagramming Notation 28

Requirements Management Plan

1. Introduction
1.1 Purpose
Seiring perkembangan zaman yang menuju era teknologi informasi dimana semua dituntut untuk cepat,
akurat, dan efisien sehingga dalam proses bisnis pun mengikuti perkembangan era teknologi informasi,
dalam hal ini penerapan sistem informasi berdasarkan teknologi informasi untuk penggunaan di
Puskesmas. Sebagai pioneer dalam bidang kesehatan terutama didaerah, peran Puskesmas sangatlah vital
untuk menunjang kesehatan masyarakat Indonesia karena hak kesehatan telah diatur dalam UUD 1945.
Penggunaan sistem informasi yang tepat dapat meningkatkan kinerja Puskesmas, mengoptimalisasi
sumber daya yang dimiliki Puskesmas, dan masih banyak keuntungan lain yang bisa didapatkan dengan
menerapkan sistem informasi di Puskesmas. Maka dari itu kami menawarkan implementasi Sistem
Informasi Administrasi Puskesmas yang terdiri dari Sistem informasi Pasien, Sistem Rekam Medis, dan
Sistem Informasi Dokter dan Perawat yang ditujukan untuk mempermudah pelayanan Puskesmas dan
meningkatkan kualitas pelayanan Puskesmas di masa mendatang.
1.2 Scope
Cakupan dari permasalahan ini adalah kurangnya penggunaan teknologi dibidang kesehatan utamanya
pada penyelenggara kesehatan di daerah terpencil yang umumnya dikenal sebagai Puskesmas dalam hal
ini beberapa permasalahan atau kendala yang akan diselesaikan dengan sistem informasi antara lain:
a. Sistem Administrasi
b. Sistem Pendataan Pasien
c. Rekam Medis
d. Pendataan Pemberian Obat.
1.3 Collaborators
 Nurul Eka Lestari
 Annisa Dwi Andiani
 Rifqi Taufiqurrohman
 Rere Gilang Nuri Auladi
1.4 Definitions, Acronyms and Abbreviations
 DataBase / Server : Sebuah perangkat komputer yang berfungsi menyimpan data dan
mengolah informasi yang disimpan didalam server untuk dapat dijadikan informasi yang
berguna untuk perusahaan.
 Personal Computer : Komputer yang akan digunakan dokter dan petugas administrasi
untuk mempermudah input data pasien, diagnosa pasien, dan mengelola administrasi
puskesmas.
 Local Area Network (LAN) : Sebuah jaringan yang bersifat lokal yang akan digunakan
untuk komunikasi antar PC dan Server agar bisa bekerja dengan optimal.
 Internet : Koneksi atau penghubung Antar Puskesmas yang sudah terintegrasi dengan
sistem, dapat juga menjadi penghubung antara pasien dan Puskesmas yang sudah memiliki
sistem informasi modern.
 Rekam Medik : Dokumen mengenai kesehatan pasien yang berobat, terdiri dari hasil
diagnosa, penanganan, dan obat yang diberikan.
 Back-up : Proses pengamanan data dengan cara memindahkan data dari sebuah media ke media
lain.

1.5 References
Applicable references are:
1. https://eclass.uop.gr/modules/document/file.php/CST255/feasibility-study-template.doc
2. https://arali2008.wordpress.com/berkunjung-ke-polewali-mandar/sistem-dan-sub-sistem-
puskesmas/
3. http://dinus.ac.id/repository/docs/ajar/JURNAL_KELAYAKAN_SI.pdf.
1.6 Overview
Pada zaman modern sekarang ini segala proses bisa dipermudah dengan menggunakan teknologi.
Namun permasalahannya disini adalah kurangnya penggunaan teknologi dan sistem informasi dibidang
kesehatan utamanya pada penyelenggara kesehatan di daerah terpencil yang umumnya dikenal sebagai
Puskesmas. Yang sebetulnya dalam sistem Puskesmas itu bisa dipermudah dengan menggunakan
teknologi dan sistem informasi yang ada saat ini, mulai dari sistem administrasi, sistem pendataan
pasien, rekam medis serta pendataan pemberian obat.
Overview systemnya adalah sebagai berikut :
Nama Project : Sistem Informasi Puskesmas
Kategori : Aplikasi Baru (major aplication), Transction Process System
System Code : Java
Fungsi Umum : Menyediakan Aplikasi Untuk Kebutuhan Administrasi
Fungsi Spesifik : Menyediakan layanan Registrasi
Menyediakan Layanan Rekam Medik Pasien
Menyediakan Layanan Administrasi Pelayanan
Mempercepat Alur Bisnis Puskesmas
Status Operasional : Pengembangan


2. Requirement Artifacts and Requirement Types
ARTIFACT REQ. TYPE DESCRIPTION

Vision (VIS) Stakeholder Masalah yang memungkinkan untuk membebankan pembelian atau
Need penggunaan. Juga dikenal sebagai tujuan atau sasaran. Disediakan oleh
(NEED) Stakeholder.
Product Ini adalah jenis persyaratan standar untuk Dokumen Visi. Kondisi atau
Feature kemampuan sistem. Beberapa Fitur Produk mungkin keluar dari Baseline
(FEAT) untuk rilis khusus dari sistem.
Glossary Term Glosarium mendefiniskan Istilah-istilah penting di dalam proyek. Dimiliki dan
(GLS) (TERM) ditulis oleh Analis Sistem. Konten disediakan oleh Stakeholder dan TGI IT.
Business Rule Business Menentukan kebenaran bisnis atau data bisnis yang dalam domain masalah.
Reference(BR) Rule (BR) Dimiliki dan ditulis oleh Analis Sistem. Konten yang disediakan oleh
Stakeholder.
Use-Case Laporan Rasional SoDAÒ Generated memberikan informasi tingkat tinggi dari
Model Survey semua Use-Kasus dan Pelaku untuk rilis ini dilakukan di Rational RoseÒ.
Use-Case Use-Case Persyaratan rinci perorangan yang tepat dalam penggunaan spesifikasi kasus.
Specification Detail Ini juga disebut sebagai persyaratan perangkat lunak. Dimiliki dan ditulis oleh
(UC) Requirement Analis Sistem. Konten yang disediakan oleh Stakeholder.
(UCDR)
Supplementary Supplementar Spesifikasi Tambahan biaya yang digunakan dalam kasus penggunaan kasus.
Specification y Seperti itu persyaratan meliputi: persyaratan hukum dan peraturan dan standar
(SS) Requirement aplikasi; atribut kualitas dari sistem yang akan dibangun, termasuk kegunaan,
(SUPP) persyaratan menyeluruh, kinerja dan berbagai; Menyesuaikan dan
menggunakan desain, Analis Sistem. Konten yang disediakan oleh
Stakeholder.
Test Test Plan Rencana Uji memuat informasi tentang tujuan dan sasaran dalam proyek,
Plan(TPL) Requirement mengidentifikasi strategi yang akan digunakan untuk mengimplementasikan,
dan menetapkan biaya tinggi khusus, dan sumber daya yang diperlukan.
(TPR)
Memiliki Rencana Uji (TPR) sendiri dan ditulis oleh Perancang Tes. Minimal,
setiap Use-Case harus mendapatkan satu TPR. Daftar TPR yang lebih detail
akan menghasilkan satu TPR untuk setiap alur kejadian Use-Case.
Test Case(TC) Test Test Case adalah seperangkat masukan uji, kondisi pelaksanaan, dan hasil yang
Requirement diharapkan untuk tujuan tertentu, seperti untuk menjalankan program jalur
tertentu atau untuk verifikasi dengan persyaratan tertentu. Test Case
(TR)
mengimplementasikan seluruh atau sebagian dari Persyaratan Rencana
Pengujian. A Test Requirement (TR) mengidentifikasi titik dalam test case di
mana status status Sistem Di Bawah Uji diperlukan.
Issues(ISU) Issue(ISS) Masalah yang sedang diperdebatkan antara dua pihak dan lebih, jika tidak
dapat menghasilkan kualitas yang lebih baik atau slip jadwal. Ditulis oleh siapa
pun di tim proyek.
Assumptions Assumption Fakta atau pernyataan yang diterima begitu saja. Ditulis oleh siapa pun di tim
pengembangan. Harus dikeluarkan oleh Manajer Sistem Bisnis dan tim
(ASM) (ASM)
pengembangan.
Table Requirement Artifacts and Requirement Types-1 Document based Requirement Artifacts and Types

REQUIREMENT TYPE DESCRIPTION

Impacted Group(IG) Grup, area, atau divisi yang dapat memberikan layanan TI TGI atau dapat diubah
oleh satu atau beberapa sistem yang dikembangkan oleh TI TGI (mis. Pemasaran,
Rekanan Penjualan, Hukum, TI, Hutang Akun). Dimiliki dan ditulis oleh Analis
Sistem.
Stakeholder(STK) Nama pengguna individu. Dimiliki dan ditulis oleh Analis Sistem.
Actor(ACTOR) Seseorang atau sesuatu, diluar sistem yang berinteraksi dengan sistem.
Design Element(DE) Ini adalah komponen-komponen yang sedang dibangun, kadang-kadang sampai ke
tingkat. Dimiliki dan dibuat oleh Arsitek, Desainer atau Pelaksana.
Use-Case (UC) Referensi tingkat tinggi pada usecase.
Table Requirement Artifacts and Requirement Types-2 Database Only Requirement Types

3. Requirement Attributes
3.1 Requirement Attributes for Impacted Group(IG)
Pasien
Dampak dari adanya sistem informasi ini dari sisi pasien adalah kemudahan dalam pendaftaran untuk
mendapatkan pelayanan kesehatan dengan menggunakan aplikasi, melihat histori penyakit dan juga untuk melihat
resep yang telah diberikan maupun histori resep terdahulu yang pernah diberikan. Namun ada sedikit kendala
dalam penyuluhan dalam penggunaan sistem informasi puskesmas yaitu diperlukannya sosialisasi dan juga tidak
semua pasien mengerti mengenai penggunaan aplikasi terutama pasien yang berdomisili di daerah yang jauh dari
kawasan yang ramah dengan teknologi. Selain permasalahan dengan interaksi pasien dengan aplikasi,
Dokter dan Perawat

Penerapan sistem informasi puskesmas yang salah satunya akan berdampak pada kerja dokter dalam pencatatan
rekam medis yang tidak lagi menggunakan kertas sebagai media pencatatannya sehingga perlu adaptasi ataupun
pelatihan terhadap penggunaan perangkat komputer.
Administrasi
Penerapan teknologi informasi dalam sistem informasi puskesmas akan mempermudah dalam pendataan
administratif pasien ataupun dokter sehingga mempermudah pekerjaan dasar karyawan bagian administrasi. Di
satu sisi dapat memungkinkan untuk mengurangi karyawan bagian administrasi untuk penghematan anggaran
Pemerintah
Pemerintah sebagai stakeholder dalam penyelenggaraan fasilitas kesehatan masyarakat nantinya akan memiliki
cara baru guna menilai kinerja sebuah puskesmas yang dikelolanya melalui sistem informasi, juga secara keuangan
dapat dimonitoring melalui sistem informasi yang nantinya pemerintah akan ikut berada didalamnya guna
mengawasi kinerja. Dampak lainnya adalah adanya beban anggaran guna perawatan dan penyediaan fasilitas dan
sarana prasarana teknologi informasi terkait.
Supplier Alat Tulis Kantor

Dengan digunakannya komputerisasi dalam segi administrasi maka penggunaan alat tulis kantor (ATK) akan
berkurang dalam jumlah yang signifikan sehingga berkurang juga cost untuk pembelian ATK tersebut.
Karyawan non medik

Dengan diterapkannya sistem informasi puskesmas berbasis teknologi informasi maka nantinya pasti ada
perubahan dari business rule.
.
3.2 Requirement Attributes for Stakeholder(STK)

Beberapa pihak yang terlibat dalam proses bisnis Puskesmas antara lain
a. Kementrian Kesehatan
b. Pemerintah Daerah
c. Puskesmas Terkait

d. Internet Service Provider (ISP)

3.3 Requirement Attributes for Stakeholder Need(NEED)
Problem Analyzed
Permasalahan dari puskesmas saat ini adalah Puskesmas menjadi salah satu ujung tombak pemerintah
dalam pemerataan fasilitas kesehatan di indonesia, dalam hal ini berarti puskesmas berada di pelosok dan
terluar dari perkotaan, maka kemajuan atau perkembangan puskesmas dapat dikatakan kurang. Salah satu
hal yang menjadi tolak ukur adalah penggunaan teknologi informasi dalam proses bisnis yang digunakan
untuk mempermudah dan menjadikan proses bisnis lebih efisien seperti dalam menjalankan proses bisnis,
disini berupa pelayanan medis yang membutuhkan administrasi yang diselenggarakan secara
komputerisasi.
Contribution
Dalam penerapan sistem informasi ini diharapkan dapat memenuhi ekspektasi pengguna dan stakeholder
dalam implementasi sistem administrasi yang terkomputerisasi sehingga dapat memenuhi 25 % proses
bisnis dari puskesmas secara umum.
3.4 Requirement Attributes for Feature(FEAT)

Requirement Text is the feature description.
Status
Proposed Sistem informasi ini sudah melewati tahapan rancangan dan saat ini sedang
dalam tahap pengajuan ke Departemen Kesehatan.
Table Requirement Attributes-3 Status attribute values for FEAT requirement type.
Benefit
Useful Penerapan sistem informasi ini menjadi suplemen guna meningkatkan efektifitas
dan efisiensi dalam proses bisnis Puskesmas..
Table Requirement Attributes-4 Benefit attribute values for FEAT requirement type.

Effort
No Perencanaan Pembangunan Sistem Effort
1 Koordinasi dengan Stakeholder 10 %
2. Perancangan Sistem 25 %
3. Pembangunan Aplikasi 20 %
4. Perancangan Jaringan untuk Sistem Secara 15 %

Keseluruhan
5. Perancangan GUI 15 %
6 Sosialisasi Tentang Sistem 10 %
7 Finalisasi 5%
Total 100%

Coordination Complexity
Karyawan Koordinasi diperlukan sebagai salah satu bentuk pelatihan kepada karyawan agar
Internal dapat berkontribusi baik.
Pemda Koordinasi dengan pemerintah daerah sebagai stakeholder sangat diperlukan
Kemenkes
Vendor ISP Koordinasi dengan vendor ISP dibutuhkan dalam pembangunan jaringan yang
akan dibangun, pada implementasinya pihak ISP akan bertugas untuk membangun
jaringan ke beberapa puskesmas di daerah.
Table Requirement Attributes-5 Coordination Complexity attribute values for FEAT requirement
type.
Technology Risk
Dalam pembangunan sistem secara keseluruhan, tingkat kerumitan berada di kisaran 75 %, angka
tersebut diakibatkan penerapan sistem yang jauh dari perkotaan sehingga menimbulkan kesulitan dalam
penerapan sistem informasi.

Target Release
Proyeksi kami, angka waktu keseluruhan untuk pengerjaan membutuhkan 8 bulan sampai
aplikasi dapat berjalan dan memasuki versi alpha, kami akan memulai menggunakan aplikasi dalam skala
kecil dan menguji coba sistem secara langsung dengan melibatkan pihak puskesmas, pemda, kemenkes,
dan pihak kami selama 1 bulan lalu akan dievaluasi guna mencari kelemahan sistem secara aktual dan
mempersiapkan untuk naik menjadi versi beta. Setelah mendapatkan bahan evaluasi maka selanjutnya
adalah memperbaiki sistem dan penyesuaian dengan hasil evaluasi yang ada, proses ini memakan waktu 1
bulan.
Kemudian kami akan merilis versi beta yang masih tahap uji coba namun sudah melibatkan
beberapa pengguna seperti dokter, perawat, dan pasien sehingga kami dapat mendapatkan masukan dari
pengguna secara langsung, ketika masa beta berakhir selama satu bulan maka selanjutnya adalah
penyempurnaan dari versi alpa dan beta untuk dimodifikasi guna memenuhi kebutuhan secara pengguna
dari hasil uji coba langsung. Terakhir adalah rilis versi 0 yang dimana semua sistem sudah berjalan dan
akan digunakan selama tidak ada keperluan mendesak mengenai pembaharuan sistem.
No Versi Target Rilis
1 Alpa 9 bulan pasca kontrak
2 Beta 12 bulan pasca kontrak
3 Release Candidate 13 Bulan pasca kontrak
4 Stable Versi 0 14 bulan pasca kontrak
Impact to Business Process

Low Penerapan sistem informasi tidak akan mengubah banyak dalam proses bisnis,.
Table Requirement Attributes-6 Business Process Impact values for FEAT requirement type.
3.5 Requirement Attributes for Actor(ACTOR)
Brief Description
Di dalam sistem informasi puskesmas ini mencatat semua kegiatan operasional puskesmas yang bersifat
operasional medis. Meliputi proses pendaftaran pasien, tindakan medis, dan sebagainya yang nantinya
akan tercatat secara elektronik pada database. Dengan beberapa perubahan yang terjadi pada system ini
membuat pelayanan kepada pasien atau masyarakat menjadi lebih baik lagi. Pasien dapat berobat dengan
nyaman dan enak. Dan dengan ada penambahan di sistemnya membuat petugas lebih mudah melakukan
tugasnya dipuskemas.
3.6 Requirement Attributes for Use-Case(UC)

1. Perawat
2. Dokter
3. Petugas Administrasi
4. Apoteker.

3.7 Requirement Attributes for Use-Case Detail(UCDR)
3.8 Requirement Attributes for Supplemental(SUPP)

Perawat
Didalam system ini, tugas atau kerja perawat semakin dipermudah dengan adanya penambahan system
informasi dipuskesmas ini. Contohnya dalam hal mendata pasien tidak perlu manual lagi, pembuatan
laporan juga mempermudah perawat.
Dokter
Seperti umumnya dokter, dia melayani pasien yang akan berobat ke puskesmas tersebut. Bedanya adalah
dengan adanya penambahan system informasi di puskesmas dokter dapat melihat jejak atau rekam medis
setiap pasien yang pernah berobat ke puskesmas tersebut dan banyak lagi.
Apoteker
Apoteker disistem informasi ini tidak begitu berdampak karena tergolong sederhana. Karena hanya
menerima resep dari dokter dan memberikan obatnya ke pasien. Jadi hamper tidak menyentuh system
informasi yang kita tambahkan dipuskesmas tersebut.
Petugas Administrasi
Administrasi merupakan yang paling berdampak pada system informasi ini. Mengapa paling berdampak ,
karena penambahan system informasi ini mempermudah petugas seperti registrasi pasien untuk berobat
ke puskesmas ,sebelumnya secara manual setelah ada penambahan jadi mempermudah petugas
melakukan kerjanya.

3.9 Requirement Attributes for Design(DE)

Kebutuhan perangkat keras untuk digunakan di ruang pemeriksaaan:
1. Processor type Intel (R) Core i3

2. Memory 4Gb DDR4 / (2x2 DIMMs)
3. Hard drive type 500GB Serial ATA (7200 RPm)
4. Monitor 17”
5. Keyboard USB Keyboard
6. Mouse USB Optical Mouse
7. Motherboard B250m
Kebutuhan perangkat keras untuk digunakan oleh server:
1. Server Rack
2. Minumim Processor server 8 Thread/4 Core 3.0 GHz (64 bit)
3. RAM Minimum 16 GB, DDR 4
4. Harddisk 20 TB
5. Operating System (64 bit): Windows ServerDebian 8.0
6. LAN CARD (NIC)
7. UPS
3.10 Requirement Attributes for Test Plan(TPR)
3.11 Requirement Attributes for Test(TR)
3.12 Requirement Attributes for Issue(ISS)
3.13 Requirement Attributes for Assumption(ASM)
3.14 Requirement Attributes for Term(TERM)

3.15 Requirement Attributes for Business Rule(BR)
Perawat
Tidak ada Batasan, akses hamper sama dengan dokter. Bedanya perawat membuat laporan pasien kepada
dokter. Dan perawat tidak dapat memberikan resep obat kepada pasien. Hanya seorang dokter yang berhak
memberikan resep obat kepada pasien.
Dokter
Tidak ada Batasan akses terhadap dokter. Dokter dapat melihat rekam medis pasien, data pasien,
membuat atau memberikan resep kepada pasien dan apoteker.
Apoteker
Apoteker memiliki beberapa Batasan. Seperti tidak dapat melihat data pasien, rekam medis pasien, dan
tidak membuat laporan. Apoteker hanya memberikan obat kepada pasien berdasarkan pemberian resep
dari dokter.
Petugas Administrasi
Petugas administrasi memiliki batas untuk mengakses system informasi. Yaitu seperti melihat data rekam
medis, dan pemberian resep. Petugas administrasi hanya melayani pasien dalam hal registrasi, dan
merekap data pasien yang akan berobat dipuskesmas.

Appendix 1: Technology Risk Assessment
Risk Factor Weight

1. Which hardware, needed for the feature, is new to the comapany? X5
None 0
CPU High 3
Peripheral and/or additional storage High 3
Terminals High 3
Mini/Micro/CU High 3
2. Is the system software (non-operating system) new to the IT project team? X5
No 0
Programming Language High 3
Database High 3
Data communications High 3
Other High 3
3. How knowledgeable is the primary Stakeholder(s) in the proposed application area? X5
Limited High 3
Understands concept but has no experience Medium 2
Has been involved in prior implementation efforts Low 1
4. How knowledgeable is IT team in proposed application area? X5
Limited High 3
Understands concept but has no experience Medium 2
Has been involved in prior implementation efforts Low 1
Total 10-
150
Table A-1 Technology Risk Assessment. [5]
Answer the questions for each feature, multiply the weight by the weight factor, in table A-1 the weight factor for
all questions is five. Then total the weighted answers for the Technical Risk. Range 10-150. The Solution Center
may want to revise this assessment with experience.

Appendix 2: Tracability Diagramming Notation
Classes are used to

Tracability Typ e Nam e represent the
Traceability Types
Uni-directio nal relations hips

between two Tracability
Types are us ed to repres ent
TraceTy pe1
a trac-to relations hip ( in this
cas e TraceType1s can be
traced to TraceType2 s .
Trace Type2
Recursive aggregations are
us ed to show hierarchical
TraceTy pe3 relationships between
Traceability Types. Role
names are us ed to clarify the
+children nature of the parent / child
relationship.
Recurs ive non-agg regate

TraceTy pe4 relations hips are us ed to s how
navigable relations hips
between s im ilar Tracability
Types .
All traces have a multiplic ity of 1 to 0..* unless otherwise

annotated.
Figure A2- Appendix 2: Tracability Diagramming Notation-1 Tracability Diagramming Notations [6]

TODO
Verify all references are present and referenced.

2 Requirements Management Plan

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

2 Requirements Management Plan

Caricato da

Copyright:

Formati disponibili

Requirements Management Plan

Confidential © 2000 The Great Idea 1

Confidential © 2000 The Great Idea 2

4.1 CRITERIA FOR IMPACTED GROUP 24

Appendix 2: Tracability Diagramming Notation 28

Confidential © 2000 The Great Idea 4

Requirements Management Plan

Confidential © 2000 The Great Idea 5

Confidential © 2000 The Great Idea 6

Confidential © 2000 The Great Idea 7

2. Requirement Artifacts and Requirement Types

ARTIFACT REQ. TYPE DESCRIPTION

Confidential © 2000 The Great Idea 8

REQUIREMENT TYPE DESCRIPTION

Confidential © 2000 The Great Idea 9

Dokter dan Perawat

Supplier Alat Tulis Kantor

Karyawan non medik

3.2 Requirement Attributes for Stakeholder(STK)

Confidential © 2000 The Great Idea 10

d. Internet Service Provider (ISP)

3.4 Requirement Attributes for Feature(FEAT)

Confidential © 2000 The Great Idea 11

No Perencanaan Pembangunan Sistem Effort

1 Koordinasi dengan Stakeholder 10 %

4. Perancangan Jaringan untuk Sistem Secara 15 %

6 Sosialisasi Tentang Sistem 10 %

Confidential © 2000 The Great Idea 12

Confidential © 2000 The Great Idea 13

No Versi Target Rilis

1 Alpa 9 bulan pasca kontrak

2 Beta 12 bulan pasca kontrak

3 Release Candidate 13 Bulan pasca kontrak

4 Stable Versi 0 14 bulan pasca kontrak

Impact to Business Process

3.5 Requirement Attributes for Actor(ACTOR)

3.6 Requirement Attributes for Use-Case(UC)

Confidential © 2000 The Great Idea 14

3.7 Requirement Attributes for Use-Case Detail(UCDR)

3.8 Requirement Attributes for Supplemental(SUPP)

Confidential © 2000 The Great Idea 15

3.9 Requirement Attributes for Design(DE)

1. Processor type Intel (R) Core i3

Kebutuhan perangkat keras untuk digunakan oleh server:

3.10 Requirement Attributes for Test Plan(TPR)

3.11 Requirement Attributes for Test(TR)

3.12 Requirement Attributes for Issue(ISS)

3.13 Requirement Attributes for Assumption(ASM)

3.14 Requirement Attributes for Term(TERM)

Confidential © 2000 The Great Idea 16

3.15 Requirement Attributes for Business Rule(BR)

Confidential © 2000 The Great Idea 17

Appendix 1: Technology Risk Assessment

Risk Factor Weight

Table A-1 Technology Risk Assessment. [5]

Confidential © 2000 The Great Idea 18

Appendix 2: Tracability Diagramming Notation

Classes are used to

Uni-directio nal relations hips

Recurs ive non-agg regate

All traces have a multiplic ity of 1 to 0..* unless otherwise

Confidential © 2000 The Great Idea 19

Confidential © 2000 The Great Idea 20

Potrebbero piacerti anche