It's all about the answers!

Ask a question

When would individual artifacts be used instead of a Specification for requirements?

Mary Miller (87231) | asked Jul 15 '19, 2:28 p.m.

Good day,

I am used to using Specifications for the development of requirements given I came from an organization that consistently used SSS, SSDD, SRS, design descriptions, test descriptions, etc.

Would there be any instance of when would create individual sets of requirements instead of a specification?  What I could find was here: 

However, I personally would advise people use a Specification unless they needed to develop requirements in an Agile environment where they needed a backlog of requirements.  

Are there any other advantages of creating an individual set of requirements vs. collecting the requirements in a Specification?



Accepted answer

permanent link
Carol Watson (71017) | answered Jul 15 '19, 3:10 p.m.

 Hi Mary,

What we've found works well is to put what we call "Business Rules" in as non-module artifacts. These can include Error Trigger-Type-Message as well as User Interface behaviors.  We then link them to the artifacts in modules where they apply. In our case, our modules are mostly User Interface Requirements.

Our reasons for going this route were:
  • These rules do not have a hierarchy.
  • The same rule often applies in many places throughout the User Interface Requirements.
  • Without the hierarchy of a module, it makes filtering (e.g., all Error Type = Hard Error) cleaner.
  • It helps encourage the users to state each rule separately and not combine multiple rules into one statement (because they know they'll have to link to specific artifacts in the UI Modules).
The whole Module vs. non-module artifact concept is a bit of a learning curve, but even our DOORS 9 users are comfortable with it now.

Hope this helps.


Mary Miller selected this answer as the correct answer

Mary Miller commented Jul 15 '19, 4:45 p.m.

 Okay, thanks!  -Mary

One other answer

permanent link
Davyd Norris (2.4k217) | answered Jul 15 '19, 8:37 p.m.
Carol's response is a good one. I would add a few comments to that:
 - when I start looking at the requirements in a new project, I look at their source. If the team normally creates a document to define the particular requirement artefacts, and releases that document as it is written, I capture them in document format
 - if the created document is something like notes from a workshop, where there might be a lot of contextual information or different types of artefact captured, I import it as rich text into a text based artefact, and then use the DNG editor to turn the important information into individual artefacts that will then be more formally used elsewhere. This allows you to capture more informal sessions exactly as they were taken down, but then synthesise the information into something more formal
 - if the created document is a formal specification, I use a Module artefact type from the start, and format it so that it's as close to the output format as possible. I try to make what is in the tool look like what is output from the tool
 - if the requirement artefacts are not normally initially captured in document form, or are more typically represented in a spreadsheet, I just create them directly in a folder. This tends to apply to supplementary information such as Hazard Logs and Controls, Verification and Validation type artefacts (if they are not being captured in the qm application), Glossary Terms, and the like
 - some artefacts often start out in spreadsheets but then get developed further, such as Interfaces. In this case I will define the initial list in a folder, and then as the interface gets turned into a specification I'll also add it to a Module. Often you want to operate on things like Interfaces as a list, but then dig into the details as part of a spec so this works well

So to summarise, my rule is that if people normally create and manage the artefact in a document, then I start it in a specification. If the document is informal and unstructured, I use a text artefact as the specification, otherwise I use a Module. If they normally create and manage it as a list or spreadsheet then I start as artefacts in a folder.

Carol Watson commented Jul 16 '19, 9:04 a.m.


That makes sense to me and I especially like your last point, starting out with a list of artifacts, then later using them to create a module.  I hadn't thought of that before, but am going to float that idea next time I have a project where that would fit.

Mary, one thing I wanted to mention, our biggest pain point is with the Modules we migrated from DOORS 9.6.  Some were over 10,000 artifacts and three years later I still get complaints about how difficult it is to navigate in them (they miss the DOORS 9 Explorer view).  For new Projects not migrated from DOORS, I'm encouraging them to create "small modules", which in our case means one module per User Interface screen.  That has worked out well, and no complaints from those users.


Mary Miller commented Jul 18 '19, 1:26 p.m.

Davyd, this is great.  I really appreciate these points. 

Carol, okay definitely a point taken.  I missed that too.  Although I did see an RMS extension that did bring back one thing that I liked from classic DOORS - the ability to see the all the module headings without the text.  

We probably won't use that for now, but it is kind of nice especially for people more familiar with classic DOORS.



Davyd Norris commented Jul 18 '19, 9:30 p.m.
@Carol - check out the Module Explorer in the DNG Extensions section. Quite a few of my clients use it to get their familiar old DOORS explorer back.

Your answer

Register or to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.