Architectural Design: Logical – SEBOK (35)

The purpose of logical architecture definition (or design) is to work out the functionality and behavior of the system while in service. The logical architecture of a system is composed of a set of related technical concepts and principles that support the logical operation of the system. It is described with views corresponding to viewpoints, and as a minimum, includes a functional architecture view, a behavioral architecture view, and a temporal architecture view.

Functional Architecture View

A functional architecture is a set of functions and their sub-functions that defines the transformations performed by the system to achieve its mission.

Function and Input-Output Flow - A function is an action that transforms inputs and generates outputs, involving data, materials, and/or energies. These inputs and outputs are the flow items exchanged between functions. The general mathematic notation of a function is y = ƒ(x,t), in which y and x are Generally speaking, there are two kinds of functions:

1.- functions that are directly deduced from functional and interface requirements. These equations express the expected services of a system necessary to meet its system requirements and

2.- functions that are derived and issued from the alternative solutions of physical architecture and are dependent upon the result of the design; additionally, they rely upon on technology choice to implement the logical architecture elements.

Functional Hierarchy/Decomposition of Functions – At the highest level of a hierarchy, it is possible to represent a system as a unique, central function (defined as the system's mission) that in many ways is similar to a "black box" ("F0" in plan A-0). In order to understand in detail, what the system does, this "head-of-hierarchy" (F0) is broken down into sub-functions (F1, F2, F3, F4) grouped to form a sub-level of the hierarchy (plan A0), and so on. Functions of the last level of a functional hierarchy can be called leaf-functions (F21, F22, F23, F24 in plan A2). Hierarchies (or breakdowns) decompose a complex or global function into a set of functions for which physical solutions are known, feasible, or possible to imagine. But a static functional hierarchy does not represent well how the flows of inputs and outputs are exchanged.

Behavioral Architecture View

A behavioral architecture is an arrangement of functions and their sub-functions as well as interfaces (inputs and outputs) that defines the execution sequencing, conditions for control or data-flow, and performance level necessary to satisfy the system requirements (ISO/IEC 26702 2007). A behavioral architecture can be described as a set of inter-related scenarios of functions and/or operational modes.

Control (Trigger) - A control flow is an element that activates a function as a condition of its execution. The state of this element, or the condition it represents, activates or deactivates the function (or elements thereof). A control flow can be a signal or an event, such as a switch being moved to the “on” position, an alarm, a trigger, a temperature variation, or the push of a key on a keyboard.

Scenario (of Functions) - A scenario is a chain of functions performed as a sequence that synchronizes the functions between them by using their control flows to achieve a global transformation of inputs into outputs. A scenario of functions expresses the dynamic of an upper level function. A behavioral architecture is developed with considering both scenarios for each level of the functional hierarchy and for each level of the system hierarchy. When representing scenarios of functions and behavioral architectures it is appropriate to use modeling techniques using diagrams, such as functional flow block diagrams (FFBD) (Oliver, Kelliher, and Keegan 1997) or activity diagrams, developed with SysML (OMG 2010).

Operational Mode - A scenario of functions can be viewed by abstracting the transformation of inputs into outputs of each function and focusing on the active or non-active state of the function and its controls. This view is called a "scenario of modes" - a chain of modes performed as a sequence of transitions between the various modes of the system. The transition from one mode to another is triggered by the arrival of a control flow (event/trigger). An action (function) can be generated within a transition between two modes following the arrival of an event or a trigger.

Behavioral Patterns

When designing scenarios or behavioral architectures, architects may opt to recognize and use known models to represent the expected transformations and behaviors. Patterns are generic basic models that may be more or less sophisticated depending on the complexity of the treatment. A pattern can be represented with different notations. Behavioral design patterns are classified into several categories, which can be seen in the following examples:

• Basic patterns or constructs linking functions - such as sequence, iteration, selection, concurrence, multiple exits, loops with an exit, and replication.

• Complex patterns - such as monitoring a treatment, exchanging a message, man machine interfaces, modes monitoring, real-time monitoring of processes, queue management, and continuous monitoring with supervision.

• Failure detection, identification, and recovery (FDIR) patterns- such as passive redundancies, active redundancies, semi-active redundancies, and treatments with reduced performance.

Temporal Architecture View

A temporal architecture is a classification of the functions of a system that are derived according to the frequency level of execution. Temporal architecture includes the definition of synchronous and asynchronous aspects of functions. The decision monitoring that occurs inside a system follows the same temporal classification because the decisions are related to the monitoring of functions.

Temporal and Decisional Hierarchy Concept – Not every function of a system is performed at the same frequency. The frequencies change depending on the time and the manner in which the functions are started and executed. One must therefore consider several classes of performance. There are synchronous functions that are executed cyclically and asynchronous functions that are executed following the occurrence of an event or trigger.

To be more specific, "real-time" systems and "command-control" systems combine cyclical operations (synchronous) and factual aspects (asynchronous). Cyclical operations consist of sharing the execution of functions according to frequencies, which depend on either the constraints of capture or dispatching the input/output and control flows. Two types of asynchronous events can be distinguished:

• Disturbances on high frequencies - Decisions that are made at either the level they occur or one level above. The goal is to deter disturbances from affecting the low frequencies so that the system continues to achieve its mission objectives. This is the way to introduce exception operations, with the typical example relating to operations concerns, breakdowns, or failures.

• Changes happening on low frequencies - Decisions pertaining to changes that are made at the upper levels. The ultimate goal is to transmit them toward bottom levels to implement the modifications. A typical example relates to operator actions, maintenance operations, etc.

System Requirements Analysis – SEBOK (34)

The purpose of the system requirements analysis process is to transform the stakeholder, user-oriented view of desired services and properties into a technical view of the product that meets the operational needs of the user. This process builds a representation of the system that will meet stakeholder requirements and that, as far as constraints permit, does not imply any specific implementation. It results in measurable system requirements that specify, from the supplier’s perspective, what performance and non-performance characteristics it must possess in order to satisfy stakeholders' requirements. (ISO/IEC 2008)

Activities of the process

Major activities and tasks during this process include

1. Analyze the stakeholder requirements to check completeness of expected services and operational scenarios (glossary), conditions, operational modes, and constraints.

2. Define the system requirements and their rationale.

3. Classify the system requirements using suggested classifications (see examples above).

4. Incorporate the derived requirements (coming from architecture and design) into the system requirements baseline.

5. Establish the upward traceability with the stakeholder needs and requirements.

6. Establish bi-directional traceability between requirements at adjacent levels of the system hierarchy.

7. Verify the quality and completeness of each system requirement and the consistency of the set of system requirements.

8. Validate the content and relevance of each system requirement against the set of stakeholder requirements.

9. Identify potential risks (or threats and hazards) that could be generated by the system requirements.

10. Synthesize, record, and manage the system requirements and potential associated risks.

11. Upon approval of the requirements, establish and control baselines along with the other system definition elements in conjunction with established configuration management practices.

Checking and Correctness of System Requirements

System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics which can be used to check system requirements, such as standard peer review techniques and comparison of each requirement against the set of requirements characteristics listed in Table 2 and Table 3 of the "Presentation and Quality of Requirements" section (above). Requirements can be further validated using the requirements elicitation and rationale capture described in section "Methods and Modeling Techniques" (below).

Requirements Elicitation and Prototyping

Requirements elicitation requires user involvement and can be effective in gaining stakeholder involvement and buy-in. Quality Function Deployment (QFD) and prototyping are two common techniques that can be applied and are defined in this section. In addition, interviews, focus groups, and Delphi techniques are often applied to elicit requirements.

QFD is a powerful technique to elicit requirements and compare design characteristics against user needs (Hauser and Clausing 1988). The inputs to the QFD application are user needs and operational concepts, so it is essential that the users participate. Users from across the life cycle should be included so that all aspects of user needs are accounted for and prioritized.

Early prototyping can help the users and developers interactively identify functional and operational requirements and user interface constraints. This enables realistic user interaction, discovery, and feedback, as well as some sensitivity analysis. This improves the users' understanding of the requirements and increases the probability of satisfying their actual needs.

Capturing Requirements Rationale

One powerful and cost-effective technique to translate stakeholder requirements to system requirements is to capture the rationale for each requirement. Requirements rationale is merely a statement as to why the requirement exists, any assumptions made, the results of related design studies, or any other related supporting information. This supports further requirements analysis and decomposition. The rationale can be captured directly in a requirements database. (Hull, Jackson, and Dick 2010).

Presentation and Quality of Requirements

Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about syntax of requirements statements, wording (exclusions, representation of concepts, etc.), characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to (INCOSE 2010, Section 4.2.2.2) and (ISO/IEC 2011).

There are several characteristics of both requirements and sets of requirements that are used to aid the development of the requirements and to verify the implementation of requirements into the solution.

Characteristics of Individual Requirements. (SEBoK Original)

Necessary: The requirement defines an essential capability, characteristic, constant, and/or quality factor. If it is removed or deleted, a deficiency will exist which cannot be fulfilled by other capabilities of the product or process.

Implementation Free: The requirement, while addressing what is necessary and sufficient in the system, avoids placing unnecessary constraints on the architectural design. The objective is to be implementation-independent. The requirement states what is required, not how the requirement should be met.

Unambiguous: The requirement is stated in such a way so that it can be interpreted in only one way. The requirement is stated simply and is easy to understand.

Consistent: The requirement is free of conflicts with other requirements.

Complete: The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the stakeholders' needs.

Singular: The requirement statement includes only one requirement with no use of conjunctions. Feasible: The requirement is technically achievable and fits within system constraints (e.g., cost, schedule, technical, lethal, regulatory).

Traceable: The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or other source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specification or other system definition artifacts. That is, all parent-child relationships for the requirement are identified in tracing such that the requirement traces to its source and implementation.

Verifiable: The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.

Characteristics of a Set of Requirements. (SEBoK Original)

Complete The set of requirements needs no further amplification because it contains everything pertinent to the definition of the system or system element being specified. In addition, the set contains no to be defined (TBD), to be specified (TBS), or to be resolved (TBR) clauses. Resolution of the TBx designations may be iterative and there is an acceptable time frame for TBx items, determined by risks and dependencies.

Consistent: The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicate. The same term is used for the same item in all requirements.

Affordable: The complete set of requirements can be satisfied by a solution that is obtainable/feasible within life cycle constraints (e.g. cost, schedule, technical, legal, regulatory).

Bounded: The set of requirements maintains the identified scope for the intended solution without increasing beyond what is needed to satisfy user needs.

System Requirement

Statement that expresses an expected characteristic or a constraint using a semantic code (such as natural language, mathematical, arithmetic, geometrical expression). A system requirement is feasible, objective, and verifiable.

Rationale Argument that provides the justification for the selection of an engineering element.

Scenario A set of actions/functions representing the dynamic of exchanges between the functions allowing the system to achieve a mission or a service.

Risk An event having a probability of occurrence and gravity degree on its consequence onto the system mission or on other characteristics (used for technical risk in engineering). A risk is the combination of vulnerability and of a danger or a threat.

System Requirements – SEBOK (33)

System requirements are all of the requirements at the “system level” that have been properly translated from the list of stakeholders' requirements. System requirements form the basis of system architecture and design, verification, validation, and stakeholder acceptance. System requirements play major roles in the engineering activities

• as the essential inputs of the system architecture and design activities;

• as reference for the system validation activities; and

• as a communication means, between the various technical staff that interact within the project.

Definition and Purpose of Requirements

A requirement is a statement that identifies a product or process operational, functional, or design characteristic or constraint which is unambiguous, testable or measurable and necessary for product or process acceptability. (ISO/IEC 2007)

To avoid confusion in the multitude of terms around requirements, consider the following classifications:

• Process role or state: The role the requirement plays in the definition process; for instance, its position in the system block: translated, derived, satisfied; or its state of agreement: proposed, approved, cancelled.

• Level of abstraction: The level within the definition process for the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.

• Type of requirement: The nature of the requirement itself; for instance functional, performance, constraint, etc.

Requirements Management

Requirements management is performed to ensure alignment of the system and system element requirements with other representations, analysis, and artifacts of the system. It includes ensuring an understanding of the requirements, obtaining commitment, managing changes, maintaining bi-directional traceability among the requirements and with the rest of the system definition, and alignment with project resources and schedule.

There are many tools available to provide a supporting infrastructure for requirements management; the best choice is the one that matches the processes of the project or enterprise. Requirements management is also closely tied to configuration management for baseline management and control. When the requirements have been defined, documented, and approved, they need to be put under baseline management and control. The baseline allows the project to analyze and understand the impact (technical, cost, and schedule) of ongoing proposed changes.

Assessment Types for a System Requirement. (SEBoK Original)

Direct Assignment The system requirement from the higher level is directly assigned to a system or a system element for a lower level (for example, the color used to paint visible parts of the product).

Indirect Assignment (Simply Decomposed) The system requirement is distributed across several systems or system elements, and the sum or a more complex calculation for distribution is equal to the requirement of higher level (for example, a mass requirement, power distribution, reliability allocation, etc.) with sufficient margin or tolerance. A documented and configuration-managed "assignment budget" for each assignment must be maintained.

Indirect Assignment (Modeled and Decomposed) The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique, and the resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, a radar detection requirement may be analyzed; lower-level parameters for output power, beam size, frequencies, etc. will then be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.

Derived Requirement (from Design) Such system requirements are developed during the design activities as a result of the decision of the design team, not the stakeholder community. These requirements may include the use of commercial-off-the-shelf (COTS) items, existing systems or system elements in inventory, common components, and similar design decisions in order to produce a "best value" solution for the customer. As such, these derived requirements may not directly trace to a stakeholder requirement, but they do not conflict with a stakeholder requirement or a constraint.

Classification of System Requirements

Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods used.

Functional Requirements Describe qualitatively the system functions or tasks to be performed in operation.

Performance Requirements Define quantitatively the extent, or how well, and under what conditions a function or task is to be performed (e.g. rates, velocities). These are quantitative requirements of system performance and are verifiable individually. Note that there may be more than one performance requirement associated with a single function, functional requirement, or task.

Usability Requirements Define quality in use such as measurable effectiveness, efficiency, and satisfaction criteria.

Interface Requirements Define how the system is required to interact or to exchange material, energy, or information with external systems (external interface), or how system elements within the system, including human elements, interact with each other (internal interface). Interface requirements include physical connections (physical interfaces) with external systems or internal system elements supporting interactions or exchanges.

Operational Requirements Define operational conditions or properties under which the system is required to operate or exist. This type of requirement includes human factors and ergonomics, availability, maintainability, reliability, security.

Modes and/or States Requirements Define the various operational modes of the system in use and events conducting to transitions of modes.

Adaptability Requirements Define potential extension, growth, or scalability during the lift of the system.

Physical Constraints Define constraints on weight, volume, and dimension applicable on system elements that compose the system.

Design Constraints Define the limits on the options open to a designer of a solution by imposing immovable boundaries and limits (e.g., the system shall incorporate a legacy or provided system element, or certain data shall be maintained in an online repository).

Environmental Conditions Define the environmental conditions to be encountered by the system in its different operational modes. Should be addressed the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environment (e.g. motion, shock, noise, electromagnetism, thermal, etc.), threats societal environment (e.g. legal, political, economic, social, business, etc.).

Logistical Requirements Define the logistical conditions needed by the continuous utilization of the system. These requirements include sustainment (provision of facilities, level support, support personnel, spare parts, training, technical documentation, etc.), packaging, handling, shipping, transportation.

Policies and Regulations Define relevant and applicable organizational policies or regulatory requirements that could affect the operation or performance of the system (e.g. labor policies, reports to regulatory agony, health or safety criteria, etc.).

Cost and Schedule Constraints Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.