Requirements Hierarchy not Realising aggreggation

[Steve Roberts]

Hi all. Perhaps I am missing something obvious. I spent some time ensuring an imported requirements csv file had parent/child relationships in the CSV_KEY and CSV_PARENT_KEY columns. This worked well in terms of the project browser showing the hierarchy. But I seem to now be having to go create the actual "link" relationships regardless - eg to create a aggregation part relationship. Is this by design does anybody know. After all arrangement in hierarchy surely suggests its an aggregation or compsition by default ?
Thanks
Steve
PS; This would be less painful if for example dragging a requirement on top of another created the relationship but Im faced wit using the quick linker (which is not too quick when you have several hundred relationships to create).

[Eve]

The provided CSV import doesn't create connectors.

If ownership implied aggregation then there would be no point creating the connectors. They are two different concepts and CSV import can only do one. If you really want that behavior you could write a script that looped over child items and created an aggregation.

[Steve Roberts]

Simon thanks for the feedback. I take your general point, but for requirements specifically ownership DOES imply aggregation. Its the lack of intelligent behavior for specific defined object types that is a frustration. Whether I import, or whether I create parent/child structures in the project browser is irrelevant really - requirements hierarchies are a concept that goes back 40 years. I guess I'll have to learn how to write scripts unless a simple example is available then as the matrix approach is equally unintelligent/cumbersome for this very simple need.
 

[qwerty]

A hierarchy does not tell how to implement it. Nesting and creating aggregation are two different ways to represent a hierarchy. Both ways are completely legal, valid and interchangeably. If A is nested in B then A owns B. It's the same as saying A aggregates B.

q.

[Steve Roberts]

Qwerty - Im afraid I disagree. When I look at the Links property on a requirement UNLESS I specifically create a relationship then there is no recognition that the Requirenment has a parent.  Im not concerned with implementation details yet; this is supposd to be an EA tool addressing the architure concerns of traceability and gap analysis   If I want to ensure traceability from requirements I first need to establish dependencies and relationships. All I am asking is is there a way to have Sparx automatically create those relationships given I went to the laborious trouble of creating the hierarchy. If there were lots of choices of relationship type that made sense for Requirement to Requirement I would get that its not possible to have a common sense automatic behavior, but there arent. This sort of usability hurdle/ feature stops the tool being used by non experts as its a very basic "requirement" for requirements management. I'm trying to persuade business analysts to have a look to broaden its usage but I'm struggling myself !

[qwerty]

Honestly I prefer connectors over nesting. That was one reason I created my own importer for DOORS. However, traceability is given in both cases. Of course you can create element traceability only via relations since you need 1:n relations. But a requirements structure is not depending on that. I think that creating relations when nesting elements introduces an unwanted redundancy.

q.

[Steve Roberts]

Hi qwerty. For sure, but I am focussed on traceability and gap analysis and BAs who "get" hierarchy and arent too UML savvy. However GOOD NEWS.

Either new in version 12, or already there in 11 but I have upgraded now to the beta (brave...but Im nit in production use yet on this contract) if I right mouse click on the object in the browser, choose Add, I can create link of whatever type I want, in bulk. Does the job pefectly with no scripts in sight  

[Steve Roberts]

Small bug with the above. On selecting multiple other elements to link to , the very first relationship it sets just as a dependency regardless of what connection type I select , but all the others it sets to the right type.