kuliah rpl - 6

R E Q U I R E M E N T E N G I N E E R I N G

Sofiyanti Indriasari

Rekayasa Perangkat Lunak Pertemuan 6

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%)

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 find and fix requirements-based problems during requirement definition 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

The Requirement Process


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

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.

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

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-specific strategies, such as Joint Application Design

Brainstorming with current and potential users

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?

Types of Requirements


1. Functional Requirements

Required behavior in terms of required activities.

Define 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

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

Example of Non-functional Requirements


Two Kinds of Requirements Documents


Requirements Definition 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

Documenting Requirements Definition


1. Outline the general purpose and scope of the system

(including relevant benefits, objectives and goals) 2. Describe the background and the rationale behind the

proposal for a new system 3. Describe the essential characteristics of an acceptable

solution 4. Describe the environment in which the system will

operate 5. If the customer has a proposal for solving the problem

then outline the description of the proposal 6. List any assumptions we make about how the

environment behaves



Requirements Specification document restates the requirements as a specification 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

Documenting Requirements Specification


1. In documenting the system’s interface, describe all inputs and output in detail

2. Restate the required functionality in terms of the interfaces’ inputs and outputs

3. Devise fit criteria for each of the customer’s non-functional requirements

The result is a description of what the developers are supposed to produce, written in sufficient detail to distinguish between acceptable and unacceptable solutions, but without saying how the proposed system should be designed or implemented

Requirements Traceability


Direct correspondence between the requirements in the definition document and those in the specification document.

Use the process management methods to track:

The requirements that define 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

Requirements Traceability


To facilitate this correspondence, we establish a numbering scheme or data file for convenient tracking of requirements from one document to another.

Validation and Verification


Requirements validation

We check that our requirements definition accurately reflects the stakeholders’ need

Ensuring that we build the right system!

Requirements verification

We check that one document or artifact conforms to another

Ensuring that we build the system right

Validation and Verification Techniques


Modelling


Entity-Relationship Diagram

Data Flow Diagram

Data Modelling


Data modeling – a technique for organizing and documenting a system’s 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.

ERD NOTATION


Process Modelling


Process modeling – a technique used toorganize and document a system’s 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.

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

Contoh


Correct Or Incorrect?


The End
