On the Viability of Diagrams and Drawings as System Requirements

Abstract

Requirement expression media is an overlooked consideration in requirements innovation. The path to including media other than natural language requirement sentences begins with determining the viability of media to be used as requirement expressions in systems engineering. This research uses the INCOSE characteristics for individual requirements and sets of requirements as a basis for an assessment of the sufficiency of model diagrams and engineering drawings to express requirements. A critical review of high-impact sources is used to develop characteristic lists for natural language requirement sentences and for model diagrams and engineering drawings. A comparative analysis of the characteristic lists for requirement sentences, model diagrams, and engineering drawings shows that each have the same fundamental characteristics and the differences are based on the ability of the media to represent abstraction. The contribution of this research is the establishment of model diagrams and engineering drawings as viable alternatives to natural language sentences for system engineering requirements expressions.

1. Introduction

Systems engineering currently relies almost exclusively on natural language in sentence structures to contractually convey the needs and wants of stakeholders to those who would design and develop a solution to meet those needs and wants. Requirements efforts, namely low quality requirements and requirements engineering, are the first potential mistakes of an engineering project whose effects manifest themselves later in the engineering effort as increased costs and schedule overruns [1,2,3,4]. Requirement expressions are historically overlooked when considering innovation in systems engineering [5]. Many of the efforts to improve systems engineering and requirements engineering have omitted changing requirement media and focused exclusively on how to improve the textual expression of requirements:

• Consider that Johnson and Day described several model types to establish a Discipline of Systems Engineering, but stopped short of offering said models as requirement expressions [5,6].
• Bruel et al. adjudicated a number of media as they relate to formalism and systems engineering, but focused on the application of formalism to address precision regarding validation instead of offering those media as requirement expression media for systems engineering [7].
• Natural language requirement specification ambiguity has been addressed with patterns in the work of Tjong et al. [8] and improved structure in that of Carson [9]; however, neither suggest changing the medium itself.

Otherwise, media available to capture requirements are often dismissed with no rigor as shown in the INCOSE Guide for Writing Requirements, which acknowledges the shortcomings of natural language but arbitrarily claims it to be the “only universal means of expression that covers the huge variety of concepts needed” [10]. This research challenges the media constraint within current systems engineering requirement practices based on a media agnostic definition of requirements which defines requirement expressions as “a means to capture an instance of a want or need of:

• A requesting external stakeholder that serves as the contractually obligated origin of a problem that a project agrees to solve.
• A requesting intra-project authority stakeholder that represents an iteration towards a solution to which the receiving intra-project group is accountable” [11].

This media agnostic definition creates a foundation to reimagine the media through which requirements are expressed within systems engineering.

This research starts the conversation on alternate media opportunities for systems engineering requirement expressions by comparing the characteristics of natural language sentences, model diagrams, and engineering drawings as systems engineering requirement expressions. This comparison reveals the differences that would need to be potentially overcome to consider using diagrams and drawings to capture requirements in systems engineering. Previous research has explored the representation of natural language requirements as models. For a system modeled in accordance with Wymore’s methodology [11], it has been shown that the system requirements can be represented as SysML diagrams, although that work did not specifically address stakeholder requirements [12]. In software engineering, research has explored the automated transformation of textual requirements into object-oriented models, which may in turn be expressed in object-oriented modeling languages such as the Unified Modeling Language (UML) [13]. The research described in this paper goes beyond previous research in that: (1) it collects fundamental characteristics for requirement expressions for natural language sentences, model diagrams, and engineering drawings; (2) it compares these characteristic lists to identify differences; and (3) it proposes characteristics that apply to any potential media used to capture requirements. These results provide a basis for the use of different media to capture requirements within systems engineering.

Requirements are a form of information. The concept of requirements, requirement expressions, and sets of requirements expressions exist in multiple engineering disciplines [5]. This research uses the term requirement for the abstract need or want [14]. The definition for requirement expression is adapted from the work of Ryan and Wheatcraft, who claim “a requirement statement is the result of a formal transformation of one or more needs into an agreed-to obligation for an entity to perform some function or possess some quality (within specified constraints)” [15]. Ryan and Wheatcraft use the term requirement statement, which carries the connotation of sentences, whereas this research uses the term requirement expression to allow for multiple media options, such as model diagrams and engineering drawings, since those media meet the definition criteria. Requirements can then be expressed as requirement sentences, model diagrams, engineering drawings, and other media as illustrated in Figure 1. The media considered in this paper are requirement sentences, model diagrams, and engineering drawings, and do not represent all potential media available for requirement expressions.

This paper is organized as follows:

• Section 2: describes the research methodology including the sources used in the implementation of the methodology and validation of the methodology;
• Section 3: illustrates instances of the methodology as implemented for both diagrams and engineering drawings and presents the outcomes of the analysis in tabular form;
• Section 4: analyzes and interprets differences in the requirement expression characteristic analysis results between requirement sentences, diagrams, and engineering drawings;
• Section 5: summarizes the key findings of the research, including limitations, and identifies areas for further research.

2. Materials and Methods

To gain broader insight into requirement expression characteristics, multiple engineering disciplines were explored in this research. In addition to systems engineering, this research expands the scope to include software engineering, mechanical engineering and electrical engineering. These engineering disciplines were selected based on the availability and accessibility of the standards and their use of requirements media distinct from requirements sentences [5]. These scoped disciplines also scope the media for requirement sentences (systems engineering), model diagrams (software engineering), and engineering drawings (mechanical and electrical engineering). The scope of this research serves as a starting position for theoretical foundations and its findings can be generalized to show how the characteristics or requirement expressions relate across various engineering disciplines.

2.1. Approach

The approach for this research has two phases. The first phase is a critical review of high-impact sources to identify characteristics of requirement media from the scoped engineering disciplines [7,16]. The critical review uses the INCOSE characteristics as themes to identify passages that address similar themes in respect to the scoped media. The critical review also sought passages that addressed characteristics that may not be aligned with the INCOSE characteristics. By using the INCOSE characteristics, this research applied a minimum characteristic set for the viability of a medium; therefore, the absence of additional characteristics does not negatively affect this research premise.

The second phase is a comparative analysis of the identified characteristics across the scoped media to determine the similarities and differences. A characteristic list is developed for each media based on the evidence of the critical review. Each media characteristic list is then compared to enable discussion and conclusions. This methodology supports the goal of this research to determine the viability of model diagrams and engineering drawings as viable for system requirements.

2.2. Validation

This research bases its validity on two primary qualitative research principles: authenticity of data and comparison objectivity [17]. Poor data generate poor results and an improper comparison provides no insight between the objects of comparison. The quality and authenticity of the data is addressed using reputable sources. Objectivity is maintained by making a proper comparison [17,18].

Two items must be addressed to ensure a proper comparison of the requirement expression characteristics: (1) the characteristics must be adapted to this research; and (2) the comparison approach needs to be explained. Each characteristic, for each scoped media, is subsequently elaborated in the context of this research in subsequent sections. This research bases the characteristic comparison on the brief description of the INCOSE source and the literature review findings for the scoped disciplines. The comparison does not extrapolate beyond that available information.

A proper comparison would also be between similar amounts of information. In systems engineering, a system is represented as a set of requirement sentences, whereas in the other scoped disciplines, a system is represented with a model set or an engineering drawing set. From the perspective of model-based systems engineering (MBSE), model diagrams and engineering drawings, including digital CAD, are views or perspectives of the overall model of a system. “There is no such thing as non-model based engineering” [19] since specifications are just verbal models, according to von Bertalanffy [20]. If specifications are considered verbal models, then collections of requirement sentences from a specification would be equivalent to a model diagram or an engineering drawing. From the other perspective, a single model diagram or engineering drawing may need multiple requirement sentences when represented in natural language. This transformation continues into individual wants and needs being represented with a single requirement sentence in systems engineering or a component within a model diagram or an engineering drawing. These assertions have been aligned in

Table 1. Alignment of subject of representation to scoped major media categories.

Subject of Representation	Natural Language Sentences	Models	Drawings
System	Specification	System Model	System Drawing Set
Sub-system	Subsystem Specification	Subsystem Model	Subsystem Drawing Set
System Behavior or Function	Requirement Sentence Collection	Model Diagram	System Drawing
Individual Need or Want	Requirement Sentence	Diagram Component	Drawing Component

for natural language sentences, models, and drawings. This alignment of information representation supports the effort of a proper comparison by ensuring that a similar amount of information is being considered.

2.3. Example

The following example of a requirement sentence and a potential model diagram are provided to illustrate the alignment of information between alternative media. The Leader Radio (LR) Performance Requirements Document (PRD) from 2019 provides a relatively straight forward requirement sentence that defines the components of an ordered, i.e., purchased, LR set. The LR PRD is a publicly released document seeking procurement of a two-channel radio system in handheld and mounted (M-LR) variants [21]. The LR PRD includes several sections that establish a capability and component hierarchy using only requirement sentences. There are no alternate media offered to complement these hierarchies, even as supplemental, i.e., non-requirement expression, material in the LR PRD. This paper developed Figure 3 as a model diagram of the requirement sentence in Figure 2. Figure 3 presents a SysML block definition diagram that depicts the composition of the LR ordered set. Even without elaborating on the particulars of SysML notation, readers can infer the equivalent information content of both the textual and diagram representations of the LR ordered set. In the interest of brevity, no engineering drawing example was developed.

3. Results

This section provides the requirement expression characteristics for the scoped disciplines and media. Each media are given their own section that provides the characteristics and their basis. A final section consolidates the findings and provides brief observations to conclude the first phase of the methodology prior to the comparative analysis.

3.1. Requirement Sentence Characteristics in Systems Engineering

Within systems engineering, there are many sources of what makes a “good” requirement expression [1,2,3,4,5] and how to avoid mistakes in requirements expression, all of which are offered for requirement sentences as the default media for expressing the requirements [6]. The Institute of Electrical and Electronics Engineers’ (IEEE) source for requirements engineering is a standard shared with ISO and IEC—ISO/IEC/IEEE 29148 [7]. A review of this high-impact source led to the recognition that the INCOSE Guide for Writing Requirements and ISO/IEC/IEEE 29148:2018 have identical characteristics for both individual requirement sentences and sets of requirement sentences [8]. While there are many sources on the subject of requirement expressions in systems engineering and requirements engineering [1,2,3,4,5,9], this research used the characteristics found in the INCOSE Guide for Writing Requirements and ISO/IEC/IEEE 29148:2018 standards since there is an established precedent for scoping research to standards [10].

The characteristics of individual requirement sentences and sets of requirement sentences are defined in both the INCOSE Guide for Writing Requirements and ISO/IEC/IEEE 29148:2018. Those lists and their definitions are captured in

Table 2. INCOSE individual requirement characteristics and definitions [8].

INCOSE Individual Requirement Characteristic	INCOSE Definition
Necessary	The requirement defines an essential capability, characteristic, constraint, or quality factor. If it is not included in the set of requirements, a deficiency in capability or characteristic will exist, which cannot be fulfilled by implementing other requirements.
Appropriate	The specific intent and amount of detail of the requirement is appropriate to the level (level of abstraction) of the entity to which it refers.
Unambiguous	The requirement is stated in such a way that it can be interpreted in only one way.
Complete	The requirement sufficiently describes the necessary capability, characteristic, constraint, or quality factor to meet the entity need without needing other information to understand the requirement.
Singular	The requirement should state a single capability, characteristic, constraint, or quality factor.
Feasible	The requirement can be realized within entity constraints (e.g., cost, schedule, technical, legal, ethical, regulatory) with acceptable risk.
Verifiable	The requirement is structured and worded such that its realization can be proven (verified) to the customer’s satisfaction at the level the requirement exists.
Correct	The requirement must be an accurate representation of the entity need from which it was transformed.
Conforming	The individual requirements should conform to an approved standard pattern and style for writing requirements.

and

Table 3. INCOSE sets of requirements characteristics and definitions [8].

INCOSE Sets of Requirements Characteristics	INCOSE Definition
Complete	The requirement set stands alone such that it sufficiently describes the necessary capabilities, characteristics, constraints, interfaces, standards, regulations, and/or quality factors to meet the entity needs without needing other information.
Consistent	The set of requirements contains individual requirements that are unique, do not conflict with or overlap with other requirements in the set, and the units and measurement systems they use are homogeneous. The language used within the set of requirements is consistent.
Feasible	The requirement set can be realized within entity constraints (e.g., cost, schedule, technical, legal, ethical, regulatory) with acceptable risk.
Comprehensible	The set of requirements must be written such that it is clear what is expected by the entity and its relation to the system of which it is a part.
Able to be validated	It must be able to be proven that the requirement set will lead to the achievement of the entity needs within the constraints (such as cost, schedule, technical, legal and regulatory compliance).

.

When utilizing natural language requirement sentences, each of the other scoped engineering disciplines used the same characteristics as systems engineering to characterize individual requirement sentences and sets of requirement sentences. Software engineering uses the same specification documentation to capture requirement sentences [11].

3.2. Example—Requirement Sentence

Recall the leader radio (LR) example introduced in Section 2.3 for illustration of the equivalence of characteristics of two alternative media for representing the LR ordered set. Figure 1 is a requirement sentence that shows some of the INCOSE characteristics. The compilation of the ordered LR Set is “Unambiguous”, “Feasible”, and “Verifiable”. Without additional context, it cannot be stated with certainty that the requirement sentence is “Necessary”, “Appropriate”, “Complete”, “Singular”, “Correct”, or “Conforming”.

3.3. Model Characteristics in Software Engineering

UML is a widely accepted standard for modeling software. This research uses the UML user guide, which is a high-impact source that defines UML and the use of UML as the primary source regarding modeling in software engineering [11]. While the INCOSE guide provided a specific list, the UML user guide provides insight into the characteristics of software models throughout its text with no specific list. The literature review did not identify a standard list of characteristics for model diagrams such as INCOSE has for system requirements. A critical review using the INCOSE characteristics as themes identified passages that addressed similar themes in respect to model diagrams. The critical review also looked for passages that addressed software model characteristics but may not be aligned with the INCOSE characteristics. No such passages were identified. By using the INCOSE characteristics, this research applied a minimum characteristic set for the viability of a medium; therefore, the absence of additional characteristics does not negatively affect this research premise.

These themes are captured and compared in

Table 4. UML user guide model characteristics compared to INCOSE [11].

INCOSE Individual Requirement Characteristic	UML User Guide Model Characteristic	Relevant Cited Passage or Rationale
Necessary	Necessary	Modeling Tip: “Show only relationships that are necessary to understand a particular grouping of things.”
Appropriate	Appropriate	First Principle of Modeling: “The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped.”
Unambiguous	Unambiguous	Passage from Overview of UML: UML is for specifying which “means building models that are precise, unambiguous, and complete” Modeling Tip: “Avoid lines that cross.”
Complete	Complete	Passage from Overview of UML: UML is for specifying which “means building models that are precise, unambiguous, and complete”
Singular	(Nearly) Independent	Fourth Principle (passage from follow on description paragraph): “‘Nearly independent’ means having models that can be built and studied separately but that are still interrelated.”
Feasible	Realistic	Third Principle of Modeling: “The best models are connected to reality.”
Verifiable	(blank)	(blank)
Correct	Precise	Passage from Overview of UML: UML is for specifying which “means building models that are precise, unambiguous, and complete”
Conforming	Self-Consistent	Passage from Rules of the UML: “A well-formed model is one that is semantically self-consistent and in harmony with all its related models”

and

Table 5. UML user guide model set characteristics compared to INCOSE [11].

INCOSE Sets of Requirements Characteristic	UML User Guide Model Set Characteristic	Relevant Cited Passage or Rationale
Complete	Sufficient	Fourth Principle of Modeling: “No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models.”
Consistent	Harmonious	Passage from Rules of the UML: “A well-formed model is one that is semantically self-consistent and in harmony with all its related models”
Feasible	Realistic	Third Principle of Modeling: “The best models are connected to reality.”
Comprehensible	(blank)	(blank)
Able to be validated	(blank)	(blank)

along with relevant passages to support the model characteristic. To illustrate an example, consider the sixth row in Table 4 which cites the third principle of modeling offered in the UML user guide, “the best models are connected to reality”, a passage that directly cites the media and names a characteristic. The theme of realism is analogous to the INCOSE characteristic “feasible”. This process was repeated while reviewing the UML user guide for characteristics. The applicable text name of the characteristics is drawn directly from the cited text to maintain the integrity of the source for the upcoming comparison.

This literature review did not identify model characteristics to match the requirement characteristics of “Verifiable”, “Comprehensible”, and “Able to be Validated”. These differences in the model diagram characteristics and the requirement sentence characteristics are addressed in the comparative analysis in a subsequent section.

The UML guide cites the use of multiple models within software engineering [11], which differs from MBSE, which utilizes a single model with model diagrams serving as perspectives of the single model [12]. While this is a semantic difference, the UML guide’s references to models align with the MBSE concept of model diagrams; therefore, this information is applicable to the media.

3.4. Example—Model Diagram

Returning to the LR example introduced in Section 2.3, Figure 2 is a notional model diagram of the requirement sentence in Figure 1. Figure 2 is a SysML block definition diagram that shows the composition of the LR ordered set. SysML is an extension of UML [13]. Using the UML user guide characteristics, Figure 2 is “Unambiguous” and “Realistic”. As stated in Section 3.3, the UML guide did not identify a model characteristic to match the requirement characteristic of “Verifiable”. The remaining characteristics must be assumed without additional context, which is a similar assessment to that in Figure 1.

3.5. Drawing Characteristics in Electrical and Mechanical Engineering

Research into engineering drawing characteristics for electrical and mechanical engineering revealed that a logical representation was defined by the American National Standards Institute (ANSI)/IEEE 991—Logic Circuit Diagrams [13] and physical representations were defined by the American Society of Mechanical Engineers (ASME) Y14.100—Engineering Drawing Practices [14] and ASME Y14.24—Types and Applications of Engineering Drawings [15]. ASME Y14.100 is a high-impact document that has been adopted by the Department of Defense since 1997 (per MIL-STD-100G [16], MIL-DTL-31000 [17], and MIL-STD 31000 [18]). This research also used ANSI Y14.15—interconnecting diagrams [19]—which is included for historical purposes as this source was used from its inception in 1966 through to its latest reaffirmation in 1988 until it was withdrawn in 1997 [20].

ASME Y14.100 “establishes the essential requirements and reference documents applicable to the preparation and revision of engineering drawings”; however, most of the “requirements” it refers to are attributes of the drawings such as title and revision history. These are not the requirements applicable to this research. The primary benefit of ASME Y14.100 for this research is its further referred documents for more specific details on aspects of engineering drawings which include ASME Y14.24, IEEE 991, and, until 1997, ANSI Y14.15. The relationship between these documents shows that electrical and mechanical engineering adhere to the same characteristics despite the differences in the nature of the media, i.e., the inherent properties of the media.

It should be noted that ASME Y14.100 states that these characteristics of drawings are applicable to both digital data and drawings. ASME Y14.24 describes the use of tables to capture requirements such as common characteristics that are stated once while the differences are tabulated, and each item is attributed a part or identifying number (PIN). ASME Y14.24 also allows for the combination of drawing types provided the requirements are met for each. Very similarly to the model quality characteristics, the literature showed themes consistent with the INCOSE Guide for Writing Requirements, which are listed and compared in

Table 6. Engineering drawing characteristics compared to INCOSE [13,14,15].

INCOSE Individual Requirement Characteristic	Engineering Drawing Characteristic	Relevant Cited Passage or Rationale
Necessary	Necessary	IEEE 991: Diagrams should include necessary functional symbols to convey conceptual principles of a circuit; Diagrams show the necessary information for development of a circuit or system
Appropriate	Scale	ASME Y14.100: Drawings should be drawn to a scale that depicts all the details of the item clearly and accurately ASME Y14.24: Scale should be applied to attain sufficient accuracy and completeness for its intended use
Unambiguous	Clear	ASME Y14.100: Drawings should be drawn to a scale that depicts all the details of the item clearly and accurately. IEEE 991: Lines should be legible without breaks; Signal names should be concise, informative, and unambiguous. ANSI 14.15a: The term “clear” is used in multiple contexts throughout the standard and is emphasized for any decisions
Complete	Complete	ASME Y14.24: Scale should be applied to attain sufficient accuracy and completeness for its intended use
Singular	Singular	ASME Y14.100: Duplicate drawings are not acceptable unless replacing an original drawing. IEEE 911: A diagram should be prepared for each distinct unit, or assembly of units, intended to fulfill a defined purpose
Feasible	(blank)	(blank)
Verifiable	(blank)	(blank)
Correct	Accuracy	ASME Y14.100: Drawings should be drawn to a scale that depicts all the details of the item clearly and accurately ASME Y14.24: Scale should be applied to attain sufficient accuracy and completeness for its intended use
Conforming	Consistent	ASME Y14.100, ASME Y14.24, IEEE 991, ANSI 14.15a: The lines, views, lettering, dimensions, tolerances, symbols, markings, and numbering of engineering drawings need to conform to standards.

and

Table 7. Engineering drawing set characteristics compared to INCOSE [13,14,15].

INCOSE Sets of Requirements Characteristic	Engineering Drawing Set Characteristic	Relevant Cited Passage or Rationale
Complete	Complete	ASME Y14.24: Drawings should be layered based on detail. For instance, a Layout Diagram can lead to the creation of multiple Detailed Drawings that provide additional detail for a particular item. The drawings are complete when the detail is enough for development
Consistent	Consistent	ASME Y14.100, ASME Y14.24, IEEE 991, ANSI 14.15a: The lines, views, lettering, dimensions, tolerances, symbols, markings, and numbering of engineering drawings need to conform to standards.
Feasible	(blank)	(blank)
Comprehensible	Correlated	ASME Y14.100, ASME Y14.24, IEEE 991, ANSI 14.15a: Drawings should be labeled to correlate families of drawings together for a given system.
Able to be validated	(blank)	(blank)

. For example, row one in Table 6 shows the IEEE 991 claim that diagrams show necessary information which directly states the same characteristic as INCOSE. The second row of Table 6 relates the engineering drawing characteristic of scale to the INCOSE appropriate characteristic as they are both used to ensure the representation of the requirement is sufficient and complete for its intended use. The second row of Table 7 shows that ASME Y14.24 describes how a complete set of engineering drawings is compiled to ensure that development or production can occur.

This research did not identify engineering drawing characteristics to match the requirement characteristics of “Verifiable”, “Feasible”, and “Able to be validated”. These differences in the drawing characteristics and the requirement sentence characteristics are addressed in the subsequent section.

3.6. Observations on Requirement Expression Characteristics

The characteristics identified by this research for the scoped disciplines and media are consolidated for both individual characteristics (

Table 8. Consolidated individual requirement expression characteristics.

INCOSE Individual Requirement Characteristic [8]	UML User Guide Model Characteristic [11]	Individual Engineering Drawing Characteristic [13,14,15,19]
Necessary	Necessary	Necessary
Appropriate	Appropriate	Scale
Unambiguous	Unambiguous	Clear
Complete	Complete	Complete
Singular	(Nearly) Independent	Singular
Feasible	Realistic	(blank)
Verifiable	(blank)	(blank)
Correct	Precise	Accuracy
Conforming	Self-Consistent	Consistent

) and set characteristics (

Table 9. Consolidated set of requirement expression characteristics.

INCOSE Sets of Requirements Characteristic [8]	UML User Guide Model Set Characteristic [11]	Engineering Drawing Set Characteristic [13,14,15,19]
Complete	Sufficient	Complete
Consistent	Harmonious	Consistent
Feasible	Realistic	(blank)
Comprehensible	(blank)	Correlated
Able to be Validated	(blank)	(blank)

). The gathering, alignment, and comparison of characteristics of requirement sentences, model diagrams, and engineering drawings revealed a similarity among the scoped disciplines for what constitutes proper use of each of their respective media. Many of the characteristics used the same vocabulary to either state or describe the characteristic as necessary, complete, and singular. These concepts applied to both individual requirement expressions and sets of requirement expressions. The differences in the lists and alignments are the focus of the comparative analysis section which follows.

4. Discussion

This section addresses the comparative analysis phase of the methodology. The first phase identified similar characteristics between the scoped disciplines and their media. These similarities indicate that the scoped disciplines have similar intentions for their respective requirement expression media. The differences in the characteristic lists were omissions:

• Model diagrams did not have an individual characteristic align with the INCOSE “Verifiable”;
• Model diagrams did not have a set characteristic align with the INCOSE “Comprehensible” or “Able to be validated”;
• Engineering drawings did not have an individual characteristic align with the INCOSE “Feasible” or “Verifiable”;
• Engineering drawings did not have a set characteristic align with the INCOSE “Feasible” or “Able to be validated”.

The INCOSE characteristics that were omitted are similar for individual requirement expressions and requirement sets; therefore, they are addressed simultaneously based on the alignment in

Table 10. Characteristic alignment for individual requirements and requirement sets.

Individual Requirement Characteristic	INCOSE Guide for Writing Requirements Description [8]	Corresponding Requirement Set Characteristic	INCOSE Guide for Writing Requirements Description [8]
Unambiguous	The requirement is stated in such a way that it can be interpreted in only one way.	Comprehensible	The set of requirements must be written such that it is clear what is expected by the entity and its relation to the system of which it is a part.
Feasible	The requirement can be realized within entity constraints (e.g., cost, schedule, technical, legal, ethical, regulatory) with acceptable risk.	Feasible	The requirement set can be realized within entity constraints (e.g., cost, schedule, technical, legal, ethical, regulatory) with acceptable risk.
Verifiable	The requirement is structured and worded such that its realization can be proven (verified) to the customer’s satisfaction at the level the requirement exists.	Able to be validated	It must be able to be proven the requirement set will lead to the achievement of the entity needs within the constraints (such as cost, schedule, technical, legal and regulatory compliance).

. This table defines each characteristic for subsequent comparison.

4.1. Unambiguous and Comprehensible

Ambiguity continues to be a struggle in requirements engineering [8,22,23]. Ambiguity is directly related to semantics and pragmatics which, along with context, guide the reader to the interpretation intended by the requirement developer, which is the toolmaker’s paradigm [24]. These topics are researched in cognitive sciences; however, the applicability to systems engineering is that accountability is improved when ambiguity is reduced as it ensures that both parties understand what is expected from one another.

Different media inherently possess differing capabilities for providing context or, alternatively, reducing ambiguity. Sentences, when unburdened with arbitrary constraints, carry the most flexibility to communicate requirements anywhere on the spectrum of abstraction, from the conceptual to empirical [24]. This is consistent with the INCOSE Guide for Writing Requirements which acknowledges that sentences are the most flexible and the most easily understood media [8] and that flexibility covers a wide range of context; however, this research contends that the flexibility is created by a lack of inherent context in the media, i.e., a sentence provides no inherent context and is therefore more flexible. Conversely, model diagrams, to include formal logic, provide spatial context and relationships between their components which allow engineers and problem solvers to better understand what is being conveyed [11,22]. Since more context is preferable in communication [24] and visual context reduces cognitive load [25], higher-context-offering media are potentially preferable in communication. This implies that model diagrams are potentially preferable in communication to requirement sentences in that model diagrams are less ambiguous based on the level of context needed or wanted to be conveyed.

The model diagram literature omitted a set characteristic related to “Comprehensible”. Because each model diagram can represent multiple requirement sentences, the individual characteristics potentially address the same amount of information as a set of requirement sentences. Therefore, it may be inferred that the “Unambiguous” characteristic for a model applies to both model diagrams and model diagram sets. Additionally, if a model set can be characterized using the characteristics of its components, then it stands that if lower-level representations are “Unambiguous”, then the collective set is “Unambiguous”. These two concepts imply that the omission of “Comprehensible” from model diagram sets is covered by the individual characteristic for “Unambiguous” model diagrams.

4.2. Feasible

For requirement sentences, feasibility is ensured via the restraint of the requirement developer [3,26]. Engineering drawings do not carry a characteristic to match “Feasible” for individual or sets of drawings (Table 8). Many of the engineering drawing types depict components ready for manufacture and are therefore bound to physical laws, which inherently provides feasibility [27]. The level of abstraction of the information dictates which media can be used to represent it. That said, being able to draw a concept speaks to its feasibility. If a component or concept can be diagrammed or drawn, the ability of the concept to be realized as part of the solution is shown to be more feasible. Therefore, based on indirect evidence, engineering drawings provide a potentially positive benefit regarding the determination of feasibility for a requirement expression.

4.3. Verifiable and Able to Be Validated

The “Verifiable” requirement sentence characteristic ensures that the requirement can be realized at the level of abstraction described [8]. For a requirement set, the “Able to be validated” characteristic ensures that the set achieves the goal of the originating stakeholder [8]. Currently, requirement developers gather verification information from appropriate stakeholders, such as the test group, to ensure that requirement sentences are verifiable [3,25]. These concepts provide accountability within the requirement sentence.

This research did not identify any matching characteristics for model diagrams or engineering drawings. Requirement sentences, because of their flexibility to capture abstractions and the ambiguity tied to natural language [24], are at risk of being unverifiable and therefore require a contingency to ensure the author accounts for verification. An example would be capability requirements that capture concepts from a concept of operations (CONOPS) document while deliberately maintaining an implementation agnostic position, as described in the INCOSE Systems Engineering Handbook [28]. Model diagrams may be verified using various strategies. Model diagrams can enable objective verification strategies including executable models [29,30,31]. Executable models can be used to capture and communicate requirement expressions among stakeholders and allow systems engineers to “forecast success in meeting the expectations of users and the acquirer, as well as to provide feedback to identify and correct performance deficiencies before implementation” [32,33,34]. The concept of executing model diagrams indicates that verification and validation are important to the respective scoped disciplines. Verifying an engineering drawing can be a straightforward process of inspections or measurements of compliance of the component as produced to the drawing. This does not imply that all drawings are verifiable as it is possible to draw a component that cannot be realized. However, a proper drawing is complete with tolerances and the other characteristics are inherently more verifiable because of the empirical information provided [35]. Overall, there is indirect evidence to support a claim that engineering drawings are more verifiable based on their visual representations.

The omission of the characteristics does not reduce that importance; however, it would indicate less concern with the scoped media representing information that is not “Verifiable” or “Able to be validated”. The omission would also conversely imply that requirements expressed as model diagrams inherently possess less uncertainty or ambiguity regarding verification and validation.

4.4. Returning to the Example

The leader radio (LR) example introduced in Section 2.3 was assessed (Section 3.2 and Section 3.4) based on the findings of this research, which showed that there was no direct UML characterization for the “Verifiable” requirement sentence characteristic. Figure 2, the SysML model diagram, shows an “Unambiguous” and “Realistic” composition for the LR ordered set. Figure 2 is “Verifiable” based on the definition of the requirement sentence characteristic and illustrates the implication that model diagrams are inherently clearer concerning verification.

4.5. Observations on the Differences

It can be said that, fundamentally, the scoped disciplines have very similar although not identical characteristics for their requirement expression media. A set of unambiguous individual model diagrams would likely be “Comprehensible”; therefore, a specific set characteristic of “Comprehensible” could be interpreted as unnecessary. A set of feasible individual engineering drawings would likely be “Feasible”; therefore, a specific set characteristic of “Feasible” could be interpreted as unnecessary. Both model diagrams and engineering drawings have less ambiguity and uncertainty compared to natural language requirement sentences based on inherent context. Additionally, both model diagrams and engineering drawings as requirement expressions are inherently more feasible, verifiable, and able to be validated.

5. Conclusions

This paper conducted a critical review of high-impact sources to identify characteristics of requirement media from the scoped engineering disciplines of systems, electrical, and mechanical engineering. Characteristic lists were developed for engineering drawings using the INCOSE system requirement sentence characteristics as themes. Model diagrams shared a total of eight of the INCOSE characteristics for individual requirements, and engineering drawings shared a total of seven of the characteristics. These characteristic lists showed that the scoped disciplines characteristics correlate strongly to the fundamental characteristics for requirement sentences. The characteristics of requirement expressions are largely consistent across the disciplines of systems engineering, software engineering, electrical engineering, and mechanical engineering.

Neither model diagram nor engineering drawing characteristics included the “Verifiable” individual characteristic, and engineering drawing characteristics did not include the “Feasible” individual characteristic either. Neither model diagrams nor engineering drawings included the “Able to be validated” set characteristic. Model diagrams did not include the “Comprehensible” set characteristic, and engineering drawings did not include the “Feasible” set characteristic. The differences in the characteristic lists are attributable to the flexibility of natural language and the inherent context provided by model diagrams and engineering drawings. The more flexible the media are, the more characteristics are needed to ensure that the information is captured properly; therefore, additional characteristics are applied to the development of natural language requirement sentences.

Both model diagrams and engineering drawings have inherent context and therefore less ambiguity and uncertainty compared to natural language requirement sentences. Thus, model diagrams are inherently more comprehensible, verifiable, and able to be validated. Likewise, engineering drawings are inherently more feasible, verifiable, and able to be validated. This research has shown that model diagrams and engineering drawings are viable to be considered for use as requirement expressions in systems engineering based on their ability to capture information with the same characteristics typified by systems engineering.

6. Further Research

The viability of the scoped media does not provide the justification for their potential inclusion. Further research is needed to identify potential benefits that different media would provide in a system engineering context. This paper was limited to model diagrams and engineering drawings as potentially viable media for systems requirement expressions. Additionally, there is an opportunity to identify other media for inclusion. The inclusion of different media will create confusion and challenges on occasion both to potential readers and requirement developers. Hence, a media selection framework will need to be developed to choose the best media for a given requirements expression or set of requirements expressions in the requirements engineering process.