• 1.  One Module ... for All requirements?

    Posted Tue April 03, 2018 08:22 AM

    I understand the visual usefulness of organizing a DOORS Project with subfolders and a collection of modules (eg, per the V-model of system engineering) ... but is this necessary? Can all requirements for all disciplines and stages of development be captured in a single module, with appropriate chapters/subchapters (that would follow a more complicated folder hierarchy with multiple modules)?

    I know DOORS is a complex database, and a single module would become Huge, but given the computing power of most workstations nowadays, I'm not sure performance would really be affected. So, what don't I know about DOORS & req engineering that would advise against a single module approach?

  • 2.  RE: One Module ... for All requirements?

    IBM Select
    Posted Wed April 04, 2018 03:17 AM

    With DNG, this isn't feasible.  We have divided out our requirements into modules, and we still have major performance issues with the larger (2000 artifact +) ones. This is despite the fact that DNG is on the highest tier of servers for our company. 

    From what I understand, DNG's poor performance has less to do with the server/workstation environment on which it's hosted and more to do with its basic Jena architecture.  

  • 3.  RE: One Module ... for All requirements?

    Posted Fri April 06, 2018 01:45 PM

    DNG 6.0.5 has tuning settings to help with loading and viewing large modules. Anyone with large modules should have a plan to get to 6.0.5 as soon as possible just for this reason.

    You can read about it here.

  • 4.  RE: One Module ... for All requirements?

    User Group Leader
    Posted Wed August 01, 2018 08:22 AM
    I'm not sure why one would want to put everything in one module. It's like putting all your own documents into a single huge document or all your spreadsheets into a single big one. What a mess.

    Multiple focused modules allows you to work with permissions, review processes, traceability, versioning, history and more, per stage in the V model. And different levels of data have different information which is interesting, meaning with multiple modules you can focus the data on the relevant artifact types, attributes (columns), views (what you see) and reporting.

    If you are designing an airplane and model it on a high-level (say model it with 1 sheet of paper), you have different data than the engineer designing the engines or designing the auto-pilot, and to mix them them means 1000+ columns for data parameters of which 950 are empty for any single row. I'm not hiring that person. Happy to discuss a logical design.


    John Straathof
    Senior Trainer/Consultant, IBM CLM Products