When would individual artifacts be used instead of a Specification for requirements?
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: https://jazz.net/library/article/87165
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?
Thanks!
Mary
|
Accepted answer
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:
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.
Carol
Mary Miller selected this answer as the correct answer
|
One other answer
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.
Comments Davyd,
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.
Carol
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.
Thanks!
Mary
@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
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.