Is the use of module still relevant in DOORS Next Generation ?
In DOORS the only mean to have requirement was to use modules as containers. So it was a technical constraint.
Today requirements are manageable in DOORS NG without the use of modules.
I was wondering if it's still make sense to use modules in DOORS Next Generation, or is it just a legacy from the past ?
4 answers
Hi Mokhtar,
It is not a legacy feature since DOORS Next was re-engineered from scratch and initially did not have modules.
They were only introduced to DNG in later versions after pressure from DOORS Classic users migrating to DNG.
Modules are very useful for providing a hierarchical document structure with Headings to your requirements and attributes to give them a kind of hybrid presentation between a Word document and a spreadsheet.
It makes requirements more intuitive to manage when they are presented in a document hierarchy in the way that people are used to absorbing complex information.
We are using DNG modules to address the following...
- Having a well-organized, hierarchical document look&feel tremendously helps our teams review the requirements
- We have enabled configuration management with a Catalog (mainline) stream with child project/release streams.
- The Catalog stream contains the superset of all requirements
- The Project streams need to identify the 'applicable' requirements for that project. We do this by adding/removing requirements from the Module. The flow is easy & intuitive for the users.
- Prior to using Modules, we had an "Applicable" attribute (yes/no)...but, it was high-maintenance to manage the field in a multi-stream environment.
What is often forgotten is that requirements only make sense as collections i.e.
- completeness of the collection
- consistency of the collection
-
dependencies between requirements within the collection e.g. functional vs interface
Reviewing atomic requirements in isolation isn't sufficient.
Modules are also the basis for analysis e.g. which requirements in the parent (module) aren't satisfied by one or more requirements in child (module(s)).
it makes no sense to do this if all you've got is a requirement "soup". You cannot assess completeness (of the collection) without this.
... and documents are far from dead for many of the reasons above so it makes sense to collect requirements in an organised way.
Thanks all for your feedback.
I know what modules are for, having used DOORS before using DOORS NG.
I was telling myself that the document part could be handled via the usage of reports (using Rational Publishing Engine for instance), but I understand and agree that it's far better to have all that in the same tool to act directly in the tool if needed.
I find the term "soup" a bit exagerated though, as many people still find their way without the document view on the requirements
But I agree that modules are definitely required :-)