best way to handle deleted objects

SystemAdmin - Thu Sep 02 04:05:50 EDT 2010
Approach that I have taken is to have an attribute that indicates the change status of each requirement, either Modified, Deleted or New. This attribute can be set manually or use DXL to create a DXL Attribute that can interpret the objects history and determine what is the appropriate change status to display.

For deleted objects, these should be soft deleted but visible when printing - the change status attribute should be included in the print job so that the reader can see what's New, Modified or Deleted.

When ever a new major baseline is created in DOORS, the soft deleted objects will have been captured in that baseline so you have a visible & traceable record of the change, they really serve no purpose after this, so immediately after creating a major baseline, I purge all soft deleted objects in the current version so that I have clean slate ready for the next round of changes.

kierant - Thu Sep 02 04:22:04 EDT 2010
Hi Paul - Thanks a lot for that reply. So it sounds like you do use soft-delete - they are included in the publications, accompanied with a tag (the attribute you mention). Can I further enquire on two questions:
> Presumably your outputs will be driven off a view that shows deletions (I'm thinking RPE here, but the principle would apply in other cases too). Do you also show deletions on your normal user views? i.e. so that what authors see when working is in line with what will get published.
> When using soft-delete in this way, do you find any problems/confusion with 'real' deletions (i.e. a reqmt that was present and is now being removed) Vs stuff that never made it out of draft (e.g. objects created in error)? It seems that, in the latter case, users would need to purge them before the publication is generated.

Kieran

kierant - Thu Sep 02 04:22:04 EDT 2010
Hi Paul - Thanks a lot for that reply. So it sounds like you do use soft-delete - they are included in the publications, accompanied with a tag (the attribute you mention). Can I further enquire on two questions:
> Presumably your outputs will be driven off a view that shows deletions (I'm thinking RPE here, but the principle would apply in other cases too). Do you also show deletions on your normal user views? i.e. so that what authors see when working is in line with what will get published.
> When using soft-delete in this way, do you find any problems/confusion with 'real' deletions (i.e. a reqmt that was present and is now being removed) Vs stuff that never made it out of draft (e.g. objects created in error)? It seems that, in the latter case, users would need to purge them before the publication is generated.

Kieran

SystemAdmin - Thu Sep 02 20:12:30 EDT 2010
Quote: Presumably your outputs will be driven off a view that shows deletions (I'm thinking RPE here, but the principle would apply in other cases too). Do you also show deletions on your normal user views? i.e. so that what authors see when working is in line with what will get published

Users are directed to use a "Change Management" view that I have in each module which shows all information associated with change (incl show deletions). The view I use for printing also has Show Deletions enabled, otherwise, all other views have it disabled. The "Change Management" view includes the Change Status attribute I mentioned as well as a column which mimics the Main Column but shows all differences w.r.t. to the last baseline in a marked up text format. Another attribute captures the UID of Change Requests that are the source of a change to an object. I don't use RPE, I don't use WEXP, DocExpress is fortunately a dim memory, I've managed so far to get by with keeping it simple and just use a combination of the native print and export to MSWord features of DOORS plus a few tricks with Adobe Acrobat PDF creation. Customers just need to be given the business case for keeping outputs from DOORS simple so that more time is spent engineering the system deliverable rather than engineering a beautiful looking document.
Quote: When using soft-delete in this way, do you find any problems/confusion with 'real' deletions (i.e. a reqmt that was present and is now being removed) Vs stuff that never made it out of draft (e.g. objects created in error)? It seems that, in the latter case, users would need to purge them before the publication is generated.

When a spec is in the initial DRAFT state, new, modified and deleted objects mean nothing so deletions ought to be purged prior to cutting the first major baseline which represents the inaugural official release. Having said that, often the initial DRAFT document does go through several minor baseline iterations as it gets handed around for review, so these deleted objects can be retained in these minor baselines if that's important. If people want to keep these deletions just in case they might become relevant later on, you can go back to one of these minor baselines and just copy the object text over to a new object in the current version - you'll get a new UID of course but who cares, this is effectively a new requirement being added. In anticipation of deleted requirements that will be needed later, I've seen some projects copy objects that will be deleted from the DRAFT over to a module which acts like a Trash repository where they can drag-drop-copy objects into spec modules should they become relevant later on.

kierant - Fri Sep 03 04:16:38 EDT 2010
Hi Paul, Roy - Thanks a lot for all that insight, most helpful. That's pretty much as I expected - today I have the indicator and markup attributes too, however a user sets an attribute to 'mark for deletion' and i'm considering changing to use of soft-delete. So it's good to hear that's in common usage out there.
It would be nice if the product gave clearer direction on this basic/universal need - it isn't clear out-of-the-box. Even more of a gap is all of these change indicator/markup attributes that everyone seems to have to (a) discover the need for and (b) design and build a solution for. But that's enough moaning for today...

Kieran