What are the essential tools for Systems Engineering?

The most important tools for systems engineering are a functioning set of brains, with diverse view points, experience, and speciality working together - in particular being curious and asking all the awkward, often unasked questions about the system being created / modified, and the systems / enterprise need to realise / produce the system The test of a software tool is whether it supports and enables this thinking, or prevents it - either by preventing / ‘replacing’ thinking, or being too awkward, or difficult, to use (which includes communication to non-tool experts Too often engineers look to tools to replace the difficult job of really thinking (especially about the question)

The increased focus on Model Based Systems Engineering has resulted in engineers that look to create models, and have forgotten that the purpose is Systems Engineering. There needs to be a renewed focus on the basics of developing good requirements. Good Systems Engineering combined with inherent modeling can be a powerful tool, but Systems Engineering needs to be the focus.

From The Art and Science of System Engineering by M. Ryschkewitsch, D. Schaible, and W. Larson 1. Intellectual Curiosity. Ability and desire to learn new things 2. Ability to see the big picture 3. Comfortable with change 4. Comfortable with uncertainty and unknowns 5. Proper Paranoia. Expect the best - plan for the worst 6. Ability to make system-wide connections 7. Exceptional two-way communicator 8. Strong team member and leader 9. Self confidence and decisiveness short of arrogance 10. Appreciation of process-rigor and knowing when to stop 11. Diverse technical skills - ability to apply sound technical judgement

The most important 'tool' for System Engineering is a logical, disciplined thought process. Unless you know what you are trying to do you will never select the right tool to do the right job. "First make sure you are developing the right solution, then you can focus on making sure you develop the solution right.'

I think it's pretty tough to argue that a dedicated requirements management application isn't the most important tool for Systems Engineering practices to be successful. Sure, spreadsheets can do a good job of organizing, but only at one level. Showing traceability through layers, being able to maintain "multiple to multiple" relationships between items, and making it easy to navigate through layers, are not native functions of the typical spreadsheet software. Without the dedicated tool, requirements can easily be lost. But perhaps more importantly, it is nearly impossible to put a process around a spreadsheet, because there are no built-in mechanisms for formal review and approval.

For a reliable and robust system, it's critical to have proper modelling and simulation analysis performed. The initial investment into tools, effort and time should be evaluated with business objectives. To optimise cost of modeling and simulation, it's important to have a strategy based on re-usability and modularity of models, so that overall development cycle and cost can be optimized.

Modeling and simulation tools allow systems engineers to create models of the system's components and interactions. They can simulate system behavior under different conditions to analyze performance and make informed design decisions. Examples include MATLAB/Simulink, SysML (a modeling language), and simulation software like AnyLogic.

In my experience managing interfaces, particularly external interfaces, to the system is very crucial. Failure to manage interfaces can render the system unsuitable for the intended purpose or to catastrophic failures that even the best modeling and simulation could not predict.

Modeling and Simulation Tools are where the rubber meets the road in systems engineering. Think of these tools as your virtual sandbox. Before spending big bucks on physical prototypes or deployment, you get to play around with different setups, conditions, and variables. This is where you can answer your "What if?" questions without breaking the bank or delaying your timeline. Take network design as an example. You could simulate how your network architecture behaves under heavy load, or what happens if a key node fails. You can even model how your system interacts with external systems, or how it'll scale as your user base grows. The insights from these models can highlight bottlenecks or vulnerabilities that you hadn't even considered.

Configuration management is probably one of the most important components of the system engineering process. In the products I have worked on developing this not only defines the source control as listed in this section, but also in maintaining multiple fielded configurations within a family of products. Without a clear configuration management strategy this would have quickly become a mess.

Configuration Management is a very important part that there is not a commercial solution for it, yet. We developed a software linking different modeling and documentation tools which may help us to control changes and interfaces truly, however, it is still under improvement based on our needs in the projects.

Systems Engineering activities are characterized by iterative processes, and involve a broad range of tools throughout the system life cycle, which poses a challenge of tracking changes coming from those various assets. Configuration Management tools help capture the changes of all the assets at important milestones, and are therefore a key component to manage the project.

The most important thing I've found is to really think through *how* you're going to use the tool. Be very specific on the use cases. For example, do you want detailed Gantt charts? Resource loading? A quick learning curve so multiple people can come up to speed quickly? Think through these both for your business today and where you want to be in a year, as you don't want to outgrow the tool after only a few quarters of use. Once you have your use cases do your research - I've seen applications where MS Project was the best choice, some where Asana was, some where Smartsheet fit the needs the best, etc. So do your homework and think through your use cases (which as a Systems Engineer you should be very used to already!) - good luck!

Make sure you define a project management process and KPI's that work for your business before selecting a tool. Most people just jump in and use the tools without considering the end goal. Creating wonderful reports of data are often meaningless because the effort to maintain the input is time consuming. This results in misleading reporting and a lot of wasted effort.

Big organizations managing hundreds of high-complexity projects cannot do without project management tools. These applications help project managers estimate deadlines based on available resources, overall risk of the organization, delays of other projects, top management change strategy, suppliers, etc.

All you need is a basic task board that everyone can see and communicate to each other at the task level. Wherever possible, information should be transparent for all users and located as granular as possible. I.e. discussion around a specific task should happen in the task so the context of the discussion has clear boundaries. Often businesses default to bureaucratic information hoarding which prevents collaboration and reduces productivity.

Knowledge Management is the key asset of organizations, big or small. As the number of stakeholders, tools and the overall complexity of systems grow, there is a need for collaborative solutions in organizations. Also, agile development and other organizations which foster teamwork and cross-level coordination have a strong need for efficient communication tools.

Active collaboration is an important pillar of good systems engineering and an efficient systems team. When dealing with complex systems it becomes a very important part of overall design activities as the dependencies, interfaces, technical oversight and task management become quite important. Hence having a tool that enables all of these combined with proper traceability and change management paves a path to quality systems engineering. Creating tasks, progress tracking, planning, risk management and product delivery are some of the activities a good collaboration or work management tool should enable. Easy to use and a neat and clean user interface is an added bonus.

This is more important than any of the others. Start with the fundamentals: meeting structures, mentor/mentee parings, and ways to keep the whole team aiming at the same goal. We waste time putting tools in place before thinking about these basics.

I mostly agree with the previous comment regarding centralized task boards, but I would go one step up from this and say that the task board needs to be linked with some iteration of your requirements. I have worked in teams where this is done both physically and virtually, and seen it be a mess in both cases. The solution seems to be having a clear hierarchy to the tasks that ties them back to features and establishes some implied or pseudo code test as a requirement for the tasks creation.

There's a couple of good tools on the market which help show traceability from parent requirements to test protocols and finally the test results. These are very useful if you have a regulatory requirement to produce a traceability matrix. Cognition Cockpit and DOORS do this well.

Systems Engineering isn't a Skillset or a Toolset. It has to start with a Systems Mindset! This kind of systems thinking consists of: 1. Insatiable Curiosity 2. The humility to accept we don't know as much about the system as we'd like to think 3. Intentional freframing to see if the problem statements and requirements change with perspective. This can be captured as a simple mantra: "If you think you understand the problem, step back and see if you understand the system."

As we all know the key value of applying systems engineering is collaboration development and traceability through the system development lifecycle from the requirements phase to design and simulation to v&v and plm. We do have individual tools that operate effectively at the specific parts of the V model implementation but the key success and benefitial outcome of SE application would only come when these individual tools can interact with each other. I feel the Dassault 3Dexperience is one of the first and best tools in the SE implementation as it covers all the phases of the V model starting from requirements thru TRM, modelling and simulation through cameo and simulia and so on and so forth.

Your brain! Many people just use tools and processes blindly. Use your head!

I always characterized the essential skill of a systems engineer is the ability to “know a little about a lot.” You have to be able to think differently than your colleagues who “know a lot about a little” and identify problems and issues they don’t see.

Yes, there are useful tools for analysis, design, and simulation, and I like the observation that it starts with a system mindset. Effective systems engineering also requires communication — with the intended users and between those responsible for interfacing subsystems. A good systems engineer ensures that these conversations occur regularly and in depth.