Handling requirements relatedto multiple contracts

[Davide]

Hi all,
      I’m in the common situation to manage requirements related to different contracts. Obviously there are some relationships among these requirements; for example they may overlap. How do you suggest to handle these relationships in EA? Is it recommended to use one meta-package (my company) and then a single package for each contract? Or one EA project for each contract?
Obviously the answer should change based on my objectives; I just want to save effort in documenting requirements, realize overlapping requirement to save effort in the development phase.

Thanks in advance,
Davide

[Jan ´Bary´ Glas]

... the answer should change based on my objectives...

Yes, that's true. As work for me - different customers, different approach.

[thomas.kilian]

... save effort in documenting requirements...

I guess that never pays off. The more exact you document requirements, the less pain you have later in the project.

If you have some kind of global requirements then you should consider using a global tool for them. EA works nicely for medium projects (whatever that measure would be). Most of the projects (even large ones) did not use any RM tool at all (a bunch of XLS and DOC files distributed over several networks describes best practice I've seen in the best way). So putting requirement into a single EAP and exporting them as XMI for reuse in other models would be gold against that.

[Oliver F.]

The answer propably depends on the type of project, your companies structure/setup and the product itself.

A principle which pays off for us is to split up the process into customer projects and development projects.
One or more customer projects are injecting requirements which are then collected into one or more development projects, in this process requirements are filtered for synergies/overlaps (which are then joined together into one requirement if possible).

That way we reduce redundancies, can benefit from synergies (thus lowering costs) and improve the overview/structure a lot.

For the development project it is mostly transparent which requirement is targeted at which customer as they get the same product.

However this approach has a few drawbacks:
- It requires an intensive requirements engeneering
- in the worst case low range customers get a high range product for a lower price so you will have to take countermeasures against benefitting from features the customer did not pay for
- It will not scale down well for small products
and a few more.

Summary: Joining requirements can pay off very well but it requires and appropriate process, some thoughts and good handling.

I hope this helps.

Oliver