Some of you may be working on systems with many complex relationships between the parts. These complex systems may be described as a system of systems, or may be described as a product line, or perhaps both at once.
In these cases, you will often find that the requirements of a large, overall system are shared among a number of related projects, each of which implements some well-defined part of the overall system.
In this environment, it is really good to have a team of Business Analysts who work collaboratively on all the requirements of all the projects. Another approach is to have one or more Business Analysts work on the shared requirements, then have Analysts on each project work on the detailed requirements for that project.
If you do not have that kind of relationship between Business Analysts in your company, it is good for everyone to work informally with the Analysts on the other projects to share work as much as possible. This will lead to greater consistency and will avoid wasted effort in developing the same requirements multiple times.
You can use tools such as DOORS or Rational Requisite Pro to show the relationships between the requirements in different projects. For example, you might define a ReqPro project for a set of common requirements that all the projects share, then put a folder in that ReqPro project to store the requirements of one software project. That way, all of the related projects can see what is common and what is specific to a particular project. By reviewing the requirements of other related projects, a project team may find some similarities they can take advantage of.
If you have to keep one version of a set of requirements for one set of projects, and develop a new version of those requirements for another set of projects, then you would likely want to copy the first set of requirements, for example into a new ReqPro project, then edit the requirements in the new project. You can set up a trace relationship between the relationships in the two ReqPro projects.
I do not know DOORS, but assume you can set up similar structures in that tool.
A good book for project teams involved with complex projects is “Designing Software Product Lines with UML”, by Hassan Gomaa.
I have also written a paper with an example of a system of systems/product line approach to requirements. It is called “Requirements Structure in a System of Systems / Product Line Architecture. You can find it at:
http://www.writingusecases.com/wordpress/index.php/
report-requirements-structure-in-a-system-of-systems-product-line-architecture/
Author: Geri Schneider Winters
* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at http://www.writingusecases.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.