Desain Solusi

Dokumen (SDD)

Nama Proyek: [Nama lengkap]

Kode proyek: [Kode 8 karakter]
Versi: kapan: XX
Pengarang: [Namamu]
Posisi: [Posisi kamu]
Telepon: [Nomor telepon Anda]

1. Surel: [Alamat email anda]

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

Riwayat Dokumen

Versi: kapan Bertanggung jawab Tanggal Catatan

1.0

*** Akhir
Daftar Revisi
***
Tabel 1Riwayat Dokumen

1. Kontak untuk Pertanyaan dan Usulan Perubahan

Jika Anda memiliki pertanyaan mengenai dokumen ini, hubungi:
Nama: Marc Dimmick
Penamaan: Analisis Bisnis Sistem
Telepon: (08) 6216 6335
Surel: Marc.dimmick@dcp.wa.gov.au

Jika Anda mempunyai saran untuk menyempurnakan dokumen ini, lengkapi dan teruskan
salinannya Saran untuk Perbaikan ke Dokumentasi .

2. Catatan Masalah
Catatan Masalah mencerminkan revisi terhadap templat ini. Informasi ini harus dihapus dari
dokumen Anda.
Ver Tanggal Sifat Amandemen
1.0 12 April 2006 Dokumen Awal
1.1 8 Juni Perbarui Tata Letak dan lembar gaya
1.2 23 November Perbarui Tata Letak dan Gaya
06
1.3 19 Juli 2007 Perbarui Logo Perusahaan

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

2. Pedoman penyelesaian Dokumen ini:
Konsultan diharuskan mengumpulkan dan mendokumentasikan persyaratan dalam konsultasi dengan
pemangku kepentingan proyek. Tanggung jawab keseluruhan untuk hal ini terletak pada pimpinan
proyek.
Templat ini memastikan bahwa rincian penting yang berkaitan dengan Persyaratan ini
mendokumentasikan pernyataan Persyaratan Fungsional dan Non-Fungsional yang jelas dan tidak
ambigu.
Dokumen ini digunakan dalam pengembangan, pengujian, penjaminan mutu, manajemen proyek, dan
fungsi proyek terkait.
Item dalam tanda kurung siku harus diganti dengan konten yang sesuai. Misalnya, [Manajer Proyek]
harus diganti dengan nama Manajer Proyek.
Templat ini menyediakan struktur dan format yang direkomendasikan beserta contoh isi, catatan
penjelasan, dan pertanyaan untuk memandu dan mendorong penulis.
Harap hapus catatan ini dan pedoman lainnya dari dokumen sebenarnya. Itu dimaksudkan untuk
informasi Anda saja. Ini diberikan dalam warna dan font ini.
Jika suatu bagian/subbagian tidak berlaku, jangan dihapus. Sebaliknya, sebutkan hal tersebut dan
jelaskan mengapa hal tersebut tidak dapat diterapkan. Ingatlah untuk menjalankan pemeriksaan ejaan.
Sebaiknya gunakan tanggal dengan nama bulan daripada nomor bulan untuk menghindari kebingungan
(gunakan 2 Jan 2006 atau 2 Jan 2006, daripada 2/1/2006 atau 1/2/2006)
Dokumen ini berisi gaya judul yang telah diformat sebelumnya. Untuk mengubah baris menjadi judul, pilih
baris dan pilih BS Heading 1, BS Heading 2, dll., sesuai kebutuhan dari drop down gaya yang berdekatan
dengan kotak drop down font

Daftar isi
1 Riwayat Dokumen 2
1.1 Kontak untuk Pertanyaan dan Usulan Perubahan 2
1.2 Catatan Masalah 2

2 Pedoman penyelesaian Dokumen ini: 3

3 [Klien / Proyek] 6
3.1 Tujuan 6
3.2 Ikhtisar dan Status Proyek 6
3.3 Tujuan Proyek / Pernyataan Masalah 6

4 Ruang lingkup proyek 7

4.1.1 Inklusi 7
4.1.2 Pengecualian 7
4.1.3 Pentahapan jika diperlukan 7
4.2 Pemangku Kepentingan Utama 7
4.3 Dokumen Terkait Proyek dan Referensi Lainnya 7

5 Tinjauan Arsitektur 8
5.1 Antarmuka Sasaran 8

6 Keputusan Arsitektur 9
6.1 Masalah Arsitektur Utama 9
6.2 Risiko dan Asumsi Arsitektur 9

7 Deskripsi Solusi 10

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 7.1 Model Komponen 10
7.2 Penggunaan kembali komponen 10
7.3 Model Informasi 10
7.3.1 Karakteristik Informasi dan Data 11
7.4 Model Infrastruktur 11
7.5 Integrasi dan Desain Jaringan 11
7.6 Arsitektur Keamanan 11
7.6.1 Keamanan Aplikasi 11
7.6.2 Keamanan Operasional 12

8 Persyaratan sistem 13
8.1 [nama sistem/komponen] 13
8.1.1 Diagram Alir yang Relevan 13
8.1.2 Persyaratan Arsitektur Solusi 13
8.1.3 Deskripsi Desain 13

9 Implementasi dan Migrasi 14

9.1 Rencana Migrasi Arsitektur 14
9.1.1 Rencana Migrasi 14
9.1.2 Daftar Ketergantungan 14
9.2 GLOSARIUM 14

10 Persyaratan fungsional 15
10.1 Persyaratan – [Judul Fungsi 1] 15
10.2 Keluaran 15
10.3 Layar 15
10.4 Laporan 15
10.5 Persyaratan – [Judul Fungsi 2] 15
10.6 Keluaran 16
10.7 Layar 16
10.8 Laporan 16

11 masukan 17
11.1 Data 17
11.2 Aplikasi 17
11.3 Pihak ketiga 17

12 Desain 18
12.1 Warna 18
12.2 Lihat dan rasakan 18
12.3 Masalah Kegunaan 18
12.4 Hadirin 18

13 Pertunjukan 19
14 Migrasi dan Konversi Data 20
15 LAMPIRAN 21
15.1 Definisi 21
15.2 Lampiran 21

16 Daftar tanda tangan 22

Tabel

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

Tabel 1Riwayat Dokumen 2
Tabel 2 - Tujuan Proyek / Pernyataan Masalah 6
Tabel 3 -Pemangku Kepentingan Utama 7
Tabel 4 - Dokumen Terkait Proyek dan Referensi Lainnya 7
Tabel 5 - Keputusan Arsitektur 9
Tabel 6 -Masalah Arsitektur Utama 9
Tabel 7 - Resiko dan Asumsi Arsitektur 9
Tabel 8 - Diagram Alir yang Relevan 13
Tabel 9 - Glosarium 14
Tabel 10 - Persyaratan Fungsional 15
Tabel 11 - Persyaratan Fungsional 16
Tabel 12 - Definisi 21
Tabel 13 - Lampiran 21

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

3. [Klien / Proyek]
1. Tujuan
Tujuan utama dari dokumen ini adalah untuk mengomunikasikan elemen-elemen penting dari
keseluruhan solusi sehingga implikasi bisnis dapat dinilai dan dipahami, dan agar aktivitas desain dalam
Build/Acquire dapat dilanjutkan jika inisiatif tersebut disetujui.
Masukkan deskripsi pengembangan teknis dan apa yang akan dicapai setelah implementasi solusi yang
dijelaskan dalam dokumen ini berhasil.

2. Ikhtisar dan Status Proyek

Berikan latar belakang dan konteks inisiatif, serta statusnya saat ini dari perspektif proyek.
Status saat ini juga harus mencakup segala risiko atau permasalahan signifikan yang mungkin relevan
dengan desain.

3. Tujuan Proyek / Pernyataan Masalah

Berikan gambaran singkat tentang tujuan proyek, misalnya gambaran umum produk baru atau fitur baru,
atau sistem pendukung baru, dll. Sertakan ringkasan singkat mengenai kebutuhan bisnis dan pendorong
di balik inisiatif ini, serta kendala perusahaan, desain, dan standar. EG, termasuk perkiraan pertumbuhan,
lalu lintas puncak/volume transaksi, dan proyeksi pasar referensi, dll. Lihat BRD untuk detailnya.
Alternatifnya, tujuan dapat digambarkan sebagai inisiatif untuk memecahkan suatu masalah. Tabel di
bawah ini memberikan format yang disarankan untuk pernyataan masalah.
Masalah dari
Mempengaruhi
Dampaknya adalah
Solusi yang sukses akan
berhasil

4. Tabel 2 - Tujuan Proyek / Pernyataan Masalah

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 Ruang lingkup proyek
Sisipkan pernyataan yang menjelaskan ruang lingkup proyek.

1. Inklusi

2. Pengecualian

3. Pentahapan jika diperlukan

2. Pemangku Kepentingan Utama

Daerah/Posisi Nama / Peran Nomor kontak

Pemangku
Kepentingan Bisnis

Pemangku
Kepentingan Teknologi

Pemangku
Kepentingan Operasi

Tabel 3 -Pemangku Kepentingan Utama

3. Dokumen Terkait Proyek dan Referensi Lainnya

Cantumkan semua referensi yang digunakan dalam pembuatan dokumen ini.
ID Dokumen Judul / Deskripsi / Lokasi
Dokumen Terkait Proyek

Dokumen Referensi
Lainnya

5. Tabel 4 - Dokumen Terkait Proyek dan Referensi Lainnya

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

Tinjauan Arsitektur
Masukkan diagram arsitektur sistem, antarmuka, dan arus informasi dari solusi yang direncanakan.
Beri nomor pada setiap antarmuka untuk referensi di bawah.

1. Antarmuka Sasaran

Kunci Antarmuka Tujuan/Deskripsi

Misalnya. Misalnya. Sulaiman, Startrack Misalnya antarmuka yang ada, memberikan informasi manifes
1 akhir hari untuk keperluan pengiriman.

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

6. Keputusan Arsitektur
Sertakan ringkasan keputusan penting yang dibuat dalam memperoleh solusi di sini.
Pengidentifikasi Keputusan
Keterangan
Arsitektur
Misalnya.
Bagaimana pembuatan faktur untuk pesanan yang dikembalikan?
IKLAN-01
Faktur akan terjadi melalui proses batch harian antara…

IKLAN-02
…
Tabel 5 - Keputusan Arsitektur

1. Masalah Arsitektur Utama

Pengidentifikasi Sistem Terkena Keterangan Pemilik Status

Masalah Dampak
ISS – 01 Identifikasi sistem Masalah yang akan Pemilik masalah yang Tertutup/
yang terpengaruh didokumentasikan di bagian ini akan mengelolanya Terbuka
oleh nama sistem misalnya hingga mencapai
seperti yang resolusi
dijelaskan dalam 01/01/2003: Tidak jelas
dokumen ini apakah XXX akan
menghasilkan pesan
kesalahan axe.
ISS – 02
….
Tabel 6 -Masalah Arsitektur Utama

2. Risiko dan Asumsi Arsitektur

Risiko dan asumsi arsitektur utama adalah sebagai berikut:
NB, risiko yang harus dikelola oleh manajemen risiko proyek
Asumsi Resiko Sistem Terkena Dampak Keterangan

Identifikasi sistem yang

terpengaruh oleh nama
sistem seperti yang
Misalnya. Diasumsikan bahwa migrasi ke Microsoft .Net Framework
AR – 01 dijelaskan dalam
untuk portal ini tidak akan berdampak pada fungsionalitas antarmuka
dokumen ini
sistem ke portal ini saat ini.
Misalnya.
Portal Peramalan

7. Tabel 7 - Resiko dan Asumsi Arsitektur

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

Deskripsi Solusi
Bagian ini menjelaskan solusi Tingkat Tinggi dalam hal sistem/komponen dan bagaimana setiap
komponen berinteraksi dengan sistem/komponen lainnya.

1. Model Komponen
Menyertakan dan menjelaskan model komponen desain.
Komponen adalah elemen arsitektur apa pun yang dapat diterapkan. Hal ini ditandai dengan perilaku atau
fungsinya seperti yang diekspos atau diungkapkan melalui antarmuka eksternal. Komponen dapat
didekomposisi atau digabungkan menjadi komponen lain. Contohnya termasuk program, modul perangkat
lunak, sistem, penyimpanan data, elemen jaringan, dll. Masing-masing komponen dapat memanfaatkan
layanan yang diberikan oleh komponen lainnya, serta memberikan layanannya sendiri.
Model komponen menjelaskan bagaimana kumpulan komponen berpartisipasi dalam mendefinisikan
desain. Ini mencakup hubungan statis dan dinamis serta interaksi antar komponen. Dokumentasi model
biasanya mencakup sejumlah diagram yang mengekspresikan berbagai jenis hubungan — misalnya,
hubungan ketergantungan, hubungan penggunaan, hubungan interaksi dan waktu, dll. Jika solusi telah
dipartisi, masing-masing subset model komponen harus didefinisikan dengan jelas, dan penugasan ke
masing-masing penyedia harus diidentifikasi. Setiap subset selanjutnya akan menjadi subjek Spesifikasi
Komponen Desain dan biasanya ditentukan oleh Klien berdasarkan perkiraan biaya dan waktu yang
diberikannya hingga tingkat kepercayaan yang ditentukan oleh Manajer Proyek.
Penting untuk mengenali kategori antarmuka berikut:
● Antarmuka Pengguna — interaksi yang ada untuk memungkinkan interaksi manusia dengan
sistem;
● Antarmuka Layanan Aplikasi — interaksi yang memungkinkan layanan aplikasi yang disediakan
oleh satu sistem untuk digunakan oleh sistem lain secara otomatis;
● Antarmuka Operasional — interaksi yang digunakan untuk mengelola dan mengoperasikan
lingkungan sistem, termasuk pemantauan, pemulihan, dan manajemen pengecualian;
● Antarmuka Layanan Sinkronisasi Sistem — interaksi yang digunakan untuk mempertahankan
referensi persisten dan menyatakan integritas informasi di berbagai sistem secara tersinkronisasi.

Dalam menentukan antarmuka dan layanan, penting untuk dipahami bahwa ada dua kasus
penting:
● Layanan Fungsional — kasus ini melibatkan layanan yang pada dasarnya tidak memiliki
kewarganegaraan, dan terdapat korespondensi satu-ke-satu antara antarmuka dan layanan.
Masing-masing layanan tersebut dapat dijelaskan secara independen.
● Layanan Proses - ini melibatkan layanan yang mengimplementasikan suatu proses, dan
perilakunya bergantung pada aktivitas sebelumnya. Biasanya, satu proses mungkin melibatkan
banyak panggilan antarmuka — panggilan kadang-kadang disebut sebagai “pemicu” dan dalam
hal ini diperlukan, tidak hanya untuk menggambarkan masing-masing antarmuka tetapi juga
perilaku keadaan dari proses itu sendiri.
2. Penggunaan kembali komponen
Penting untuk mengidentifikasi layanan, komponen, kode, dokumentasi, dll yang merupakan kandidat
untuk digunakan kembali oleh perusahaan dan merancang serta memelihara dokumentasi dasar
sedemikian rupa sehingga memungkinkan penggunaan kembali dengan biaya minimal. Di bagian ini
jelaskan apa yang telah dicapai dalam penggunaan kembali, dan masalah apa pun yang timbul.

3. Model Informasi
Sertakan (atau referensi) dan jelaskan model informasi yang berkaitan dengan solusi.

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 Model Informasi mencakup pandangan terstruktur tentang informasi bisnis, sistem, dan keadaan yang
menjadi subjek desain. Model informasi tidak perlu menangani objek atau data yang tidak terekspos (atau
kemungkinan besar akan terekspos) secara eksternal.
Untuk solusi intensif manajemen data seperti Databases of Record, bagian dari solusi ini akan
membentuk proporsi yang signifikan dari total, dan sebenarnya dapat dimuat dalam dokumentasi terpisah
yang secara eksplisit dirujuk berdasarkan judul, tanggal dan versi.
Meskipun informasi yang diteruskan dan dikembalikan oleh setiap antarmuka dijelaskan dalam Model
Komponen, dalam banyak kasus, model informasi konsolidasi juga tepat untuk dijelaskan.
Jika solusi telah dipartisi, masing-masing subset model informasi harus didefinisikan dengan jelas, dan
penugasan ke masing-masing penyedia harus diidentifikasi.

1. Karakteristik Informasi dan Data

Terlepas dari kompleksitas atau ukuran model informasi, tentukan karakteristik non-fungsional yang
diperlukan dari elemen model (atau kelompok elemen). Karakteristik yang harus ditangani dapat
mencakup, namun tidak terbatas pada:
● Persistensi — menunjukkan elemen model mana yang harus bertahan di luar transaksi atau sesi,
termasuk kondisi di mana persistensi mungkin tidak lagi diperlukan, dan periode persistensi;
● Ukuran — menunjukkan jumlah kejadian yang diantisipasi dari setiap elemen;
● Keamanan dan Privasi — menunjukkan elemen mana yang bersifat sangat sensitif yang
memerlukan tindakan akses atau pengungkapan khusus, atau batasan privasi;
● Hukum dan Peraturan — menunjukkan elemen mana yang memerlukan penyimpanan data
tertentu, pengarsipan, pencatatan jejak audit, atau tindakan lain untuk memenuhi kewajiban
hukum atau peraturan. Semua persyaratan hukum dan peraturan mengenai informasi atau data
harus diidentifikasi sebagai persyaratan meskipun tercantum dalam judul topik lain (misalnya
persyaratan privasi yang diberlakukan oleh regulator pemerintah harus diidentifikasi sebagai
persyaratan hukum dan peraturan meskipun persyaratan tersebut tercantum dalam keamanan
dan privasi );
● Integritas — menunjukkan persyaratan integritas atau validitas spesifik apa pun yang terkait
dengan elemen informasi.
4. Model Infrastruktur
Untuk sistem TI, model infrastruktur mungkin diperlukan di mana server yang mendasarinya, media
penyimpanan, dll, ditentukan. (Dalam istilah IBM - model operasi)

5. Integrasi dan Desain Jaringan

Berlaku pada desain sistem TI di mana jaringan komunikasi yang mendasarinya harus ditentukan.
Tentukan aspek konseptual jaringan atau mekanisme integrasi yang diperlukan untuk menghubungkan
komponen-komponen. Model Komponen membahas mekanisme antarmuka, terutama dari perspektif
tingkat aplikasi atau layanan. Di sini disertakan informasi tambahan yang berkaitan dengan mekanisme
komunikasi, protokol atau model jaringan. Biasanya, rincian subbagian ini dikembangkan lebih lanjut
sebagai bagian dari Spesifikasi Integrasi.
Karakteristik fungsional dan non-fungsional dari integrasi dan perilaku jaringan harus disertakan.

6. Arsitektur Keamanan
Tujuan dari bagian ini adalah untuk menjelaskan kontrol keamanan yang akan dimasukkan ke dalam
solusi.

1. Keamanan Aplikasi
Jelaskan hal berikut:

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 ● Autentikasi. Bagaimana pengguna mengautentikasi ke sistem, jelaskan aturan kata sandi
terperinci. Jelaskan di mana infrastruktur otentikasi eksternal digunakan, misalnya akun-01.
● Otorisasi. Jelaskan kategori pengguna dan fungsionalitas yang akan mereka miliki. Sertakan
semua pengguna, pelanggan, staf, staf operasi yang mendukung platform
● Audit/Pencatatan. Jelaskan apa yang akan dicatat dan jelaskan platform audit atau pencatatan
eksternal apa pun yang digunakan
2. Keamanan Operasional
Jelaskan pada tingkat tinggi setiap proses terkait keamanan dan bagaimana sistem akan mendukung
proses ini:
● Bagaimana cara pengguna mendaftar atau mendaftarkan diri pada layanan ini? Bagaimana
kredensial autentikasi dikeluarkan dan diatur ulang?
● Bagaimana hak akses pengguna ditentukan dan diterapkan? Akankah proses persetujuan untuk
akses pengguna dikembangkan, jika ya, oleh siapa?
● Bagaimana hak akses pengguna dicabut?
● Proses manajemen kunci kriptografi
● Proses Respons Insiden Keamanan
● Manajemen kerentanan – termasuk penerapan patch dan penilaian kerentanan
8. Klasifikasi informasi khusus dan proses penanganannya

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 Persyaratan sistem
1. [nama sistem/komponen]
Selesaikan satu per sistem/komponen

1. Diagram Alir yang Relevan

ID Diagram Alir Nama Diagram Alir

FCXX

Tabel 8 - Diagram Alir yang Relevan

2. Persyaratan Arsitektur Solusi

Tujuan dari bagian ini adalah untuk menentukan persyaratan spesifik dan terstruktur dengan baik untuk
sistem yang terkena dampak, dan mempartisinya sedemikian rupa sehingga memudahkan definisi
desain.
Saat membuat Persyaratan Arsitektur, setiap persyaratan yang dapat diverifikasi yang ditentukan dalam
bagian ini harus dimuat dalam paragraf terpisah.
Sumber seluruh persyaratan mentah harus tercakup dalam Matriks Ketertelusuran Persyaratan, bersama
dengan referensi silang ke persyaratan yang diberi label di bagian ini.
Bagian ini berisi persyaratan arsitektur solusi spesifik untuk [Nama Sistem/Komponen].

3. Deskripsi Desain
9. Bagian ini merinci respons desain klien yang berkaitan dengan sistem/komponen spesifik yang akan
dikirimkan. Jika dokumen spesifikasi telah dirujuk pada bagian ini, pastikan dokumen terkait telah
dilampirkan pada bagian lampiran dokumen ini.

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 Implementasi dan Migrasi
Mengatasi pendekatan implementasi secara keseluruhan. Hal ini mencakup strategi migrasi dari proses
dan sistem yang ada, serta pertimbangan migrasi data. Biasanya bagian ini akan menjelaskan tahapan
implementasi yang akan meminimalkan dampak terhadap operasi bisnis sekaligus memberikan nilai
bisnis tambahan pada setiap tahapan.

1. Rencana Migrasi Arsitektur

1. Rencana Migrasi
Masukkan Rencana Migrasi Arsitektur. Rencana ini harus membahas pendekatan keseluruhan terhadap
implementasi arsitektur baru dan melengkapi rincian yang tertulis di bagian 6 Implementasi dan Migrasi.
Contoh jenis informasi yang dapat ditemukan di sini adalah:
● urutan migrasi
● kebutuhan infrastruktur baru
● daftar potensi penghentian teknologi atau infrastruktur yang disebabkan oleh rencana ini
● dampak bisnis
● rencana migrasi data
2. Daftar Ketergantungan
Bagian ini harus berisi semua ketergantungan rencana dari bagian di atas. Semua masalah dan risiko
yang teridentifikasi harus dikelola melalui proses manajemen risiko dan masalah [Perusahaan].
Semua Asumsi dari rencana dan ketergantungan ini harus dicantumkan di bagian Resiko dan Asumsi
Arsitektur.

2. GLOSARIUM

Istilah / Akronim Definisi / Perluasan / Deskripsi

Data Tabel Data Tabel

10. Tabel 9 - Glosarium

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 Persyaratan fungsional
1. Persyaratan – [Judul Fungsi 1]

Judul

BR-FID 99 J Prioritas 1 Fase 9

u
m
a
t

Alur Lang
Peristiwa kah-
langk
ah
persy
arata
n.
Gam
bark
an
dafta
r
terse
but
seba
gai
dafta
r
berp
oin/b
erno
mor
Sasaran hasil
dari
rang
kaian
tinda
kan
ini,
misal
nya
Peng
guna
Masu
k ke
Solu
si
Sub- FID
fungsi,
Judu
l
Asumsi Asu
msi
apa
pun
yang

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 berla
ku
dala
m
pelak
sana
an
fungs
i,
misal
nya:
Peng
guna
suda
h
terda
ftar
atau
masu
k.
Solu
sinya
akan
men
gakui
hak
masi
ng-
masi
ng
indivi
du.
Jika
peng
guna
tidak
dapa
t
diide
ntifik
asi,
solus
inya
akan
mem
beri
tahu
admi
n.
Solu
sinya
secar
a
otom
atis
meny
impa
n
peng
atura
n
sesi.

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

Pra- Apa
kondisi persy
arata
n
agar
diagr
am
alur
ini
dapa
t
berjal
an,
dafta
r
kondi
si
yang
haru
s ada
sebel
um
pros
es
dapa
t
dijala
nkan,
misal
nya:
Peng
guna
memi
liki
sesi
drift
yang
seda
ng
berjal
an
dan
telah
men
gaks
es
solus
inya.
Peng
guna
memi
liki
hak
akse
s.
Peng
guna
telah
ditam
bahk
an ke
dafta
r

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 peng
guna
….dll
.
Ketentua Baga
n iman
Posting a
kead
aan
solus
inya
setel
ah
pros
es
berjal
an
misal
:
Peng
guna
mem
puny
ai
akse
s
terha
dap
aplik
asi
sesu
ai
deng
an
hak
istim
ewan
ya
Antarmu Refer
ka ensi
penggun ke
a proto
tipe
UI
atau
layar
terte
ntu
dan
catat
an
terkai
t UI
Peratura Kond
n bisnis isi
apa
yang
berla
ku
untuk
fungs
i

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 terse
but?
Peng
etah
uan
atau
algori
tma
atau
atura
n
valid
asi
khus
us
dom
ain
apa
pun
(rele
van
deng
an
kasu
s
peng
guna
an
ini),
misal
nya.
Setel
ah
tiga
kali
gagal
saat
masu
k,
solus
inya
akan
men
gunci
peng
guna
dan
mem
beri
tahu
admi
n
siste
m.
Diagram Ini
Alir atau opsio
Proses nal.
Terkait Cant
umka
n
semu
a

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 Diagr
am
Alir,
serta
kan,
perlu
as,
atau
khus
uska
n
Diagr
am
Alir
ini
atau
Diagr
am
Alir
terkai
t
Masalah Klarif
ikasi
diperl
ukan
dari
peng
guna
.
Setia
p
perta
nyaa
n
terkai
t
deng
an
Diagr
am
Alir
Referens Pers
i yarat
an #,
Doku
men,
Oran
g
Catatan Catat
an
apa
pun
yang
dapa
t
mem
bant
u
mem
perjel
as
pros

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 es
dan
infor
masi
atau
opsi
yang
terse
dia
untuk
peny
elesa
ian
tugas
.
Misal
:
nam
a
peng
guna
dan
kata
sandi
akan
sama
deng
an
akun
staf
mere
ka.
Tabel 10 - Persyaratan Fungsional

Grid di atas akan digunakan untuk setiap fungsi yang diidentifikasi.

Jika perlu, salin diagram alur dari BRD ke bagian dokumen ini.

2. Keluaran
3. Layar
4. Laporan
5. Persyaratan – [Judul Fungsi 2]

Judul

BR-FID 99 J Prioritas 1 Fase 9

u
m
a
t

Alur Lang
Peristiwa kah-
langk
ah
persy
arata

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 n.
Gam
bark
an
dafta
r
terse
but
seba
gai
dafta
r
berp
oin/b
erno
mor
Sasaran hasil
dari
rang
kaian
tinda
kan
ini,
misal
nya
Peng
guna
Masu
k ke
Solu
si
Sub- FID
fungsi,
Judu
l
Asumsi Asu
msi
apa
pun
yang
berla
ku
dala
m
pelak
sana
an
fungs
i,
misal
nya:
Peng
guna
suda
h
terda
ftar
atau
masu
k.
Solu
sinya

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 akan
men
gakui
hak
masi
ng-
masi
ng
indivi
du.
Jika
peng
guna
tidak
dapa
t
diide
ntifik
asi,
solus
inya
akan
mem
beri
tahu
admi
n.
Solu
sinya
secar
a
otom
atis
meny
impa
n
peng
atura
n
sesi.
Pra- Apa
kondisi persy
arata
n
agar
diagr
am
alur
ini
dapa
t
berjal
an,
dafta
r
kondi
si
yang
haru
s ada
sebel
um

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 pros
es
dapa
t
dijala
nkan,
misal
nya:
Peng
guna
memi
liki
sesi
drift
yang
seda
ng
berjal
an
dan
telah
men
gaks
es
solus
inya.
Peng
guna
memi
liki
hak
akse
s.
Peng
guna
telah
ditam
bahk
an ke
dafta
r
peng
guna
….dll
.
Ketentua Baga
n iman
Posting a
kead
aan
solus
inya
setel
ah
pros
es
berjal
an
misal
:
Peng
guna

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 mem
puny
ai
akse
s
terha
dap
aplik
asi
sesu
ai
deng
an
hak
istim
ewan
ya
Antarmu Refer
ka ensi
penggun ke
a proto
tipe
UI
atau
layar
terte
ntu
dan
catat
an
terkai
t UI
Peratura Kond
n bisnis isi
apa
yang
berla
ku
untuk
fungs
i
terse
but?
Peng
etah
uan
atau
algori
tma
atau
atura
n
valid
asi
khus
us
dom
ain
apa
pun
(rele
van

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 deng
an
kasu
s
peng
guna
an
ini),
misal
nya.
Setel
ah
tiga
kali
gagal
saat
masu
k,
solus
inya
akan
men
gunci
peng
guna
dan
mem
beri
tahu
admi
n
siste
m.
Diagram Ini
Alir atau opsio
Proses nal.
Terkait Cant
umka
n
semu
a
Diagr
am
Alir,
serta
kan,
perlu
as,
atau
khus
uska
n
Diagr
am
Alir
ini
atau
Diagr
am
Alir
terkai
t

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

Masalah Klarif
ikasi
diperl
ukan
dari
peng
guna
.
Setia
p
perta
nyaa
n
terkai
t
deng
an
Diagr
am
Alir
Referens Pers
i yarat
an #,
Doku
men,
Oran
g
Catatan Catat
an
apa
pun
yang
dapa
t
mem
bant
u
mem
perjel
as
pros
es
dan
infor
masi
atau
opsi
yang
terse
dia
untuk
peny
elesa
ian
tugas
.
Misal
:
nam
a
peng
guna

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 dan
kata
sandi
akan
sama
deng
an
akun
staf
mere
ka.
Tabel 11 - Persyaratan Fungsional

Grid di atas akan digunakan untuk setiap fungsi yang diidentifikasi.

Jika perlu, salin diagram alur dari BRD ke bagian dokumen ini.

6. Keluaran
7. Layar
11. Laporan

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 masukan
1. Data
2. Aplikasi
12. Pihak ketiga

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 Desain
1. Warna
2. Lihat dan rasakan
3. Masalah Kegunaan
13. Hadirin

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

 Pertunjukan
14. Uraikan kemampuan kinerja dan kendala solusi.

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

Migrasi dan Konversi Data
15. Jika suatu aplikasi akan dimodifikasi, tunjukkan di sini jika ada konversi data yang diperlukan pada
catatan data yang ada. Jika aplikasi baru menggantikan aplikasi yang sudah ada, tunjukkan di sini
migrasi/konversi data apa yang diperlukan

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

LAMPIRAN
Buat daftar dokumen-dokumen yang akan berguna bagi pembaca Dokumen Desain Arsitektur

1. Definisi
Kata-kata, akronim dan singkatan berikut diacu dalam dokumen ini.
Ketentuan Definisi

Tabel 12 - Definisi

2. Lampiran

Nomor dokumen Judul

16. Tabel 13 - Lampiran

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]

Daftar tanda tangan

Pimpinan Proyek _____________________ ____/____/______

[Judul Posisi]

Konsultan _____________________ ____/____/______

[Judul Posisi]

xxxxx _____________________ ____/____/______

[Judul Posisi]

XXXXX _____________________ ____/____/______

(Manajemen Pembangunan)

[Perusahaan] Halaman 22 dari 22 SDD – [Klien / Proyek]