1 follower Follow

Can I associate/report on issues related to a requirement in a listing of other requirements?

I use requirements in CaseComplete to report on document revisions (a requirements table where the type is Document Revision). What I would like to do is to use Issues in my functional requirements statements to track change requests.

My problem is aggregating all "Issues" (i.e. Change Requests) into a report where the "Requirement" is the Document Revision.


Here's what I would like it to look like:

7/12/13 - Updated business requirements (Tom Tomasovic) [where this is a Document Revision requirement]

REQ-CLM-1 Add group plans (Business User) [where this is an Change Request issue related to REQ-CLM-1]

The thing that would tie the two together is the date, where the "requirement" date is a custom field and matches the Resolve Date on the issue. I've tried listing issues within the requirements table, but that seems to only look for issues which are associated with the current requirement. I've also tried listing the issues in a separate table, but then I have no way of filtering them to get the issues which relate to the "current" release. I've also tried creating a variable and assigning a value to the variable within the requirements table to tie to the issues, but not having much success with that either, since where clauses don't like (accept) variables.

Anyone have a suggestion?



Tom Tomasovic Answered

Please sign in to leave a comment.

1 comment


I think we've got just the thing, Tom - $listAll or $repeatAll.

You're right, when reporting in the context of a requirement, you'll normally get the issues that apply only to that requirement, unless you use one of those $All keywords. Since you can also report on issues at the top level, these keywords allow you to perform a list (or repeat) for EVERY issue in the project, regardless of the owner.

All sorting and filtering syntax used by their base forms call also be used with the "All" variations; you'll probably want to do some filtering and maybe even set up a variable or two to prevent a whole bunch of duplicate listings in your report.

As a side note, where clauses can actually use variables, too. Just make sure you're using the double dollar sign ($$). Let's say for example you want to set up a variable on each requirement so that you can match your custom field later to your issues' resolved date. I'll call my custom field "CustomDateField."

$repeatRequirements where Type = Document Revision

$set $$datecheck $CustomDateField


Now that we've got the variable set, you can show the issues that match that using a 'where': 


$listAllIssues where DateResolved = $$datecheck $Description


So, the above will list all of the issues from your entire project with a DateResolved property that matches the current requirement’s CustomDateFIeld value.

Jason Payne 0 votes