A Systems Engineering Tools Taxonomy
By Robert Halligan
A SYSTEMS ENGINEERING TOOLS TAXONOMY by Robert J. Halligan FIE Aust CPEng IntPE(Aus) Email: rhalligan@ppi-int.com Copyright © 2021 Project Performance International. All rights reserved. Authored for PPI SyEN.
Abstract Utilization of software tools and cloud-based services to support a systems approach to the engineering of systems continues to grow apace. This reliance led to Project Performance International (PPI) and the International Council on Systems Engineering (INCOSE) establishing under a Memorandum of Understanding a project to develop a systems engineering tools database (SETDB). One aspect of the work on this project has been the development of a systems engineering (SE) tools taxonomy to assist in organizing data on SE tools. The development built upon work previously done by the author. This paper describes the taxonomy that has resulted and is used with the SETDB (see systemsengineeringtools.com). Principles for defining tool categories The following principles were defined for use in developing the taxonomy. These principles were derived from a study of the intended users and users of the database, the aim being to maximize ease of use of the SEDB: Principle 1.
The taxonomy should accommodate stand-alone software tools, families of software tools, and cloud-based services supporting systems engineering.
Principle 2.
Each tool category should possess a significant orientation towards one or more practices commonly associated with systems engineering, viz. problem definition/problem solving/verification/validation, and management of these activities, as contrasted to a more general application. This criterion places, for example, technical management software such as EVM as being within scope, whereas general project management software would be out of scope. Similarly, a requirements authoring tool would be within scope, whereas a word processing application would not be.
Principle 3.
Consistent with the nature of systems engineering, the tool taxonomy should be predominantly agnostic to application domains and solution technologies. However, provision should be made for domain-specific tool categories – both application domain and technology domain, at a low level of granularity. This principle would place within scope, for example, regulatory compliance software for medical device development.
Principle 4.
Tool categories should be oriented towards tool functionality (capability of the tool), not necessarily the application of the tool. The reasoning behind this principle was that many tool functionalities can be used for a multitude of purposes having different degrees of likelihood, making classification of tools on this later basis problematic.
October 2021
[Contents]
23
