Rekayasa Kebutuhan

Requirement Engineering
Fajar Pradana S.ST., M.Eng
 2

Pendahuluan
• Relevansi Perkuliahan :
 Banyak terjadi kasus bahwa perangkat lunak yang sudah jadi tidak
sesuai dengan apa yang dibutuhkan oleh customer
 Dengan melakukan analisis kebutuhan perangkat lunak maka
diharapkan PL dikembangkan berdasarkan apa-apa yang dibutuhkan
oleh customer
• Tujuan Instruksional Khusus :
 Memahami pengertian dan urgensi rekayasa kebutuhan
 Memahami proses rekayasa kebutuhan
 Memahami problem-problem dalam rekayasa kebutuhan
 3

Point of View
• Motivation
• Requirement Engineering Concept
• Requirement Engineering Process
 Elicitation and Analysis
 Specification
 Validation and Verification
 Manajemen
• Example of Question
 4

Motivation

“The hardest single part of building a system is

deciding what to build”
[Brooks – 1987]
 5

Anonymous Customer
“I know you believe you understood what you think I said, but I am
not sure you realize that what you heard is not what I meant . . . . .”
 6

Anonymous Customer
 7

Requirements Engineering
• Each software development process goes through the phase of
Requirements Engineering
• The process of establishing the services that the customer
requires from a system and the constraints under which it
operates and is developed [Ian Sommerville]
• The broad spectrum of tasks and techniques that lead to an
understanding of requirements [Roger S. Pressman]
 8

Requirements Engineering
• Requirements engineering provides the appropriate mechanism
for understanding what the customer wants, analyzing need,
assessing feasibility, negotiating a reasonable solution, specifying
the solution unambiguously, validating the specification, and
managing the requirements as they are transformed into an
operational system. [Thayer, R.H. and M. Dorfman]
 9

Different Perspective
 10

RE Categories
• Functional
 what a system does
 Process description, input , output
• Non-functional
 constraint or quality of a system
 Performance, availability, security, reliability, implementation & design
constraints, storage size
• Usability
 constraint to use
 Acceptance criteria, end-user characteristics, system environments
 11

Levels of requirements
• Normal requirement
 The objectives and goals that are stated for a product or system
during meetings with the customer
 Eg. requested types of graphical displays, specific system functions,
and defined levels of performance
• Expected requirement
 These requirements are implicit to the product or system and may be
so fundamental that the customer does not explicitly state them.
 Their absence will be a cause for significant dissatisfaction.
 Eg. ease of human/machine interaction, overall operational
correctness and reliability, and ease of software installation
• Exciting requirement
 These features go beyond the customer’s expectations and prove to
be very satisfying when present
 12

Requirements Engineering
• RE is a software engineering task that bridges the gap between
system level requirements engineering and software design
• Requirements analysis provides the software designer with a
representation of information, function, and behavior that can be
translated to data, architectural, interface, and component-level
designs
• the requirements specification provides the developer and the
customer with the means to assess quality once software is built.
Requirements Engineering 13
 14

Process
• Requirement elicitation and analysis
• Requirement specification
• Requirement validation and verification
• Requirement management
 15

Elicitation and analysis (1)

• ask the customer, the users, and others what the objectives for
the system or product are,
• what is to be accomplished, how the system or product fits into
the needs of the business, and finally, how the system or product
is to be used on a day-to-day basis.
• Christel and Kang [CRI92] identify a number of problems that help
us understand why requirements elicitation is difficult :
 Problem of scope
 Problem of understanding
 Problems of volatility
 16

Detailed guidelines
• Sommerville and Sawyer [SOM97] suggest a set of detailed
guidelines for requirements elicitation, which are summarized in
the following steps
 Assess the business and technical feasibility for the proposed
system.
 Identify the people who will help specify requirements and
understand theirorganizational bias.
 Define the technical environment placed.
 Identify “domain constraints”
 Define one or more requirements elicitation methods (e.g.,
interviews, focus groups, team meetings).
 Solicit participation from many people so that requirements are
defined from different points of view; be sure to identify the rationale
for each requirement that is recorded.
 Identify ambiguous requirements as candidates for prototyping.
 17

Work Products
• For most systems, the work products include
 A statement of need and feasibility.
 A bounded statement of scope for the system or product.
 A list of customers, users, and other stakeholders who participated in
therequirements elicitation activity.
 A description of the system’s technical environment.
 A list of requirements (preferably organized by function) and the
domain constraints that apply to each.
 A set of usage scenarios that provide insight into the use of the
system or product under different operating conditions.
 Any prototypes developed to better define requirements.
 18

Example of question
• The first set of context-free questions focuses on the customer,
the overall goals, and the benefits. For example, the analyst might
ask:
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a successful solution?
 Is there another source for the solution that you need?verall goals,
and the benefits
 19

Example of question (cont)

• The next set of questions enables the analyst to gain a better
understanding of the problem and the customer to voice his or her
perceptions about a solution:
 How would you characterize "good" output that would be generated
by a successful solution?
 What problem(s) will this solution address?
 Can you show me (or describe) the environment in which the solution
will be used?
 Will special performance issues or constraints affect the way the
solution is approached?
 20

Example of question (cont.)

• The final set of questions focuses on the effectiveness of the
meeting. Gause and Weinberg [GAU89] call these meta-
questionsand propose the following :
 Are you the right person to answer these questions? Are your
answers "official"?
 Are my questions relevant to the problem that you have?
 Am I asking too many questions?
 Can anyone else provide additional information?
 Should I be asking you anything else?
 21

Requirement Specification (2)

• the final work product produced by the system and requirements
engineer.
• It serves as the foundation for hardware engineering, software
engineering, database engineering, and human engineering.
• It describes the function and performance of a computer-based
system and the constraints that will govern its development
 22

Requirement Specification (2)

• Definisi kebutuhan (req. definition) :
1. PL harus mampu menyediakan sarana untuk menampilkan dan
mengakses file-file yang dibuat oleh tool yang lain. (SRS_PRJ_100)
• Spesifikasi kebutuhan (req. specification) :
1.1 Pengguna harus disediakan fasilitas untuk mendefinisikan tipe
file. (SRS_PRJ_101)
1.2 Setiap tipe file direpresentasikan dengan ikon tertentu pada
layar pengguna. (SRS_PRJ_102)
 23

Validation and Verification

• examines the specification to ensure that all system requirements
have been stated unambiguously;
• that inconsistencies, omissions, and errors have been detected
and corrected
• The review team includes system engineers, customers, users,
and other stakeholders
• Validasi : do we make the right product ….. ?
• Verifikasi : do we make the product right ….. ?
• Teknik :
• Review : Software Specification Review (SSR)
• Prototyping : executable model of the system/software
 24

Parameter
• Validation Parameter :
 Validity -> does the system provide the functions which best support
the customer’s needs ?
 Consistency -> are there any requirements conflicts ?
 Comprehensibility -> are all functions required by the customer
included ?
• Verfication Parameter:
 Readability
 Testability
 Completeness
 Identifiability
 Ambiguity
 25

Requirement Management
• Identification
• Change Management
• Documentation
• Tracking and Traceability
26
 27

Terima Kasih
Ada Pertanyaan