Hi All,
Could you please share some guidance on Requirements definition using RRC, as to
1. The order of artifacts creation
2. Linking of RRC Artifacts - like associating graphical artifacts to the main requirement artifact etc
3. Is the User Story elaboration, the main requirement artifact and all other artifacts would support it by linking to it?
Similar way, Is Use Case spec the main requirement artifact and all other artifacts would support it by linking to it?

Please share any process that you are currently following

Thanks

The order of the artifact creation may change depending upon which is your project process.

For example if you are following a more agile process and use stories, you might take the product backlog user story work items and create elaborations in RRC, then create a Storyboard. However if you are following a Use Case process, it would be create a Vision document, then the use case diagram, then the specifications before creating the storyboard.

In these two examples the Use Story Elaborations and Use Case Specifications would be the main artifacts, with both links to Vision (Epic) documents that describe the theme for the release, as well as any stakeholder needs, with links to analysis and design documents that help the developers and testers. So a typical trace tree might be Stakeholder need traces to Features that trace to Use Stories Elaborations that trace to visual diagrams, that trace to implementation work items, that trace to test cases.

Note: There are some Rational Method Composer practices, "Shared Vision", "Requirements Management", "User Stories". and "Use Cases" that describe this in more detail.

Thanks bater. I have a few queries on the above:
1. By Vision(Epic)-> Is this the Epic WI in RTC?
2. So, we would do User-Story-elaboration for Agile and Use-Cases for waterfall and other related artifacts like diagrams, needs, features would be related to these main artifacts. These main artifacts would be linked to RTC/RQM Artifacts based on scenario. Does the order of creation really matter?
3. In case of a Business/System requirement, Which artifact would be the best that would support this? - could it be a feature (or) supplementary?
4. Trace tree would change based on our artifact creation order?

Could you please share any related links for best practices, Requirements management, shared vision, etc relating to RRC Usage.

In regards to the Vision(Epic) this can be an RRC document that groups RTC Use Story Work Items together to form the Epic, with supporting comments and descriptions around the embedded links to the RTC work items in the body of the text. This is similar to our own usage in the RRC team.

Now both Use Cases and User Stories can be iterative, with Use Case Main (Basic) flow being developed in one iteration and the Alternative Flows in subsequent iterations. The main difference is the length of iteration, and whether they must be completed in the iteration or not - Use Stories YES - Use Case Flows not necessarily. Though I do see many customers use Use Cases in a Waterfall pricess.

I have also seen some customers use Use Cases Specifications as a form of Epic, with the Use Stories being part of the Use Case Flows.

In our own development of RRC we have RTC Plan Items that describes the high-level plan objective, associated to an RRC Document that describes in more detail the objective together with any other user requirements, architectural discussions and Storyboards. From both these RTC plan items and documents, we describe the individual use stories. For example one feature we have planned for the next major release, we have several storyboards, several architectural documents in RRC, with more than 100+ user stories in RTC. The user stories being implemented in the many milestones we are delivering.

Here is the CLM 2012 RM plan

https://jazz.net/jazz03/web/projects/Requirements Management#action=com.ibm.team.apt.viewPlan&page=com.ibm.team.apt.web.ui.plannedItems&id=_VBH2wKG5EeCUuZ6KJYHdnw

Core Module support

https://jazz.net/jazz03/web/projects/Requirements%20Management#action=com.ibm.team.workitem.viewWorkItem&id=44243

That has some 200 Children Stories and links to two high-level RRC documents, that link to several other architectural documents and storyboards. Unfortunately at this time we cannot share these documents.

In regards to the practices you can find some more information on DeveloperWorks

https://www.ibm.com/developerworks/rational/practices

And yes the trace tree would change depending upon not the creation order but more the parent-child (dependency) order. Sometimes we find that not all requirements are created from the top but from the bottom - so you might have a situation whereby the creation order is not strictly top-down.

Thanks Bater. Which RRC Artifact would be equivalent to Business/System requirement - could it be a feature (or) supplementary?
When is a Business Rule artifact used and which artifacts would it link to?

Thanks.

With the RRC type system, and Administrator role, you can can create your own requirement types. So there is no need to use feature for Business/System Requirement but you can create you own. If you have the Administrator role, use the RRC Web Client "Manage Project Properties" to add types and links. This menu is found in the top right corner of the client.

In regards to the Business Rule artifact this would typically constrain feature requirements, as well as any User Interface designs. For example in the Money That Matters example, we have a business rule that entered dividend values cannot exceed 100% so this constrains not only the Feature where by customers can enter a value but the User Interface as well. To show this constrains relationship we add a custom link type.

These customized projects can then be use for new projects, by creating a project template. This is another function of the administrators page.

Hi Bater,
I have a few queries on the artifacts usage:
1. Is the Business process diagram artifact used only in a Waterfall methodology?
2. There will not be a Business process diagram for each requirement. There can be a few depicting the overall business process flow (General). Is my understanding correct?
3. Is the Vision document a Mandatory artifact? We did not use a Vision document in Req.Pro and we are planning to cover it as a part of the requirements itself. How would this vision document help in CLM Point of view, say?

Thanks Bater. Which RRC Artifact would be equivalent to Business/System requirement - could it be a feature (or) supplementary?
When is a Business Rule artifact used and which artifacts would it link to?

Thanks.

With the RRC type system, and Administrator role, you can can create your own requirement types. So there is no need to use feature for Business/System Requirement but you can create you own. If you have the Administrator role, use the RRC Web Client "Manage Project Properties" to add types and links. This menu is found in the top right corner of the client.

In regards to the Business Rule artifact this would typically constrain feature requirements, as well as any User Interface designs. For example in the Money That Matters example, we have a business rule that entered dividend values cannot exceed 100% so this constrains not only the Feature where by customers can enter a value but the User Interface as well. To show this constrains relationship we add a custom link type.

These customized projects can then be use for new projects, by creating a project template. This is another function of the administrators page.

A business process sketch is usually written by the business, and is usually at a high-level of abstraction. Each sketch can contain task and sub-processes. With each sub-process being its own sketch.

Now is this type of sketching only for waterfall - No. We use it in iterative development to provide the business flow that the implementation of a set of requirements will support. Now these requirements can be linked to tasks, swimlanes, pools etc. So you could use it in an agile environment as an Epic, with the tasks linked to Use Stories, even though for some it is not an agile artifact.

Also we use a business sketch often without the pools and swimlanes, so it shows visually flows of the process.

In regards to a Vision Document, just like any process and its artifacts should be customized to your own needs. If you don't have a need for a Vision document then there is no need to create one. However, We like to use am artifact (customized to meet our needs) that describes the high-level objectives and business case for the next major release, as it focuses the executives, architects, designers, developers and testers on what we are trying to achieve.

So this document contains the high-level requirements, that map to plan items, which in turn map to user stories.

If you look at this plan for 2012

https://jazz.net/jazz03/web/projects/Requirements%20Management#action=com.ibm.team.apt.viewPlan&page=com.ibm.team.apt.web.ui.planlinks&id=_VBH2wKG5EeCUuZ6KJYHdnw&planMode=com.ibm.team.apt.viewmodes.internal.backlog2

you will see several links to collections which contain the requirements from these high-level documents. Unfortunately we do not allow you to see the RRC content as it is confidential as it contains business case information, as well as strategy and architectural discussions. Not sure if you expand the links how much you will see but the high-level requirements in the collection, are linked to the plan items implementing them. Each plan item might have 10s or 100s of user stories.

You will also see that our plan links to the both the overall CLM release plan, as well as the particular CLM milestone plan.

Robin Bater

@valli there is no one "right" answer regarding how to do this. It depends on the process your teams will follow, and that should be based on your project methodology and the characteristics of projects they are doing.

You might benefit from some advice on methodology and how to customize the tool accordingly. This could be provided by experts from IBM Software Services for Rational or one of our business partners.