How does this compare to https://github.com/FundingCircle/fc4-framework? If I understand correctly, FC4 was a 2-way sync but strictly revolved around the proprietary Structurizr? (And I'm not sure if it is still maintained) While overarch looks like a one-way sync, EDN input, multiple exports?

Ah, my mistake. Just found https://github.com/soulspace-org/overarch/blob/main/doc/design.md :)

Yes, no two way sync at the moment. Modelling is done in EDN only (at least currently). But I want to prevent any lock in, so the data can be exported as JSON and as Structurizr workspace (experimental).

It looks like a nice project. What's the "reusable" part of the story? Is that achieved by using :ref ?

Btw. there's a small typo in Rationale: https://github.com/soulspace-org/overarch#rationale > But but the models

Thanks for the feedback, the typo is fixed now. Regarding the reusable part of the story, it should be actual reusable on different levels. With :ref the reusablility of model elements in different diagrams is archieved, which is a benefit over the diagram focused specification in the PlantUML C4 DSL, where you have to duplicate information in the different diagrams. Another level of reuse (and composablity) is the combination of smaller models to larger models with loading all EDN files in a directory, namespaced IDs to avoid conflicts and :ref's to refer to other model elements. Even another level of reuse lies in the plain data specification and the extensible nature of EDN. you can augment models with information that is not evaluated by overarch, but maybe other tools working on the data. Because it is just plain data, you don't need a specific parser to read the model and view descriptions. And with the JSON export you can even reuse the data in languages, for which no EDN reader exists. So the model is not bound to overarch as a specific tool but stands for itself.

👍

That's a great summary. Perhaps worth adding to the docs in some form?

That's a good idea. I have to reformulate it a bit and find a place in the docs. Thanks.

I've added it as a Q&A in the design documentation.

Hi @U017HM6BG07, thanks for publishing overarch, looking at it now. If you were to have more textual elements for requirements engineering and traceability, how would you go about it?

Thanks. Traceability can be realized with relations between the different model elements, e.g. between a use case and a container or component. Currently there is no view to visualize those relations, but it could be rendered with graphviz like the context view. For requirements currently only the use case view exists. You could enhance the model with your own attributes (e.g. in another namespace). Or if you f´have ideas on how to model requirements, we can discuss them and see if they fit into the concept of overarch. The goal of overarch is to provide a holistic approach to modelling software systems.

Maybe you could provide me with an example of what you like to achieve with requirements.

Yes relations between the elements is definitely the approach (hence overarch:). I'm considering using https://github.com/nextjournal/clerk to create the glue, I guess one could create a requirements.edn file containing the data, clerk could load it and display it in various ways, tabular of course, but I'm sure we can also have queries, filtering, etc. I guess one could have custom viewers in clerk for displaying the overarch generated diagrams...

I wonder if clerk could also help with writing the requirements, meaning using forms and writing back to the edn file...

The file structure for your model is completely in your hands. Overarch just picks up every .edn file in the model dir recursively.

I'm currently modeling a system with 50 external systems connected and about 80 containers. Putting everything in one file is no option. 😜 So I'm using a deep directory structure and context-boundary elements to model some internal structure.

How do you like to model your requirements? As use cases or user stories? Or more like a catalog of flat requirements?

There was some Eclipse tool I used in the past, based on the Requirements Modeling Framework and the ReqIF format, that could give some ideas on how to structure the data so that ReqIF export could be envisaged (I dont really need that format but it seems a good idea while avoiding the NIH syndrom)

If I were to capture the requirements now I'd use some word document, and smart referencing with models in other tools. But the idea of having everyting captured as data like overarch does, including traceability, while allowing various forms of visualization is appealing.

I will take a look into the framework and see what I can make of it.

I have to attend other matters now, but I'm planning to look into clerk and get inspiration from ReqIF to define an edn data structure, starting simple of course.

Overarch hasan initial markdown export so generating textual documents is in scope. 🙂

I suggest #C03RZRRMP for publicising events 🙂

@U060WE55Z Deleted as off-topic from #C06MAR553 Feel free to post it in #C03RZRRMP