Migrate Object Heading to Name and Object Text to Primary Text
Hi,
Is it possible to migrate the content of Object Heading (Classic) into Name (Next) and Object Text (Classic) into Primary Text (Next)?
I.e. I may have a single object in Classic with "Software Requirement" in Object Heading and "The system shall raise errors within 500ms." in Object Text and want them both in one artifact in DOORS Next, with Heading in Name and Text in Primary Text.
Many thanks in advance
Calum
One answer
There are a lot of reasons why you don't want to do that:
- Next is not the same beast as Classic as I'm sure you know. Modules are no longer the containers for artefacts and you can reuse artefacts across multiple contexts. In each of these contexts the artefact can be treated like a Heading or not, and the Primary Text will be formatted accordingly
- The Name attribute is an overridable calculated field. If you don't explicitly put something in it, then it will default to the first sentence or the first 255 characters of the Primary Text. This makes it useful when you need a summary of very long Primary Text, or when there's stuff that doesn't represent well as text when exported
- the default view for a folder or Collection uses the Name attribute to maximise screen real estate. The default view for a Module is the Primary Text formatted according to the style that module is using (Heading or Content). If you take the approach you suggest, you'll end up with messed up views in both places
I would suggest that the best approach is to go back to DOORS Classic and make sure only one of those attributes is filled at any one time - splitting ones that have both filled into two separate objects
Comments
Thanks for the reply. I am looking to experiment with both Classic and Next. To date I have only ever seen both tools being used as word processors, heading objects/artifacts and text/diagram objects/artifacts, as you describe.
But I don't want my modules, in either Classic or Next to look like documents, they're not, they're repositories of data (namely requirements), RPE can make the documents for me and save everyone a lot of time and effort. If it is not possible to use it the way I'm suggesting and it needs to be done like a word processor then I'm as well to use a different requirements tool - even just modify Excel to do the job.
And it doesn't mess up views if I just use object heading and text attributes.
My response didn't mention anything about usage - I just said it was a bad idea because of how the tools work. I don't care how you plan to use your modules but it sure sounds like you're making a lot of work for yourself.
The DNG Migration tool and ReqIF won't do it the way you want. But you can create a view in DOORS with Object Heading and Object Text as two columns, rename the columns to Name and Primary Text, export as CSV and import into DNG and that will do it.
Thanks, so at present there is no "built in" functionality to do what I wish to try, this will be why a number of people on different forums are trying to move to other requirements management tools instead of Next then.
With respect, your response is about usage, my question relates to usage.
No, the built in functionality assumes the system defined fields have been used in standard ways - there's no way to remap built in functionality using system defined fields.
I think that's a pretty reasonable thing to expect of any product really.
The Excel export/import outlined above is a very straightforward approach and would take you a lot less time than properly setting up ReqIF packages for export or consolidating the data for the migration wizard to use. Given you're asking about migration, this is a once off, and is not a whole lot of effort
Comments
Calum Button
May 27 '22, 3:21 a.m.Further to my own question, I have found that Name in DNG migrates into Object Short Text in Classic whilst Contents/Primary Text in DNG migrates into Object Heading/Text depending on its settings as a normal or heading row (though I note this can be independent of artifact type - seems like a flaw in DNG).