It's all about the answers!

Ask a question

Enhancement Request: RRC Collections should be able to be optionally baselined (immutable)


Andy Phillipson (10431418) | asked Jul 26 '12, 4:38 a.m.
JAZZ DEVELOPER
Not really a question... I tried to issue an enhancement request for RRC but was denied as not having the required license... so, posting it here  ;-)

Also, while I'm here - in the check boxes below this edit box under "Which products is your question about? " the RRC box incorrectly says "Rational Requirements Computer" ..  Ha!!

----------

Collections are extremely useful when they are linked to a backlog plan.  From the backlog plan we can create work items (e.g., stories) for each requirement in the collection and subsequently create child tasks (to the story) to make team assignments that complete the implementation (code it) and validation (write the test case) activities.  To accomplish this it is useful to create a collection (as in the MTM sample) named something like "Release 1 planning" that is linked to the "Release 1 Backlog" plan.

The challenge is that when requirements are added to the "Release 1 planning" collection they can be changed from outside the collection (e.g., from any requirements view, including another collection, that exposes the requirement).

The scenario is as follows:

1. write a requirement
2. create a "Release 1 planning" collection
3. add the requirement to the collection
4. link the "Release 1 planning" collection to the "Release 1 backlog" plan
5. create a story linked (implemented by plan item) to the requirement
6. create a child task to the story that requires some implementation (design, code, etc.) during the current sprint
7. during the current sprint the requirement exposed through the linked collection is modified by a business analyst...

The implementation team may not want to accept the requirement change during this sprint (e.g., let's address this requirement change in the next sprint, or even the next release).  I realize that suspect links can trigger the awareness but that is not the point in this scenario.  The point in this scenario is to enable "parallel requirements authoring" that allows the implementation team to work on a stable set of requirements and accept changes to requirements in a controlled/governed manner.

Having this capability would be extremely useful when, for example, use cases are used to express requirements.  If the use case document (an RRC requirements artifact) is included in a collection and linked to a plan as described then it is very challenging to manage changes to the use case that might simply result in adding new optional or additional behavior (use case alternatives); new scenarios.

When non-use case requirements are used (or in the case of needing to modify the core behavior of the use case) it is still desirable to have the capability to work an implementation against an immutable baseline of the requirement.  This offers a method by which the team can negotiate change and accept change from the requirements team in a controlled manner (at the right time etc).

My design recommendation is as follows:

- Preserve existing capability to allow for backward compatibility.
- Add the capability of the requirement author to optionally baseline the collection and it's contents (similar to the Jazz SCM component baseline) with a named baseline.
- Add the capability of the project manager to optionally select from available collection baseline (or "plain" collection as RRC currently implements) when linking a requirements collection to a plan.
- Add the capability of the requirements inside the baselined collection to be decorated with suspicion icons in accordance with the suspicion profiles in use; the requirement in the collection is not changed (e.g., the text is just as before the suspicion icon showed up).
- Add the capability of the suspect requirements in the collection to be reviewed against the new changes; allow for comparison of the baseline with the latest changes.
- Add the capability of the suspect requirements in the collection to be optionally updated to match the latest changes (this is analogous to performing a Jazz SCM "Accept" operation).

One answer



permanent link
Ralph Schoon (63.1k33645) | answered Jul 26 '12, 5:03 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
edited Jul 26 '12, 5:04 a.m.
Hi Andy, please file an enhancement requests or defects for RRC to support or here: https://jazz.net/jazz03/web/projects/Requirements%20Management#action=com.ibm.team.workitem.viewWelcome

Comments
Andy Phillipson commented Jul 26 '12, 9:31 a.m.
JAZZ DEVELOPER

Would love to but when I try I get the following error:

Missing required license. An error response was received from the Jazz Team Server. Status=400. Message: CRJAZ1848E To perform the "Save Work Item" operation, your server administrator must assign you one of the following licenses installed on the server: Contributor-Floating, Developer-Floating, Developer, Contributor, Stakeholder-Floating. You can contact your administrator, learn more about licenses in the Information Center (under Help > Help Contents), consult the Rational License Key Cent...


Ralph Schoon commented Jul 26 '12, 11:14 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I have a similar problem. I will try to get you the right link.


Ralph Schoon commented Jul 26 '12, 11:24 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I had changed my password and managed to confuse the system. I can access https://jazz.net/jazz03/web/projects/Requirements%20Management#action=com.ibm.team.workitem.viewWelcome can you try to go to mystuff and use the report a bug link to the right? If it still does not work, you shoult try to send a mail to the webmasters.


Andy Phillipson commented Jul 26 '12, 8:07 p.m.
JAZZ DEVELOPER

Yep, I can access the work item page just fine. Just cannot save a work item.

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.