Rekayasa Perangkat Lunak

Pertemuan 6
REQUIREMENT ENGINEERING

Sofiyanti Indriasari

Why are requirements so important?

Penyebabnya adalah:
Kebutuhan yg disyaratkan tidak lengkap (13,1%)
Kurangnya keterlibatan pengguna (12,4%)
Kurangnya sumber daya (10,6%)
Harapan yang tidak realistis (9,9%)
Kurangnya dukungan eksekutif (9,3%)
Perubahan kebutuhan dan spesifikasi (8,7%)
Kurangnya perencanaan (8,1%)
Sistem tidak lagi diperlukan (7,5%)
Sofiyanti Indriasari

Why are requirements so important?

Jika kesalahan identifikasi kebutuhan tidak

terdeteksi dari awal dalam proses pembangunan,

maka bisa mengakibatkan cost menjadi mahal.
Based on Boehm and Papaccio (1988) if it cost $1 to
nd and x requirements-based problems during
requirement denition process:

It costs $5 to repair during design

It costs $10 to repair during coding
It costs $20 to repair during unit testing
It costs as much as $200 after delivery of the system

Sofiyanti Indriasari

The Requirement Process

Sofiyanti Indriasari

Understanding Requirement
Tujuan dari Understanding Requirement adalah

untuk memahami masalah dan kebutuhan

pelanggan
Understanding Requirement fokus pada pelanggan
dan masalah, bukan pada solusi atau implementasi
Requirement merujuk pada kebutuhan pelanggan,
tanpa mengatakan bagaimana hal tersebut akan
diwujudkan
Mendiskusikan solusi terlalu prematur sampai
masalah ini jelas didefinisikan
Sofiyanti Indriasari

Understanding Requirement
Selama fase spesifikasi, diputuskan requirement

mana yang akan diakomodasi dalam sistem

perangkat lunak.
Selama fase desain, menyusun rencana bagaimana
spesifikasi kebutuhan akan dilaksanakan.

Sofiyanti Indriasari

Stakeholders in Requirement Engineering

Clients, who are the ones paying for the software to be developed
Customers, who buy the software after it is developed
Users, who are familiar with the current system and will use the

future system
Domain experts, who are familiar with the problem that the
software must automate
Market researchers, who have conducted surveys to determine
future trends and potential customers needs
Lawyers or auditors, who are familiar with government, safety, or
legal requirements
Software engineers or other technology experts

Sofiyanti Indriasari

Techniques of eliciting requirements:

Interviewing stakeholders

Reviewing available documentation

Observing the current system (if one exists)
Apprenticing with users

Interviewing users or stakeholders in groups

Using domain-specic strategies, such as Joint

Application Design
Brainstorming with current and potential users

Sofiyanti Indriasari

Characteristics of Requirements
The desirable characteristics we should check in
requirements:
1. Are the requirements correct?
2. Are the requirements consistent?
3. Are the requirements unambiguous?
4. Are the requirements complete?
5. Are the requirements feasible?
6. Is every requirement relevant?
7. Are the requirements testable?
8. Are the requirements traceable?
Sofiyanti Indriasari

Types of Requirements
1. Functional Requirements

Required behavior in terms of required activities.

Dene the boundaries of the solution space of our problem.

Solution space is the set of possible ways that software can be

designed to implement the requirements

Sofiyanti Indriasari

Types of Requirements
2. Non-functional Requirements / Quality
Requirements

Describes some quality characteristic that the software

solution must posses
E.g.: fast response time, ease of use, high reliability, or low
maintenance costs

Sofiyanti Indriasari

Example of Non-functional Requirements

Sofiyanti Indriasari

Two Kinds of Requirements Documents

Requirements Denition document is a

complete listing of everything the customer wants to

achieve.

It expresses requirements by describing the entities in the

environment in which the proposed system will be installed
The purpose of the proposed system is to realize these
requirements

Sofiyanti Indriasari

Documenting Requirements Denition

1.
2.
3.
4.
5.
6.

Outline the general purpose and scope of the system

(including relevant benets, objectives and goals)
Describe the background and the rationale behind the
proposal for a new system
Describe the essential characteristics of an acceptable
solution
Describe the environment in which the system will
operate
If the customer has a proposal for solving the problem
then outline the description of the proposal
List any assumptions we make about how the
environment behaves

Sofiyanti Indriasari

Two Kinds of Requirements Documents

Requirements Specication document restates

the requirements as a specication of how the

proposed system shall behave (from the perspective
of the developers).

It also written entirely in terms of the environment, except that

it refers solely to environmental entities that are accessible to
the system via its interface

Sofiyanti Indriasari

Documenting Requirements Specication

1. In documenting the systems interface, describe all
inputs and output in detail
2. Restate the required functionality in terms of the
interfaces inputs and outputs
3. Devise t criteria for each of the customers nonfunctional requirements
The result is a description of what the developers are
supposed to produce, written in sufcient detail to
distinguish between acceptable and unacceptable
solutions, but without saying how the proposed system
should be designed or implemented
Sofiyanti Indriasari

Two Kinds of Requirements Documents

Sofiyanti Indriasari

Requirements Traceability
Direct correspondence between the requirements in

the denition document and those in the

specication document.
Use the process management methods to track:

The requirements that dene what the system should do

The design modules that are generate from the requirements
The program code that implements the design
The tests that verify the functionality of the system
The documents that describe the system

Sofiyanti Indriasari

Requirements Traceability
To facilitate this correspondence, we establish a

numbering scheme or data le for convenient

tracking of requirements from one document to
another.

Sofiyanti Indriasari

Validation and Verication

Requirements validation
We check that our requirements denition accurately reects
the stakeholders need
Ensuring that we build the right system!
Requirements verication
We check that one document or artifact conforms to another
Ensuring that we build the system right

Sofiyanti Indriasari

Validation and Verication Techniques

Sofiyanti Indriasari

Modelling
Entity-Relationship Diagram

Data Flow Diagram

Sofiyanti Indriasari

Data Modelling
Data modeling a technique for organizing and

documenting a systems data. Sometimes called

database modeling.
Entity relationship diagram (ERD) a data
model utilizing several notations to depict data in
terms of the entities and relationships described by
that data.

Sofiyanti Indriasari

ERD NOTATION

Sofiyanti Indriasari

Process Modelling
Process modeling a technique used toorganize and
document a systems processes.
Flow of data through processes
Logic
Policies
Procedures
Data flow diagram (DFD) a process model used to
depict the flow of data through a system and the work or
processing performed by the system. Synonyms are
bubble chart, transformation graph, and process model.
Sofiyanti Indriasari

Data Flow Diagrams

A data flow diagram (DFD) shows how data moves

through an information system but does not show

program logic or processing steps
A set of DFDs provides a logical model that shows
what the system does, not how it does it

Sofiyanti Indriasari

Sofiyanti Indriasari

Sofiyanti Indriasari

Contoh

Sofiyanti Indriasari

Correct Or Incorrect?

Sofiyanti Indriasari

The End

Sofiyanti Indriasari