1

Modul 2

Data, Informasi,
Pengetahuan
II2240 Analisis Kebutuhan Sistem

Dicky Prima Satya, S.T., M.T.

Sistem & Teknologi Informasi – STEI ITB

2

Data (Datum)
• Satu atau lebih simbol yang digunakan untuk merepresentasikan sesuatu
• Runutan fakta mentah, informasi yang tidak terformat menggambarkan penomena
khusus
• Fakta mentah tentang orang, tempat, kejadian dan sesuatu yang penting dalam suatu
organisasi.
• Kumpulan item a.l. kata, angka, gambar dan suara yang tidak teriorganisir dan hanya
berarti kecil bagi individu / bagi perorangan.
• Nilai atomik, biasanya dapat diaplikasikan ke obyek individu dari suatu domain tertentu
• Data (atau capta) merupakan bahan mentah masukan kedalam SI, atau fakta dari
beberapa kepentingan pemakai SI
• Deskripsi tentang benda, kejadian, aktivitas, dan transaksi, yang tidak mempunyai makna
atau tidak berpengaruh secara langsung kepada pemakai
• Misal: 6.30 27 6.32 28 6.34 27. Apa artinya?
3

Informasi
• Data yang telah diproses atau direorganisasi sehingga lebih berarti atau
memberikan nilai tambah pada seseorang/penerima (mempunyai arti dalam
suatu konteks khusus)
• Interpretasi, generalisasi atau validasi dari data faktual umumnya dapat
diaplikasikan untuk kelompok atau subset dari domain yang diminati
• Dapat juga dilihat informasi sebagai data yang diinterpretasikan dalam
beberapa arti suatu konteks.
• Informasi mempunyai dimensi waktu/tempo, sangat berarti pada suatu
waktu tetapi menjadi tidak relevan lagi pada waktu yang berbeda.
• Informasi dapat berarti bagi seseorang tetapi tidak bagi orang lain- karena
tiap orang mempunyai kepentingan yang lain pada waktu yang berbeda
4

Data vs Informasi
• Bandingkan 1.30 35 2.45 37 3.15 39 dengan

• Adakah artinya?
5

Data vs Informasi
• Data dapat berupa nilai yang terformat, teks, citra, audio,dan video.
• Data yang terformat adalah data dengan suatu format tertentu;
misalnya data yang menyatakan tanggal atau jam, atau menyatakan
nilai mata uang.
• Teks adalah sederetan huruf, angka, dan simbol-symbol khusus
(misalnya + dan $) yang kombinasinya tak tergantung masing-masing
item secara individual.
• Contoh teks adalah artikel koran.
6

Data vs Informasi
• Citra (image) adalah data dalam bentuk gambar. Citra dapat berupa
grafik, foto, hasil rontgen, dan tanda tangan, ataupun gambar yang
lain.
• Audio adalah data dalam bentuk suara. Instrumen musik, suara orang
atau suara binatang, gemericik air, detak jantung merupakan beberapa
contoh data audio
• Video menyatakan data dalam bentuk sejumlah gambar yang
bergerak dan bisa saja dilengkapi dengan suara.Video dapat
digunakan untuk mengabadikan suatu kejadian atau aktivitas
7

Data vs Informasi
• Informasi sebagai data yang telah diproses sedemikian rupa sehingga
meningkatkan pengetahuan sesorang yang menggunakan data
tersebut (McFadden dkk 1999).
• Informasi adalah “jumlah ketidakpastian yang dikurangi ketika sebuah
pesan diterima” (Shannon dan Weaver).
• Artinya, dengan adanya informasi, tingkat kepastian menjadi
meningkat.
• Informasi adalah data yang telah diolah menjadi sebuah bentuk yang
berarti bagi penerimanya dan bermanfaat dalam pengambilan
keputusan saat ini atau saat mendatang (Davis 1999)
8

Data vs Informasi
9

Siklus Informasi
• Data dan Informasi membentuk suatu siklus
• (Burch dan Grudnitski, 1989)
10

Makna Informasi
• Makna informasi itu bersifat relatif terhadap pemakai
• Bagi seseorang informasi itu bermakna, tetapi bagi orang lain
mungkin tidak
11
Kandungan Informasi
(Davis, 1999)
• Benar atau salah. Dalam hal ini, informasi berhubungan dengan
kebenaran terhadap kenyataan. Jika penerima informasi yang salah
mempercayainya, efeknya seperti kalau informasi itu benar
• Baru. Informasi benar-benar baru bagi si penerima.
• Tambahan. Informasi dapat memperbaharui atau memberikan
perubahan terhadap informasi yang telah ada.
• Korektif. Informasi dapat digunakan untuk melakukan koreksi
terhadap informasi sebelumnya yang salah atau kurang benar
• Penegas. Informasi dapat mempertegas informasi yang telah ada,
sehingga keyakinan terhadap informasi semakin meningkat
12

Pengetahuan
• Pengetahuan (knowledge) adalah kombinasi dari naluri, gagasan, aturan,
dan prosedur yang mengarahkan tindakan atau keputusan (Alter, 1992)
• Informasi yang dipadukan dengan pengalaman masa lalu dan keahlian akan
memberikan suatu pengetahuan yang tentu saja memiliki nilai yang tinggi
• Proses dimana data diubah jadi informasi yang penuh arti dan mengarah
kepada struktur lebih besar dari informasi yang terkait
• Hubungan pemahaman antara informasi dengan informasi lainnya
• Telah dibuktikan dan teruji dapat digunakan dengan valid pada situasi
berbeda
13

Pengetahuan
• Data dan informasi lebih lanjut dimurnikan berdasarkan fakta-fakta,
kebenaran-kebenaran, kepercayaan-kepercayaan, penilaianpenilaian,
pengalaman-pengalaman, dan keahlian dari penerima.
• Struktur yang lebih besar, hidup lebih panjang dikenal sebagai
pengetahuan.
• Struktur yang lebih besar sering terintegrasi dengan pengetahuan
yang ada untuk menciptakan satu pengetahuan yang diperbaiki di
dalam konteks itu.
• Pengetahuan dapat juga dimengerti sebagai satu pemahaman dari
informasi yang berarti, atau yang disiratkan.
14

Pengetahuan
• Pekerja Berpengetahuan (Knowledge Worker)
• Profesional yang berpendidikan, yang mengkreasikan,memodifikasi atau mensintesakan
pengetahuan pada suatu profesi.
• Masyarakat Pengetahuan (Knowledge Society)
• Juga sering disebut masyarakat digital, ekonomi baru
• Bekerja dengan otak melebihi tangan
• Pentingnya pendidikan
• Perangkat digital
• • Manajemen Aset Pengetahuan (Knowledge Asset Management)
• Menghargai data, informasi dan pengetahuan sebagai sumberdaya kritikal dalam
usaha
• Bagaimana organisasi dapat mengelola dan berbagi pengetahuan agar unggul berkompetisi?
• Strives to integrate the data and information that can create and preserve knowledge
15
16
Data, Informasi, Pengetahuan,
Kebijaksanaan
• Data: fakta mentah, belum terformat
• Information: data yang sudah diproses (berarti)
• Knowledge: pengertian hubungan baik antar potongan informasi
(struktur); pola; pengalaman (diaplikasikan untuk suatu tipe
persoalan)
• Wisdom: pengetahuan yang diakumulasikan dan diaplikasikan.
17
18
19

Atribut dari Kualitas Informasi

20

Informasi sebagai Sumberdaya Kunci

21

Terima Kasih
1

Modul 3

System Development
Process
II2240 Analisis Kebutuhan Sistem

Dicky Prima Satya, S.T., M.T.

Sistem & Teknologi Informasi – STEI ITB Sumber: Jeffry O. Grady, System Requirement Analysis, Elsevier, 2006
2

Creating A System
• Precedented System
• Current system/existing system transforms into a new/future system
• Unprecedented System
• When developing an unprecedented system there is no existing predecessor
system that can be observed functioning and little or no available descriptive
informationon what it might do or how it might be created.
• The way we begin this process is through a series of models of the system we are
creating.
3

System Development Process (1)

• Transform the problem space into a set of models that represent the problem
space and from which essential characteristics that a design solution must
possess can be derived andincluded in a set of specifications applying to the
entities and interfaces of the system. The product entities and interfaces are
modeled in a set of solution space models along with specialty engineering or
quality characteristics and environmental influences from which the final set of
requirements are derived to complete the specification development work.
• Transform the modeling work into a set of requirements for each entity identified
in the product entity model and interface defined in an interface model.
• Transform the content of the specifications into design solutions that respect the
content of those specifications. This is the creative design process accomplished
by teams of specialists.
• Transform knowledge of the design solution into procurement sources,
manufacturing planning, and quality assurance planning.
4

System Development Process (2)

• Transform sets of plans, procedures, and materials into physical product including
the procurement and/or manufacture of computer software as well as hardware
entities.
• Transform specification content into a set of comprehensive plans and procedures
to guide verification that a product design satisfies its requirements.
• Transform the verification plans and procedures into the accomplishment of the
related tasks on product entities that produce evidence of the relationship
between the product requirements and the features of the product design and
audit that evidence supporting a conclusion that the product does or does not
satisfy the requirements.
• Transform the availability of physical product into delivery of that product to
customers, collect revenue, and logistically sustain the system over its life.
5

System Development Transformation

6

Model
• Model → a standard or example for imitation or comparison, a
representation, generally in miniature, to show the construction or
appearance of something
• It is a representation to show the construction or purpose of a system
that does not yet exist
• Every model is wrong to the extent that it is a representation of a
system focusing on only certain aspects of the problem space but we
may gain great advantage from models.
7

Principal facets of problem space

• Three principal facets of problem space that are commonly addressed
by modeling approaches:
• We are interested in what the system must accomplish, its functionality →
functional model
• We are interested in what the system must consist of, its entity, static, object,
or physical perspective → structure/entity model
• we are interested in how the system and its entities must behave while
accomplishing needed functionality → behavioral model
8

“Which facet should be pursued first?”

9

Best Practice
• Best practice: forms follows function

• First we should determine what we expect the system to do and then

we should determine what is going to accomplish that functionality.
10

Debate?
• Many computer software engineers who embrace the early object-
oriented model believe that one should first identify the static objects
in the problem space and then determine the dynamic behavior of
those objects.
• Clearly this is the reverse of what we encouraged
• OOA modeling approach is the only modeling approach where the
analyst is encouraged to enter the problem space on the entity facet.
• OOA approach would be adequate for developing a precedented
system (a new payroll system) but not for use with an unprecedented
system.
11

Principal facets of problem space

We will explore these facets in more detail later.
12

Problem Space Modeling Fundamentals

• Different modeling approaches call for different
representations of the functional, entity, and behavioral facets.
Some models do not make a significant distinction between
the functional and behavioral facets.
• In some cases these graphics are very intense and in others
very simple.
• The meaning expressed by simple models like, for example,
functional flow diagramming, passes very easily into the
human mind through vision but the message conveyed is
relatively simple.
• More complex graphics, such as those used in IDEF-0,
behavioral diagramming, or enhanced functional flow block
diagramming, pass with more difficulty into the human mind
through vision but do convey a richer picture of the problem
space in the process.
13

Problem Space Modeling Fundamentals

• We must model the problem space from all three perspectives more
or less simultaneously all the while recognizing that modeling work on
one facet will have effects on the others.
• In the process of modeling the problem space we have also derived
essential characteristics from the features of the images crafted
about the problem space and these become requirements for the
entities depicted on the entity facet.
14

Requirement Fundamentals
There are some ideas about requirements that we must master before moving on to modeling
15

The Essence of a Requirement

• A requirement is an essential attribute or characteristic for a system
or an element of a system. The attribute is coupled with value and
units information for the attribute by a relation statement.
• A normal requirement statement is a written statement of a
requirement in one or more complete sentences in a language familiar
to the customer using the idiom of the particular business sector
(aerospace for example).
• Characteristics including
• (i) proper grammar,
• (ii) appropriate use of shall, will, and other key words, and
• (iii) rigid compliance with a format.
16

Primitive Requirement Statement

• If we strip away all of the style and format common to a paragraph in a
specification, we are left with a residue that we will call a primitive
requirements statement. You can combine several of these primitive
statements to form a very simple requirements document for an entity.
• This simple document can be used by anyone to easily and inexpensively
document the requirements for the system or entity very early in the
development process before formal specifications are needed.
• As the need for formality increases to support detailed design or
procurement, this primitive requirements list may be converted into a
specification of the appropriate type using conversion logic covered in this
section.
17

CRL
• CRL → list of primitive requirement statement
• Concept requirements list, consists of
• a cover page and
• as many pages of requirements as needed.
• Each page contains primitive requirements
• statements. These statements are numbered from 1 through “n”.
18

Primitive requirement statement

19

The CRL Cover

• Identification of the element by item title and product entity number,
• Work breakdown structure (WBS) identification or chapter number
• A date and document number.
• The engineer responsible for preparing the document (normally the
principal engineer for the entity) and the project, program, proposal,
or lead engineering person should sign the cover page to indicate it is
an element of the concept baseline.
20

The CRL Cover

21

The CRL Body

• Composed of one or more pages of numbered primitive requirements
statements
• Simply number the primitive statements from 1 to “n”
• If, after the initial list is published, it is necessary to delete a
statement embedded within the list, it and its number should be
deleted without changing the other statement numbers. Or the
deleted statement may be retained followed by the word “Deleted.”
• May include any of the simple block diagrams defined in subordinate
paragraphs. When included they should be referenced in a primitive
requirements statement.
22

The CRL Body

23

Block Diagram of CRL

• Product entity block diagram. A product entity block diagram is a
hierarchical diagram consisting of simple blocks depicting the
elements of a system illustrating the family structure of the system.
• Schematic block diagram (SBD). An SBD illustrates the interfaces
required in a system or element thereof by connecting blocks from
the product entity block diagram with lines.
• Functional Flow Diagram (FFD)
• Process Flow Diagram (PFD)
• Timeline Diagram (TLD)
24

Terima Kasih
1

Modul 4

Requirements
Foundation
II2240 Analisis Kebutuhan Sistem

Dicky Prima Satya, S.T., M.T.

Sistem & Teknologi Informasi – STEI ITB Sumber: Jeffry O. Grady, System Requirement Analysis, Elsevier, 2006
2
Primitive Requirement Statement
Conversion
• At some point the CRL should transition into a
specification with the normal, complete requirements
document structure.
• At that time, the principal engineer may convert the CRL
content very easily into complete English sentences. At the
same time it will be necessary to organize the requirements
into the prescribed template paragraphing structure.
• Tips:
• Add a subject, add a shall verb, provide a sentence ending,
provide a paragraph title and number, additional data, and
total effect of changes (see Jeffrey O. Grady (2014) System
Requirement Analysis 2nd Edition page 97-98)
3
Primitive Requirement Statement
Conversion
• By way of example, assume an original primitive requirements
statement for a liquid hydrogen valve of, “Closure time less than or
equal to 0.5 s.”
• Complete requirement statement:
3.2.4 Valve closure time. Valve closure time shall be less than or equal to 0.5
s. Valve closure time is measured from the time the controlling signal reaches
50.0% of its nominal value until flow through the valve drops to zero.
4

Some requirements will invariably be of a

qualitative kind existential requirements being an
example. But the norm should be that
requirements contain numbers making related
magnitudes clear.
5
Why is requirements quantification
important?
• A requirement states a necessary attribute of an item yet to be designed.
• How can the designer possibly design an item for an attribute without the
attribute magnitude being characterized?
• In the absence of quantification, there is an excellent chance for failure in
the form of:
• (1) exceeding the minimum necessary cost due to overdesign or
• (2) failing to account for needed capability that reduces item value to the customer.
• Quantitative requirements are also necessary in order to adequately verify
the produced item satisfies its requirements.
• Test planning activities focused on requirements verification must define
pass/fail criteria and this is very hard to do for qualitatively stated
requirements.
6

Value definition methods

• The assignment of a value to a requirement can be done through an
application of good judgment based on information acquired through
some rational process including:
• (1) a market survey to find out what industry is doing or what customers
prefer,
• (2) experience with the product line and customer needs,
• (3) an appeal to authority such as the customer or program engineering
management, or
• (4) reference to industry or customer standards for values proven in past
practice or testing.
• (5) use of a flow down modeling technique.
7

Requirements Derivation
• Two types of requirement based on the source:
• (1) source or customer requirements, and
• (2) derived requirements.
• One motivation for this feeling is that externally identified
requirements cannot be changed while derived requirements are
under the control of the engineer and are often enforced by the
design decisions made by the engineer.
• Design solution at one level can and should influence the
requirements for lower-tier elements.
8

Requirements Derivation
• A requirement is identified by deriving it from a model and then
defined through the application of a relevant analytical discipline
• For example, the fact that item A132 must have a reliability requirement is
identified by the reliability math model including item A132. A performance
requirement is derived from a function included in an FFD and defined as a
result of analysis of just how well the system must accomplish that
functionality.
• It can be supported by using a requirements analysis sheet (RAS),
ideally captured in a requirements database in a computer application,
as the means by which we relate all requirements and the models
from which they were derived and the product entities to which they
are allocated.
9

Kind of Requirements
• Performance requirements
• what the system or item must do and how well it must be done.
• Design constraints
• A design constraint, or simply a constraint, is a boundary condition within
which the designer must remain while satisfying the aggregate of the
performance requirements for the item.
• Some engineers assign a more general meaning to the word constraint as
anything that bounds their design prerogatives
10

Constraints
• Three major categories form the body of constraints :
• (1) interface,
• Interface requirements analysis identifies physical and functional
relationships between system elements and between system elements
and the system environment.
• (2) environment, and
• Environmental requirements analysis identifies conditions that are
expected to be encountered during storage, shipment, and operation
from natural, hostile, non-cooperative and self-induced sources (e.g.,
thermal, vibration, g-loading, acoustics, humidity, etc.).
• (3) specialty engineering.
• The specialties include reliability, maintainability, producibility, mass
properties, electromagnetic interference/electromagnetic
compatibility, and many others that will be listed later. In each case,
the specialty engineer works to identify a minimum set of
characteristics that each system element must have to satisfy
program requirements for that specialty engineering discipline.
11

Why Requirements Traceability?

• A record of the traceability between requirements for system
elements affords customer and company management an opportunity
to monitor development team progress by providing insights
• This data can stimulate the right questions that help to maintain
team focus on efforts to satisfy the customer’s need.
• The traceability data can be used to trace higher order requirements
changes throughout the design to help determine what must be
changed in the lower tiers to satisfy a higher-level requirements
change.
12

Requirements Traceability
Three-dimensional Traceability
13

Requirements Traceability
• Vertical Traceability
• from the original user system documentation through to the formal system
specification and from there down through all of the program specifications
• Parent-child requirements traceability
• Requirements source traceability
• Requirements rationale traceability
• Longitudinal Traceability
• from the content of the specifications through the design and verification
information stream
• Lateral Traceability
• traceability to the modeling source from which the requirement was derived
14

Program-wide Requirements Traceability

15

Vertical Traceability

Parent-child requirements traceability

• Vertical parent–child
requirements traceability is
a condition of clear
knowledge of the ancestry
of that requirement in
terms of the parent
requirements that make it
necessary for the design of
the lower-tier element to
respect that requirement.
• Every requirement for
every system entity should
theoretically be ultimately
traceable to the customer
need
16

Vertical Traceability

Requirements Source Traceability

• A requirements source statement identifies where the
requirement came from.
17

Vertical Traceability

Requirements Rational Traceability

• A requirements rationale statement include reasons why
the requirement is included and/or the basis for the value
identified.
18

Longitudinal Traceability

Requirements Traceability to Design

• The engineering drawings and software code reflect the design of the
product driven by the content of the item performance specification and
ideally it should in some fashion be traceable to the content of the
specification
• This form of traceability, if developed would perhaps better be captured in
the entity detail specification than the performance specification. The detail
specification should be design-dependent, driven by the product design.
This content includes a selection of the most significant design features
that should be used as the basis for the article acceptance process at the
end of the manufacturing process.
19

Longitudinal Traceability

Requirements Traceability to Verification

• The specification should include a table giving traceability between product
requirements appearing in Section 3 and verification requirement is Section
4.
• This table should also identify the inspection method to be applied in
determining the extent to which the design complies with the requirement.
• Four methods are recognized by many people: test, analysis, demonstration, and
examination.
• Completion of this table marks the end of the systems requirements
activity and the beginning of the systems verification activity.
20

Longitudinal Traceability

Requirements
Traceability to
Verification
21

Lateral Traceability

• Ideally, the requirements published in every specification would be derived

from a model and we should be able to capture the traceability between
those models and the content of the specifications.
• It would be best if the modeling capability existed in the same computer
application that the requirements text management capability existed but
there are few if any such combinations.
• Models will be offered in this book for interface, specialty engineering, and
environmental modeling from which requirements in these areas can be
derived with linkage to modeling artifacts. Two other problem space models
apply a combination of MSA-PSARE and a combination of UML-SysML
modeling artifacts also coordinated with an MID arrangement.
22

Requirements Traceability to Process

• We should understand by now that requirements analysis is not

accomplished well in today’s work environment by individualists, but
rather by a team of specialists cooperating toward a common goal.
• Each of these specialists is performing requirements analysis for a
specific discipline across the whole system or in the context of a
particular product entity scope. Each of these specialists should have
some means of independently collecting and reporting the results of
their analysis.
• It needs some tools to process.
23

Requirements Traceability to Process

Single-Sheet Traceability
• While requirements analysis process traceability information can best
and most economically be captured in a computer database approach,
it is possible to do it manually.
• Note that this sheet will capture only a single allocation of a function
to an architecture element and the definition of only a single
performance requirement from that allocation.
24

Requirements Traceability to Process

Single-Sheet Traceability
25

Requirements Traceability to Process

Specification Template Traceability

• The content of each template should be mapped to a preferred
method for defining the content for each major paragraph heading,
the functional department from which a program would obtain the
specialist needed to perform the related work (DEPT), and the
appendix (APP) of the program system architecture report (SAR)
where the model data is captured.
26

Requirements Traceability to Process

Specification Template Traceability

27
28

Terima Kasih
1

Modul 5

Requirements Analysis
Strategies
II2240 Analisis Kebutuhan Sistem

Dicky Prima Satya, S.T., M.T.

Sistem & Teknologi Informasi – STEI ITB Sumber: Jeffry O. Grady, System Requirement Analysis, Elsevier, 2006
2

The Four Strategies

• All requirements analysis work can be collected under one of four

fundamental strategies: (i) structured analysis or modeling, (ii)
cloning, (iii) freestyle, and (iv) question and answer.
• A program engineering team can select one of these strategies for use
throughout a program in all phases, use some single combination of
them throughout the development process, or move from one
strategy, or set of strategies, to another as the program and system
mature.
3

Requirements Analysis Strategy

• (1) structured analysis,
• The structured analysis strategy provides an organized, systematic
environment within which to decompose a large problem into a
series of smaller ones such that solution of all of the smaller, more
specialized problems results in a solution to the larger one.
• (2) cloning,
• A program that is already established with a large library of
specifications, however they were created, can have a very successful
requirements analysis experience. Such a program has a tremendous
storehouse of requirements already in existence in the form of the
many specifications on hand.
• (3) freestyle
• It is possible for an experienced system engineer, familiar with the
product line appropriate to the customer need, to craft a system
requirements document for the system based on a customer need
statement and minimal additional information entirely from scratch
on a word processor.
• (4) question and answer
• the developing agent asking the customer questions about their
needs and formatting the answers into requirements for inclusion in
top-level specifications. It is not effective as a sole requirements
identification technique because it is not, of itself, structured or
organized.
4

Freestyle Strategy

• It is possible for an experienced system engineer, familiar with the

product line appropriate to the customer need, to craft a system
requirements document for the system based on a customer need
statement and minimal additional information entirely from scratch
on a word processor.
• We call this a freestyle approach since the engineer makes no obvious
appeal to any kind of structure as a way of gaining insight into the
appropriate set of requirements.
5

Freestyle Strategy
6

Freestyle Strategy
• Freestyle carries with it the danger of possible
incompleteness due to lack of rigor in the analysis
process.
• It requires a very experienced analyst to have any hope
that this approach will succeed. Regardless who does the
work, the results should be scrutinized carefully by
project personnel most familiar with the customer’s
needs.
• It is a great truth that we cannot see our own mistakes,
but that anyone else will see them clearly. So, we should
always take advantage of the low cost of criticism
through peer review.
7

Freestyle Strategy
• When this strategy is followed as the only requirements
analysis approach on a large program, it can be characterized
as chaos. There is a likelihood that the principal engineers
responsible for the many lower-tier specifications will not
effectively communicate with each other in any organized way
and that the requirements for lower-tier items will not be
properly influenced by the system requirements. As a result,
the system created from the integration of the lower-tier
items designed and produced from those requirements will be
unlikely to satisfy the need to the customer’s full satisfaction.
• While freestyle can be useful when accomplished under
certain conditions by a skilled practitioner. It is encouraged to
migrate to a more organized process using at least some of the
modeling methods.
8

Cloning Strategy
• A program that is already established with a large library
of specifications, however they were created, can have a
very successful requirements analysis experience without
applying the structured analysis approach preferred in
Grady.
• Such a program has a tremendous storehouse of
requirements already in existence in the form of the
many specifications on hand. While one may question the
quality of that storehouse as a function of how it was
obtained in the first place, it has probably withstood the
test of time.
• These documents can be used as an inspiration for others
through a process called cloning, which is a scheme for
using an existing document as the basis for another.
9

Cloning Strategy

Three cloning methodologies

10

Cloning Strategy
• Methodologies – Specification Standards (Boilerplate)
• A specification standard is a document that contains a set
of standard requirements applicable to a range of system
items.
• When an engineer must prepare a particular specification,
he or she can select a copy of the closest standard and edit
it, in accordance with a set of instructions, into the new
specification.
• In the process of editing, the results of the requirements
analysis process are included in the document in place of
generic placeholders.
• A commonly used word for this kind of standard is the
term “boilerplate”.
11

Cloning Strategy
• Methodologies – Specification Standards (Boilerplate)
• A boilerplate can be prepared for a whole class of specifications,
such as a procurement specification boilerplate, etc.
• Essential elements of a boilerplate include standard structure,
content definition, and formatting, an approved applicable
documents list coordinated with contract requirements, and
standard environmental requirements that account for planned
test program needs.
• A principal engineer uses the boilerplate to gain insight into at
least some of the requirements attributes that should be
considered and places the results of the requirements analysis
process implemented for the item into the context of a copy of
the standard to arrive at a complete program-peculiar
specification.
12

Cloning Strategy
• Methodologies – Specification Standards (Boilerplate)
• This technique is very effective to the extent that the
principal appeals to a standard list of applicable
documents, not all of which are used); the constraints
portion; and the text and verification matrix format.
• It cannot be effective in the performance requirements
because these vary so widely as a function of the specific
kind of item. A standard is also of little value in interface
requirements definition.
13

Cloning Strategy
• Methodologies – Like Item Approach
• The like item approach entails the use of an existing
specification covering a similar item as a basis for a new
specification.
• A sound approach here is to obtain an electronic copy of
the existing specification and edit it into the new one by
changing a few appropriate details.
14

Cloning Strategy
• Methodologies – Parent Item, Flow Down, or Allocation
Approach
• The third cloning approach involves using the parent item
specification as the basis for the new specification rather
than a like item specification.
• In this case, the requirements analysis approach that will
be most effective is a flow down methodology. The
requirements called out in the parent item are allocated
to the subordinate item and form the basis for the
differences introduced through editing a copy of the
parent specification. This topic extends to a discussion of
margins and budgets.
15

Question and Answer Strategy

• The third strategy involves the developing agent asking
the customer questions about their needs and formatting
the answers into requirements for inclusion in top-level
specifications.
• This process should be part of every requirements
analysis activity. It is not effective as a sole RID technique
because it is not, of itself, structured or organized.
• The key to this process providing any useful information
is that good questions are asked of people who know the
answers. So, those who would ask the questions need
some kind of machinery to encourage good questions
and all of them of interest. Also, these questions must be
asked of people who have knowledge.
16

Question and Answer Strategy

• Q and A combined with structured analysis provides

the best combination since it uses simple pictures
(models) to stimulate a conversation between one
party with questions and another who may have
answers.
• These models communicate with the minds of the
parties using the most efficient way of getting
information into the mind of man, that is through
vision, and therefore encourage discussion and
refinement of the meaning. They encourage common
understanding and completeness as well.
17
Structured Analysis or Modelling
Strategy*
• The structured analysis strategy provides an
organized, systematic environment within which to
decompose a large problem into a series of smaller
ones such that solution of all of the smaller, more
specialized problems results in a solution to the
larger one.
• Structured analysis applies a general model to the
solution of a specific problem such that the model
encourages us to think of all of the factors of
importance in arriving at a clear definition of the
problem while allowing us to remain undistracted by
unrelated factors.
18

Terima Kasih
1

Modul 6

The Functional Problem

Space Model
II2240 Analisis Kebutuhan Sistem

Dicky Prima Satya, S.T., M.T.

Sistem & Teknologi Informasi – STEI ITB Sumber: Jeffry O. Grady, System Requirement Analysis, Elsevier, 2006
2

System Beginnings
• Problem space modeling techniques are valuable tools for uncovering the
right questions to ask about the problem space proscribed by the
customer’s need statement but to be most effective they must be
accomplished within a context richer than a simple user-oriented need
statement.
• A problem space model is applied to expand our knowledge of the system
needed from the simple view of a known system need statement combined
with the simple system block interacting with an environment to
accomplish that need to a clear knowledge of the top-level system
functionality, product entity structure, top-level interface relationships
between these product entities, and at least the content of the system
specification.
3

What is Structured Analysis?

• Structured analysis applies a general model to the solution of a
specific problem such that the model encourages us to think of all of
the factors of importance in arriving at a clear definition of the
problem while allowing us to remain undistracted by unrelated
factors.
• Structured analysis provides an organized, systematic way of thinking
about a complex problem. This process provides a model within which
we can think about the important characteristics of a problem
space.
• Structured analysis is not a problem-solving domain, rather a problem
definition domain
4

What is Structured Analysis?

• All structured models known to the author feature one or
more simple diagrams, the features of which relate to
elements of the problem space. It is often consisting of
rectangles or bubbles connected by directed lines.
• If we use the model to capture all of the related details
that we are interested in, it will obscure the visual power of
the diagram.
• As a result, these models often include one or more views,
and dictionaries are used to link the modeling artifacts of
the diagrams in which we can include the details.
5

Structured Analysis Method

• Traditional Structured Analysis (TSA),
• developed in association with military weapons and space
systems programs. It uses functional flow diagramming as a
main element of its model. There are several variations on the
use of using functional flow diagramming in this model: IDEF-
0, behavioral diagramming, or enhanced functional flow
diagramming.
• Modern Structured Analysis (MSA),
• used in the development of computer software, features
dataflow diagrams and other constructs with extensions for
real-time system development.
• Database Modeling Analysis (DMA)
• applies table normalization or IDEF 1X to develop relational
databases.
6

Structured Analysis Method

• Early Object-Oriented Analysis (OOA)
• recognizes a fundamental modeling structure called an
object about which software code is written, avoiding a
leading functional or procedural perspective. Experts
encouraged identifying the objects as a precedent to the
functionality or behavior of the resulting software in
conflict with Sullivan’s idea of “…form ever follows
function.”
• Unified Modeling Language (UML)
• improved upon the early OOA models in an attempt to
gain agreement on a common or unified approach.
7

The Goals of Structured Analysis

• The goal of structured analysis is completeness and avoidance of the
unnecessary in terms of identifying characteristics that the product
must have as a prerequisite to designing that product.
8
Where does it Appear in the
Process?
• Structured analysis resides early in the development period, of course,
because we must identify the problem before we attempt to solve it.
• Grady encouraged the individual, team, program, or company to not
select a single method for all applications, rather that all of these
methods have a useful application in some situations and product
lines.
• Some of these methods work best for hardware or software and regardless
what the background of the system engineer, he or she should master
approaches that are effective in each.
9

Comparative Overview of Approaches

• TSA, is most useful for grand systems of yet to be
determined character and will work well below the system
level for hardware entities that exhibit a space–time
dynamic with big things moving in space and time.
• The author has had trouble applying it in applications that are
relatively static from a physical perspective.
• Problems that will reveal themselves while the analyst is focusing
on what the system must do (functionality) will yield to this
approach.
• TSA is not a good approach for computer software
development, though this is where the software process
started in what was called flowcharting
10

Comparative Overview of Approaches

• The MSA approach will work well for computer software systems
where computer processing of data is very intense and interest in the
data is important but incidental.
• Database modeling approaches are useful in developing computer
database systems where the processing of that data is incidental to
the warehousing of and access to the data.
11

Comparative Overview of Approaches

• The object-oriented approach makes an overt three-dimensional

attack on the problem space simultaneously probing it for needed
objects or things (what the solution must consist of), functionality
(what the solution must do), and behavior (how the solution must
work).
• It exposes a three-faceted structure that all structured analysis
models should address in some way.
12
Polyfaceted View of Problem
Spaces
• All problem spaces can be viewed in the context of an n-faceted
construct, where n is the number of simultaneous facets through
which we stare at the problem space.
13
Polyfaceted View of Problem
Spaces
• We have many options for trying to collect information
about this problem en route to a solution.
• If the problem is sufficiently simple, a single engineer can
apply his or her native skills and knowledge to
understand it by brute force and guile without plan from
within the engineer’s domain of knowledge. This
approach corresponds to n = 0 and is often called an ad
hoc approach.
• Often this approach involves trying to match known solutions
from the past to the problem space followed by a leap to a point
design solution based on past successes.
• It is not an effective approach where complex problems are
being dealt with and serious money is at stake
14
Polyfaceted View of Problem
Spaces
• A three-faceted structured approach encourages us
to stare at the problem space through one or more
organizing facets.
• The problem becomes organized in context with these
facets and the unknown aspects of the problem space
begin to disappear.
• Grady lists four three-faceted approaches and
identifies the model structures used in each for the
three facets. It is called Four Three-Faceted Modeling
Approaches.
15
Four Three-Faceted Modeling
Approaches.

• The modeling structures named in bold are the normal entry

facets for the indicated approach.
16

Entry Facet Differences

• Each approaches has different ideas to probe problem

space (read more on page 178-180)
• System engineer should realize that there is more than
one way to probe a complex problem space and that
some of these techniques have particular value for
particular problem and product types.
• A system engineer should be familiar with all of these
techniques to the point that he or she can understand
what is expressed in the models and documentation
common to the method and interact with those who
have built that documentation to express the results of
their analysis.
17

Entry Facet Differences

• It is possible to master multiple methods after one

recognizes that each new method that comes onto the field
recycles some of our old friends.
• This is not a reasonable cause to fight over who has the
biggest slide rule, best airplane, or finest modeling method.
Rather, it is an opportunity to see how the elements of this
new method play in the context of an n-faceted problem
space viewer and thus allow us to fit it into our personal
inventory of methods.
• We should recognize all of these techniques as three-
faceted problem space viewers that will enable the
communication process between different specialists
encouraging the sharing of information about a problem
space as we seek to understand that space so difficult that
none of us can master it by ourselves.
18

An Entry Continuum

• There are situations where it makes sense to enter

the problem space primarily from the product
entity perspective.
• Given that you must develop a new system that is
heavily precedented by an existing system leading to a
modification rather than a new build, it probably makes
more sense to begin with the product entity structure of
the existing system than to begin a new structured
analysis effort led by functional analysis.
• For a new, unprecedented development one should
fully apply Sullivan’s perspective.
19
The Problem Space Entry Perspective
Continuum
20

Terima Kasih
1

Modul 7-A

The Functional Problem

Space Model Part 2
II2240 Analisis Kebutuhan Sistem

Dicky Prima Satya, S.T., M.T.

Sistem & Teknologi Informasi – STEI ITB Sumber: Jeffry O. Grady, System Requirement Analysis, Elsevier, 2006
2

Completeness and Avoiding Model Madness

• While structured models can yield helpful results when
wielded by a skilled practitioner, they can lead to analysis
paralysis when the process is not well managed.
• The use of models should be seen as a means to an end
not an end in itself.
• It is necessary to keep one’s mind on the goal and be
ready to declare victory when that end has been achieved.
• Team and program management must monitor the
ongoing results of the modeling work against clear
completion criteria defined prior to the start of the work.
• When that criterion has been satisfied, it is time to call an
end to it and move on to other tasks.
3

Completeness and Avoiding Model Madness

• So, what is that end goal that we can use to
determine when we have completed the modeling
and thus the requirements analysis?
• A specification for an item (system or component) is
complete, therefore, when you have identified all of the
essential characteristics and excluded all other content.
• As previously noted, all system and hardware essential
characteristics can be partitioned into performance
requirements and design constraints. The latter can be
further partitioned into specialty engineering, interface,
and environmental requirements. We should ensure all of
these requirements have been identified completely (it will
be discussed after Mid Exam).
4
Detail
Coverage of
Models
5

Detailed Coverage of Models

• There was no single model that could be depended

upon to expose every needed requirement for every
specification that must be developed for a program.
• Grady has met system engineers who were able to
apply a particular model across the HW/SW divide
but it is not a common talent.
6

Detailed Coverage of Models

• It is unusual today when a system is developed that

does not entail some software. It is a reality that this
software must run in hardware.
• Therefore, every system will involve some
combination of hardware and software and there is
no current model that can be employed for both. The
author is convinced that this will change early in the
second millennium, but until the universal model is
available, we will have to use multiple models.
7

Functional Analysis
• Functional analysis is identification of needed
functionality as a prerequisite to design and the
association of that functionality with physical things of
which the system shall be composed, and identification of
the performance characteristics corresponding to those
things based on the functionality.
• Functional analysis is a continuous stream of work from
the first insight into a need through the time when we are
sure of the preferred product entity structure and the
necessary characteristics those entities and relations
must respect.
• There are several methods or models people have found
useful to this end. The first one we will discuss is called
functional flow diagramming (if you want to explore
FFD, please read more on page 188-205).
8

Functional Analysis
9

Functional-based Requirement Analysis

Integration of user, acquisition agent, and contractor requirements work.
10

Specification Template for Functional Analysis

• It is a fundamental principal that the requirements
appearing in a specification be derived from models and
that they be traceable to the modeling artifacts from
which they were derive.
• Recommended functional model specification structure:
11
Performance Requirements Analysis and
Allocation
• Performance requirements analysis depends on
functional analysis to expose needed performance related
functions that will then be transformed into performance
requirements suitable for inclusion in a specification for
the item to which they are allocated.
• It is convenient to group product and process
performance requirements analysis work together
because they share a common methodology for gaining
insight into appropriate requirements.
12
Product Performance Requirement
Analysis
• The results of product performance requirements analysis for a given
system or item flow into the corresponding specification performance
or entity capability requirements section.
• In this process we attempt to clearly define what the product system
or item must do and how well it must do it, that is, how well it must
perform.
• We wish to be complete while not over-specifying. This is a very
difficult objective to satisfy because it is very hard to know when you
have attained a condition of completeness.
13
Product Performance Requirement
Analysis
• If we choose to apply too much structure, we run the risk of angry
analysts forced to mindlessly work within a structure so rigid they are
not able to think expansively. If we apply too little rigor, we run the
risk of incompleteness.
• Grady offers no clear direction here.
• Clearly, a condition of balance is required but the precise balance point for a
given program is best selected through experience and knowledge on the part
of the person who will perform the work.
14
Process Performance Requirement
Analysis
• In process requirements analysis we seek to provide planning
information useful in establishing program plans for
• (i) material acquisition,
• (ii) manufacturing,
• (iii) quality assurance,
• (iv) testing,
• (v) deployment, and
• (vi) logistics support for the product system that is consistent with the
evolving product system requirements and concept.
15

Product Entity Structure Synthesis

• This refers to architecture synthesis task
• It covers the physical entities of which the system
consists piled up in a hierarchical breakdown diagram.
• The architecture is described by a collection of models
covering what the system consists of, how it behaves,
and what it must accomplish.
• It is derived from functional and performance
requirements through trade studies, an appeal to
historical precedent, good engineering judgment,
and respect for customer direction to use specific
resources in the system.
16

Product Entity Structure Synthesis

• This refers to architecture synthesis task
• It covers the physical entities of which the system
consists piled up in a hierarchical breakdown diagram.
• The architecture is described by a collection of models
covering what the system consists of, how it behaves,
and what it must accomplish.
• It is derived from functional and performance
requirements through trade studies, an appeal to
historical precedent, good engineering judgment,
and respect for customer direction to use specific
resources in the system.
17

Product Entity Structure Synthesis

• Two principal products in this activity: a product entity
block diagram and a product entity dictionary.
• The product entity diagram defines system composition.
Everything that is part of the system is illustrated in its family
relationships. It uses simple blocks and interconnecting lines to
define the existence of elements and their relationships.
• The product entity dictionary is a tabular listing of system
product entities illustrated on the product entity diagram (one
tabular line item for each block on the product entity diagram)
containing the element name, a description of the element, and
other reference information too extensive to place on the face of
the product entity diagram. This information includes the name of
the principal engineer and/or the responsible design agent
and/or their department or team.
18

Typical Product Entity Diagram

19

Product Entity Cross Conditions

20

Product Entity Cross Conditions

21

Interface Analysis
• Systems consist of entities, referred to as elements of
the system product entity structure in the previous
section, and relations between those entities. The
relations between the entities are referred to as
interfaces.
• Interface analysis is one of the methods by which we
arrive at an optimum product entity structure for a
system before we commit to design it.
22

Interface Analysis
• The desired goal is to refine the match between how the design
teams are organized and how the product system is organized
in order to simplify the system development process and
assure we have accounted for all needed system functionality.
• Systems with the simplest interfaces relative to system design
responsibilities result in programs with the fewest risks. But,
the richer the interface complexity is, the greater the potential
for synergism between the components.
• We must have interfaces between elements designed by
different agents and we desire to minimize these interfaces.
This is perhaps the most important task of a system
engineering community, to control the development of the
interfaces in a system to satisfy these conflicting demands
23

Terima Kasih