Requirements Rekayasa Perangkat Lunak

(1)

Requirements

Rekayasa Perangkat Lunak

(2)



helps software engineers better understand the problems they are trying to solve



produce a written understanding of the customer's problem.



begins during the software engineering

communication activity and continues into the modeling activity

Requirements Engineering

* SEPA 6^th ed, Roger S. Pressman

(3)

Requirements



Should describe functional and non-

functional requirements in such a way that they are understandable by system users

who don’t have detailed technical knowledge.



Requirements are defined using natural

language, tables and diagrams as these can be understood by all users.

* Software Engineering 7^th ed, Ian Sommerville

(4)

Functional Requirements Examples

 Problem Analysis

Keluhan Ketua Jurusan :

 Sulit memberi penilaian terhadap kinerja dosen dalam proses pembelajaran

 Sulit mendeteksi matakuliah yang akan dibuka di semester padat

 Problem Scope

 Ketua Jurusan dapat melihat data angka akhir setiap

matakuliah per kelas/dosen : angka minimum, maksimum, rata-rata, standar deviasi, histogram nilai akhir

(5)

Functional Requirements Examples

 Problem Analysis

 Pasien lama tidak membawa kartu identitas berobat

 Sering terjadi kesalahan saat menyimpan kartu rekam medis

 Pasien lama kehilangan kartu indentitas berobat yang berisi nomor kartu rekam medis

 Penyimpanan data pasien masih dilakukan manual

 Proses registrasi dan pembayaran memerlukan waktu lama

 Problem Scope

 Pengelolaan sistem administrasi mencakup sistem registrasi dan sistem pembayaran

 Pengelolaan sistem administrasi mencakup rawat jalan dan rawat inap

(6)

Non functional Requirements

 User interface and human factors

 Documentation

 Hardware considerations

 Performance characteristics

 Error handling and extreme conditions

 System Interfacing

 Quality issues

 System modifications

 Physical environment

 Security issues

 Resources and management issues

(7)

Non functional Requirements: Trigger Questions

User interface and human factors



What type of user will be using the system?



Will more than one type of user be using the system?



What sort of training will be required for each type of user?



Is it particularly important that the system be easy to learn?



Is it particularly important that users be protected from making errors?



What sort of input/output devices for the human interface are available, and what are their

characteristics?

(8)

Non functional Requirements:

Trigger Questions

Documentation

 What kind of documentation is required?

 What audience is to be addressed by each document?

Hardware considerations

 What hardware is the proposed system to be used on?

 What are the characteristics of the target

hardware, including memory size and auxiliary storage space?

(9)

Requirements Interaction

 Conflicts between different non-functional

requirements are common in complex systems.

 Example: Spacecraft system

 To minimise weight, the number of separate chips in the system should be minimised.

 To minimise power consumption, lower power chips should be used.

 However, using low power chips may mean that more chips have to be used. Which is the most critical

requirement?

(10)

Requirements Completeness and Consistency

 In principle, requirements should be both complete and consistent.

 Complete

 They should include descriptions of all facilities required.

 Consistent

 There should be no conflicts or contradictions in the descriptions of the system facilities.

 In practice, it is impossible to produce a complete and consistent requirements document.

(11)

The Requirements Document

 The requirements document is the official statement of what is required of the system developers.

 Should include both a definition of user

requirements and a specification of the system requirements.

 It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than HOW it should do it

(12)

Users of a Requirements Document (RD)

System Customers

Managers

System Engineers System Test

Engineers System Maintenance

Engineers

Specify the requirements and read them to check that they meet their needs. They

specify change to the requirements

To plan a bid for the system and to plan the system development process

To understand what system is to be developed

To develop validation tests for the system

To help understand the system and the relationships between its parts

(13)

02/28/2024 rpl 13

(14)

(15)

(16)

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.

(17)

Tugas



Dari topik sistem buatlah, bab 1 : Pendahuluan, yang berisi

 Latar Belakang

 Identifikasi masalah

 Batasan masalah



Dari topik sistem buatlah, bab 3 : Analisis Sistem Informasi, yang berisi

 Gambaran umum perusahaan

 Struktur organisasi

 Prosedur kerja

 Flow map

(18)

Simbol Flowmap

(19)

Contoh flowmap

(20)