nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Dynamic constraint checking DOORs link

medini_1005899080

Hi Jan,

Currently I thing constraint 0003 is checking only if a requirement is linked to a goal, but we are using DOORs requirements.

How can I change the constraint?

inv:
let
MessageArg1:String= self.identifier
in
self.targetRelations->exists(rel|rel.source.oclIsTypeOf(SafetyRequirement) and rel.source.oclAsType(SafetyRequirement).kind= safetygoals::SafetyReqKind::FUNCTIONAL)

Find more posts tagged with

medini

medini legacy

Accepted answers

medini_1023909254

Hi Sven, what looks the same - the validation result or the constraint itself?

The constraint has one difference: it is using oclIsKindOf instead of oclIsTypeOf ...

Eckhardt

All comments

medini_1023909254

Hi Sven,

actually constraint 0003 is slightly different: It checks whether each safety goal is having at least one contributing functional safety requirement. So what exactly do you want to validate for DOORS requirements?

I suppose you have requirements from DOORSClassic - and not requirements imported from DNG - right?

Eckhardt

medini_1005899080

Hi Eckhardt,

I need exactly this check. (Each Goal has to have a functional Safety Requirement (in DOORs, Classic).

But: The Check doesn't work.(My thought was, that is is related to the fact that the constraint is only checking requirements, not DOORs Requirements.

Sven

medini_1005899080

medini_1033829014

Hi Sven,

I'm just guessing, but could the issue be that this rules explicitly wants a FUNCTIONAL kind of requirement, not just any sort of requirement, and that your requirements imported from DOORS don't have this particular kind assigned?

If this is the situation, then you'll probably just want to delete the part starting from "and".

Best regards

Bernhard

medini_1023909254

Exactly Bernhard, probably I should have written FUNCTIONAL also in capital characters to make my point more clear.

Eckhardt

medini_1005899080

As you can see in the screenshot, the requirement is FUNCTIONAL. (This was also my first thourght)

medini_1023909254

Thanks Sven,

yes the rule is currently strict in type checking and only accepts "real" safety requirements. This can be a little more relaxed to include also subtypes (i.e. DOORSRequirement) by uchanging it to

inv:
let
MessageArg1:String= self.identifier
in
self.targetRelations->exists(rel|rel.source.oclIsKindOf(SafetyRequirement) and rel.source.oclAsType(SafetyRequirement).kind= safetygoals::SafetyReqKind::FUNCTIONAL)

Eckhardt

medini_1005899080

Hi Eckardt,

for me it looks exactly the same as the "standard" constraint.

medini_1023909254

Hi Sven, what looks the same - the validation result or the constraint itself?

The constraint has one difference: it is using oclIsKindOf instead of oclIsTypeOf ...

Eckhardt