0% found this document useful (0 votes)
40 views34 pages

Sesi 3 - Requirement Engineering - Overview

The document discusses requirements engineering and defines what requirements are, including different types. It states that requirements capture the purpose of a system in a way that is agreed upon by stakeholders. There are various types of requirements like functional, non-functional, user, and system requirements. The requirements engineering process involves gathering and analyzing requirements and ensuring they are well-written.

Uploaded by

FadlyFebriya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
40 views34 pages

Sesi 3 - Requirement Engineering - Overview

The document discusses requirements engineering and defines what requirements are, including different types. It states that requirements capture the purpose of a system in a way that is agreed upon by stakeholders. There are various types of requirements like functional, non-functional, user, and system requirements. The requirements engineering process involves gathering and analyzing requirements and ensuring they are well-written.

Uploaded by

FadlyFebriya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 34

Rekayasa Perangkat Lunak

Fadly Febriya S.SI., M.Kom


Sesi 3
Rekayasa Kebutuhan Sistem
(Requirement Engineering)
Pokok Bahasan Overview :

• What are “Requirements”


• Types of Requirement
An expression of the ideas to be embodied in
What are “Requirements”? the system or application under development
A requirement is: A statement about the proposed system that all
Capturing the purpose of a system stakeholders agree must be made true in order
for the customer’s problem to be adequately
solved
• Short and concise piece of information
• Says something about the system
• All the stakeholders have agreed that it is
valid
• It helps solve the customer’s problem
General Problems
• Lack of the right expertise (software engineers, domain experts, etc.)

• Initial ideas are often incomplete, wildly optimistic, and firmly entrenched in the
minds of the people leading the acquisition process

• Difficulty of using complex tools and diverse methods associated with


requirements gathering may negate the anticipated benefits of a complete and
detailed approach
Statistics from NIST Report
NIST (National Institute of Standards and Technology) has published a comprehensive (309 pages)
and very interesting report on project statistics and experiences based on data from a large number of
software projects

– 70% of the defects are introduced in the specification phase


– 30% are introduced later in the technical solution process
– Only 5% of the specification inadequacies are corrected in the specification phase
– 95% are detected later in the project or after delivery where the cost for correction on average is
22 times higher compared to a correction directly during the specification effort
– The NIST report concludes that extensive testing is essential, however testing detects the
dominating specification errors late in the process
Requirements’ Gathering
Types of Requirements
So Many “Requirements”… (1)
• A goal is an objective or concern that guides the RE process. It can be used to
discover and evaluate functional and non-functional requirements
– A goal is not yet a requirement…
• Note: All requirements must be verifiable (by some test, inspection, audit etc.)
So Many “Requirements”… (2)
• A functional requirement is a requirement defining functions of the system under
development
– Describes what the system should do
• A non-functional requirement is a requirement that is not functional. This includes
many different kinds of requirements.
So Many “Requirements”… (3)
• A user requirement is a desired goal or function that a user and other
stakeholders expect the system to achieve
– Does not necessarily become a system requirement
• Application domain requirement (sometimes called business rules) are
requirements derived from business practices within a given industrial
sector, or in a given company, or defined by government regulations or
standards.
– May lead to system requirements. Can be functional or non-functional
• Problem domain requirements should be satisfied within the problem domain
in order to satisfy some of the goals
• System requirements are the requirements for the system to be built, as a whole
– A system is a collection of interrelated components working together
towards some common objective (may be software, mechanical, electrical
and electronic hardware and be operated by people)
– Systems Engineering is a multidisciplinary approach to systems
development – software is only a part (but often the problematic part)
So Many “Requirements”… (4)
• In a system containing software, software requirements are derived
from the system requirements. The system then consists of
hardware and software, and the hardware (and often the operating
system and other existing software modules) are part of the
environment in which the software is used.
The Requirements Engineering Process
Requirements
within the
software
development
process
What is the
right system to
build ?
RE activities and documents
(Wiegers)
Requirements and Modeling go together
The systems engineering sandwich!

Source: http://www.telelogic.com/download/paper/SystemsEngineeringSandwich.pdf
RE Process and Related Activities
Writing Effective Requirement Spesification
User Requirement
• Ditulis oleh developer, sumber dari user, berdasar kebutuhan user

Ex : User melakukan login untuk mengakses sistem.


Software Requirement
• Kebutuhan Software yang dirancang berdasarkan kebutuhan user.

Ex : perangkat lunak dapat menyimpan data penjualan.


Business Requirement
• Batasan dari sistem, berhubungan dengan tujuan departemen
terkait.

Ex : Bagian HRD akan mengirimkan data absensi pegawai untuk


menghitung jumlah hari hadir.
Hardware Requirement
• Kebutuhan hardware yang akan dipergunakan penunjang
berjalannya aplikasi yang dikembangkan.

Ex : Printer yang digunakan dapat melakukan pencetakan struk 2


rangkap.
Functional Requirements
• What inputs the system should accept
• What outputs the system should produce
• What data the system should store other systems might use
• What computations the system should perform
• The timing and synchronization of the above
Functional Requirements (2)
• Depend on the type of software, expected users, and the type of system where
the software is used
• Functional user requirements may be high-level statements of what the system
should do, but functional system requirements should describe the system
services in detail
Examples of Functional Requirements

• The user shall be able to search either all of the initial set of
databases or select a subset from it.

• The system shall provide appropriate viewers for the user to read
documents in the document store.

• Every order shall be allocated a unique identifier (ORDER_ID)


which the user shall be able to copy to the account’s permanent
storage area.
Non-Functional Requirements (NFR)
• Non-functional requirements are important
– If they are not met, the system is useless
– Non-functional requirements may be very difficult to state
precisely (especially at the beginning) and imprecise
requirements may be difficult to verify
• They are sometimes called quality requirements, quality of service,
or extra-functional requirements.
Non-Functional Requirements (NFR) (1)

• Three main categories :


– Performance requirements reflecting: usability, efficiency, reliability,
maintainability and reusability (note: also security requirements)
– Response time, throughput
– Resource usage
– Reliability, availability
– Recovery from failure
– Allowances for maintainability and enhancement
– Allowances for reusability
Non-Functional Requirements (NFR) (2)
– Design constraints: Categories constraining the environment and
technology of the system.
– Platform (minimal requirements, OS, devices…)
– Technology to be used (language, DB, …)

– Commercial constaints: Categories constraining the project plan and


development methods
– Development process (methodology) to be used
– Cost and delivery date
– Often put in contract or project plan instead
Various NFR Types

Source: Gerald Kotonya and Ian Sommerville, Requirements Engineering – Processes and Techniques, Wiley, 1998
Examples of NFR
• Product requirement
– It shall be possible for all necessary communication between the APSE and
the user to be expressed in the standard Ada character set.
• Process requirement
– The system development process and deliverable documents shall conform
to the process and deliverables defined in XYZCoSPSTAN95.
• Security requirement
– The system shall not disclose any personal information about customers
apart from their name and reference number to the operators of the system.
Measurable Non-Functional Requirements
Question?
NPM akhir genap
Sistem Informasi Rumah Sakit

NPM akhir ganjil


Sistem Informasi Restaurant

Buatkan FR & NFR nya


Deadline: 23 Okt 2021 pkl 23.59
Email [email protected]
Subject: FR NFR – NPM - Nama

You might also like