In this tutorial, the system-of-interest is an Electric Flashlight System. The system architecture will be designed using a Systems Engineering process and a Model-Based Systems Engineering method implemented with the System Modeling Language (SysML) and Catia Magic Systems of Systems Architect as a modelling software.

Table of Content

References

Systems Architecting Glossary

SYSTEM: Combination of interacting system elements organized to satisfy one or more system requirements. [adapted fromISO/IEC/IEEE 15288:2015, ISO/IEC/IEEE 12207:2017, ISO 24748-7000:2022]

Note 1 to entry: The system elements can include people, hardware, software, facilities, policies, processes and documents.
Note 2 to entry: In practice, the interpretation of meaning is frequently clarified by the use of an associative noun, e.g., autoinjector system.
Note 3 to entry: A system is comprised of multiple system elements.

SYSTEM ELEMENT (syn. subsystem): A combination of interacting elements that constitute a system and are organised to satisfy a set of system element requirements. [adapted from ISO/IEC/IEEE 15288]

Note 1 to entry: A system element is a system in its own right.
Note 2 to entry: A system element contributes to the realisation of higher-level system or system element requirements to which the system element belongs but is not satisfied on its own.

SYSTEM-OF-INTEREST: System whose life cycle is under consideration. [adapted from ISO/IEC/IEEE 15288:2015, ISO/IEC/IEEE 12207:2017, ISO 24748-7000:2022]

LIFE CYCLE: Series of all distinguishable life cycle phases that a system goes through from conceptualization until it ceases to exist. [adapted from ISO 14971:2019, ISO 42020:2019, and ISO 15288:2015]

LIFE CYCLE PHASE: Period of time in the life cycle of a system during which activities are performed that enable achievement of objectives for that phase [ISO 42020:2019].

Note 1 to entry: There is often a distinct set of stakeholders, external systems, and external interfaces associated with each life cycle stage.
Note 2 to entry: Not addressing a life cycle phase could result in omitting stakeholder and user needs.
Note 3 to entry: A life cycle phase can often be further decomposed.

STAKEHOLDER: Individual or organization having a right, share, claim or interest in a system-of-interest [adapted from ISO 15288!2015, ISO 42010:2019]

Note 1 to entry: An individual or organization with a personal stake in the SOI, may be affected by the SOI, participate in the development of the SOI, or able to influence the SOI.
Note 2 to entry: Stakeholders are both internal and external to the developing organization.
Note 3 to entry: A stakeholder can directly interact with the SOI or indirectly influence the SOI.
Note 4 to entry: Stakeholders are the primary source of needs.
Note 5 to entry: A stakeholder is the direct beneficiary of the system or other interested party who affects or is affected by the system, providing overarching constraints within which the customers’ needs should be achieved.
Note 6 to entry: It may not be practical to collaborate with every member of the group to elicit their needs. In this case, a means must be implemented to name a representative of the group concerning their needs.

EXTERNAL SYSTEM: A system outside the system-of-interest but directly interacts with or indirectly influences it.

EXTERNAL ENTITY: A stakeholder or external system.

SYSTEM CONTEXT: System Context is the set of surrounding stakeholders, external systems, and external interfaces [adapted from ISO 42010:2019]

Note 1 to entry: The system context is sometimes called the system environment, but the environment is often limited to environmental properties such as ambient temperature, humidity rate, pressure, etc.
Note 2 to entry: The system context includes external entities that can have various influences upon the system-of-interest, such as developmental, technological, business, operational, organisational, political, economic, legal, regulatory, ecological and social influences, as well as external physical effects such as electromagnetic radiation, charged particles, gravitational effects, or electric and magnetic fields.
Note 3 to entry: A label attached as a qualifier to the term context identifies a particular context, such as development, testing, or operational.
Note 4 to entry: The context of use, which is the intended operational context for a system, is not unique, as there can be several operational contexts .
Note 5 to entry: Life cycle phases are the primary sources of system contexts.

EXTERNAL INTERFACE: A conceptual shared boundary between the system-of-interest and an external entity. [adapted from ISO/IEC/IEEE 24748-7000:2022]

NEED: An agreed-to expectation for a system to perform a system function or satisfy a design constraint imposed on the system.

Note 1 to entry: A need may not specify the minimum and maximum capabilities.
Note 2 to entry: External systems and stakeholders are the sources of needs.

SYSTEM FUNCTION: An effect – intended by a stakeholder – of the interaction of the system with the system context.

Note 1 to entry: A system function is a unitless term that does not express a level of performance to be achieved.
Note 2 to entry: A system function is a function whose effects can be observed from outside the system.
Note 3 to entry: A system function depends on the boundary between the system-of-interest and the system context.
Note 4 to entry: A system function is a service the system provides to a stakeholder.
Note 5 to entry: Users are the primary sources of expected system functions.

OPERATIONAL SCENARIO: Description of an imagined sequence of events that includes the interaction of the system-of-interest and external entities.

DESIGN CONSTRAINT: A limitation on the design or implementation of a system or a system element externally imposed by a stakeholder or external system. [adapted from ISO 29148:2018]

Note 1 to entry: A design constraint often makes certain designs not allowed.
Note 2 to entry: A design constraint cannot be traded off.
Note 2 to entry: External systems and stakeholders who are not users are the primary sources of design constraints.
Note 3 to entry: Design constraints should constantly be challenged as they often are paraphrases of hasty design decisions or existing designs.
Note 4 to entry: Design constraints are usually flowed down as non-functional system requirements.

SYSTEM REQUIREMENT: An agreed-to expectation that a system performs a system function at a specified level of performance and under some conditions or a design constraint imposed on the system.

Note 1 to entry: A system requirement must specify the minimum and maximum capabilities to verify the design and implementation of the system-of-interest.
Note 2 to entry: There may be more than one system requirement defined for each need.
Note 3 to entry: Needs are the primary source of system requirements.

SYSTEM ELEMENT REQUIREMENT (syn. subsystem requirement): An agreed-to expectation that a system element performs a system function at a specified level of performance and under some conditions or a design constraint imposed on the system element.

Note 1 to entry: A system requirement must specify the minimum and maximum capabilities to verify the design and implementation of the system-of-interest.
Note 2 to entry: System functions and requirements are the primary sources of desired system functions.
Note 3 to entry: External systems and stakeholders (except users) are the primary sources of design constraints.

INTERNAL INTERFACE: A conceptual shared boundary between two system elements or between an external entity and a system element.

Systems Architecting Process

Systems Engineering, therefore, Systems Architecture, is an internationally standardised approach. ISO 15288 and ISO 24641 standardises Systems Engineering and Model-Based Systems Engineering processes, respectively. ISO 42010, 42020 and 42030 concentrate on the standardisation of System Architecture.

This course focuses on the 6.4.1 Mission Analysis, 6.4.2 Stakeholder Needs Definition, 6.4.3 System Requirements Definition, and 6.4.4 System Architecture Definition as defined in ISO 15288. As illustrated below, these activities are iterative and recursive.

When the application of the same process or set of processes is repeated on the same level of the system structure, the application is referred to as iterative. The iterative use of processes is important for the progressive refinement of process outputs. Iteration is not only appropriate but also expected. New information is created by the application of a process or set of processes. Typically, this information takes the form of questions (Exit questions) with respect to requirements, analysed risks, or opportunities. Iterative application of a process or set of processes should continue until such questions are resolved. Iteration between business or mission analysis, stakeholder needs and requirements definition, system requirements definition, system architecture definition, and design definition processes often occurs to help achieve a common understanding of the problem to be solved and the identification of a satisfactory solution.

The recursive use of processes, i.e. the repeated application of the same process or set of processes applied to successive levels of system elements in a system’s structure, is a key aspect of the systems engineering approach. From a view of relations between a system and its system elements, the outputs of processes applied for a system or system element are inputs to other processes or other system elements for additional analysis or more generalised synthesis of its system elements, to arrive at a more detailed or mature set of outcomes. Such an approach adds value to systems at successive levels in the system structure.

This set of activities aims to 1) understand the needs and 2) define the solution defined in ISO 24641:2023 . All activities related to the realisation of the solution are out of scope.

In addition to the activities defined in the processes, developing engineered systems using a model-based approach requires making at least four decisions that are usually under the responsibility of a Methods & Tools department:

Select or develop a Systems Engineering method (How to capture Systems Engineering concepts?),
Select or develop a Model-Based Systems Engineering language (Which modelling language to use for encoding Systems Engineering concepts?),
Select or develop a Model-Based Systems Engineering software (Which modelling software to use for implementing the modelling language?), and
Select or develop a Model-Based Systems Engineering method (How can Systems Engineering concepts be captured with the selected modelling language and software?).

The following section is a case study that exemplifies how these concepts can be implemented.

Flashlight System Development

The first systems architecting recursion will focus on the Flashlight System as the system-of-interest. We could consider four different business scenarios:

Greenfield: The company has developed Flashlight systems for many years or is new to the flashlights market and desires to start an innovative Flashlight "greenfield" (unprecedented) new product development that does not incorporate legacy system elements or partial prior design.
Brownfield: The company has developed Flashlight systems - especially Dynamo Flashlight - for many years and starts a new Flashlight "brownfield" (precedented) new product development incorporating legacy system elements or at least partial prior design.
Business-to-Customer (B2C): The Flashlight will be distributed to personal customers (e.g., Decathlon).
Business-to-Business (B2B): The Flashlight will be distributed as a subsystem to a system integrator (e.g., Petzl to be integrated into a helmet).

For each scenario, the input data at the beginning of the project would be relatively different. This case study concentrates on the Greenfield B2C scenario, that is, a "greenfield/blank page" unprecedented new product development that will be distributed to personal customers.

New Project

Open the MBSE software Catia Magic Systems of Systems Architect. Connect to the server with IP: 195.83.78.42 and Port: 1101. Create a new "SysML Project" named "Flashlight System".

Model Organisation

Populating your model will lead to the creation of thousands of modelling elements that must be logically organised within Packages. There is no unique organisation, but there should be some logic behind yours. Create a set of Packages as follows:

Stakeholder Needs Definition

The first set of activities of the proposed Systems Architecting process consists in defining the problem space. The system requirements bound the problem space. Remember that the problem space can be seen as a conceptual N-dimension vectorial space where each vector N is a requirement.

Marketing Needs

As previously discussed, the input data and the scope of the project will vary depending on the business scenario. For instance, if it is a brownfield new product development, the system requirements definition will incorporate legacy system elements or at least partial prior design. In this case study, the system-of-interest could be a Dynamo Flashlight System with an external interface "Mechanical rotational power" between the user and the system, meaning that the choice of a dynamo as a solution is already made. In this tutorial, design inputs correspond to a greenfield, blank page new product development project without such prior design decisions.

In a Business-to-Customer (B2C) project, the marketing department is key in collecting stakeholder - especially targeted end-user - needs. A need is something wanted or desired by one or more internal or external stakeholders. Stakeholder needs often focus on the external customer's needs—the targeted end-user in this case study. Needs are usually expressed in user-oriented, unquantified language, neither solution-neutral nor atomic. In a word, a need does not satisfy the characteristics of an individual requirement.

Let's start with the set of needs for a Flashlight System collected by the marketing department using benchmarking and qualitative data collection techniques, such as online surveys, questionnaires, interviews, focus groups, etc.

As an R&D engineer, such ill-defined input data doesn't help you get started. Even if you may reuse data (needs, requirements, architecture design, test cases, etc.) from past projects in a brownfield development, I advise you to do so by going through all the activities of the systems engineering process, starting with the needs definition activity.

There is no single recipe for needs definition, but to get a complete and correct set of requirements, a good practice is to identify all potential requirements sources, that is, the stakeholders and external systems. To increase confidence in the completeness of stakeholders or external systems, one can systematically define the system contexts for each system life cycle phase.

Define System Life Cycle

Below is a definition of the Flashlight System life cycle using a SysML State Machine diagram (STM). SysML States, which are graphically represented by boxes, encode life cycle phases. SysML Transitions between states are graphically represented by arrows and are used to encode the temporal sequence of life cycle phases. The Initial node, represented by a black circle, encodes the beginning of the system life cycle. The Final State node, represented by a black circle within a white circle, symbolises the end of the Flashlight System life cycle. Move all life cycle phases in a package.

For the rest of this tutorial, we will concentrate on the life cycle "Use" phase, but the same Systems Engineering activities must be performed for every context of each life cycle phase.

Create a cartography of views that enable any stakeholder to REFINE

ADD PCK DIAGRAM

Define System Contexts

The next activity consists in the definition of the Flashlight System contexts, including:

The identification of the external entities (stakeholders and external systems) that directly interact with the Flashlight System or indirectly influence it, and
The environmental conditions within which the Flashlight System will operate.

The Flashlight System can be part of one or multiple contexts in each life cycle phase. For instance, the life cycle phase "Use" can be refined by multiple contexts:

Search for an object in the dark.
Hiking in altitude by night
Help a baby fall asleep.

Each context may involve different external entities and environmental conditions, and each external entity may expect different system functions or impose design constraints according to the context of use.

A SysML Use Case Diagram (UC) is a graphical representation of a context of use (or use case). I personally do not see any value in using such a diagram to develop system requirements. Modelling has a cost that encourages me to adopt a lean engineering approach. However, it is not forbidden to use it as long as you find any value and can argue why.

The graphical representation of a context - of use or any other life cycle phase (manufacturing, transportation, maintenance, recycling, etc.) - is a SysML Block Definition Diagram (BDD). SysML Blocks encode the context (<Hiking in altitude by night> use contexts), the system-of-interest (Flashlight), external entities (User, External object, Source of ingress, Backpack) and environmental conditions (Use environment). SysML Directed Composition relationships are used to represent the composition of a context. Move all context blocs, external entity blocs and environmental conditions blocs in the corresponding packages.

0..* is the multiplicity. The multiplicity is the definition of a cardinality - i.e., number of elements - of some collection of elements (e.g., External object) by providing a lower bound (possibly infinite) and an upper bound (possibly infinite too) that serve to provide an inclusive interval of non-negative integers to specify the allowable number of instances of described element.

Multiplicity	Option	Cardinality
0..0	0	Collection must be empty
0..1		No instances or one instance
1..1	1	Exactly one instance
0..*	*	Zero or more instances
1..*		At least one instance
5..5	5	Exactly 5 instances
m..n		At least m but no more than n instances

After creating a BDD to define a system context, you can create a hyperlink by dragging and dropping the context diagram on the life cycle phase "Use" modelled with a SysML State of the SysML State Machine Diagram. A BDD symbol will be attached to the state of the machine diagram.

Note that you can create only one hyperlink between two objects.

Trace Life Cycle Phases VS. External Entities

Change management requires to perform <What-if?> impact analyses. Dependency matrices capture the relationship between two model elements (e.g., System Function VS. System Requirement; System Requirement VS. Subsystems; etc.). For example, trace the dependencies between the Life Cycle Phases and the External Entities to capture whether an external entity is involved or not in a life cycle phase.

Create a new Dependency Matrix with the following criteria as definition for the row and column elements. In this example, drag and drop a State element corresponding to to specify the Row Element Type. Catia Magic will recognise the type (here a Block) of the selected element (here an External entity). The Row Scope is the Package that contains all elements corresponding to the external entities.

To trace model elements, select the SysML Trace relationship as Dependency Criteria.

Both tables below define and illustrate the different types of relationships in SysML V1.6. Traceability - using dependency matrices or concept maps - must be performed after each activity of the Systems Engineering process.

Define System Functions

The definition of system functions is a two-step process starting with the definition of the EFFECT-FUNCTIONS before defining the TRANSFORMATION-FUNCTIONS of the Flashlight System.

An EFFECT-FUNCTION is a function – intended by a stakeholder – of the interaction of the system with the system context.

Ports: Elements of components enabling exchange with other components.

Flows:

Signal flow: Items exchange numeric information.
- Input ports accept only incoming flows.
- Output ports provide only outgoing flows.
- Bidirectional ports accept incoming flows and provide outgoing flows (for physical interactions, see the Physical Interaction).

Physical interaction: Items exchange various kinds of physical substances in terms of their conserved characteristics, such as electric charge, momentum, and entropy.

Flow rate: The amount of substance per time moving in or out ports, such as current (electric charge per time), force and torque (linear and angular momentum per time), and entropy flow rate (entropy per time).
Potential of flow: An impetus for substances to move in or out of ports, such as voltage for electric charge, linear and angular velocity for momentum, and temperature for entropy.

Domain	Effort (e) or Potential to flow	Flow (f) or Flow rate	What is flowing
power	effort e	flow f	power
mechanical (translation)	force F [N]	velocity v [m/s]	linear momentum
mechanical (rotation)	torque T [Nm]	angular velocity omega [rad/s]	angular momentum
pneumatic	pressure p [Pa]	volume flow (rate) phi [m3/s]	volume
thermal	temperature T [K]	entropy flow dS [J/Ks]	entropy
electric	voltage u [V]	current i [A]	charge
hydraulic	pressure p [Pa]	volume flow (rate) phi [m3/s]	volume
magnetic	current i [A]	voltage u [V]	charge

The example below illustrates the modelling of signal flows and physical interactions.

The EFFECT-FUNCTIONS "To light" and "To inform on autonomy level" are modelled with a SysML Part Property and the external interfaces corresponding to signal flows or physical interactions with SysML Flow Ports.

Complete the definition of both functions with the input flows that the Flashlight System must transform into light intensity when used in its operating environment. Interactions between the Source of ingress, Use environment and Source of impact are SysML Connectors with SysML Item Flows.

How could this transformation function differ in a brownfield (precedented) new product development incorporating legacy system elements or at least partial prior design?

Ensure all your model elements are logically organised within your set of Packages.

Define Design Constraints

Looking at the context definition, we remark that the external system "Backpack" does not contribute to the "To light" function. We could add a new function "To attach the flashlight (to the backpack)", but we will add a set of design constraints. A design constraint is a limitation on the design or implementation of a system or a system element externally imposed by a stakeholder or external system. A design constraint often makes certain designs not allowed and cannot be traded off. When a design constraint is specified during the definition of the design problem (i.e., the specification of requirements), you should always challenge it because it is often a paraphrase of a hasty design decision or existing design.

Create a new SysML Bloc Definition Diagram to define the interactions between the Flashlight System and the external entities that impose design constraints.

Create a new SysML Requirement Table and add a new SysML Design Constraint to define the maximum size of the flashlight that can fit in a backpack's pocket. Add a new design constraint (if the external entity imposing the design constraint is missing, add it in the BDD and IBD).

Create a new custom attribute by selecting Columns > New Custom Column. Rename it as Source and search for the SysML Trace relationship and rename it.

Add the external entity "Backpack" as the source of the design constraint.

Create a SysML Dependency Matrix to trace Design Constraints VS. External Entities. You should obtain the following matrix.

The same sequence of activities should be performed for each system life cycle phase.

System Requirements Definition

System Requirements Development

Create a SysML Requirement Diagram for each predefined system function (SysML Block) and create the system requirements (SysML Requirement) derived from the function. Add a SysML Refine relationship between the function and the derived requirements.

Create the Flashlight System Specification using a SysML Requirement Table with custom attributes.

All attributes should be filled with adequate values.

System Requirements Validation

The validation of system requirements is an activity to make sure that the system specification is complete and correct. As a means of system requirements validation, you can ask for peer reviews of the system specification:

A peer deskcheck, in which you ask one colleague to look over the specification.
A passaround, in which you invite several colleagues to examine the specification concurrently.
A walkthrough, during which the author describes the specification and solicits comments on it.

When conducting peer reviews, to avoid overwhelming the review team, you should perform incremental reviews throughout requirements development:

Identify high-risk areas that need a careful look through inspection, and use informal reviews for less risky sections.
Ask particular reviewers to start at different locations in the specification document to make certain that fresh eyes have looked at every page.
Judge whether you really need to inspect the entire specification, examine a representative sample and the number and types of errors you find will help you determine whether investing in a full inspection is likely to pay off.

Make sure that the quality criteria listed below for requirements expressed using natural language are satisfied.

	ISO 29148:2018	INCOSE Guide to Writing Requirements, May 2022
Superlatives	(such as 'best', 'most');
subjective language	(such as 'user friendly', 'easy to use', 'cost effective');
open-ended, non-verifiable terms	(such as 'provide support', 'but not limited to', 'as a minimum');
comparative phrases	(such as 'better than', 'higher quality');
loopholes	(such as 'if possible', 'as appropriate', 'as applicable');

/ACCURACY/SENTENCESTRUCTURE		The structure of needs and requirements statements must be in the form of a complete sentence, the simplest form of which is:
/ACCURACY/USEACTIVEVOICE		Use the active voice in the main sentence structure of the need or requirement statement with the responsible entity clearly identified as the subject of the sentence.
/ACCURACY/SUBJECTVERB		Ensure the subject and verb of the need or requirement statement are appropriate to the entity to which the need or requirement refers.
/ACCURACY/USEDEFINEDTERMS		Define terms.
/ACCURACY/USEDEFINITEARTICLES		Use definite article “the” rather than the indefinite article “a.”
/ACCURACY/UNITS		Use appropriate units when stating quantities.
ambiguous terms /ACCURACY/AVOIDVAGUETERMS	adverbs and adjectives (such as 'almost always', 'significant', 'minimal') and ambiguous logical statements (such as ‘or’, 'and', ‘and/or’);	Avoid the use of vague terms. - vague quantification, such as “some”, “any”, “allowable”, “several”, “many”, “a lot of”, “a few”, “almost always”, “very nearly”, “nearly”, “about”, “close to”, “almost”, and “approximate”. - vague adjectives such as “ancillary”, "relevant”, “routine”, “common”, “generic”, “significant”, “flexible”, “expandable”, “typical”, “sufficient”, “adequate”, “appropriate”, “efficient”, “effective”, “proficient”, “reasonable” and “customary.” - vague adverbs, such as “usually”, “approximately”, “sufficiently”, and “typically”.
/ACCURACY/NOESCAPECLAUSES		Avoid escape clauses such as “so far as is possible”, “as little as possible”, “where possible”, “as much as possible”, “if it should prove necessary”, “if necessary”, “to the extent necessary”, “as appropriate”, “as required”, “to the extent practical”, and “if practicable.”
/ACCURACY/NOOPENENDED		Avoid open-ended clauses such as “including but not limited to”, “etc.” and “and so on.”
/CONCISION/SUPERFLUOUSINFINITIVES		Avoid superflous infinitive such as "be able to ...” “be designed to be capable of ...”, "be capable of...".
/CONCISION/SEPARATECLAUSES		Use a separate clause for each condition or qualification.
/NONAMBIGUITY/CORRECTGRAMMAR		Use correct grammar.
/NONAMBIGUITY/CORRECTSPELLING		Use correct spelling.
/NONAMBIGUITY/CORRECTPUNCTUATION		Use correct punctuation.
/NONAMBIGUITY/LOGICALCONDITION		Use a defined convention to express logical expressions such as “[X AND Y]”, “[X OR Y]”, [X XOR Y]”, “NOT [X OR Y]”.
/NONAMBIGUITY/AVOIDNOT		Avoid the use of “not.” that implies “not ever”, which is impossible to verify in a finite time.
/NONAMBIGUITY/OBLIQUE		Avoid the use of the oblique ("/") symbol that has so many possible meanings that it should be avoided.
/SINGULARITY/SINGLESENTENCE		Write a single sentence that contains a single thought conditioned and qualified by relevant subclauses.
/SINGULARITY/AVOIDCOMBINATORS		Avoid combinators, such as “and”, “or”, “then”, “unless”, “but”, “as well as” “but also”, “however”, “whether”, “meanwhile”, “whereas”, “on the other hand”, or “otherwise.”
/SINGULARITY/AVOIDPURPOSE		Avoid phrases such as “……to”, “in order to”, “so that”, and “thus allowing. that indicate the purpose of or reason for the need or requirement statement.
/SINGULARITY/AVOIDPARENTHESES		Avoid parentheses and brackets containing subordinate text.
/SINGULARITY/ENUMERATION		Enumerate sets explicitly instead of using a group noun to name the set.
SINGULARITY/CONTEXT		When a need or requirement is related to complex behavior, refer to the supporting diagram or model.
/COMPLETENESS/AVOIDPRONOUNS	(such as 'it', 'this', 'that');	Avoid the use of pronouns and indefinite pronouns such as “all”, “another”, “any”, “anybody”, “anything”, “both”, “each”, “either”, “every”, “everybody”, “everyone”, “everything”, “few”, “many”, “most”, “much”, “neither”, “no one”, “nobody”, “none”, “one”, “several”, “some”, “somebody”, “someone”, “something”, and “such.”
/COMPLETENESS/USEOFHEADINGS		Avoid relying on headings to support explanation or understanding of the requirement.
terms that imply totality /REALISM/AVOIDABSOLUTES	(such as ‘all’, ‘always’, ‘never’, and ‘every’);	Avoid using unachievable absolutes, such as “100% availability”, “all”, “every”, “always”, and “never”
/CONDITIONS/EXPLICIT		State applicability conditions explicitly instead of leaving applicability to be inferred from the context.
/CONDITIONS/EXPLICITLISTS		Express the propositional nature of a condition explicitly for a single action instead of giving lists of actions for a specific condition as it may not be clear whether all the conditions must hold (a conjunction) or any one of them (a disjunction) for the action to take place.
/UNIQUENESS/CLASSIFY		Classify requirements according to the aspects of the problem or system it addresses.
/UNIQUENESS/EXPRESSONCE		Express each requirement once and only once.
/ABSTRACTION/SOLUTIONFREE		When defining design inputs avoid stating a solution unless there is rationale for constraining the design.
/QUANTIFIERS/UNIVERSALS		Use “each” instead of “all”, “any”, or “both” when universal quantification is intended.
/TOLERANCE/VALUERANGE		Define quantities with a range of values appropriate to the entity to which the apply and to which the entity will be verified or validated against.
/QUANTIFICATION/MEASURABLE		Provide specific measurable performance targets appropriate to the entity to which the need or requirement is stated and against which the entity will be verified to meet. Avoid unmeasured quantification, such as “prompt”, ”fast”, ”routine”, ”maximum”, ”minimum”, ”optimum”, ”nominal”, ”easy to use”, ”close quickly”, ”high speed”, ”medium-sized”, ”best practices”, and ”user-friendly.”
/QUANTIFICATION/TEMPORALINDEFINITE		Define temporal dependencies explicitly instead of using ambiguous and unverifiable indefinite temporal keywords, such as “eventually”, “until”, “before”, “after”, “as”, “once”, “earliest”, “latest”, “instantaneous”, “simultaneous”, and “at last”
/UNIFORMLANGUAGE/USECONSISTENTTERMS		Use each term and units of measure consistently throughout requirement sets.
/UNIFORMLANGUAGE/DEFINEACRONYMS		The same acronym must be used in each requirement; various versions of the acronym are not acceptable.
/UNIFORMLANGUAGE/AVOIDABBREVIATIONS		The use of abbreviations adds ambiguity and is to be avoided unless the context is clear and the abbreviation is clearly defined in the project glossary or acronym list.
/UNIFORMLANGUAGE/STYLEGUIDE		Use a project-wide style guide for individual need and requirement statements.
/MODULARITY/RELATEDREQUIREMENTS		Group related needs and requirements together.
/MODULARITY/STRUCTURED		Conform to a defined structure or template for organizing sets of needs and requirements.

In addition to using the checklists of quality criteria for an individual and a set of requirements, it is necessary to ensure that all system requirements are derived from system functions (e.g., an empty row). Also, ensure there is no system function for which there is no derived requirement (e.g., an empty column).

To increase your level of confidence in the completeness and correctness of the set of system requirements using traceability relationships, create a SysML Relation Map Life Cycle Phases -> External Entities -> System Functions and Design Constraints -> System Requirements.

System Architecture Definition

The definition of a system architecture usually requires two views: a tree and a graph. The tree corresponds to the definition of the decomposition of the system into subystems. The graph corresponds to the usage of subsystems by instantiating the system and subsystems and defining the internal interfaces. How would you define the system decomposition and internal interfaces?

System Decomposition

...

Internal Interfaces

...

Subsytems Requirements Definition

At the beginning of this document, the Systems Engineering process was defined as recursive. How would you perform similar activities at the subsystem level?

Subsystems Contexts Definition

...

Subsystems Function Definition

...

Subsystems Requirements Definition

...