ГОСТ Р 55346—2012
description : OPTIONAL text_select;
(* The related_class specifies the second Related_class in the relationship. *)
related_class: requirement_class;
(* The relating_class specifies the first Relating_class in the relationship. *)
relating_class: requirement_dass:
(* The relationship_type specifies the nature of the relationship. Where applicable one of the following values shall be
used:<ul> <li>specialization: The related_class Requirement_class is a specialization of the relating_class Require-
ment_dass:«qti. <li>equivalence: The related_dass Requirement_class is a synonym of the relating_dass Requirement
dass.</li> </ul> *)
relationship_type: label;
END_ENTITY;
(*A Requirement_composition_relationship represents the decomposition relationship between a Requirement_defini-
tion and a Requirement_occurence. <note number=T>ARequirement_definition object may be decomposed into any
number of Requirement_occurence objects.</note> <note number=’2*>One important assumption is that the model
will be employed for representation of multiple versions or vanants of a system specification. Consequently there is a
substantial benefit if common design elements among the versions could be shared or reused. These assumptions have
led to a model where four entities are involved in representing a single requirement as seen from a user’s pointof view.
The structure is outlined below. <p>The entity Requirement_definition holds the description of what is required. In the
model there are three sup-types of this entity that support different representations of what is required. No assumptions
are made as to the context in which the requirement is used which means that no inter-requirement relationships are
defined on the Requirement_definition entity. A Requirement_definition object may provide definition for any number of
requirement_occurence objects.</p><p>The Requirementjnstance entity is a context dependent representation of a
requirement. A Requirementjnstance object may be assigned to a System_view object (in the system architecture UoF).
All relationships between requirements are defined on the Requirementjnstance entity.</p><p>The requirement_com-
position_relationship entity is the means for decomposing requirements. Foreach added requirement in a composition
a new Requirement_composition_relationship object has to be instantiated.</p><p>The Requirement_occurence entity
is an intermediate representation of a requirement. It is included in the model to allow for maximum traceability and
for improving the support for reusing a requirement in more than one context (different system versions or systems). A
requirement_occurence object using exactly one Requirement_defmition object as its definition may serve as a definition
for any number of Requirementjnstance objects.</p><p>Consequently. the requirement_occurence entity separates the
static requirement breakdown structure from the dynamic system specific requirement representation (represented by the
Requirementjnstance entity) and it implements loose coupling between parent and child requirements in a requirement
breakdown structure.</p><p>The first aspect is important as it allows multiple context dependent objects ( Requirement
instance )to reference the same context independent object.</p> <p>The second aspect is that a Requirement_defini-tion
object that is part of a composition (via a requirement_occurence and requirement_composition_relationship objects) is
not tightly linked to the parent Requirement_defmition object The construct a Bows the information model to represent a
specific requirement as part of a requirement composition hierarchy in one situation while in another situation it may be
viewed as a top-level requirement.</p></note> *)
ENTITY requirement_composition_relationship;
(* The child_requirement specifies the decomposing Requirement_occurence object in the relationship. *)
child_requirement: requirement_occurence;
(* The description specifies additional textual information about the Requirement_composition_relationship. *)
description : OPTIONAL text_select;
(* The index specifies an identifier for the Requirement_occurence identified by the child_requirement in the contextof
the Requirement_definition defined by the parent_definition attribute. <note number="3’’>The index is the means of rep
resenting the identifier often used to identify a requirement in requirement management tools. In PAS 20542. this idenfier
is built up stepwise one position at a time. If numerical indexing is used and a particular child_requirement is the third in
the composition defined by the parent_defimtion. then the index attribute shall be 3.</note> *)
index; label;
(* The parent_defmition specifies the decomposed Requirement_definition n the relationship. *)
parent_definition ; requirement_definition;
UNIQUE
UR1: index. parent_definition;
END_ENTITY;
(*A Requirement_definition isthe context independent definition of a requirement. <note>The combination of Requirement
definition. Requirement_occurrence and Requirement_composition_relationshipobjects define the mechanism for breaking
down complex requirements to their basic parts. The use of three separate entities allows for representing that a particular
requirement_definition object ispart of several breakdown hierarchies and the use of a Requirement_occurrence object for
each individual hierarchy allows for the unambiguous and insulated representation of each breakdown hierarchy.</note> *)
376