2 ShinjuRamenIS - Requirements Management Plan

Shinju Ramen Information System
Requirements Management Plan
Version 0.8
Confidential © 2000 The Great Idea 1

Project Name: Kelompok Version: 0.8 Author:
Requirements Management Plan Creation Date: 26-03-2017 Kelompok
File: 378911859.doc Published Date:
Revision History
Date Version Description Author
Confidential © 2017 Shinju Ramen Information System

2
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 6
1.6 OVERVIEW 6
2. REQUIREMENT ARTIFACTS AND REQUIREMENT TYPES 7
3. REQUIREMENT ATTRIBUTES 9
3.1 REQUIREMENT ATTRIBUTES FOR IMPACTED GROUP(IG) 9
3.2 REQUIREMENT ATTRIBUTES FOR STAKEHOLDER(STK) 9
3.3 REQUIREMENT ATTRIBUTES FOR STAKEHOLDER NEED(NEED) 9
3.4 REQUIREMENT ATTRIBUTES FOR FEATURE(FEAT) 10
3.5 REQUIREMENT ATTRIBUTES FOR ACTOR(ACTOR) 14
3.6 REQUIREMENT ATTRIBUTES FOR USE-CASE(UC) 15
3.7 REQUIREMENT ATTRIBUTES FOR USE-CASE DETAIL(UCDR) 15
3.8 REQUIREMENT ATTRIBUTES FOR SUPPLEMENTAL(SUPP) 18
3.9 REQUIREMENT ATTRIBUTES FOR DESIGN(DE) 19
3.10 REQUIREMENT ATTRIBUTES FOR TEST PLAN(TPR) 20
3.11 REQUIREMENT ATTRIBUTES FOR TEST(TR) 20
3.12 REQUIREMENT ATTRIBUTES FOR ISSUE(ISS) 21
3.13 REQUIREMENT ATTRIBUTES FOR ASSUMPTION(ASM) 21
3.14 REQUIREMENT ATTRIBUTES FOR TERM(TERM) 21
3.15 REQUIREMENT ATTRIBUTES FOR BUSINESS RULE(BR) 22
4. TRACABILITY CRITERIA 23
FIGURE 4-1 REQUIREMENTS TRACABILITY DIAGRAM 23
4.1 CRITERIA FOR IMPACTED GROUP 23
4.2 CRITERIA FOR STAKEHOLDER 23
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 24
4.8 CRITERIA FOR SUPPLEMENTAL REQUIREMENTS 24
4.9 CRITERIA FOR DESIGN ELEMENT REQUIREMENTS 24
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 25
4.16 CRITERIA FOR SUPPORTING DOCUMENT REQUIREMENTS 25
5. RATIONAL REQUISITEPRO VIEWS 26
5.1 SCOPING VIEW, SEE TARGET RELEASE IN 3.4 26

3
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

4
Requirements Management Plan

1. Introduction
1.1 Purpose
Dokumen dibuat dengan tujuan untuk digunakan sebagai pemandu menggambarkan secara umum
kebutuhan standar yang diperlukan untuk mengembangkan sistem informasi yang akan dibangun. Yang
akan dijelaskan dalam dokumen ini antara lain:
 Requirement Artifacts
 Requirement Types
 Tracability Criteria
1.2 Scope
Ruang lingkup requirements management plan ini berguna untuk membatasi kebutuhan-kebutuhan yang
akan digunakan untuk pengembangan sistem informasi Shinju Ramen. Ruang lingkup yang akan
digunakan antara lain:
 Operational Management
 Marketing Management
 Human Resource Management
 Financial Management
1.3 Collaborators
 Angky Fajriati
 Atika Wahyugirini
 Dhiva Azhara
 Rona Uli Pardede
1.4 Definitions, Acronyms and Abbreviations
Business Rule
Suatu rangkaian aturan yang harus diikuti dalam suatu proses/activity.
Product Feature
Kemampuan atau karakteristik sistem yang secara langsung memenuhi kebutuhan.
Stakeholder
Suatu masyarakat, kelompok, komunitas ataupun individu manusia yang memiliki hubungan dan
kepentingan terhadap suatu organisasi atau perusahaan.
Stakeholder Need
Masalah bisnis atau operasional yang harus dipenuhi untuk memastikan pembelian atau penggunaan.
Pareto Chart
Sebuah alat yang berguna untuk grafis yang menggambarkan di mana mengalokasikan waktu, manusia,
dan sumber daya keuangan akan menghasilkan hasil terbaik.
Rational Requisite®Pro
Rational Requisite®Pro membantu tim mengatur, memprioritaskan, melacak dan mengontrol perubahan
kebutuhan dari sistem atau aplikasi.

5
Customer
Pembeli ekonomi dari proyek yang dikembangkan. Biasanya diwakili oleh Bisnis Sistem Manajer.
Engineering Time
Sebuah unit pengukuran yang menggambarkan upaya rekayasa. Biasanya dinyatakan dalam satuan
minggu atau bulan. Dalam sebagian besar menggunakan, waktu rekayasa digunakan untuk memahami
ukuran relatif sesuatu, bukan sebagai waktu yang telah berlalu diiklankan untuk menyelesaikan tugas.
1.5 References
Referensi yang digunakan dalam pembuatan dokumen ini antara lain:
1. Feasibility Study Template
2. Feasibility Study Shinju Ramen
3. Requirement Management Plan Template
1.6 Overview
Dokumen ini akan menjelaskan secara rinci mengenai kebutuhan-kebutuhan dan proses pengelolaan
sistem informasi Shinju Ramen yang akan dibangun. Dokumen ini juga akan menjelaskan tanggung
jawab dari masing-masing stakeholder dalam pembangunan sistem informasi Shinju Ramen ini.

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

Vision (VIS) Stakeholder  Sistem transaksi online.
Need (NEED)
 Pencarian data pesanan pelanggan dapat dilakukan by ID (nomor
meja).
 Menampilkan data kehadiran pegawai.
Glossary Term (TERM) The Glossary defines important terms used in the project. Owned and
(GLS) authored by the System Analyst. Content provided by Stakeholders and TGI
IT.
Business Rule Business Rule Admin
Reference(BR) (BR)
 Dapat mengelola data user baru (pegawai)
 Dapat mengelola transaksi yang masuk
 Dapat mengelola menu makan dan minuman
User (Pegawai)
 Dapat menginputkan pesanan pelanggan secara online
 Dapat meihat jumlah transaksi pelanggan
Use-Case Error: Reference source not found menyediakan aktor dan use-case yang
Model Survey akan didokumentasikan dalam Rational Rose.
Use-Case Use-Case Detail Admin
Specification Requirement
 List data user
(UC) (UCDR)
 List transaksi
 List menu
User (pegawai)
 Form pemesanan
Supplementary Supplementary Sistem informasi Shinju Ramen ini membutuhkan gadget yang support
Specification Requirement terhadap web ini serta jaringan yang cepat dan stabil agar proses transaksi
(SS) (SUPP) tidak terhambat. Selain itu sistem informasi ini juga harus terjaga keamanan
sistemnya agar seluruh history transaksi tidak dapat diakses oleh yang tidak
berwenang.
Issues(ISU) Issue(ISS)  Terjadi kesalahpahaman analisis
 Kurang komunikasi antar developer
Table Requirement Artifacts and Requirement Types-1 Document based Requirement Artifacts and Types
REQUIREMENT TYPE DESCRIPTION

Impacted Group(IG)  Owner Shinju Ramen
7
 Pelanggan
Stakeholder(STK) Pegawai Shinju Ramen
Actor(ACTOR)  Admin (Owner Shinju Ramen)
 User (Pegawai Shinju Ramen)
Design Element(DE) Kebutuhan Input
 Database user
 Database menu
 Database transaksi
 Hak akses sistem infromasi
Kebutuhan output
 Input user baru
 Input menu
 Infromasi transaksi dikirim melalui email kepada pelanggan
 Mencetak struk transaksi jika dibutuhkan
Use-Case (UC) Suatu fungsionalitas yang disediakan oleh sistem sebagai sarana interaksi dengan
user.
Table Requirement Artifacts and Requirement Types-2 Database Only Requirement Types

8
3. Requirement Attributes
3.1 Requirement Attributes for Impacted Group(IG)
Artifact (Document Type) Attributes Description
Stakeholder Request Stakeholder Request Berisi permintaan dan kebutuhan
(STR) (STRQ) stakeholders yang dipaparkan
dalam dokumen STRQ
Vision (VIS) Stakeholder Need Kondisi pada sistem yang dibangun untuk
(NEED), Feature mewujudkan permintaan stakeholder
(FEAT) yang dijelaskan dalam dokumen VIDO.
Use-Case Model Use Case (UC) Berisi use case dan aktor.
Glossary (GLS) Glossary Term Berisi kata-kata atau istilah asing
(TERM) dalam seluruh dokumen.
Supplementary Suplementary Berisi kebutuhan sistem yang
Spesification (SS) Requirement (SUPP) tidak dijelaskan dalam use case,
maka dijelaskan dalam dokumen
SUPP.
Requirements Requirements Menjelaskan kebutuhan dan dan
Management Plan Management Plan strategi terntentu yang digunakan
(RMP) (RMP) untuk pengembangan sistem
3.2 Requirement Attributes for Stakeholder(STK)

Stakeholders berupa Shinju Ramen dan tim pengembang Shinju Ramen Information System
3.3 Requirement Attributes for Stakeholder Need(NEED)
Problem Analyzed
Permasalahan yang dapat diambil dari hasil analisis yaitu:
1. Transaksi harian seperti pencatatan pesanan pelanggan dan penghitungan tagihan masih
dilakukan secara manual
2. Human error masih banyak terjadi ketika merekapitulasi laporan keuangan bulanan
3. Laporan absensi bulanan tidak akurat
4. Pelanggan tidak tahu menu Shinju Ramen
Contribution
Mengindikasi kontribusi dari setiap masalah yang dirasakan oleh Shinju Ramen

9
Transaksi m asih m anual

50
40
Laporan Keuangan tidak akurat
30
20
Laporan Absensi Bulanan tidak akurat
10
0
Stakeholder Needs Pelanggan tidak tahu m enu Shinju Ram en
Figure Requirement Attributes-1 Pareto Chart for root problems of Shinju Ramen
Level
Atribut level merepresentasikan tinggi dari requirement pada hirarki. Semakin besar jumlahnya,
maka semakin tinggi juga requirementsnya.
Dependency
Atribut depedency ini merepresentasikan jumlah dari requirements lain yang berhubungan dengan
suatu requirements.
3.4 Requirement Attributes for Feature(FEAT)
Status
Digunakan untuk menentukan ruang lingkup dari sistem. Dilakukan setelah negosiasi dan
peninjauan oleh tim project management dan manajer sistem bisnis
Proposed Fitur-fitur yang masih di diskusikan:
1. Pencatatan pesanan pelanggan yang akan dipakai oleh pelayan
2. Perhitungan biaya dan mengeluarkan nota tagihan pelanggan.
3. Pembuatan laporan keuangan perbulan yang dapat diakses oleh
karyawan bagian keuangan.
4. Pengelolaan data dan absensi karyawan oleh bagian human resource.
5. Web Shinju dapat juga di akses oleh pelanggan untuk mendapatkan
informasi mengenai menu dan promosi yang ada.
Approved Fitur-fitur yang telah disetujui:
1. Pencatatan pesanan pelanggan yang akan dipakai oleh pelayan.
5. Menampilkan menu dan promosi yang dapat diakses oleh
pelanggan

10
Incorporated 1. Pencatatan pesanan pelanggan yang akan dipakai oleh pelayan.

5. Menampilkan menu dan promosi yang dapat diakses oleh
pelanggan
Validated 1. Pencatatan pesanan pelanggan yang akan dipakai oleh pelayan.
5. Menampilkan menu dan promosi yang dapat diakses oleh pelanggan
Table Requirement Attributes-3 Status attribute values for FEAT requirement type.
Benefit
Me-ranking kebutuhan yang bermanfaat bagi stakeholders. Untuk mengelola ruang lingkup dan
menentukan prioritas dalam pengembangan sistem
Critical Merupakan fitur yang sangat penting pada sistem. Kegagalan dalam
implementasi fitur ini, menandakan bahwa sistem tidak memenuhi
kebutuhan customer
Important Merupakan fitur penting dalam keefektifan dan efisiensi sistem. Jika ada
kesalahan, maka akan mempengaruhi kepuasaan customer.
2. Pembuatan laporan keuangan bulanan.
3. Pengelolaan data dan absensi karyawan.
Useful Merupakan fitur yang diperkirakan akan jarang dipakai
restaurant
Table Requirement Attributes-4 Benefit attribute values for FEAT requirement type.

11
Effort
Beberapa fitur memerlukan waktu dan resource yang lebih banyak daripada yang lainnya.
Sehingga memperkirakan waktu adalah cara terbaik untuk mengatur apa saja yang harus dilakukan
Requirem ents
Test 22%
28%
Design
16%
Develop
34%
Figure Requirement Attributes-2 Percent engineering hours by phase. [2]

12
Size
Diperkirakan akan ada 4 modul, yaitu modul transaksi harian, modul laporan keuangan, modul
absensi karyawan, dan modul marketing. Semakin banyak baris code yang akan dibangun, maka
semakin besar kompleksitas proyek.
Coordination Complexity
Dalam pengembangan Shinju Ramen Information System, tim pengembang akan berkoordinasi
dengan seluruh organisasi dari mulai internal hingga external.
Technology Risk
Resiko yang melibatkan teknologi yang kemungkinan terjadi seperti kurangnya user yang
menguasai teknologi, sehingga akan mengakibatkan berkurangnya nilai dari suatu sistem tersebut.
Architectural Impact
Fitur-fitur pada Shinju Ramen Information System tidak akan berdampak kepada perubahan
arsitektural.

13
Development Risk
Resiko yang kemungkinan terjadi ketika pengembangan Shinju Ramen Information System yaitu:
1. Waktu yang dibutuhkan untuk mengembangkan sistem melebihi waktu yang telah ditentukan.
2. Memungkinkan ada beberapa fitur yang tidak berjalan dengan baik.
Stability
Digunakan untuk membantu menentukan prioritas dan menentukan item-item tambahan.
Hard Sangat tidak mungkin fitur ini akan berubah:

Neutral Tidak ada indikator untuk memprediksi perubahan pada fitur ini:
2. Pembuatan laporan keuangan bulanan.
Soft Memungkinkan fitur ini akan berubah:
restaurant
2. Pengelolaan data dan absensi karyawan
Table Requirement Attributes-5 Stability attribute values for FEAT requirement type.
Target Release
Fitur yang kemungkinan akan di realease terlebih dahulu yaitu fitur-fitur penting seperti aplikasi
pencatatan pesanan pelanggan, perhitungan biaya tagihan pelanggan dan pembuatan laporan
keuangan bulanan.
Impact to Business Process
Dampak dari Shinju Ramen Information System terhadap bisnis proses yang telah ada yaitu
mengganti yang tadinya dilakukan secara manual, sekarang menjadi terkomputerisasi dan berbasis
online.
Level
Dependency
suatu requirements.
3.5 Requirement Attributes for Actor(ACTOR)
Brief Description
Aktor yang terlibat dalam Shinju Ramen Information System ini yaitu:
1. Karyawan restaurant (pelayan dan kasir)
2. Karyawan bagian keuangan
3. Karyawan bagian human resource

14
4. Pelanggan Shinju Ramen
3.6 Requirement Attributes for Use-Case(UC)
Brief Description
1. Karyawan berupa pelayan dan kasir dapat melakukan transaksi harian seperti pencatatan
pesanan dan penghitungan tagihan pelanggan
2. Karyawan bagian keuangan dapat melakukan rekapitulasi laporan keuangan bulanan
3. Karyawan bagian human resource dapat melakukan pencatatan dan rekapitulasi data&laporan
absensi karyawan
4. Pelanggan shinju ramen dapat melihat menu melalui web
3.7 Requirement Attributes for Use-Case Detail(UCDR)

Menjelaskan hal apa saja yang harus dilakukan oleh sistem
Section
Name Pencatatan Order Pelanggan
Brief Pelayan akan melakukan pencatatan order pelanggan melalui web, lalu akan
Description disimpan dalam database
Basic Flow Actor Sistem
1. Mengklik nomor meja dan
menu yang diorder oleh
pelanggan
2. Menyimpan data ke database
3. Menampilkan pesan berhasil
Special Nomor meja dan menu tidak boleh kosong
Requirements
Pre-Condition Pelayan harus login ke dalam web
Post-Condition Data tersimpan ke database
Name Penghitungan Tagihan Order Pelanggan

Brief Kasir akan memilih nomor meja pelanggan, lalu sistem akan mengeluarkan
Description tagihan yang harus dibayar
1. Mengklik nomor meja
2. Menampilkan jumlah tagihan
yang harus dibayar oleh
pelanggan
3. Memvalidasi harga
4. Mengeluarkan tampilan nota
tagihan
5. Jika sudah selesai, data
keuangan akan masuk ke
database tetapi data nomor meja
akan terhapus

15
Special Input nomor meja tidak boleh kosong

Requirements
Pre-Condition Kasir harus login ke dalam web
Name Pembuatan Laporan Keuangan Bulanan

Brief Sistem akan membuat laporan keuangan dari setiap transaksi harian yang
Description tersimpan di database
1. Mengklik menu Laporan
Keuangan Bulanan
2. Menampilkan laporan keuangan
perhari yang telah di satukan
perbulannya
Pre-Condition Bagian keuangan harus login ke dalam web
Name Pembuatan Laporan Absensi Bulanan

Brief Sistem akan membuat laporan absensi dari setiap absensi harian yang
Description tersimpan di database
1. Mengklik menu Laporan
Absensi Bulanan
2. Menampilkan laporan absensi
perhari yang telah di satukan
perbulannya
Pre-Condition Bagian human resource harus login ke dalam web
Name View Menu Shinju Ramen

Brief Pelanggan dapat melihat menu dan promosi yang disediakan oleh Shinju
Description Ramen
1. Masuk ke dalam web Shinju
Ramen
2. Menampilkan menu dan
promosi yang ada
Pre-Condition Pelanggan harus masuk ke dalam web
Post-Condition
Table Requirement Attributes-6 Location attribute values for UCDR requirement type.

16
Affects Architecture
Mengindikasikan apakah kebutuhan mempengaruhi arsitektur dari software atau tidak.
Effort
Waktu yang dibutuhkan untuk membangun Shinju Ramen Information System yaitu selama 10
minggu. Kebutuhan yang diajukan membutuhkan biaya dan sumber daya yang sedang.
Size
Masing-masing aplikasi pada Shinju Ramen Information System mempunyai jumlah baris kode
yang berbeda. Semakin besar jumlah baris kode lebih besar kompleksitas dan kesulitan dari
requirements nya.
Reviewed Ambiguity
Menunjukkan beberapa perbedaan tafsiran dari pengguna ketika melihat spesifikasi kebutuhan.
Stability
Digunakan untuk menentukan prioritas dalam pengembangan sistem informasi. Kemungkinannya
yaitu Neutral, karena tidak ada indikasi untuk memprediksi perubahan dari perilaku dari
requirements.
Level
Dependency
suatu requirements.

17
3.8 Requirement Attributes for Supplemental(SUPP)
Effort
Beberapa fitur memerlukan waktu dan resource yang lebih banyak daripada yang lainnya.
Sehingga memperkirakan waktu adalah cara terbaik untuk mengatur apa saja yang harus dilakukan
Size
Masing-masing aplikasi pada Shinju Ramen Information System mempunyai jumlah baris kode
yang berbeda. Semakin besar jumlah baris kode lebih besar kompleksitas dan kesulitan dari
requirements nya.
Reviewed Ambiguity
Ditentukan oleh sistem analist, dan mewakili dari perbedaan tafsiran oleh user yang melihat
requirements.
Stability
Digunakan untuk menentukan prioritas dalam pengembangan sistem informasi. Kemungkinannya
yaitu Neutral, karena tidak ada indikasi untuk memprediksi perubahan dari perilaku dari
requirements.
Level
Dependency
suatu requirements.

18
3.9 Requirement Attributes for Design(DE)
Type
Executable Menggunakan bahasa pemrograman HTML
Package Menggunakan MVC (Model View Controller) Design Patterns
Class - Admin
- Karyawan_keuangan
- Pelayan
- Kasir
- Karyawan_HR
- Pelanggan
- Menu
- Meja
- Laporan_keuangan
- Laporan_absensi
- View
- Controller
Method - setter
- getter
- addMenu()
- deleteMenu()
- addPesanan()
- editPesanan()
- deletePesanan()
- manageLaporanKeuangan()
- manageLaporanAbsensi()
- viewMenu()
Table Requirement Attributes-7 Type attribute values for DE requirement type.
Actual NCSS
Ditentukan oleh Software Architect, Designer atau Implementers. Digunakan untuk menghitung
kepadatan defect atau kecacatan untuk keputusan rilis oleh Manajer Proyek.
Status
No Design Belum ada desain yang selesai untuk elemen.
Designed Desain telah selesai untuk suatu elemen.
Design Desain elemen telah diperiksa dan diterima.
Inspected
Coding Coding untuk elemen yang sedang berlangsung.
Code Inspected Kode untuk elemen telah diperiksa.
Tested Uji unit telah dilaksanakan pada elemen.
Untuk saat ini, tim baru sampai mendesain database dari sistem.

19
3.10 Requirement Attributes for Test Plan(TPR)

Menjelaskan hal apa saja yang akan dilakukan oleh test requirement.
Assigned To
Seorang test engineer bertanggung jawab untuk menulis test cases yang dapat menyetujui
requirement.
Status
No Activity Belum ada pekerjaan yang selesai dalam pelaksanaan requirements
In Progress Uji kasus yang memverifikasi requirements sedang ditulis
Written Uji kasus telah ditulis namun belum lulus pemeriksaan
Inspected Uji kasus telah ditulis, diperiksa, dan diterima
Table Requirement Attributes-8 Status attribute values for TPR requirement type.
Untuk saat ini, status masih di No Activity karena belum ada pekerjaan yang terselesaikan.
Planned Build
Pembangunan sistem dapat terlaksana dengan baik apabila sudah dilakukan pengujian dan dinilai
kelayakannya oleh user.
3.11 Requirement Attributes for Test(TR)

Menjelaskan hal apa saja yang akan diperiksa oleh test requirement.
Assigned To
Seorang test engineer bertanggung jawab untuk menulis test cases yang dapat menyetujui
requirement.
Status
Ditentukan oleh test engineer
No Activity Belum ada pekerjaan yang selesai dalam pelaksanaan requirements

Planned Script manual atau otomatis yang sudah diidentifikasi dan terasosiasi dengan
requirements.
Manual Script manual yang telah dibuat dan divalidasi menjadi yang mampu untuk
membuktikan requirements.
Automated Script otomatis yang telah dibuat dan divalidasi menjadi yang mampu untuk
membuktikan requirements.
Table Pembangunan sistem dapat terlaksana dengan baik apabila sudah dilakukan pengujian dan
dinilai kelayakannya oleh user.-9 Status attribute values for TR requirement type.
Untuk saat ini, status masih di No Activity karena belum ada pekerjaan yang terselesaikan.
Planned Build
Test case diuji dengan menggunakan white box testing, yaitu testing dengan kesesuaian suatu komponen
terhadap desain.

20
3.12 Requirement Attributes for Issue(ISS)
Created
Tanggal dimulai permasalahan yaitu pada tanggal 28 Februari 2017.
Resolved
Tanggal permasalahan selesai belum ditentukan.
Assigned To
Pihak yang bertanggung jawab untuk menyelesaikan permasalahan yaitu anggota kelompok atau
tim pengembang.
Status
Set by the test assigned development team member. Tracks progress during issue resolution.
No Activity Belum ada pekerjaan yang telah selesai.

In Progress Permasalahan sedang dikerjakan.
Resolved Permasalahan telah diselesaikan.
dinilai kelayakannya oleh user.-10 Status attribute values for ISS requirement type.
Untuk saat ini, status masih pada In Progress.
3.13 Requirement Attributes for Assumption(ASM)
Requirement text defines the assumption.
Created
Tanggal dari asumsi yaitu 11 Maret 2017
Status
Set by any team member. Minimizes repeated discussions or miss-directed expectations.
Stated Asumsi telah didokumentasikan

Accepted Tim dan perusahaan telah menerima asumsi
Rejected Asumsi telah ditolak
dinilai kelayakannya oleh user.-11 Status attribute values for ASM requirement type.
Untuk saat ini, asumsi yang sebelumnya telah ditulis pada dokumen Feasibility Study telah Stated dan
Accepted.
3.14 Requirement Attributes for Term(TERM)
Created
Waktu ketika term termasuk ke dalam salah satu glosari.

21
Status
TERM telah pada tahap stated dan accepted.
Stated The Term has been initially defined..

Accepted Team and business have accepted the Term and its definition.
dinilai kelayakannya oleh user.-12 Status attribute values for TERM requirement type.
3.15 Requirement Attributes for Business Rule(BR)
Created
Aturan dalam bisnis telah ditetapkan sejak tanggal 28 Februari 2017.
Status
Aturan bisnis atau business rules telah dalam tahap stated dan accepted.
Stated The Business Rule has been documented.
Accepted Team and business have accepted the Business Rule.
dinilai kelayakannya oleh user.-13 Status attribute values for BR requirement type.

22
4. Tracability Criteria
Impacted Group Issue
Note: This tracability link is

optional as ift can be derived from Assumption
the link between the Product Stakeholder
Feature and Use Case Section.
This link is often used to relate Supporting Document
the Product Features to the Use
Cases before the Use Case Stakeholder Need
Sections are written.
Product Feature
Use Case
1..*
1..* 1..*
Supplemental Requirement Actor Use Case Detail Requirement
1
Design
+Lower Element
Glossary
+definition Test Plan Requirement
Test Requirement
1..* 1..*
Business Rule This trace is implied by
a relationship to a test
script which contains
+definition the verification and is
1..* under the control of
Verification Point Rational TestManager
the great indoors - Requirements Traceability Diagram

Created: 29 Feb. 2000 by Stephen Hunt, Rational Software
Figure Tracability Criteria-3 Requirements Tracability Diagram
4.1 Criteria for Impacted Group

Impacted group terdiri dari sekelompok orang yang melakukan pembangunan sebuah proyek.
Proyek tersebut dibangun berdasarkan ide yang dikemukakan setiap anggota sehingga memberikan
saran dan ide untuk kelancaran pembangunan proyek tersebut.
4.2 Criteria for Stakeholder

Stakeholder yang berkaitan dengan sistem ini adalah :

23
 Client, pada sistem ini bagian client adalah Shinju Ramen. Client akan memberikan
permasalahan terkait dengan website untuk melayani dan mengatur segala proses transaksi
pada Shinju Ramen. Kemudian pihak developer akan memberikan tawaran solusi terhadap
permasalahan yang diberikan.
 User, pada sistem ini user adalah orang yang menggunakan layanan Sistem Informasi Shinju
Ramen yaitu pegawai dan pelanggan reastauran dimana system ini berbasis website.
4.3 Criteria for Stakeholder Need Requirements
Client, pada bagian ini client membutuhkan sistem yang mempermudahkan proses transaksi dan
pencatatan proses transaksi serta pengelolaanya. Terutama pada bagian antrian pelayanan yang
dibutuhkan/digunakan oleh user.
4.4 Criteria for Product Feature Requirements

Kriteria kebutuhan feature di produk yang dibutuhkan untuk fitur-fitur pemesanan adalah nomer
meja dari pelangga yang akan melakukan pemesanan berupa integer. Nomor antrian ini akan
digunakan sebagai nomer identitas pelanggan saat akan melakukan pemesanan dan saat akan
melakukan transaksi pembayaran.
4.5 Criteria for Use-Case Requirements

Kriteria dalam requirment use-case diantaranya terdiri dari aktor, boundary, association,
generalisasi, include,extend
4.6 Criteria for Actor Requirements

Actor merupakan orang atau sesuatu yang berinteraksi dengan sistem, seperti: manusia, sistem,
device, dll. Dalam Sistem Informasi Shinju Ramen, actor yang digunakan ada dua, yakni pegawai
dan pelanggan.
4.7 Criteria for Use-Case Detail Requirements

Dalam detail use-case Requirement diperlukan kriteria yaitu harus adanya aktor, dalam Sistem
Informasi Shinju Ramen online ini yang menjadi aktor diantaranya pegawai dan pelanggan. Selain
itu use-case yang disediakan diantaranya berupa pemesanan, jumlah tra.
4.8 Criteria for Supplemental Requirements

Modul yang akan dilakukan pengetesan adalah :
1. Bagian penginputan data user akan masuk ke dalam database yang sesuai atau tidak.
2. Pelanggan bisa melihat pilihan menu yang dapat dipesan.
3. Pegawai bisa melihat jumlah transaksi yang benar dari seorang pelanggan berdasarkan
inputan nomor meja yang diberikan pelanggan.
4. Pegawai dapat melihat rekap laporan keuangan bulanan.
4.9 Criteria for Design Element Requirements

Dalam perancangan elemen, diperlukan suatu input untuk menghasilkan output yang sesuai dengan
kebutuhan user.

24
4.10 Criteria for Test Plan Requirements

Metode yang digunakan untuk melakukan rencana testing pada Sistem Infomasi Shinju Ramen
adalah dengan metode white box dimana metode ini menjamin operasi-operasi internal pada sistem
informasi berjalan sesuai dengan spesifikasi yang telah ditetapkan serta sesuai dengan prosedur
yang dirancang
4.11 Criteria for Test Requirements

Test requirements digunakan untuk melakukan pengujian dan menentukan kelayakan sistem
informasi yang telah dibangun..
4.12 Criteria for Issue Requirements

Modul bisa dilacak sesuai dengan requirements yang ada agar lebih memudahkan jika terjadi error
dan diperlukan maintenance.
4.13 Criteria for Glossary Requirements

Kriteria pada bagian ini adalah kriterian untuk kalimat, akronim, defisini yang ada pada setiap
dokumen dan selalu digunakan. Kalimat tersebut juga akan menjadi bagian utama dari sistem.
4.14 Criteria for Assumption Requirements

Assumption requirements digunakan oleh sistem analis dalam menentukan dugaan sementara
mengenai kebutuhan yang kurang jelas. Asumsi tersebut harus mendapat persetujuan dari anggota
tim agar tidak terjadi perbedaan pendapat.
4.15 Criteria for Business Rule Requirements

Kriteria dalam requirement peraturan bisnis di sistem informasi shinju ramen ini diantaranya user
hanya dapat melihat daftar harga dan daftar menu, dalam proses pembayaran harus menggunakan
nomor meja pelanggan.
4.16 Criteria for Supporting Document Requirements

Kriteria yang menjadi requirement dalam dokumen pendukung diantaranya dokumen yang
berisikan tentang requirement management plan, feasibility study mengenai sistem informasi
shinju ramen dimana dokumen tersebut berpengaruh dalam pengerjaan dokumen ini.

25
5. Rational RequisitePro Views

Untuk bab ini, diperlukan software yang berbayar RequisitePro yang berguna untuk membantu
pengembang untuk mengelola requirements atau kebutuhan sebuah proyek
5.1 Scoping View, see Target Release in 3.4
6. Rational RequisitePro Extensions

Untuk bab ini, diperlukan software yang berbayar RequisitePro yang berguna untuk membantu
pengembang untuk mengelola requirements atau kebutuhan sebuah proyek
6.1 Calculate Feature dependency count
6.2 Calculate requirement level counter
6.3 Calculate Technology Risk
6.4 Trace Check the requirements
6.5 Do a Pareto check on Stakeholder Needs
6.6 Create Soda document for UCMS

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

27
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-4 Tracability Diagramming Notations [6]
TODO
Verify all references are present and referenced.

28

2 ShinjuRamenIS - Requirements Management Plan

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2 ShinjuRamenIS - Requirements Management Plan

Загружено:

Авторское право:

Доступные форматы

Shinju Ramen Information System

Requirements Management Plan

Confidential © 2000 The Great Idea 1

Confidential © 2017 Shinju Ramen Information System

Confidential © 2017 Shinju Ramen Information System

6. RATIONAL REQUISITEPRO EXTENSIONS 26

Appendix 2: Tracability Diagramming Notation 28

Confidential © 2017 Shinju Ramen Information System

Requirements Management Plan

Confidential © 2017 Shinju Ramen Information System

Confidential © 2017 Shinju Ramen Information System

2. Requirement Artifacts and Requirement Types

ARTIFACT REQ. TYPE DESCRIPTION

REQUIREMENT TYPE DESCRIPTION

Confidential © 2017 Shinju Ramen Information System

3.2 Requirement Attributes for Stakeholder(STK)

Confidential © 2017 Shinju Ramen Information System

Transaksi m asih m anual

3.4 Requirement Attributes for Feature(FEAT)

Confidential © 2017 Shinju Ramen Information System

Incorporated 1. Pencatatan pesanan pelanggan yang akan dipakai oleh pelayan.

Confidential © 2017 Shinju Ramen Information System

Figure Requirement Attributes-2 Percent engineering hours by phase. [2]

Confidential © 2017 Shinju Ramen Information System

Confidential © 2017 Shinju Ramen Information System

Hard Sangat tidak mungkin fitur ini akan berubah:

3.5 Requirement Attributes for Actor(ACTOR)

Confidential © 2017 Shinju Ramen Information System

4. Pelanggan Shinju Ramen

3.6 Requirement Attributes for Use-Case(UC)

3.7 Requirement Attributes for Use-Case Detail(UCDR)

Name Penghitungan Tagihan Order Pelanggan

Confidential © 2017 Shinju Ramen Information System

Special Input nomor meja tidak boleh kosong

Name Pembuatan Laporan Keuangan Bulanan

Name Pembuatan Laporan Absensi Bulanan

Name View Menu Shinju Ramen

Confidential © 2017 Shinju Ramen Information System

Confidential © 2017 Shinju Ramen Information System

3.8 Requirement Attributes for Supplemental(SUPP)

Confidential © 2017 Shinju Ramen Information System

3.9 Requirement Attributes for Design(DE)

Table Requirement Attributes-7 Type attribute values for DE requirement type.

Confidential © 2017 Shinju Ramen Information System

3.10 Requirement Attributes for Test Plan(TPR)

3.11 Requirement Attributes for Test(TR)

No Activity Belum ada pekerjaan yang selesai dalam pelaksanaan requirements

Confidential © 2017 Shinju Ramen Information System

3.12 Requirement Attributes for Issue(ISS)

No Activity Belum ada pekerjaan yang telah selesai.

Stated Asumsi telah didokumentasikan

Confidential © 2017 Shinju Ramen Information System

Stated The Term has been initially defined..

3.15 Requirement Attributes for Business Rule(BR)

Confidential © 2017 Shinju Ramen Information System

Note: This tracability link is

+definition Test Plan Requirement

the great indoors - Requirements Traceability Diagram

Figure Tracability Criteria-3 Requirements Tracability Diagram

4.1 Criteria for Impacted Group

4.2 Criteria for Stakeholder

Confidential © 2017 Shinju Ramen Information System

4.4 Criteria for Product Feature Requirements