No offense taken. It is the purpose of the discussion to clarify. As such, I never claimed this discussion was based on or was restricted to UML definitions or terminology.
By the way, I am a visual computing / graph grammar specialist. There have been several attempts to model the UML as a visual language. Every parsing process I know about for the UML is sketchy at best. If the UML was a true, well defined language, we could dispense with "code generation" and execute UML models directly. Work continues in this direction.
No, I am not new to the UML--I just happen to disagree that the UML is "correct". It applies rigidity in its definition while rejecting rigidity in its use at the same time. It supplies a definition, but allow the user the flexibility to interpret that definition for their own use. As such, the UML does not define how a user should specify, construct, or define design. It simple provides some basic tools to model them. It is based on graph theory, but then bastardizes its terms to define itself. It is fairly well defined in this respect.
As you say,
This is unfortunate as UML "steals" all these common terms and gives them its own twist.
As far as terminology and definitions I use are concerned, I make the following disclaimers for your benefit:
----------
1. For any graph you care to consider, whether called a hierarchy, lattice, tree, etc., when a single node is selected as a root node, any sufficiently satisfying spanning tree defines a parent-child relationship from root to leaves. Therefore, I use the commonly accepted definition for parent-child, not the UMLs.
2. All edges in the UML are simply labeled edges that specify context. I implied that "aggregations", "generalizations", and "nestings" are parent-child. I should also state they are directed edges which limits and defines the parent-child relationships within a satisfying spanning tree.
3. You said
although UML uses the term Package, it doesn't use it in the same way as we would normally accept
I counter that UML uses the term "Package" precisely as user intends it to be used. It is a generic container tool. It is the user's responsibility to define its use within a project and is used pervasively by various UML tools in the code generation process for languages, such as Java, for specifying package constructs.
4. It is commonly accepted that, w.r.t parent-child relationships, a child may have one or more parents. The selection of the parent-child edge within the spanning tree is arbitrary as long as it satisfies. Therefore, at will, we may selected the satisfying edge for the tree.
5. For any "hierarchy", a comprehensive spanning tree can be constructed by arbitrarily adding a single root/parent node that connects all "superior" nodes as children. This process applies to any graph. I apply this to requirements modeling by declaring a "single root project / application / system" requirement node to which all other requirements aggregate.
----------
To address your issue on "Requirements Element", this issue is no more serious than the way in which a user defines the use of the tool. When I say "contains", I am stating in the request, a desire for a single internal requirement to
define the element w.r.t. requirements as a requirement element. Categorically, I desire elements to be "requirement" only, "design" only, or both (in general, both). A simple way to do that is to declare the generic element with a requirements definition (a requirements element "contains" a requirements definition, its properties, which IS the requirement). This definition should be within the generic element--as its internal requirement properties. I do NOT want an external definition as it is redundant (see below) and does not provide the typing mechanism I need to specify the SRS (I need UI Concept, Use Case, System, Feature, Class, Attribute, Method, Instance, Event, etc., types to properly section the document).
You say,
an EA "internal" requirement is best conceptualized as an an element's responsibility
You may choose to view internal requirements as an objects responsibilities. I have no use for internal requirements defined in this manner. If an element it "responsible" for something then it "realizes" one or more "requirements" and each can be defined as external without exception. This leave the realm of requirements specification and enters design. I am not concerned with relationships between requirements and design. This is well established in EA. I am only concerned with the proper relationships between requirements.
Here is an example problem: EA views Use Cases as "design" elements as, by default, it realizes (external) requirements. I can manually specify aggregate relationships for UCs in a requirements model, but EA still does not view them as requirements (they do not show up as external requirement "parts" for its "whole", if you wish). I have never seen anyone "design" a Use Case, so it should not "realize" anything. I have seen a system "realize" a Use Case and a Use Case used to specify the "requirements" for other requirements that, in turn, specify "design" elements that are "realize" or implemented, such as classes. Therefore, strictly speaking, a Use Case element is a "requirements" element. Systems, subsystems, modules, packages, classes, etc. are generally "design" elements. They "fulfill", "realize", or "are responsible for fulfilling" a requirement such as is specified in Use Case, Feature, and Class requirements.
However, there is no such thing as a class "requirement" element within EA. We can arbitrarily declare one, but it is no different than any other requirement. And, as I need to define a class "design" element for it anyway, there is a one-to-one relationship (I declare its need once in the requirements and its fulfillment once in the design) --therefore, it is completely redundant. If I could declare the class element as a "requirement" within the context of the requirements model diagram, I could use the same element in a class model diagram, reduce the redundancy, and self-satisfy its "requirement" definition with its "design" definition.
Enough for now.