Author Topic: How to deal large number of items in Relationship Matrix  (Read 5509 times)

lordofthering

  • EA Novice
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
How to deal large number of items in Relationship Matrix
« on: July 11, 2021, 09:17:54 pm »
We need to link the requirements and the use case using Relationship Matrix. However, there are hundreds of items for each under its corresponding packages. This makes Relationship Matrix is really large and we need to scroll back and forth a lot. Is there any way to improve the situation? Filter them or split the package?

By the way, this is worse especially when the item in the column has a long name.

qwerty

  • EA Guru
  • *****
  • Posts: 12318
  • Karma: +346/-286
  • I'm no guru at all
    • View Profile
Re: How to deal large number of items in Relationship Matrix
« Reply #1 on: July 12, 2021, 08:03:21 am »
Why the need for the RM? If you focus on a single UC you have to know by reading the requirements which are relevant and you hook them up in a requiemrents diagram related to the UC.

q.

lordofthering

  • EA Novice
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Re: How to deal large number of items in Relationship Matrix
« Reply #2 on: July 12, 2021, 08:29:00 am »
Why the need for the RM? If you focus on a single UC you have to know by reading the requirements which are relevant and you hook them up in a requiemrents diagram related to the UC.

q.

Do you mean to create dedicated diagrams to link different requirements and UCs? There are 2 drawbacks for me.
1) Many diagrams need to be created manually
2) With RM, we can easily see which requirements and UCs is NOT linked

qwerty

  • EA Guru
  • *****
  • Posts: 12318
  • Karma: +346/-286
  • I'm no guru at all
    • View Profile
Re: How to deal large number of items in Relationship Matrix
« Reply #3 on: July 12, 2021, 07:45:35 pm »
I have a composite UC diagram for each UC where I place/trace the relevant requirements along with actors etc. This is a single and useful diagram. As you may have noticed the RM is not that useful when it comes to many relations. You can only work on a single UC and link what req. are needed by getting them from some pre-scanned structure. Requiremens stem from customer documents and are usually "wildly" structured. DOORS might be a dinosaur but for that pre-scanning it's worth the money (I think, don't know the price honestly).

q.

lordofthering

  • EA Novice
  • *
  • Posts: 3
  • Karma: +0/-0
    • View Profile
Re: How to deal large number of items in Relationship Matrix
« Reply #4 on: July 13, 2021, 12:55:48 pm »
I agree with you. DOORS NG is a much powerful tool for requirement management. Anyway, we are using EA now. Your idea is worth trying. Thanks.

qwerty

  • EA Guru
  • *****
  • Posts: 12318
  • Karma: +346/-286
  • I'm no guru at all
    • View Profile
Re: How to deal large number of items in Relationship Matrix
« Reply #5 on: July 13, 2021, 05:37:48 pm »
EA as basic RM tool is likely not the best choice. It works to a certain extend in a small environment. Even there it has shortcomings. Whenever you deal with large volumes of user requirement docs you are better off with handling them in something like DOORS before stepping into UC synthetisation. DOORS does have "something" to model use cases, but that's where you should leave that boat and switch over to EA. Of course, getting the information from DOORS to EA is tricky itself. Life is complicated.

q.

Richard Freggi

  • EA User
  • **
  • Posts: 353
  • Karma: +13/-7
    • View Profile
Re: How to deal large number of items in Relationship Matrix
« Reply #6 on: July 13, 2021, 06:19:20 pm »
Although what the OP wants to do is useful, I'm not sure if it is compatible with UML metamodel.  This would explain the limited support by EA.  I'd much prefer keeping EA fully consistent with UML over adding functionalities.

Maybe some Sparxians can help me here, I remember that in UML 2.5 Actors are classifiers but use cases are not (maybe?) so the proper UML way would be to use a class diagram (with OCL if really needed) to document the requirements as constraints on the classes.  Also can use the use cases descriptions to fill in semantics, context etc.  That would be fully supported by EA even for very large models.

Geert Bellekens

  • EA Guru
  • *****
  • Posts: 11229
  • Karma: +413/-33
  • Make EA work for YOU!
    • View Profile
    • Enterprise Architect Consultant and Value Added Reseller
Re: How to deal large number of items in Relationship Matrix
« Reply #7 on: July 13, 2021, 06:48:29 pm »
EA does support linking requirement objects to use cases just fine, that's not the problem. You have the same problem when trying to model relations between use cases and classes.

The thing is that in order to keep your model manageable, you should limit the number of items in a package. My "rule of thumb" is to not put more then 20 to 30 elements in a single package. (pretty much like how you would organize your files into folders)

You can then use the relationship manager package per package to create the relations between use cases and requirements.

Geert

Modesto Vega

  • EA User
  • **
  • Posts: 624
  • Karma: +18/-8
    • View Profile
Re: How to deal large number of items in Relationship Matrix
« Reply #8 on: July 13, 2021, 08:05:08 pm »
Although what the OP wants to do is useful, I'm not sure if it is compatible with UML metamodel.  This would explain the limited support by EA.  I'd much prefer keeping EA fully consistent with UML over adding functionalities.

Maybe some Sparxians can help me here, I remember that in UML 2.5 Actors are classifiers but use cases are not (maybe?) so the proper UML way would be to use a class diagram (with OCL if really needed) to document the requirements as constraints on the classes.  Also can use the use cases descriptions to fill in semantics, context etc.  That would be fully supported by EA even for very large models.
According to the UML 2.5 specification:
Code: [Select]
A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors (p. 637)In fact, both Actors and UseCases are BehavioredClassifiers (please see pages 645 & 647)