REQUIREMENT

ENGINEERING
Software Engineering
Software Engineer’s NIGHTMARE
(by Ralph Young on Effective requirements practices)

It’s your worst nightmare. A customer walks into your

office, sits down, looks you straight in the eye, and
says, “I know you think you understand what I said, but
what you don’t understand is what I said is not what I
meant.” Invariably, this happens late in the project,
after deadline commitments have been made,
reputations are on the line, and serious money is at
stake.
Intro

 Understanding the requirements of a problem is among the

most difficult tasks that face a software engineer.
 When you first think about it, developing a clear
understanding of requirements doesn’t seem that hard.
 After all, doesn’t the customer know what is required?
Shouldn’t the end users have a good understanding of the
features and functions that will provide benefit? Surprisingly,
in many instances the answer to these questions is “no.” And
even if customers and end users are explicit in their needs,
those needs will change throughout the project.
Requirement Definitions

 A requirement is a statement about what the proposed

system will do that all stakeholders agree must be made
true in order for the customer’s problem to be adequately
solved [Leithbridge & Laganiere]
 Requirements are the descriptions of the services provided
by the system and its operational constraints [Sommerville]
 From abstract (user requirements) to detailed (system
requirements)

5
Requirement Engineering
 Requirement Engineering (RE) is a broad spectrum of tasks and
techniques that lead to an understanding of requirements.
 RE is major software engineering action that begins during the
communication activity and continues into the modeling activity

Requirement
Engineering
Software Engineering Stakeholders

1. Users
Those who use the software
2. Customers
Those who pay for the software
3. Software developers
4. Development Managers

5
INFORMATION SOURCES

 Stakeholders
 Other software systems
 Manual/documentation

5
 Contractor / System Analyst
Requirement
Customer of the system Engineering

User requirement, system

requirement, others
General requirement requirement types

Proposals Detail requirement

Tender participants
Need a good initiative to Stakeholders
create a good proposal
Requirement Engineering (2)
 Requirement Engineering (RE) is a broad spectrum of tasks and
techniques that lead to an understanding of requirements.
 RE is major software engineering action that begins during the
communication activity and continues into the modeling activity
 Requirements engineering encompasses seven distinct tasks:

2. 3.
Elicitation Elaboration
1.
Inception 4.
Negotiation

7. Requirement
Management 5.
6. Specification
Validation
Requirement Engineering (3) - Inception
 Inception (beginning) - OVERVIEW
 Problem Analysis
 Business Requirement
 Vision and Scope document
 Problem analysis
 Goal: gain a better understanding of the problem being solved before
development begins
 Five steps for problem analysis (Leffingwell and Widrig)
1. Gain agreement on the problem definition
2. Understand the root causes – the problem behind the problem
3. Identify the stakeholders
4. Define the solution system vision and boundary
5. Identify the constraints to be imposed on the solution
 Result: Product Vision & Project Scope
Requirement Engineering (4) – Inception
 Business Requirements
 Business Opportunity
 Description of market opportunity, competing market, business problem
being solved or improved, advantage of proposed solution, problems that
will be solved...
 Business Objective and Success Criteria
 Important business benefits the product will provide in a quantitative and
measurable way, how success will be measured, factors that have great
impact on success...
 Customer or Market Needs
 Problems that customers currently encounter that will be addressed
 Business Risks
 Major risks associated with developing or not developing the product
(marketplace competition, timing, user acceptance, implementation
issues...)
Requirement Engineering (5) – Inception
 Business requirements example:
 Business Opportunity
 Exploit the poor security record of a competing
 Business Objective and Success Criteria
 Capture a market share of 80 percent by being recognized as the most secure
product in the market through trade journal reviews and consumer surveys
 Achieve positive cash flow on the product within 6 months
 Important for:
 Ensuring that all project participants work for the same reasons
 Getting stakeholders agreement on requirements
 User and software requirements must align with the context and
objective defined by business requirements
 Requirements that do not help achieve business objective should not
be included
Problem Statement Example
Requirement Engineering (6) - Elicitation
 Elicitation (obtain, gain)
 It certainly seems simple enough—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.
But it isn’t simple—it’s very hard.
 An important part of elicitation is to establish business goals.
 Your job is to engage stakeholders and to encourage them to share their
goals honestly.
 Problems of scope occur when the boundary of the system is ill-defined or
the customers and users specify unnecessary technical detail that may
confuse, rather than clarify, overall system objectives.
 Activity: observation, interview, brainstorming
Observation

 Gathering requirements by directly observing the users at

work
 Users may forget to report important details that may
change requirements
 Time consuming, best for large projects

5
Interviewing

Some guidelines:
 Cover as many stakeholders as possible
 Spread over time, to give some time for analysis between interviews
 Prepare an extensive list of questions
 Specific details
 Vision for the future
 Alternative ideas
 Minimally acceptable solution
 Other sources of information
 Diagrams
 Open-ended questions
 Summarize information and ask for comments
5
Brainstorming

 Goal: generate ideas

 Moderator/leader is needed
 Effective with 5 – 20 people
 Trigger questions
 Write down ideas and share
 Maintain anonymity
 Voting for priority

5
Elicitation Risk and Challenges
 You need to extract information from the brain of your customer
without damaging the customer, much less his brain!
 Good technology and good tools can help, but cannot substitute for
adequate social interaction!
 Problems of understanding
 Stakeholder not sure of what is needed
 Stakeholder has trouble communicating needs
 Stakeholder does not understand capabilities and limitation of computing
environment
 Stakeholder does not have full understanding of domain
 Problems of volatility
 Stakeholders will not commit to a set of written requirements
 Other typical issues
 Experts seldom available
 Common vocabulary often missing
Elicitation Risk and Challenges (2)
 Requirements do not fall from the sky!
 Sometimes hidden
 Sometimes too obvious, implicit, ordinary…
 Participants often lack motivation and resist to change
 We need much effort and discussion to come up with a common
agreement and understanding
Requirement Engineering (5)
 Elaboration
 The information obtained from the customer during inception and elicitation
is expanded and refined during elaboration.
 This task focuses on developing a refined requirements model (Use case
diagram etc.) that identifies various aspects of software function, behavior,
and information.
 Elaboration is driven by the creation and refinement of user scenarios that
describe how the end user (and other actors) will interact with the system.
 Negotiation
 It isn’t unusual for customers and users to ask for more than can be achieved,
given limited business resources.
 It’s also relatively common for different customers or users to propose
conflicting requirements, arguing that their version is “essential for our
special needs.”
 You have to reconcile these conflicts through a process of negotiation.
 Customers, users, and other stakeholders are asked to rank requirements and
then discuss conflicts in priority
PRIORITISING REQUIREMENTS

 Limitations on the project force you to prioritize

 MOSCOW is a feature prioritizing method
 MUST: required features that must be included
 SHOULD: important features that should be included if possible
 COULD: desirable features that can be omitted
 WON’T: completely optional features that are agreed not to be
included in current version

5
Requirement Engineering (7)
 Specification
 In the context of computer-based systems (and software), the term
specification means different things to different people.
 A specification can be a written document, a set of graphical models, a
formal mathematical model, a collection of usage scenarios, a prototype, or
any combination of these.
 Software Requirement Specification (SRS)
 Search: IEEE SRS Document Standard!!
Requirement Engineering (8)
 Validation
 Requirements validation examines the specification to ensure that all
software requirements have been stated unambiguously; that
inconsistencies, omissions, and errors have been detected and corrected;
and that the work products conform to the standards established for the
process, the project, and the product.
 The primary requirements validation mechanism is the technical review. The
review team that validates requirements includes software engineers,
customers, users, and other stakeholders who examine the specification.
 To illustrate some of the problems that occur during requirements validation,
consider two seemingly innocuous requirements:
 The software should be user friendly.
 The probability of a successful unauthorized database intrusion should be less than
0.0001.
Requirement Engineering (9)
 Validation (cont)
 The first requirement is too vague for developers to test or assess. What
exactly does “user friendly” mean? To validate it, it must be quantified or
qualified in some manner.
 The second requirement has a quantitative element (“less than 0.0001”), but
intrusion testing will be difficult and time consuming. Is this level of security
even warranted for the application? Can other complementary requirements
associated with security (e.g., password protection, specialized handshaking)
replace the quantitative requirement noted?
 Requirement Management
 Requirements for computer-based systems change, and the desire to change
requirements persists throughout the life of the system.
 Requirements management is a set of activities that help the project team
identify, control, and track requirements and changes to requirements at any
time as the project proceeds.
 Many of these activities are identical to the software configuration
management (SCM) techniques (will be discussed later)
 Requirement Engineering:
MORE AN ART THAN SCIENCE
Agile Requirement Elicitation
 Within the context of an agile process, requirements are elicited by
asking all stakeholders to create user stories.
 Each user story describes a simple system requirement written from
the user’s perspective.
As a < type of user >, I want < some goal > so that < some reason >
 User stories can be written on small note cards, making it easy for
developers to select and manage a subset of requirements to
implement for the next product increment.
 Although the agile approach to requirements elicitation is attractive
for many software teams, critics argue that a consideration of overall
business goals and nonfunctional requirements is often lacking. In
some cases, rework is required to accommodate performance and
security issues. In addition, user stories may not provide a sufficient
basis for system evolution over time
TYPES of REQUIREMENTS
 User Requirement
 Uses daily language
 States in ‘human’ language and image(s) if needed
 Defines user wishes related to the system and operational constraint(s)
 Need to be confirmed to the stakeholders
 System Requirement
 Uses technical language
 Uses structured document that includes functions, services, and operational
constraints description
 Define things that will be implemented, possibly will be a part of the contract
document between client and contractor
 System Requirement documentation
 Domain Requirements (will be discussed later)

5
TYPES of REQUIREMENTS (2)
 Business Requirement
 Business requirements are often captured by business analysts, who
analyze business activities and processes, and often study As-is process to
define a target To-be process.
 Business requirements often include:
 Business context, scope, and background, including reasons for change
 Key business stakeholders that have requirements
 Success factors for a future/target state
 Constraints imposed by the business or other systems
 Business process models and analysis, often using flowchart notations to depict
either 'as-is' and 'tobe'
 business processes
 Logical data model and data dictionary references
 Glossaries of business terms and local jargon
 Data flow diagrams to illustrate how data flows through the information systems
(different from
 flowcharts depicting algorithmic flow of business activities)
5
TYPES of REQUIREMENTS (3)
 Quality of Service Requirements

 Technical requirement

5
TYPES of REQUIREMENTS (4)
 Software Requirement
 Software Requirements is a field within software engineering that deals with
establishing the needs of stakeholders that are to be solved by
software.
 The IEEE Standard Glossary of Software Engineering Terminology
defines a requirement as: [IEEE Computer Society (1990). "IEEE Standard Glossary
of Software Engineering Terminology". IEEE Standard.]
 A condition or capability needed by a user to solve a problem or achieve an
objective.
 A condition or capability that must be met or possessed by a system or
system component to satisfy a contract, standard, specification, or other
formally imposed document.
 A documented representation of a condition or capability as in 1 or 2.
 Interface Requirement

5
TYPES of REQUIREMENTS (5)
 Functional Requirement (FR)
 What inputs the system should accept
 What outputs the system should produce
 What data the system should store that other systems might use
 What computations the system should perform
 The timing and synchronization of the above
 Non Functional Requirement (NFR)
 Quality requirements: response time, throughput, resource
usage, reliability, availability, recovery from failure,
maintainability, reusability
 Organizational requirements: SOPs, tools and methodologies,
platforms, programming languages
 External requirements: domain standards, interoperability, legal
and ethical requirements
5
 Requirement types conclusion

There are so many point of view to

classify the requirement

5
Software Quality Conflicts
 The different qualities can conflict
 Increasing efficiency can reduce maintainability or reusability
 Increasing usability can reduce efficiency

 Setting objectives for quality is a key engineering activity

 You then design to meet the objectives
 Avoids ‘over-engineering’ which wastes money

 Optimizing is also sometimes necessary

 E.g. obtain the highest possible reliability using a fixed budget

5
Software Quality (short overview)

 Correctness: It performs its task as specified

 Robustness: It reacts appropriately to abnormal conditions
 Usability: Users can learn it fast and get their job done easily
 Efficiency: It doesn’t waste resources such as CPU time and memory
 Reliability: It does what it is required to do without failing
 Maintainability: It can be easily changed
 Reusability: Its parts can be used in other projects, so reprogramming
is not needed
 Portability: It is easy to transfer the software to various environments

5
Software Quality and stakeholders
Customer: User:
solves problems at easy to learn;
an acceptable cost in efficient to use;
terms of money paid and helps get work done
resources used

QUALITY
SOFTWARE

Developer: Development manager:

easy to design; sells more and
easy to maintain; pleases customers
easy to reuse its parts while costing less
to develop and maintain

5
Characteristics of a good SRS (IEEE)
read the full document for the complete information!
 An SRS should be
a. Correct;
b. Unambiguous;
c. Complete;
d. Consistent;
e. Ranked for importance and/or stability;
f. Verifiable;
g. Modifiable;
h. Traceable.
Characteristics of a good SRS (IEEE)
Characteristics of a good SRS (IEEE)
Characteristics of a good SRS (IEEE Std 830-1998)
Characteristics of a good SRS (IEEE)
Characteristics of a good SRS (IEEE)
Characteristics of a good SRS (IEEE)
Traceability
 Traceability is a software engineering term that refers to documented
links between software engineering work products (e.g.,
requirements and test cases).
 A traceability matrix allows a requirements engineer to represent the
relationship between requirements and other software engineering
work products.
 Rows of the traceability matrix are labeled using requirement names
and columns can be labeled with the name of a software engineering
work product (e.g., a design element or a test case). A matrix cell is
marked to indicate the presence of a link between the two.
Traceability (2)
Traceability (2)
Penjelasan dengan contoh kasus
 User Req:
 Mahasiswa dapat mengisi FRS secara online
 Software Req:
 SW menyediakan form entri FRS yang dapat diisi oleh mahasiswa
 SW menyediakan fasilitas untuk menyimpan draft FRS yang dibuat mahasiswa
 SW menyediakan fasilitas untuk men-submit FRS final yang diisi mahasiswa
 SW menyediakan fasilitas untuk menampilkan daftar kelas yang dibuka di
semester tersebut
 SW menyediakan fasilitas untuk menampilkan transkrip mahasiswa
Catatan

 Perhatikan bahwa definisi User Requirement sifatnya lebih umum

(high level);
 Sedangkan spesifikasi kebutuhan sistem sifatnya sudah lebih
rinci/detil;
 Pada kasus di atas, user requirement belum memperhatikan kapan persisnya
laporan akan dicetak, siapa yang bertanggung jawab mencetak, atau bentuk
format yang akan dicetak.
Kebutuhan Pengguna

 Pernyataan kebutuhan pengguna bisa bersifat fungsional ataupun

non-fungsional
 Penulisan kembali suatu pernyataan kebutuhan harus dapat dimengerti oleh
pengguna yang kadang-kadang tidak mengerti bahasa teknis
 Pernyataan kebutuhan pengguna ini menggunakan bahasa ‘sehari-
hari’ yang dapat didukung oleh diagram atau tabel yang dapat
dimengerti oleh semua calon pengguna.
Permasalahan dengan Bahasa Alami

 Kadang tidak jelas

 Kurang presisi, tetapi kalau terlalu presisipun mungkin menyebabkan
dokumen sulit dibaca
 Ketidakjelasan kebutuhan
 Kebutuhan fungsional dan non-fungsional cenderung tercampur
 Kebutuhan yang berlebihan
 Beberapa pernyataan kebutuhan mungkin diungkapkan bersamaan.
Contoh Kebutuhan Pengguna

 Sistem Perangkat lunak untuk Perpustakaan

 [SR01] “Pengguna harus dapat mencari buku”
 [SR02] “Sistem dapat memberikan tampilan data buku untuk anggota
perpustakaan”
 [SR03] “Sistem harus dapat memberikan laporan bulanan”
 [SR04] “Setiap pemesanan buku akan diberikan nomor pemesanan yang
unik”
 [SR05] “Tidak boleh ada anggota yang boleh meminjam lebih dari 5 buku dan
masa peminjaman tidak lebih dari 7 hari”

Tentukanlah yang fungsional dan yang nonfungsional!

NF Requirements

 Kebutuhan NF kadang-kadang bisa lebih kritikal daripada kebutuhan

fungsional
 Contoh: Pada sistem auto-cruise mobil: saat rem dipijak, maka sistem auto-
cruise harus stop
 Kebutuhan NF kadang bisa berakibat pada sistem secara
keseluruhan (tidak hanya satu komponen tunggal)
 Contoh: kebutuhan performansi suatu sistem, akan melibatkan berbagai
komponen
 Satu kebutuhan NF mungkin bisa menghasilkan beberapa
kebutuhan fungsional.
Contoh Kebutuhan Non-Fungsional

 Sistem perpustakaan
 Tampilan browser diimplementasikan dengan HTML sederhana, tidak perlu
ada frame atau Java applets
 Sistem harus berjalan 24 jam, jika terjadi down, maka tidak melebihi 15
menit di jam kerja atau 3 jam di luar jam kerja.
 Proses pengembangan dan dokumen yang diserahkan harus sesuai dengan
aturan di SNI-PL-1005
 Semua pengguna harus terdaftar oleh sistem
Masalah pada kebutuhan NF

 Kebutuhan NF harus semaksimal mungkin terkuantifikasi (agar dapat

diuji (testable))
 Pernyataan asli dari pengguna:
 “Software harus mudah digunakan dan kesalahan pada saat penggunaan semaksimal mungkin
di kurangi”
 Pengembang perlu mengkuantifikasi sbb:
 “Software harus dapat digunakan oleh staf setelah 8 jam training, dan sesudahnya bagi
pengguna yang sudah berpengalaman jumlah rata-rata error yang muncul tidak melebihi 2 kali
untuk setiap jam.

 Jika mungkin kebutuhan NF harus ditulis secara kuantitas

agar mudah diuji secara objektif.
Keterkaitan antar Kebutuhan

 Konflik sering terjadi pada kebutuhan NF

 Terutama pada sistem yang kompleks
 Contoh Spacecraft System
 Untuk mengurangi beban, jumlah chips harus dikurangi
 Untuk mengurangi konsumsi daya, gunakan chips dengan daya rendah
 Tetapi dengan chips daya rendah, mungkin berarti makin banyak chip yang
harus digunakan
 Mana requirement yang paling kritis untuk dipenuhi?
Kebutuhan yang tidak Presisi

Pernyataan kebutuhan yang tidak presisi menyebabkan interpretasi

yang berbeda antara pengembang dan pengguna
 “Pengguna harus dapat mencari buku”
 Interpretasi Pengguna:
 Hanya mencari buku berdasarkan judul buku yang tidak sedang dipinjam
 Interpretasi Pengembang
 Mencari suatu buku tanpa mempedulikan apakah buku sedang dipinjam
atau tidak
Kelengkapan Kebutuhan dan Konsistensi

 Suatu kebutuhan harus lengkap dan konsisten

 Lengkap: semua deskripsi yang diperlukan sudah terungkapkan
 Konsisten: tidak ada konflik atau kontradiksi pada deskripsi
 Dalam prakteknya, tidak mungkin membuat kebutuhan yang
lengkap dan konsisten.
 Tapi kita harus berusaha membuatnya
Kebutuhan dan Perancangan

 Kebutuhan harus mendefinisikan apa (WHAT) yang

seharusnya dilakukan oleh sistem sedangkan perancangan
menjelaskan bagaimana (HOW) mencapai definisi tadi
 Kebutuhan dan perancangan tidak terpisahkan
 Suatu arsitektur sistem di rancang sesuai dengan struktur kebutuhan
sistem
 Sistem mungkin saling beroperasi dengan sistem lain
 Pemakaian arsitektur yang spesifik untuk memenuhi kebutuhan NF
mungkin adalah kebutuhan dari domain
 Hal ini mungkin adalah konsekuensi harus mengikuti suatu aturan
(regulatory)
Cara Menuliskan Spesifikasi Kebutuhan Sistem
Spesifikasi dengan Bahasa Natural

 Kebutuhan-kebutuhan dituliskan dalam kalimat natural yang di

dukung oleh diagram dan table
 Digunakan untuk menulis kebutuhan karena sifatnya yang ekspresif,
intuitif dan universal
 Agar mudah dimengerti oleh pengguna (user) dan pelanggan (customer)
Panduan menulis Kebutuhan

Untuk mengatasi kelemahan penggunaan bahasa natural/bahasa manusia,

berikut adalah panduan cara penulisan kebutuhan
 Buat format yang standard, dan diikuti untuk semua pernyataan
kebutuhan
 Gunakan bahasa yang konsisten
 – “Sistem harus dapat …”
 Pernyataan ini berarti sistem harus bisa melakukan yang dinyatakan
 – “Sistem sebaiknya dapat …”
 Pernyataan ini berarti sistem yang diinginkan..

 Gunakan huruf yang lebih tebal atau berbeda untuk

mengindentifikasi bagian yang penting
 Hindari istilah yang hanya dikenal oleh orang teknis.
 Berikan penjelasan kenapa suatu kebutuhan diperlukan
Bahasa Natural Terstruktur
(Structured Natural language)
 Spesifikasi kebutuhan ditulis mengikuti suatu aturan standard
 – jadi tidak sembarangan
 Cara ini bisa digunakan dengan baik untuk sistem yang sudah
lebih ‘pasti’ seperti sistem kendali (control system), tetapi
terlalu kaku untuk menuliskan kebutuhan sistem bisnis
 Sistem informasi banking, sistem informasi perpustakaan, dll.
Contoh untuk Pompa Insulin
Spesifikasi dengan bentuk tabel
 Digunakan sebagai pendukung penjelasan dengan bahasa alami
 Sangat berguna jika kita harus mendefinisikan sejumlah alternatif
yang mungkin terjadi
 Sistem pompa insulin bergantung komputasinya pada kecepatan perubahan
level gula dari darah
 Tabel spesifikasi ini akan membantu menjelaskan bahwa cara perhitungan
dosis insulin untuk setiap kasus
Contoh spesifikasi bentuk tabel