Object Deletion Rules

There are several rules that are checked before an object is deleted using the Requirement Structure Browser or the Specification Structure View. This section explains the overall logic used to delete objects. It also describes settings in the properties file that indicate parent/child relationships that are checked before deleting objects.

Delete Rules

The following process is followed when an object is deleted.


  1. The object is disconnected from its current parent.
  2. The policy/state/access is checked to ensure that the current user has delete privileges.
  3. A check is performed to ensure that if the object is reserved by another user, the object cannot be deleted.
  4. The parent and child relationships are checked to ensure that there are no objects that this object is linked to. See the topic below about "Checking Parent/Child Relationships for Objects".

Only when all these conditions are satisfied can the object be deleted.

In a case where multiple objects are selected, the Delete logic will delete as many objects as possible for which all the conditional checks are satisfied. For the objects that were not deleted, a Delete Report is displayed giving the reasons why the objects could not be deleted.

In the case of a recursive delete, if the conditional check for any one object fails, then the entire transaction will be rolled back. The branch (object and children) can be completely deleted only when the conditional checks are satisfied for all objects.

Checking Parent/Child Relationships for Objects

The emxRequirements.properties file contains definitions the parent/child relationships to check for each Type (Requirement, Chapter, Comment, Decision, Requirement Specification) before deleting. This section shows the default settings for each Type, which can be modified. 

emxRequirements.type_SoftwareRequirementSpecification.CheckParentRels=
emxRequirements.type_SoftwareRequirementSpecification.CheckChildRels=relationship_SpecificationStructure
emxRequirements.type_Requirement.CheckParentRels=relationship_SpecificationStructure
emxRequirements.type_Requirement.CheckChildRels=relationship_RequirementBreakdown,relationship_DerivedRequirement
emxRequirements.type_Chapter.CheckParentRels=relationship_SpecificationStructure
emxRequirements.type_Chapter.CheckChildRels=relationship_SpecificationStructure
emxRequirements.type_Comment.CheckParentRels=relationship_SpecificationStructure
emxRequirements.type_Comment.CheckChildRels=
emxRequirements.type_Decision.CheckParentRels=relationship_RequirementDecision
emxRequirements.type_Decision.CheckChildRels=

As an example, let's use these two settings:

emxRequirements.type_Requirement.CheckParentRels
AND
emxRequirements.type_Requirement.CheckChildRels

The following is a setting that checks parent relationships:

emxRequirements.type_Requirement.CheckParentRels=relationship_SpecificationStructure

The above setting indicates that a Requirement can only be deleted when it has no parents pointing to it in a relationship_SpecificationStructure relationship (excluding its current parent displayed from the current UI).

For example, for a requirement that has a parent Chapter, this requirement cannot be deleted from the Requirements list view. However, it can be deleted from the Specification Structure Browser view because in the Specification Structure Browser view its parent in relationship_SpecificationStructure is explicitly displayed, thus this parent is ignored in the parent check. While in the Requirement list view, this parent check needs to be conducted and would fail. However, if this requirement has more than one parent Chapter, the parent check would still fail even in the Specification Structure Browser view unless its other parent Chapters are also selected for deletion (using the action "Delete > Selected Objects") or its other parents fall into the same branch selected for deletion (using the action "Delete > Selected Object and Children")

Here is another example:

emxRequirements.type_Requirement.CheckChildRels=