I am just starting to look seriously at ProR for requirements, specification, design and testing capture and traceability. I am thinking that I will need many SpecObject Types, Data Types and SpecRelation Types. Is there a way to limit what choices are available, say at the specification level?

(As an aside, it is frustrating having objects in the tool named the same as what I would normally use for the work product. Specification is the prime example, but there are others. Why not SpecDocument or similar?)

If I have specifications (ProR specifications) for a Requirements Document, a Specification Document, a Design Document and a Test Document (probably multiple test documents), is there a way to have only a subset of the SpecObject types presented when selecting the SpecObject Type for a Requirements Document SpecObject? And a different set of SpecObject Types for the Specification Document? etc. (Ideally the other SpecObject Types would be available, but the primary list for a particular "specification" would be the easiest to choose.)

And a similar set of constraints when selecting the SpecRelations? But I realize that this could be much more involved. (Is there a way to force SpecRelations to only be realized between specific SpecObject types?)

(As an aside, it is frustrating having objects in the tool named the same as what I would normally use for the work product. Specification is the prime example, but there are others. Why not SpecDocument or similar?)

Just so you understand the reasoning, RMF/ProR is currently used mainly for inspection and debugging of ReqIF models. In that context, the naming makes sense ("Specification" is the actual model element name). But I can see your reasoning, with respect to using ProR as a requirements tool.

We use EMF under the hood, which is pretty much ready for internationalization. It should not be that much work to provide a language-specific fragment that provides new names. So that could be an easy solution.

As far as the filtering for the creation of new elements is concerned, this is of course possible in principle. But to get this "right", we would have to think such a feature all the way through. To be frank, there are many pending issues that have higher priority right now. Of course, you could try to implement it, or pay to get it implemented.

Not sure whether it helps, but there is a keyboard shortcut (Ctrl-Enter) that inserts a new SpecObject of the same time as the one currently selected. This could be useful for entering many SpecObjects of the same type.