Deleting Requirements in DOORS Next Generation



Deleting information from any document is something to think about twice may be thrice. But deleting a requirement from a specification is not as simple as deleting a sentence. A requirement is an object which holds not only the specification sentence but other information like name-value pair attributes, history, link information etc. 

In this document we will try to explain possible ways to approach how to delete requirements 


Sometimes it is required to discard some information from the project for various reasons. But even in such cases, when specification information is discarded, there are still some risks as follows: 

  • It may break the integrity of the overall information map. 
  • The information piece to be discarded may not be needed in one configuration but may still be critical in others. 
  • The information piece to be discarded now, may still be an important component of an audit trail 
  • The information itself may have no value anymore, but the links it bears, my still constitute some value 

So when we decide to delete any information from the requirements base, we should be considering several cases. Or somebody has to pre-consider for us.      

How to delete requirements from DOORS Next Generation 

How can we delete any requirement from DNG? Or what is the best approach to delete requirements from the requirements database? 

For the reasons mentioned above, deleting requirements from GUI doesn’t exactly remove the data from the database. It just gets unaccessible. But to keep the integrity intact, any deleted requirement, still occupies a placeholder in the database. 

Soft Delete of Artifacts

Since any “delete” operation via the GUI doesn’t cause the physical deletion of the data from the database, and in spite of this result, the data is still permanently unreachable when deleted, may be we can consider a “soft” delete operation. 

It is a widely accepted approach to organize requirements in modules within DNG. Like we create/edit requirements within module, we also tend to execute the delete command in modules. This command is called as “Remove Artifact”: 


What we are doing with this command is not actually deleting the requirement, but removing it from the module. So it will remain accessible in the base artifacts and folders. 



Also, by design, there is a concept of requirement reusability. This means this requirement may coexist in other modules. 

This is why, when removing a requirement from a module it is not “deleted” by default. However if the artifact is present only in one module, then there is an option to delete it via “remove” comment as follows: 

If the artifact to be removed doesn’t exist in any other module, this option permanently deletes it. 

The permanent deletion of the artifact will still leave the artifact on the database for the integrity of the data. But it will not be possible to retrieve this artifact any more. 

So we can recommend not to permanently delete any artifact but remove. However there might still be some issues with removing the artifact from the module:

When an artifact is removed from the module, the specification text, its key-value pair attributes, history, all information will remain. Only its link to the module it belongs to will be broken. But there is one important piece of information else which gets broken. The link to other artifacts! In this example we see that the requirement is linked to another requirement in another module. When the artifact is removed from the module, we use that link as well. So when we retrieve it back to the module, it won’t have the link information anymore:

Sometimes our clients may prefer this behavior, sometimes not. For those, of which this is not preferable, we generally consult a “softer” delete operation. We advise to define a boolean attribute called “Deleted” with default value “false”. This attribute is assigned to all artifact types and instead of deleting the artifact, simply change the boolean value from “false” to “true”. 

Of course it is not enough to do this. Also we need to define a filter for every view which filters out the “Delete” attribute “true” valued requirements. 

Hard Delete of Artifacts

Hard delete of artifacts can be considered as deleting the artifacts with the option “If the artifact is not in other modules, permanently delete it.” selected. 

But this will still not be sufficient if the artifact is being used in more than one module. To make sure a hard delete, first remove it from the modules it is being used in. 

You can used the information “in modules” 

Then, just simply locate the base artifact in the folder structure and select “Delete Artifact” from the context menu. 


Upon confirming the deletion it will be permanently deleted: 


This operation will still not delete the artifact from other configurations if there are more than one stream and the artifact appears in those streams.   

How to clean up requirements 

As mentioned above, the requirements even deleted from GUI are not deleted from the database for various reasons. Most of which is to maintain the data integrity and database indices. Theoretically, after every physical deletion of the artifacts a reindexing and database maintenance scripts should be run. This would not make sense for a daily operation done by an end user.  

For those artifacts which are permanently deleted from the GUI, there is a repotools command which helps to remove from database as well. This is deleteJFSResources command. However, use it with extra precaution and please review the information in the link below: 


Making use of configurations, streams and modules complicates the deletion concept. We may loose information where we don’t expect. Also we may get results even after properly deleting artifacts. Since they will still be available in other configurations. That is why we generally advise to use the “Deleted” attribute approach and implement the filtering of non-deleted artifacts.   


Softacus AG

Löwenstrasse 20
8001 Zürich
Tel.: +41 43 5087081
Fax: +41 43 344 6075 

VAT: CHE-108.817.809 MWST
D-U-N-S® Number 486800618


Softacus GmbH

Westendstrasse 28
60325 Frankfurt am Main
Tel.: +49 69 34876544
Fax: +49 69 5830 35709

VAT: DE301903892
D-U-N-S® Number 313482703


Softacus s.r.o.

Křídlovická 351/47A
603 00 Brno
Czech Republic
Tel.: +420 530333482
Fax: +41 43 344 6075

VAT: CZ07286333
D-U-N-S® Number 496165108


Softacus s.r.o.

Tatranské nám. 3
058 01 Poprad
Tel: +421 911 083 612
Fax: +41 43 344 6075

VAT: SK53507070
D-U-N-S® Number  2121388148