It's all about the answers!

Ask a question

Using Rational Requirement Composer in a a waterfall approach environment


0
1
Robert Rocco (112) | asked Aug 07 '12, 9:21 a.m.
edited Aug 07 '12, 11:26 a.m.

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



permanent link
Robin Bater (3.4k47) | answered Aug 07 '12, 3:55 p.m.
JAZZ DEVELOPER
Is there any reason you are using separate project areas for your applications and projects?

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
Robert Rocco commented Aug 08 '12, 10:25 a.m.

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).


Robert Rocco commented Aug 08 '12, 10:26 a.m.

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.

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.