Transcript Software Requirements

Software Requirements
Software Requirements - adopted & adapted from I.
Sommerville, 2004
Tujuan
• Memperkenalkan konsep kebutuhan sistem dan user
• Menjelaskan kebutuhan fungsional dan non fungsional
• Menjelaskan bagaimana kebutuhan perangkat lunak di
organisasikan pada dokumentasi perangkat lunak
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Topik
•
•
•
•
•
Functional and non-functional requirements
User requirements
System requirements
Interface specification
The software requirements document
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Rekayasa Kebutuhan
• Proses memberikan layanan mengenai apa yang
dibutuhkan customer dari sebuah sistem dan semua
kendalanya ketika dioperasikan dan dikembangkan
• Kebutuhan adalah deskripsi dari layanan sistem dan
kendalanya yang dihasilkan selama proses rekayasa
kebutuhan
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Apa itu kebutuhan ?
• Abstraksi High-level dari sebuah layanan dan kendala
atau batasan sistem sampai dengan kebutuhan
fungsional matematis
• Kebutuhan yang tidak dapat dihindari melayani fungsi
sebagai berikut :
– dasar Bid contract ( Open interpretation )
– Dasar dari isi kontrak itu sendiri ( detail )
– Statement diatas dapat disebut requirement
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Requirements abstraction (Davis)
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Tipe dari Requirement
• User requirements
– Persyaratan pengguna adalah pernyataan, biasanya dalam bahasa
natural (mis. Bahasa Inggris, Indonesia, dsb.) dan dapat ditambahkan
diagram, tentang layanan yang diharapkan untuk disediakan oleh sistem
dan tentang batasan operasi sistem tersebut
• System requirements
– Persyaratan sistem menjelaskan fungsi-fungsi sistem, layanan-layanan sistem,
dan batasan operasional sistem secara rinci. Dokumen persyaratan sistem
(kadang-kadang disebut dengan spesifikasi fungsional) seharusnya tepat dan
teliti. Dia semestinya mendefinisikan secara pasti apa yang akan
diimplementasikan. Dia bisa menjadi bagian dari kontrak antara pembeli sistem
dan pengembang sistem.
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Pembaca Requirements
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Definisi dan spesifikasi
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Requirement fungsional dan non fungsional
•
Persyaratan Fungsional
–
•
Persyaratan Non-fungsional
–
•
pernyataan-pernyataan tentang layanan yang harus disediakan sistem, bagaimana seharusnya sistem
bereaksi terhadap masukan tertentu, dan bagaimana seharusnya sistem berperilaku dalam situasisituasi tertentu. Pada beberapa kasus, pernyataan fungsional dapat juga menyatakan secara eksplisit
apa yang tidak seharusnya dikerjakan oleh sistem.
Ini adalah batasan-batasan (constraints) pada layanan atau fungsi yang disediakan oleh sistem. Mereke
meliputi batasan waktu (timing constraints), batasan pada proses pengembangan dan standar yang
digunakan. Persyaratan non-fungsional sering berlaku pada sistem secara keseluruhan. Mereka tidak
biasanya hanya berlaku pada fitur atau layanan tertentu secara individu.
Persyaratan Domain
–
Ini adalah persyaratan yang berasal dari domain aplikasi dari sistem dan mencerminkan karakteristik dan
batasan-batasan domain tersebut. Ketika dijabarkan, persyaratan domain dapat berupa persyaratan
fungsional ataupun persyaratan non-fungsional.
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Kebutuhan fungsional
• Menjelaskan fungsionalitas atau layanan sistem
• Tergantung dari tipe software,user yang diharapkan dan
tipe dari sistem dimana software akan digunakan
• Fungsional user requirement dapat berupa statement
high level tapi fungsional sistem requirement harus
dijabarkan layanan dari sistem tersebut secara detail
Software Requirements - adopted & adapted
from I. Sommerville, 2004
The LIBSYS system ( user requirement)
• Sistem perpustakaan yang menyediakan interface ke
beberapa database artikel pada perpustakaan lain.
• User dapat melakukan pencarian, download dan cetak
artikel tersebut untuk belajar personal
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Contoh system functional requirements
• User harus bisa melakukan search pada beberapa
kelompok database atau memilih salah satu nya.
• Sistem harus menyediakan “appropriate viewers” untuk
user ketika membaca document pada media
penyimpan document
• Setiap order harus dialokasikan sebuah Unique
identifier ( ORDER_ID) dimana user akan mampu untuk
mengkopi ke account media penyimpanan user
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Ketidak tepatan requirement
• Masalah muncul ketika kebutuhan tidak dijabarkan
secara tepat
• Kebutuhan yang bersifat ambigu di interprestasikan
berbeda antara pengembang dan pengguna
• Lihat kata pada slide 13 =‘appropriate viewers’
– Keinginan user- Viewer untuk beberapa macam
dokumen
– Interprestasi Developer – hanya menyediakan text
viewer yang menunjukkan isi dari dokument
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Kelengkapan dan konsistensi
requirement
• Pada prinsipnya, spesifikasi persyaratan fungsional seharusnya
lengkap dan konsisten.
• Kelengkapan (completeness) berarti seluruh layanan yang
dibutuhkan pengguna harus didefinisikan.
• Konsistensi (consistency) bermakna persyaratan-persyaratan
tidak boleh memiliki definisi-definisi yang kontradiktif.
• Pengaruh banyaknya stakeholders dapat menyebabkan
permasalahan ini muncul
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Non-functional requirements
• Persyaratan non-ungsional adalah persyaratan yang tidak secara langsung
terkait dengan fungsi-fungsi tertentu yang dimiliki oleh sistem.
• Persyaratan ini mendefinisikan properti dan batasan sistem, misalnya
reliability, waktu respon, dan persyaratan kapasitas penyimpanan.
• Persyaratan proses juga dapat dispesifikasikan untuk mengharuskan sistem
CASE, bahasa pemrograman, atau metode pengembangan tertentu.
• Persyaratan non-fungsional bisa lebih kritis daripada persyaratan fungsional.
Sebagai contoh, persyaratan keselamatan (safety) tertentu pada sistem
control pesawat terbang. Jika persyaratan ini tidak dipenuhi, sistem tidak
dapat atau tidak boleh digunakan.
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Klasifikasi Non-functional
• Product requirements
– Requirement yang menspesifikasikan perilaku produk harus berjalan dengan
syarat tertentu e.g kecepatan exekusi, reliabily dsb
• Organisational requirements
– Requirement yang memiliki konsekuensi terhadap aturan dan prosedur
organsasi .e.g SOP, implementasi , dsb
• External requirements
– Requirement yang muncul karena faktor dari external sistem dan proses
pengembangannya e.g Sistem harus beroperasi sesuai hukum ,dsb
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Tipe Non-functional requirement
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Contoh Non-functional requirements
• Product requirement
– Interface user pada LIBSYS harus dapat diimplemntasikan dengan HTLM tanpa frames
atau java Applets
• Organisational requirement
– Proses pengembangan sistem dan dokumen yang harus memenuhi
proses dan pengembangan yang didefiniskan pada
• External requirement
– Sistem harus tidak membuka seluruh informasi personal tentang customers selain nama
dan nomor referensi untuk operator sistem
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Goals dan requirements
• Nong-functional requirement mungkin akan sangat sulit untuk
dinyatakan secara tepat dan requirement yang tidak tepat akan
sangat sulit untuk di verifikasi
• Goal
– Maksud dari user secara umum  ex: kemudahan penggunaan
• Verifiable non-functional requirement
– Pernyataan yang menggunakan pengukuran tertentu yang dapat di tes secara
obyektif
• Goals sangat membantu pengembang ketika user menyampaikan
maksud dari sistem user
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Contoh
• A system goal
– Sistem harus mudah untuk digunakan dengan metode/penguna yang sudah
umum dan di organsiasikan sehingga kesalahan pengguna dapat
diminimalisasikan
• A verifiable non-functional requirement
– Pengguna yang sudah umum harus mampu untuk menggunakan semua fungsi
sistem setelah menempu 2 jam pelatihan. Setelah pelatihan, jumlah rata-rata
kesalahan yang dialami user harus tidak lebih dari 2 kesalahan per hari
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Pengukuran kebutuhan
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Interaksi requirement
• Konflik antara perbedaan requirement non-fungsional
pada sebuah sistem yang kompleks
• Spacecraft system
– Untuk mengurangi beban, jumlah dari chips harus
diminimalisasikan
– Untuk mengurangi konsumsi daya, chips yang hemat
daya harus digunakan
– Menggunakan low power chips artinya harus
memperbanyak jumlah chip . Mana requirement yang
lebih kritikal ?
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Domain requirements
• Diturunkan dari aplikasi domain dan menyjelaskan
karakteristik dan fitur yang merefleksikan domain
• Domain requirement akan menjadi fungsional
requirement yang baru, kendala pada requirement yang
existing atau mendefinisikan komputasi yang spesifik
• Jika domain requirement tidak dipenuhi, sistem
mungkin tidak dapat bekerja
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Library system domain requirements
• Harus ada user interface standar pada semua database
yang harus mengacu pada standar Z39.50
• Karena ada aturan copyright, dokument harus dihapus
segera setelah di ambil. Tergantung pada kebutuhan
user, dokumen ini akan di cetak, yang akan memforward user untuk menggunakan network printer di
LAN
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Train protection system
• Perlambatan kereta dihitung sebagai berikut :
Dtrain = Dcontrol + Dgradient
where Dgradient is 9.81ms2 * compensated
gradient/alpha and where the values of 9.81ms2
/alpha are known for different types of train.
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Masalah Domain requirements
• Understandability
– Requirement di ekspresikan dengan bahasa domain
tersebut berada
– Tidak dipahami oleh pengembang dari sistem
• Implicitness
– Domain spesialis memahami area tersebut secara detail
sehingga tidak berpikir untuk membuat domain
requirement lebih explicit
Software Requirements - adopted & adapted
from I. Sommerville, 2004
User requirements
• Harus menjelaskan fungsional dan non fungsional
requirement dengan cara tertentu yang membuat
pengguna sistem paham meski tidak memiliki
pengetahuan bidang tersebut secara detail
• User requirement didefinsikan menggunakan bahasa
naturalm tabel, dan diagram yang mudah dipahami
oleh semua
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Problems with natural language
• Ketidak jelasan
– Kejelasan sangat sulit tanpa harus membuat dokument
sangat sulit untuk dipahami
• Requirements confusion
– Fungsional dan non fungsional requirement sering
tercampur
Software Requirements - adopted & adapted
from I. Sommerville, 2004
LIBSYS requirement
4..5 LIBSYS shall provide a financial accounting system
that maintains records of all payments made by users of
the system. System managers may configure this system
so that regular users may receive discounted rates.
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Editor grid requirement
2.6 Grid facilities To assist in the positioning of entities on a
diagram, the user may turn on a grid in either centimetres or inches,
via an option on the control panel. Initially, the grid is off. The grid
may be turned on and off at any time during an editing session and
can be toggled between inches and centimetres at any time. A grid
option will be provided on the reduce-to-fit view but the number of
grid lines shown will be reduced to avoid filling the smaller diagram
with grid lines.
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Requirement problems
• Database requirement termasuk didalamnya konseptual dan
informasi yang detail
– Menjelaskan konsep dari accountung system yang termasuk dalam libsys
– Juga termasuk didalamnya detail dari manager yang mampu mengkonfigurasi
sistem yang harusnya tidak perlu pada level ini
• Grid requirement mixes three different kinds of requirement
– Conceptual functional requirement (the need for a grid);
– Non-functional requirement (grid units);
– Non-functional UI requirement (grid switching).
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Structured presentation
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Guidelines for writing requirements
• Temukan format standar dan gunakan pada semua
requirement
• Gunakan bahasa dengan konsisten. Gunakan ‘harus’
untuk requirement yang vital , sebaiknya untuk
kebutuhan yang diinginkan
• Text highlite untuk indentifikasi bagian kunci dari
requrement
• Hindari penggunakan jargon komputer
Software Requirements - adopted & adapted
from I. Sommerville, 2004
System requirements
• Spesifikasi yang lebih detail dari fungsi dan layanan
sistem, juga hambatan dari user requirement
• Dimaksudkan untuk menjadi dasar desain sistem
• Mungkin Tergabung dalam kontrak
• Sistem requirement mungkin dapat di ilustrasikan
menggunakan sistem model
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Requirements and design
• Prinsipnya, requirement harus menjabarkan apa yang
sistem harus lakukan dan desain harus menjelaskan
bagaimana sistem tersebut bekerja
• Prakteknya, requirement dan desain tidak dapat
dipisahkan
– Arsitektur sistem didesain berdasar struktur dari
requirement
– Penggunakan desain spesifik mungkin diambil dari
requirement domain
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Problems with NL specification
• Ambiguity
– The readers and writers of the requirement must
interpret the same words in the same way. NL is
naturally ambiguous so this is very difficult.
• Over-flexibility
– The same thing may be said in a number of different
ways in the specification.
• Lack of modularisation
– NL structures are inadequate to structure system
requirements.
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Alternatives to NL specification
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Structured language specifications
• Kebebeasan penulis requirement dibatasi oleh template
yang ditetapkan pada requirement
• Semua requirement dituliskan dengan menggunakan
standard
• Terminologi yang digunakan dibatasi
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Form-based specifications
•
•
•
•
Mendefinisikan fungsi atau entitas
Deskripsi input dan darimana mereka berasal
Deskripsi output dan kemana output tersebut pergi
Efek samping ( jika ada ) pada fungsi
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Form-based node specification
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Tabular specification
• Sebagai suplement dari NL
• Berguna ketika kita mendefinisikan jumlah dari
alternatif yang mungkin ada sebuah action
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Tabular specification
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Graphical models
• Berguna ketika kita ingin menunjukkan tingkat
berubahan dari beberapa actions
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Sequence diagrams
• Menunjukkan urutan dari event yang berjalan selama
user berinteraksi dengan sistme
• Membaca dari atas keb awah untuk melihat urutan dari
actions
• Cash withdrawal dari mesin ATM
– Validate card;
– Handle request;
– Complete transaction.
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Sequence diagram of ATM withdrawal
Software Requirements - adopted & adapted
from I. Sommerville, 2004
IEEE requirements standard
• Defines a generic structure for a requirements
document that must be instantiated for each specific
system.
– Introduction.
– General description.
– Specific requirements.
– Appendices.
– Index.
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Key points
• Requirements set out what the system should do and define
constraints on its operation and implementation.
• Functional requirements set out services the system should provide.
• Non-functional requirements constrain the system being developed
or the development process.
• User requirements are high-level statements of what the system
should do. User requirements should be written using natural
language, tables and diagrams.
Software Requirements - adopted & adapted
from I. Sommerville, 2004
Key points
• System requirements are intended to communicate
the functions that the system should provide.
• A software requirements document is an agreed
statement of the system requirements.
• The IEEE standard is a useful starting point for
defining more detailed specific requirements
standards.
Software Requirements - adopted & adapted
from I. Sommerville, 2004