Welcome to the Jazz Community Forum
Requirments and Test Case Relation in Doors and RQM
5 answers
Hi Adolfo and Rohit and all,
Our Structure is(for one demand in doors);
-> business req. (all req. in single artifact)
-> func. & non fun. req (all req. in single artifact)
-> feature (all feature in single artifact for single app)
Why i am not split into pieces? or Why i am split into pieces this artifacts? Which one is right way?
1 artifacts validated by many test cases in a test plan(for example unit test plan) Do you think this makes sense?
or 1 artifacts split more artifacts(linked extracted/extracted by) and each splited artifacts related test case(1to1).
Which one makes sense? And why?
Could you please explain it? Thanks a lot.
Hello Hakki,
When you say artifact It sounds like a module, which is a feature for logically organize and structure a set of related objects i.e. requirements, stories, features, etc. Modules give that set of objects a context for specific purposes, for example, documentation, testing, validation and verification. Module structures and boilerplate text also be reused in different projects.
On the other hand, any object is considered to be an artifact i.e. requirements, stories, features, modules, etc. The objects can also appear in different modules.
In your case, I think you could consider separating functional from non functional requirements in different modules, creating links between them, if necessary. You can also create a module for requirements specification, having both functional and non-functional requirements.
Each object can be validated by one or more test cases. You can create a test plan for each module, containing all test cases for the objects inside of that module. So yes, it makes sense.
When creating an object, or artifact, you must think of the lowest granularity possible for the level of abstraction you're in, avoiding having more that on requirement in the same object.
Hope this helps.
I think there is no answer to use 1:1 or many:many.
We are in a railway industry.
A general requirement is: If the train passes a red signal, it has to stop automatically. So it should be one testcase, passing the red signal, looking if it slows down to 0 km/h.
An other requirement is, if the train passes a yellow signal, the driver has to slow down in a defined way.
There would be two testcases:
1.) The driver doesn't slow down in the defined way -> the train has to stop.
2.) The driver slows down in the defined way -> nothing happens. But in this case, you can test, if the definition "how to slow down" is implemented in the correct way.
greetings georg.
We are in a railway industry.
A general requirement is: If the train passes a red signal, it has to stop automatically. So it should be one testcase, passing the red signal, looking if it slows down to 0 km/h.
An other requirement is, if the train passes a yellow signal, the driver has to slow down in a defined way.
There would be two testcases:
1.) The driver doesn't slow down in the defined way -> the train has to stop.
2.) The driver slows down in the defined way -> nothing happens. But in this case, you can test, if the definition "how to slow down" is implemented in the correct way.
greetings georg.