Logic of a "Package"

[Crush]

As far as EA is concerned, what is the definition of a "package" ?

 In other words, how should I create my packages to best align with the methodology inherent in the tool?

I am generating a ton of requirements for our project and I just create a new package for each "functional" type of requirement, (ie. a "print" package, a "UI" Package, etc..)

Not sure if this falls in line with the way EA works (Im a newb).

One of the guys on the team wanted to have a package for every "Feature", but I dont like that idea... since we may have features that cross functional boundaries..

Any ideas are greatly appreciated!!!

Thanks in advance!!!

 

[Paul Lotz]

EA will support whatever logical organization you choose.

Common groupings are by component or by type of requirement (functional, performance, etc.), or a combination of the these.

If you have a system that is complex enough then you might set up a package for each component, and then have a package for the functional requirements for that component, and so on....

Paul

[Geert Bellekens]

I usually use packages to group elements that somehow belong together. This somehow is usually the fact that they all deal with the same functional concept or area.
So my packages are much more oriented towards components then towards the type of the elements.

I alwas try to have some other mechanism to indicate the "type" of an element. Think of naming conventions (prefix/suffix), stereotypes, tagged values, or other properties that you can set on the element to define its (sub)type.

This type of organisation allows two type of groupings, where, if you use packages to group elements of the same type, you loose the "belong together" aspect.

Remember, there is only one package hierarchy possible, so use it wisely.

Geert