You might need three architecture elements to satisfy one system requirement. You create "satisfies" links from each architecture element to the system requirement. If one of the architecture elements is deleted, the requirement is no longer satisfied, but you still have two architecture elements with "satisfies" links to the requirement. How do you detect this problem?
DOORs stores deleted items until they are purged. If there was an inadvertent deletion of a requirement, you could catch it at the baselining stage when performing a delta of all changes in the new baseline against the old. If an object with a parent trace is deleted prior to removing the parent trace, there will remain a trace artifact behind that would show up when doing top-down analysis from the system requirement down to the architecture elements. It would be feasible to set up a "Deletions" view to catch traces to deleted requirements and make assessments on whether they were valid deletions or not. Some metrics from DOORs can be captured for periodic or continuous review as a dashboard for that purpose. It's best to catch anything like that as part of the review stage, however, which I think is where most programs have a challenge implementing/using DOORs. It can easily become bloated with review processes that slow the usefulness of the tool.
I've come back to this video a couple times now. It's been very helpful. I'm Canadian and could follow the accent just fine. Watched it at 2x speed.
You might need three architecture elements to satisfy one system requirement. You create "satisfies" links from each architecture element to the system requirement. If one of the architecture elements is deleted, the requirement is no longer satisfied, but you still have two architecture elements with "satisfies" links to the requirement. How do you detect this problem?
DOORs stores deleted items until they are purged. If there was an inadvertent deletion of a requirement, you could catch it at the baselining stage when performing a delta of all changes in the new baseline against the old. If an object with a parent trace is deleted prior to removing the parent trace, there will remain a trace artifact behind that would show up when doing top-down analysis from the system requirement down to the architecture elements. It would be feasible to set up a "Deletions" view to catch traces to deleted requirements and make assessments on whether they were valid deletions or not. Some metrics from DOORs can be captured for periodic or continuous review as a dashboard for that purpose. It's best to catch anything like that as part of the review stage, however, which I think is where most programs have a challenge implementing/using DOORs. It can easily become bloated with review processes that slow the usefulness of the tool.
Nothing about how Doors manages the justifications of the links?
Speed was fine. Watched once before doing anything, and then played it while operating the program.
Hard to follow - a fast delivery, in a strong accent, with some odd mistaken words like "transverse" where "TRAVERSE" was clearly meant.
Way too fast. Slow down please.
You can adjust the speed in the settings.
hard to follow! too fast
You can adjust the speed in the settings.
Shame about the typos/pronunciation, e.g. effect pronounced as affect, etc.
I can't stand the buzzing + this woman's voice/accent.
Get used to it. IBM now means Indian Business Maschines.