![](bg4.png)
As an example, we pick up such ambiguous require-
ment as “we need a software product that helps the
students to understand programming more exactly”,
then analyze using a fishbone diagram. The above
client requirement implies a background problem that
can be expressed as “students do not understand pro-
gramming”. Therefore, the client requires the solu-
tion of this background problem.
This background problem is analyzed using a fish-
bone diagram. Each factor that occurs in the fishbone
diagram causes the problem directly or indirectly, and
the solution for it satisfies a part of the customer re-
quirement. For example, if a factor “dynamic algo-
risms in a textbook are difficult to understand” occurs
in the diagram, there could be a solution “explanation
using motion pictures”. This solution can be regarded
as a part of the software function that the clients an-
ticipate. Therefore, we can define the software spec-
ifications that the clients anticipate, by analyzing the
programs behind the client requirements, and then by
designing a corresponding solution to each factor in
the fishbone diagram, succeeded by expressing it as
the specifications. We call a fishbone diagram that
includes the corresponding solutions to factors as a
“requirement structure diagram”. Each solution in a
requirement structure diagram represents a function
to be implemented in the software specification, and
the solutions are categorized based on the factors of
the original problem. The most detailed level solu-
tions are implemented as methods or functions, which
compose the classes of the software to be developed.
This approach can be generalized as follows. Let
R be a client requirement, and R be a software specifi-
cation that cannot be implemented by the client him-
self. We define generalized factors and solutions iter-
atively in the following way.
1. A solution for the factor Q
−→
p
is denoted as Q
′
−→
p
,
where
−→
p represents a series of natural numbers.
2. If a factor Q
−→
p
has farther factors that cause Q
−→
p
these factors are denoted as Q
−→
p −n
(n=1,2,...).
3. The highest level factors are denoted as Q
n
(n=1,2,...).
If we can implement the solution Q
′
−→
p
that occur in
the requirement structure diagram, the original prob-
lem Q
−→
p
is considered to be resolved, and they satisfy
a part of the original requirement, that is Q
′
n−m
⊆ R
′
holds. Consequently, R
′
⊆ ∪Q
′
−→
p
holds. Q
′
−→
p
is a solu-
tion that the clients did not notice, and the one that is
derived from the requirement structure diagram. The
most detailed level solutions {Q
′
−→
p
} are regarded as
methods or functions, and these are organized into
classes. We can define ambiguous requirements, and
can determine the class structure by deriving require-
ment structure diagrams from fishbone diagrams of
the original requirements.
3.4 Transforming a Requirement
Structure Diagram into UML
Diagrams
In 3.3, we discussed a way to derive class diagrams
from fishbone diagrams using requirement structure
diagrams. In this section, we present how fishbone
diagrams are transformed into requirement structure
diagrams in FDM. The following three translation ta-
bles are used for the above translation.
• Assign a unique number for each factor in a fish-
bone diagram, and then note these numbers in the
translation table 1.
• For each factor in the translation table 1, define the
solution for it, in order to complete the translation
table 2.
• For each solution in translation table 2, define ac-
tors and their behavior associated with it, in order
to complete the translation table 3.
By the translation table 2, we can analyze the detailed
requirements which we can not obtain trough hear-
ing, and can define the solutions for each requirement.
Based on the agreement on the translation table 2 be-
tween the clients and the developers, the actors and
their behavior are defined, which are associated with
each solution. The above defined items are identical
to use cases in UML. A “requirement structure dia-
gram” is a fishbone diagram, each factor of which
represents the solution that corresponds to the origi-
nal factor.
In object orientation, class diagrams are most es-
sential diagrams to develop software. A class is a set
of data and associated operations, which can be cat-
egorized based on its role or purpose. Each method
in a requirement structure diagram is classified based
on the purposes, and this classification is similar to
that of the classes. A bone to which a method is at-
tached directly represents the factor to be resolved by
the method, and the factor is regarded as a purpose.
This purpose is also a solution for another purpose if
it is decomposed from another factor. A set of all the
methods can resolve all the factors reside in a fishbone
diagram. Even though we can categorize the methods
in any granularity based on the bone structure which
represents the relationship between purposes and so-
lutions, all the requirement structure diagrams always
have three major bone types, that is “main bones”,
“large bones”, and “small bones”, and other lower
level bones might not included.
EXTRACTING CLASS STRUCTURE BASED ON FISHBONE DIAGRAMS
463