Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Requirments and Test Case Relation in Doors and RQM

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?

0 votes



5 answers

Permanent link
 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. 

1 vote


Permanent link
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.

1 vote


Permanent link

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.

0 votes


Permanent link
 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.


0 votes


Permanent link
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.

0 votes

Your answer

Register or log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,019
× 7,495
× 218
× 198

Question asked: May 21 '15, 7:28 a.m.

Question was seen: 6,299 times

Last updated: Jun 15 '15, 11:16 a.m.

Confirmation Cancel Confirm