represent real projects in a RRC project area
We are thinking about having one RRC project area for each business unit at our company. What's the best way of organizing the requirements in the project area? I'm more interested in knowing how to organize requirements for different projects. Every time we need to make changes to an application/product, we group all the requirements into a project. Inside the RRC project area, should you organize your requirements by applications or by projects? When requirements in a project have been implemented, should you move them out of the project folder and into the corresponding application folder?
Accepted answer
That could work, but there is no one right answer here. I offer some considerations below.
1. Some teams think of requirements as one-project artifacts. They are implemented in a project and not used again.
2. Other teams think of requirements as the evolving capabilities of a an application, system, or business process: old requirements requirements as "how the system works now" and new requirements "how the system will work when this project is over"
In the second case, the team starts with the latest "old" requirements and adds to them or modifies them for the next project.
In general, requirements are most useful (and understandable) when they are in a meaningful context -- not as atomic statements. So keeping them associated with use cases, scenarios, etc. is a good idea.
Will applications/products be modified by multiple projects/teams at the same time? If so, you want this to be visible to all relevant teams to foster communication and coordination where it's necessary.
Also ... my earlier post on this subject might be helpful:
RRC the right Project Area set up?
1. Some teams think of requirements as one-project artifacts. They are implemented in a project and not used again.
2. Other teams think of requirements as the evolving capabilities of a an application, system, or business process: old requirements requirements as "how the system works now" and new requirements "how the system will work when this project is over"
In the second case, the team starts with the latest "old" requirements and adds to them or modifies them for the next project.
In general, requirements are most useful (and understandable) when they are in a meaningful context -- not as atomic statements. So keeping them associated with use cases, scenarios, etc. is a good idea.
Will applications/products be modified by multiple projects/teams at the same time? If so, you want this to be visible to all relevant teams to foster communication and coordination where it's necessary.
Also ... my earlier post on this subject might be helpful:
RRC the right Project Area set up?