Narasi Use Case (Use case Narative)

3.3. Fase Analisis Kebutuhan

3.3.3 Narasi Use Case (Use case Narative)

Bagian ini menjelaskan mengenai langkah-langkah kegiatan dalam setiap

use case.

Tabel 5 Narasi Use Case Mengkonfigurasi Server

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: konfigurasi Server Jenis Use case

Business Requirements: ฀

Use case ID: SCO-001

Priority : High

Source:

-Primary

Business Actor:

Penjual

Decription: Use case ini menggambarkan proses konfigurasi server untuk

melayani transaksi pulsa.

Precondition:

-Trigger: Use case ini digunakan apabila penjual akan mengkonfigurasi

sistem.

Typical Course

of event:

Actor Action System Response

Step 1: penjual memanggil

halaman utama server

Step 3: memanggil halaman

konfigurasi server

Step 4: Penjual memilih

setingan-setingan yang sesuai

dengan hardware.

Step 5: Penjual menekan

tombol ”START” untuk

menjalankan server

Step 2: Sistem menampilkan

halaman utama server.

Step 4: Sistem menampilkan

halaman konfigurasi sistem

Step 6: Sistem menjalankan

server

Alternate

Course:

Alt-step 4: Penjual menekan tombol “BATAL” sehingga keluar

dari menu setting server.

Conclusion: Sistem akan berjalan apabila pengaturan software sesuai dengan

hardware yang digunakan

Post Condition: Penjual berhasil men-setting server

Business Rules:

-Implementation

Constrains and

Specifications:

Tabel 6 Narasi Use Case Tambah pelanggan

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Tambah Pelanggan Jenis Use case

Business Requirements: ฀

Use case ID: SCO-002

Priority : High

Source:

-Primary

Business Actor:

Penjual

Decription: Use case ini menggambarkan proses menambah pelanggan baru.

Precondition:

-Trigger: Use case ini digunakan apabila penjual ingin menambah

pelanggan baru

Typical Course

of event:

Actor Action System Response

Step 1: penjual memanggil

menu data pelanggan

Step 3: penjual memanggil

menu tambah pelanggan

Step 5: Penjual memasukkan

data pelanggan

Step 6: Penjual menekan

tombol ”TAMBAH”

Step 2: Sistem menampilkan

menu data pelanggan

Step 4: Sistem menampilkan

menu tambah pelanggan

Step 7: Sistem menyimpan

data pelanggan ke database

Step 8: Sistem pelanggani

konfirmasi bahwa data

pelanggan berhasil dimasukan.

Alternate

Course:

Alt-step 6: Penjual menekan tombol “BATAL” sehingga

dilakukan pembatalan proses tambah pelanggan

Alt-step 7: Apabila data yang dimasukan tidak sesuai format

yang ditentukan maka muncul pesan gagal.

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Penjual berhasil memasukan data pelanggan baru

Penjual gagal memasukan data pelanggan dan kembali ke

formpengisian data pelanggan.

Business Rules:

-Implementation

Constrains and

Specifications:

Tabel 7 Narasi Use Case Tambah Saldo

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Tambah Saldo Jenis Use case

Business Requirements: ฀

Use case ID: SCO-003

Priority : High

Source:

-Primary

Business Actor:

Penjual

Decription: Use case ini menggambarkan proses menambah pelanggan baru.

Precondition:

-Trigger: Use case ini digunakan apabila penjual ingin menambah

pelanggan baru

Typical Course

of event:

Actor Action System Response

Step 1: penjual memanggil

menu tambah saldo

Step 3: memilih pelanggan

yang akan ditambah saldo dan

penjual menambah saldo

pelanggan

Step 4: Penjual menekan

tombol ”TAMBAH”

Step 2: Sistem menampilkan

menu tambah saldo

Step 5: Sistem menyimpan

data saldo ke database

Step 6: Sistem pelanggani

konfirmasi bahwa saldo

pelanggan berhasil

ditambahkan.

Alternate

Course:

Alt-step 4: Penjual menekan tombol “BATAL” sehingga

dilakukan pembatalan proses tambah saldo pelanggan

Alt-step 5: Apabila data yang dimasukan tidak sesuai format

yang ditentukan maka muncul pesan gagal.

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Penjual berhasil menambahkan saldo pelanggan

Penjual gagal menambahkan saldo pelanggan dan masuk ke

halaman utama sistem.

Business Rules:

-Implementation

Constrains and

Specifications:

Tabel 8 Narasi Use Case Edit pelanggan

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Edit Pelanggan Jenis Use case

Business Requirements: ฀

Use case ID: SCO-004

Priority : High

Source:

-Primary

Business Actor:

Penjual

Decription: Use case ini menggambarkan proses mengedit data pelanggan.

Precondition:

-Trigger: Use case ini digunakan apabila penjual ingin mengedit data

pelanggan.

Typical Course

of event:

Actor Action System Response

Step 1: penjual memanggil

menu data pelanggan

Step 3: penjual memanggil

menu editpelanggan

Step 5: Penjual memilih

pelanggan yang ingin di-edit

Step 6: Penjual memasukkan

data pelanggan ter-edit

Step 7: Penjual menekan

tombol ”EDIT”

Step 2: Sistem menampilkan

menu data pelanggan.

Step 4: Sistem menampilkan

menu editdata pelanggan.

Step 8: Sistem menyimpan

data pelanggan ter-edit ke

database

Step 9: Sistem pelanggani

konfirmasi bahwa data

pelanggan berhasil di-edit.

Alternate

Course:

Alt-step 6: Penjual menekan tombol “BATAL” sehingga

dilakukan pembatalan proses editdata pelanggan

Alt-step 7: Apabila data yang dimasukan tidak sesuai format

yang ditentukan maka muncul pesan gagal.

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Penjual berhasil mengedit data pelanggan.

Penjual gagal mengedit data pelanggan dan masuk ke form

editdata pelanggan.

Business Rules:

-Implementation

Constrains and

Specifications:

Tabel 9 Narasi Use Case Hapus pelanggan

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Hapus Pelanggan Jenis Use case

Business Requirements: ฀

Use case ID: SCO-005

Priority : High

Source:

-Primary

Business Actor:

Penjual

Decription: Use case ini menggambarkan proses menghapus data pelanggan.

Precondition:

-Trigger: Use case ini digunakan apabila penjual ingin menghapus data

pelanggan.

Typical Course

of event:

Actor Action System Response

Step 1: penjual memanggil

menu data pelanggan

Step 3: Penjual memilih data

pelanggan yang akan dihapus.

Step 4: Penjual menekan

tombol ”HAPUS”

Step 6: Penjual menekan

tombol ”YES”

Step 2: Sistem menampilkan

menu data pelanggan.

Step 5: Sistem menampilkan

konfirmasi hapus pelanggan.

Step 7: Sistem menghapus

data pelanggan dari database

Step 8: Sistem pelanggani

konfirmasi bahwa data

pelanggan berhasil dihapus.

Alternate

Course:

Alt-step 6: Penjual menekan tombol “NO” sehingga dilakukan

pembatalan proses hapus data pelanggan

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Penjual berhasil menhapus data pelanggan.

Penjual batal menghapus data pelanggan dan masuk ke

halaman utama sistem.

Business Rules:

-Implementation

Constrains and

Specifications:

Tabel 10 Narasi Use Case Tambah data pulsa

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Tambah Data Pulsa Jenis Use case

Business Requirements: ฀

Use case ID: SCO-006

Priority : High

Source:

-Primary

Business Actor:

Penjual

Decription: Use case ini menggambarkan proses menambah data pulsa baru.

Precondition:

-Trigger: Use case ini digunakan apabila penjual ingin menambah data

pulsa baru

Typical Course

of event:

Actor Action System Response

Step 1: penjual memanggil

menu data pulsa

Step 3: penjual memanggil

menu tambah pulsa

Step 5: Penjual memasukkan

data pulsa

Step 6: Penjual menekan

tombol ”TAMBAH”

Step 2: Sistem menampilkan

menu data pulsa

Step 4: Sistem menampilkan

menu tambah pulsa baru

Step 7: Sistem menyimpan

data pulsa ke database

Step 8: Sistem pelanggani

konfirmasi bahwa data pulsa

berhasil dimasukan.

Alternate

Course:

Alt-step 6: Penjual menekan tombol “BATAL” sehingga

dilakukan pembatalan proses tambah pulsa

Alt-step 7: Apabila data yang dimasukan tidak sesuai format

yang ditentukan maka muncul pesan gagal.

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Penjual berhasil memasukan data pulsa baru

Penjual gagal memasukan data pulsa dan masuk ke halaman

utama sistem.

Business Rules:

-Implementation

Constrains and

Specifications:

Tabel 11 Narasi Use Case Edit data pulsa

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Edit Data Pulsa Jenis Use case

Business Requirements: ฀

Use case ID: SCO-007

Priority : High

Source:

-Primary

Business Actor:

Penjual

Decription: Use case ini menggambarkan proses meng-editdata pulsa.

Precondition:

-Trigger: Use case ini digunakan apabila penjual ingin mengedit data

pulsa.

Typical Course

of event:

Actor Action System Response

Step 1: penjual memanggil

menu data pulsa

Step 3: penjual memanggil

menu editpulsa

Step 5: Penjual memilih data

pulsa yang ingin di-edit

Step 6: Penjual memasukkan

data pulsa ter-edit

Step 7: Penjual menekan

tombol ”EDIT”

Step 2: Sistem menampilkan

menu data pulsa.

Step 4: Sistem menampilkan

menu editdata pulsa.

Step 8: Sistem menyimpan

data pulsa ter-editke database

Step 9: Sistem memberi

konfirmasi bahwa data pulsa

berhasil di-edit.

Alternate

Course:

Alt-step 6: Penjual menekan tombol “BATAL” sehingga

dilakukan pembatalan proses editdata pulsa

Alt-step 8: Apabila data yang dimasukan tidak sesuai format

yang ditentukan maka muncul pesan gagal.

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Penjual berhasil meng-editdata pulsa.

Penjual gagal meng-edit data pulsa dan masuk ke halaman

utama sistem.

Business Rules:

-Implementation

Constrains and

Specifications:

Tabel 12 Narasi Use Case Hapus data pulsa

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Hapus Data Pulsa Jenis Use case

Business Requirements: ฀

Use case ID: SCO-008

Priority : High

Source:

-Primary

Business Actor:

Penjual

Decription: Use case ini menggambarkan proses menghapus data pulsa.

Precondition:

-Trigger: Use case ini digunakan apabila penjual ingin menghapus data

pulsa.

Typical Course

of event:

Actor Action System Response

Step 1: penjual memanggil

menu data pulsa

Step 3: Penjual memilih data

pulsa yang akan dihapus.

Step 4: Penjual menekan

tombol ”HAPUS”

Step 6: Penjual menekan

tombol ”YES”

Step 2: Sistem menampilkan

menu data pulsa.

Step 5: Sistem menampilkan

konfirmasi hapus.

Step 7: Sistem menghapus

data pulsa dari database

Step 8: Sistem memberi

konfirmasi bahwa data pulsa

berhasil dihapus.

Alternate

Course:

Alt-step 6: Penjual menekan tombol “NO” sehingga dilakukan

pembatalan proses hapus data pulsa

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Penjual berhasil menhapus data pulsa.

Penjual batal menghapus data pulsa dan masuk ke halaman

utama sistem.

Business Rules:

-Implementation

Constrains and

Specifications:

Tabel 13 Narasi Use Case Batalkan Transaksi

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Batalkan Transaksi Jenis Use case

Business Requirements: ฀

Use case ID: SCO-009

Priority : High

Source:

-Primary

Business Actor:

Penjual

Decription: Use case ini menggambarkan proses menghapus data pesan.

Precondition:

-Trigger: Use case ini digunakan apabila penjual ingin menghapus data

pesan.

Typical Course

of event:

Actor Action System Response

Step 1: penjual memanggil

menu data status pengiriman.

Step 3: Penjual memilih data

pesan yang akan dibatalkan.

Step 4: Penjual menekan

tombol ”BATALKAN

TRANSAKSI”

Step 6: Penjual menekan

tombol ”YES”

Step 2: Sistem menampilkan

menu data status pengiriman.

Step 5: Sistem menampilkan

konfirmasi batalkan transaksi.

Step 7: Sistem membatalkan

transaksi

Step 8: Sistem memberi

konfirmasi bahwa transaksi

berhasil dibatalkan

Alternate

Course:

Alt-step 6: Penjual menekan tombol “NO” sehingga dilakukan

pembatalan proses batalkan transaksi.

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Penjual berhasil membatalkan transaksi.

Penjual batal membatalkan transaksi.

Business Rules:

-Implementation

Constrains and

Specifications:

Tabel 14 Narasi Use Case Hapus Semua Pesan

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Hapus Semua Pesan Jenis Use case

Business Requirements: ฀

Use case ID: SCO-010

Priority : High

Source:

-Primary

Business Actor:

Penjual

Decription: Use case ini menggambarkan proses menghapus data pesan.

Precondition:

-Trigger: Use case ini digunakan apabila penjual ingin menghapus data

pesan.

Typical Course

of event:

Actor Action System Response

Step 1: penjual memanggil

menu data status pengiriman.

Step 3: Penjual menekan

tombol ”HAPUS SEMUA

PESAN”

Step 5: Penjual menekan

tombol ”YES”

Step 2: Sistem menampilkan

menu data status pengiriman.

Step 4: Sistem menampilkan

konfirmasi hapus pesan status

pengiriman.

Step 6: Sistem menghapus

data inbox dari database

Step 7: Sistem memberi

konfirmasi bahwa data status

transaksi berhasil dihapus.

Alternate

Course:

Alt-step 5: Penjual menekan tombol “NO” sehingga dilakukan

pembatalan proses hapus data status transaksi

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Penjual berhasil menghapus data transaksi.

Penjual batal menghapus data trasaksi

Business Rules:

-Implementation

Constrains and

Specifications:

Tabel 15 Narasi Use kirim SMS

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Kirim SMS Jenis Use case

Business Requirements: ฀

Use case ID: SCO-011

Priority : High

Source:

-Primary

Business Actor:

Penjual

Decription: Use case ini menggambarkan proses mengirim sms ke

pelanggan.

Precondition:

-Trigger: Use case ini digunakan apabila penjual ingin mengirim sms ke

pelanggan.

Typical Course

of event:

Actor Action System Response

Step 1: penjual membuka

menu kirim sms.

Step 3: Penjual memasukkan

pesan yang akan dikirim.

Step 4: Penjual memilih

pelanggan yang akan dikirimi

pesan

Step 5: Penjual menekan

tombol ”KIRIM”

Step 2: Sistem menampilkan

menu kirim sms.

Step 5: Sistem mengirim pesan

ke pelanggan yang dimaksud

Step 6: Sistem memberi

konfirmasi bahwa pesan telah

dikirim.

Alternate

Course:

Alt-step 4: Penjual menekan tombol “BATAL” sehingga

dilakukan pembatalan pengiriman pesan.

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Penjual berhasil mengirim sms kepada pelanggan

Business Rules:

-Implementation

Constrains and

Specifications:

Tabel 16 Narasi Use Case Buat Laporan Pelanggan

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Buat Laporan Pelanggan Jenis Use case

Business Requirements: ฀

Use case ID: SCO-012

Priority : High

Source:

Primary

Business Actor:

Penjual

Decription: Use caseini menggambarkan proses cetak laporan pelanggan

Precondition:

-Trigger: Use case ini dilakukan apabila penjual ingin mencetak laporan

transaksi pelanggan

Typical Course

of event:

Actor Action System Response

Step 1: penjual membuka

menu cetak laporan pelanggan

Step 3 : penjual memilih

waktu dan nama pelanggan

yang akan dicetak

Step 4 : penjual menekan

tombol cetak laporan

Step 2: sistem menampilkan

menu cetak pelanggan

Step 5 : sistem menampilkan

halaman laporan.

Alternate

Course:

Conclusion: .

Post Condition: Penjual berhasil mencetak laporan transaksi sicho cell

Business Rules: Penjual harus memasukan data dengan tipe yang sesuai

Implementation

Constrains and

Specifications:

Tabel 17 Narasi Use Case Buat Laporan Sicho Cell

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Buat Laporan Sicho Cell Jenis Use case

Business Requirements: ฀

Use case ID: SCO-013

Priority : High

Source:

Primary

Business Actor:

Penjual

Decription: Use caseini menggambarkan proses cetak laporan sicho cell

Precondition:

-Trigger: Use case ini dilakukan apabila penjual ingin mencetak laporan

transaksi sicho cell

Typical Course

of event:

Actor Action System Response

Step 1: penjual membuka

menu cetak laporan sicho cell

Step 3 : penjual memilih

waktu transaksi yang akan

dicetak

Step 4 : penjual menekan

tombol cetak laporan

Step 2: sistem menampilkan

menu cetak sicho cell

Step 5 : sistem menampilkan

halaman laporan.

Alternate

Course:

Conclusion: .

Post Condition: Penjual berhasil mencetak laporan sicho cell

Business Rules: Penjual harus memasukan data dengan tipe yang sesuai

Implementation

Constrains and

Specifications:

Tabel 18 Narasi Use Case Lihat daftar harga

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Lihat Daftar Harga Jenis Use case

Business Requirements: ฀

Use case ID: SCO-014

Priority : High

Source:

-Primary

Business Actor:

Pelanggan

Decription: Use case ini menggambarkan proses melihat daftar harga pulsa

Precondition: pelanggan telah terdaftar sebelumnya.

Trigger: Use case ini digunakan apabila pelanggan ingin melihat daftar

harga pulsa

Typical Course

of event:

Actor Action System Response

Step 1: pelanggan

mengirimkan SMS melihat

daftar harga pulsa. Step 2: Sistem mengecek

apakah SMS berasal dari

pelanggan yang tepat dan

sesuai format atau tidak

Step 3: Sistem mengirim SMS

ke pelanggan dengan isi daftar

harga pulsa.

Alternate

Course:

Alt-step 3: Apabila SMS berasal dari orang yang tidak

berkepentingan atau format salah maka Sistem mengirim SMS

konfirmasi kesalahan.

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Pelanggan mendapatkan SMS berisi daftar harga pulsa.

Business Rules: Pelanggan mengirim SMS dengan format yang benar

Implementation

Constrains and

Specifications:

 Harus dapat diakses setiap saat

Tabel 19 Narasi Use Case Cek saldo

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Cek Saldo Jenis Use case

Business Requirements: ฀

Use case ID: SCO-015

Priority : High

Source:

-Primary

Business Actor:

Pelanggan

Decription: Use case ini menggambarkan proses melihat sisa saldo dari

Pelanggan

Precondition: pelanggan telah terdaftar sebelumnya.

Trigger: Use case ini digunakan apabila pelanggan ingin melihat sisa

saldo dari pelanggan.

Typical Course

of event:

Actor Action System Response

Step 1: pelanggan

mengirimkan SMS melihat

saldo. Step 2: Sistem mengecek

apakah SMS berasal dari

pelanggan yang tepat dan

sesuai format atau tidak

Step 3: Sistem mengirim SMS

ke pelanggan dengan isi saldo

yang dimiliki oleh pelanggan.

Alternate

Course:

Alt-step 3: Apabila SMS berasal dari orang yang tidak

berkepentingan atau format salah maka Sistem mengirim SMS

konfirmasi kesalahan.

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Pelanggan mendapatkan SMS berisi saldo yang masih dimiliki

oleh pelanggan.

Business Rules: Pelanggan mengirim SMS dengan format yang benar

Implementation

Constrains and

Specifications:

 Harus dapat diakses setiap saat

Tabel 20 Narasi Use Case Isi pulsa

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Isi Pulsa Jenis Use case

Business Requirements: ฀

Use case ID: SCO-016

Priority : High

Source:

-Primary

Business Actor:

Pelanggan

Decription: Use case ini menggambarkan proses pengisian pulsa oleh

pelanggan.

Precondition: pelanggan telah terdaftar sebelumnya.

Trigger: Use caseini digunakan apabila pelanggan ingin mengirim pulsa

ke nomor handphone yang dimaksud.

Typical Course

of event:

Actor Action System Response

Step 1: pelanggan

mengirimkan SMS mengisi

pulsa ke nomor handphone

tertentu. Step 2: Sistem mengecek

apakah SMS berasal dari

pelanggan yang tepat dan

sesuai format atau tidak

Step 3: Sistem melakukan

proses pengisian pulsa.

Step 4: Sistem memberi

konfirmasi berupa SMS ke

pelanggan bahwa proses

pengisian telah dilakukan.

Alternate

Course:

Alt-step 3: Apabila SMS berasal dari orang yang tidak

berkepentingan atau format salah maka Sistem mengirim SMS

konfirmasi kesalahan.

Alt-step 4: Sistem memberi konfirmasi bahwa pengisian pulsa

gagal.

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition:  Pelanggan mendapatkan SMS berisi pesan bahwa proses

pengisian pulsa berhasil

 Pelanggan mendapatkan SMS berisi pesan bahwa proses

pengisian pulsa gagal.

Business Rules: Pelanggan mengirim SMS dengan format yang benar

Implementation

Constrains and

Specifications:

 Harus dapat diakses setiap saat

Tabel 21 Narasi Use Case Ganti PIN

Author : Hendri Cahyana Date : 11 November 2008

Version : 1.0

Use case Name: Ganti PIN Jenis Use case

Business Requirements: ฀

Use case ID: SCO-017

Priority : High

Source:

-Primary

Business Actor:

Pelanggan

Decription: Use case ini menggambarkan proses pelanggan merubah PIN

lamanya dengan PI N baru

Precondition: pelanggan telah terdaftar sebelumnya.

Trigger: Use case ini digunakan apabila pelanggan ingin mengganti PIN

lama dengan PIN baru.

Typical Course

of event:

Actor Action System Response

Step 1: pelanggan

mengirimkan SMS ganti PIN.

Step 2: Sistem mengecek

apakah SMS berasal dari

pelanggan yang tepat dan

sesua format atau tidak

Step 3: Sistem merubah PI

pelanggan dan mengirimkan

konfirmasi bahwa PI berhasil

dirubah.

Alternate

Course:

Alt-step 3: Apabila SMS berasal dari orang yang tidak

berkepentingan atau format salah maka Sistem mengirim SMS

konfirmasi kesalahan.

Conclusion: Sistem hanya akan menerima inputan data yang sesuai untuk

tiap-tiap pemrosesan data.

Post Condition: Pelanggan berhasil merubah PIN pelanggan tersebut.

Business Rules: Pelanggan mengirim SMS dengan format yang benar

Implementation

Constrains and

Specifications:

 Harus dapat diakses setiap saat

3.4. Fase Desain Logikal (Logical Design Phase)