REKAYASA PERANGKAT LUNAK (RPL) Analisis Kebutuhan Perangkat Lunak

(1)

REKAYASA PERANGKAT

LUNAK (RPL)

Analisis

Kebutuhan

Perangkat

(2)

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 . . . . .

(3)

Communication

(4)

Pendahuluan

Relevansi

Perkuliahan

:

–

– Banyak terjadi kasus bahwa perangkat lunak yang Banyak terjadi kasus bahwa perangkat lunak yang sudah jadi tidak sesuai dengan apa yang dibutuhkan sudah jadi tidak sesuai dengan apa yang dibutuhkan

oleh

oleh customercustomer

–

– DenganDengan melakukanmelakukan analisisanalisis kebutuhankebutuhan perangkatperangkat lunak

lunak makamaka diharapkandiharapkan PL PL dikembangkandikembangkan berdasarkan

berdasarkan apaapa--apaapa yang yang dibutuhkandibutuhkan oleholeh customercustomer

Tujuan

Instruksional

Khusus

:

Mahasiswa akan dapat menjabarkan pengertian dan Mahasiswa akan dapat menjabarkan pengertian dan

metode

(5)

Agenda

Pembahasan

Pendahuluan

Pengertian

Analisis

Kebutuhan

dan

Kebutuhan

Urgensi

dan

Fungsi

Analisis

Kebutuhan

Problem

Proses

Metode

Alat

(6)

Pengertian

:

S/W Req. Analysis (SRA)

Aktifitas

RPL yang

menjembatani

antara

kebutuhan

di

tingkat

sistem

dan

perancangan

perangkat

lunak

(

Roger S. Pressman

)

Proses

yang

digunakan

untuk

mendapatkan

,

menganalisis

,

dan

memvalidasi

kebutuhan

-

-kebutuhan

(7)

Pengertian

:

Requirement

Suatu

kondisi

atau

kemampuan

yang

dibutuhkan

oleh

pengguna

untuk

menyelesaikan

permasalahan

atau

untuk

mencapai

sebuah

tujuan

(

IEEE

)

Sebuah

kondisi

atau

kemampuan

yang

harus

dipenuhi

atau

dimiliki

oleh

sebuah

sistem

…

untuk

memenuhi

sebuah

kontrak

, standard,

spesifikasi

,

atau

dokumen2 formal

lainnya

(

IEEE

)

Setiap

fungsi

,

batasan

,

atau

properti

lainnya

yang

harus

disediakan

,

dimiliki

atau

dipenuhi

untuk

mencapai

kebutuhan

dari

sistem

yang

dimaksudkan

oleh

(8)

Urgensi

&

Fungsi

If you don

’

t analyze, it

’

s highly likely that you

’

ll build a

very elegant software solution that solves the wrong

problem. The result is wasted time and money,

personal frustration

, and unhappy customers

(

Roger S. Pressman

)

Kegunaan

Kegunaan hasilhasil analisisanalisis kebutuhankebutuhan::

–

– UntukUntuk mencapaimencapai kesepakatankesepakatan antaraantara developerdeveloper, , customercustomer

dan

dan penggunapengguna akhirakhir akanakan kebutuhankebutuhan yang yang harusharus dipenuhidipenuhi –

– UntukUntuk menyediakanmenyediakan dasardasar yang yang akuratakurat bagibagi perancanganperancangan perangkat

(9)

Problem

Stakeholder

Stakeholder ((endend--user, user, manajermanajer, maintenance engineer, maintenance engineer, ,

policy maker

policy maker) ) tidaktidak tahutahu persispersis apaapa yang yang sesungguhnyasesungguhnya mereka

mereka inginkaninginkan

Stakeholder

Stakeholder menyatakanmenyatakan kebutuhannyakebutuhannya dalamdalam bahasabahasa yang

yang dipahamidipahami oleholeh merekamereka sendirisendiri

Stakeholder

Stakeholder yang yang berbedaberbeda mungkinmungkin memilikimemiliki kebutuhankebutuhan yang

yang salingsaling bertentanganbertentangan Kebutuhan

Kebutuhan mungkinmungkin berubahberubah padapada saatsaat dilakukandilakukan analisis

analisis. . StakeholderStakeholder barubaru yang yang bergabungbergabung mungkinmungkin merubah

merubah dandan lingkunganlingkungan bisnisbisnis mengalamimengalami perubahanperubahan Pertentangan

Pertentangan antaraantara unjukunjuk kerjakerja ((performanceperformance) dan) dan kemudahan

(10)

Proses

Penggalian

dan

analisis

kebutuhan

(

s/w

req.

elicitation and analysis

)

Spesifikasi

kebutuhan

(

s/w

req. specification

)

Validasi

kebutuhan

(

s/w

req. validation

)

Manajemen

kebutuhan

(

s/w

req. management

)

Karakteristik

(11)

Proses

:

Elisitasi

dan

Analisis

Developer

harus

memahami

domain

permasalahan

Developer

dan

stakeholder

menggali

domain

aplikasi

,

layanan

-

layanan

sistem

yang

harus

disediakan

,

unjuk

kerja

sistem

yang

diperlukan

,

batasan

-

batasan

perangkat

keras

dan

sejenisnya

Fokus

pada

A P A (

WHAT

)

dan

B U K A N

bagaimana

(

HOW

)

Via

(12)

Proses

:

Elisitasi

dan

Analisis

Tipe

kebutuhan

(

D. T. Ross & K. F.

Schoman

) :

–

Fungsional

(

functional

)

fungsi/kapabilitas

yang

harus

mampu

dijalankan

oleh

sistem

–

Non

fungsional

(

non

-

functional

)

performance

,

reliability

,

security

,

availability

,

constraints

,

dll

.

–

Inversi

(

inverse

)

apa

-

apa

yang

harus

tidak

boleh

dilakukan

sistem

–

Batasan

perancangan

&

implementasi

(

design &

implementation constraints

(13)

Proses

:

Elisitasi

dan

Analisis

Sumber

-

sumber

kebutuhan

:

Relatively high Relatively

low

Approximate % of requirements gathered from people

Type of application

highly constrained

missile guidance system

flight control system for airliner

enhancement to corporate accounting system manufacturing control system

corporate accounting system

encounter video game

decision support system

(14)

Proses

:

Elisitasi

dan

Analisis

Domain understanding Requirements checking Requirements collection Classification Prioritisation Conflict resolution Requirements definition Requirements specification

(15)

Proses

:

Elisitasi

dan

Analisis

(

Contoh

)

Perangkat

Perangkat lunaklunak harusharus mampumampu menyediakanmenyediakan saranasarana untuk

untuk menampilkanmenampilkan dandan mengaksesmengakses filefile--file yang file yang dibuatdibuat oleh

oleh tooltool yang lain. (yang lain. (ff)) Pengguna

Pengguna harusharus dapatdapat mencarimencari buku/dokumen/literaturbuku/dokumen/literatur di

di perpustakaanperpustakaan dgndgn memasukkanmemasukkan sebuahsebuah katakata kuncikunci. (. (ff)) Sistem

Sistem tidaktidak bolehboleh dioperasikandioperasikan oleholeh penggunapengguna yang yang tidak

tidak memilikimemiliki otoritasotoritas. (. (ii)) Sistem

Sistem harusharus menyediakanmenyediakan GUIGUI sehinggasehingga dapatdapat digunakan

digunakan secarasecara mudahmudah oleholeh penggunapengguna yang yang belumbelum berpengalaman

berpengalaman. (. (nn--ff)) Sistem

Sistem harusharus bisabisa memanfaatkanmemanfaatkan databasedatabase yang yang sudahsudah ada

ada. (. (dd--cc))

Sistem harus diimplementasikan dgn bahasa Java. (

(16)

Proses

:

Spesifikasi

Proses

Proses untukuntuk menjelaskanmenjelaskan kebutuhankebutuhan P/L yang P/L yang telahtelah didefinisikan

didefinisikan sebelumnyasebelumnya secarasecara lebihlebih detildetil dandan tepattepat yang

yang akanakan menjadimenjadi dasardasar bagibagi perancanganperancangan dandan implementasi

implementasi Definisi

Definisi kebutuhankebutuhan ((req. definitionreq. definition) :) :

1.

1. P/L P/L harusharus mampumampu menyediakanmenyediakan saranasarana untukuntuk menampilkanmenampilkan dan

dan mengaksesmengakses filefile--file yang file yang dibuatdibuat oleholeh tool yang lain. tool yang lain. (SRS_PRJ_100)

(SRS_PRJ_100)

Spesifikasi

Spesifikasi kebutuhankebutuhan ((req. specificationreq. specification) :) :

1.1

1.1 PenggunaPengguna harusharus disediakandisediakan fasilitasfasilitas untukuntuk mendefinisikanmendefinisikan tipe

tipe file. (SRS_PRJ_101)file. (SRS_PRJ_101) 1.2

1.2 SetiapSetiap tipetipe file direpresentasikanfile direpresentasikan dengandengan ikonikon tertentutertentu padapada layar

(17)

Proses

:

Validasi

(+

Verifikasi

)

Proses

Proses pengecekanpengecekan untukuntuk menjaminmenjamin bahwabahwa pernyataanpernyataan kebutuhan

kebutuhan yang yang telahtelah didefinisikandidefinisikan dandan dispesifikasikandispesifikasikan adalah

adalah benarbenar, , akuratakurat dandan lengkaplengkap Dilakukan bersama

Dilakukan bersama--sama antara kustomer dan sama antara kustomer dan developer

developer Sangat

Sangat pentingpenting dilakukandilakukan karenakarena kesalahankesalahan didi dalamdalam menentukan

menentukan kebutuhankebutuhan akanakan berdampakberdampak padapada keseluruhan

keseluruhan prosesproses yang yang mengikutinyamengikutinya Validasi

Validasi : : do we make the right product do we make the right product …….. ?.. ?

Verifikasi

Verifikasi :: do we make the product right do we make the product right …….. ?.. ?

Teknik Teknik ::

–

– ReviewReview : : Software Specification Review (SSR)Software Specification Review (SSR)

–

(18)

Proses

:

Validasi

(+

Verifikasi

)

Parameter

validasi

:

–

– ValidityValidity does the system provide the functions which does the system provide the functions which best support the customer

best support the customer’’s needs ?s needs ?

–

– ConsistencyConsistency are there any requirements conflicts ?are there any requirements conflicts ?

–

– ComprehensibilityComprehensibility are all functions required by the are all functions required by the customer included ?

customer included ?

Parameter

verifikasi

:

– – ReadabilityReadability – – TestabilityTestability – – CompletenessCompleteness – – IdentifiabilityIdentifiability

(19)

Proses

:

Manajemen

Kebutuhan

Aktifitas untuk melakukan kontrol terhadap

kebutuhan yang sedang maupun telah didefinisikan :

–

– IdentifikasiIdentifikasi bagaimanabagaimana setiapsetiap kebutuhankebutuhan dapatdapat diidentifikasi

diidentifikasi dengandengan mudahmudah (Cont. : SRS_PRJ_XXX, (Cont. : SRS_PRJ_XXX, IRS_PRJ_XXX)

IRS_PRJ_XXX) –

– ManajemenManajemen perubahanperubahan bagaimanabagaimana mekanismemekanisme untuk

untuk menanganimenangani perubahanperubahan kebutuhankebutuhan yang yang terjaditerjadi –

– DokumentasiDokumentasi SRS SRS dandan IRS IRS sebagaisebagai deliverable, deliverable, ECP, PCR

ECP, PCR –

– TrackingTracking penelusuranpenelusuran informasiinformasi yang yang berhubunganberhubungan dengan

dengan sebuahsebuah kebutuhankebutuhan ((sumber/asalsumber/asal, , alokasialokasi keke perancangan

(20)

Metode

:

Pemodelan

Bagian dari proses elisitasi/analisis dan spesifikasi Bagian dari proses elisitasi/analisis dan spesifikasi kebutuhan

kebutuhan Mengapa

Mengapa ::

–

– MemudahkanMemudahkan memahamimemahami dandan menganalisismenganalisis kebutuhankebutuhan –

– IdentifikasiIdentifikasi potensipotensi masalahmasalah lebihlebih awalawal

Model

Model ygyg baikbaik ::

–

– MengurangiMengurangi kompleksitaskompleksitas –

– MemfasilitasiMemfasilitasi penjelasanpenjelasan daridari permasalahanpermasalahan ygyg komplekskompleks –

– TidakTidak mahalmahal dandan mudahmudah untukuntuk modifikasimodifikasi

Structured Analysis

(21)

Metode

:

Structured Analysis

Pertama

kali

dipopulerkan

oleh

T.

T. DeMarco

DeMarco

(1979)

Structured Analysis and System

Specification

Perluasan

notasi

untuk

kebutuhan

real

-

time

systems

oleh

Hatley

dan

Pirbhai

(1987)

–

SA/RT

Strategies for Real

-

Time System Specification

Processes

(22)

Metode

:

Structured Analysis

Elemen

-

elemen

:

Data Dictionary Data Flow Diagram (DFD) ER Diagram State Transition Diagram (STD) Process Specification (PSPEC) Data Object Description Control

(23)

Metode

:

Structured Analysis

ER Diagram : ER Diagram :

–

– EntitasEntitas –

– ModalitasModalitas : : tingkattingkat mandatorymandatory –

– KardinalitasKardinalitas : : tingkattingkat relasirelasi –

– BentukBentuk relasirelasi

Manufacturer Builds Car

Data Flow Diagram (DFD) : Data Flow Diagram (DFD) :

–

– DFD level 0 : DFD level 0 : Context DiagramContext Diagram

–

– DFD level 1, dstDFD level 1, dst. : breakdown . : breakdown detildetil, , konsistensikonsistensi –

– Terminator, process, data flow, control flow, memory/storage, Terminator, process, data flow, control flow, memory/storage, control bar

(24)

Metode

:

Structured Analysis

Contoh

Data/Control Context Diagram

(DCD/CCD)

Vend product Customer returned coins 0* Customer product object customer selection slug coin return request product

(25)

Metode

:

Structured Analysis

Contoh

Data/Control Flow Diagram (DFD/CFD

level 1)

1* Get customer payment 2p Get product price 3p Validate payment 4p Get valid selection 5* Dispense change 6p Dispense product price table coins products returned coins product object customer selection slug coin return request payment price valid selection change due valid selection coin detected sufficient payment product dispensed product available product available

(26)

Metode

:

Structured Analysis

PSPEC

–

Validate payment (Process 3)

Inputs : payment (data in) price (data in)

Outputs : change due (data out)

sufficient payment (control out)

Body :

IF payment >= price THEN

change due = payment – price sufficient payment = TRUE ELSE

(27)

Metode

:

Structured Analysis

Data/Control Flow Diagram (DFD/CFD level 2) :

Dispense change

5.1p Get change coin coin return request 5.2p Get payment coin product available change due coins payment payment coins

(28)

Metode

:

Structured Analysis

CSPEC

–– Dispense change : Process Activation TableDispense change : Process Activation Table

1 1 0 0 FALSE FALSE D/C D/C 0 0 1 1 TRUE TRUE TRUE TRUE get get payment payment coin coin get change get change coin coin product product available available coin return coin return request request

(29)

Metode

:

Structured Analysis

State Transition Diagram (STD)

Waiting for a coin Waiting for selection Dispensing product Returning payment initial accept new coin

payment returned accept new coin coin detected

accept customer request product dispensed

accept new coin

sufficient payment dispense product

product available=FALSE

return payment coin return request

(30)

Metode

:

Structured Analysis

Data Dictionary

Representasi Simbol : = : composed of + : and { } : iterations of [….|…] : selection / or ( ) : optional “ “ : literal * * : comment/description Vend product (partly) :

Name Element Type

object [coin | slug](product) data product [ice cream | coffee | candy] data coins 0{[quarter | nickel | dime]}8 data product available [TRUE | FALSE] control

(31)

Metode

:

Structured Analysis

Beberapa

Beberapa panduanpanduan pemodelanpemodelan ::

–

– JumlahJumlah prosesproses dalamdalam satusatu diagram DFD : 4 diagram DFD : 4 ++ 22 –

– MaksMaks. 4 level . 4 level dekomposisidekomposisi (DFD/CFD)(DFD/CFD) –

– DekomposisiDekomposisi fungsionalfungsional (DFD) :(DFD) :

fungsi

fungsi--fungsifungsi yang yang salingsaling berhubunganberhubungan dikelompokkandikelompokkan fungsi

fungsi--fungsifungsi yang yang tidaktidak berhubunganberhubungan dipisahkandipisahkan setiap

setiap fungsifungsi dispesifikasidispesifikasi hanyahanya sekalisekali

–

– Data flowData flow membawamembawa informasiinformasi ygyg diperlukandiperlukan oleholeh sebuahsebuah prosesproses untuk

untuk transformasitransformasi, , control flowcontrol flow membawamembawa informasiinformasi yang yang harusharus diinterpretasikan

diinterpretasikan untukuntuk merubahmerubah perilakuperilaku sistemsistem dandan/ / aktifasiaktifasi prosesproses –

– ProsesProses pemodelanpemodelan DFD/CFD DFD/CFD adalahadalah prosesproses iterasiiterasi, , tidaktidak sekalisekali jadijadi –

– Context DiagramContext Diagram adalahadalah level level tertinggitertinggi daridari Data/Control Flow Data/Control Flow Diagram

Diagram

–

(32)

Metode

:

Object Oriented Analysis

Mulai

Mulai populerpopuler akhirakhir ’’80an 80an –– ’’90an (90an (BoochBooch, , Rumbaugh-Rumbaugh -OMT, Jacobson

OMT, Jacobson--OOSE, OOSE, Coad+YourdonCoad+Yourdon, , WirfsWirfs--Brock) :Brock) :

–

– ElisitasiElisitasi kebutuhankebutuhan customercustomer

–

– IdentifikasiIdentifikasi skenarioskenario / use/ use--case (case (useuse--case diagramcase diagram)) –

– IdentifikasiIdentifikasi klasklas berdasarkanberdasarkan kebutuhankebutuhan customercustomer

–

– IdentifikasiIdentifikasi atributatribut dandan operasioperasi setiapsetiap klasklas –

– DefinisiDefinisi strukturstruktur klasklas ((class diagramclass diagram)) –

– DefinisiDefinisi model model relasirelasi antarantar klasklas ((collaboration/sequence collaboration/sequence diagram

diagram)) –

– DefinisiDefinisi perpindahanperpindahan status status sistemsistem ((statechartstatechart diagramdiagram))

1996 : UML (

(33)

Object, Class

–

Apa

Itu

?

Objek

(

Object

) :

–

– Benda (Benda (tangible & intangible thingtangible & intangible thing)) –

– ContohContoh : : AndiAndi, , EkoEko, Susi , Susi –– dalamdalam sistemsistem akademikakademik perkuliahan

perkuliahan –

– SebuahSebuah objekobjek memilikimemiliki karakteristikkarakteristik : : identity identity

(

(identitasidentitas), ), statestate ((sekumpulansekumpulan atributatribut) & ) & behaviourbehaviour

(

(sekumpulansekumpulan operasioperasi))

Notasi

:

Nama

Nama ObjekObjek Atribut2 Atribut2 Operasi2 Operasi2

(34)

Object, Class

–

Apa

Itu

?

Klas

(

Class

) :

–

– GambaranGambaran umumumum ((template, bluetemplate, blue--printprint) yang ) yang menjelaskanmenjelaskan sekumpulan

sekumpulan objekobjek yang yang memilikimemiliki kesamaankesamaan karakteristikkarakteristik (

(atributatribut dandan operasioperasi)) –

– MerupakanMerupakan cetakancetakan daridari objekobjek –

– DigunakanDigunakan untukuntuk menginstansiasimenginstansiasi objekobjek yang yang memilikimemiliki identitas

identitas yang yang berbedaberbeda –

– ContohContoh : : KlasKlas MahasiswaMahasiswa objekobjek AndiAndi, , EkoEko, Susi , Susi –

– KlasKlas AbstrakAbstrak dandan KonkretKonkret ((abstract & concrete classabstract & concrete class)) –

– AbstrakAbstrak : : tidaktidak bisabisa diinstansiasidiinstansiasi, , sebagaisebagai interfaceinterface ((harusharus ada

(35)

Object, Class

–

Apa

Itu

?

Mahasiswa Mahasiswa -- NIMNIM -- NamaNama

-- BuatBuat skripsiskripsi -- UjianUjian Mahasiswa Mahasiswa -- NIM : 001NIM : 001

-- NamaNama : : AndiAndi

-- BuatBuat skripsiskripsi

-- UjianUjian

Mahasiswa

Mahasiswa : Andi: Andi

Mahasiswa Mahasiswa

-- NIM : 002NIM : 002

-- NamaNama : : EkoEko

-- UjianUjian

Mahasiswa

Mahasiswa : Eko: Eko

Mahasiswa Mahasiswa

-- NIM : 003NIM : 003

-- NamaNama : Susi: Susi

-- UjianUjian

Mahasiswa

Mahasiswa : Susi: Susi Instansiasi

Instansiasi : : penciptaan

(36)

Metode

:

Object Oriented Analysis

–

UML

Diagram

utama

:

–

– UseUse--case diagramcase diagram ((statisstatis)) –

– Class diagramClass diagram (statis(statis)) –

– Collaboration/sequence diagramCollaboration/sequence diagram ((dinamisdinamis)) –

– StatechartStatechart diagramdiagram ((dinamisdinamis))

Use

-

case diagram

:

–

– MenjelaskanMenjelaskan perilakuperilaku sistemsistem daridari tampaktampak luarluar –

– MenyediakanMenyediakan fungsifungsi-fungsi-fungsi ygyg harusharus dipenuhidipenuhi sistemsistem –

– AktorAktor ((orangorang, , sistemsistem lain) lain) dandan useuse--casecase

–

(37)

Metode

:

Object Oriented Analysis

–

UML

Use

-

case diagram :

Select product

Get return coins Customer

(38)

Metode

:

Object Oriented Analysis

–

UML

Use

Use--case scenariocase scenario ::

Customer

Actors Actors

1.

1. If the selected product is not available, the system will If the selected product is not available, the system will display a message

display a message ““Your selected product is not availableYour selected product is not available””..

2.

2. If the selected product is available but there isnIf the selected product is available but there isn’’t enough t enough number to order, the system will display a

number to order, the system will display a messangemessange ““The The

number isn

number isn’’t enough, max. xt enough, max. x”. X is the existing number of the ”. X is the existing number of the

product.

Alternative flows Alternative flows

1.

1. The customer selects a button product.The customer selects a button product. 2.

2. The system displays an entry prompt of number of product The system displays an entry prompt of number of product to order.

to order.

Main flow Main flow

Coin detected and valid

Pre

Pre--conditioncondition

Allow customer to select a certain product to dispense

Objective Objective

Flow of events for the

(39)

Metode

:

Object Oriented Analysis

–

UML

Class diagram (

‘

is a

’

-

inheritance)

:

Product name : String description : String price : Currency getName() : String getDescription() : String getPrice() : Currency setName(newName : String) setDescription(newDescription : String) setPrice(newPrice : Currency) Candy weight : double t ast e : String Coffee volume : double sugarContent : double type : String Ice Cream weight : double milkContent : double

(40)

Metode

:

Object Oriented Analysis

–

UML

Class diagram (

‘

part of

’

-

aggregation)

:

Product name : String

description : St ring price : Currency getName() : String getDescript ion() : String getP rice() : Currency

setName(newName : String) Products

getP roduct(name : String) : Product

isP roductAvailable(name : String) : boolean

0..* 0..*

(41)

Metode

:

Object Oriented Analysis

–

UML

Sequence diagram

:

: Customer : SelectionScreen : SelectionController : Products :

DispenserProduct

selectProduct( )

getValidSelection(String)

isProductAvailable(String)

(42)

Alat Bantu + Dokumentasi : Alat Bantu

Structured Analysis

:

–

– AplikasiAplikasi pengolahpengolah model : Visio, dllmodel : Visio, dll.. –

– AplikasiAplikasi pengolahpengolah katakata : MS Word, : MS Word, dlldll.. –

– CASE Tool : CASE Tool : StPStP ((Software through PictureSoftware through Picture), PSL/PSA ), PSL/PSA (

(Problem Statement Language/Problem Statement Problem Statement Language/Problem Statement Anaylzer

Anaylzer), ), ILeafILeaf, SPMS, , SPMS, dlldll..

OO Analysis

:

–

– AplikasiAplikasi pengolahpengolah model : Visio, model : Visio, dlldll.. –

– AplikasiAplikasi pengolahpengolah katakata : MS Word, dll: MS Word, dll.. –

(43)

Alat Bantu + Dokumentasi : Dokumentasi

IEEE Standard+ (IRS/SRS):

1.

1. IntroductionIntroduction 1.1.

1.1. Purpose of the requirements documentPurpose of the requirements document 1.2.

1.2. Scope of the productScope of the product 1.3.

1.3. Definition, acronyms and abbreviationsDefinition, acronyms and abbreviations 1.4.

1.4. ReferencesReferences 2.

2. General DescriptionGeneral Description 2.1.

2.1. Product perspectiveProduct perspective 2.2.

2.2. Product functionsProduct functions 2.3.

2.3. User characteristicsUser characteristics 2.4.

2.4. General constraintsGeneral constraints 3.

3. Specific RequirementsSpecific Requirements All functional and non

All functional and non--functional requirements, system models (functional requirements, system models (egeg. DFD/CFD, ERD, . DFD/CFD, ERD, STD, Use

STD, Use--Case, Class, Sequence, Case, Class, Sequence, StatechartStatechart diagrams), performance, database diagrams), performance, database requirements, design constraints, security.

requirements, design constraints, security.

3.

3. Qualification/Validation RequirementsQualification/Validation Requirements 4.