35.2 Commonly Applied System Design Objectives 407 Design-for-Efficiency Some systems and products require focused consideration on efficient utilization of resources. In these cases a Design-for-Efficiency objective must be established. Design-for-Effectiveness One of the key contributors to User satisfaction is a system, product, or service’s degree of effectiveness. Did the missile hit and destroy the target? Does the flight simulator improve pilot effectiveness? Establish Design-for-Effectiveness objectives where the effectiveness is the key determinate for mission success. Design-for-Reconfigurability Some systems and products are designed to accommodate a variety of missions as well as a quick turnaround between missions. Therefore, some may have to be reconfigurable within a specified time frame. Design-for-Integration, Test, and Evaluation Objective Modular system and products that undergo multiple levels of integration and test require a Design- for-Integration, Test, and Evaluation objective. Ideally, you would isolate each configuration item (CI) and test it with actual, simulated, stimulated, or emulated interfaces. If the system or product is to be integrated at various facilities, special interface considerations should be given to physical constraints and equipment, and the tools available should be investigated. Finally, EQUIPMENT-based systems and products must be designed to facilitate multi-level system verification and validation. This requires the incorporation of temporary or permanent test points and access ports for calibration and alignments among other things. Design-for-Verification Objective Once the system or product is integrated, tested, and ready to be verified, designers must consider HOW the item will be verified. Some requirements can be physically verified; other requirements may not. Establish a Design-for-Verification objective to ensure all data required for verification are accessible and can be easily measured. Design-for-Maintainability Objective Single-use, multi-use, and multi-purpose systems require some form of Design-for-Maintainability objective. This may include preventive maintenance, corrective maintenance, calibration, upgrades, and refurbishment. Key design considerations include maintenance operator access and clearances for hands, arms, tools, and equipment. Additional considerations include the availability of elec- trical power, need for batteries, or electrical generators, external air sources for aircraft while on the ground, and so on. These considerations emphasize the need for a Maintenance Concept to provide a framework for deriving Design-for-Maintainability requirements. Design-for-Disposal Objective Systems and products that employ nuclear, biological, or chemical (NBC) materials and ultimately wear out, become exhausted, damaged, or destroyed intentionally or by accident. In any case, the system or product requires a Design-for-Disposal objective. This includes mechanisms for moni- toring and removal of hazardous materials such as NBC substances or traces. For items that can Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 408 Chapter 35 System Design Objectives be reclaimed and recycled, special tools and equipment—categorized as peculiar support equip- ment (PSE)—may be required. Design-for-Security-and-Protection Objective Various systems and products require a Design-for-Security-and-Protection objective that limits SYSTEM or product access to only authorized individuals or organizations. Design considerations include layers of armor, Internet firewalls, and authorized accounts and passwords. Design-for-Safety Objective The application of SE requires strict adherence to laws, regulations, and engineering principles and practices that promote the safety of system and product stakeholders—the operators, maintainers, general public, personal property, and environment. The Design-for-Safety objective focuses on ensuring that systems, products, and services are safe to deploy, operate, maintain, and dispose of. This includes not only the physical product but also establishing training and instructional proce- dures, cautionary warnings and notices, and potential consequences for violation. Quality Function Deployment (QFD) One method for sorting out customer needs and priority values is Quality Function Deploy- ment (QFD). Where time permits, you are encouraged to consider and investigate QFD as part of your analysis. 35.3 GUIDING PRINCIPLES In summary, the preceding discussions provide the basis with which to establish the guiding prin- ciples that govern system design objectives practices. Principle 35.1 Every User has key Operations and Support (O&S) Phase objectives that a SYSTEM/entity design must satisfy; collaborate with Users to understand their needs and priori- tize them. 35.4 SUMMARY Our discussions in this chapter highlighted the need to establish system design objectives practices to ensure that User operational needs are met. These objectives form the basis for developing Mission Needs Statements (MNSs), Statements of Objectives (SOOs), Operational Requirements Document (ORD), System Requirements Documents (SRDs), and System Performance Specifications (SPS). GENERAL EXERCISES 1. Answer each of the What You Should Learn from This Chapter questions identified in the Introduction. 2. Refer to the list of systems identified in Chapter 2. Based on a selection from the preceding chapter’s General Exercises or a new system selection, apply your knowledge derived from this chapter’s topical discussions. A User has employed your services to recommend the driving design “to/for” objectives for the selected system or product. (a) What are the top three or five objectives you would recommend? (b) How would you prioritize each objective? Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com References 409 (c) Prepare a statement for a formal Request for Proposal (RFP) that expresses each objective and its relative priority. ORGANIZATIONAL CENTRIC EXERCISES 1. Contact a contract program in your organization. (a) What are the User’s objectives for the system, product, or service? (b) How were the objectives expressed? RFP? Contract? (c) What are the objectives? (d) How is the program implementing the objectives? (e) What lessons has the program learned from this exercise? REFERENCES IEEE Std 610.12-1990. 1990. IEEE Standard Glossary of Software Engineering Terminology. Institute of Electrical and Electronic Engineers (IEEE). New York, NY. Defense Systems Management College (DSMC) Ft. Belvoir. VA. 2001. Glossary: Defense Acquisition Acronyms and Terms, 10th ed. Defense Acquisition University Press. MIL-STD-882D. 2000. Standard Practice for System Safety. Washington, DC: Department of Defense (DoD). Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com Chapter 36 System Architecture Development 36.1 INTRODUCTION All human-made and living systems, by definition, are composed of interacting elements. Each element has its own unique identity, capabilities, and characteristics, integrated into a purposeful framework specifically arranged to accomplish a function or mission. The integrated, multi-level framework of elements and combinations of elements represent the SYSTEM’s architectural con- figuration or simply architecture. This chapter explores the development of system architectures. As discussed in Part I on System Analysis Concepts, the system architecture is an aggregate abstraction consisting of four classes of architectures: 1) a requirements architecture, 2) an operations architecture, 3) a behav- ioral architecture, and 4) a physical architecture. Our discussions in this chapter establish the foundation for developing a system architecture. Since the fundamental concepts of the architectural frameworks were covered in Part I on System Architecture Concepts, this chapter focuses attention on physical configuration unique topics. Topics include centralized, decentralized, and distributed processing; fault tolerant architectural design; environmental, safety, and health (ES&H) considerations, fire detection and suppression; and security and protection. What You Should Learn from This Chapter 1. What is a system architecture? 2. What are the key attributes of an architecture? 3. What are the primary architectural views of a system? 4. Define the semantics of architectures. 5. What is centralized control processing architecture? 6. What is decentralized control processing architecture? 7. What is distributed processing architecture? 8. What is a fault tolerant architectural design? 9. What are some architectural power system considerations? 10. What are some architectural environmental, safety, and health (ES&H) considerations? 11. What are some fire detection and suppression architectural configuration considerations? 12. What are some security and protection architectural considerations? System Analysis, Design, and Development, by Charles S. Wasson Copyright © 2006 by John Wiley & Sons, Inc. 410 Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 36.2 What Is an Architecture? 411 Definitions of Key Terms • Architect (System) The person, team, or organization responsible for innovating and cre- ating a system configuration that provides the best solution to User expectations and a set of requirements within technical, cost, schedule, technology, and support constraints. • Architecting “The activities of defining, documenting, maintaining, improving, and certifying proper implementation of an architecture.” (Source: IEEE Std. 1471-2000, para. 3.3, p. 3) • Architectural Description (AD) “A collection of products to document an architecture.” (Source: IEEE Std. 1471-2000, para. 3.4, p. 3) • Architecture A graphical model or representation, such as an interpretative artistic render- ing, a technical drawing, or a sketch, of a specific view of a system that communicates the form, fit, or function of a SYSTEM, its operational elements, and interfaces as envisioned by its developer. • Centralized Architecture An architecture that “uses a central location for the execution of the transformation and control functions of a system.” (Source: Buede 2000, p. 231) • Concerns “Those interests which pertain to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability.” (Source: IEEE Std. 1471-2000, para. 4.1, p. 4) • Decentralized Architecture An architecture characterized by “multiple, specific locations at which the same or similar transformational or control functions are performed.” (Source: Buede, 2000, p. 231) • Open System Architecture “A logical, physical structure implemented via well defined, widely used, publicly-maintained, non-proprietary specifications for interfaces, services, and supporting formats to accomplish system functionality, thereby enabling the use of properly engineered components across a wide range of systems with minimal changes.” (Source: Former MIL-STD-499, Appendix A, Glossary, p. 37) • Open Systems Environment (OSE) “A comprehensive set of interfaces, services and sup- porting formats, plus aspects of interoperability of application, as specified by information technology standards and profiles. An OSE enables information systems to be developed, operated and maintained independent of application specific technical solutions or vendor products.” (Source: Adapted from DSMC, Glossary: Defense Acquisition Acronyms and Terms) • View “A representation of a whole system from the perspective of a related set of concerns.” (Source: IEEE Std. 1471-2000, para. 3.9, p. 3) • Viewpoint “A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audi- ence for a view and the techniques for its creation and analysis.” (Source: IEEE Std. 1471- 2000, para. 3.10, p. 3) 36.2 WHAT IS AN ARCHITECTURE? IEEE Std. 1471-2000 (para. 3.5, p. 3) defines an architecture as “The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.” Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 412 Chapter 36 System Architecture Development Through our educational systems, most people associate architecture with beautiful classical buildings with ornamented façades that are tracable back to the Greek and Roman antiquity. What is missing from the educational paradigm is a universal definition that encompasses building architec- tures, systems, products, and services. Using the IEEE definition as a backdrop, if you analyze the educational paradigm of architecture, you soon discover that architecture represents the totality of three elements common to systems, products, and services. These elements are form, fit, and function. An architecture exposes key features of a system, product, or service and expressively com- municates via interpretative artistic renderings or graphics HOW those features interrelate within the overall framework and its OPERATING ENVIRONMENT. Note the term “exposes.” However, just because an architectural element or object is visually exposed DOES NOT infer frequency of usage. System, product, or service architectures depict the summation of a system’s entities and capa- bilities levels of abstration that support all phases of deployment, operations, and support. Some entities may be an integral part of a system’s phases of operation 100% of the time; other entities may be only used 1% of the time. Depending on the mission or system application, the system, product, or service architecture can be abstracted to expose only those capabilities unique to the mission. System Architects In most professional domains, the system architect is expected to possess licensed credentials, preferably by some form of certification accorded by a state of residency. Part of this process is to demonstrate to decision authorities that the system architect has the experience, knowledge, and understanding of artistic, mathematical, and scientific principles to translate a User’s vision into a system, product, or service within the constraints of performance standards, laws, and regulations established by society. As in the case of the educational architecture paradigm above, there is a paradigm for system architects. Whereas most people think of architects as being individuals, teams and organizations may be referred to as architects. Formulating the System Architecture System architecting requires years of experience in application-dependent knowledge and technol- ogy. Due to the diversity of systems, product, and services, there are no specific ways to formulate an architecture. There are guidelines that, in combination with experience, enable us to formulate system, product, or service architectures. In recent years the Institute of Electrical and Electronic Engineers (IEEE) issued IEEE Standard-1471-2000, IEEE Recommended Practice for Architectural Description of Software- Intensive Systems. IEEE-Std-1471-2000 established as a conceptual framework for developing architectural descriptions of software intensive systems. IEEE 1471-2000 (para. 1.1, p. 1) defines software intensive systems as those “. . . where software contributes essential influences to the design, construction, deployment, and evolution of the system as a whole.” Although IEEE 1471 is a software standard, the conceptual framework presented is equally applicable to all types of systems—electrical, electronic, mechanical, optical, and so forth. Figure 36.1 illustrates the standard’s framework. IEEE 1471 provides a key construct that exposes several key terms that serve as the frame- work for formulating a system, product, or service architecture. Specifically the terms are: archi- tectural description, viewpoints, views, and concerns. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 36.2 What Is an Architecture? 413 • Architectural Description “An architectural description selects one or more viewpoints for use. The selection of viewpoints typically will be based on consideration of the stake- holders to whom the AD is addressed and their concerns.” (Source: IEEE Std. 1471-2000, para. 4.1, p. 4) • Viewpoint “A viewpoint establishes the conventions by which a view is created, depicted and analyzed. In this way, a view conforms to a viewpoint. The viewpoint determines the languages (including notations, model, or product types) to be used to describe the view, and any associated modeling methods or analysis techniques to be applied to these representa- tions of the view. These languages and techniques are used to yield results relevant to the concerns addressed by the viewpoint.” (Source: IEEE Std. 1471-2000, para. 4.1, p. 4) • View “A view may consist of one or more architectural models. Each such architectural model is developed using the methods established by its associated architectural viewpoint. An architectural model may participate in more than one view.” (Source: IEEE Std. 1471- 2000, para. 4.1, p. 4) • Concerns “Those interests which pertain to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, security, distribution, and evolvability.” (Source: IEEE Std. 1471-2000, para. 4.1, p. 4) Attributes of an Architectural Description An Architectural Description exposes and expresses the architecture of a system, product, or service via standard attributes and conventions. These include: Mission Environment System Architecture Stakeholder Concern Viewpoint View Library Viewpoint Model Architecture Description Rationale fulfills 1 * influences inhibits has an has 1 * identifies 1 * described by 1 provides participates in is important to 1 * is addressed to 1 * participates in 1 * establishes methods for 1 * aggregates 1 * has 1 * identifies 1 * used to cover 1 * has source 0 1 conforms to selects 1 * organized by 1 * Figure 36.1 IEEE-Std-1471-2000 Architectural Description Source: IEEE-Std-1471-2000 Figure 1: “Conceptual Model of Architectural Description,” p. 5. Reprinted with permission of IEEE. Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com • Architectural Entities An architecture exposes the operational elements such as objects or actors—which can be persons, places, things, roles, or capabilities—that comprise a SYSTEM or entity, regardless of the level of abstraction, and interacts synergistically to perform the entity’s mission. • Hierarchical Level of Abstraction An architecture expresses an entity’s operational, behavioral, and physical context within the User’s system of systems (SoS) for a given level of abstraction (Level 0, Level 1, Level 2, etc.). • Unique Identity Architecture expresses HOW a SYSTEM’s object or actor capabilities are uniquely identified via reference designators. • Interactions with its OPERATING ENVIRONMENT An architecture expresses how the SYSTEM entity interacts and interoperates with external systems in its OPERATING ENVI- RONMENT based on external inputs, stimuli, or cues—for example, inputs such as event- based interrupts, raw materials, and information—as well as its SYSTEM RESPONSES—its behavioral patterns, products, by-products, or services. • Completeness An architecture expresses the integrated set of entities, capabilities, and inter- actions for a specific entity required to satisfy a prescribed set of User mission use cases and operational scenarios. This is accomplished in terms of incremental or phased capabilities evolving from: 1) an initial operational capability (IOC) through a series of “builds” to a full operational capability (FOC) or 2) a single grand design. • Architectural Views An entity’s architecture is characterized by four types of views: 1) a requirements view, 2) an operations view, 3) a behavioral view, and 4) a physical view. Now that we have established WHAT a system architecture is and its attributes, let’s explore the HOW the architectural description is represented. Architectural Description Representation Methods For most applications, system architectures are communicated via three mechanisms: 1) three- dimensional and two-dimensional artistic renderings of buildings, 2) block diagrams, and 3) hierarchy trees. Most SE applications employ block diagrams such as system block diagrams (SBDs), architecture block diagrams (ABDs), and functional block diagrams (FBDs) as the primary mechanism for communicating a SYSTEM or entity’s architecture. Block diagrams depict horizontal peer level and external relationships within a given system level of abstraction. Vertical linkages to higher level parent or lower level siblings are referenced by symbology but not shown. For example, a system entity, as a level of abstraction, may include a symbol on or next to its box to denote lower levels exist. In contrast, hierarchy trees enable us to depict vertical relationships that infer levels of abstrac- tion; they do not communicate, however, direct relationships and interactions among peers. Figure 36.2 contrats the two approaches. Architectural Description Views and Concerns When tasked to develop the architectural description, engineers naturally gravitate to debates over WHAT tools and methods to use. Traditionally, SEs prefer to use functional methods; software engi- neers focus on object-oriented methods, and so forth. Instead, the focus should be on WHAT is to be described in terms of views. Once these views are identified, then you can decide whether a viewpoint is best described using functional, object-oriented, or some other methods. The selection depends on WHAT architectural view best communicates the System Architect’s solution to the User’s vision in a manner that is accepted by the User. 414 Chapter 36 System Architecture Development Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 36.3 Architectural Views of a System 415 36.3 ARCHITECTURAL VIEWS OF A SYSTEM There are numerous engineering perspectives of a system’s architecture. In general, the perspec- tives are reflective of the views and concerns of key stakeholders of the system, product, or service as illustrated in Figure 36.3. Your job as a system analyst or SE is to integrate these views. Earlier we introduced the concept of the four solution domains: Requirements, Operations, Behavioral, and Physical. Each solution domain represents a unique view of a system representing a consensus of its stakeholders. Let’s define each view: • Requirements Architecture View A representation of the hierarchy and traceability of an entity’s specification requirements that bound its phases and modes of operation, capabili- ties, characteristics, design and construction constraints, and verification methods. • Operations Architecture View A representation of HOW the MISSION SYSTEM and SUPPORT SYSTEM operational assets are employed—meaning deployed, operated, and supported—by the User in their Level 0 HIGHER ORDER SYSTEM. The operational archi- tecture may include lower level training, maintenance, and support architectures that graph- ically represent their respective concepts. • Logical/Functional Architecture View A representation of the logical/behavioral entity relationships and interactions—meaning behavior, products, by-products, and services— that express HOW the MISSION SYSTEM capabilities are envisioned to respond to external stimuli and cues for hypothesized scenarios within its prescribed OPERATING ENVIRONMENT. • Physical Architecture View A representation of HOW an entity is physically composed, constructed, configured, and interfaced to respond to external stimuli and cues to achieve the desired outcome-based responses. 2 SYSTEM SYSTEM SUBSYSTEM A SUBSYSTEM A SUBSYSTEM B SUBSYSTEM B SUBSYSTEM C SUBSYSTEM C A1 A1 A2 A2 B1 B1 B2 B2 C1 C1 C2 C2 SUBSYSTEM A SUBSYSTEM A SUBSYSTEM B SUBSYSTEM B SUBSYSTEM C SUBSYSTEM C Block Diagram Approach (Horizontal Architecture Relationships) Hierarchy Tree Approach (Vertical Architecture Relationships) System Architecture A1 A1 A2 A2 B1 B1 B2 B2 C1 C1 C2 C2 Decomposition System SUBSYSTEM A SUBSYSTEM B SUBSYSTEM C Figure 36.2 System Architecture Presentation Methods Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com 416 Chapter 36 System Architecture Development SYSTEM or Entity Architectural Description SYSTEM or Entity Architectural Description Requirements Architecture View (Multi-Level) Requirements Architecture View (Multi-Level) Operations Architecture View (Multi-Level) Operations Architecture View (Multi-Level) Logical/ Behavioral Architecture View (Multi-Level) Logical/ Behavioral Architecture View (Multi-Level) Physical Architecture View (Multi-Level) Physical Architecture View (Multi-Level) Consists of Requirements Domain Solution Operations Domain Solution Behavioral Domain Solution Physical Domain Solution Figure 36.4 System Architectural Description (AD) Elements Figure 36.4 illustrates these relationships as elements of an overall system architecture description. The SYSTEM architecture description (AD) consists of a multi-level requirements architecture, a multi-level operations architecture, a multi-level logical/functional architecture, and a multi-level physical architecture. Architectural Responses to the Solution Space If we translate the IEEE construct shown in Figures 36.1 with the views of a system illustrated in Figure 36.4, Figure 36.5 results. Here, we see the architectural views as satisfying the solution space(s) based on stakeholders, views, and concerns. Guidepost 36.1 At this point we have established the general relationships between the four solution domain architectures with the solution space. Now let’s explore the interdependencies of these views further. System Views • Requirements • Operations • Behavioral •Physical System Views • Requirements • Operations • Behavioral •Physical User(s) User(s) Acquirer Acquirer System Engineering System Engineering Hardware Engineering Hardware Engineering Software Engineering Software Engineering Specialty Engineering Specialty Engineering System Developer(s) System Developer(s) Operator(s) Operator(s) Maintainer(s) Maintainer(s) System Administrators System Administrators Instructor(s) Instructor(s) = Inputs & Reviews = Collaboration & Consensus Where: Test Engineering Test Engineering Product Engineering Product Engineering User Community System Developer User’s Representative Figure 36.3 Stakeholder Views of a System Simpo PDF Merge and Split Unregistered Version - http://www.simpopdf.com [...]... cases and cope with use case scenarios without regard to element frequency of usage Principle 36. 5 Every system architecture must be compliant with its specification requirements and applicable laws, regulations, and cultural values Principle 36. 6 Every system architecture must factor in considerations for the environment, safety, and health 36. 10 SUMMARY The discussion of system architecture development. .. technology, cost, schedule and risk constraints Conduct a mission and operations analysis, field interviews with the User, analyze existing system trouble reports, and understand the OPERATING ENVIRONMENT and its players and threats Step 2: Capture and Bound Entity Requirements If an entity’s item development specification requirements are undefined, you need to capture, allocate, and flow down higher level... Timeline (MET) Translate mission operations into system use cases and scenarios Identify the system modes and states of operation Derive system capabilities from use cases and scenarios Develop the system Concept of Operations (ConOps) Resolve critical operational and technical issues (COIs/CTIs) and risks Verify and validate operational solution Establish and maintain the Baseline Concept Description... strategy and tailor them to suit your own business domain and systems application Step 1: Understand the problem and solution space(s) Step 2: Capture and bound entity requirements Step 3: Analyze and reconcile entity specification requirements Simpo PDF Merge and Split Unregistered Version - Development Methodology 433 37.3 Requirements Solution http://www.simpopdf.com Step 4: Step 5: Step 6: Step... to Chapter 26 Step 1: Conduct a Mission Analysis The System Architect, in collaboration with the System Engineering and Integration Team (SEIT), begins by developing a full understanding of the System Performance Specification (SPS) operational requirements During the formulation of the concept, the System Architect or LSE collaborates with various system stakeholders to fully understand and validate... development practices of this chapter serve as a precursor for the Requirements, Operations, Behavioral, and Physical Domain Solutions that follow System architectures Simpo PDF 36 System ArchitectureUnregistered Version - http://www.simpopdf.com 428 Chapter Merge and Split Development provide the means to communicate the key stakeholder concerns and engineering viewpoints required to develop each SYSTEM. .. Behavioral, and Physical Domain Solutions? 5 What is the methodology used to develop the Requirements Domain Solution? 6 What are the steps of the methodology employed to derive the Requirements Domain Solution? 7 How do you develop the Requirements Domain Solution architecture? System Analysis, Design, and Development, by Charles S Wasson Copyright © 20 06 by John Wiley & Sons, Inc 430 Simpo PDF Merge and. .. entity verification and formal acceptance Author’s Note 37.1 The usage of the term “contextual role” above refers to multi-level development For example, at the SYSTEM Level, the Acquirer and System Developer organizations establish a contractual agreement for requirements via the System Performance Specification (SPS) Within the System Developer’s program organization, the System Engineering and Integration... activities begin with HOW the system is structured for communications and decision-making Figure 36. 7 serves as a reference for our discussion Chapters 8 through 12 System Architecture Concepts discussed system interactions with its OPERATING ENVIRONMENT The discussion highlighted various types of command and control (C2) interactions that included open loop and closed loop systems For the C2 mechanism,... misapplication of the system or product 10 Physical breaks in resource or data communications interfaces or supplies 11 Lack of preventive and corrective maintenance Simpo PDF 36 System ArchitectureUnregistered Version - http://www.simpopdf.com 422 Chapter Merge and Split Development 12 Physical intrusion such as hacking, spamming, malicious mischief, and sabotage by unauthorized users and threats For systems in . configured, and interfaced to respond to external stimuli and cues to achieve the desired outcome-based responses. 2 SYSTEM SYSTEM SUBSYSTEM A SUBSYSTEM A SUBSYSTEM B SUBSYSTEM B SUBSYSTEM C SUBSYSTEM. security and protection architectural considerations? System Analysis, Design, and Development, by Charles S. Wasson Copyright © 20 06 by John Wiley & Sons, Inc. 410 Simpo PDF Merge and Split. Relationships) System Architecture A1 A1 A2 A2 B1 B1 B2 B2 C1 C1 C2 C2 Decomposition System SUBSYSTEM A SUBSYSTEM B SUBSYSTEM C Figure 36. 2 System Architecture Presentation Methods Simpo PDF Merge and Split