RPL

1. REKAYASA PERANGKAT LUNAK (Software
Engineering)
Software Requirement Specification
Pertemuan ke 5 : Specification, Validation, and Change
Dosen :
Arif Rinaldi Dikananda, M.Kom
Willy Prihartono, M.Kom

2. View of Requirements Engineering : Process Requirements Engineering
Requirements Elicitation :
Requirements Discovery and Understanding / Gathering,
Requirements Classification and Organization,
Requirements Prioritization and Negotiation,
Requirements Documentation , 3 Stage (MDI, TOE, Final
Doc)
Requirements Spesification (SRS)
Requirements Validation
Requirement Change
Resume Sesion 1

3. Software Requirement Specification
(SRS)
SKPL

4. Manfaat dan
kegunaan
• Memastikan kesamaan antara kebutuhan untuk pengembangan
dengan kebutuhan yang ditulis didalam dokumen.
• Mendefinisikan kerangka kerja bersama untuk proses-proses
pengembangan perangkat lunak.
• Memperjelas peran dan antarmuka bagi para pihak yang terlibat
dalam proses pengembangan perangkat lunak.
• Memperjelas jenis dan isi dokumen.
• Mengenali tugas, tahapan, baseline, aktivitas kaji ulang, dan
dokumentasinya.
Belajar pendekatan praktis yang diterapkan didunia industri.
• Menghilangkan persoalan-persoalan seperti yang pernah
dialami masa lalu.
Software Requirement Specification
(SRS) / SKPL

5. • Mudah diidentifikasi
• Diuraikan dengan jelas, konsisten,
tidak ambigu
• Bisa divalidasi, bisa ditest
• Mampu untuk ditelusuri
• Dapat dipertanggungjawabkan
Shoul
d Be
Software Requirement Specification
(SRS) / SKPL

6. • Over specification (penjelasan berlebih dan berulang-
ulang sehingga menjadi tidak jelas)
• Tindakan unconcistency (seperti menggunakan istilah
yang tidak konsisten)
• Ambiguity dalam kata atau kalimat seperti menyatakan
keterukuran kebutuhan secara tidak jelas misalkan
menggunakan kata-kata :minimal, maksimal, optimal,
cepat, user friendly, efisien, fleksible dan lainnya
• Menuliskan “mimpi-mimpi”, yaitu hal-hal yang tidak bisa
dilakukan
Don’t
Software Requirement Specification
(SRS) / SKPL

7. Percfet
SRS if :
• Jelas
• Benar
• Konsisten
• Koheren
• Komprehensif
• Dapat dimodifikasi
• Dapat diverifikasi
• Memiliki prioritas
• Tidak ada unsur ambiguitas
• Dapat dilacak Sumberny
Software Requirement Specification
(SRS) / SKPL

8. Person
• Pemakai (user)
• Client
• System analyst (system engineer)
• Software engineer
• Programmer
• Test integration group
• Maintenance group
• Technical Support
• Staff dan Clerical Work
Software Requirement Specification
(SRS) / SKPL

9. Software Requirement Specification (SRS) adalah dokumen yang menjelaskan hal-hal
yang diinginkan oleh klien yang dapat disediakan pengembang , Dokumen SRS
sebagai dokumentasi perjanjian tertulis yang mencakup detail software yang akan
dikerjakan.
Dokumen SRS juga dapat membantu pihak ketiga memperkirakan
biaya dan waktu pengerjaan. Dokumen ini juga dapat membantu
kepada developer dari pihak ketiga untuk menentukan teknologi yang
diperlukan untuk menyelesaikan pekerjaan
Dokumen SRS harus memiliki informasi yang cukup detail untuk pihak ketiga selaku
pengembang atau developer software. Dokumen ini tidak hanya
mendeskripsikan software yang akan dibuat, tetapi juga harus memuat informasi
mengenai tujuan pembuatan software dan ekspektasi mengenai kinerja seharusnya
dari software yang akan dihasilkan
Software Requirement Specification
(SRS)

10. Software Requirement Specification
(SRS)
Software Requirement Specification
(SRS)

11. Software Requirement Specification
(SRS)
Software Requirement Specification
(SRS)

16. IEEE Recommended Practice for Software Requireme
nts
SpeciÞcations
Sample of SRS Document

17. Requirement Validation
VALIDITY CHECKS These check that the requirements reflect the real needs of system users.
Because of changing circumstances, the user requirements may have changed since they
were originally elicited.
CONSISTENCY CHECKS Requirements in the document should not conflict. That is, there
should not be contradictory constraints or different descriptions of the same system function.
COMPLETENESS CHECKS The requirements document should include requirements that
define all functions and the constraints intended by the system user.
REALISM CHECKS By using knowledge of existing technologies, the requirements should be checked to
ensure that they can be implemented within the proposed budget for the system. These checks should also
take account of the budget and schedule for the system development.
VERIFIABILITY To reduce the potential for dispute between customer and contractor, system
requirements should always be written so that they are verifiable. This means that you should
be able to write a set of tests that can demonstrate that the delivered system meets each
specified requirement
Requirements validation is the process of checking that
requirements define the system that the customer really
wants

18. REQUIREMENTS REVIEWS The requirements are analyzed
systematically by a team of reviewers who check for errors and
inconsistencies
PROTOTYPING This involves developing an executable model of a system
and using this with end-users and customers to see if it meets their needs
and expectations. Stakeholders experiment with the system and feed back
requirements changes to the development team.
TEST-CASE GENERATION Requirements should be testable. If the tests for
the requirements are devised as part of the validation process, this often
reveals requirements problems. If a test is difficult or impossible to design,
this usually means that the requirements will be difficult to implement and
should be reconsidered. Developing tests from the user requirements
before any code is written is an integral part of test-driven development.
Requirement Validation Techique

19. Requirement Change
The requirements for large software systems are always
changing , Because the problem cannot be fully defined,
the software requirements are bound to be incomplete

20. Requirement Change
Person can change
system
requirements to
the business
environment of
the system:
The business and
technical environment
The people who pay for
a system and the users
of that system are rarely
the same people.
Large systems usually
have a diverse
stakeholder community,
with stakeholders
having different
requirements.

21. TUGAS
Membuat SKPL/SRS untuk Sistem Informasi/Aplikasi, Cukup hanya
dibuat Outline nya saja
Dikumpulkan pada hari Sabtu,24 September 2022 Pukul 08.00
dengan menampilkan identitas JUDUL SKPL/SRS , NAMA, NIM, PRODI
Tugas Agar dikumpulkan melalui link https://bit.ly/RPL_S4 dg format
file pdf, dan diberikan nama SRS_NAMA_NIM_PRODI