Test Case step related to Requirement

No, there isn't.
If you need to ensure traceability you would need to separate the steps into separate test cases.

I would also find it useful to be able to cite a defect report number/link at that same step which points to a requirement.

In this way a reviewer could follow along a test run and see when steps failed which requirement was connected, and that a defect report was filed against that failure, and which defect report.

We currently address this as Bob describes, using the Notes field.  Yes, we're forced to settle, which is unfortunate considering all the untapped Jama potential in this area.  

 Imagine this:

a.  If a [linked to / related] test step changes, or the item traced to it changes, the "to" and "from" items, as well as the link/relationships themselves are flagged as suspect (with a pop-up, email, something conspicuous - it's user/admin configurable) which tells me that an important requirement may no longer be adequately tested. Since I have 10, 20, 30, 40, or more requirements tested by this test case, if a single test step or requirement changes, I need only investigate the items linked / related to that changed item rather than all test steps or all requirements, as must be done now when linking the entire test case.  True, test cases could be broken down into smaller units but that's not always practical, and essentially puts a much greater burden on the user who'd rather use a tool to alleviate such burdens.

b.  Verifying proper traceability becomes less burdensome and traceability (and coverage view) reliability increases significantly. I no longer must spend extra time trying to 'figure out' where / how / if each requirement that traces to a test case, including the one just created to fill a hole seen in Coverage View, is actually addressed somewhere within the test case.

2.  I look at a requirement /item's test tab and see if / when that particular item was tested, whether it passed (satisfied) or failed, under what conditions (i.e. the test date/time, the test case and version, etc.) I can now more easily compare the test history for this particular item, as well as its version history, with other 'system' changes or conditions – this helps in troubleshooting and root cause analysis, among other benefits.  I can of course do this without the new 'trace-to-step' feature, but not as seamlessly.

3.  I generate reports and charts showing test status of individual items, and patterns, and more – essentially the same type of reports and charts that I could generate external to the tool, but now at a fraction of the time and effort. I can more readily respond to customer status requests, or better yet, they can see more directly for themselves.

 
4.  I'm happier, and less frustrated! My customer is happier, and impressed!

P.S.  @Kristina

------------------------------
Steve
------------------------------
-------------------------------------------
Original Message:
Sent: 06-23-2016 14:53
From: Kristina King
Subject: Re: Test Case step related to Requirement

Thanks for providing some context around this, szawasky. It sounds like people would love to see Test Steps act more like discrete items than item fields...

@Kristina Hopefully it leads to a non-fiction masterpiece!