It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×6,098
×3,952

question asked: Jan 28 '14, 2:39 p.m.
question was seen: 2,992 times
last updated: Jan 28 '14, 4:37 p.m.

Related questions

Grouping Requirements Projects in Folders

0
Duncan MacLean (1●2●2) | asked Jan 28 '14, 2:39 p.m.

Very new to Composer (we are evaluating it). 

Is there a way to group the Requirements Projects we create into folders or some other container?  We may end up with 100's or more Projects and it would be helpful to be able to do this.

Thanks in advance.

One answer

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Daniel Moul (4.9k●13●18) | answered Jan 28 '14, 3:02 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
It would help to ensure we are using "project" to mean the same thing.

RRC uses "project" to be a grouping mechanism for artifacts, their types, and permissions (including users' ability to see or modify these artifacts).  In this sense, there is no higher grouping mechanism on one server.  However each project is accessible with a URL, and you could have one or more landing pages elsewhere (or even in a special RRC project) that provides a directory to the other RRC projects.

People use "project" to mean a temporary endeavor that results in some deliverables.  In that sense a RRC project could contain artifacts for more than one project.

Comments
Duncan MacLean commented Jan 28 '14, 3:33 p.m.

We are still working through how we would use the project concept in Composer.

Our initial thought was have a project equate to a "business initiative" - e.g., 4-day Shipping Service.  So this project would have a number of requirement statements, rules, use cases, etc. associated with it.   As I mentioned, we would have 100's (eventually 1000's) of business initiatives - some small and impacting a single application and others quite large that could impact 100 applications.

I am not sure this is the best approach though.

Daniel Moul commented Jan 28 '14, 4:36 p.m.
FORUM MODERATOR / JAZZ DEVELOPER

Key criteria for creating RRC projects are (1) to provide boundaries for who can see / interact with the artifacts, and (2) to partition and organize sets of related artifacts.

In general, you want your RRC projects to persist and be reused over time. So within a RRC project you would create/modify/interact with artifacts in many of your project initiatives.

I have seen a couple of different organizing approaches:

  • Organize by application - OK but doesn't take a business view
  • Organize by business process - Good, but may not make clear application boundaries (and thus provide a good mapping to who should see/modify artifacts in various application dev teams).
  • Organize multi-tier:  one for business process, one for application
  • Additionally project-specific artifacts could be stored in a third RRC project or in a folder hierarchy in these two RRC projects.
Hope that helps. It might be worth investing in some design time with a consultant from Rational or an IBM business partner who has done this before and can bring more client examples to your attention.

Daniel Moul commented Jan 28 '14, 4:37 p.m.
FORUM MODERATOR / JAZZ DEVELOPER

NOTE TO OTHERS READERS: it would be interesting to hear how YOU organize your RRC projects.

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.