It's all about the answers!

Ask a question

Requirments and Test Case Relation in Doors and RQM


Hakki Bozkurt (1631228) | asked May 21 '15, 7:28 a.m.
edited May 21 '15, 7:31 a.m.

Hi All,

How should the relationship between the test case and requirment in the test plan?

We were undecided on this issue.

I think we make it 1 to 1 but different an idea, a to-many relationship is recommended.

What do you think? Which one is more sensible and why?

5 answers



permanent link
Adolfo Brandao (60148) | answered May 21 '15, 4:13 p.m.
 Hello, given the high level nature of a requirement, it may yield many use cases and scenarios. Thats why I think you should have many test cases for a single requirement. Hope this helps. Best regrds. 

permanent link
Rohit Rishabh (1531136) | answered May 21 '15, 4:38 p.m.
A high level requirement can be broken into sub requirement and use cases. A business requirement can be further broken into multiple functional or component requirements using parent child links.
Hence you should be having many test cases linked to a single requirement.

permanent link
Hakki Bozkurt (1631228) | answered May 22 '15, 8:43 a.m.
edited May 22 '15, 8:44 a.m.

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.


permanent link
Adolfo Brandao (60148) | answered Jun 13 '15, 2:15 p.m.
 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.



permanent link
Georg Kellner (840378108) | answered Jun 15 '15, 11:16 a.m.
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.

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.