Documentation Requirements

Persyaratan Dokumentasi

Pertemuan Minggu Kedua

Teaching Team (Tim Pengajar):
Deddy Kusbianto
Ahmadi Yuli Ananta
Elok Hamdana
Dhebys Suryani
Retno Damayanti
What are requirements?

• A specification of what should be implemented

• Defined at early stages of a system development
• Include:
• how the system should behave
• application domain information
• constraints on the system's operation
• specification of a system property or attribute.
Apa persyaratannya?

• Spesifikasi apa yang harus diterapkan

• Didefinisikan pada tahap awal pengembangan sistem
• Termasuk:
• bagaimana sistem seharusnya berperilaku
• informasi domain aplikasi
• kendala pada operasi sistem
• spesifikasi properti sistem atau atribut.
What is a requirements engineering process?

• Requirements engineering process is a structured set of

activities which are followed to derive, validate and maintain a
systems requirements document. The activities include:
• Requirements elicitation
• Requirements analysis and negotiation
• Requirements documentation
• Requirements validation
Apa itu proses rekayasa persyaratan?

• Proses rekayasa persyaratan adalah serangkaian kegiatan

terstruktur yang diikuti untuk memperoleh, memvalidasi, dan
memelihara dokumen persyaratan sistem. Kegiatannya
meliputi:
• Perolehan persyaratan
• Analisis persyaratan dan negosiasi
• Dokumentasi persyaratan
• Validasi persyaratan
Requirements elicitation techniques

• The system requirements are discovered through consultation with

stakeholders, from system documents, domain knowledge
• Other names are 'requirement acquisition' or 'requirement discovery‘
• Interviews
• Closed loop: interviewer looks for answers to a set of pre-defined
questions
• Open loop: there are no pre-defined agenda and discussion is
done in an open-ended way.
Persyaratan teknik perolehan

• Persyaratan sistem ditemukan melalui konsultasi dengan pemangku

kepentingan, dari dokumen sistem, pengetahuan domain
• Nama-nama lain adalah 'akuisisi persyaratan' atau 'penemuan
kebutuhan ‘
• Wawancara
• Loop tertutup: pewawancara mencari jawaban untuk serangkaian
pertanyaan yang telah ditentukan sebelumnya
• Open loop: tidak ada agenda yang telah ditentukan dan diskusi
dilakukan secara terbuka.
Scenarios
• Stories of how the system will be used
• End-users and other stakeholders find it easier to relate to real-life
examples rather than abstract descriptions of functions of a system
• They should at least include:
• Description of the state of the system before entering the scenario
• Normal flow of events in the scenario
• Exceptions to the normal flow of events
• Information about other activities which might be going at the
same time
• Description of the state of the system after the scenario
Skenario
• Kisah tentang bagaimana sistem akan digunakan
• Pengguna akhir dan pemangku kepentingan lainnya merasa lebih
mudah untuk berhubungan dengan contoh-contoh kehidupan nyata
daripada deskripsi abstrak dari fungsi suatu sistem
• Mereka setidaknya harus mencakup:
• Deskripsi kondisi sistem sebelum memasuki skenario
• Alur peristiwa normal dalam skenario
• Pengecualian untuk aliran peristiwa normal
• Informasi tentang kegiatan lain yang mungkin terjadi pada saat
bersamaan
• Deskripsi keadaan sistem setelah skenario
An example scenario
Scenario of ordering a report from a library:
• The user logs on the system
• The order document is issued
• The reference number of the document is entered
• A delivery option is selected
• The user logs out.
• Exception: if the reference number is incorrect, the user is
offered to enter the document reference or invoke the
system help.
Contoh skenario
Skenario pemesanan laporan dari perpustakaan:
• Catatan pengguna sistem
• Dokumen pengeluaran pesanan
• Nomor referensi dokumen yang dimasukkan
• Opsi pemilihan pengiriman
• Pengguna keluar.
• Pengecualian: jika nomor referensi salah, pengguna
ditawari untuk memasukkan referensi dokumen atau
meminta bantuan sistem.
Requirements Reuse
• A good practice to reuse as much knowledge as possible when
developing a new system
• Although requirements for each system is distinct, there are a number
of situations where reuse is possible:
• Where requirement is concerned with providing information about
the application domain, e.g. constraints on the system.
• Where the requirement is concerned with the style of presentation
of the information, like the user interface of the whole systems for
an organization.
• Where the requirements reflect company policies such as security
requirements.
Persyaratan Penggunaan Kembali
• Praktik yang baik untuk menggunakan kembali sebanyak mungkin
pengetahuan saat mengembangkan sistem baru
• Meskipun persyaratan untuk setiap sistem berbeda, ada beberapa
situasi di mana penggunaan kembali dimungkinkan:
• Di mana persyaratan berkaitan dengan penyediaan informasi
tentang domain aplikasi, mis. kendala pada sistem.
• Dimana persyaratannya berkaitan dengan gaya penyajian informasi,
seperti antarmuka pengguna dari keseluruhan sistem untuk suatu
organisasi.
• Dimana persyaratan mencerminkan kebijakan perusahaan seperti
persyaratan keamanan.
Prototyping
• An initial version of the system which is available early in the
development process
• Helps elicit and validate the system requirements
• 'throw-away' prototypes used to help elicit and analyze the requirements
are often called
• In contrast evolutionary prototypes are intended to deliver a workable
system quickly to the customer
• Prototypes help to establish the overall feasibility and usefulness of the
system
• The only effective way of developing system user interface.
• May be possible to be used in system tests later in the validation process
Prototyping
• Versi awal dari sistem yang tersedia di awal proses pengembangan
• Membantu memperoleh dan memvalidasi persyaratan sistem
• Prototipe 'membuang' yang digunakan untuk membantu memperoleh
dan menganalisis persyaratan sering disebut
• Sebaliknya, prototipe evolusioner dimaksudkan untuk memberikan sistem
yang bisa diterapkan dengan cepat kepada pelanggan
• Prototipe membantu menetapkan kelayakan dan kegunaan keseluruhan
sistem
• Satu-satunya cara efektif untuk mengembangkan antarmuka pengguna
sistem.
• Dimungkinkan untuk digunakan dalam pengujian sistem nanti dalam
proses validasi
Requirements analysis and negotiation

• Aim at discovering problems with the system requirements and reach

agreement on changes to satisfy all system stakeholders
• Requirements are analyzed in detail
• Different stakeholders negotiate to decide on which requirements
are to be accepted
• Since there are inevitably conflicts between the requirements from
different sources, information may be incomplete or may be
incompatible with the budget available
Analisis persyaratan dan negosiasi

• Bertujuan menemukan masalah dengan persyaratan sistem dan

mencapai kesepakatan tentang perubahan untuk memuaskan semua
pemangku kepentingan sistem
• Persyaratan dianalisis secara rinci
• Para pemangku kepentingan yang berbeda bernegosiasi untuk
memutuskan persyaratan mana yang harus diterima
• Karena ada konflik yang tidak dapat dihindari antara persyaratan dari
sumber yang berbeda, informasi mungkin tidak lengkap atau mungkin
tidak sesuai dengan anggaran yang tersedia
Analysis checklists
A list of questions which the analyst may use to assess the
requirement. Some items in these lists may be:
• Premature design
• Combined requirements
• Unnecessary requirements
• Use of non-standard software/hardware
• Requirements ambiguity
• Conformance with business rules
• Requirements testability
• Requirements realism
Daftar periksa analisis
Daftar pertanyaan yang dapat digunakan analis untuk menilai
persyaratan. Beberapa item dalam daftar ini mungkin:
• Desain prematur
• Persyaratan gabungan
• Persyaratan yang tidak perlu
• Penggunaan perangkat lunak / perangkat keras non-standar
• Ambiguitas persyaratan
• Kesesuaian dengan aturan bisnis
• Persyaratan testabilitas
• Persyaratan realisme
Interaction matrices
• Used to discover the interactions between requirements and to highlight requirements
conflicts and overlaps
• If we can not assume that conflicts do not exist, we should assume that there is a
potential conflict
• Undetected conflicts are much more expensive to resolve

Requirement R1 R2 R3 R4 R5 R6

R1 - - O - C C

R2 - - - - - -

R3 O - - O - O

R4 - - O - C C

R5 C - - C - -
O: OVERLAP
R6 C - O C - - C: CONFLICT
Matriks interaksi
• Digunakan untuk menemukan interaksi antara persyaratan dan untuk menyoroti konflik
dan tumpang tindih persyaratan
• Jika kita tidak dapat berasumsi bahwa konflik tidak ada, kita harus berasumsi bahwa ada
potensi konflik
• Konflik yang tidak terdeteksi jauh lebih mahal untuk diselesaikan

Requirement R1 R2 R3 R4 R5 R6

R1 - - O - C C

R2 - - - - - -

R3 O - - O - O

R4 - - O - C C

R5 C - - C - -
O: OVERLAP
R6 C - O C - - C: CONFLICT
Requirements negotiation and Documentation
• Discussing conflicts and finding some compromise which all of the stakeholders
can live with
• Meetings are most effective way. Meetings should be conducted in three stages:
• An information stage, explaining the nature of the problem
• A discussion stage, in which stakeholders discuss possible solutions
• A resolution stage, where actions concerning the requirements are agreed
• There are many different ways to structure the requirements documents,
depending on:
• The type of the system being developed
• The level of detail included
• Organizational practice
• Budget
• Schedule
Negosiasi dan Dokumentasi persyaratan
• Membahas konflik dan menemukan beberapa kompromi yang dapat dijalani oleh
semua pemangku kepentingan
• Rapat adalah cara paling efektif. Rapat harus dilakukan dalam tiga tahap:
• Tahap informasi, menjelaskan sifat masalah
• Tahap diskusi, di mana pemangku kepentingan mendiskusikan solusi yang memungkinkan
• Tahap penyelesaian, di mana tindakan mengenai persyaratan disepakati
• Ada banyak cara berbeda untuk menyusun dokumen persyaratan, tergantung
pada:
• Jenis sistem yang dikembangkan
• Tingkat detail termasuk
• Praktik organisasi
• Anggaran
• Susunan acara
Standard Templates
• Ensures that all the essential information is included
• A number of different large organizations such as the US Department of
Defense and IEEE have defined standards for requirements documents
• Probably the most acceptable of these standards is the IEEE/ANSI 830-
1993
• The standard recognizes differences between systems, and allows for
some variations in the structure.
• There is a list of stable and variant parts:
• Stable parts
• Variant parts
Template Standar
• Memastikan bahwa semua informasi penting disertakan
• Sejumlah organisasi besar yang berbeda seperti Departemen
Pertahanan AS dan IEEE telah menetapkan standar untuk dokumen
persyaratan
• Mungkin yang paling dapat diterima dari standar-standar ini adalah IEEE
/ ANSI 830-1993
• Standar mengenali perbedaan antara sistem, dan memungkinkan untuk
beberapa variasi dalam struktur.
• Ada daftar bagian yang stabil dan varian:
• Bagian yang stabil
• Bagian varian
IEEE/ANSI 830 - 1993
• Introduction: • Specific requirements
• Purpose of the requirements document • Covering functional, non-
• Scope of product functional and interface
• Definitions, acronyms and abbreviations requirements. These should
• References include external interfaces,
• Overview of the remainder of the functionality, performance
document requirements, logical
• General Description: requirements, design
• Product perspective constraints, system attributes
• Product functions and quality characteristics
• User characteristics • Appendices
• General constraints • Index
• Assumptions and dependencies
IEEE/ANSI 830 - 1993
• Pengantar:
• Tujuan dari dokumen persyaratan
• Lingkup produk
• Definisi, akronim dan singkatan
• Referensi
• Tinjauan umum sisa dokumen
• Gambaran umum:
• Perspektif produk
• Fungsi produk
• Karakteristik pengguna
• Kendala umum
• Asumsi dan dependensi
• Persyaratan khusus
• Meliputi persyaratan fungsional,
non-fungsional, dan antarmuka.
Ini harus mencakup antarmuka
eksternal, fungsionalitas,
persyaratan kinerja, persyaratan
logis, kendala desain, atribut
sistem, dan karakteristik kualitas
• Lampiran
• Indeks
A template based on IEEE/ANSI 830 – 1993
• Preface
• Introduction
• Definition of the product, its
expected usage and an
overview of its functionality
• Glossary
• Definition of technical terms
and abbreviations used
• General user requirements
• The systems requirements from
the perspective of the user
• System architecture
• A high-level overview of the
anticipated system
architecture, showing the
distribution of functions across
system modules
• Hardware specification
• Optional part for specifying of the hardware that the
software system is to expected control
• Detailed software specification
• Detailed description of the expected system
functionality
• Reliability and performance requirements
• Describes the reliability and performance expected.
• Appendices for
• Hardware interface specification
• Software components
• Data structures specification
• Data-flow models of the software system
• Detailed object models of the software system
• Index
Templat yang didasarkan pada IEEE / ANSI 830 - 1993
• Kata pengantar
• pengantar
Definisi produk, penggunaan yang
diharapkan, dan tinjauan
fungsionalitasnya
• Glosarium
Definisi istilah teknis dan
singkatan yang digunakan
• Persyaratan pengguna umum
Persyaratan sistem dari perspektif
pengguna
• Sistem arsitektur
Tinjauan tingkat tinggi arsitektur
sistem yang diantisipasi,
menunjukkan distribusi fungsi di
seluruh modul sistem
• Spesifikasi perangkat keras
Bagian opsional untuk menetapkan perangkat keras
yang akan dikontrol oleh sistem perangkat lunak
• Spesifikasi perangkat lunak terperinci
Penjelasan terperinci tentang fungsionalitas sistem
yang diharapkan
• Persyaratan keandalan dan kinerja
Menjelaskan keandalan dan kinerja yang diharapkan.
• Lampiran untuk
• Spesifikasi antarmuka perangkat keras
• Komponen perangkat lunak
• Spesifikasi struktur data
• Model aliran data dari sistem perangkat lunak
• Model objek terperinci dari sistem perangkat lunak
• Indeks
Requirements validation
• The process outputs are as follows:
• A list of problems
• Agreed solution
• Techniques for requirements validation:
• Requirements reviews: Involves a group of people who read and
analyze the requirements
• Pre-review checking: one person carries out a quick standards
check to ensure that the documents structure is consistent with
defined standards
• Review team membership: Stakeholders from different
disciplines should be involved
Validasi persyaratan
• Output proses adalah sebagai berikut:
• Daftar masalah
• Solusi yang disepakati
• Teknik untuk validasi persyaratan:
Ulasan persyaratan: Melibatkan sekelompok orang yang membaca
dan menganalisis persyaratan
• Pemeriksaan pra-tinjauan: satu orang melakukan pemeriksaan
standar cepat untuk memastikan bahwa struktur dokumen
konsisten dengan standar yang ditetapkan
• Tinjau keanggotaan tim: Para pemangku kepentingan dari berbagai
disiplin ilmu harus dilibatkan
Actors in requirements engineering process
• Domain expert: provide information about the application domain and the
specific problem in that domain which is to be solved
• System end-user: will use the system after delivery
• Requirements engineer: eliciting and specifying the requirements
• Software engineer: responsible for developing the software system
• Project manager: planning and estimating the prototyping project

Common problems in writing requirements

• Requirements are written in complex conditional clauses which are confusing
• Terminology is used in a sloppy and inconsistent way
• The writers of the requirement assume that the reader has specific knowledge of
the domain of the system and may leave out some essential information
Aktor dalam proses rekayasa persyaratan
• Pakar domain: memberikan informasi tentang domain aplikasi dan masalah khusus
dalam domain tersebut yang harus diselesaikan
• Pengguna akhir sistem: akan menggunakan sistem setelah pengiriman
• Insinyur kebutuhan: memperoleh dan menetapkan persyaratan
• Insinyur perangkat lunak: bertanggung jawab untuk mengembangkan sistem
perangkat lunak
• Manajer proyek: merencanakan dan memperkirakan proyek pembuatan prototipe
Masalah umum dalam persyaratan penulisan
• Persyaratan ditulis dalam klausa kondisional kompleks yang membingungkan
• Terminologi digunakan dengan cara yang ceroboh dan tidak konsisten
• Penulis persyaratan berasumsi bahwa pembaca memiliki pengetahuan khusus
tentang domain sistem dan dapat meninggalkan beberapa informasi penting
Things that the writer should bear in mind
• Requirements are read more often than they are written. Invest more effort to write
documents that are easy to read and understand
• Readers of requirements come from diverse backgrounds. Don't assume that readers
have the same background and knowledge as you
• Writing clearly and concisely is not easy. Allow sufficient time for drafting and
reviewing

Guidelines
• Define standard templates for describing requirements
• Use language simply, concisely and consistently. Use short sentences and paragraphs
• Use diagrams appropriately to present overviews and relationships between entities
• Specify requirements quantitatively (number of users, response time requirements,
etc.)
Hal-hal yang harus diingat penulis
• Persyaratan dibaca lebih sering daripada yang tertulis. Investasikan lebih banyak
upaya untuk menulis dokumen yang mudah dibaca dan dipahami
• Pembaca persyaratan berasal dari beragam latar belakang. Jangan berasumsi bahwa
pembaca memiliki latar belakang dan pengetahuan yang sama dengan Anda
• Menulis dengan jelas dan singkat tidak mudah. Berikan waktu yang cukup untuk
penyusunan dan peninjauan

Pedoman
• Tetapkan templat standar untuk menggambarkan persyaratan
• Gunakan bahasa secara sederhana, singkat dan konsisten. Gunakan kalimat dan
paragraf pendek
• Gunakan diagram secara tepat untuk menyajikan ikhtisar dan hubungan antar entitas
• Tentukan persyaratan secara kuantitatif (jumlah pengguna, persyaratan waktu respons,
dll.)
 Tanks
(Terimakasih)

Teaching Team (Tim Pengajar):

Deddy Kusbianto
Ahmadi Yuli Ananta
Elok Hamdana
Dhebys Suryani
Retno Damayanti