Best Practices / Ideas for setting up Projects
We are evaluating Composer for Requirements Management and wanted to see how others are defining "Projects" within the tool.
For example; is a Composer Project an application or is it a business initiative for an application?
Our organization is broadly diversified, but there are cross-functional projects on which many Business Analysts will collaborate.
Looking for opinions on what worked and what didn't work for folks who have previously adopted Composer.
Thanks in advance.
One answer
Not sure what type of organisation you are but if you are following CMMI, and strong governance is required for auditing / reporting perspective, I guess it's better to put RTC into consideration from design stage.
If BA needs to work closely with dev and testing, collobaration is regarded as a key to a project success, CLM provides ideal platform for that.
In terms of organising a requirement project, rrc can cope with business initiatives + composing requirements + decomposition of requirement + share requirement with dev and test.
If you have any specific topics or consideration as success criteria, I guess it would be easier for the community to provide you more relevant info.
Comments
Appreciate the response.
We are failrly close to CMMI - so that is the context in which I would want to look at it.
My initial take is that each Composer project should equate to a business initiative. So, if I had a Payroll application that had to be changed to allow for the entry of wage garnishments, I would set up a project called "Wage Garnishment Entry." The trouble I see is that this could get ugly fast. I will have thousands of projects (unless I further organized them additionally in some way).
I should also note that we are looking at Composer just for requirements - development is largely done in Microsoft TFS and testing is done in HP Quality Center. We would initially produce physical requirement documentation out of Composer (like we do today out of MS Office) and slowly mirgate our Stakeholders to viewing requirement info in Composer (and potentially feed TFS and QC from Composer).
Can you "folder" projects in Composer? That would seem to be the best design, but I am not sure.
I see where you are from. I guess using RRC, you can still define decomposition level for your requirements, for example
Level 1 - Business initiatives
Level 2 - Business requirements
Level 3 - Functional requirements
Level 4 - Technical requirements
and you can keep track of your initiatives by traceability. You can definitely use folder organisation for your projects but if your business initiative representing a projet, you might not need to.
If you are gonna have thousands of project and keep them in one single RRC project repository won't be feasible since it has limitation in terms of number of artifact as well as size of data for performance issue. Also, if you are using CMMI, Change control should be a key criteria. Without using RTC, I think RRC might be too flexible.
So my final verdict ( not sure how reliable it is :) would be to use a single RRC project for each project you run and use folder organisation for requirement decomposition levels. I guess this way you should be available to produce documentation for different stakeholders.
In addition to that, there should be more consideration to think of such as
Support parrellel development?
Requirement reuse?
Measure / governance model?
Using RRC + HP ALM, you can integrate them to consolidate information, which can support matrix and governance.
Thanks Charlie... I wasn't aware there were limitations on projects/artifacts.
Do you have a link to any IBM-published guidance on this?
Thanks...
I think I might have given old information since it seems IBM improved performance and sizing for RRC. I found the link below for performance benchmark
https://jazz.net/wiki/bin/view/Deployment/CollaborativeLifecycleManagementPerformanceReportRRC406Release