Requirements Models and 'Construct' reports.

[timoc]

Hi EA gurus,

I have been trying to figure out how to use EA for requirements management. There seem to be multiple overlapping (but mutually exclusive) methods for this.
Requirements models and Maintenance diagrams are a good example, as they are similar to the 'internal item' vs 'external element' with requirements.

I create a maintenance diagram, and add some change elements in a diagram to represent changes to go into a Kanban. I then try to use the Construct ribbon, (or the search drop-down) to get a simple report of all of these changes and it comes up empty. If i add a change item to an element (via properties->construct->maintenance->changes) it appears.

Which begs so many questions:

If you have to use the <element>[change item]? What then is a <common Change element>[change item]?, or a <common Issue element>[issue item]?
Are there existing searches that work for maintenance elements?
How are people using EA in this way? is the best practice to use the <element>[change item]? How does Specification Manager support this?
Can someone explain to me the utility of this split/overlap? are they supposed to be orthogonal to one another?

Any and all answers appreciated, as i cannot yet see the 'hard edges' i expected for requirements management enough to use it with confidence.

[qwerty]

There are too many way to accomplish that. I usually set up individual change elements with a profile in a MDG. If you just want to search for Change element set up a query like "SELECT * FROM t_object WHERE Object_Type = 'Change'"

q.

[Richard Freggi]

Timoc, my thinking is that you are in a common situation, many people find themselves in this quagmire when they ignore proven/robust methodology.
My advice is NOT to rely on EA tool functionalities to help you manage requirements, but the other way round - decide how you are going to manage requirements based on a robust methodology, and then use the EA functionalities that support that methodology.

UML per se does not have much to say about requirements, besides the fact that you can develop stereotypes for them.  But if you look into methodologies like TOGAF or Agile they will tell you how to manage requirements, and you will find EA features that support that methodology (not always 100%, but still make your life easier).

Good luck!

[timoc]

Timoc, my thinking is that you are in a common situation, many people find themselves in this quagmire when they ignore proven/robust methodology.
My advice is NOT to rely on EA tool functionalities to help you manage requirements, but the other way round - decide how you are going to manage requirements based on a robust methodology, and then use the EA functionalities that support that methodology.

This is where i am confused. There is an obvious presumption of fixed workflow/usage in the design of the main element properties Dialogs (e.g. Start->Properties->Construct or Start->Properties->Requirements) because the major features (e.g. Construct ribbon) seem to be designed to support element properties based workflows. Ironically i have yet to find a diagram visualising these implied workflows and how they relate to one another. Any ideas if there is one?

UML per se does not have much to say about requirements, besides the fact that you can develop stereotypes for them.  But if you look into methodologies like TOGAF or Agile they will tell you how to manage requirements, and you will find EA features that support that methodology (not always 100%, but still make your life easier).

I am a TOGAF and Agile practitioner. I need to use EA as an architecture/requirements repository. I want to understand the 'out of the box' capabilities because i do not want to spend too much of my time setting it up. I want to get a repository working and then evolve it (as per TOGAF/Agile best practice!) into something that better fits my needs, as understanding will come with use.

Good luck!

Thanks, but If i need luck then maybe i have already lost

[Glassboy]

I am a TOGAF and Agile practitioner. I need to use EA as an architecture/requirements repository. I want to understand the 'out of the box' capabilities because i do not want to spend too much of my time setting it up. I want to get a repository working and then evolve it (as per TOGAF/Agile best practice!) into something that better fits my needs, as understanding will come with use.

It sounds like you should be modelling requirements at the motivation level then, not the functional level.  http://pubs.opengroup.org/architecture/archimate3-doc/chap06.html#_Toc489946009

[timoc]

I am a TOGAF and Agile practitioner. I need to use EA as an architecture/requirements repository. I want to understand the 'out of the box' capabilities because i do not want to spend too much of my time setting it up. I want to get a repository working and then evolve it (as per TOGAF/Agile best practice!) into something that better fits my needs, as understanding will come with use.

It sounds like you should be modeling requirements at the motivation level then, not the functional level.  http://pubs.opengroup.org/architecture/archimate3-doc/chap06.html#_Toc489946009

I did try to use Archimate3 motivation and requirement elements, as i want to build Work Packages from them: http://pubs.opengroup.org/architecture/archimate3-doc/chap13.html#_Toc489946119

Unfortunately compartment visibility seems to be broken in the Archimate symbols (at least on Goal elements in v14.latest), so no notes, tags, maintenance items, etc can be shown (Info view kinda works but looses color and symbol).

The Archimate approach started to become a rabbit hole, so rather than spend effort building something from scratch (reports, searches, documenting workflows, and creating training material etc)  In the common toolbox there are Requirement/Issue/Change elements, which implied to me that they are there to easily allow you to capture by diagram annotation etc. I started looking for the 'out of the box' requirements workflow as defined by EA and the common elements in the toolbox, for use alongside Archimate diagrams.

So, by 'out of the box capabilities' i am looking for the whatever the full REPL of capture, organize and reporting is for EA's basic requirements management workflow. I started with the assumption that the UI default searches and reports should be linked to these 'out of the box' capture capabilities as defined in the 'common' part of the toolbox.

It is confusing when you have so many of the same terms used in what seem to be different overlapping domains, all with their own assumptions. It has not been simple or basic, as you can tell by my initial post, but i am starting to sort things out in my head. I hope to have enough to deduce what is an EA basic requirements management REPL. All part of the EA learning experience

Do you (or anyone else!) have a working Archimate3 based REPL for requirements management/work packages in EA?

[Glassboy]

I did try to use Archimate3 motivation and requirement elements, as i want to build Work Packages from them: http://pubs.opengroup.org/architecture/archimate3-doc/chap13.html#_Toc489946119

Unfortunately compartment visibility seems to be broken in the Archimate symbols (at least on Goal elements in v14.latest), so no notes, tags, maintenance items, etc can be shown (Info view kinda works but looses color and symbol).

It's not broken.  Those concepts don't exist in ArchiMate.  But the ArchiMate and TOGAF folks don't see that as an issue.

It actually sounds like you want to build your own meta-model and MDG for modelling. 

[timoc]

I did try to use Archimate3 motivation and requirement elements, as i want to build Work Packages from them: http://pubs.opengroup.org/architecture/archimate3-doc/chap13.html#_Toc489946119

Unfortunately compartment visibility seems to be broken in the Archimate symbols (at least on Goal elements in v14.latest), so no notes, tags, maintenance items, etc can be shown (Info view kinda works but looses color and symbol).

It's not broken.  Those concepts don't exist in ArchiMate.  But the ArchiMate and TOGAF folks don't see that as an issue.

It actually sounds like you want to build your own meta-model and MDG for modelling.

I'm sure i will have to. That's where all of the signs point. I have been hoping to avoild it until i need to do it.

[Richard Freggi]

I remember that EA has a TOGAF module that you can license for a fee, there must be documentation somewhere...

I'm TOGAF level 2 certified and happily use pure UML for my architectures.  TOGAF itself is very explicit that it leaves the notation choice and artifact choice to the practitioner (method tailoring).  I capture requirements as text in Excel tracker and then as soon as I can I update the use case / sequence diagram / class diagram / component diagram / deployment diagram according to the tracker.  These diagram sets cover TOGAF Phases A to D and are very strong bases for phases E to G.  It takes skill and experience to translate the text requirement from the tracker into the right model changes, but it's very efficient and effective.  There should be some presentations and workshop guides from me in TOGAF website (not sure if Open Gropu APJ is keeping the seminar notes updated: I presented in 2017 and 2018).

I have not seen much business value in strict end-to-end requirement traceability in real life; my experience is that senior stakeholders like the idea but it can become a nightmare to implement while it does not result in measurably better architectures (at least as far as I've seen) .

[qwerty]

In some industry is it required. Sometimes even out of legal reasons.

q.

[timoc]

I remember that EA has a TOGAF module that you can license for a fee, there must be documentation somewhere...

I'm TOGAF level 2 certified and happily use pure UML for my architectures.  TOGAF itself is very explicit that it leaves the notation choice and artifact choice to the practitioner (method tailoring).  I capture requirements as text in Excel tracker and then as soon as I can I update the use case / sequence diagram / class diagram / component diagram / deployment diagram according to the tracker.  These diagram sets cover TOGAF Phases A to D and are very strong bases for phases E to G.  It takes skill and experience to translate the text requirement from the tracker into the right model changes, but it's very efficient and effective.  There should be some presentations and workshop guides from me in TOGAF website (not sure if Open Gropu APJ is keeping the seminar notes updated: I presented in 2017 and 2018).

Thanks, i will check it out. I'm also level 2 certified, but knowing TOGAF, is not the same as having your organization adopt it. I have found that Archimate works better for my business stakeholders, and UML is better for execution teams. I have a requirement to be able to show requirements and tractability at every level in the models, and they come from various stakeholders and systems. The biggest difficulty therefore is not requirements management per-se, but making and reporting on it as a coherent whole. Having a reasonable single representation as a placeholder in the model, without having to build it from scratch, and some kind of stakeholder reporting is my overall goal.
 

I have not seen much business value in strict end-to-end requirement traceability in real life; my experience is that senior stakeholders like the idea but it can become a nightmare to implement while it does not result in measurably better architectures (at least as far as I've seen) .

I need to be able to relate requirements from various systems together for QA, and the agile execution teams. Architecture is as much about convergence as it is about investment and moving in the right direction. Making this benefit visible to stakeholders helps build convergence, and steer the agile teams away from their own 'agile' short term re-interpretation of your architecture, and what needs to be done.

Many thanks for the workflow. Anyone else out there care to share?

[qwerty]

The most common (I have seen) is to use the dinosaur DOORS to manage requirements themselves (so to uniquely number the relevant text blocks in customer documents). What I did was to  setup a more decent import scheme (than what the DOORS MDG offers) so the requirements are inside EA and can be traced further to synthesized use cases.

q.