System design is the key to long-lasting, scalable, and maintainable systems and is therefore also essential for agile projects. Developing system architecture with objectiF doesn’t always necessarily entail the creation of graphical design models. You can set the focus and graphically display only as many aspects as you need.
System elements can also be set and related to requirements without diagram displays by using forms. This is also creates traceable and navigable paths between requirements and system architecture.
But you can also decide to use a graphical system design – for example, in the case of modern REST architectures with a variety of services. objectiF RPM provides simple block diagrams where the relationships between requirements and architecture elements can be clearly visualized. These give you a clear overview.
Whether form-based or with diagrams – both methods ensure traceability from requirements to system design.
With forms, establish relationships between requirements and system elements
Use design models for implementation
When it comes down to understanding system architecture, making design decisions visible, and localizing necessary changes, design models for system design show clear advantages. In order to ensure that only exactly what you designed gets built, objectiF RPM goes one step further. You can use design models – for example, block diagrams – to generate source code and then easily switch to the code editor with the click of a button from within the design context.
Doing so is worth it. The lightweight form of model-driven development – MDD – ensures compliance with chosen architecture styles throughout all system releases, with planning patterns and automated implementation steps.
Trace development – from requirements up to code
Many questions arise while working on a project – for example, concerning the impact of requirements changes. This question has two aspects: For which stakeholders is a change relevant? And which planned or already implemented components, as well as test cases, need to be modified? Another frequent question: What changes were actually made in the code due to a user story and who made them and when?
In objectiF RPM the answers to such questions are just a few clicks away.
Here objectiF RPM offers the following useful features:
- configurable and filterable real-time queries of the repository.
From within each query you can navigate directly to the affected elements.
- visualization of relationships between requirements and architecture elements in design models.
In each diagram element, it’s possible to call up further diagrams and additional information.
- a history of all results in the project.
In the history you can open previous development stages with already used forms and select any versions for comparison.
Particularly useful are:
- the requirements diagram.
This makes visible the path from stakeholders and their requirements to the test cases and system elements that fulfill them.
- The block diagram.
This ensures that requirements are traceable from system components all the way to code.
Deploy solutions with microservices in the cloud
In order to achieve high agility, many companies choose to establish a DevOps culture. In other words, they combine two skills in their teams: development competence and the ability to continuously provide solutions. Microservice architectures – in other words, small, decoupled services that communicate via defined APIs and are developed by independent teams – are particularly well-suited for this. objectiF RPM supports the development of microservices with:
- patterns for simple structuring of expertise into domains,
- backlogs per domain and team for independent development,
- functions for API-definition, design and implementation.
This really pays off for your company: Direct cloud deployment with objectiF RPM helps your teams shorten deployment cycles, more rapidly roll out innovations, and more easily scale systems.
Diagram types for system design