Blog

January 20, 2017

Introduction In Part 1, we created a SysML model for an IoT product and the system engineering project for developing the IoT product. This model is represented by the gray blocks in the center of Figure 1. Figure 1 Total System Model architecture However, we must recognize that most of the engineering effort takes place

January 18, 2017

In Part 1 and Part 2 of this series, we focused entirely on possible visualizations of inter-model connections, i.e. connections created by Syndeia between elements in different tools. But many use-cases require us to trace connections across the system model where the sequences include both inter-model and intra-model connections. Syndeia 3.0 can show many of these,

January 12, 2017

Consider a healthcare facility with independent software systems for each department. A system engineer is tasked with developing a message exchange system between the departments based on the HL7 Version 2 standards. She begins by describing the interfaces and content exchanged between departments based on SysML interface blocks. The flow properties of these interface blocks are typed

January 6, 2017

In Part 1 of the blog series on Syndeia-JIRA interface, we described how Syndeia can connect to and browse JIRA repositories, and generate and connect SysML blocks from JIRA issues so that the block’s value properties mirror the issue characteristics like status, last update, etc. In Part 2, we showed how a multi-level SysML structure (e.g.

January 5, 2017

In Part 1 of this series, we connected individual requirements in DOORS NG to requirements and other elements in SysML. Greater challenges arise when we need to map requirement structure and organization between tools, because different tools organize requirements in significantly different ways. SysML tends to organize requirements in simple tree hierarchies using containment relationships.

December 15, 2016

Introduction Every system development project has both product-specific and project-specific considerations: Product-specific includes product requirements (market, technical, regulatory), product function and hardware and software design Project-specific includes organization structure, project requirements, and product development methodology The intersection of these two domains is often the Work Breakdown Structure (WBS) which captures the product-specific tasks in the