Which kind of identifier to use for which purpos

[Sebastian]

Hello,
I have a problem to understand which kind of IDs should stay unchanged during a reqIF roundtrip and which kind of IDs can change during the process to document versioned changes of a requirement:

We have requirements which we version consequently, i.e. if a requirement changes due to feedback of a supplier, it has a new ID in our Authoring system.
But I doubt the supplier is able to track this change, e.g. if our IDENTIFIER of the SPEC-OBJECT changes in the secound round of our roundtrip.

There is also the foreignid, for which the documentation states, it is for “the partner” (but who is the partner – customer or supplier) and there is the ALTERNATIVE-ID which ist documented in the spec as a “tool-specific alternative identifier.
Furthermore I don’t understand, where and how to place an ALTERNATIVE-ID for a spec object and I cannot find an example on that.

I cannot change a requirement in our system without getting a new identifier which points to the new version of that requirement. So I guess I need to map between the requirements id which stays they same, while the requirement changes, and I need a possibility to transport the actual id of the requirement to find it in my authoring system.

So my question, would it be the right approach to use the alternative-id to transport our id of the requirement which *changes* during the roundtrip (only on customer side, of course) and use the IDENTIFIER attribute of the SPEC-OBJECT for the constant ID?
And I am not also talking about requirements which will be deleted by the customer during the roundtrip, this is sure a separate topic.

Any clarification on which ID to use for what, which of them should stay fixed and which of them may change due to requirements versioning is welcome.

[Michael Jastram]

Hi Sebastian,

The most important rule: Once a SpecObject has been created, its Identifier must never change, period. This is what ReqIF relies on to match SpecObjects on a roundtrip-return. In fact, if the Identifier changes, you’re not ReqIF-compliant any more. Therefore, you are correct: You need to build a mapping table.

Regarding the AlternativeId: Once assigned, this must never be changed either. So I don’t think it helps you in your situation. It was introduced to give tools more flexibility. But honestly, I would stay away from it. It’s also used to deal with compatibility to the older RIF format, which was the predecessor of ReqIF.

In practice, all ReqIF importers and exporters maintain a mapping table between ReqIF IDs and references to the requirements in their tool. So that’s best practice.

I hope this helps!

Best – Michael

[Sebastian]

Hello Michael,

ah, now I am getting close. So the IDENTIFIER attribute of a SPEC-OBJECT should never change, while the requirement develops over several roundtrips – OK.
The foreignid should be human readable and therefore also cannot be the place for my “real” id. And the ALTERNATIVE-ID is not meant for this also – and shouldn’t be changed.

But if I have no possibility to transport the real id through the roundtrip iteration, then I would need to store a mapping between the IDENTIFIER (which stays the same through the whole conversation) and the real id for each outgoing Customer Request.

Wouldn’t it be much better, if I could transport the real id through the reqIF roundtrip?

Thanks for you reply btw 🙂

[Author]

Posts