RRC Attributes vs. Tags
Hi there
We are in the early rolout phase of RRC in our organisation. In the different meeting and workshops came several times the same question up: eg: Target Release, Requirement Source, Topic , etc I've actually no good answer. Can someone give me some hints, best practices, link to doc.. whatever helping me in answering this question. Thanks erwin |
Accepted answer
... when would you add Collections to the list? I want to separate and be able to search for a particular Feature or Requirement by Department. The primary purpose of a collection is to provide a "bag of artifacts" with a unique name and URL that can be used to populate development plans in the work item system or be associated with test plans in the QM system (and from there generate test cases) and in both cases establish traceability back to the individual requirements). We envisioned collections representing a set of requirements be delivered in a release or milestone. At the same time we recognized the need (even in our own use) for team members to be able to create collections for many other reasons, and for that reason it's possible to create both shared and personal collections. Part of the decision making process ("When do I use collections, tags or attributes?") should take into account the kinds of questions you are going to want to ask about your requirements information. In this case implied in your example I see these:
Which requirements lack an association with a department? (a requirements quality gap) In the release we are currently specifying, are any departments over- or under-represented in the requirements we intend to deliver? Other parts of the decision-making process should include the following:
* Which kinds of queries does the tool make it easy for me to ask? Filters make it easy to include or exclude tags or attribute values; they are a little less flexible (and it's a little less obvious how to do this) with collections. * Is it a big or small effort to maintain the organizational system? If your departments and their names are stable year-to-year, maintenance won't be much of a problem; otherwise you'll need to be redoing this. Given the above, if your departments are stable, it's probably easiest to use a multi-value attribute to identify the department. This also nicely covers the case of intersecting departments (where requirements apply to more than one department). Erwin Kunz selected this answer as the correct answer
|
5 other answers
|
There is some guidance here:
Usage Tips for Rational Requirements Composer 3.0.1 https://jazz.net/library/article/742 In summary: * tags are best for informal or temporary designations * attributes are best for formal and persisting designations * implement a solution in a way that you will avoid having a lot of "dead" attributes cluttering your requirement types after using RRC for a few years. |
There is some guidance here: Thank you. I already did know the article but didn't find what I looked for. I like your summary. erwin |
There is some guidance here: This is a pretty good recap of using tags vs attributes. However, when would you add Collections to the list? I want to separate and be able to search for a particular Feature or Requirement by Department. Should I add a attribute (Department) of "IT" or "Engineering"? Or tag them IT or Engineering and put them in a collection of "Department"? thanks |
|
Thanks for the quick response!!!
One final question: How do I add a new custom attribute to the "create" form of RRC? Or is it even possible? thanks... |
How do I add a new custom attribute to the "create" form of RRC? Or is it even possible? First, as an administrator, edit the project properties. On the type system tab you can add attributes, including permissible values of single- or multi-value attributes. Then, when you create a new artifact, for example from the big blue button in the upper left of the screen, the artifact will have the attribute you created. But you cannot assign a value to an attribute from that create dialog. * If you want to set a default value for each new artifact of that type, you can create an artifact template, and set the attribute value as part of the template (I think). Then in the create dialog, choose the template. * Alternatively, after you create the artifact, either (1) open it and modify the attribute in the sidebar, or (2) from the project artifact list ("View all Artifacts") select a view that shows that attribute in a column, and set its value for one or more artifacts (all at the same time). |
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.