Book a Demo

Author Topic: Requirements & Archimate 3 Requirements Stereotype.  (Read 8173 times)

timoc

  • EA User
  • **
  • Posts: 201
  • Karma: +14/-0
    • View Profile
Requirements & Archimate 3 Requirements Stereotype.
« on: March 12, 2020, 02:06:15 am »
I have been looking into EA and Archimate for requirements management. The idea being something like:

- Create "Archimate 3 Outcome"
- Using the properties window - Outline any Requirements, constraints and Scenarios internally to the element
- Once an internal requirement is approved, move to external requirement for further refinement.

EA creates the external requirement element as a native EA requirement type, rather than an Archimate Requirement, which i cannot change the stereotype of, so it does not look like Archimate. Creating Archimate requirements manually does not work too well either. Archimate Requirements elements are classes, not EA requirement type elements, so i have to do more around them to get the same level of support (e.g. in document generation, searches, etc.).

For that matter, i have other internal element properties i cannot externalize with EA, but have Archimate element counterparts.
e.g.
Internal element constraints -> Archimate Constraint
Internal internal scenarios -> Archimate Course of Action

So i am trying to think about approaches. On one hand, Archimate types are visible and usable by others. On the other hand, EA native types offer features that are not available to classes.

Are others using architect in this way? any advice or ideas (other than don't use EA!)

Glassboy

  • EA Practitioner
  • ***
  • Posts: 1367
  • Karma: +112/-75
    • View Profile
Re: Requirements & Archimate 3 Requirements Stereotype.
« Reply #1 on: March 12, 2020, 11:36:56 am »
Personally no.  If I'm going to use ArchiMate I use pure ArchiMate.  If I find myself trying to use any of the UML underlying the Sparx implementation, I stop using ArchiMate and switch to UML.

Sunshine

  • EA Practitioner
  • ***
  • Posts: 1353
  • Karma: +121/-10
  • Its the results that count
    • View Profile
Re: Requirements & Archimate 3 Requirements Stereotype.
« Reply #2 on: March 12, 2020, 11:54:59 am »
Ditto - I wouldn't recommend that approach.
If you are working in the Enterprise Architecture level then use ArchiMate for enterprise strategies, roadmaps, future states etc.

If you are working on system or software requirements use functional and non-functional requirements the built into Sparx EA. Alternatively use user stories or use cases with scenarios, constraints etc.

Plenty of books out there on the topic.
Happy to help
:)

timoc

  • EA User
  • **
  • Posts: 201
  • Karma: +14/-0
    • View Profile
Re: Requirements & Archimate 3 Requirements Stereotype.
« Reply #3 on: March 12, 2020, 08:45:28 pm »
Ditto - I wouldn't recommend that approach.
If you are working in the Enterprise Architecture level then use ArchiMate for enterprise strategies, roadmaps, future states etc.

If you are working on system or software requirements use functional and non-functional requirements the built into Sparx EA. Alternatively use user stories or use cases with scenarios, constraints etc.

Plenty of books out there on the topic.

I've been playing with the idea of a requirements model that starts with Archimate and drills down to UML, while using the native 'otRequirement' object type in the element for the properties window dispatcher. This is based on the assumption that stereotypes can be applied to other EA object types when making an MDG.

adepreter

  • EA User
  • **
  • Posts: 190
  • Karma: +10/-10
    • View Profile
Re: Requirements & Archimate 3 Requirements Stereotype.
« Reply #4 on: March 12, 2020, 09:45:12 pm »
This is how we successfully resolved these problems at very large scale:

We use target capabilities as in the Scaled Agile Framework (SAFe).
Since target capabilities are high-level requirements, we use stereotyped requirements.
https://www.labnaf.one/ln-content/EndUserMaterial/02_00/guidance/index.html?guid=C9AAB9B6-F352-4fbf-8607-BE8854753986

So we can then create target capabilities roadmaps:
https://www.labnaf.one/ln-content/EndUserMaterial/02_00/guidance/index.html?guid=874C7F1E-E5D3-4224-8495-CB6B9F13CB3F

And to avoid the usual semantic mess around "business capabilty" vs "business function", we use the word "Enterprise Functions" to define our functional taxonomies and the word "capabilities" for the target capabilities that we plan to deliver. So there is no more discussion.
https://www.labnaf.one/ln-content/EndUserMaterial/02_00/guidance/index.html?guid=4F851039-52E7-4511-BE54-0958BBE06E86

Whatever the terms are, we first focused on the definition of the transformation process and on the semantics needed (conceptual metamodel) throughout the process.
Then we derived a language metamodel which is our real user-friendly metamodel that is both readable and used for validation.
Then we defined the viewpoints needed throughout the process along with the dependencies between these viewpoints.