How to model all-of vs. one-of?

[BenGardiner]

I have read through the ReqIF document from the OMG and also have become pretty familiar with strictdoc but I'm not sure how to model these two different situations in strictdoc:

1. an abstract requirement is satisfied only by satisfying all of the more concrete requirements

2. an abstract requirement is satisfied when any one of the more concrete requirements are satisfied

for example, is the parent-child relationship supposed to mean 1) whereas composite means 2)?

[BenGardiner]

something we tried out in vcr-experiment was to model all-of as parent-child and one-of as composite

e.g. https://github.com/nmfta-repo/vcr-experiment/blob/750ca6f467c5f19a484373afd7bd443ba58b7e55/01_gateways.sdoc#L160

and https://github.com/nmfta-repo/vcr-experiment/blob/750ca6f467c5f19a484373afd7bd443ba58b7e55/01_gateways.sdoc#L58

But we don't know if that is the right approach to take. We'd like to get the approach right before the set of requirements explodes.

[stanislaw]

I am not familiar with the concept of "abstract requirement". There is no such thing supported in StrictDoc's model.

Right now, StrictDoc only looks at the "parent link is present" or "child link is present" for each requirement and that's how the traceability screens are created.

You seem to be looking for a more advanced semantics that I have not encountered before in my work where I usually see these layers:

1. Customer's requirements (aka Requirements Baseline (TB))
2. Supplier's technical specifications (aka Technical Speification (TS))
3. Supplier's test specifications

Each test spec item from the layer 3 has one or more parent links to the layer 2 (so-called "validation against the TS") or the layer 1 (so-called "validation against the RB").
Each tech spec item from the layer 2 has one or more parent links to the layer 1.

The traceability and requirements coverage is ensured by having all layers's tech and test requirements items completely traceable in both directions.

What is special about this "abstract requirement"?

[BenGardiner]

'abstract requirement' is perhaps my poor choice of name. All I mean is a requirement which is more-general/higher-level. e.g. the TB requirements are (probably) abstract requirements to the more concrete TS requirements in your levels...

The requirements we are putting together have to cover an array of options. This drives the need to specify a high-level/broad/'abstract' requirement and provide a few possible requirements that would satisfy it. e.g. https://github.com/nmfta-repo/vcr-experiment/blob/750ca6f467c5f19a484373afd7bd443ba58b7e55/01_gateways.sdoc#L58

Then also there are cases where the requirements appear to need a list of requirements to be 'comprehensive' . e.g. https://github.com/nmfta-repo/vcr-experiment/blob/750ca6f467c5f19a484373afd7bd443ba58b7e55/01_gateways.sdoc#L152

[stanislaw]

In the separation between layers 1 and 2 above, the layer 1 is often of a customer and the layer 2 is of a supplier.

In your case, is your document stating the abstract requirements and concrete requirements right away in the same document? How much do you care about these two layers of abstract/concrete to be strictly maintained if that's the same document?

In my experience, most of the time you have a separate document for the level 1, very often by a different company or a team, which is traced to the level 2 in another document.

[BenGardiner]

Good points.

In your case, is your document stating the abstract requirements and concrete requirements right away in the same document?

Yes. In the same document in fact -- as you surmise. I think that before the project is done there will be cases where the abstract and concrete reqs are still specified by the same team (the working group) but would span different .sdoc files.

How much do you care about these two layers of abstract/concrete to be strictly maintained if that's the same document?

That's an excellent question ... I'm not entirely sure how much we care about maintenance. We care greatly that when the requirements are used by customers (fleets) to send to their suppliers (OEMs) that the all-of or one-of nature requirements are clear... The working group could probably manage any necessary maintenance to keep that clear in the finished product.

[stanislaw]

The requirements we are putting together have to cover an array of options. This drives the need to specify a high-level/broad/'abstract' requirement and provide a few possible requirements that would satisfy it. e.g. https://github.com/nmfta-repo/vcr-experiment/blob/750ca6f467c5f19a484373afd7bd443ba58b7e55/01_gateways.sdoc#L58

The idea behind the composite requirement seems to be a little different - the composite requirement states a requirement that is specified by its sub-requirements that are not "either or" options but are all smaller aspects that constitute this composite requirement altogether.

Using composite requirement for options would probably work but is not the intended use case.

[BenGardiner]

Just for your interest, this is one of my favorite guides on writing the requirements documents: Requirements Engineering Management Handbook from FAA, find it here: https://awesome-safety-critical.readthedocs.io/en/latest/#topic-requirements.

Ooooh this is great. Thank you !

This is something that would be very unusual to my experience but of course not impossible to implement 👍

Yes. We're unusual ;) ¯_(ツ)_/¯

Your case is something that I have not seen before. Even if we add some kind of a field to a requirement, how would this be used by the users of your requirements document?

The users of the requirements will be fleets and OEMS. The fleets will be able to compile questionnaires (or better[1]) from the documents and send those to potential OEMs during procurement. https://github.com/nmfta-repo/vcr-experiment is where we are messing around with a smallish set while it's manageable. In https://github.com/nmfta-repo/nmfta-vehicle_cybersecurity_requirements it will be a comprehensive set for a vehicle.

^[1]: The 'or better' is that at that scale of requirements receiving ReqIF would almost certainly be better for the OEM than questionnaires.

But the fleet can't always reasonably require a particular implementation option, only that one of the satisfactory ways is implemented. e.g. https://nmfta-repo.github.io/vcr-experiment/vcr-experiment/01_gateways.html#2.5-AGW-S-004 or https://nmfta-repo.github.io/vcr-experiment/vcr-experiment/01_gateways.html#2.11-AGW-S-010

[stanislaw]

How do you see this to work?

It sounds like the way to model 'all-of' is COMPOSITE_REQUIREMENTs -- maybe what is missing is a way to tag children as options?

Let's say,

[COMPOSITE_REQUIREMENT]
OPTIONS: OneOf

[REQUIREMENT]

[REQUIREMENT]

[REQUIREMENT]

What should happen? What should be the visible behavior?

[BenGardiner]

How do you see this to work?

It sounds like the way to model 'all-of' is COMPOSITE_REQUIREMENTs -- maybe what is missing is a way to tag children as options?

Let's say,
[...]
What should happen? What should be the visible behavior?

I think OPTIONS: OneOf or OPTIONS: OneOrMore should impact traceability and (ideally) export

For traceability a composite-oneof should be satisfied if any of the component requirements have a child in the next level document.

For export:

• some kind of visual cue in the HTML rendering
• an instruction in questionnaires (this is an export we are going to work on)
• something (I have no idea) in ReqIF [2]

^[2] I've read through ReqIF and did not see any way to model this. Your experience you shared above also suggests that this just isn't something requirements interchange is meant to do...

[BenGardiner]

Another option here is to capture all-of as composite requirements (the intended way) and capture one-or-more of as non-normative freetext. The 'options' for one-or-more are sort of instructions to the next level of detail anyways so perhaps that is the way to avoid adding a non-exportable OPTIONS: OneOrMore

[stanislaw]

After having given it some thought, I think it is indeed better to not introduce things like OPTIONS: OneOrMore because it will be quite unintuitive use of a composite requirement.

If capture one-or-more of as non-normative freetext. would solve your problem, then please proceed with such a solution because I don't know yet what would be a better solution for your "one of" case.

[BenGardiner]

The answer is: model all-of using COMPOSITE_REQUIREMENT and model any options (one-of or one-or-more) as a note in the text of the requirement.

[BenGardiner]

quoting @stanislaw

After having given it some thought, I think it is indeed better to not introduce things like OPTIONS: OneOrMore because it will be quite unintuitive use of a composite requirement.

If capture one-or-more of as non-normative freetext. would solve your problem, then please proceed with such a solution because I don't know yet what would be a better solution for your "one of" case.

[BenGardiner]

@stanislaw how is ReqIF supposed to serialize COMPOSITE_REQUIREMENTs ?

[stanislaw]

To my knowledge, there is no direct way of modeling the composite requirement in ReqIF.

One way of doing it could be as follows:

Create a custom relation "composite requirement" and make all child requirements have their parent be a parent using this custom relation. This would ensure a compatibility between StrictDoc and ReqIF but of course other tools (that you want to feed such a ReqIF to) would have to support this concept as well.

A concept of a "composite requirement" is not something that you find supported by requirements management tools.

[BenGardiner]

Thank you.

A concept of a "composite requirement" is not something that you find supported by requirements management tools.

ok that is what I was afraid of...