Department of Information Systems

Subject : Requirement Engineering

RE PROCESS

IS184309, 3 sks

Feby Artwodini M.
feby.artwodini@gmail.com
Outline
✓ Why RE
✓ RE Process
✓ Discussion

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 2

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 3
What is Process?

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 4

Why RE
https://youtu.be/VmEFwXczVlM

??

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 5

Why Software Engineering?
A naive view:
Problem Specification coding Final Program

But ...
◦ Where did the specification come from?
◦ How do you know the specification corresponds to the user’s needs?
◦ How did you decide how to structure your program?
◦ How do you know the program actually meets the specification?
◦ How do you know your program will always work correctly?
◦ What do you do if the users’ needs change?
◦ How do you divide tasks up if you have more than a one-person team?

© Oscar Nierstrasz ESE — INTRODUCTION ESE 1.6

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 7
SWEBOK

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 8

Focus of RE

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 9

What is RE??

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 10

Software Life Cycle

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 11

Cost on Software Changes

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 12

Requirement Engineering - DSI Gasal 2018/2019
 Requirements Engineering-I
Inception—ask a set of questions that establish …
◦ basic understanding of the problem
◦ the people who want a solution
◦ the nature of the solution that is desired, and
◦ the effectiveness of preliminary communication and collaboration between the customer and the developer

Elicitation—elicit requirements from all stakeholders

Elaboration—create an analysis model that identifies data, function and behavioral requirements
Negotiation—agree on a deliverable system that is realistic for developers and customers

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by REQUIREMENT ENGINEERING - DSI GASAL 2018/2019
Roger Pressman.
 Requirements Engineering-II
Specification—can be any one (or more) of the following:
◦ A written document
◦ A set of models
◦ A formal mathematical
◦ A collection of user scenarios (use-cases)
◦ A prototype

Validation—a review mechanism that looks for

◦ errors in content or interpretation
◦ areas where clarification may be required
◦ missing information
◦ inconsistencies (a major problem when large products or systems are engineered)
◦ conflicting or unrealistic (unachievable) requirements.

Requirements management

These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 REQUIREMENT ENGINEERING - DSI GASAL 2018/2019
by Roger Pressman.
RE Process – Input and Output

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 19

Input and Output Description

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 20

 Why is it difficult to gain a clear understanding of what the customer wants?

Aim is to build the right system

◦ A system that meets the user’s needs

Requires the collaboration of several groups of participants with different backgrounds

◦ Knowledge GAP

The software engineer needs to :

◦ Learn about application domain and “discover” requirements
◦ Choose an appropriate representation for specifying requirements
◦ May need to “educate “” user

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019

Problems of scope
The boundary of the system may be ill-defined
◦ Who is going to interact with the system?
◦ What other systems are involved?
◦ Exactly what functionality is the responsibility of the system
◦ e.g. should a rostering system produce a telephone directory?

The customer/user may specify unnecessary technical detail that may confuse overall system
objectives
◦ e.g. specifying OS, language, hardware, etc. for no particularly good reason

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019

Problems of Understanding
Customers/users may:
◦ Not be completely sure of what is needed, e.g.:
◦ “See what you can do to help us” (Marketing director of textile business)
◦ “Try to improve the project” (Director of British Aircraft Corporation, with
reference to the Concorde project)
◦ Have a poor understanding of the capabilities and limitations of their
computing equipment
◦ Not have a full understanding of the problem domain
◦ Have trouble communicating needs to system engineer
◦ Omit information believed to be “obvious”
◦ Specify requirements that conflict with needs of others
◦ Specify requirements that are ambiguous or untestable

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019
Problem of volatility
Requirements change over time
Change is inevitable in most systems, due to factors such as:
◦ Changes in customer organization, e.g. new divisions, new products
◦ Changes in scale, e.g.
◦ Number of transactions per day
◦ Number of users
◦ Increased connection bandwidth
◦ External changes
◦ Changes in law (e.g. taxation)
◦ Changes in international standards (e.g. MPEG)
◦ Customers get new ideas as they become aware of system possibilities

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019

Elicitation techniques
1) Focus Group Discussion
2) Questioner
3) Brainstorming
4) Prototype
5) Observasi
6) JAD – Joint Application Design
7) Goal-based Methods
8) Scenario-based Methods
9) Ethnography
10) Interview

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019

References
•Software Engineering: A Practioner's Approach. Roger S. Pressman. McGraw Hill Text; ISBN:
0072496681; 7th edition, 2009
•Analisis Kebutuhan Dalam Rekayasa Perangkat Lunak. Daniel Siahaan. Penerbit ANDI;
Yogyakarta; 2012
•E-Book: SWEBOK
•E-Book: REBOK

REQUIREMENT ENGINEERING - DSI GASAL 2018/2019 27