Using Rational Requirement Composer in a a waterfall approach environment
Good morning,
I work for a financial (Insurance) company that currentlly uses RRC v4.0. We are at the very beginning of our journey. Our team uses a waterfall project methodolgy.
The question I have revolves around using the tool to run multiple project requirements for one application (in some cases multiple). Our RRC environment will be broken down into one application environment library, within the the repository and multiple project folder/libraries. The folder/projects are separate from the application library.
My concern is; how would multiple Business Systems Analysts (BSA) be able to make changes to their project and then promote/incorporate them into the Application library? Keep in mind that an artifacte that was copied into BSA#1's own project library could have been modified by BSA#2 in their own (#2) project library and then copied by BSA#2 back into the application library, before BSA#1 copies their version. In this situation BSA#1 would need to perform some sort of retrofit based on what was promoted by BSA#2.
Please provide some guidance on how companies are rolling our RRC for on application system running multiple concurrent projects in a waterfall project methodolgy.
Thanks
Robert.
One answer
In RRC V4 - you can create team areas where you can restrict Create, Update and Delete access to folders, sub folders and artifacts contained in that structure? To move artifacts between folders requires somebody with project permissions who could move the artifact from folder to another folder.
If you need to control read access then separate projects will be needed and the new ReqIF interchange format will be needed to copy artifacts from one folder to another.
For more information for exchanging information between RRC projects please see this help topic:
http://pic.dhe.ibm.com/infocenter/clmhelp/v4r0/index.jsp?topic=%2Fcom.ibm.rational.rrm.help.doc%2Ftopics%2Fr_compare_data_exchange.html
Now parallel development of two BA's modifying the same library artifact will require copies of their work to be added to the application library and then their work manually added together.
Comments
I need to comment in two segments because of the 345 character limit.
Thank you for helping Robin. I really appreciate it. As you can guess I am new to RRC and so is the company. We are one of Canada's largest Institutions.
The reason we using separate project folders is to allow the department to keep the application (AKA production version of requirements) area is to allow the team to reuse the artefacts on a go forward basis.
Our team works in a multi-project environment. The releases of program source code and requirements are dictated by the projects. As different teams complete a project (i.e. each team has a different project completion date). They will bundle their source program and requirement artefact changes and promote them into a production system environment. In the case of the RRC artefacts, they would be moved to an application area (i.e. consider production version for reuse by the next project).
Each time a new project is started, we will have a Requirement configuration manager set up a new project. Artefacts, as required, are selected by the Business system analyst and copied from the Application level project folder and copied into the project folder. In other words, an instance of the artefacts is copied.
I guess the reason we are approaching the RRC set and process in this manner is that we are a multi-project waterfall approach shop. I guess if we were using the agile approach it would only be one library and we would release all artefacts in a sprint (one logic unit of work) as a team.
Not sure if I was clear, or if were going about it the wrong way.