RRC... customer centric or product centric?
I have a fairly generic question that I think I know the answer to but I want to verify it. In general you create a single RTC instance for a product.... it is product centric. I would say the same thing about RQM... you would in general create a single instance of RQM to contain all the testing needs of all versions or releases of that product.
Would you say the same thing about RRC? You could set up one RRC instance and all customer requirements captured within it or you could set up a separate instance for each customer.
Personally I think the former is correct (one RRC instance) but I wanted to see if there were people out there that have gone the other way. I'd like to know why they decided this and how it has worked out for them. I can see it being workable when you have a small fixed set of customers but I don't see it scaling up.
Would you say the same thing about RRC? You could set up one RRC instance and all customer requirements captured within it or you could set up a separate instance for each customer.
Personally I think the former is correct (one RRC instance) but I wanted to see if there were people out there that have gone the other way. I'd like to know why they decided this and how it has worked out for them. I can see it being workable when you have a small fixed set of customers but I don't see it scaling up.
3 answers
Hi Guy,
I have only seen single instances of RRC too. I feel like it would be natural for decision makers to prioritize requirements from multiple customers or multiple products with using different projects over one single instance (with the same public URL.) When it comes to RTC, RQM, I would say instances could be different because developers and testers would be different.
I have only seen single instances of RRC too. I feel like it would be natural for decision makers to prioritize requirements from multiple customers or multiple products with using different projects over one single instance (with the same public URL.) When it comes to RTC, RQM, I would say instances could be different because developers and testers would be different.
If you look at this article https://jazz.net/library/article/853 and specifically Illustration 3: Overview of the CICS Jazz server architecture, towards the end, you will see an example with several RRC instances, where one is used for the overall customer perspective and then other instances of RRC for individual product projects.
In general RRC requirements tend to have more a business focus that span multiple systems, products and releases, where specific milestone requirements maybe be contained in RTC as stories.
In general RRC requirements tend to have more a business focus that span multiple systems, products and releases, where specific milestone requirements maybe be contained in RTC as stories.
Comments
Hi Robin,
Thanks for this pointer. Nice to see a slightly different usage scenario. I don't think this is changing my mind for the particular scenario I have ..... a discussion where we have a request for a separate RRC instance for each customer of the product. I just see scaling issue if we do this and I think we can use a single RRC instance and still be able to easily identify separate customer requests and have multiple people working with multiple customers successfully in this one RRC instance environment.
This is a new scenario to me and I wanted to do some due diligence and see if others out there had a set up like this and if so get some feedback on whether it is working for them.
I'm a long time user of RequisitePro and Rational Requirement Composer.
Its my opinion that Product and Client Solution requirements should be managed separately as our clients' solutions often will incorporate many IBM products and technologies, not to mention non-functional solution requirements and solution deployment requirements. Thus it’s my preference and practice to capture and refine a customer's requirements separately from one another and then associated them to the products and technology that best address them.
As I work with customers I keep individual customer requirements separate from each other while refining them to simplify how I work with my customers. My approach is to refine customer business needs to IT requirements that map to the capabilities of IBM products (new and existing) and other emerging technologies. For me as a customer facing IT solution architect its pretty black and white. I don't want my Nation Wide Insurance requirements mixed with my American Airlines or REX Hospital requirements.
If your organization is responsible for rolling out the complete solutions, I cannot envision managing the engagement any other way. However, If your organization is product focused and solely responsible for developing product offerings, I can see that combining all customer requirements into a single RRC instance would be tempting and could make sense in many cases. For organizations that have both solutions and product development responsibilities, the black and white lines become blurred. In working with customers who have requirements that are complex and diverse where a subset of their requirements contribute heavily to 1 or more than 1 product’s direction, I think it’s appropriate to manage their requirements separately as solution requirements. On the other hand, if you have 10 or 50 other customers who only contribute a few requirements to a product’s direction, I can see grouping them together in a common RRC project to minimize administrative tasks and costs. Of course for these 10 or 50 customers, their other solution requirements will still need to be managed by the services organization.
Linking the individual customer requirements in RRC projects to specific products (managed in RTC) is how requirements are consolidated for each product that a Development team is producing. This linkage is one mechanism of how customer requirements can be prioritized as product requirements (Requirement Z is linked to 6 customers). Of course not all customer requirements are linked to products under development, thus they would not be linked to a development teams RTC projects.
Requirements that are best addressed by a new product’s capabilities (features in plan or features yet to be prioritized to be in plan) would first be captured in RRC and refined - maybe as a high level business requirement and then refined to one or more system level requirements before being linked to a product’s RTC project. This linkage is a primary feature of the Rational CLM tools - you select a RRC customer Requirement (system level) and simply create a link (via the RRC User Interface) that renders the customer requirement as an artifact in a Product RTC project to be prioritized into a Sprint.
One Example of a CLM Environment
Its my opinion that Product and Client Solution requirements should be managed separately as our clients' solutions often will incorporate many IBM products and technologies, not to mention non-functional solution requirements and solution deployment requirements. Thus it’s my preference and practice to capture and refine a customer's requirements separately from one another and then associated them to the products and technology that best address them.
As I work with customers I keep individual customer requirements separate from each other while refining them to simplify how I work with my customers. My approach is to refine customer business needs to IT requirements that map to the capabilities of IBM products (new and existing) and other emerging technologies. For me as a customer facing IT solution architect its pretty black and white. I don't want my Nation Wide Insurance requirements mixed with my American Airlines or REX Hospital requirements.
If your organization is responsible for rolling out the complete solutions, I cannot envision managing the engagement any other way. However, If your organization is product focused and solely responsible for developing product offerings, I can see that combining all customer requirements into a single RRC instance would be tempting and could make sense in many cases. For organizations that have both solutions and product development responsibilities, the black and white lines become blurred. In working with customers who have requirements that are complex and diverse where a subset of their requirements contribute heavily to 1 or more than 1 product’s direction, I think it’s appropriate to manage their requirements separately as solution requirements. On the other hand, if you have 10 or 50 other customers who only contribute a few requirements to a product’s direction, I can see grouping them together in a common RRC project to minimize administrative tasks and costs. Of course for these 10 or 50 customers, their other solution requirements will still need to be managed by the services organization.
Linking the individual customer requirements in RRC projects to specific products (managed in RTC) is how requirements are consolidated for each product that a Development team is producing. This linkage is one mechanism of how customer requirements can be prioritized as product requirements (Requirement Z is linked to 6 customers). Of course not all customer requirements are linked to products under development, thus they would not be linked to a development teams RTC projects.
Requirements that are best addressed by a new product’s capabilities (features in plan or features yet to be prioritized to be in plan) would first be captured in RRC and refined - maybe as a high level business requirement and then refined to one or more system level requirements before being linked to a product’s RTC project. This linkage is a primary feature of the Rational CLM tools - you select a RRC customer Requirement (system level) and simply create a link (via the RRC User Interface) that renders the customer requirement as an artifact in a Product RTC project to be prioritized into a Sprint.
One Example of a CLM Environment
Comments
Hi Holt
Thanks for taking the time to explain this. I had not looked at things from this point of view before and I see your point here. In your scenario you are using RRC to collect requirements for goodness knows what from a customer and then organizing them by products and feeding the requirement back to that product. This would work as long as the number of customers did not explode.
Comments
Ginny Ghezzo
JAZZ DEVELOPER Nov 04 '13, 6:00 p.m.Good question. I've only seen single instances of RRC. It will be interesting to hear how others have managed multiple customers.