https://sandbox.sebokwiki.org/api.php?action=feedcontributions&user=Eleach&feedformat=atom
SEBoK - User contributions [en]
2024-03-28T13:00:41Z
User contributions
MediaWiki 1.35.13
https://sandbox.sebokwiki.org/index.php?title=Integrating_Supporting_Aspects_into_System_Models&diff=48907
Integrating Supporting Aspects into System Models
2013-11-05T18:37:10Z
<p>Eleach: </p>
<hr />
<div>This article discusses the integrated modeling of systems and supporting aspects using Model-Based Systems Engineering methodologies and frameworks. Supporting aspects of systems engineering include: <br />
*Engineering Management<br />
*Project Management<br />
*Requirements Engineering and Management<br />
*Risk Modeling, Analysis, and Management<br />
*Quality Assurance, Testing, Verification, and Validation<br />
*System Integration and Employment<br />
*Analysis of "-ilities" (e.g., Reliability, Availability, Maintainability, Safety, And Security (RAMSS), Manufacturability, Extensibility, Robustness, Resilience, Flexibility, and Evolvability)<br />
<br />
These aspects can pertain to physical facets, as well as to functional, structural, behavioral, social, and environmental facets of the core system model. The article focuses on three main aspects: <br />
<br />
# Project and Engineering Management <br />
# Risk Modeling, Analysis, and Management<br />
# Requirements Definition and Management<br />
<br />
===Background=== <br />
The model-based approach to systems engineering considers the system model as much more than a plain description of the system; the model is the central common basis for capturing, representing, and integrating the various system aspects listed above. The model is essential to the design and understanding of the system as well as to managing its life cycle and evolution. Modeling languages constitute the basis for standardized, formal descriptions of systems, just like natural languages form the basis for human communication. <br />
<br />
As systems progressively become more complex and multidisciplinary, the conceptual modeling of systems needs to evolve and will become more critical for understanding complex design (Dori 2002). In addition to facilitating communication among clients, designers, and developers, conceptual modeling languages also assist in clearly describing and documenting various domains, systems, and problems, and define requirements and constraints for the design and development phases (Wand and Weber 2002). The importance of model-based analysis is demonstrated by the variety of conceptual modeling methodologies and frameworks, although ''de facto'' standards are slow to emerge. While certain disciplines of engineering design, such as structural analysis or circuit design, have established modeling semantics and notation, the conceptual modeling of complex systems and processes has not yet converged on a unified, consolidated modeling framework (Estefan 2007). The challenge is not only to integrate multiple aspects and support the various phases of the system’s life cycle, but also to capture the multidisciplinary nature of the system, which has led to the creation of various frameworks. Nevertheless, the information systems analysis paradigm is currently the most widely used, perhaps due to the need to integrate complex systems via information-intensive applications and interactions.<br />
<br />
===Integrated Modeling of Systems and Projects=== <br />
This section discusses the integrated modeling of systems and projects and of the project-system relationship (often called Project-Product Integration). The fields of [[Project Management (glossary)]] and [[Systems Engineering (glossary)]] have been advancing hand-in-hand for the last two decades, due to the understanding that successful projects create successful systems. Many of the main systems engineering resources pay considerable attention to project management and consider it to be a critical process and enabler of systems engineering (Haskins, Forsberg, and Krueger 2007; NASA 2007; Sage and Rouse 2011). The integration of system-related aspects and concepts into project plans is more common than the integration of project-related aspects and concepts into system models. Because the project is a means to an end, it is the process that is expected to deliver the system. Indeed, project activities are often named after or in accord with the deliverables that they are aimed at facilitating (e.g., “console design”, “software development”, “hardware acquisition”, or “vehicle assembly”). Each is a function name, consisting of an object (noun), or the system to be attained, and a process (verb), being the project or part of the project aimed at attaining the end system.<br />
<br />
The specific process associated with each of these examples refers to different stages or phases of the project and to different maturity levels of the system or sub-system it applies to. Moreover, the mere inclusion of system and part names in activity names does not truly associate system model artifacts with these activities. Overall, it is not truly possible to derive the set of activities associated with a particular part or functionality of the system which that will be delivered by the project. Project-Product integration is not straightforward, as project models and system models are traditionally disparate and hardly interface. A model-based approach to project-system integration follows a system-centric paradigm and focuses on incorporating project-related aspects and concepts into the core system model, as opposed to the project-centric approach described in the previous paragraph. Such aspects and concepts include schedule, budget and resources, deliverables, work-packages, constraints and previous relations. The integrated system-project model should provide useful information on the mutual effects of project activities and system components and capabilities. Some examples of integrated system-project modeling include the following: <br />
*The set of project activities associated with a particular system component, feature, or capability.<br />
*The set of resources required for performing a task of designing or developing a particular component of the system.<br />
*The team or subcontractor responsible for delivering each system component. <br />
*The preexisting dependencies between activities of system components deployment. <br />
*The cost associated with each system component, feature, or capability. <br />
*The parts of the system negotiated for each delivery, deployment, build, release, or version. <br />
<br />
The Work Breakdown Structure (WBS) is designed to support the division of the project scope (work content) amongst the individuals and organizations participating in the project (Golany and Shtub 2001). The WBS is traditionally organization or activity-oriented; however, one of its main cornerstones focuses on the deliverable, which corresponds to the system, sub-system, component, or a capability or feature of one or more of these. A deliverable-oriented WBS, in which the high-level elements correspond to primary sub-systems, is advocated, as it is likely to allow the WBS to be more product-oriented (Rad 1999). An integrated approach to project planning and system modeling (Sharon and Dori 2009) merges the system model with the project’s WBS using Object-Process Methodology (OPM) (Dori 2002). The unified OPM model captures both the project activities and the system components and functionalities. <br />
<br />
The Design Structure Matrix (DSM) is a common method for enhancing and analyzing the design of products and systems. DSMs can be component-based, task-based, parameter-based, or team-based (Browning 2001). A DSM for an OPM-based project-product model derives a hybrid DSM of project activities and system building blocks from the unified OPM model, accounting for dependencies between project activities and system components, as well as replacing the two monolithic and separate component-based and task-based DSM views (Sharon, De-Weck, and Dori 2012). The underlying OPM model assures model consistency and traceability. The integrated project-product OPM model includes both a diagram and an equivalent auto-generated textual description. The DSM derived from this model visualizes a dependency loop comprising both system components and project activities.<br />
<br />
Another model-based approach (Demoly et al. 2010) employs System Modeling Language (SysML) in order to create various views that meet the needs of various system stakeholders, such as the project/process manager. The approach includes both product-oriented and process-oriented views.<br />
<br />
===Integrated Modeling of Systems and Requirements=== <br />
Requirements are statements that describe operational, functional, or design-related aspects of a system. Requirements definition and management is an important SE process, as it both initiates and facilitates the entire SE effort by defining the expected functions and performance of the engineered system. Several challenges associated with requirements include:<br />
*Defining the requirements in a structured, controlled manner.<br />
*Tracing these requirements to system components, aspects, and decisions.<br />
*Testing and verifying compliance of the system with these requirements. <br />
The extension of conceptual system models to include requirements has several significant benefits: <br />
# Requirements provide the rationale for the system's architecture and design by making and justifying architectural and design decisions based on specific requirements. <br />
# Modeling the internal logic and the hierarchy and dependency relations among requirements enables identification and elimination of redundant and contradictory requirements. <br />
# Responsibility for satisfying specific requirements can often be assigned to teams and persons responsible for delivering various system components. While the advantages of having good requirements engineering is clear, it is often a challenge to directly trace requirements to specific system artifacts, especially when the requirements are defined in a holistic, solution-independent manner. <br />
<br />
<br />
There are several methods to incorporate requirements into system models, including SysML Requirements Engineering and Object-Process Methodology(OPM)-based Requirements Engineering and Authoring. <br />
<br />
====SysML-Based Requirements Engineering====<br />
The SysML requirements diagram makes it possible to capture the requirements and the relations among them in a visual manner, which is more intuitive than the textual manner in which requirements are traditionally edited and managed. The diagram was added to the basic set of UML diagrams that formed the basis for SysML (Friedenthal, Moore, and Steiner 2006), and is not a native UML diagram. Tracing requirements to the system blocks and artifacts satisfying them can be captured in the SysML Block Definition Diagram, which is primarily designated to capture the relations among types of system elements and components. The < > link between the block and the requirement captures the trace.<br />
<br />
====OPM-Based Requirements Engineering==== <br />
Object-Process Methodology (OPM) is a methodology and language for conceptual modeling of complex systems and processes with a bimodal textual and graphical representation (Dori 2002). OPM’s textual representation is coordinated with the graphical representation; additionally, each visual model construct in the Object-Process Diagram (OPD) is described by a formal structured textual statement in Object-Process Language (OPL), which is a subset of natural English. OPM facilitates model-based requirements engineering, authoring, and specification, in three possible modes:<br />
<br />
# OPM can be used to generate conceptual models which initially focus on the requirements level—the problem domain, rather than the design level or the solution domain, which facilitates automated model-based requirements generation (Blekhman and Dori 2011). The requirements model is solution-neutral and it can be the basis for one or more architectural solutions for achieving the functions specified in the requirements.<br />
# Utilizing OPM in order to generate requirement-oriented OPDs in a manner similar to the SysML Requirements Diagram enables an engineer to capture the requirements specification as the skeleton for the system model. User-defined tagged structural relations, such as "is realized by" or is allocated to", provide for associating requirements with system model functions (objects and processes that transform them). This approach is similar to the SysML requirements diagram; however, instead of using a unique notation in a separate diagram type, the requirements are seamlessly incorporated into the single system model.<br />
# OPM can be used for the purpose of generating visual system models from formally specified requirements by tracing the textually authored requirements to system model inserts and artifacts (Dori et al. 2004).<br />
<br />
===Integrating Risk into System Models=== <br />
Risk is an expression and a measure of the negative or adverse impact of uncertainty. Risk exists whenever uncertainty can lead to several results, of which some may be negative (adverse) and some positive. A system faces risks from other systems or from the environment, and it can also pose risks to other systems or to the environment. Systems are characterized by such attributes, such as: goals, objectives, inputs, outputs, variables, parameters, processes, events, states, subsystems, interfaces, mechanisms, and methods. System vulnerability is the system's total potential to be harmed or negatively affected in any one of these attributes. Analogously, system harmfulness is the system's total potential to harm others or to generate negative effects, which can be manifested in one or more of these attributes (Haimes 2009). Model-based risk analysis (MBRA) enables structured analysis and risk-related process control. Several model-based risk analysis approaches are available in the literature. MBRA is presently common in the information technology and information security domains more than the systems engineering domain; however, some of the methods are generally applicable to complex systems as well. The ISO-IEC-IEEE collaborative software development and operation lifecycle standard (ISO and IEC 2004) proposes a concurrent approach to IT Risk Management. This approach consists of six main activities: <br />
*Plan and Implement Risk Management <br />
*Manage the Project Risk Profile<br />
*Perform Risk Analysis <br />
*Perform Risk Monitoring <br />
*Perform Risk Treatment <br />
*Evaluate the Risk Management Process <br />
<br />
These activities are executed concurrently, affect and provide feedback to each other, and interact with other software life cycle processes, such as the technical management and the design processes (ISO and IEC 2004). <br />
<br />
The CORAS approach (Fredriksen et al. 2002; den Braber et al. 2006; Lund, Solhaug, and Stølen 2011) is a UML-derivative for IT security risk modeling and assessment. This framework consists mostly of the UML use case (UC) diagram, extended for misuse cases. Additional notation was added to the UC notation in order to capture risk sources, effects, and results (e.g., the “bad actor” icon, moneybag for asset-in-risk). A misuse diagram can include, for example, the risk of loss of legal protection of proprietary know-how due to information theft and distribution by an unfaithful employee. The treatment for the risk source of insufficient security policy, which contributes to the above risk, is illustrated in a separate treatment diagram.<br />
<br />
A quantitative risk assessment method for component-based systems (Grunske and Joyce 2008) supports component vulnerability analysis and specification using modular attack trees. In addition, it provides attacker profiling, which enables supporting econometric approaches to risk response. The methodology utilizes SysML as its underpinning language, and especially the SysML block definition diagram and parametric diagram, in order to capture parametric relations and constraints as a means to defining risk profiles. <br />
<br />
System-Theoretic Accident Model and Processes, STAMP (Leveson 2011) is a method for system and component design for safety. STAMP reformulates the safety problem as a control problem as opposed to a reliability problem. STAMP is optimized for safety-oriented systems engineering and design and for hazard avoidance and mitigation, specifically in complex socio-technical systems. A model-based adaptation of STAMP was also proposed (Leveson 2004) and was implemented in various safety-critical and mission-critical systems, including aircraft collision avoidance systems (CAS) (Leveson 2004) and ballistic missile defense systems (Pereira, Lee, and Howard 2006). Risk-Oriented Systems Engineering (ROSE) (Mordecai and Dori 2013) is a method based on Object-Process Methodology (OPM) for integrating risk into system models. Being system-centric, ROSE is responsible for capturing risk layers and aspects on top of and in sync with the core system model, while improving and immunizing it against captured risks, as well as for generating system robustness and resilience by design in response to various risk-posing scenarios. The risk handling meta-model includes risk mitigation during the design phase and risk response during the operational phase.<br />
<br />
==References==<br />
===Works Cited===<br />
===Primary References===<br />
<br />
Dori, D. 2002. ''[[Object-Process Methodology – A Holistic Systems Paradigm]]''. New York, NY, USA: Springer-Verlag.<br />
<br />
Estefan, J. 2008. ''[[A Survey of Model-Based Systems Engineering (MBSE) Methodologies]],'' Rev. B. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TD-2007-003-02. Available at http://www.incose.org/ProductsPubs/pdf/techdata/MTTC/MBSE_Methodology_Survey_2008-0610_RevB-JAE2.pdf.<br />
<br />
Golany, Boaz, and Avraham Shtub. 2001. “Work Breakdown Structure.” In Salvendy, G. (ed.) 2001. ''[[Handbook of Industrial Engineering, Technology and Operations Management]],'' 3rd ed. Hoboken, NJ, USA: John Wiley & Sons, Inc. 1263–1280.<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.<br />
<br />
<br />
===Additional References===<br />
<br />
Blekhman, Alex, and Dov Dori. 2011. “Model-Based Requirements Authoring - Creating Explicit Specifications with OPM.” In 6th International Conference on Systems Engineering. Herzeliyya, Israel. <br />
<br />
Browning, T.R. 2001. “Applying the Design Structure Matrix to System Decomposition and Integration Problems: a Review and New Directions.” IEEE Transactions on Engineering Management 48 (3): 292–306. doi:10.1109/17.946528. http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=946528. <br />
<br />
Demoly, Frédéric, Davy Monticolo, Benoît Eynard, Louis Rivest, and Samuel Gomes. 2010. “Multiple Viewpoint Modelling Framework Enabling Integrated Product–process Design.” International Journal on Interactive Design and Manufacturing (IJIDeM) 4 (4) (October 12): 269–280. doi:10.1007/s12008-010-0107-3. http://link.springer.com/10.1007/s12008-010-0107-3. <br />
<br />
Den Braber, Folker, Gyrd Brændeland, Heidi E. I. Dahl, Iselin Engan, Ida Hogganvik, Mass S. Lund, Bjørnar Solhaug, Ketil Stølen, and Fredrik Vraalsen. 2006. The CORAS Model-based Method for Security Risk Analysis. SINTEF, Oslo. Oslo: SINTEF. <br />
<br />
Dori, Dov, Nahum Korda, Avi Soffer, and Shalom Cohen. 2004. “SMART: System Model Acquisition from Requirements Text.” Lecture Notes in Computer Science: Business Process Management 3080: 179–194. http://link.springer.com/chapter/10.1007/978-3-540-25970-1_12. <br />
<br />
Kristiansen, Ba Gran, and K Stolen. 2002. “The CORAS Framework for a Model-based Risk Management Process.” In Lecture Notes In, edited by Stuart Anderson, Massimo Felici, and SandroEditors Bologna, 2434:94–105. Springer-Verlag. doi:10.1007/3-540-45732-1_11. <br />
<br />
Friedenthal, Sanford, Alan Moore, and Rick Steiner. 2006. “OMG Systems Modeling Language ( OMG SysML ™ ) Tutorial” (July). <br />
<br />
Grunske, L, and D Joyce. 2008. “Quantitative Risk-based Security Prediction for Component-based Systems with Explicitly Modeled Attack Profiles.” Journal of Systems and Software 81 (8): 1327–1345. Haimes, YY. 2009. “On the Complex Definition of Risk: A Systems-Based Approach.” Risk Analysis 29 (12): 1647–1654. http://onlinelibrary.wiley.com/doi/10.1111/j.1539-6924.2009.01310.x/full. <br />
<br />
ISO, and IEC. 2004. “ISO/IEC 16085: Information Technology — Software Life Cycle Processes — Risk Management”. Vol. 2004.<br />
<br />
Leveson, NG. 2004. “Model-based Analysis of Socio-technical Risk.” <br />
<br />
Leveson, NG. 2011. Engineering a Safer World. MIT Press. <br />
<br />
Lund, Mass Soldal, Bjørnar Solhaug, and Ketil Stølen. 2011. Model-Driven Risk Analysis: The CORAS Approach. Berlin, Heidelberg: Springer Berlin Heidelberg. doi:10.1007/978-3-642-12323-8. <br />
http://www.springerlink.com/index/10.1007/978-3-642-12323-8. <br />
<br />
Mordecai, Yaniv, and Dov Dori. 2013. “Model-Based Risk-Oriented Robust Systems Design with Object-Process Methodology.” International Journal of Strategic Engineering Asset Management TBD (CESUN 2012 Special Issue). <br />
<br />
Pereira, SJ, Grady Lee, and Jeffrey Howard. 2006. “A System-Theoretic Hazard Analysis Methodology for a Non-advocate Safety Assessment of the Ballistic Missile Defense System”. Vol. 1606. http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA466864. <br />
<br />
Rad, Parviz F. 1999. “Advocating a Deliverable-oriented Work Breakdown Structure.” Sage, Andrew P., and William B. Rouse. 2011. Handbook of Systems Engineering and Management. Edited by Andrew P. Sage and William B. Rouse. 2nd ed. John Wiley & Sons. <br />
<br />
Sharon, Amira, Olivier L De-Weck, and Dov Dori. 2012. “Improving Project-Product Lifecycle Management with Model-Based Design Structure Matrix : A Joint Project Management and Systems Engineering Approach.” Systems Engineering: 1–14. doi:10.1002/sys. <br />
<br />
Sharon, Amira, and Dov Dori. 2009. “A Model-Based Approach for Planning Work Breakdown Structures of Complex Systems Projects.” In Proc. 14th IFAC Symposium on Information Control Problems in Manufacturing. <br />
<br />
Wand, Yair, and Ron Weber. 2002. “Research Commentary: Information Systems and Conceptual Modeling?A Research Agenda.” Information Systems Research 13 (4) (December): 363–376. doi:10.1287/isre.13.4.363.69.<br />
<br />
----<br />
<center>[[Modeling Standards|< Previous Article]] | [[Representing Systems with Models|Parent Article]] | [[Systems Approach Applied to Engineered Systems|Next Article >]]</center><br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 2]][[Category:Topic]]<br />
[[Category:Representing Systems with Models]]</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Decision_Management&diff=48898
Decision Management
2013-11-01T21:45:34Z
<p>Eleach: </p>
<hr />
<div>Many systems engineering decisions are difficult because they include numerous stakeholders, multiple competing objectives, substantial uncertainty, and significant consequences. In these cases, good decision making requires a formal decision management process. The purpose of the decision management process is:<br />
<blockquote>“…to provide a structured, analytical framework for identifying, characterizing and evaluating a set of alternatives for a decision at any point in the life-cycle and select the most beneficial course of action.” (ISO/IEC 15288:2008)</blockquote> <br />
<br />
Decision situations (opportunities) are commonly encountered throughout a system’s lifecycle. The decision management method most commonly employed by systems engineers is the trade study. Trade studies aim to define, measure, and assess shareholder and stakeholder value to facilitate the decision maker’s search for an alternative that represents the best balance of competing objectives. By providing techniques for decomposing a trade decision into logical segments and then synthesizing the parts into a coherent whole, a decision management process allows the decision maker to work within human cognitive limits without oversimplifying the problem. Furthermore, by decomposing the overall decision problem, experts can provide assessments of alternatives in their area of expertise. <br />
<br />
==Decision Management Process==<br />
The decision analysis process is depicted in Figure 1 below. The decision management process is based on several best practices, including:<br />
*Utilizing sound mathematical technique of decision analysis for trade off studies (Parnell (2009) provided a list of decision analysis concepts and techniques).<br />
*Developing one master decision model, followed by its refinement, update, and use, as it required for trade studies throughout the system life cycle.<br />
*Using Value-Focused Thinking (Keeney, 1992) to create better alternatives. <br />
*Identifying uncertainty and assessing risks for each decision.<br />
<br />
[[File:Decision_Mgt_Process_DM.png|thumb|center|650px|center|'''Figure 1. Decision Management Process (INCOSE DAWG 2013).''' Permission granted by INCOSE Decision Analysis Working Group (DAWG). All other rights are reserved by the copyright owner.]]<br />
<br />
The center of the diagram shows the five trade space objectives. The ten blue arrows represent the decision management process activities and the white text within the green ring represents SE process elements. Interactions are represented by the small, dotted green or blue arrows. The decision analysis process is an iterative process. <br />
A hypothetical UAV decision problem is used to illustrate each of the activities in the following sections. <br />
<br />
===Framing and Tailoring the Decision===<br />
To ensure the decision team fully understands the decision context, the analyst should describe the system baseline, boundaries and interfaces. The decision context includes: the system definition, the life cycle stage, decision milestones, a list of decision makers and stakeholders, and available resources. The best practice is to identify a decision problem statement that defines the decision in terms of the system life cycle.<br />
<br />
===Developing Objectives and Measures===<br />
Defining how an important decision will be made is difficult. As Keeney puts it:<br />
<blockquote>Most important decisions involve multiple objectives, and usually with multiple-objective decisions, you can't have it all. You will have to accept less achievement in terms of some objectives in order to achieve more on other objectives. But how much less would you accept to achieve how much more? (Keeney 2002)</blockquote><br />
The first step is to develop objectives and measures using interviews and focus groups with subject matter experts (SMEs) and stakeholders.<br />
For systems engineering trade-off analyses, stakeholder value often includes competing objectives of performance, development schedule, unit cost, support costs, and growth potential. For corporate decisions, shareholder value would also be added to this list. For performance, a functional decomposition can help generate a thorough set of potential objectives. Test this initial list of fundamental objectives by checking that each fundamental objective is essential and controllable and that the set of objectives is complete, non-redundant, concise, specific, and understandable. (Edwards et al. 2007) Figure 2 provides an example of an objectives hierarchy.<br />
<br />
[[File:Fund_Obj_Hierarchy_DM.png|thumb|center|650px|center|'''Figure 2. Fundamental Objectives Hierarchy (INCOSE DAWG 2013).''' Permission granted by INCOSE Decision Analysis Working Group (DAWG). All other rights are reserved by the copyright owner.]]<br />
<br />
For each objective, we define a measure to assess the value of each alternative for that objective. A measure (attribute, criterion, and metric) must be unambiguous, comprehensive, direct, operational, and understandable (Keeney & Gregory 2005).<br />
A defining feature of multi-objective decision analysis is the transformation from measure space to value space. This transformation is performed by a value function which shows returns to scale on the measure range. When creating a value function, we ascertain the walk-away point on the measure scale (x-axis) and map it to a 0 value on the value scale (y-axis). A walk-away point is the measure score where regardless of how well an alternative performs in other measures, the decision maker will walk away from the alternative. He or she does this through working with the user, finding the measure score beyond, at which point an alternative provides no additional value, and labeling it "stretch goal" (ideal) and then mapping it to 100 (or 1 and 10) on the value scale (y-axis). Figure 3 provides the most common value curve shapes. The rationale for the shape of the value functions should be documented for traceability and defensibility (Parnell et al. 2011).<br />
<br />
[[File:Value_Function_Example_DM.png|thumb|center|750px|center|'''Figure 3. Value Function Examples (INCOSE DAWG 2013).''' Permission granted by INCOSE Decision Analysis Working Group (DAWG). All other rights are reserved by the copyright owner.]]<br />
<br />
The mathematics of multiple objective decision analysis (MODA) requires that the weights depend on importance of the measure and the range of the measure (walk away to stretch goal). A useful tool for determining priority weighting is the swing weight matrix (Parnell et al. 2011). For each measure, consider its importance through determining whether the measure corresponds to a defining, critical, or enabling function and consider the gap between the current capability and the desired capability; finally, put the name of the measure in the appropriate cell of the matrix (Figure 4). The highest priority weighting is placed in the upper-left corner and assigned an unnormalized weight of 100. The unnormalized weights are monotonically decreasing to the right and down the matrix. Swing weights are then assessed by comparing them to the most important value measure or another assessed measure. The swing weights are normalized to sum to one for the additive value model used to calculate value in a subsequent section. <br />
<br />
[[File:Swing_Weight_Matrix_DM.png|thumb|center|750px|center|'''Figure 4. Swing Weight Matrix (INCOSE DAWG 2013).''' Permission granted by INCOSE Decision Analysis Working Group (DAWG). All other rights are reserved by the copyright owner.]]<br />
<br />
===Generating Creative Alternatives===<br />
<br />
To help generate a creative and comprehensive set of alternatives that span the decision space, consider developing an alternative generation table (also called a morphological box) (Buede, 2009; Parnell et al. 2011). It is a best practice to establish a meaningful product structure for the system and to be reported in all decision presentations (Figure 5). <br />
<br />
[[File:Descript_of_Alt_DM.png|thumb|center|750px|center|'''Figure 5. Descriptions of Alternatives (INCOSE DAWG 2013).''' Permission granted by INCOSE Decision Analysis Working Group (DAWG). All other rights are reserved by the copyright owner.]]<br />
<br />
===Assessing Alternatives via Deterministic Analysis===<br />
<br />
With objectives and measures established and alternatives having been defined, the decision team should engage SMEs, equipped with operational data, test data, simulations, models, and expert knowledge. Scores are best captured on scoring sheets for each alternative/measure combination which document the source and rationale. Figure 6 provides a summary of the scores. <br />
<br />
[[File:ALT_Scores_DM.png|thumb|center|750px|center|'''Figure 6. Alternative Scores (INCOSE DAWG 2013).''' Permission granted by INCOSE Decision Analysis Working Group (DAWG). All other rights are reserved by the copyright owner.]]<br />
<br />
Note that in addition to identified alternatives, the score matrix includes a row for the ideal alternative. The ideal is a tool for value-focused thinking, which will be covered later.<br />
<br />
===Synthesizing Results===<br />
<br />
Next, one can transform the scores into a value table, by using the value functions developed previously. A color heat map can be useful to visualize value tradeoffs between alternatives and identify where alternatives need improvement (Figure 7).<br />
<br />
[[File:Value_Scorecard_w_Heat_Map_DM.png|thumb|center|850px|center|'''Figure 7. Value Scorecard with Heat Map (INCOSE DAWG 2013).''' Permission granted by INCOSE Decision Analysis Working Group (DAWG). All other rights are reserved by the copyright owner.]]<br />
<br />
The additive value model uses the following equation to calculate each alternative’s value:<br />
<br />
EQUATION HERE<br />
<br />
where<br />
<br />
EQUATION VALUES HERE<br />
<br />
The value component chart (Figure 8) shows the total value and the weighted value measure contribution of each alternative (Parnell et al. 2011). <br />
<br />
[[File:Value_Comp_Graph_DM.png|thumb|center|700px|center|'''Figure 8. Value Component Graph (INCOSE DAWG 2013).''' Permission granted by INCOSE Decision Analysis Working Group (DAWG). All other rights are reserved by the copyright owner.]]<br />
<br />
The heart of a decision management process for system engineering trade off analysis is the ability to assess all dimensions of shareholder and stakeholder value. The stakeholder value scatter plot in Figure 9 shows five dimensions: unit cost, performance, development risk, growth potential, and operation and support costs for all alternatives.<br />
<br />
[[File:Ex_Stakeholder_Value_Scat_DM.png|thumb|center|700px|center|'''Figure 9. Example of a Stakeholder Value Scatterplot (INCOSE DAWG 2013).''' Permission granted by INCOSE Decision Analysis Working Group (DAWG). All other rights are reserved by the copyright owner.]]<br />
<br />
Each system alternative is represented by a scatter plot marker (Figure 9). An alternative’s unit cost and performance value are indicated by x and y positions respectively. An alternative’s development risk is indicated by the color of the marker (green = low, yellow= medium, red = high), while the growth potential is shown as the number of hats above the circular marker (1 hat = low, 2 hats = moderate, 3 hats = high).<br />
<br />
===Identifying Uncertainty and Conducting Probabilistic Analysis===<br />
<br />
As part of the assessment, the SME should discuss the potential uncertainty of the independent variables. The independent variables are the variables that impact one or more scores; the scores that are independent scores. Many times the SME can assess an upper, nominal, and lower bound by assuming low, moderate, and high performance. Using this data, a Monte Carlo Simulation summarizes the impact of the uncertainties and can identify the uncertainties that have the most impact on the decision.<br />
<br />
===Accessing Impact of Uncertainty - Analyzing Risk and Sensitivity===<br />
<br />
Decision analysis uses many forms of sensitivity analysis including line diagrams, tornado diagrams, waterfall diagrams and several uncertainty analyses including Monte Carlo Simulation, decision trees, and influence diagrams (Parnell et al. 2013). A line diagram is used to show the sensitivity to the swing weight judgment (Parnell et al. 2011). Figure 10 shows the results of a Monte Carlo Simulation of performance value. <br />
<br />
[[File:Uncertainty_on_Perf_Value_from_Monte_DM.png|thumb|center|700px|center|'''Figure 10. Uncertainty on Performance Value from Monte Carlo Simulation (INCOSE DAWG 2013).''' Permission granted by INCOSE Decision Analysis Working Group (DAWG). All other rights are reserved by the copyright owner.]]<br />
<br />
===Improving Alternatives===<br />
<br />
Mining the data generated for the alternatives will likely reveal opportunities to modify some design choices to claim untapped value and/or reduce risk. Taking advantage of initial findings to generate new and creative alternatives starts the process of transforming the decision process from "alternative-focused thinking" to "value-focused thinking" (Keeney 1993).<br />
<br />
===Communicating Tradeoffs===<br />
<br />
This is the point in the process where the decision analysis team identifies key observations about tradeoffs and the important uncertainties and risks.<br />
<br />
===Presenting Recommendations and Implementing Action Plan===<br />
<br />
It is often helpful to describe the recommendation(s) in the form of a clearly-worded, actionable task-list in order to increase the likelihood of the decision implementation. Reports are important for historical traceability and future decisions. Take the time and effort to create a comprehensive, high-quality report detailing study findings and supporting rationale. Consider static paper reports augmented with dynamic hyper-linked e-reports.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Buede, D.M. 2009. The Engineering Design of Systems: Models and Methods, Wiley.<br />
<br />
Edwards, W., Miles Jr, R.F. & Von Winterfeldt, D. 2007. Advances In Decision Analysis: From Foundations to Applications, Cambridge University Press.<br />
<br />
Keeney, R.L. and Raiffa H. 1976. Decisions with Multiple Objectives - Preferences and Value Tradeoffs. New York: Wiley.<br />
<br />
Keeney, R.L. 1992. Value-Focused Thinking: A Path to Creative Decision-making. Cambridge, Massachusetts: Harvard University Press.<br />
<br />
Keeney, R.L. 1993. Creativity in MS/OR: Value-focused thinking—Creativity directed toward decision making. Interfaces, 23(3), pp.62–67.<br />
<br />
Parnell, G. S. 2009. Decision Analysis in One Chart, Decision Line, Newsletter of the Decision Sciences Institute.<br />
<br />
Parnell, G. S., Driscoll, P. J., and Henderson D. L., (eds). 2011. Decision Making for Systems Engineering and Management, 2nd Edition, Wiley Series in Systems Engineering, Wiley & Sons Inc. <br />
<br />
Parnell, G., Bresnick, T., Tani, S., & Johnson, E. 2013. Handbook of Decision Analysis, Wiley & Sons.<br />
<br />
===Primary References===<br />
Buede, D.M. 2004. On Trade Studies, INCOSE.<br />
<br />
Keeney, R.L. 2004. Making Better Decision Makers. Decision Analysis, 1(4), pp.193–204.<br />
<br />
Keeney, R.L. & Gregory, R.S. 2005. Selecting Attributes to Measure the Achievement of Objectives. Operations Research, 53(1), pp.1–11.<br />
<br />
Kirkwood, C. W. 1197. Strategic Decision Making: Multiobjective Decision Analysis with Spreadsheets, Belmont, California: Duxbury Press.<br />
<br />
===Additional References===<br />
Buede, D.M. & Choisser, R.W. 1992. Providing an Analytic Structure for Key System Design Choices. Journal of Multi-Criteria Decision Analysis, 1(1), pp.17–27.<br />
<br />
Felix, A. 2004. Standard Approach to Trade Studies, INCOSE.<br />
<br />
Felix, A. 2005. How the Pro-Active Program (Project) Manager Uses a Systems Engineer’s Trade Study as a Management Tool, and not just a Decision Making Process, INCOSE.<br />
<br />
Miller, G.A. 1956. The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information. Psychological Review, 63(2), p.81.<br />
<br />
Ross, A.M. and Hastings, D.E. 2005. Tradespace Exploration Paradigm, INCOSE.<br />
<br />
Sproles, N. 2002. Formulating Measures of Effectiveness, INCOSE.<br />
<br />
Silletto, H. 2005. Some Really Useful Principles: A new look at the scope and boundaries of systems engineering, INCOSE.<br />
<br />
Ullman, D.G. and Spiegel, B.P. 2006. Trade Studies with Uncertain Information, INCOSE.<br />
<br />
----<br />
<center>[[Measurement|< Previous Article]] | [[Systems Engineering Management|Parent Article]] | [[Configuration Management|Next Article >]]</center><br />
<br />
{{DISQUS}}<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:Systems Engineering Management]]</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Integrating_Supporting_Aspects_into_System_Models&diff=48897
Integrating Supporting Aspects into System Models
2013-10-31T22:10:00Z
<p>Eleach: </p>
<hr />
<div>===Introduction=== <br />
The model-based approach to systems engineering considers the system model as much more than a plain description of the system; the model is the central common basis for capturing, representing, and integrating the various system aspects listed below. The model is essential to the design and understanding of the system as well as to managing its life cycle and evolution. Modeling languages constitute the basis for standardized, formal descriptions of systems, just like natural languages form the basis for human communication. <br />
As systems progressively become ever more complex and multidisciplinary, as does the need for the conceptual modeling of systems to evolve, and also become more critical for understanding complex design (Dori 2002). In addition to facilitating communication among clients, designers, and developers, conceptual modeling languages also assist in clearly describing and documenting various domains, systems, and problems, and define requirements and constraints for the design and development phases (Wand and Weber 2002). The importance of model-based analysis is demonstrated by the variety of conceptual modeling methodologies and frameworks, although de facto standards are slow to emerge. While certain disciplines of engineering design, such as structural analysis or circuit design have established modeling semantics and notation, the conceptual modeling of complex systems and processes has not yet converged on a unified, consolidated modeling framework (Estefan 2007). The challenge is not only to integrate multiple aspects and support the various phases of the system’s life cycle, but also to first to capture the multidisciplinary nature of the system, which has led to the creation of various frameworks. Nevertheless, the information systems analysis paradigm is currently the most widely used, perhaps due to the need to integrate complex systems via information-intensive applications and interactions. <br />
This article discusses the integrated modeling of systems and supporting aspects using Model-Based Systems Engineering methodologies and frameworks. Supporting aspects of systems engineering include: <br />
*Engineering Management<br />
*Project Management<br />
*Requirements Engineering and Management<br />
*Risk Modeling, Analysis, and Management<br />
*Quality Assurance, Testing, Verification, and Validation<br />
*System Integration and Employment<br />
*Analysis of "-ilities" (e.g., Reliability, Availability, Maintainability, Safety, And Security (RAMSS), Manufacturability, Extensibility, Robustness, Resilience, Flexibility, and Evolvability)<br />
These aspects can pertain to physical facets, as well as to functional, structural, behavioral, social, and environmental facets of the core system model. The article focuses on three main aspects: <br />
<br />
# Project and Engineering Management <br />
# Risk Modeling, Analysis, and Management<br />
# Requirements Definition and Management<br />
<br />
===Integrated Modeling of Systems and Projects=== <br />
This section discusses the integrated modeling of systems and projects and of the project-system relationship (often called Project-Product Integration). The fields of project management and systems engineering have been advancing hand-in-hand for the last two decades, due to the understanding that successful projects create successful systems. All the main systems engineering resources pay considerable attention to project management and consider it to be a critical process and enabler of systems engineering (Haskins, Forsberg, and Krueger 2007; NASA 2007; Sage and Rouse 2011). The integration of system-related aspects and concepts into project plans is more common than the integration of project-related aspects and concepts into system models. Because the project is a means to an end, it is the process that is expected to deliver the system. Indeed, project activities are often named after or in accord with the deliverables that they are aimed at facilitating (e.g., “console design”, “software development”, “hardware acquisition”, or “vehicle assembly”). Each is a function name, consisting of an object (noun), or the system to be attained, and a process (verb), being the project or part of the project aimed at attaining the end system. The specific process associated with each of these examples refers to different stages or phases of the project and to different maturity levels of the system or sub-system it applies to. Moreover, the mere inclusion of system and part names in activity names does not truly associate system model artifacts with these activities. Overall, it is not truly possible to derive the set of activities associated with a particular part or functionality of the system which that will be delivered by the project. Project-Product integration is not straightforward, as project models and system models are traditionally disparate and hardly interface. A model-based approach to project-system integration follows a system-centric paradigm and focuses on incorporating project-related aspects and concepts into the core system model, as opposed to the project-centric approach described in the previous paragraph. Such aspects and concepts include schedule, budget and resources, deliverables, work-packages, constraints and previous relations. The integrated system-project model should provide useful information on the mutual effects of project activities and system components and capabilities; the processes it is designed to perform in order to provide value. Some examples of integrated system-project modeling included the following: <br />
*The set of project activities associated with a particular system component, feature, or capability.<br />
*The set of resources required for performing a task of designing or developing a particular component of the system.<br />
*The team or subcontractor responsible for delivering each system component. <br />
*The preexisting dependencies between activities of system components deployment. <br />
*The cost associated with each system component, feature, or capability. <br />
*The parts of the system negotiated for each delivery, deployment, build, release, or version. <br />
<br />
The Work Breakdown Structure (WBS) is designed to support the division of the project scope (work content) amongst the individuals and organizations participating in the project (Golany and Shtub 2001). The WBS is traditionally organization or activity-oriented; however, one of its main cornerstones focuses on the deliverable, which corresponds to the system, sub-system, component, or a capability or feature of one or more of these. A deliverable-oriented WBS, in which the high-level elements correspond to primary sub-systems, is advocated, as it is likely to allow the WBS to be more product-oriented (Rad 1999). An integrated approach to project planning and system modeling (Sharon and Dori 2009) merges the system model with the project’s WBS using Object-Process Methodology (OPM) (Dori 2002). The unified OPM model captures both the project activities and the system components and functionalities. <br />
<br />
The Design Structure Matrix (DSM) is a common method for enhancing and analyzing the design of products and systems. DSMs can be component-based, task-based, parameter-based, or team-based (Browning 2001). A DSM for an OPM-based project-product model derives a hybrid DSM of project activities and system building blocks from the unified OPM model, accounting for dependencies between project activities and system components, as well as replacing the two monolithic and separate component-based and task-based DSM views (Sharon, De-Weck, and Dori 2012). The underlying OPM model assures model consistency and traceability. The integrated project-product OPM model includes both a diagram and an equivalent auto-generated textual description. The DSM derived from this model visualizes a dependency loop comprising both system components and project activities.<br />
<br />
Another model-based approach (Demoly et al. 2010) employs the System Modeling Language (SysML) in order to create various views that meet the needs of various system stakeholders, such as the project/process manager. The approach includes both product-oriented and process-oriented views.<br />
<br />
===Integrated Modeling of Systems and Requirements=== <br />
Requirements are statements that describe operational, functional, or design-related aspects of a system. Requirements definition and management is an important SE process, as it both initiates and facilitates the entire SE effort by defining the expected functions and performance of the engineered system. Several challenges associated with requirements include:<br />
*Defining the requirements in a structured, controlled manner.<br />
*Tracing these requirements to system components, aspects, and decisions.<br />
*Testing and verifying compliance of the system with these requirements. <br />
The extension of conceptual system models to include requirements has several significant benefits: <br />
# Requirements provide the rationale for the system's architecture and design by making and justifying architectural and design decisions based on specific requirements. <br />
# Modeling the internal logic and the hierarchy and dependency relations among requirements enables identification and elimination of redundant and contradictory requirements. <br />
# Responsibility for satisfying specific requirements can often be assigned to teams and persons responsible for delivering various system components. While the advantages of having good requirements engineering is clear, it is often a challenge to directly trace requirements to specific system artifacts, especially when the requirements are defined in a holistic, solution-independent manner. <br />
<br />
<br />
There are several methods to incorporate requirements into system models, including SysML Requirements Engineering and Object-Process Methodology(OPM)-based Requirements Engineering and Authoring. <br />
<br />
====SysML-Based Requirements Engineering====<br />
The SysML requirements diagram makes it possible to capture the requirements and the relations among them in a visual manner, which is more intuitive than the textual manner in which requirements are traditionally edited and managed. The diagram was added to the basic set of UML diagrams that formed the basis for SysML (Friedenthal, Moore, and Steiner 2006), and is not a native UML diagram. Tracing requirements to the system blocks and artifacts satisfying them can be captured in the SysML Block Definition Diagram, which is primarily designated to capture the relations among types of system elements and components. The < > link between the block and the requirement captures the trace. <br />
<br />
====OPM-Based Requirements Engineering==== <br />
Object-Process Methodology (OPM) is a methodology and language for conceptual modeling of complex systems and processes with a bimodal textual and graphical representation (Dori 2002). OPM’s textual representation is coordinated with the graphical representation; additionally, each visual model construct in the Object-Process Diagram (OPD) is described by a formal structured textual statement in Object-Process Language (OPL), which is a subset of natural English. OPM facilitates model-based requirements engineering, authoring, and specification, in three possible modes:<br />
<br />
# OPM can be used to generate conceptual models which initially focus on the requirements level—the problem domain, rather than the design level or the solution domain, which facilitates automated model-based requirements generation (Blekhman and Dori 2011). The requirements model is solution-neutral and it can be the basis for one or more architectural solutions for achieving the functions specified in the requirements.<br />
# Utilizing OPM in order to generate requirement-oriented OPDs in a manner similar to the SysML Requirements Diagram enables an engineer to capture the requirements specification as the skeleton for the system model. User-defined tagged structural relations, such as "is realized by" or is allocated to", provide for associating requirements with system model functions (objects and processes that transform them). This approach is similar to the SysML requirements diagram; however, instead of using a unique notation in a separate diagram type, the requirements are seamlessly incorporated into the single system model.<br />
# OPM can be used for the purpose of generating visual system models from formally specified requirements by tracing the textually authored requirements to system model inserts and artifacts (Dori et al. 2004).<br />
<br />
===Integrating Risk into System Models=== <br />
Risk is an expression and a measure of the negative or adverse impact of uncertainty. Risk exists whenever uncertainty can lead to several results, of which some may be negative (adverse) and some positive. A system faces risks from other systems or from the environment, and it can also pose risks to other systems or to the environment. Systems are characterized by such attributes, such as: goals, objectives, inputs, outputs, variables, parameters, processes, events, states, subsystems, interfaces, mechanisms, and methods. System vulnerability is the system's total potential to be harmed or negatively affected in any one of these attributes. Analogously, system harmfulness is the system's total potential to harm others or to generate negative effects, which can be manifested in one or more of these attributes (Haimes 2009). Model-based risk analysis (MBRA) enables structured analysis and risk-related process control. Several model-based risk analysis approaches are available in the literature. MBRA is presently common in the information technology and information security domains more than the systems engineering domain; however, some of the methods are generally applicable to complex systems as well. The ISO-IEC-IEEE collaborative software development and operation lifecycle standard (ISO and IEC 2004) proposes a concurrent approach to IT Risk Management. This approach consists of six main activities: <br />
*Plan and Implement Risk Management <br />
*Manage the Project Risk Profile<br />
*Perform Risk Analysis <br />
*Perform Risk Monitoring <br />
*Perform Risk Treatment <br />
*Evaluate the Risk Management Process <br />
<br />
These activities are executed concurrently, affect and provide feedback to each other, and interact with other software life cycle processes, such as the technical management and the design processes (ISO and IEC 2004). <br />
<br />
The CORAS approach (Fredriksen et al. 2002; den Braber et al. 2006; Lund, Solhaug, and Stølen 2011) is a UML-derivative for IT security risk modeling and assessment. This framework consists mostly of the UML use case (UC) diagram, extended for misuse cases. Additional notation was added to the UC notation in order to capture risk sources, effects, and results (e.g., the “bad actor” icon, moneybag for asset-in-risk). A misuse diagram can include, for example, the risk of loss of legal protection of proprietary know-how due to information theft and distribution by an unfaithful employee. The treatment for the risk source of insufficient security policy, which contributes to the above risk, is illustrated in a separate treatment diagram.<br />
<br />
A quantitative risk assessment method for component-based systems (Grunske and Joyce 2008) supports component vulnerability analysis and specification using modular attack trees. In addition, it provides attacker profiling, which enables supporting econometric approaches to risk response. The methodology utilizes SysML as its underpinning language, and especially the SysML block definition diagram and parametric diagram, in order to capture parametric relations and constraints as a means to defining risk profiles. <br />
<br />
System-Theoretic Accident Model and Processes, STAMP (Leveson 2011) is a method for system and component design for safety. STAMP reformulates the safety problem as a control problem as opposed to a reliability problem. STAMP is optimized for safety-oriented systems engineering and design and for hazard avoidance and mitigation, specifically in complex socio-technical systems. A model-based adaptation of STAMP was also proposed (Leveson 2004) and was implemented in various safety-critical and mission-critical systems, including aircraft collision avoidance systems (CAS) (Leveson 2004) and ballistic missile defense systems (Pereira, Lee, and Howard 2006). Risk-Oriented Systems Engineering (ROSE) (Mordecai and Dori 2013) is a method based on Object-Process Methodology (OPM) for integrating risk into system models. Being system-centric, ROSE is responsible for capturing risk layers and aspects on top of and in sync with the core system model, while improving and immunizing it against captured risks, as well as for generating system robustness and resilience by design in response to various risk-posing scenarios. The risk handling meta-model includes risk mitigation during the design phase and risk response during the operational phase.<br />
<br />
==References==<br />
===Works Cited===<br />
===Primary References===<br />
<br />
Dori, D. 2002. ''[[Object-Process Methodology – A Holistic Systems Paradigm]]''. New York, NY, USA: Springer-Verlag.<br />
<br />
Estefan, J. 2008. ''[[A Survey of Model-Based Systems Engineering (MBSE) Methodologies]],'' Rev. B. San Diego, CA, USA: International Council on Systems Engineering. INCOSE-TD-2007-003-02. Available at http://www.incose.org/ProductsPubs/pdf/techdata/MTTC/MBSE_Methodology_Survey_2008-0610_RevB-JAE2.pdf.<br />
<br />
Golany, Boaz, and Avraham Shtub. 2001. “Work Breakdown Structure.” In Salvendy, G. (ed.) 2001. ''[[Handbook of Industrial Engineering, Technology and Operations Management]],'' 3rd ed. Hoboken, NJ, USA: John Wiley & Sons, Inc. 1263–1280.<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.<br />
<br />
<br />
===Additional References===<br />
<br />
Blekhman, Alex, and Dov Dori. 2011. “Model-Based Requirements Authoring - Creating Explicit Specifications with OPM.” In 6th International Conference on Systems Engineering. Herzeliyya, Israel. <br />
<br />
Browning, T.R. 2001. “Applying the Design Structure Matrix to System Decomposition and Integration Problems: a Review and New Directions.” IEEE Transactions on Engineering Management 48 (3): 292–306. doi:10.1109/17.946528. http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=946528. <br />
<br />
Demoly, Frédéric, Davy Monticolo, Benoît Eynard, Louis Rivest, and Samuel Gomes. 2010. “Multiple Viewpoint Modelling Framework Enabling Integrated Product–process Design.” International Journal on Interactive Design and Manufacturing (IJIDeM) 4 (4) (October 12): 269–280. doi:10.1007/s12008-010-0107-3. http://link.springer.com/10.1007/s12008-010-0107-3. <br />
<br />
Den Braber, Folker, Gyrd Brændeland, Heidi E. I. Dahl, Iselin Engan, Ida Hogganvik, Mass S. Lund, Bjørnar Solhaug, Ketil Stølen, and Fredrik Vraalsen. 2006. The CORAS Model-based Method for Security Risk Analysis. SINTEF, Oslo. Oslo: SINTEF. <br />
<br />
Dori, Dov, Nahum Korda, Avi Soffer, and Shalom Cohen. 2004. “SMART: System Model Acquisition from Requirements Text.” Lecture Notes in Computer Science: Business Process Management 3080: 179–194. http://link.springer.com/chapter/10.1007/978-3-540-25970-1_12. <br />
<br />
Kristiansen, Ba Gran, and K Stolen. 2002. “The CORAS Framework for a Model-based Risk Management Process.” In Lecture Notes In, edited by Stuart Anderson, Massimo Felici, and SandroEditors Bologna, 2434:94–105. Springer-Verlag. doi:10.1007/3-540-45732-1_11. <br />
<br />
Friedenthal, Sanford, Alan Moore, and Rick Steiner. 2006. “OMG Systems Modeling Language ( OMG SysML ™ ) Tutorial” (July). <br />
<br />
Grunske, L, and D Joyce. 2008. “Quantitative Risk-based Security Prediction for Component-based Systems with Explicitly Modeled Attack Profiles.” Journal of Systems and Software 81 (8): 1327–1345. Haimes, YY. 2009. “On the Complex Definition of Risk: A Systems-Based Approach.” Risk Analysis 29 (12): 1647–1654. http://onlinelibrary.wiley.com/doi/10.1111/j.1539-6924.2009.01310.x/full. <br />
<br />
ISO, and IEC. 2004. “ISO/IEC 16085: Information Technology — Software Life Cycle Processes — Risk Management”. Vol. 2004.<br />
<br />
Leveson, NG. 2004. “Model-based Analysis of Socio-technical Risk.” <br />
<br />
Leveson, NG. 2011. Engineering a Safer World. MIT Press. <br />
<br />
Lund, Mass Soldal, Bjørnar Solhaug, and Ketil Stølen. 2011. Model-Driven Risk Analysis: The CORAS Approach. Berlin, Heidelberg: Springer Berlin Heidelberg. doi:10.1007/978-3-642-12323-8. <br />
http://www.springerlink.com/index/10.1007/978-3-642-12323-8. <br />
<br />
Mordecai, Yaniv, and Dov Dori. 2013. “Model-Based Risk-Oriented Robust Systems Design with Object-Process Methodology.” International Journal of Strategic Engineering Asset Management TBD (CESUN 2012 Special Issue). <br />
<br />
Pereira, SJ, Grady Lee, and Jeffrey Howard. 2006. “A System-Theoretic Hazard Analysis Methodology for a Non-advocate Safety Assessment of the Ballistic Missile Defense System”. Vol. 1606. http://oai.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADA466864. <br />
<br />
Rad, Parviz F. 1999. “Advocating a Deliverable-oriented Work Breakdown Structure.” Sage, Andrew P., and William B. Rouse. 2011. Handbook of Systems Engineering and Management. Edited by Andrew P. Sage and William B. Rouse. 2nd ed. John Wiley & Sons. <br />
<br />
Sharon, Amira, Olivier L De-Weck, and Dov Dori. 2012. “Improving Project-Product Lifecycle Management with Model-Based Design Structure Matrix : A Joint Project Management and Systems Engineering Approach.” Systems Engineering: 1–14. doi:10.1002/sys. <br />
<br />
Sharon, Amira, and Dov Dori. 2009. “A Model-Based Approach for Planning Work Breakdown Structures of Complex Systems Projects.” In Proc. 14th IFAC Symposium on Information Control Problems in Manufacturing. <br />
<br />
Wand, Yair, and Ron Weber. 2002. “Research Commentary: Information Systems and Conceptual Modeling?A Research Agenda.” Information Systems Research 13 (4) (December): 363–376. doi:10.1287/isre.13.4.363.69.<br />
<br />
----<br />
<center>[[Modeling Standards|< Previous Article]] | [[Representing Systems with Models|Parent Article]] | [[Systems Approach Applied to Engineered Systems|Next Article >]]</center><br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 2]][[Category:Topic]]<br />
[[Category:Representing Systems with Models]]</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Technical_Leadership_in_Systems_Engineering&diff=48884
Technical Leadership in Systems Engineering
2013-10-31T16:52:45Z
<p>Eleach: </p>
<hr />
<div>=Technical Leadership= <br />
==Introduction==<br />
Technical leadership in systems engineering is exhibited by effectively communicating a vision, strategy, method, or technique needed to achieve a shared goal, which is accepted and enacted by team members, technical personnel, managers, and other project/program stakeholders. A systems engineering leader may lead a team of systems engineers for a project or program, or may be the only systems engineer who leads a team of members from the various disciplines involved in the project or program (e.g., other engineers, IT personnel, service providers).<br />
There is a vast amount of literature addressing leadership issues from multiple points of view, including philosophical, psychological, and emotional considerations (Yukl 2013). This article is concerned with the pragmatic aspects of the leading team members involved in a systems engineering project. Related knowledge areas and articles are in Part 5 [[Enabling Systems Engineering]] and the Part 6 knowledge area [[Systems Engineering and Project Management]].<br />
<br />
['''Editorial Note:''' The reference in the article in the Part 6 SE and Project Management KA, “An Overview of the PMBoK Guide” should be changed from 4th ed. to the 5th ed. The publication date is 2013, if you want to include it. It should be noted that it should be changed to 5th ed. throughout SEBoK. Also, the body of the SE and Project Management KA incorrectly cites (PMI 2008); it should be (PMI 2013).]<br />
<br />
==Attributes of Effective Leaders==<br />
Some commonly cited attributes of effective leaders are listed in Table 1 (Fairley 2009):<br />
<br />
{|<br />
|+ '''Table 1. Attributes of effective leaders (Fairley 2009)'''<br />
|-<br />
!<br />
!<br />
|-<br />
| Listening carefully<br />
| Maintaining enthusiasm<br />
|-<br />
| Delegating authority <br />
| Saying “thank you” <br />
|-<br />
| Facilitating teamwork<br />
| Praising team for achievements<br />
|-<br />
| Coordinating work activities<br />
| Accepting responsibility for shortcomings<br />
|-<br />
| Facilitating communication<br />
| Coaching and training <br />
|-<br />
| Making timely decisions<br />
| Indoctrinating newly assigned personnel<br />
|-<br />
| Involving appropriate stakeholders <br />
| Reconciling differences and resolving conflicts<br />
|-<br />
| Speaking with individual team members on a frequent basis<br />
| Helping team members develop career paths and achieve professional goals <br />
|-<br />
| Working effectively with the project/program manager and external stakeholders<br />
| Reassigning, transferring, and terminating personnel as necessary<br />
|}<br />
<br />
Characteristics that result in effective leadership of systems engineering activities include behavioral attributes, leadership style, and communication style. In addition, a team leader for a systems engineering project or program has management responsibilities that include, but are not limited to: developing and maintaining the systems engineering plan, as well as establishing and overseeing the relationships between the project/program manager and project/program management personnel.<br />
<br />
===Behavioral Attributes===<br />
Behavioral attributes are habitual patterns of behavior, thought, and emotion that remain stable over time (Yukl 2013). Positive behavioral attributes enable a systems engineering leader to communicate effectively and to make sound decisions, while also taking into consideration the concerns of all stakeholders. Desirable behavioral attributes for a systems engineering leader include characteristics such as (Fairley 2009):<br />
*Aptitude - This is exhibited by the ability to effectively lead a team. Leadership aptitude is not the same as knowledge or skill but rather is indicative of the ability (either intuitive or learned) to influence others. Leadership aptitude is sometimes referred to as charisma or as an engaging style.<br />
*Initiative - This is exhibited by enthusiastically starting and following through on every leadership activity.<br />
*Enthusiasm - This is exhibited by expressing and communicating a positive, yet realistic attitude concerning the project, product, and stakeholders.<br />
*Communication Skills - These are exhibited by expressing concepts, thoughts, and ideas in a clear and concise manner, in oral and written forms, while interacting with colleagues, team members, managers, project stakeholders, and others. <br />
*Team Participation - This is exhibited by working enthusiastically with team members and others when collaborating on shared work activities.<br />
*Negotiation - This is the ability to reconcile differing points of view and achieve consensus decisions that are satisfactory to the involved stakeholders.<br />
*Goal Orientation – This involves setting challenging but not impossible goals for oneself, team members, and teams.<br />
*Trustworthiness - This is demonstrated over time by exhibiting ethical behavior, honesty, integrity, and dependability in taking actions and making decisions that affect others.<br />
Weakness, on the other hand, is one example of a behavioral attribute that may limit the effectiveness of a systems engineering team leader.<br />
===Personality Traits===<br />
“Personality traits” was initially introduced in the early 1900's by Carl Jung, who published a theory of personality based on three continuums: introversion-extroversion, sensing-intuiting, and thinking-feeling. According to Jung, each individual has a dominant style which includes an element from each of the three continuums. Jung also emphasized that individuals vary their personality traits in the context of different situations; however, an individual’s dominant style is the preferred one, as it is the least stressful for the individual to express and it is also the style that an individual will resort to when under stress (Jung 1971).<br />
The Myers-Briggs Type Indicator (MBTI), developed by Katherine Briggs and her daughter Isabel Myers, includes Jung’s three continuums, plus a forth continuum of judging-perceiving. These four dimensions characterize 16 personality styles for individuals designated by letters, such as ISTP (Introverted, Sensing, Thinking, and Perceiving). An individual’s personality type indicator is determined through the answers the person has provided on a questionnaire (Myers 1995).<br />
MBTI profiles are widely used by job counselors to match an individual’s personality type to job categories in which the individual would be "most comfortable and effective”. Matching is based on the results of having applied the MBTI model to several thousands of subjects who have described themselves as comfortable and effective in their jobs.<br />
The MBTI has also been applied to group dynamics and leadership styles. Most studies indicate that groups perform better when a mixture of personality styles work together to provide different perspectives. Some researchers claim that there is evidence suggests that positive leadership styles are most closely related to an individual’s position on the judging-perceiving scale of the MBTI profile (Hammer 2001). Those on the judging side of the scale are most likely to be “by the book” managers, while those on the perceiving side of the scale are most likely to be “people-oriented” leaders. “Judging” in the MBTI model does not mean judgmental; rather, a judging trait indicates a quantitative orientation and a perceiving trait indicates a qualitative orientation. <br />
The MBTI has its detractors (http://en.wikipedia.org/wiki/Myers-Briggs_Type_Indicator#Criticism), (Nowack 1996); however, MBTI personality styles can provide insight into effective and ineffective modes of interaction and communication among team members and team leaders. For example, an individual with a strongly Introverted, Thinking, Sensing, and Judging personality index (ITSJ) may have difficulty interacting with an individual who has a strongly Extroverted, Intuiting, Feeling, Perceiving personality index (ENFP). <br />
===Leadership Styles and Communication Styles===<br />
There is a vast amount of literature pertaining to leadership styles and there are many models of leadership. Most of these leadership models are based on some variant of Jung’s psychological types. One of the models, the Wilson Social Styles, integrates leadership styles and communication styles (Wilson 2004). The Wilson model characterizes four kinds of leadership styles:<br />
*Driver leadership style - This is exhibited when a leader focuses on the work to be accomplished and on specifying how others must do their jobs.<br />
*Analytical-style leadership - This emphasizes collecting, analyzing, and sharing data and information. An analytical leader asks others for their opinions and recommendations to gather information.<br />
*Amiable leadership style – This is characterized by emphasis on personal interactions and on asking others for their opinions and recommendations.<br />
*Expressive leadership style – Like the amiable style, this also focuses on personal relationships, but an expressive leader tells others rather than asking for opinions and recommendations.<br />
When taken to extremes, each of these styles can result in weakness of leadership.<br />
By focusing too intently on the work, "drivers" can provide too much or too little guidance and direction. Too little guidance occurs when the individual is preoccupied with her or his personal work, while too much guidance results in micromanagement, which limits the personal discretion for team members. Drivers may also be insensitive to interpersonal relationships with team members and others.<br />
Analytical leaders may provide too much information or may fail to provide information that is obvious to them, but not their team members. They do not like to discuss things they already know or that are irrelevant to the task at hand. Like driver-style leaders, they may be insensitive to interpersonal relationships with other individuals.<br />
Amiable leaders focus on interpersonal relationships in order to get the job done. They may exhibit a dislike of those who fail to interact with them on a personal level and may fail to show little concern for those who show little personal interest in them.<br />
Expressive leaders also focus on interpersonal relationships. In the extreme, an expressive leader may be more interested in stating their opinions than in listening to others. Additionally, they may play favorites and ignore those who are not favorites.<br />
While these characterizations are gross oversimplifications, they serve to illustrate leadership styles that may be exhibited by systems engineering team leaders. Effective team leaders are able to vary their leadership style to accommodate the particular context and the needs of their constituencies without going to extremes; but as emphasized by Jung, each individual has a preferred comfort zone that is least stressful and to which an individual will resort during times of added pressure.<br />
===Communication Styles===<br />
An additional characterization of the Wilson model is the preferred style of communication for different leadership styles, which is illustrated by the dimensions of assertiveness and responsiveness.<br />
<br />
[[File:Dimensions_of_Communication_Styles.png|600px|thumb|center|'''Figure 1. Dimensions of Communication Styles (Fairley 2009).''' Reprinted with permission of Dick Fairley. All other rights are reserved by the copyright owner.]]<br />
<br />
Task-oriented assertiveness is exhibited in a communication style that emphasizes the work to be done rather than on the people who will do the work, while the people-oriented communication style addresses personnel issues first and tasks secondly. A tell-oriented communication style involves telling rather than asking, while an ask-oriented assertiveness emphasizes asking over telling. Movies, plays, and novels often include caricatures of extremes in the assertiveness and responsiveness dimensions of Wilson communication styles.<br />
An individual’s communication style may fall anywhere within the continuums of assertiveness and responsiveness, from extremes to more moderate styles and may vary considering the situation. Examples include:<br />
* Driver communication style exhibits task-oriented responsiveness and tell-oriented assertiveness. <br />
*Expressive communication style shares tell-oriented assertiveness with the driver style, but favors people-oriented responsiveness. <br />
*Amiable communication style involves asking rather than telling (as does the analytical style) and emphasizes people relationships over task orientation (as does the expressive style). <br />
*Analytical communication style exhibits task-oriented responsiveness and ask-oriented assertiveness. <br />
The most comfortable communication occurs when individuals share the same communication styles or share adjacent quadrants in Figure 1. Difficult communication may occur when individuals are in diagonal quadrants; for example, communication between an extreme amiable style and an extreme driver style. Technical leaders and others can improve communications by being aware of different communication styles (both their own and others) and by modifying their communication style to accommodate the communication styles of others.<br />
<br />
===Management Responsibilities===<br />
Leading a systems engineering team involves communicating, coordinating, providing guidance, and maintaining progress and morale. Managing a project, according to the PMBOK® Guide (PMBOK 2013), involves application of the five process groups of project management: initiating, planning, executing, monitoring and controlling, and closing. Colloquially, systems engineering project/program management is concerned with making and updating plans and estimates, providing resources, collecting and analyzing product and process data, working with the technical leader to control work processes and work products, as well as managing the overall schedule and budget. <br />
Good engineering managers are not necessarily good technical leaders and good technical leaders are not necessarily good engineering managers; the expression of different personality traits and skill sets is required. Those who are effective as both managers and leaders have both analytical and interpersonal skills, although their comfort zone may be in one of managing or leading. Two management issues that are typically the responsibility of a systems engineering team leader are: <br />
*Establishing and maintaining the division of responsibility among him or herself, the systems engineering team leader, and the project/program manager. <br />
*Developing, implementing, and maintaining the systems engineering plan (SEP).<br />
<br />
Relationships between systems engineering and project management are addressed in the Part 6 KA of this Guide SE and Project Management. Also, see the Part 5 KA Enabling Teams for a discussion of the relationships between a project/program manager and a systems engineering technical leader.<br />
The System Engineering Plan (SEP) is, or should be, the highest-level plan for managing the technical aspects of a project or program. It is subordinate to the systems engineering management plan (SEMP) and often has a number of secondary technical plans that provide details on specific technical areas and supporting processes. Also, see the article SE Planning Process Overview in the Part 3 Planning KA. The SEP may be integrated into the System Engineering Management Plan (SEMP) or it may be a standalone, coordinated document. A template for SEPs is provided in Table 2 (See SEP 3011).<br />
<br />
['''Editorial Note:''' the Part 3 article of SEBoK says the SEP is sometimes known as the SEMP; other references indicate they are separate documents – which is correct?]<br />
<br />
<br />
<br />
{| <br />
|+'''Table 2. Outline of a Systems Engineering Plan (Sandbox Original)'''<br />
!<br />
|-<br />
|'''1. Introduction – Purpose and Update Plan'''<br />
|-<br />
|'''2. Program Technical Requirements'''<br />
|-<br />
| 2.1. Architectures and Interface Control<br />
|-<br />
| 2.2. Technical Certifications <br />
|-<br />
|'''3. Engineering Resources and Management'''<br />
|-<br />
| 3.1. Technical Schedule and Schedule Risk Assessment<br />
|-<br />
| 3.2. Engineering Resources and Cost/Schedule Reporting<br />
|-<br />
| 3.3. Engineering and Integration Risk Management <br />
|-<br />
| 3.4. Technical Organization <br />
|-<br />
| 3.5. Relationships with External Technical Organizations <br />
|-<br />
| 3.6. Technical Performance Measures and Metrics <br />
|-<br />
|'''4. Technical Activities and Products'''<br />
|-<br />
| 4.1. Results of Previous Phase SE Activities<br />
|-<br />
| 4.2. Planned SE Activities for the Next Phase<br />
|-<br />
| 4.3. Requirements Development and Change Process<br />
|-<br />
| 4.4. Technical Reviews <br />
|-<br />
| 4.5. Configuration and Change Management Process<br />
|-<br />
| 4.6. Design Considerations<br />
|-<br />
| 4.7. Engineering Tools <br />
|-<br />
|'''Annex A – Acronyms'''<br />
|}<br />
<br />
SEP templates are often tailored to meet the needs of individual projects or programs by adding needed elements and modifying or deleting other elements. A systems engineering team leader typically works other team members, the project/program manager (or management team), and other stakeholders to develop the SEP and maintain currency of the plan as a project evolves. Some organizations provide one or more SEP templates and offer guidance for developing and maintaining an SEP. Some organizations have a functional group that can provide assistance in developing the SEP.<br />
<br />
==References==<br />
===Works Cited===<br />
[[A Guide to the Project Management Body of Knowledge]]: PMBOK® Guide, Project Management Institute, 2013.<br />
Fairley, R.E. Managing and Leading Software Projects. Hoboken, NJ, USA: John Wiley & Sons. ISBN 978-0470294550.<br />
<br />
Hammer, A.L., Myers-Briggs Type Indicator Work Styles Report, Consulting Psychologists Press, 2001. [http://www.cpp.com/images/reports/smp261182.pdf]<br />
<br />
Jung, Carl Gustav. "Psychological Types". Collected Works of C.G. Jung, Volume 6. Princeton University Press, 1971, ISBN 0-691-09774.<br />
<br />
Myers, Isabel Briggs with Peter B. Myers. Gifts Differing: Understanding Personality Type. Mountain View, CA: Davies-Black Publishing (reprint 1995). ISBN 0-89106-074-X. <br />
<br />
Nowack, K. “Is the Myers Briggs Type Indicator the Right Tool to Use? Performance in Practice,” American Society of Training and Development, Fall 1996, 6)<br />
<br />
Systems Engineering Plan Outline (Version 1.0, April 20, 2011) [https://acc.dau.mil/ILC_SEP].<br />
<br />
Wilson, L., The Social Styles Handbook, Nova Vista Publishing, 2004.<br />
<br />
Yukl, G. Leadership in Organizations – 8th edition, Pearson, 2013. ISBN 978-0132771863<br />
<br />
===Primary References===<br />
Fairley, R.E. [[Managing and Leading Software Projects]]. Hoboken, NJ, USA: John Wiley & Sons. <br />
<br />
Myers, Isabel Briggs with Peter B. Myers. 1995. [[Gifts Differing: Understanding Personality Type]]. Mountain View, CA: Davies-Black Publishing under special license from CPP, Inc. 2nd edition (May 3, 1995). ISBN 978-0-89106-074-1.<br />
<br />
Wilson, Larry. 2004. [[The Social Styles Handbook]]. Canada: Nova Vista Publishing (June 25, 2004). ISBN 90-77256-04-0.<br />
<br />
----<br />
<br />
<center>[[Team Dynamics|< Previous Article]] | [[Enabling Systems Engineering|Parent Article]] | [[Enabling Individuals|Next Article >]]</center><br />
<br />
[[Category: Part 5]][[Category:Topic]]<br />
[[Category:Enabling Systems Engineering]]<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Download_SEBoK_PDF&diff=48383
Download SEBoK PDF
2013-04-24T21:12:43Z
<p>Eleach: </p>
<hr />
<div>For those readers who would like to access the SEBoK offline, the editors have generated a set of PDFs. The first PDF listed - "SEBoK v. 1.1" - is a PDF of this version of the SEBoK. <br />
<br />
New PDFs will be generated with each minor and major refresh (e.g. versions 1.1, 1.2, 2.0, etc.). PDFs are ''not'' generated for micro releases (e.g. v. 1.0.1), as these updates are intended to be "bug fix" versions and do not change content.<br />
<br />
==Version 1.1 PDFs==<br />
<br />
In addition to the full PDF, the author team has also developed individual PDFs for each part. This will enable reviewers who are interested in viewing just one specific part easier access to the information.<br />
<br />
<font color=EE0000>NOTE: ALL LINKS NEED TO BE UPDATED - ADD Note to Community, Acknowledgements</font><br />
<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0_Final.pdf SEBoK v. 1.1]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part1_Final.pdf Part 1 - Introduction]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part2_Final.pdf Part 2 - Systems]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part3_Final.pdf Part 3 - Systems Engineering and Management]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part4_Final.pdf Part 4 - Applications of Systems Engineering]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part5_Final.pdf Part 5 - Enabling Systems Engineering]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part6_Final.pdf Part 6 - Related Disciplines]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part7_Final.pdf Part 7 - Systems Engineering Implementation Examples]<br />
<br />
==Archive==<br />
Older versions of the SEBoK are archived as PDFs. To access a previous version, please select a download link below.<br />
<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0_Final.pdf SEBoK v. 1.0]<br />
<br />
<center>'''Note: The complete SEBoK is over 850 pages and over 28 MB, so may take a considerable time to download depending on your connection speed.''' </center><br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Download_SEBoK_PDF&diff=48382
Download SEBoK PDF
2013-04-24T21:12:16Z
<p>Eleach: </p>
<hr />
<div>For those readers who would like to access the SEBoK offline, the editors have generated a set of PDFs. The first PDF listed - "SEBoK v. 1.1" - is a PDF of this version of the SEBoK. <br />
<br />
New PDFs will be generated with each minor and major refresh (e.g. versions 1.1, 1.2, 2.0, etc.). PDFs are ''not'' generated for micro releases (e.g. v. 1.0.1), as these updates are intended to be "bug fix" versions and do not change content.<br />
<br />
==Version 1.1 PDFs==<br />
<br />
In addition to the full PDF, the author team has also developed individual PDFs for each part. This will enable reviewers who are interested in viewing just one specific Part easier access to the information.<br />
<br />
<font color=EE0000>NOTE: ALL LINKS NEED TO BE UPDATED - ADD Note to Community, Acknowledgements</font><br />
<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0_Final.pdf SEBoK v. 1.1]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part1_Final.pdf Part 1 - Introduction]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part2_Final.pdf Part 2 - Systems]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part3_Final.pdf Part 3 - Systems Engineering and Management]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part4_Final.pdf Part 4 - Applications of Systems Engineering]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part5_Final.pdf Part 5 - Enabling Systems Engineering]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part6_Final.pdf Part 6 - Related Disciplines]<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0-Part7_Final.pdf Part 7 - Systems Engineering Implementation Examples]<br />
<br />
==Archive==<br />
Older versions of the SEBoK are archived as PDFs. To access a previous version, please select a download link below.<br />
<br />
*[http://www.sebokwiki.org/1.0/PDF/SEBoKv1.0_Final.pdf SEBoK v. 1.0]<br />
<br />
<center>'''Note: The complete SEBoK is over 850 pages and over 28 MB, so may take a considerable time to download depending on your connection speed.''' </center><br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=How_to_Read_the_SEBoK&diff=48380
How to Read the SEBoK
2013-04-24T21:08:26Z
<p>Eleach: </p>
<hr />
<div>The SEBoK is implemented as a ''wiki'' with more than 100 articles about various [[Systems Engineering (glossary)|systems engineering]] (SE) topics, such as [[Emergence|emergence]] and [[System Requirements|system requirements]]. Those articles are grouped into 26 knowledge areas, which are further grouped into 7 parts. The underlying engine for the SEBoK wiki, mediawiki, is the same engine used by wikipedia (see http://www.wikipedia.org), but many customizations have been made for the SEBoK. This article explains the special features of the SEBoK wiki implementation and also suggests how you can navigate the SEBoK to find SE information of interest.<br />
<br />
==Wiki Features==<br />
<br />
Most of the features of the SEBoK are self-evident to anyone familiar with normal website navigation mechanisms or who has ever used a common wiki such as wikipedia (see http://www.wikipedia.org). Nevertheless, it is worthwhile highlighting the content on the left-hand side of each page, which is always the same and always has four sections:<br />
<br />
*Quicklinks<br />
*Outline<br />
*Navigation<br />
*Toolbox<br />
<br />
<font size=3>'''Quicklinks'''</font><br />
<br />
The seven quicklinks are hotlinks that are likely to be of main interest to new SEBoK users. You are now looking at one of them, ''How to Read the SEBoK''. The purpose of most of the quicklinks is self-apparent, but of special note is [[Bkcase Wiki:Copyright|copyright information]], which explains what you may do with the information found on the SEBoK. All of the information contained in the SEBoK is copyright protected, but can be accessed and viewed without cost by anyone through the Internet. On the other hand, there are restrictions on what you can do with that information beyond access and viewing. Please look at the [[Bkcase Wiki:Copyright|Copyright Information]] article for complete information.<br />
<br />
<font size=3>'''Outline'''</font><br />
<br />
The SEBoK is divided into seven major ''parts'', each of which is further divided into ''knowledge areas''; these are in turn divided into related ''topics''. The hierarchical structure of the SEBoK is represented in the outline. Conveniently, the outline auto-expands to show the article you are currently reading.<br />
<br />
<font size=3>'''Navigation'''</font><br />
<br />
A webpage containing each of the structural elements of the SEBoK can be accessed by clicking the element name; .e.g., clicking on [[Glossary of Terms]] takes you to a webpage containing all glossary entries.<br />
<br />
<font size=3>'''Toolbox'''</font><br />
<br />
Finally, the [[Toolbox]] contains links to less commonly accessed features; e.g., as the name implies, ''What Links Here'', takes you to a webpage that shows all the other pages within the SEBoK that link to the page you were just viewing. Readers should rarely need to use the toolbox links.<br />
<br />
===Breadcrumbs===<br />
In addition to the features listed above, the wiki also contains a feature for tracking the path you navigate. As you move through the wiki, the last 5 pages you have visited will be listed at the top of the page. These "breadcrumbs" provide an easy way for you to return to articles you've recently viewed.<br />
<br />
==Finding Information==<br />
If you are new to SE, we suggest you begin by visiting Part 1, [[SEBoK v. 1.1 Introduction]]. It provides an excellent overview of the SE discipline, the history of SE, and other useful insights. Note that every topic has one or more primary references, which are those generally available readings the SEBoK authors believe have the best coverage of that topic. For example, the topic [[Systems Engineering Overview]] suggests the INCOSE Systems Engineering Handbook as an excellent introduction to SE, and the topic [[Economic Value of Systems Engineering]] recommends three articles by authors Boehm, Honour, and Valerdi as "must reads". Each primary reference has its own webpage which provides full citation information, indicates all the articles that cite it, and in many cases, elaborates on its content. You can browse through the entire set of more than 200 primary references at [[Primary References]]. Similarly, the SEBoK defines more than 350 important glossary terms, such as [[Architecture (glossary)|architecture]] and [[Verification (glossary)|verification]]. When you read an article that uses one of these terms, it will generally be a hotlink that will take you to a separate webpage which contains one or more definitions for the term, the source for each definition, and other places in the SEBoK that also link to that webpage. You can browse the entire glossary at [[Glossary of Terms]].<br />
<br />
If you are already familiar with SE and want to look for a specific topic, you have several options available. First, you can type the word or phrase in the search box at the top right hand corner of any page, hit "Go", and view the results to see where in the SEBoK you can find the sought after information. You can also use the outline structure of the SEBoK, shown on the left-hand side of every page, to select a specific part, knowledge area, or topic. Still another approach is to read the use cases called out in [[SEBoK Users and Uses]] in Part 1, which suggest ways in which you might find valuable information for different purposes.<br />
<br />
==Article Format==<br />
Each article has the same basic structure.<br />
<br />
At the top is an introduction to the article content, followed by the table of contents of the article, followed by sections containing the main body of information in the article. To promote readability, articles are generally no longer than 2000 words. Most articles contain hyperlinks to other articles, glossary terms, primary references, and even to external websites outside the SEBoK. <br />
<br />
Towards the bottom of each article are the references, which are divided into ''works cited'', ''primary references'', and ''additional references''. Works cited, as the name implies, are simply the full citations for articles, books, and websites found in the article. As described earlier, primary references are works that the SEBoK authors recommend anyone who wishes to know about the topic read. Finally, additional references are works that the SEBoK authors think are worthwhile for you to read beyond the primary references if you want to learn about the topic in greater depth. ''Works cited'' may also appear in the ''primary references'' or ''additional references,'' and when that occurs, it signals to the reader that they are encouraged to read beyond the actual cited portion of the work. Citation formats largely follow the Chicago Manual of Style; however this manual does not provide a format for citing standards. Because of this, standards are formatted as reports with the standard number replacing the report number.<br />
<br />
At the end of each article is a DISQUS segment where you can enter comments about the article, such as possible improvements or corrections or where you can simply state your opinion about what you read. Because DISQUS supports threaded comments, you can also reply to previously posted comments.<br />
<br />
You can also vote whether you ''like'' the article, using the familiar Facebook interface.<br />
<br />
The SEBoK editors will monitor all of your comments and suggestions to use when planning periodic updates to the SEBoK.<br />
<br />
==SEBoK v. 1.0.1 Discussion==<br />
Please provide your comments and feedback on SEBoK v. 1.0.1 below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account (click "DISQUS" button). Feedback will be archived and used for future updates to the SEBoK.<br />
<br />
{{#widget:DISQUS<br />
|id=sebokwiki10<br />
|uniqid={{PAGENAME}}<br />
|url={{fullurl:{{PAGENAME}}}}<br />
}}<br />
<br />
[[category:DISQUS]]</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Acknowledgements_and_Release_History&diff=48367
Acknowledgements and Release History
2013-04-24T20:41:38Z
<p>Eleach: </p>
<hr />
<div>The Guide to the Systems Engineering Body of Knowledge (SEBoK) has been, and continues to be, an immense undertaking involving the collective efforts of so many, including more than 70 authors, hundreds of reviewers, and numerous others, including: associate editors, assistant editors, technical editors, governors, wiki implementers, and graphical artists.<br />
<br />
We acknowledge their contributions, <br />
<br />
<blockquote>With gratitude,</blockquote><br />
<br />
[[File:EditorsinChiefSignatures.png||center|400px]]<br />
<br />
==BKCASE==<br />
<br />
The SEBoK was developed by the Body of Knowledge and Curriculum to Advance Systems Engineering Project (BKCASE) (http://www.bkcase.org), which concurrently produced the Graduate Reference Curriculum for Systems Engineering (GRCSE). Nearly everyone involved in BKCASE has contributed to both products. Hence, the acknowledgements generally do not distinguish between contributions to SEBoK and GRCSE.<br />
<br />
==Original Sponsor==<br />
<br />
The Department of Defense (DoD) recognizes the importance of SEBoK to its own workforce development and has provided substantial financial support and partnership to the BKCASE project. The office of the Deputy Assistant Secretary of Defense for Systems Engineering (DASD(SE)) is the original Department of Defense sponsor for the BKCASE Project. DASD(SE) graciously provided much of the funding for SEBoK development through their Systems Engineering Research Center (SERC) (see http://www.sercuarc.org). Those funds have primarily paid for the time spent by the SEBoK leadership, enabled the many volunteer authors to conduct quarterly physical workshops, and provided for the technical and administrative infrastructure to conduct such a complex distributed project. DASD(SE) has not determined the content of the SEBoK, but instead has allowed the author team and the community to determine what the SEBoK should contain. Without this support over the life of the project, the creation of the SEBoK would not have been possible. Moreover, DASD(SE) continues to provide substantial support to BKCASE through the SERC. Special thanks go to Stephen Welby, Kristen Baldwin, Nicholas Torelli, Don Gelosh, Scott Lucero, and Darren Dusza. <br />
<br />
''This material is based upon work supported, in whole or in part, by the U.S. Department of Defense through the Systems Engineering Research Center (SERC) under Contract H98230-08-D-0171. SERC is a federally funded University Affiliated Research Center managed by Stevens Institute of Technology. Any opinions, findings, conclusions, or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense.''<br />
<br />
==New Governance==<br />
<br />
Beginning in January of 2013, the SEBoK began operating under a new governance structure, led by INCOSE, IEEE-CS, and the SERC acting jointly as stewards. Under this new structure, the Editor-in-Chief and Co-Editor-in-Chief lead the newly formed BKCASE Editorial Board, which is responsible for soliciting new and revised SEBoK articles, and ensuring those articles are peer-reviewed and meet the quality standards expected of all SEBoK articles. The associate editors quickly became integral to the SEBoK 1.1 release and we thank them for their leadership and dedication.<br />
<br />
*Rick Adcock, ''Cranfield University''<br />
*Barry Boehm, ''University of Southern California''<br />
*Cihan Dagli, ''Missouri University of Science and Technology''<br />
*Judith Dahmann, ''MITRE''<br />
*Heidi Davidz, ''Pratt and Whitney Rocketdyne''<br />
*Dov Dori, ''Technion Israel Institute of Technology''<br />
*Tim Ferris, ''University of South Australia''<br />
*Greg Parnell, ''United States Military Ac<br />
*Sam Seymour, ''Johns Hopkins University''<br />
*Ariela Sofer, ''George Mason University''<br />
*Ricardo Valerdi, ''University of Arizona''<br />
<br />
The stewards also set up the BKCASE Governing Board to be their primary agents to oversee and guide the SEBoK and its companion BKCASE product, the GRCSE.<br />
<br />
*Richard Fairley, ''IEEE Computer Society''<br />
*Kevin Forsberg, ''INCOSE''<br />
*Ken Nidiffer, ''IEEE Computer Society''<br />
*David Olwell, ''SERC''<br />
*Art Pyster, ''SERC''<br />
*David Walden, ''INCOSE''<br />
<br />
The core staff (except for Alice Squires, who has taken a new position), who are central to SEBoK development, became assistant editors in the new governance structure. They have been and continue to be the bedrock on which the entire SEBoK effort rests.<br />
<br />
*Stephanie Enck, ''Naval Postgraduate School''<br />
*Devanandham Henry, ''Stevens Institute of Technology''<br />
*Nicole Hutchison, ''Stevens Institute of Technology''<br />
<br />
Finally, special thanks go out to INCOSE Presidents, Samantha Robitaille and John Thomas, for their early and constant support to the SEBoK development.<br />
<br />
==Part Team Leads==<br />
<br />
The SEBoK is divided into seven primary ''Parts'' (see [[SEBoK Table of Contents]]). Through the release of SEBoK 1.0, for each of the Parts, someone graciously volunteered to lead a team of authors in writing the articles and coordinating article integration. This was an enormous amount of work. We would like to thank each of these individuals for their time, dedication, and leadership. In addition, a member of the editorial staff supported each of the part team leads.<br />
<br />
* Part 1 - Barry Boehm with support from Art Pyster<br />
* Part 2 - Richard Adcock with support from Nicole Hutchison<br />
* Part 3 - Garry Roedler with support from Jim Anthony<br />
* Part 4 - Harold (Bud) Lawson with support from David Olwell<br />
* Part 5 - Art Pyster with support from Alice Squires and Devanandham Henry<br />
* Part 6 - David Olwell with support from Art Pyster<br />
* Part 7 - Heidi Davidz with support from Alice Squires and Devanandham Henry<br />
<br />
==Authors==<br />
<br />
As a primarily volunteer effort, BKCASE has depended on dozens of authors from around the world to provide their own time and expenses. Each of the individuals listed below has worked many hours to develop and improve SEBoK and GRCSE. Without each of them, it would have been impossible to succeed. Many of them have been supported by their organizations during this effort, including support for travel and labor, and we also gratefully acknowledge the organizational contribution. <br />
<br />
<center><br />
{|<br />
|+ '''Table 1. BKCASE Authors.''' (SEBoK Original) <br />
|-<br />
!Author<br />
!Author<br />
|-<br />
|Richard Adcock, ''Cranfield University and INCOSE, UK <br />
|Mo Jamshidi, ''University of Texas San Antonio, USA <br />
|-<br />
|James F. Anthony, Jr., ''Sevatec, Inc., USA <br />
|Cheryl Jones, ''United States Army, USA<br />
|-<br />
|Erik Aslaksen, ''Sinclair Knight Merz, Australia <br />
|Chul Whan Kim, ''Advisor of KCOSE, Korea<br />
|-<br />
|Richard Beasley, ''Rolls Royce, UK <br />
|Naohiko Kohtake, ''KEIO University, Japan<br />
|-<br />
|Barry Boehm, ''University of Southern California, USA <br />
|Harold (Bud) Lawson, ''Lawson Konsult AB, Sweden<br />
|-<br />
|Stuart Booth, ''Office of the Secretary of Defense, USA <br />
|Yeaw Lip Alex Lee, ''Defence Science and Technology Agency, Singapore<br />
|-<br />
|John Brackett, ''Boston University, USA <br />
|Ray Madachy, ''Naval Postgraduate School, USA<br />
|-<br />
|Chuck Calvano, ''Naval Postgraduate School, USA <br />
|James Martin, ''The Aerospace Corporation, USA<br />
|-<br />
|Aaron Eng Seng Chia, ''National University of Singapore, Singapore <br />
|Gregory Mayhew, ''Boeing, USA<br />
|-<br />
|Kyung-il Choe, ''HUFS, Korea <br />
|Steven Mitchell, ''Lockheed Martin, USA<br />
|-<br />
|Edmund Conrow, ''Management and Technology Associates, USA<br />
|Ken Nidiffer, ''Carnegie Mellon SEI and IEEE Systems Council, USA<br />
|-<br />
|Paul Croll, ''CSC, USA <br />
|David H. Olwell, ''Naval Postgraduate School, USA<br />
|-<br />
|Cihan Dagli, ''Missouri University of Science and Technology, USA <br />
|Bo Oppenheim, ''Loyola Marymount University, USA<br />
|-<br />
|Judith Dahmann, ''The MITRE Corporation, USA <br />
|Gregory Parnell, ''United States Military Academy, USA<br />
|-<br />
|Heidi Davidz, ''Pratt & Whitney Rocketdyne, USA <br />
|Andy Pickard, ''Rolls-Royce, USA<br />
|-<br />
|Leopoldo Decardenas, ''Raytheon, USA <br />
|Ricardo Pineda, ''University Texas at El Paso, USA<br />
|-<br />
|Johann (Hans) Demmel, ''Raytheon, USA <br />
|Daniel Prun, ''Ecole Nationale de l'Aviation Civile (ENAC), France<br />
|-<br />
|Jeremy Dick, ''Integrate Systems Engineering Ltd., USA <br />
|Art Pyster, ''Stevens Institute of Technology, USA<br />
|-<br />
|Charles Dickerson, ''Loughborough University, UK <br />
|Garry Roedler, ''Lockheed Martin, USA<br />
|-<br />
|David Dorgan, ''Raytheon, USA <br />
|Jean-Claude Roussel, ''EADS, France<br />
|-<br />
|style="width: 50%"|Dov Dori, Technion, ''Israel Institute of Technology, Isreal and Massachusetts Institute of Technology, USA <br />
|Samuel Seymour, ''Johns Hopkins University, USA<br />
|-<br />
|Joseph J. Ekstrom, ''Brigham Young University, USA <br />
|Seiko Shirasaka, ''KEIO University, Japan<br />
|-<br />
|Stephanie Enck, ''Naval Postgraduate School, USA <br />
|Hillary Sillitto, ''Thales Group and INCOSE, UK<br />
|-<br />
|Marcia Enos, ''Lockheed Martin, USA <br />
|Janet Singer, ''International Society for the Systems Sciences, USA<br />
|-<br />
|Dick Fairley, ''Observer and Author from IEEE, USA <br />
|John Snoderly, ''Defense Acquisition University, USA<br />
|-<br />
|Alain Faisandier, ''Association Francaise d 'Ingenlerie Systeme, France <br />
|Ariela Sofer, ''George Mason University, USA<br />
|-<br />
|T.L.J. Ferris, ''University of South Australia and INCOSE, Australia <br />
|Alice Squires, ''Stevens Institute of Technology, USA<br />
|-<br />
|Kevin Forsberg, ''OGR Systems, USA <br />
|Bill Stiffler, ''Raytheon, USA<br />
|-<br />
|G. Richard Freeman, ''Air Force Institute of Technology, USA<br />
|Massood Towhidnejad, ''Embry-Riddle Aeronautical University, USA<br />
|-<br />
|Sanford Friedenthal, ''SAF Consulting, Lockheed Martin (retired), USA <br />
|Guilherme Horta Travassos, ''Universidade Federal do Rio de Janeiro (UFRJ), Brazil<br />
|-<br />
|Brian Gallagher, ''CACI, USA <br />
|Ricardo Valerdi, ''University of Arizona, USA<br />
|-<br />
|Devanandham Henry, ''Stevens Institute of Technology, USA <br />
|Mary VanLeer, ''Perceptive Systems, Inc., USA<br />
|-<br />
|Michael Henshaw, ''Loughborough University, UK <br />
|Qing Wang, ''Institute of Software Chinese Academy of Sciences, China<br />
|-<br />
|Thomas Hilburn, ''Embry-Riddle Aeronautical University and IEEE Computer Society, USA <br />
|Brian Wells, ''Raytheon, USA (retired)<br />
|-<br />
|Nicole A.C. Hutchison, ''Stevens Institute of Technology, USA<br />
|Brian White, ''CAU<SES, USA<br />
|-<br />
|Duane Hyberston, ''The MITRE Corporation, USA <br />
|Ken Zemrowski, ''TASC, Inc., USA<br />
|-<br />
|Scott Jackson, ''University of Southern California, USA <br />
|<br />
|}<br />
<br />
</center><br />
<br />
==Partners==<br />
<br />
Partner organizations supported the development of the SEBoK by providing personnel and opportunities to discuss the SEBoK in open forums such as conferences and workshops, and providing valued feedback on draft SEBoK materials. Some organizations have also chosen to have an official representative(s) participate in BKCASE, as shown below. A special thanks to our partners.<br />
<br />
* [http://iienet.org The Institute of Industrial Engineers (IIE).] The official IIE representative was Johann "Hans" Demmel.<br />
* [http://www.acm.org The Association for Computing Machinery (ACM)]. The official ACM Representative was Andrew McGettrick.<br />
* [http://www.ndia.org/Divisions/Divisions/SystemsEngineering/Pages/default.aspx The National Defense Industrial Association (NDIA) Systems Engineering Division]. The official NDIA Systems Engineering Division representative was Garry Roedler.<br />
<br />
In addition, most authors came from organizations that, although not officially affiliated with BKCASE, nevertheless supported author time and expenses to participate. Collectively, those organizations provided the majority of the labor and expenses that went into creating the SEBoK.<br />
<br />
==Wiki Team==<br />
<br />
The transition from a traditional document to a wiki-based platform was a long one. We are tremendously grateful to the folks who have helped us install, manage, and update the wiki:<br />
<br />
*Nicole Hutchison (team lead), Stevens Institute of Technology<br />
*Stephanie Enck (co-lead), Naval Postgraduate School<br />
*Devanandham Henry, Stevens Institute of Technology<br />
*Hans-Peter de Koning, European Space Agency<br />
*Paola Di Maio, University of Strathclyde<br />
*Ray Jorgensen, Rockwell Collins<br />
*Sanford Friedenthal, SAF Consulting<br />
*Jude Ken-Kwofie, Stevens Institute of Technology<br />
*Steven Mitchell, Lockheed Martin<br />
*Robin Valeson, Stevens Institute of Technology<br />
<br />
The wiki is currently supported and hosted by Stevens Institute of Technology. Special thanks go to the Stevens' IT organization.<br />
<br />
==Technical Editors==<br />
Every article went through rounds of technical editing to improve writing quality and consistency. Thanks go to:<br />
<br />
*Emily Leach<br />
*Abraham Raher<br />
*Renee Malove<br />
*Justin Gercken<br />
*Dona Lee<br />
<br />
==Participants==<br />
The following individuals have provided support to the BKCASE team over the course of the project:<br />
<br />
*Johann Amsenga<br />
*John Baras<br />
*Johan Bendz<br />
*Stuart Booth<br />
*Dan Cernoch<br />
*Richard Frost<br />
*Edward Ghafari<br />
*Mike Gourley<br />
*Richard Gryzbowski<br />
*Peter Jackson<br />
*Kenneth Kepchar<br />
*Mike Kreuger<br />
*JoAnn Lane<br />
*Richard Rosenthal<br />
*Sven-Olaf Schulze<br />
*Robert (Bob) Shishko<br />
*Mary Jane Willshire<br />
<br />
==Reviewers==<br />
Reviewers are critical to the success and growth of the SEBoK. By providing feedback that represents the diversity of views and opinions on systems engineering, reviewers help the author team identify and describe ground truths for SE as well as areas of contention. The reviewers who provided feedback for earlier versions (0.25, 0.50, and 0.75) are listed in Table 2, below. In addition, there are a number of ''other'' reviewers who provided their comments directly on the wiki with only a user ID (and not a full name) and reviewers who were part of a group that provided a collective review; these reviewers are not listed in Table 2 below. Many thanks to all reviewers!<br />
<br />
The author team would like to particularly acknowledge the efforts of several INCOSE working groups (WGs) who provided feedback:<br />
* Systems Science WG<br />
* Architecture WG<br />
* Requirements WG<br />
* Decision Analysis WG<br />
* In Service WG<br />
* Lean Systems Engineering WG<br />
* System of Systems WG<br />
* Process Improvement WG<br />
<br />
The adjudication of all SEBoK review comments for all versions can be found at [[SEBoK Review and Adjudication]].<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Reviewers of earlier SEBoK versions.''' (SEBoK Original)<br />
|-<br />
!Reviewer<br />
!Reviewer<br />
|-<br />
|Aase Jakobsson<br />
|Johnny Duckworth, ''Space & Airborne Systems/Systems Development Center<br />
|-<br />
|Ada Hunter, ''Lockheed Martin<br />
|Jose Luis Fernandez Sanchez, ''Madrid Technical University (UPM)<br />
|-<br />
|Adeel Khalid, ''Southern Polytechnic State University<br />
|Julie DeMeester, ''Raytheon<br />
|-<br />
|Alan D Harding, ''BAE Systems<br />
|Julie P. Gann, ''Northrop Grumman Information Systems<br />
|-<br />
|Alan Knott, ''Parsons Brinckerhoff<br />
|Kal Toth, ''Portland State University<br />
|-<br />
|Ali Bahraman, ''Raytheon<br />
|Karen Charron, ''Raytheon<br />
|-<br />
|Andrew Farncombe, ''John Boardman Associates<br />
|Karl Best, ''Project Management Institute<br />
|-<br />
|Andrew McGettrick, ''The Association for Computing Machinery (ACM)<br />
|Ken Ellis, ''Northrop Grumman Aerospace Systems<br />
|-<br />
|Anne Sigogne, ''THALES<br />
|Kenneth Morris<br />
|-<br />
|Annette Reilly, ''Lockheed Martin<br />
|Krister Sutinen, ''Siemens Industry Software AB<br />
|-<br />
|Arnold Neville Pears, ''Uppsala University<br />
|Lajuane Brooks, ''Aurora Sciences<br />
|-<br />
|Bart Terrery, ''Lockheed Martin<br />
|Larri Rosser, ''Raytheon IIS<br />
|-<br />
|Berger, ''Northrop Grumman Corporation<br />
|Laurie Nasta, ''Booz Allen Hamilton<br />
|-<br />
|Bernadette Gasmi, ''EADS Airbus<br />
|Lori Zipes, ''NAVSEA NSWC Panama City Division (US Dept of Navy)<br />
|-<br />
|Beth Wilson, ''Raytheon<br />
|Lou Oddo, ''Northrop Grumman Aerospace Systems<br />
|-<br />
|Bob Epps and a consolidated review, ''Lockheed Martin<br />
|Louisa Guise, ''Raytheon<br />
|-<br />
|Bobinis, ''Lockheed Martin<br />
|M.T.F.M. van de Ven, ''INCOSE ISSWG<br />
|-<br />
|Bruce Elliott, ''Arbutus Technical Consulting<br />
|Marcel van de Ven, ''Movares Nederland b.v.<br />
|-<br />
|Bruce Munro, ''Raytheon Space and Airborne Systems<br />
|Mark Ardis, ''Stevens Institute of Technology<br />
|-<br />
|Bryan E. Herdlick, ''Applied Physics Laboratory, Johns Hopkins University<br />
|Mark Maier, ''The Aerospace Corporation<br />
|-<br />
|Chia Eng Seng Aaron, ''National University of Singapore<br />
|Martin Nazareth<br />
|-<br />
|Curt Zielinski, ''Lockheed Martin<br />
|Matthew Petty<br />
|-<br />
|Dahai Liu, ''Embry-Riddle Aeronautical University<br />
|Michael Bisconti, ''Lockheed Martin<br />
|-<br />
|Dan Dillery<br />
|Michael C. Dapp, ''Lockheed Martin MS2<br />
|-<br />
|Daniel J Dechant, ''Raytheon<br />
|Michael Coughenour, ''Lockheed Martin<br />
|-<br />
|Daniel Mulvihill, ''Pratt & Whitney Rocketdyne<br />
|Michael O'Neill, ''Georgia Tech Research Institute<br />
|-<br />
|David D. Walden, ''INCOSE & Sysnovation LLC<br />
|Michael Ryan, ''INCOSE Requirements Working Group<br />
|-<br />
|David Kraus, ''Northrop Grumman Electronic Systems<br />
|Michael Wilkinson, ''Niteworks/Atkins<br />
|-<br />
|David Mason, ''Lockheed Martin<br />
|Michaelson, ''Lockheed Martin<br />
|-<br />
|David Quastel<br />
|Michele Hanna, ''Lockheed Martin<br />
|-<br />
|David Yarbrough, ''Northrop Grumman Corporation<br />
|Mike Gayle, ''Boeing<br />
|-<br />
|Dawn Sabados, ''University of Alabama Huntsville<br />
|Mike O’Neill, ''Georgia Tech Research Institute<br />
|-<br />
|Denis Bertrand & others, ''Department of National Defence<br />
|Mike Prendergast<br />
|-<br />
|Dennis Moen, ''Lockheed Martin<br />
|Mike Stemig, ''Raytheon<br />
|-<br />
|Donald Larson<br />
|Mike Yokel, ''Lockheed Martin<br />
|-<br />
|Donald Robertson, ''Lockheed Martin MS2<br />
|Nelson Roberts, ''Lockheed Martin<br />
|-<br />
|Duncan Kemp, Department for Transport<br />
|Odile Mornas, ''Thales Université<br />
|-<br />
|Jon Holt, ''Atego<br />
|Paola Di Maio, ''University of Strathclyde<br />
|-<br />
|Karen J Richter, ''Institute for Defense Analyses<br />
|Patra Stroemer, ''Lockheed Martin<br />
|-<br />
|Stan Rifkin, ''Stevens Institute of Technology<br />
|Paul Joannou, ''IEEE Computer Society<br />
|-<br />
|Edmond Tonnellier, ''Thales<br />
|Paul Martellock, ''LMT<br />
|-<br />
|Emile Anderson, ''Raytheon IDS<br />
|Peter Brook, ''Dashwood Consulting Ltd<br />
|-<br />
|Francis M. Joyner, ''Raytheon<br />
|Pieter Botman, ''Independent<br />
|-<br />
|Frédéric Autran, ''EADS - Cassidian Systems<br />
|Ian Sommerville, ''University of St. Andrews<br />
|-<br />
|Gauthier Fanmuy, ''AND<br />
|Richard Rifelli, ''Northrop Grumman Corporation<br />
|-<br />
|George Rebovich, ''MITRE<br />
|Rob Schaaf, ''IEEE<br />
|-<br />
|Gerald H. Fisher<br />
|Robert Cantrell, ''Raytheon IDS<br />
|-<br />
|Gerard Auvray, ''Astrium Satellite<br />
|Robert Mottl, ''NGAS<br />
|-<br />
|Gilles Meuriot, ''AREVA TA<br />
|Robert Rathbone, ''EADS - Cassidian Systems<br />
|-<br />
|Gorman Findley, ''Raytheon<br />
|Roddey Smith, ''NGC/NGAS/AMS/CWIN<br />
|-<br />
|Greg Brown, ''Lockheed Martin<br />
|Roger C. Pare, ''Lockheed Martin MS2<br />
|-<br />
|Hagar, ''Lockheed Martin<br />
|Rolan Mazzella, ''Thales<br />
|-<br />
|Hans van Vliet, ''VU University, Amsterdam<br />
|Ronald Fradenburg, ''Ingalls Shipbuilding<br />
|-<br />
|Harold Baker<br />
|Roxann Marumoto, ''Raytheon<br />
|-<br />
|Harold Mooz, ''HMA<br />
|Scott Werner, ''Honeywell Technology Services Inc.<br />
|-<br />
|Howard Eisner, ''George Washington University<br />
|Shirley Tseng<br />
|-<br />
|Hubert Ernest Cody, ''Raytheon<br />
|Spurge Norman, ''MITRE<br />
|-<br />
|IEEE Computer Society (collective review)<br />
|Stephanie White, ''Long Island University, C.W. Post Campus<br />
|-<br />
|Ivan Mactaggart, ''AWE PLC<br />
|Stephen Townsend, ''PMI<br />
|-<br />
|Jack Ring, ''Educe LLC<br />
|Susan Ferreira, ''University of Texas at Arlington<br />
|-<br />
|Jaluane Brooks, ''Aurora Sciences<br />
|Susan Murray, ''Missouri S&T<br />
|-<br />
|James J. Peter, ''Johns Hopkins University<br />
|Theodora Saunders, ''IEEE AES, IEEE Sys Council, AHS<br />
|-<br />
|James Jamison, ''IBM<br />
|Thomas Tudron, ''Lockheed Martin<br />
|-<br />
|James Lentz, ''Northrop Grumman Corporation<br />
|Timothy W. Lohr, ''Lockheed Martin MS2<br />
|-<br />
|James van Gaasbeek, ''Northrop Grumman Aerospace Systems<br />
|Velda G. Musgrove, ''Lockheed Martin MS2<br />
|-<br />
|Jay Mandelbaum, ''Institute for Defense Analyses<br />
|Vidyut Navelkar, ''Tata Consultancy Services Ltd.<br />
|-<br />
|Jean-luc Garnier<br />
|Vincenzo Arrichiello, ''SELEX Sistemi Integrati SpA<br />
|-<br />
|Jean-Luc Wippler, ''LUCA Ingénierie<br />
|Wayne Collier, ''Siemens PLM Software<br />
|-<br />
|Jeff Lankford, ''The Aerospace Corporation<br />
|Wayne O’Brien, ''Raytheon<br />
|-<br />
|Jennifer Milligan, ''Lockheed Martin MS2<br />
|Weaver, ''Lockheed Martin<br />
|-<br />
|Jeremy I. Stuart, ''Boeing<br />
|William Ely<br />
|-<br />
|JG Demmel, ''Raytheon<br />
|William Golaz, ''Lockheed Martin Aeronautics<br />
|-<br />
|Jim Smith, ''Lockheed Martin<br />
|William J. Brocker, ''Brocker Engineering<br />
|-<br />
|Joan E. Nolan, ''Northrop Grumman Corporation<br />
|William Moore, ''Northrop Grumman Corporation<br />
|-<br />
|JoAnn Lane<br />
|William R. Lyders, ''ASSETT Inc.<br />
|-<br />
|John Clark, ''Northrop Grumman Corporation and INCOSE<br />
|Yoshihiro Matsumoto, ''ASTEM Research Institute<br />
|-<br />
|John Harauz, ''Jonic Systems Engineering<br />
|Yvonne Simms, ''Boeing<br />
|-<br />
|John R Tubb<br />
|<br />
|-<br />
|}<br />
</center><br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Editor%27s_Corner&diff=48355
Editor's Corner
2013-04-24T18:10:00Z
<p>Eleach: </p>
<hr />
<div>===History, Motivation, and Value===<br />
The Body of Knowledge and Curriculum to Advance Systems Engineering Project (BKCASE) began to create a community-based ''Guide to the Systems Engineering Body of Knowledge (SEBoK)'' and a ''Graduate Reference Curriculum for Systems Engineering (GRCSE)'' in fall of 2009 (Pyster and Olwell et al. 2012) (Please see http://www.bkcase.org for more information). The SEBoK came into being out of a recognition that the systems engineering (SE) discipline could benefit greatly by having a living authoritative guide that discusses what is included in the discipline, how the discipline should be structured to facilitate understanding, and what documents are the most important to the discipline. A key principle of the BKCASE project is that the SEBoK and GRCSE will always be available free worldwide – including the revisions to those products. <br />
<br />
Through the end of 2012, BKCASE was led by Stevens Institute of Technology and the Naval Postgraduate School in coordination with several professional societies and sponsored by the U.S. Department of Defense (DoD), which provided generous funding. Volunteers from dozens of companies, universities, and professional societies across 10 countries contributed many thousands of hours writing the SEBoK articles; their organizations provided significant other contributions in-kind. For additional information on the BKCASE authors, please see the [[Acknowledgements]] article.<br />
<br />
The scale and complexity of BKCASE emerged over the first few months of the project. Systems engineering is large and relatively immature when compared to more classic engineering disciplines, such as electrical and mechanical engineering. We are extremely pleased with how the community rose to the challenge. New authors continually stepped up when gaps in the writing team were identified and we routinely assembled 25 to 30 authors every three months in a multi-day workshop to iron out issues and make key decisions. <br />
<br />
One of the most critical decisions occurred in January 2011, when the team confirmed a switch to a wiki-based presentation for the body of knowledge. This added much complexity to the effort, but offered great advantages in terms of the modularity for update, access to interim material by the authors, easy review and suggestions for improvements, and flexible navigation. In hindsight, the impact of choosing a wiki was much greater than we understood, but we are very happy we went down that path. We believe this format to present the body of knowledge will serve the SE community much better than if we had produced a traditional PDF or Word document.<br />
<br />
To help ensure both the quality of the SEBoK and its acceptance by the community, it was vital that the SEBoK be created with an open collaborative process. Specifically, each version had public review and each review comment was adjudicated. The adjudication results can be found at [[SEBoK Review and Adjudication]].<br />
<br />
The earliest value of the SEBoK has simply been the greater sense of community that has developed among the authors, which include many fellows of professional societies and other leaders in the field. For example, the relationship between Systems Science and Systems Engineering is now more clearly understood than in the past. This relationship is captured in Parts 2 and 3 of the SEBoK. <br />
<br />
The greater value of the SEBoK, of course, comes from use by the community. As of the end of March 2013, SEBoK articles have been accessed more than 100,000 times and early usage reports are encouraging. We hope the SEBoK will regularly be used by thousands of systems engineers around the world as they undertake such activities as creating systems architectures, developing career paths for systems engineers, and deciding new curricula for systems engineering university programs. <br />
<br />
The SEBoK is intended to evolve and morph with use and with changes in the field. The wiki structure is particularly well-suited for promoting that purpose. Users are asked to comment about what they like and dislike, what is missing and what should be removed. New articles will be added and existing articles updated regularly. <br />
<br />
At the beginning of 2013, with version 1.0 of both SEBoK and GRCSE released, BKCASE transitioned to a new governance model with shared stewardship between the Systems Engineering Research Center (SERC) (see http://www.sercuarc.org), the International Council on Systems Engineering (INCOSE) (see http://www.incose.org), and the Institute of Electrical and Electronics Engineers Computer Society (IEEE-CS) (see www.computer.org). This new governance structure is being formalized in an agreement between the three stewards that will be finalized in spring of 2013. The stewards have reconfirmed their commitment to the key principle that SEBoK and GRCSE will be available at no cost to the users.<br />
<br />
===Version 1.1===<br />
This version, released 30 April 2013, is a minor release which updates many topic articles and glossary articles.<br />
<br />
Changes that have been made include:<br />
* Fourteen topic articles were updated in Parts 1, 2, 3, and 6, for the purpose of expanding or improving the explanation of the topic, or in some cases to add new references. <br />
* Sixteen glossary terms were updated and two new glossary terms were added.<br />
* The [[Acknowledgements]] page was updated to reflect the significantly revised governance structure for the SEBoK, which added many new contributors in varying roles. <br />
* The [[Main Page]] and other Quicklinks pages have been modified to reflect the new version.<br />
* The SEBoK Evolution article formerly in [[SEBoK v. 1.1 Introduction]] was deleted, being replaced by an updated version, being this Editor's Note article.<br />
<br />
There were no changes to improve wiki navigation and operation. Comments from version 1.0.1 that were adjudicated were deleted from DISQUS, while comments still to be adjudicated remain in the wiki.<br />
<br />
===Upcoming Releases===<br />
<br />
We will regularly update the SEBoK to correct errors, improve existing articles, add new articles, and respond to specific comments from the user community. The current plan is to issue occasional micro updates and two minor updates a year for the first two years, and then decide whether a larger more major revision is needed in the third year or whether additional micro and minor revisions are adequate. Micro updates correct spelling errors and sentence grammar and make other very modest changes and occur as needed. They are identified by three digits - Version 1.x.y. Version 1.0.1 was the first micro release. Minor updates will correct errors, continue to add content to existing articles, including any new references published recently, and perhaps add articles to existing knowledge areas. Minor updates will not change the basic organization of the SEBoK. The editors may not respond to all comments posted in DISQUS for the minor updates. This release, Version 1.1, is the first minor update. Major updates will be unconstrained. All accumulated comments and suggestions will be adjudicated for the major updates, and the adjudication results will be posted for the community.<br />
<br />
New releases are under the control of a Governing Board appointed by the stewards, who oversee the SEBoK Editor-in-Chief, Co-Editor-in-Chief, and an Editorial Board. The stewards contribute resources to manage the SEBoK wiki, support new releases, and encourage SEBoK adoption. Volunteer authors from the world-wide SE community continue to propose and create new content and other volunteers review that new content.<br />
<br />
The next minor release will be Version 1.2, currently scheduled for release in October 2013. At least one new article on ''Systems Engineering Education'' will be included in Part 5, but we suspect several more new articles will be included as well. The editors also plan to have implemented the process for updating references systematically, and intend to include references published since version 1.0, as appropriate to each article.<br />
<br />
===Sandbox===<br />
<br />
The SEBoK is sometimes compared to Wikipedia. The SEBoK is like Wikipedia in its most fundamental structure, as it is a collection of wiki articles built on mediawiki technology. However, SEBoK is unlike Wikipedia in that the SEBoK's content is carefully controlled. Anyone in the community can suggest changes be made to SEBoK articles, but no one except the SEBoK Editors can actually implement those changes. Wikipedia is a much more open wiki, allowing virtually anyone to change any article, while reserving the right to undo changes that are offensive or otherwise violate Wikipedia's rules.<br />
<br />
Tight control over SEBoK content is a tradeoff. Such control ensures a stable baseline whose quality and integrity are assured by its editors. On the other hand, such control discourages some members of the community from contributing improvements to the SEBoK. To satisfy both the need for a stable baseline and the desire for broader community involvement, we will be implementing a new feature sometime in the next several months. The ''Sandbox'' will be copy of the SEBoK, separate from the baseline version, where anyone in the community can edit articles. The exact rules for how this will be done are being decided now and will be announced in a micro release of the SEBoK as well as through other venues.<br />
<br />
[[File:EditorsinChiefSignatures.png||center|400px]]<br />
<br />
<br />
<center><br />
{|<br />
|-<br />
|style="background-color: #ffffff"|[[File: Stevens.jpg|300px|center|Stevens Institute of Technology]] |<br />
|style="background-color: #ffffff"|[[File:Systems_Engineering_Logo_r3.JPG|552px|center|Naval Postgraduate School's Systems Engineering Department]]<br />
|}<br />
</center><br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK)&diff=48343
Guide to the Systems Engineering Body of Knowledge (SEBoK)
2013-04-24T17:37:17Z
<p>Eleach: </p>
<hr />
<div>__NOTOC__<br />
<html><br />
<meta name="citation_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK) v. 1.1"><br />
<meta name="citation_author" content="Pyster, Art"><br />
<meta name="citation_author" content="Olwell, David H."><br />
<meta name="citation_author" content="Hutchison, Nicole"><br />
<meta name="citation_author" content="Enck, Stephanie"><br />
<meta name="citation_author" content="Anthony, James F., Jr."><br />
<meta name="citation_author" content="Henry, Devanandham"><br />
<meta name="citation_author" content="Squires, Alice (eds)"><br />
<meta name="citation_publication_date" content="2012/11/30"><br />
<meta name="citation_journal_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK)"><br />
<meta name="citation_volume" content="version 1.0.1"><br />
<meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page"></html><br />
<br />
<center><br />
<html><br />
<font size=3>Please note that this is the access area for the development of SEBoK v. 1.1. To view the current published version of the SEBoK (v. 1.0.1), please go to <a href="www.sebokwiki.org/1.0.1/">www.sebokwiki.org/1.0.1/</a>. <b>If you are a BKCASE editor, please log in.</b> If you have any questions, please contact us at <a href="mailto:bkcase@stevens.edu">bkcase@stevens.edu</a>.<br />
</font><br />
</html><br />
</center><br />
<br />
<br />
==Welcome==<br />
On behalf of [[Acknowledgements|the more than 70 authors]], the editors, and the three SEBoK steward organizations – the International Council on Systems Engineering (INCOSE), the Institute of Electrical and Electronics Engineers Computer Society (IEEE-CS), and the Systems Engineering Research Center (SERC) – welcome to the ''Guide to the Systems Engineering Body of Knowledge (SEBoK)'' version 1.1. This version was released 30 April 2013, and contains [[Release History|a number of changes]] and additions to version 1.0.1, which was released in November 2012.<br />
<br />
The SEBoK provides a compendium of the [[Primary References|key knowledge sources and references]] of systems engineering, organized and explained to assist a wide variety of users. It is a living document, accepting [[SEBoK Review and Adjudication |community input]] continuously, and [[Editors' Note|regularly refreshed and updated]].<br />
<br />
==About Systems Engineering== <br />
<br />
[[Systems Engineering (glossary)|Systems engineering]] is an interdisciplinary approach and means to enable the realization of successful systems. Separate articles in [[SEBoK v. 1.1 Introduction|Part 1]] provide an [[Systems Engineering Overview|overview of systems engineering]], place it in [[Systems Engineering: Historic and Future Challenges|historical context]], and discuss its [[Economic Value of Systems Engineering| economic value]].<br />
<br />
Systems engineering has roots in [[Systems |systems science]]. Major sections (called knowledge areas (KAs)) in [[Systems |Part 2]] discuss [[Systems Fundamentals]], [[Systems Thinking]], [[Representing Systems with Models]], and the [[Systems Approach Applied to Engineered Systems]].<br />
<br />
==About the SEBoK==<br />
The SEBoK is organized into [[SEBoK Table of Contents|7 parts]], with a [[Glossary of Terms]] and a list of [[Primary References]]. <br />
<br />
* [[SEBoK v. 1.1 Introduction|Part 1]] discusses the [[Scope of the SEBoK]], and its [[Structure of the SEBoK|structure]], including its hierarchy of parts, [http://www.sebokwiki.org/1.0/index.php/Category:Knowledge_Area knowledge areas], and [http://www.sebokwiki.org/1.0/index.php/Category:Topic topics]. Part 1 also includes a lengthy discussion of [[SEBoK Users and Uses]], including five [http://www.sebokwiki.org/1.0/index.php/Category:Use_Case use cases]. <br />
<br />
The other parts include: <br />
* Part 2 [[Systems]]<br />
* Part 3 [[Systems Engineering and Management]]<br />
* Part 4 [[Applications of Systems Engineering]]<br />
* Part 5 [[Enabling Systems Engineering]]<br />
* Part 6 [[Related Disciplines]]<br />
* Part 7 [[Systems Engineering Implementation Examples]]<br />
<br />
As a compendium, much of the content has restricted intellectual property rights. This [[Bkcase Wiki:Copyright |copyright information]] is placed on each page, and must be respected. The SEBoK copyright is held by the Trustees of the Stevens Institute of Technology, and plans for the transfer of the copyright are discussed in the [[Editors' Note]].<br />
<br />
As a living document, at the bottom of each page, version identification can be found in a link called "[[About SEBoK v. 1.1|About SEBoK 1.1]]."<br />
<br />
A PDF of SEBoK v. 1.1 and the older SEBoK v. 1.0 may be downloaded at [[Download SEBoK PDF]]. Please note that a new PDF is not generated for micro releases, such as v. 1.0.1.<br />
<br />
There is a link in the left margin under ''Toolbox'' explaining how to [[Cite the SEBoK]] correctly.<br />
<br />
==About the Sandbox==<br />
<br />
The SEBoK is a moderated wiki. Comments are accepted on each page. To provide a larger forum for users to propose new content or revisions to existing content, the BKCASE editors are also developing a 'Sandbox'. The Sandbox is expected to be operational within a few weeks of the release of version 1.1. When the Sandbox is operational, a micro-release will update the SEBoK with links to it.<br />
<br />
==Using the SEBoK==<br />
Articles in the SEBoK can be found by using the ''Search'' field in the upper right corner of each page, as well as through the ''Quicklinks'', ''Outline'', and ''Navigation'' menus in the left margin of each page.<br />
Detailed instructions about the page layout and features are found in [[How to Read the SEBoK]].<br />
<br />
==Contact the Editors==<br />
Comments can be left on any page by using the [http://help.disqus.com/ DISQUS] feature. These are periodically reviewed. Comments can be flagged in DISQUS, which will result in a faster review by the editors. <br />
<br />
Email may be sent to [mailto:bkcase@stevens.edu bkcase@stevens.edu].<br />
<br />
----<br />
<br />
<center>[[SEBoK v. 1.1 Introduction|Go to Part 1 >]]</center><br />
<br />
<br />
<center><br />
{|<br />
|-<br />
|style="background-color: #ffffff"|[[File:INCOSE-logo-.jpg]]<br />
|style="background-color: #ffffff"|[[File:CSlogo.png|350px|center|Institute of Electrical and Electronics Engineers Computer Society]]<br />
|-<br />
|colspan="2" style="background-color: #ffffff"|[[File:SERC_logo.jpg|350px|center|Systems Engineering Research]]<br />
|}<br />
</center><br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Validation_(glossary)&diff=48197
Validation (glossary)
2013-04-22T18:06:58Z
<p>Eleach: </p>
<hr />
<div><blockquote>(1a) ''Confirmation, through the provision of objective evidence, that the (stakeholder) requirements for a specific intended use or application have been fulfilled.'' (ISO/IEC 2008, Section 4.37) </blockquote><br />
<br />
<blockquote>(1b)'' The set of activities ensuring and gaining confidence that the services provided by an (engineered) system when in use comply with stakeholder requirements, achieving its intended use in its intended operational environment.'' (ISO/IEEE 2008, 1, Section 6.4.8) </blockquote><br />
<br />
<blockquote>(2) ''The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. ''(PMI 2008) </blockquote><br />
<br />
<blockquote>(3)'' The process of providing evidence that the software and its associated products satisfy system requirements allocated to software at the end of each life cycle activity, solve the right problem, and satisfy intended use and user needs. ''(IEEE 1012-2004, 3.1.35) </blockquote><br />
<br />
===Source===<br />
(1) ISO/IEC. 2008. ''Systems and Software Engineering - System Life Cycle Processes''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC). ISO/IEC 15288:2008 (E). <br />
<br />
(2) PMI. 2008. ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide),'' 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI). <br />
<br />
(3) IEEE. 2004. ''IEEE Standard for Software Verification and Validation.'' Institute of Electrical and Electronics Engineers (IEEE) Standards Association: 3.1.35. IEEE 1012-2004.<br />
<br />
===Discussion===<br />
Definition (1a) refers to the outcome of providing evidence that a particular system realization is validated (i.e. Does it satisfy the customer and user needs as stated and agreed?). The word (stakeholder) has been added to clarify the definition.<br />
<br />
Definition (1b) is based on the introduction to the validation process and refers to the process of achieving validation through a set of activities conducted across a system’s [[Life Cycle (glossary)]] to ensure that the system that has been built will serve its intended purpose. The term (engineered) system has been added to conform to SEBoK terminology.<br />
<br />
Definition (3) refers to the validation of software components in terms of satisfying both allocated system requirements as well as user needs.<br />
<br />
Validation builds on the activities and outcome of [[Verification (glossary)|verification]], a process that confirms that the system has been built correctly (i.e., Does it satisfy the system requirements?). <br />
<br />
For a full discussion of the role and importance of validation in systems engineering see the [[System Validation]] article.<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Verification_(glossary)&diff=48196
Verification (glossary)
2013-04-22T18:06:04Z
<p>Eleach: </p>
<hr />
<div><blockquote>(1a)'' Confirmation, through the provision of objective evidence, that specified (system) requirements have been fulfilled.'' (ISO/IEC 2008, section 4.38) </blockquote><br />
<br />
<blockquote>(1b)'' The set of activities ensuring and gaining confidence that each realized (engineered) system satisfies all requirements placed on it.'' (ISO/IEEE 2008, 1, Section 6.4.6) </blockquote><br />
<br />
<blockquote>(2) ''The evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition. ''(PMBOK® Guide) </blockquote><br />
<br />
<blockquote>(3a) ''The process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.'' (IEEE 1012-2004, 3.1.36) </blockquote><br />
<br />
<blockquote>(3b) ''Process of providing objective evidence that the software and its associated products comply with requirements for all life cycle activities during each life cycle process, satisfy standards, practices, and conventions during life cycle processes, and successfully complete each life cycle activity and satisfy all the criteria for initiating succeeding life cycle activities.'' (IEEE 829-2008, 3.1.54) </blockquote><br />
<br />
===Source===<br />
(1) ISO/IEC. 2008. ''Systems and Software Engineering — System Life Cycle Processes''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC). ISO/IEC 15288:2008 (E). <br />
<br />
(2) PMI. 2008. ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide),'' 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).<br />
<br />
(3) IEEE. 2004. ''IEEE Standard for Software Verification and Validation.'' Institute of Electrical and Electronics Engineers (IEEE) Standards Association: IEEE 1012-2004.<br />
<br />
===Discussion===<br />
Definition (1a) refers to the outcome of providing evidence that a particular system realization is verified(i.e. Does it satisfy the specified and agreed system requirements?). The word (system) has been added to clarify the definition.<br />
<br />
Definition (1b) is based on the introduction to the verification process and refers to the process of achieving verification through a set of activities conducted across a system’s [[Life Cycle (glossary)]] to ensure the system has been built correctly. The term (engineered) system has been added to conform to SEBoK terminology.<br />
<br />
Definition (3) refers to verification at the end of each lifecycle stage that confirms that both software and systems have been developed in compliance with all standard practices and rules.<br />
<br />
Verification supports the activities and outcome of [[Validation (glossary)|validation]], a process that ensures that the correct system has been built for its intended use (i.e., Does it satisfy the customer and user needs?).<br />
<br />
For a full discussion of the role and importance of verification in systems engineering see the [[System Verification]] article.<br />
<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Validation_(glossary)&diff=48195
Validation (glossary)
2013-04-22T17:57:53Z
<p>Eleach: </p>
<hr />
<div><blockquote>(1a) ''Confirmation, through the provision of objective evidence, that the (stakeholder) requirements for a specific intended use or application have been fulfilled.'' (ISO/IEC 2008, Section 4.37) </blockquote><br />
<br />
<blockquote>(1b)'' The set of activities ensuring and gaining confidence that the services provided by an (engineered) system when in use comply with stakeholder requirements, achieving its intended use in its intended operational environment.'' (ISO/IEEE 2008, 1, Section 6.4.8) </blockquote><br />
<br />
<blockquote>(2) ''The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. ''(PMI 2008) </blockquote><br />
<br />
<blockquote>(3)'' The process of providing evidence that the software and its associated products satisfy system requirements allocated to software at the end of each life cycle activity, solve the right problem, and satisfy intended use and user needs. ''(IEEE 1012-2004, 3.1.35) </blockquote><br />
<br />
===Source===<br />
(1) ISO/IEC. 2008. ''Systems and Software Engineering - System Life Cycle Processes''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC). ISO/IEC 15288:2008 (E). <br />
<br />
(2) PMI. 2008. ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide),'' 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI). <br />
<br />
(3) IEEE. 2004. ''IEEE Standard for Software Verification and Validation.'' Institute of Electrical and Electronics Engineers (IEEE) Standards Association: 3.1.35. IEEE 1012-2004.<br />
<br />
===Discussion===<br />
Definition (1a) refers to the outcome of providing evidence that a particular system realization is validated (i.e. Does it satisfy the customer and user needs as stated and agreed?). The word (stakeholder) has been added to clarify the definition.<br />
<br />
Definition (1b) is based on the introduction to the validation process and refers to the process of achieving validation through a set of activities conducted across a system’s [[Life Cycle (glossary)]] to ensure that the system that has been built will serve its intended purpose. The term (engineered) system has been added to conform to SEBoK terminology.<br />
<br />
Definition (3) refers to the validation of software components in terms of satisfying both allocated system requirements as well as user needs.<br />
<br />
Validation builds on the activities and outcome of [[Verification (glossary)]], a process that confirms that the system has been built correctly (i.e., Does it satisfy the system requirements?). <br />
<br />
For a full discussion of the role and importance of validation in systems engineering see the [[System Validation]] article.<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Validation_(glossary)&diff=48194
Validation (glossary)
2013-04-22T17:55:55Z
<p>Eleach: </p>
<hr />
<div><blockquote>(1a) ''Confirmation, through the provision of objective evidence, that the (stakeholder) requirements for a specific intended use or application have been fulfilled.'' (ISO/IEC 2008, Section 4.37) </blockquote><br />
<br />
<blockquote>(1b)'' The set of activities ensuring and gaining confidence that the services provided by an (engineered) system when in use comply with stakeholder requirements, achieving its intended use in its intended operational environment.'' (ISO/IEEE 2008, 1, Section 6.4.8) </blockquote><br />
<br />
<blockquote>(2) ''The assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. ''(PMI 2008) </blockquote><br />
<br />
<blockquote>(3)'' The process of providing evidence that the software and its associated products satisfy system requirements allocated to software at the end of each life cycle activity, solve the right problem, and satisfy intended use and user needs. ''(IEEE 1012-2004, 3.1.35) </blockquote><br />
<br />
===Source===<br />
(1) ISO/IEC. 2008. ''Systems and Software Engineering - System Life Cycle Processes''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC). ISO/IEC 15288:2008 (E). <br />
<br />
(2) PMI. 2008. ''A Guide to the Project Management Body of Knowledge (PMBOK® Guide),'' 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI). <br />
<br />
(3) IEEE. 2004. ''IEEE Standard for Software Verification and Validation.'' Institute of Electrical and Electronics Engineers (IEEE) Standards Association: 3.1.35. IEEE 1012-2004.<br />
<br />
===Discussion===<br />
Definition (1a) refers to the outcome of providing evidence that a particular system realization is validated (i.e. Does it satisfy the customer and user needs as stated and agreed?). The word (stakeholder) has been added to clarify the definition.<br />
<br />
Definition (1b) is based on the introduction to the validation process and refers to the process of achieving validation through a set of activities conducted across a system’s [[Life Cycle (glossary)]] to ensure that the system that has been built will serve its intended purpose. The term (engineered) system has been added to conform to SEBoK terminology.<br />
<br />
Definition (3) refers to the validation of software components in terms of satisfying both allocated system requirements as well as user needs.<br />
<br />
Validation builds on the activities and outcome of [[Verification(glossary)]], a process that confirms that the system has been built correctly (i.e., Does it satisfy the system requirements?). <br />
<br />
For a full discussion of the role and importance of validation in systems engineering see the [[System Validation]] article.<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Systems_Concept_(glossary)&diff=48193
Systems Concept (glossary)
2013-04-22T17:47:01Z
<p>Eleach: </p>
<hr />
<div>''<blockquote>A mode of description, which explains an aspect of an object in terms of a set of interacting elements. The object can, in principle, be anything: a physical object, a body of work, an idea, or an enterprise.'' (Created for SEBoK)</blockquote><br />
<br />
===Source===<br />
This definition was developed for the SEBoK.<br />
<br />
===Discussion===<br />
For a full discussion of the role and importance of systems concepts in systems engineering see the [[Concept Definition]] article.<br />
<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=System_Definition_(glossary)&diff=48192
System Definition (glossary)
2013-04-22T17:45:38Z
<p>Eleach: </p>
<hr />
<div>''<blockquote>A set of core technical activities of systems engineering, including the activities that are completed primarily in the front-end portion of the system design. This consists of the definition of system requirements, the design of one or more logical and physical architectures, and analysis and selection between possible solution options.'' (Created for SEBoK)</blockquote><br />
<br />
===Source===<br />
This definition was developed for the SEBoK.<br />
<br />
===Discussion===<br />
[[System Definition|System definition]] is a knowledge area in the SEBoK that includes several front-end systems engineering activities, such as system requirements development, logical and physical architectural design, and system analysis. This generally aligns with the "concept stage" as discussed in INCOSE (2012). In the SEBoK, [[Concept Definition|concept definition]] is used to discuss the assessment of the mission and stakeholder requirements.<br />
<br />
'''Work Cited'''<br />
<br />
INCOSE. 2012. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2.<br />
<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Stakeholder_Requirement_(glossary)&diff=48190
Stakeholder Requirement (glossary)
2013-04-22T17:42:25Z
<p>Eleach: </p>
<hr />
<div>''<blockquote>(1a) The requirements for a system that can provide the services needed by users and other stakeholders in a defined environment.'' (ISO/IEC, 2008, section 6.4.1)</blockquote><br />
<br />
''<blockquote>(1b) The stakeholder requirements definition process identifies stakeholders, as classes of stakeholders, involved with the system throughout its life cycle, and their needs, expectations, and desires. It transforms these into a common set of stakeholder requirements that express the intended interaction that the system will have with its operational environment and that will become the reference against which resulting operational services are validated.'' (ISO/IEC,2008, section 6.4.1) </blockquote><br />
<br />
===Source===<br />
ISO/IEC. 2008. ''Systems and Software Engineering - System Life Cycle Processes''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 15288:2008 (E). <br />
<br />
===Discussion===<br />
Both definitions are taken from the introduction to the "Stakeholder Requirements Definition Process" in ISO/IEC 15288; there is no formal definition of the term "stakeholder requirement" in the standard.<br />
<br />
For a full discussion of the role and importance of stakeholder requirements in systems engineering see the [[Stakeholder Needs and Requirements]] article.<br />
<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Life_Cycle_(glossary)&diff=48062
Life Cycle (glossary)
2013-04-20T18:03:42Z
<p>Eleach: </p>
<hr />
<div><blockquote>''(1) The organized collection of activities, relationships and contracts which apply to a system-of-interest during its life.'' (Pyster 2009, 73)</blockquote><br />
<br />
<blockquote>''(2) The evolution of a system, product, service, project or other human-made entity from conception through retirement.'' (ISO/IEC 2008)</blockquote><br />
<br />
<blockquote>''(3) Development (life) cycles start with user needs and end with system decommissioning and disposal. Project cycles contain three aspects: business, budget, and technical.'' (Mooz, Forsberg, Cotterman 2003, 259)</blockquote><br />
<br />
===Source===<br />
(1) Pyster, A.(ed.). 2009. ''Graduate Software Engineering 2009 (GSwE2009): Curriculum Guidelines for Graduate Degree Programs in Software Engineering''. Integrated Software & Systems Engineering Curriculum Project. Hoboken, NJ, USA: Stevens Institute of Technology, September 30, 2009.<br />
<br />
(2) ISO/IEC. 2008. ''Systems and Software Engineering -- System Life Cycle Processes''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008.<br />
<br />
(3) Mooz, H., K. Forsberg, H. Cotterman. 2003. ''Communicating Project Management.'' Hoboken, NJ, USA: John Wiley and Sons.<br />
<br />
===Discussion===<br />
For additional discussion of the different uses of "life cycle", see the [[Life Cycle Models]] article.<br />
<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Implementation_(glossary)&diff=48061
Implementation (glossary)
2013-04-20T18:01:32Z
<p>Eleach: </p>
<hr />
<div><blockquote>''The process that actually yields the lowest level system elements in the system hierarchy (system breakdown structure).''(DAU 2011)<blockquote><br />
<br />
===Source===<br />
DAU. 2011. "4.2.3.2.5. Integration Process," in ''Defense Acquisition Guidebook: Your Acquisition Policy and Discretionary Best Practice Guide.'' Ft. Belvoir, VA: Defense Acquisition University (DAU). Accessed on 11 September 2012. Available at: https://acc.dau.mil/CommunityBrowser.aspx?id=332973#4.2.3.2.5.<br />
<br />
===Discussion===<br />
For a full discussion of the role and importance of system implementation in systems engineering see the [[System Implementation]] article.<br />
<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Governance_(glossary)&diff=48060
Governance (glossary)
2013-04-20T17:53:39Z
<p>Eleach: </p>
<hr />
<div><blockquote>(1) ''System by which organizations [or systems] are directed and controlled.'' (ISO/IEC 2008, 1.6.2) </blockquote><br />
<br />
<blockquote>(2) ''Organizational chains of responsibility, authority, and communication for executing measurement and control mechanisms to effectively drive the organization and enable people to perform roles their respective roles and responsibilities.'' (Cantor 2006)</blockquote><br />
<br />
<blockquote>(3) ''A decision-making process that defines the responsibility and authority of decision makers and stakeholders for identifying, defining, discussing, making, and implementing decisions in the face of complex problems, multiple stakeholders with diverse and conflicting objectives, and resource constraints. For engineering governance, the problem complexity usually includes significant technology complexity.'' (Created for SEBoK)</blockquote><br />
<br />
===Source===<br />
(1) ISO/IEC. 2008. ''Corporate governance of information technology.'' ISO/IEC 38500:2008. Accessed on 11 September 2012. Available at http://www.iso.org/iso/catalogue_detail?csnumber=51639.<br />
<br />
(2) Cantor, M. 2006. "Estimation Variance and Governance." In IBM developerWorks. Accessed on 15 September 2011. Available at http://www.ibm.com/developerworks/rational/library/mar06/cantor/.<br />
<br />
(3) This definition was developed for the SEBoK.<br />
<br />
===Discussion===<br />
None.<br />
<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Enterprise_Architecture_(glossary)&diff=48059
Enterprise Architecture (glossary)
2013-04-20T17:50:45Z
<p>Eleach: </p>
<hr />
<div><blockquote>(1) ''A rigorous description of the [[Structure (glossary)|structure]] of an [[Enterprise (glossary)|enterprise]], its decomposition into subsystems, the relationships between the subsystems, the relationships with the external [[Environment (glossary)|environment]], the terminology to use, and the guiding principles for the [[Design (glossary)|design]] and evolution of an enterprise.'' (Giachetti 2009)</blockquote> <br />
<br />
<blockquote>(2) ''A strategic information asset base, which defines the [[Business (glossary)|business]], the information necessary to operate the business, the technologies necessary to support the business operations, and the transitional processes necessary for implementing new technologies in response to the changing business needs. It is a representation or blueprint.'' (CIO Council 1999)</blockquote><br />
<br />
<blockquote>(3) ''The formal description of the [[Structure (glossary)|structure]] and [[Function (glossary)|function]] of the [[Component (glossary)|components]] of an enterprise, their interrelationships, and the principles and guidelines governing their design and evolution over time.'' (MOD 2004)</blockquote><br />
<br />
<blockquote>(4) ''A discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. Enterprise architecture delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. It is used to steer decision making toward the evolution of the future state architecture.'' (Gartner 2013)</blockquote><br />
<br />
===Source===<br />
(1) Giachetti, R.E. 2009. ''Design of Enterprise Systems: Theory, Architectures, and Methods''. Boca Raton, FL, USA: CRC Press. <br />
<br />
(2) CIO Council. 1999. ''Federal Enterprise Architecture Framework (FEAF)''. Washington, DC, USA: Chief Information Officer (CIO) Council. <br />
<br />
(3) MOD. 2004. ''Ministry of Defence Architecture Framework (MODAF)'', version 2. London, UK: U.K. Ministry of Defence.<br />
<br />
(4) Gartner IT Glossary. S.V. "enterprise architecture." Accessed 11 March 2013, available at: http://www.gartner.com/it-glossary/enterprise-architecture-ea/.<br />
<br />
===Discussion===<br />
Components of the enterprise can be any element that is a part of the composition of the enterprise and can include people, [[Process (glossary)|processes]] and physical structures, as well as [[Engineering (glossary)|engineering]] and information systems. (MOD 2004)<br />
<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Capability_(glossary)&diff=48058
Capability (glossary)
2013-04-20T17:44:19Z
<p>Eleach: </p>
<hr />
<div><blockquote>(1) ''The ability to achieve a desired effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities.'' (DoD 2009)</blockquote><br />
<br />
<blockquote>(2) ''The ability to execute a specified course of action. It is defined by a user and expressed in non-equipment based operational terms.'' (MOD 2004)</blockquote><br />
<br />
<blockquote>(3) ''The ability to execute a specified course of action. A capability may or may not be accompanied by an intention.'' (DoD 2009) </blockquote><br />
<br />
<blockquote>(4) ''The ability to perform a function, task, or action.'' (Created for SEBoK)</blockquote><br />
<br />
===Source===<br />
(1) DoD. 2009. ''DoD Architecture Framework (DoDAF)'', version 2.0. Washington, DC, USA: U.S. Department of Defense (DoD).<br />
<br />
(2) MOD. 2004. ''Ministry of Defence Architecture Framework (MODAF),'' version 2. London, UK: U.K. Ministry of Defence.<br />
<br />
(3) DoD. 2009. ''Department of Defense Dictionary of Military and Associated Terms.'' Washington, DC, USA: U.S. Department of Defense (DoD), Joint Publication 1-02, 17 March 2009.<br />
<br />
(4) This definition was developed for the SEBoK.<br />
<br />
===Discussion===<br />
In MODAF, the term capability refers to military capability, which includes all defense lines of development (DLODs), rather than equipment capability, which refers solely to the capability of the equipment, system, or system of systems. Sometimes it is necessary to differentiate between a required capability (i.e., what is sought) and the fielded capability (i.e., the currently available capability that consists of equipment and the supporting DLODs).<br />
<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Architecture_(glossary)&diff=48057
Architecture (glossary)
2013-04-20T17:36:42Z
<p>Eleach: </p>
<hr />
<div><blockquote>(1) ''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.'' (ISO/IEC 2008, Section 4.5) </blockquote><br />
<br />
<blockquote>(2) ''The organizational structure of a system or component; the organizational structure of a system and its implementation guidelines.'' (ISO/IEC 2009, 1) </blockquote><br />
<br />
<blockquote>(3) ''Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.'' (ISO/IEC 2011, section 3.2) </blockquote><br />
<br />
===Source===<br />
(1) ISO/IEC/IEEE. 2008. ''Systems and Software Engineering — System Life Cycle Processes''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC). ISO/IEC 15288:2008 (E). <br />
<br />
(2) ISO/IEC/IEEE. 2009. ''Systems and Software Engineering — System and Software Engineering Vocabulary'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronic Engineers (IEEE) 2009 ISO/IEC/IEEE 24765:2009 [database online]. Available from http://pascal.computer.org/sev_display/index.action.<br />
<br />
(3) ISO/IEC/IEEE. 2011. ''Systems and Software Engineering — Architectural Description''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2011.<br />
<br />
===Discussion===<br />
A few definitions are presented here to illustrate the different ways that authors define architecture. Note that many authors write extensively on architecture without ever defining what they mean by the term.<br />
<br />
The use of the word ''fundamental'' (definitions (1) and (3)) is problematic, since it has no universal definition. In practice, the level of detail in an architecture depends on the context of use and the purpose to which it is being designed. In the early (conceptual) stages it might only contain a high-level description of the system as a whole, but in later stages the key features of all key subsystems need to be mapped out. An architectural description should therefore also justify what is included and what is excluded.<br />
<br />
ISO/IEC/IEEE 15288:2008 is normative - see above. The architecture associated with a system-of-interest is conceptual and is realized through an architectural description.<br />
<br />
ISO/IEC/IEEE 42010:2011 is normative - see above.<br />
<br />
OMG 2010 is normative - “The organizational structure and associated behavior of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts.”<br />
<br />
'''Works Cited'''<br />
<br />
OMG. 2010. ''OMG Systems Modeling Language Specification'', version 1.2, July 2010. http://www.omg.org/technology/documents/spec_catalog.htm.<br />
<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Physical_Architecture_(glossary)&diff=48056
Physical Architecture (glossary)
2013-04-20T03:41:51Z
<p>Eleach: </p>
<hr />
<div><blockquote>(1) ''A physical architecture is an arrangement of physical elements (system elements and physical interfaces) which provides the design solution for a product, service, or enterprise, and is intended to satisfy logical architecture elements and system requirements. It is implementable through technologies.'' (ISO/IEC 2010)</blockquote><br />
<br />
<blockquote>(2) ''An arrangement of physical elements which provides the design solution for a consumer product or life-cycle process intended to satisfy the requirements of the functional architecture and the requirement baseline.'' (ISO/IEC 2007)</blockquote><br />
<br />
===Source===<br />
(1) Adapted from ISO/IEC. 2010. ''Systems and Software Engineering, Part 1: Guide for Life Cycle Management''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 24748-1:2010.<br />
<br />
(2) ISO/IEC. 2007. ''Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC FDIS 42010:2007. <br />
<br />
===Discussion===<br />
Definition (1) comes from the terms "design architecture" provided in ISO/IEC/IEEE 24748 - 4. It is adapted here to be consistent current terminology, in particular with [[Logical Architecture (glossary) |logical architecture]].<br />
<br />
Definition (2) comes from ISO/IEC/IEEE 42010:2007 that is replaced by version 2011 in which this definition has been withdrawn.<br />
<br />
For a full discussion of the role and importance of physical architecture in systems engineering see the [[Physical Architecture Design]] article.<br />
<br />
<br />
[[Category:Glossary of Terms]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Key_Points_a_Systems_Engineer_Needs_to_Know_about_Software_Engineering&diff=48054
Key Points a Systems Engineer Needs to Know about Software Engineering
2013-04-20T02:47:44Z
<p>Eleach: </p>
<hr />
<div>The field of software engineering is extensive and specialized. Its importance to modern systems makes it necessary for systems engineers to be knowledgeable about software engineering and its relationship to systems engineering. <br />
<br />
==Key Concepts a Systems Engineer Needs to Know about Software Engineering==<br />
<br />
The following items are significant aspects that systems engineers need to know about software and software engineering. Most are documented in (Fairley and Willshire 2011):<br />
<br />
# '''For the time, effort, and expense devoted to developing it, software is more complex than most other system components''' - Software complexity arises because few elements in a software program (even down to the statement level) are identical as well as because of the large number of possible decision paths found even in small programs, with the number of decision paths through a large program often being astronomical. There are several detailed references on software complexity. [http://www.computer.org/portal/web/swebok/html/ch4#Ref22 Chapter 4 of the SWEBOK ] (Abran and Moore, 2004) discusses minimizing complexity as part of the software construction fundamentals. Zuse (1991) has a highly cited article on software complexity measures and methods. Chapter 4 of the SWEBOK also has further references. <br />
# '''Software testing and reviews are sampling processes''' - In all but the simplest cases, exhaustive testing of software is impossible because of the large number of decision paths through most programs. Also, the combined values of the input variables selected from a wide combinatorial range may reveal defects that other combinations of the variables would not detect. Software test cases and test scenarios are chosen in an attempt to gain confidence that the testing samples are representative of the ways the software will be used in practice. Structured reviews of software are an effective mechanism for finding defects, but the significant effort required limits exhaustive reviewing. Criteria must be established to determine which components (or sub-components) should be reviewed. Although there are similar concerns about exhaustive testing and reviewing of physical products, the complexity of software makes software testing, reviews, and the resulting assurance provided, more challenging. Other points include:<br />
## All software testing approaches and techniques are heuristic. Hence, there is no universal ‘‘‘best’’’ approach, practice, or technique for testing, since these must be selected based on the software context.<br />
## Exhaustive testing is not possible.<br />
## Errors in software tend to cluster within the software structures; therefore, any one specific approach or a random approach to testing is not advised.<br />
##'''Pesticide paradox''' exists. As a result, running the same test over and over on the same software-system provides no new information.<br />
## Testing can reveal the presence of defects but cannot guarantee that there will be no errors, except under the specific conditions of a given test. <br />
## Testing, including verification and validation (V&V), must be performed early and continually throughout the lifecycle (end to end.<br />
## Even after extensive testing and V&V, errors are likely to remain after long term use of the software.<br />
## [http://www.computer.org/portal/web/swebok/html/ch5 Chapter 5 of the SWEBOK] discusses software testing and provides a bibliography. <br />
# '''Software often provides the interfaces that interconnect other system components''' - Software is often referred to as the ''glue'' that holds a system together because the interfaces among components, as well as the interfaces to the environment and other systems, are often provided by digital sensors and controllers that operate via software. Because software interfaces are behavioral rather than physical, the interactions that occur among software components often exhibit emergent behaviors that cannot always be predicted in advance. In addition to component interfaces, software usually provides the computational and decision algorithms needed to generate command and control signals. The SWEBOK has multiple discussions of interfaces: [http://www.computer.org/portal/web/swebok/html/ch3 Chapter 3 on Software Design] is a good starting point and includes a bibliography. <br />
# '''Every software product is unique''' - The goal of manufacturing physical products is to produce replicated copies that are as nearly identical as much as possible, given the constraints of material sciences and manufacturing tools and techniques. Because replication of existing software is a trivial process (as compared to manufacturing of physical products), the goal of software development is to produce one perfect copy (or as nearly perfect as can be achieved given the constraints on schedule, budget, resources, and technology). Much of software development involves altering existing software. The resulting product, whether new or modified, is uniquely different from all other software products known to the software developers. IEEE Standard 1517-99 addresses software reuse, and [http://www.computer.org/portal/web/swebok/html/ch4#Ref18 Chapter 4 of the SWEBOK provides additional references.]<br />
# '''In many cases, requirements allocated to software must be renegotiated and reprioritized''' - Software engineers often see more efficient and effective ways to restate and prioritize requirements allocated to software. Sometimes, the renegotiated requirements have system-wide impacts that must be taken into account. One or more senior software engineers should be, and often are, involved in analysis of system-level requirements. This topic is addressed in the SWEBOK under [http://www.computer.org/portal/web/swebok/html/ch2#ch2-7.1 Chapter 2] with topics on the iterative nature of software and change management. <br />
# '''Software requirements are prone to frequent change''' - Software is the most frequently changed component in complex systems, especially late in the development process and during system sustainment. This is due to the fact that software is perceived to be the most easily changed component of a complex system. This is not to imply that changes to software requirements, and the resulting changes to the impacted software, can be easily done without undesired side effects. Careful software configuration management is necessary, as discussed in [http://www.computer.org/portal/web/swebok/html/ch7 Chapter 7 of the SWEBOK] with extensive references. <br />
# '''Small changes to software can have large negative effects''' (A corollary to frequently changing software requirements: ''There are no small software changes'') - In several well-known cases, modifying a few lines of code in very large systems that incorporated software negatively impacted the safety, security, and/or reliability of those systems. Applying techniques such as traceability, impact analysis, object-oriented software development, and regression testing reduces undesired side effects of changes to software code. These approaches limit but do not eliminate this problem.<br />
# '''Some quality attributes for software are subjectively evaluated.''' - Software typically provides the interfaces to systems that have human users and operators. The intended users and operators of these systems often subjectively evaluate quality attributes, such as ease of use, adaptability, robustness, and integrity. These quality attributes determine the acceptance of a system by its intended users and operators. In some cases, systems have been rejected because they were not judged to be suitable for use by the intended users in the intended environment, even though those systems satisfied their technical requirements. [http://www.computer.org/portal/web/swebok/html/ch11 Chapter 11 of the SWEBOK] provides an overview of software quality, with references. <br />
# '''The term ''''prototyping'''' has different connotations for systems engineers and software engineers''' - For a systems engineer, a prototype is typically the first functioning version of a hardware. For software engineers, software prototyping is primarily used for two purposes: (1) as a mechanism to elicit user requirements by iteratively evolving mock-ups of user interfaces, and (2) as an experimental implementation of some limited element of a proposed system to explore and evaluate alternative algorithms. Chapter 2 of the SWEBOK discusses this [http://www.computer.org/portal/web/swebok/html/ch2#ch2-3.2 here ] and [http://www.computer.org/portal/web/swebok/html/ch2#ch2-6.2 here,] with excellent references. <br />
# '''Cyber security is a present and growing concern for systems that incorporate software''' - In addition to the traditional specialty disciplines of [[Safety Engineering|safety]], [[Reliability, Availability, and Maintainability|reliability]], and [[Reliability, Availability, and Maintainability|maintainability]], systems engineering teams increasingly include security specialists at both the software level and the systems level in an attempt to cope with the cyber attacks that may be encountered by systems that incorporate software. Additional information about [[Security Engineering|security engineering]] can be found in the [[Systems Engineering and Specialty Engineering]] KA.<br />
# '''Software growth requires spare capacity''' - Moore’s Law no longer fully comes to the rescue. As systems adapt to changing circumstances, the modifications can most easily be performed and upgraded in the software, requiring additional computer execution cycles and memory capacity (Belady and Lehman 1979). For several decades, this growth was accommodated by Moore’s Law (Moore, 1965), but recent limits that have occurred as a result of heat dissipation have influenced manufacturers to promote potential computing power growth by slowing down the processors and putting more of them on a chip. This requires software developers to revise their programs to perform more in parallel, which is often an extremely difficult problem (Patterson 2010). This problem is exacerbated by the growth in mobile computing and limited battery power.<br />
# '''Several Pareto 80-20 distributions apply to software''' - These refers to the 80% of the avoidable rework that comes from 20% of the defects, that 80% of the defects come from 20% of the modules, and 90% of the downtime comes from at most 10% of the defects (Boehm and Basili 2001). These, along with recent data indicating that 80% of the testing business value comes from 20% of the test cases (Bullock, 2000), indicate that much more cost-effective software development and testing can come from determining which 20% need the most attention.<br />
<br />
==References== <br />
===Works Cited===<br />
Belady. L., and M. Lehman. 1979. “Characteristics of Large Systems,” in P. Wegner (ed), Research Directions in Software Technology. Cambridge, MA, USA: MIT Press.<br />
<br />
Boehm, B., and V. Basili. 2001. “Software defect reduction Top 10 List, “ IEEE Computer,34 (1), 135-137.<br />
<br />
Bullock, J. 2000. “Calculating the Value of Testing,” Software Testing and Quality Engineering, May-June, 56-62.<br />
<br />
Fairley, R.E. and M.J. Willshire. 2011. "Teaching software engineering to undergraduate systems engineering students." Proceedings of the 2011 American Society for Engineering Education (ASEE) Annual Conference and Exposition. 26-29 June 2011. Vancouver, BC, Canada.<br />
<br />
Moore, G.E. 1965. "Cramming more components onto integrated circuits," Electronics Magazine, April 19, 4. <br />
<br />
Patterson, D. 2010. “The Trouble With Multicore,” IEEE Spectrum, July, 28-32, 52-53.<br />
<br />
Zuse, Horst. 1991. ''Software Complexity: measures and methods.'' Hawthorne, NJ, USA: Walter de Gruyter and Co.<br />
<br />
===Primary References===<br />
<br />
Abran, A. and J.W. Moore (exec. eds); P. Borque and R. Dupuis (eds.). 2004. ''[[Guide to the Software Engineering Body of Knowledge (SWEBOK)]]''. Piscataway, NJ, USA: The Institute of Electrical and Electronic Engineers, Inc. (IEEE). Available at: http://www.computer.org/portal/web/swebok<br />
<br />
Fairley, R.E. 2009. ''[[Managing and Leading Software Projects]].'' Hoboken, NJ, USA: John Wiley and Sons.<br />
<br />
PMI. 2008. ''[[A Guide to the Project Management Body of Knowledge|A Guide to the Project Management Body of Knowledge (PMBOK® Guide)]]'', 4th ed. Newtown Square, PA, USA: Project Management Institute (PMI).<br />
<br />
===Additional References===<br />
Pyster, A., M. Ardis, D. Frailey, D. Olwell, A. Squires. 2010. "Global workforce development projects in software engineering". ''Crosstalk- The Journal of Defense Software Engineering'', Nov/Dec, 36-41. Available at: http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA535633<br />
----<br />
<center>[[An Overview of the SWEBOK Guide|< Previous Article]] | [[Systems Engineering and Software Engineering|Parent Article]] | [[Key Points a Systems Engineer Needs to Know about Managing a Software Team|Next Article >]]</center><br />
<br />
<br />
<br />
<br />
[[Category: Part 6]][[Category:Topic]]<br />
[[Category:Systems Engineering and Software Engineering]]<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Guide_to_the_Systems_Engineering_Body_of_Knowledge_(SEBoK)&diff=48053
Guide to the Systems Engineering Body of Knowledge (SEBoK)
2013-04-19T22:51:09Z
<p>Eleach: </p>
<hr />
<div> __NOTOC__<br />
<html><br />
<meta name="citation_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK) v. 1.1"><br />
<meta name="citation_author" content="Pyster, Art"><br />
<meta name="citation_author" content="Olwell, David H."><br />
<meta name="citation_author" content="Hutchison, Nicole"><br />
<meta name="citation_author" content="Enck, Stephanie"><br />
<meta name="citation_author" content="Anthony, James F., Jr."><br />
<meta name="citation_author" content="Henry, Devanandham"><br />
<meta name="citation_author" content="Squires, Alice (eds)"><br />
<meta name="citation_publication_date" content="2012/11/30"><br />
<meta name="citation_journal_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK)"><br />
<meta name="citation_volume" content="version 1.0.1"><br />
<meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page"></html><br />
<br />
<center><br />
<html><br />
<font size=3>Please note that this is the access area for the development of SEBoK v. 1.1. To view the current published version of the SEBoK (v. 1.0.1), please go to <a href="www.sebokwiki.org/1.0.1/">www.sebokwiki.org/1.0.1/</a>. <b>If you are a BKCASE editor, please log in.</b> If you have any questions, please contact us at <a href="mailto:bkcase@stevens.edu">bkcase@stevens.edu</a>.<br />
</font><br />
</html><br />
</center><br />
<br />
<br />
==Welcome==<br />
On behalf of [[Acknowledgements|the more than 70 authors]], the editors and the three SEBoK steward organizations – the International Council on Systems Engineering (INCOSE), the Institute of Electrical and Electronics Engineers Computer Society (IEEE-CS), and the Systems Engineering Research Center (SERC) – welcome you to the ''Guide to the Systems Engineering Body of Knowledge (SEBoK)'' version 1.1. This version was released 30 April 2013, and contains [[Release History|a number of changes]] to version 1.0.1, which was released in November 2012.<br />
<br />
The SEBoK provides a compendium of the [[Primary References|key knowledge sources and references]] of systems engineering, organized and explained to assist a wide variety of users. It is a living document, accepting [[SEBoK Review and Adjudication |community input]] continuously, and [[Editors' Note|regularly refreshed and updated]].<br />
<br />
==About Systems Engineering== <br />
<br />
[[Systems Engineering (glossary)|Systems engineering]] is an interdisciplinary approach and means to enable the realization of successful systems. Separate articles in [[SEBoK v. 1.1 Introduction|Part 1]] provide an [[Systems Engineering Overview|overview of systems engineering]], place it in [[Systems Engineering: Historic and Future Challenges|historical context]], and discuss its [[Economic Value of Systems Engineering| economic value]].<br />
<br />
Systems engineering has roots in [[Systems |systems science]]. Major sections (called knowledge areas (KAs)) in [[Systems |Part 2]] discuss [[Systems Fundamentals]], [[Systems Thinking]], [[Representing Systems with Models]], and the [[Systems Approach Applied to Engineered Systems]].<br />
<br />
==About the SEBoK==<br />
The SEBoK is organized into [[SEBoK Table of Contents|7 parts]], with a [[Glossary of Terms]] and a list of [[Primary References]]. <br />
<br />
*[[SEBoK v. 1.1 Introduction|Part 1]] discusses the [[Scope of the SEBoK]], and its [[Structure of the SEBoK|structure]], including its hierarchy of parts, [http://www.sebokwiki.org/1.0/index.php/Category:Knowledge_Area knowledge areas], and [http://www.sebokwiki.org/1.0/index.php/Category:Topic topics]. Part 1 also includes a lengthy discussion of [[SEBoK Users and Uses]], including five [http://www.sebokwiki.org/1.0/index.php/Category:Use_Case use cases]. <br />
<br />
The other parts are:<br />
*Part 2 [[Systems]]<br />
*Part 3 [[Systems Engineering and Management]]<br />
*Part 4 [[Applications of Systems Engineering]]<br />
*Part 5 [[Enabling Systems Engineering]]<br />
*Part 6 [[Related Disciplines]]<br />
*Part 7 [[Systems Engineering Implementation Examples]]<br />
<br />
As a compendium, much of the content has restricted intellectual property rights. This [[Bkcase Wiki:Copyright |copyright information]] is placed on each page, and must be respected. The SEBoK copyright is held by the Trustees of the Stevens Institute of Technology, and plans for the transfer of the copyright are discussed in [[Editors' Note]].<br />
<br />
As a living document, each page footer also contains version identification in a link called "[[About SEBoK v. 1.1|About SEBoK 1.1]]."<br />
<br />
A PDF of SEBoK v. 1.1 and the older SEBoK v. 1.0 may be downloaded at [[Download SEBoK PDF]]. Please note that a new PDF is not generated for micro releases, such as v. 1.0.1.<br />
<br />
There is a link in the left margin under ''Toolbox'' explaining how to [[Cite the SEBoK]] correctly.<br />
<br />
==About the Sandbox==<br />
<br />
The SEBoK is a moderated wiki. Comments are accepted on each page. To provide a larger forum for users to propose new content or revisions to existing content, the BKCASE editors are also developing a 'Sandbox.' The Sandbox is expected to be operational within a few weeks of the release of version 1.1. When the Sandbox is operational, a micro-release will update the SEBoK with links to it.<br />
<br />
==Using the SEBoK==<br />
Articles in the SEBoK can be found by using the ''Search'' field in the upper right corner of each page, and through the ''Quicklinks'', ''Outline'', and ''Navigation'' menus in the left margin of each page.<br />
<br />
Detailed instructions about the page layout and features are found in [[How to Read the SEBoK]].<br />
<br />
==Contact the Editors==<br />
Comments can be left on any page by using the [http://help.disqus.com/ DISQUS] feature. These are periodically reviewed. Comments can be flagged in DISQUS, and that results in a faster review by the editors. <br />
<br />
Email may be sent to [mailto:bkcase@stevens.edu bkcase@stevens.edu].<br />
<br />
----<br />
<br />
<center>[[SEBoK v. 1.1 Introduction|Go to Part 1 >]]</center><br />
<br />
<br />
<center><br />
{|<br />
|-<br />
|style="background-color: #ffffff"|[[File:INCOSE-logo-.jpg]]<br />
|style="background-color: #ffffff"|[[File:CSlogo.png|350px|center|Institute of Electrical and Electronics Engineers Computer Society]]<br />
|-<br />
|colspan="2" style="background-color: #ffffff"|[[File:SERC_logo.jpg|350px|center|Systems Engineering Research]]<br />
|}<br />
</center><br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Stakeholder_Requirements_Definition&diff=48052
Stakeholder Requirements Definition
2013-04-19T22:43:41Z
<p>Eleach: </p>
<hr />
<div>[[System Requirement (glossary)|System requirements]] are all of the [[Requirement (glossary)|requirements]] at the ''system level'' that describe the functions which the system as a whole should fulfill to satisfy the [[Stakeholder Requirement (glossary)|stakeholder needs and requirements]], and is expressed in an appropriate combination of textual statements, views, and non-functional requirements; the latter expressing the levels of safety, security, reliability, etc., that will be necessary. <br />
<br />
System requirements play major roles in systems engineering, as they: <br />
* Form the basis of system [[Architecture (glossary)|architecture]] and [[Design (glossary)|design]] activities.<br />
*Form the basis of system [[Integration (glossary)]] and [[Verification (glossary)|verification]] activities.<br />
* Act as reference for [[Validation (glossary)|validation]] and stakeholder acceptance.<br />
* Provide a means of communication between the various technical staff that interact throughout the project.<br />
<br />
Elicitation of stakeholder requirements starts in [[Concept Definition|concept definition]], and will be initially developed though interview and mission analysis. System requirements are considered in detail during [[System Definition|system definition]]. Neither can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed. <br />
<br />
==Definition and Purpose of Requirements==<br />
A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability (ISO/IEC 2007).<br />
<br />
To avoid confusion in the multitude of terms pertaining to ''[[Requirement (glossary)|requirements]]'', consider the following classifications:<br />
* '''Process Role or State''': The role the requirement plays in the definition process; for instance, its position in the system block (e.g. translated, derived, satisfied) or its state of agreement (e.g. proposed, approved, cancelled). <br />
* '''Level of Abstraction''': The level within the definition process that the requirement stands; for instance, stakeholder requirement, system requirement, system element requirement.<br />
* '''Type of Requirement''': The nature of the requirement itself; for instance, functional, performance, constraint, etc.<br />
<br />
Any single requirement may simultaneously be in a particular state, at a particular level abstraction, and of a particular type. For additional explanations about differences between the types of requirements, refer to Chapter 2 of Martin (1997).<br />
<br />
==Principles Governing System Requirements==<br />
===Relationship to Stakeholder Requirements and Logical Architecture===<br />
A set of [[Stakeholder Requirement (glossary)|stakeholder requirements]] are clarified and translated from statements of need into ''engineering-oriented'' language in order to enable proper architecture definition, design, and verification activities that are needed as the basis for system requirements analysis. <br />
<br />
The system requirements are based around identification and synthesis of the functions required of any solution system associated with performance and other quality measures and provide the basis for the assessment candidate solutions and verification of the completed system. The [[System Requirement (glossary)|system requirements]] are expressed in technical language that is useful for architecture and design: unambiguous, consistent, coherent, exhaustive, and verifiable. Of course, close coordination with the stakeholders is necessary to ensure the translation is accurate and traceability is maintained. This results in a set of system functions and requirements specifying measurable characteristics which can form the basis for [[System Realization (glossary) |system realization]].<br />
<br />
The [[Logical Architecture (glossary)]] defines system boundary and functions, from which more detailed system requirements can be derived. The starting point for this process may be to identify functional requirements from the stakeholder requirements and to use this to start the architectural definition, or to begin with a high level functional architecture view and use this as the basis for structuring system requirements. The exact approach taken will often depend on whether the system is an evolution of an already understood product or service, or a new and unprecedented solution (see [[Synthesizing Possible Solutions]]). However, when the process is initiated it is important that the stakeholder requirements, system requirements, and logical architecture are all complete, consistent with each other, and assessed together at the appropriate points in the systems [[Life Cycle Model (glossary)]].<br />
<br />
====Traceability and the Assignment of System Requirements during Architecture and Design====<br />
Requirements traceability provides the ability to track information from the origin of the stakeholder requirements, to the top level of requirements and other system definition elements at all levels of the system hierarchy (see section "Top-down and Recursive Approach to System Decomposition" in the [[System Definition]] article). Traceability is also used to provide an understanding as to the extent of a change as an input when impact analyses is performed in cases of proposed engineering improvements or requests for change.<br />
<br />
During [[Architecture (glossary) |architecture]] definition and [[Design (glossary) |design]], the assignment of requirements from one level to lower levels in the system hierarchy can be accomplished using several methods, as appropriate - see Table 1.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Assessment Types for a System Requirement.''' (SEBoK Original)<br />
!Assignment Type for a System Requirement<br />
!Description<br />
|-<br />
|'''Direct Assignment'''<br />
|The system requirement from the higher level is directly assigned to a system or a system element for a lower level (e.g. the color used to paint visible parts of the product).<br />
|-<br />
|'''Indirect Assignment (Simply Decomposed)'''<br />
|The system requirement is distributed across several systems or system elements and the sum of a more complex calculation for distribution is equal to the requirement of higher level (e.g. 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.<br />
|-<br />
|'''Indirect Assignment (Modeled and Decomposed)'''<br />
|The system requirement is distributed to several systems or system elements using an analysis or mathematical modeling technique. The resulting design parameters are assigned to the appropriate systems or system elements (with appropriate margin). For example, in the case of a radar detection requirement that is being analyzed, these lower-level parameters for output power, beam size, frequencies, etc. will be assigned to the appropriate hardware and software elements. Again, the analysis (or model) must be documented and configuration-managed.<br />
|-<br />
|'''Derived Requirement (from Design)'''<br />
|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.<br />
|}<br />
</center><br />
<br />
===Classification of System Requirements===<br />
Several classifications of system requirements are possible, depending on the requirements definition methods and/or the architecture and design methods being applied. (ISO/IEC 2011) provides a classification which is summarized in Table 2 (see references for additional classifications).<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Example of System Requirements Classification.''' (SEBoK Original)<br />
!Types of System Requirement<br />
!Description<br />
|-<br />
|'''Functional Requirements'''<br />
|Describe qualitatively the system functions or tasks to be performed in operation.<br />
|-<br />
|'''Performance Requirements'''<br />
|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. <br />
|-<br />
|'''Usability Requirements'''<br />
|Define the quality of system use (e.g. measurable effectiveness, efficiency, and satisfaction criteria).<br />
|-<br />
|'''Interface Requirements'''<br />
|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.<br />
|-<br />
|'''Operational Requirements'''<br />
|Define the operational conditions or properties that are required for the system to operate or exist. This type of requirement includes: human factors, ergonomics, availability, maintainability, reliability, and security.<br />
|-<br />
|'''Modes and/or States Requirements'''<br />
|Define the various operational modes of the system in use and events conducting to transitions of modes.<br />
|-<br />
|'''Adaptability Requirements'''<br />
|Define potential extension, growth, or scalability during the life of the system.<br />
|-<br />
|'''Physical Constraints'''<br />
|Define constraints on weight, volume, and dimension applicable to the system elements that compose the system.<br />
|-<br />
|'''Design Constraints'''<br />
|Define the limits on the options that are available 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).<br />
|-<br />
|'''Environmental Conditions'''<br />
|Define the environmental conditions to be encountered by the system in its different operational modes. This should address the natural environment (e.g. wind, rain, temperature, fauna, salt, dust, radiation, etc.), induced and/or self-induced environmental effects (e.g. motion, shock, noise, electromagnetism, thermal, etc.), and threats to societal environment (e.g. legal, political, economic, social, business, etc.).<br />
|-<br />
|'''Logistical Requirements'''<br />
|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.<br />
|-<br />
|'''Policies and Regulations'''<br />
|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.).<br />
|-<br />
|'''Cost and Schedule Constraints'''<br />
|Define, for example, the cost of a single exemplar of the system, the expected delivery date of the first exemplar, etc.<br />
|}<br />
</center><br />
<br />
===Requirements Management===<br />
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 providing 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. <br />
<br />
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|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.<br />
<br />
==Process Approach==<br />
===Purpose and Principle of the Approach===<br />
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).<br />
<br />
===Activities of the Process===<br />
Major activities and tasks during this process include:<br />
# Analyzing the stakeholder requirements to check completeness of expected services and [[Operational Scenario (glossary)|operational scenarios]], conditions, operational modes, and constraints.<br />
# Defining the system requirements and their [[Rationale (glossary)|rationale]].<br />
# Classifying the system requirements using suggested classifications (see examples above).<br />
# Incorporating the derived requirements (coming from architecture and design) into the system requirements baseline.<br />
# Establishing the upward traceability with the stakeholder needs and requirements. <br />
# Establishing bi-directional traceability between requirements at adjacent levels of the system hierarchy. <br />
# Verifying the quality and completeness of each system requirement and the consistency of the set of system requirements.<br />
# Validating the content and relevance of each system requirement against the set of stakeholder requirements.<br />
# Identifying potential [[Risk (glossary)|risks]] (or threats and hazards) that could be generated by the system requirements.<br />
# Synthesizing, recording, and managing the system requirements and potential associated risks.<br />
# Upon approval of the requirements, establishing control baselines along with the other system definition elements in conjunction with established configuration management practices.<br />
<br />
===Checking Correctness of System Requirements===<br />
System requirements should be checked to gauge whether they are well expressed and appropriate. There are a number of characteristics that can be used to check system requirements, such as standard peer review techniques and comparison of each requirement against the set of requirements characteristics, which are listed in Table 2 and Table 3 of the "Presentation and Quality of Requirements" section (below). Requirements can be further validated using the requirements elicitation and rationale capture described in the section "Methods and Modeling Techniques" (below).<br />
<br />
===Methods and Modeling Techniques===<br />
====Requirements Elicitation and Prototyping====<br />
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.<br />
<br />
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 to ensure that all aspects of user needs are accounted for and prioritized.<br />
<br />
Early prototyping can help the users and developers interactively identify functional and operational requirements as well as 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.<br />
<br />
====Capturing Requirements Rationale====<br />
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).<br />
<br />
Some of the benefits of this approach include:<br />
* '''Reducing the total number of requirements''' - The process aids in identifying duplicates. Reducing requirements count will reduce project cost and risk.<br />
* '''Early exposure of bad assumptions'''<br />
* '''Removes design implementation''' - Many poorly written stakeholder requirements are design requirements in disguise, in that the customer is intentionally or unintentionally specifying a candidate implementation. <br />
* '''Improves communication with the stakeholder community''' - By capturing the requirements rationale for all stakeholder requirements, the line of communication between the users and the designers is greatly improved. (Adapted from Chapter 8 of (Hooks and Farry 2000)).<br />
<br />
====Modeling Techniques====<br />
Modeling techniques that can be used when requirements must be detailed or refined, or in cases in which they address topics not considered during the stakeholder requirements definition and mission analysis, include:<br />
* State-charts models (ISO/IEC 2011, Section 8.4)<br />
* Scenarios modeling (ISO/IEC 2011, Section 6.2.3.1)<br />
* Simulations, prototyping (ISO/IEC 2011, Section 6.3.3.2)<br />
* Quality Function Deployment (INCOSE. 2010, p. 83)<br />
* Sequence diagrams, activity diagrams, use cases, state machine diagrams, Systems Modeling Language (SysML) requirements diagrams<br />
* Functional Flow Block Diagram for operational scenarios<br />
<br />
====Presentation and Quality of Requirements====<br />
Generally, requirements are provided in a textual form. Guidelines exist for writing good requirements; they include recommendations about the syntax of requirements statements, wording (exclusions, representation of concepts, etc.), and characteristics (specific, measurable, achievable, feasible, testable, etc.). Refer to INCOSE (2010, Section 4.2.2.2) and ISO/IEC (2011).<br />
<br />
There are several characteristics of both requirements and sets of requirements that are used to aid their development and to verify the implementation of requirements into the solution. Table 3 provides a list and descriptions of the characteristics for individual requirements and Table 4 provides a list and descriptions of characteristics for a set of requirements, as adapted from ISO/IEC (2011, Sections 5.2.5 and 5.2.6).<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 3. Characteristics of Individual Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Necessary'''<br />
|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.<br />
|-<br />
|'''Implementation Free'''<br />
|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.<br />
|-<br />
|'''Unambiguous'''<br />
|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.<br />
|-<br />
|'''Complete'''<br />
|The stated requirement needs no further amplification because it is measurable and sufficiently describes the capability and characteristics to meet the stakeholders' needs. <br />
|-<br />
|'''Singular'''<br />
|The requirement statement includes only one requirement with no use of conjunctions.<br />
|-<br />
|'''Traceable'''<br />
|The requirement is upwards traceable to specific documented stakeholder statement(s) of need, higher tier requirement, or another source (e.g., a trade or design study). The requirement is also downwards traceable to the specific requirements in the lower tier requirements specifications 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.<br />
|-<br />
|'''Verifiable'''<br />
|The requirement has the means to prove that the system satisfies the specified requirement. Verifiability is enhanced when the requirement is measurable.<br />
|}<br />
</center><br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 4. Characteristics of a Set of Requirements.''' (SEBoK Original)<br />
!Characteristic<br />
!Description<br />
|-<br />
|'''Complete'''<br />
|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 does not contain any 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. Note - Some practices are recommended to improve completeness: include all requirement types, account for requirements in all stages of the life cycle, and involve all stakeholders in the requirements elicitation activity.<br />
|-<br />
|'''Consistent'''<br />
|The set of requirements does not have individual requirements which are contradictory. Requirements are not duplicated. The same term is used for the same item in all requirements. There is nothing in the set of requirements as a whole to invalidate individual requirement traceability or verification.<br />
|-<br />
|'''Feasible'''<br />
|The set of requirements are technically achievable and fits within system constraints (e.g., cost, schedule, technical, lethal, regulatory, etc.). <br />
|-<br />
|'''Affordable'''<br />
|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, etc.).<br />
|-<br />
|'''Bounded'''<br />
|The set of requirements maintains the identified scope for the intended solution without increasing beyond what is necessary to satisfy user needs.<br />
|}<br />
</center><br />
<br />
====Requirements in Tables====<br />
Requirements may be provided in a table, especially when specifying a set of parameters for the system or a system element. It is good practice to make standard table templates available. For tables, the following conventions apply: <br />
* Invoke each requirements table in the requirements set that clearly points to the table.<br />
* Identify each table with a unique title and table number.<br />
* Include the word “requirements” in the table title.<br />
* Identify the purpose of the table in the text immediately preceding it and include an explanation of how to read and use the table, including context and units.<br />
* For independent-dependent variable situations, organize the table in a way that best accommodates the use of the information.<br />
* Each cell should contain, at most, a single requirement.<br />
<br />
====Requirements in Flow Charts====<br />
Flow charts often contain requirements in a graphical form. These requirements may include logic that must be incorporated into the system, operational requirements, process or procedural requirements, or other situations that are best defined graphically by a sequence of interrelated steps. For flow charts, the following conventions apply:<br />
* Invoke flow charts in the requirements set that clearly points to the flow chart.<br />
* Identify each flow chart with a unique title and figure number.<br />
* Include the word “requirements” in the title of the flow chart.<br />
* Clearly indicate and explain unique symbols that represent requirements in the flow chart.<br />
<br />
====Requirements in Drawings====<br />
Drawings also provide a graphical means to define requirements. The type of requirement defined in a drawing depends on the type of drawing. The following conventions apply:<br />
* Drawings are used when they can aid in the description of the following:<br />
** Spatial Requirements<br />
** Interface Requirements<br />
** Layout Requirements<br />
* Invoke drawings in the requirements set that clearly point to the drawing.<br />
<br />
===Artifacts===<br />
This process may create several artifacts, such as:<br />
* System Requirements Document<br />
* System Requirements Justification Document (for traceability purpose)<br />
* System Requirements Database, including traceability, analysis, rationale, decisions, and attributes, where appropriate.<br />
* System External Interface Requirements Document (this document describes the interfaces of the system with external elements of its context of use; the interface requirements can be integrated or not to the system requirements document.<br />
<br />
The content, format, layout and ownership of these artifacts will vary depending on who is creating them as well as in which domain they will be utilized. Between them and the outputs of the process, activities should cover the information identified in the first part of this article.<br />
<br />
<br />
==Practical Considerations about System Requirements==<br />
There are several '''pitfalls''' that will inhibit the generation and management of an optimal set of system requirements, as discussed in Table 5.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 5. Major Pitfalls with Definition of System Requirements.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Insufficient Analysis of Stakeholder Requirements'''<br />
|If he receivers of the stakeholder requirements do not perform a sufficient critical analysis of them, the consequence could be difficulties translating them into system requirements and the obligation to come back to the stakeholders, losing time.<br />
|-<br />
|'''Insufficient Analysis of Operational Modes and Scenarios'''<br />
|The operational modes and operational scenarios are not sufficiently analyzed or defined by the person in charge of writing the system requirements. Those elements allow the structuring of the system and its use early in the engineering process and help the designer to remember functions and interfaces.<br />
|-<br />
|'''Incomplete Set of System Requirements'''<br />
|If the system requirements are not sufficiently precise and complete, there is a great risk that the design will not have the expected level of quality and that the verification and validation of the system will be delayed.<br />
|-<br />
|'''Lack of Verification Method'''<br />
|Delaying the capture of verification methods and events for each system requirement; identification of the verification approach for each requirement often provides additional insight as to the correctness and necessity of the requirement itself.<br />
|-<br />
|'''Missing traceability'''<br />
|Incorrect or missing traceability of each requirement, both to an upper-level "parent" requirement as well as allocation to an inappropriate system or system element.<br />
|}<br />
</center><br />
<br />
<br />
The '''proven practices''' in Table 6 have repeatedly been shown to reduce project risk and cost, foster customer satisfaction, and produce successful system development.<br />
<br />
<br />
<center><br />
{|<br />
|+'''Table 6. Proven Practices for System Requirements.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|+<br />
|'''Involve Stakeholders'''<br />
|Involve the stakeholders as early as possible in the system requirements development process.<br />
|+<br />
|'''Presence of Rationale'''<br />
|Capture the rationale for each system requirement.<br />
|+<br />
|'''Always Complete before Starting'''<br />
|Check that stakeholder requirements are complete as much as possible before starting the definition of the system requirements.<br />
|+<br />
|'''Peer Reviews'''<br />
|Organize peer reviews of system requirements with applicable subject matter experts.<br />
|+<br />
|'''Modeling Techniques'''<br />
|Use modeling techniques as indicated in sections above.<br />
|+<br />
|'''Requirements Management Tool'''<br />
|Consider using a requirements management tool, especially for more complex projects. This tool should have the capability to trace linkages between system requirements to display relationships. A requirements management tool is intended to facilitate and support the systematic managing of system requirements throughout the project life cycle.<br />
|+<br />
|'''Measures for Requirement Engineering'''<br />
|Use typical measures for requirement engineering; for further information, refer to the ''Systems Engineering Leading Indicators Guide'' (Roedler et al. 2010). Both process and product measures should be used for requirements engineering. To get the desired insight to facilitate risk-managed requirements engineering, it may be necessary to use more than one measure based on the information needs (risks, objectives, issues) for the requirements. Useful measures include:<br />
* Requirements Volatility<br />
* Requirements Trends<br />
* Requirements Verification Progress (plan vs. actual)<br />
* Requirements Validation Progress (plan vs. actual)<br />
* TBD and TBR Closure Per Plan<br />
* Peer Review Defects<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Hauser, J. and D. Clausing. 1988. "The House of Quality." ''Harvard Business Review.'' (May - June 1988). <br />
<br />
Hooks, I.F., and K.A. Farry. 2000. ''Customer-centered products: Creating successful products through smart requirements management''. New York, NY, USA: American Management Association.<br />
<br />
Hull, M.E.C., Jackson, K., Dick, A.J.J. 2010. ''Systems Engineering''. 3rd ed. London, UK: Springer.<br />
<br />
INCOSE. 2011. ''Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities'' Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC. 2007. Systems and Software Engineering -- Recommended Practice for Architectural Description of Software-Intensive Systems. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 42010:2007.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and Software Engineering - Requirements Engineering''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148. <br />
<br />
ISO/IEC/IEEE. 2008. ''Systems and Software Engineering - System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).<br />
<br />
Martin, J.N. 1997. ''Systems Engineering Guidebook: A Process for Developing Systems and Products.'' 1st ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
===Primary References===<br />
<br />
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 29148|Systems and Software Engineering - Requirements Engineering]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), [[ISO/IEC/IEEE 29148]].<br />
<br />
ISO/IEC/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2008 (E).<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
Lamsweerde, A. van. 2009. ''[[Requirements Engineering]]: From System Goals to UML Models to Software Specifications''. New York, NY, USA: Wiley.<br />
<br />
===Additional References===<br />
<br />
Faisandier, A. 2012. ''Systems Opportunities and Requirements''. Belberaud, France: Sinergy'Com. <br />
<br />
Hooks, I.F., and K.A. Farry. 2000. ''Customer-Centered Products: Creating Successful Products through Smart Requirements Management.'' New York, NY, USA: American Management Association. <br />
<br />
Hull, M.E.C., K. Jackson, A.J.J. Dick. 2010. ''Systems Engineering''. 3rd ed. London, UK: Springer.<br />
<br />
Roedler, G., D. Rhodes, C. Jones, and H. Schimmoller. 2010. ''Systems Engineering Leading Indicators Guide''. Version 2.0. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2005-001-03.<br />
<br />
SEI. 2007. "Requirements Management Process Area" and "Requirements Development Process Area" in Capability Maturity Model Integrated (CMMI) for Development, version 1.2. Pittsburgh, PA, USA: Software Engineering Institute (SEI)/Carnegie Mellon University (CMU). <br />
<br />
----<br />
<br />
<center>[[System Definition|< Previous Article]] | [[System Definition|Parent Article]] | [[Logical Architecture Design|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Definition]]<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=System_Realization&diff=48051
System Realization
2013-04-19T18:09:12Z
<p>Eleach: </p>
<hr />
<div><html><br />
<meta name="citation_title" content="System Realization"><br />
<meta name="citation_author" content="Pyster, Art"><br />
<meta name="citation_author" content="Olwell, David H."><br />
<meta name="citation_author" content="Hutchison, Nicole"><br />
<meta name="citation_author" content="Enck, Stephanie"><br />
<meta name="citation_author" content="Anthony, James F., Jr."><br />
<meta name="citation_author" content="Henry, Devanandham"><br />
<meta name="citation_author" content="Squires, Alice (eds)"><br />
<meta name="citation_publication_date" content="2012/11/30"><br />
<meta name="citation_journal_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK)"><br />
<meta name="citation_volume" content="version 1.0.1"><br />
<meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page"></html><br />
[[System Realization (glossary)|System realization]] activities are conducted to create and test versions of a system as specified by [[System Definition (glossary) |system definition]]. The activities are grouped and described as generic processes that are performed iteratively and/or concurrently depending on the selected [[Life Cycle Model (glossary)]]. These activities include those required to build a system ([[Implementation (glossary)|system implementation]]), integrate disparate system elements ([[Integration (glossary)|system integration]]), and ensure that the system meets both the needs of stakeholders ([[Validation (glossary)|system validation]]) and aligns with the system requirements and architecture ([[Verification (glossary)|system verification]]). <br />
<br />
These activities are not sequential; their iteration and flow are depicted in Figure 1 (see "Overview", below), which also shows how these processes fit within the context of [[System Definition (glossary)]] and [[System Deployment and Use]] KAs. The specific activities and sequence of system realization activities will be dependent upon the type of life cycle model being utilized.<br />
<br />
<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into KAs, which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
* [[System Implementation]]<br />
* [[System Integration]]<br />
* [[System Verification]]<br />
* [[System Validation]]<br />
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.<br />
<br />
==Overview==<br />
Essentially, the outputs of [[System Definition (glossary)|system definition]] are used during [[Implementation (glossary)|system implementation]] to create [[System Element (glossary)|system elements]] and during [[Integration (glossary)|system integration]] to provide plans and criteria for combining these elements. The requirements are used to [[Verification (glossary)|verify]] and [[Validation (glossary)|validate]] system elements, systems, and the overall [[System-of-Interest (glossary)|system-of-interest]] (SoI). These activities provide feedback into the system design, particularly when problems or challenges are identified. <br />
<br />
Finally, when the system is considered, verified, and validated, it will then become an input to [[System Deployment and Use|system deployment and use]]. It is important to understand that there is overlap in these activities; they do not have to occur in sequence as demonstrated in Figure 1. Every life cycle model includes realization activities, principally, verification and validation activities. The way these activities are performed is dependent upon the life cycle model in use. (For additional information on life cycles, see the [[Life Cycle Models]] KA.) <br />
<br />
[[File:JS_Figure_1.png|thumb|600 px|center|'''Figure 1. System Realization.''' (SEBoK Original)]]<br />
<br />
The realization processes are performed to ensure that the system will be ready for transition and has the appropriate structure and behavior to enable the desired operation and functionality throughout the system’s life span. Both DAU and NASA include transition in realization, in addition to implementation, integration, verification, and validation (Prosnik 2010; NASA December 2007, 1-360).<br />
<br />
==Fundamentals==<br />
<br />
===Macro View of Realization Processes===<br />
<br />
Figure 2 illustrates a macro view of generic outputs from realization activities when using a Vee life cycle model. The left side of the Vee represents various design activities 'going down' the system.<br />
<br />
[[File:JS_Figure_2.png|thumb|600px|center|'''Figure 2. The Vee Activity Diagram (Prosnik 2010).''' Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).]] <br />
<br />
The left side of the Vee model demonstrates the development of system elements specifications and design descriptions. In this stage, verification and validation plans are developed, which are later used to determine whether realized system elements ([[Product (glossary)|products]], [[Service (glossary)|services]], or [[Enterprise (glossary)|enterprises]]) are compliant with specifications and [[Stakeholder Requirement (glossary)|stakeholder requirements]]. Also, during this stage initial specifications become flow-down requirements for lower-level system models. In terms of time frame, these activities take place early in the system’s life cycle. These activities are discussed further in the [[System Definition]] KA. However, it is important to understand that some of the system realization activities are initiated at the same time as system definition activities; this is the case with integration, verification and validation (IV&V) planning in particular.<br />
<br />
The right side of the Vee model, as illustrated in Figure 2, shows the system elements (products, services, or enterprises) are assembled according to the system model described on the left side of the Vee (integration). Verification and validation activities determine how well the realized system fulfills the stakeholder requirements, the system requirements, and [[Design Property (glossary)|design properties]]. These activities should follow the plans developed on the left side of the Vee. Integration can be done continuously, incrementally and/or iteratively, supported by verification and validation (V&V) efforts. For example, integration typically starts at the bottom of the Vee and continues upwards to the top of the Vee. <br />
<br />
The U.S. Defense Acquisition University (DAU) provides an overview of what occurs during system realization:<br />
<br />
<blockquote>''Once the products of all system models have been fully defined, Bottom-Up End Product Realization can be initiated. This begins by applying the Implementation Process to buy, build, code or reuse end products. These implemented end products are verified against their design descriptions and specifications, validated against Stakeholder Requirements and then transitioned to the next higher system model for integration. End products from the Integration Process are successively integrated upward, verified and validated, transitioned to the next acquisition phase or transitioned ultimately as the End Product to the user.'' (Prosnik 2010)</blockquote><br />
<br />
While the systems engineering (SE) technical processes are life cycle processes, the processes are concurrent, and the emphasis of the respective processes depends on the phase and maturity of the design. Figure 3 portrays (from left to right) a notional emphasis of the respective processes throughout the systems acquisition life cycle from the perspective of the U.S. Department of Defense (DoD). It is important to note that from this perspective, these processes do not follow a linear progression; instead, they are concurrent, with the amount of activity in a given area changing over the system’s life cycle. The red boxes indicate the topics that will be discussed as part of realization.<br />
<br />
[[File:JS_Figure_3.png|thumb|600px|center|'''Figure 3. Notional Emphasis of Systems Engineering Technical Processes and Program Life-Cycle Phases (DAU 2010).''' Released by the Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).]]<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
DAU. 2010. ''Defense Acquisition Guidebook (DAG)''. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD). February 19, 2010.<br />
<br />
Prosnik, G. 2010. Materials from "Systems 101: Fundamentals of Systems Engineering Planning, Research, Development, and Engineering". DAU distance learning program. eds. J. Snoderly, B. Zimmerman. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD).<br />
<br />
===Primary References===<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2008 (E).<br />
<br />
Martin, J.N. 1997. ''[[Systems Engineering Guidebook]]: A process for developing systems and products''. 1st ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.<br />
<br />
===Additional References===<br />
<br />
DAU. 2010. ''Defense Acquisition Guidebook (DAG)''. Ft. Belvoir, VA, USA: Defense Acquisition University (DAU)/U.S. Department of Defense (DoD). February 19, 2010.<br />
<br />
DAU. ''Your Acquisition Policy and Discretionary Best Practices Guide.'' In Defense Acquisition University (DAU)/U.S. Department of Defense (DoD) [database online]. Ft Belvoir, VA, USA. Available at: https://dag.dau.mil/Pages/Default.aspx (accessed 2010).<br />
<br />
ECSS. 2009. ''Systems Engineering General Requirements''. Noordwijk, Netherlands: Requirements and Standards Division, European Cooperation for Space Standardization (ECSS), 6 March 2009. ECSS-E-ST-10C.<br />
<br />
IEEE. 2012. "Standard for System and Software Verification and Validation". Institute of Electrical and Electronics Engineers. IEEE 1012.<br />
----<br />
<center>[[System Analysis|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[System Implementation|Next Article >]]</center><br />
<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 3]][[Category:Knowledge Area]]</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=System_Definition&diff=48049
System Definition
2013-04-18T22:36:40Z
<p>Eleach: </p>
<hr />
<div><html><br />
<meta name="citation_title" content="System Definition"><br />
<meta name="citation_author" content="Pyster, Art"><br />
<meta name="citation_author" content="Olwell, David H."><br />
<meta name="citation_author" content="Hutchison, Nicole"><br />
<meta name="citation_author" content="Enck, Stephanie"><br />
<meta name="citation_author" content="Anthony, James F., Jr."><br />
<meta name="citation_author" content="Henry, Devanandham"><br />
<meta name="citation_author" content="Squires, Alice (eds)"><br />
<meta name="citation_publication_date" content="2012/11/30"><br />
<meta name="citation_journal_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK)"><br />
<meta name="citation_volume" content="version 1.0.1"><br />
<meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page"></html><br />
[[System Definition (glossary)|System definition]] activities are conducted to describe in detail a system to satisfy an identified need. The activities are grouped and described as generic processes that are performed concurrently and/or iteratively depending on the selected [[Life Cycle Model (glossary)|life cycle model.]] These consist of the definition of [[System Requirement (glossary)|system requirements]], the definition of the [[Logical Architecture (glossary)| logical architecture]] and [[Physical Architecture (glossary) | physical architecture]], and [[System Analysis (glossary) | system analysis]]. During and/or at the end of any iteration, gap analysis is performed to ensure that all system requirements have been mapped to the architecture and design.<br />
<br />
System definition activities build on the artifacts and decisions from [[Concept Definition (glossary) | concept definition]], primarily the articulation of the [[Mission (glossary) | mission]] of the [[System-of-Interest (glossary)|system-of-interest]] (SoI), the [[Stakeholder Requirement (glossary)|needs and requirements of stakeholders]], and preliminary operational concepts. The products of system definition activities (system requirements, architecture, etc.) are inputs to [[System Realization (glossary) |system realization]]. The specific activities and sequence of system definition activities will be dependent upon the type of life cycle model being utilized.<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
*[[System Requirements]]<br />
*[[Logical Architecture Design]]<br />
*[[Physical Architecture Design]]<br />
*[[System Analysis]]<br />
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 to topics covered in Part 3.<br />
<br />
==System Views and System Elements ==<br />
An [[Engineered System (glossary)]] solution to a defined concept includes a defined set of engineering elements, characteristics, and properties. These elements are grouped in two ways: <br />
* Needs and requirements views<br />
* Architecture views<br />
<br />
Architecture views include the identification of the boundary and interfaces of a system-of-interest (SoI), which may then be further refined as a collection of [[System Element (glossary)|system elements]] and their relationships.<br />
<br />
===Requirements Views===<br />
<br />
Requirements provide an overall view of the [[Purpose (glossary)|purpose]] and [[Mission (glossary)|mission]] which the system as a whole is intended to satisfy, as well as a technology-independent view of that the system solutions(s) should do. They are conventionally organized into two types:<br />
<br />
*[[Stakeholder Requirement (glossary)|Stakeholder requirements]] are defined and discussed in the [[Concept Definition]] KA.<br />
<br />
*[[System Requirement (glossary)|System requirements]], which describe the functions which the system as a whole should fulfill in order to satisfy the stakeholder requirements and are expressed in an appropriate set of views, and non-functional requirements expressing the levels of safety, security, reliability, etc., which are called for. These collectively form the basis for [[Verification (glossary)|verification]] later in the life cycle.<br />
<br />
System requirements and stakeholder requirements are closely related. Neither can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed.<br />
<br />
The process activities that are used to identify, engineer and manage system requirements are described further in the [[System Requirements]] article in the KA.<br />
<br />
===Architecture Views===<br />
There are several architectural representations or views/models of the system:<br />
* The '''[[Logical Architecture (glossary)|logical architecture]]''' supports the logical operation of the system all along its life cycle, and may include functional, behavioral, and temporal views/models. Operational scenarios refine the mission into a collection of [[Function (glossary)|functions]] and dynamic structures that describe how the mission is performed (behavior).<br />
<br />
* The '''[[Physical Architecture (glossary)|physical architecture]]''' is a set of [[System Element (glossary)|system elements]] performing the functions of the system. Those system elements can be either material or immaterial (e.g., equipments made of hardware, software and/or human roles).<br />
<br />
The boundary of the system architectures depends on what engineers include within the scope of the SoI and outside of it. This decision marks the transition from the characterization of the problem context to the beginnings of solution definition.<br />
<br />
Facing the potential number of system elements that constitute the physical architecture, sets of system elements can be grouped to form systems. The decomposition of the SoI (highest level) may include the decomposition of several layers of systems (intermediate levels of systems) until technological system elements (lowest level) are defined. Any layer of the decomposition may include systems and non-decomposable technological system elements.<br />
<br />
Because a system element is primarily an engineered system, it can be characterized in its turn using the previous views in its own context. The notion of system as described and defined here is recursive, see the discussion of systems and engineered system contexts in [[What is a System?]] article. <br />
<br />
The logical and physical representations of the system architecture are mapped onto each other. The interactions between system elements are defined by interfaces whose complexity strongly depends on the way the system architecture is defined. The relationships between the outputs of concept definition and the system solution, as well as the range of other views of a system that are available to describe a more complete set of characteristics between the system elements are discussed further in the [[Logical Architecture Design|logical architecture]] and [[Physical Architecture Design|physical architecture]] sections of the KA.<br />
<br />
==Top-Down and Recursive Approach to System Decomposition==<br />
<br />
System definition is managed through methodical top-down decomposition of the SoI into systems and system elements. As the system architecture definition advances, emerging systems and system elements form a system breakdown structure (SBS). For project management purposes, every system of the SBS may be included in a ''building block'', a notion introduced in (ANSI/EIA 1998), also called ''system block''. <br />
<br />
[[Stakeholder Requirement (glossary)|Stakeholder requirements]] and [[System Requirement (glossary)|system requirements]] exist at all layers of the SBS. In ISO/IEC/IEEE (2011), these layers are known as levels of abstraction. Along with systematically introducing layers of systems, the architecture and design process manages the transformation of the [[System Requirements|system requirements]] through levels of abstraction. Figure 1 illlustrates this approach.<br />
<br />
[[File:SEBoKv05_KA-SystDef_Top-down_development_of_design_and_requirements.png|thumb|center|500px|center|'''Figure 1. Top-down Development of Architecture and Design, and Requirements (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
As shown in Figure 1<br />
* The white ovals represent requirements at decreasing levels of abstraction, and the arrows represent the transformation of those requirements through the levels using the architecture and design process. Stakeholder expressions of needs, expectations, and constraints are transformed into stakeholder requirements.<br />
* The next transformation crosses the boundary between the problem and solution areas by converting stakeholder requirements into system requirements, reflecting the bounded solution space.<br />
* At the SoI level, the system architecture is developed which serves to identify systems and system elements and establishes how they operate together to address the SoI requirements. <br />
<br />
This approach is applied recursively for each level of abstraction/decomposition recognizing that the same generic processes are applied at multiple levels of abstraction. Figure 2 below portrays the engineering that occurs in each system block. As necessary, system elements are defined through sets of system element requirements, which become inputs to other system blocks (''level n+1''). The approach is then recursively applied using the system definition processes.<br />
<br />
[[File:Recursive_Instantiation_of_Def_Process_AF_071112.png|thumb|center|700px|center|'''Figure 2. Recursive Instantiation of Definition Processes (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
At the ''n+1'' level, the systems or system elements may also collect other stakeholder requirements that are directly pertinent to this level of architecture and design. Processes within each system are generic, but unique in local purpose, scope and context.<br />
<br />
==System Architecture==<br />
Within the SE community, notions of architecture have been heavily influenced by ISO/IEC 15288 (2008), which even today presents a somewhat implicit view of architecture, conflating it with [[Design (glossary) |design]] as part of a single system life cycle process called ''architectural design''. Although there are diverse viewpoints on architecture, the different perspectives have much in common. The SEBoK considers systems engineering to cover all aspects of the creation of a system, including system architecture.<br />
<br />
The majority of interpretations of system architecture are based on the fairly intangible notion of ''structure'' (i.e. relationships between elements). <br />
<br />
Some authors limit the types of structure considered to be architectural; for example, restricting themselves to ''functional'' and ''physical'' structure. Recent practice has extended consideration to include ''temporal'' and other dimensions of structure within specified architectural frameworks (DoDAF (DoD 2010) and MODAF (MOD 2010)).<br />
<br />
ISO/IEC/IEEE 42010 (2011) provides a useful description of the architecture considering the stakeholder concerns, architecture viewpoints, architecture views, architecture models, architecture descriptions, and architecting throughout the life cycle. A discussion of the features of systems architectures can be found in Maier and Rechtin (2009).<br />
<br />
While architectural concepts are very useful and widely used in SE, there is a lack of consistency across communities of practice that creates the potential for confusion. An attempt to develop and apply a systematic approach to characterizing architecture belief systems in systems engineering has been described by the INCOSE UK Architecture Working Group (Wilkinson et al.2010, Wilkinson 2010).<br />
<br />
==System Design==<br />
<br />
In industrial practices, the term ''design'' is often used to mean both [[Architecture (glossary)]] and [[Design (glossary)]] as defined in the SEBoK. In the recent past, professionals used the term ''design'' when they dealt with simpler technological products - ones that do not include several different and interconnected technological components such as hardware, software, operators, services, etc. In the development of new multi-technology products and services, professionals have recognized the usefulness of the notion of ''system'' in dealing with [[Complexity (glossary)]] (interconnections level, multi-techno, emergence, etc.). <br />
<br />
It was due to complexity that structuring the elements that comprise a system became necessary. This structure explains the functional, behavioral, temporal, physical, and other aspects of a system as previously described. Practitioners found the term ''structure'' inadequate to describe all of these aspects of a system. The terms ''architecture'' and ''architectural design'' have been used for approximately 30 years, especially in software intensive systems and other domains, such as the space industry. The set of different types and interrelated structures can be understood as the architecture of the system.<br />
<br />
The trend today is to consider system architecture and system design as different sets of activities. Attempts are made to define separate concurrent processes, but they are strongly intertwined:<br />
<br />
* System design includes activities to conceive a system that answers a specific, intended purpose, using principles and concepts; it includes assessments and decisions to select elements that compose the system, fit the architecture of the system, and comply with traded-off system requirements. It is the complete set of detailed models, properties, and/or characteristics described into a form suitable for implementation. <br />
* System architecture is more abstract, conceptualization-oriented, global, and focused on mission success and on high level structure in (sub)systems. It may also be applied to more than one system, in some cases forming the common structure, pattern, and set of requirements for classes or families of similar or related systems.<br />
<br />
System design is intended to be the link between the system architecture (at whatever point this milestone is defined in the specific application of the systems engineering process) and the implementation of technological system elements that compose the physical architecture of the system.<br />
<br />
These related processes are presented together in the present version of the SEBoK, though effort has been made to distinguish between the corresponding activities.<br />
<br />
==General System Architecture and Design Principles and Concepts==<br />
<br />
===Classification of Principles and Heuristics===<br />
<br />
Engineers and architects use a mixture of mathematical principles and heuristics that are learned through experience. When an issue is identified through system requirements, principles and heuristics may or may not be able to address it. Principles and heuristics that are used in system views/models can be classified according to the domains in which those system views/models are used, as follows:<br />
<br />
# '''Static domain''' relates to physical structure or organization of the SoI broken down into systems and [[System Element (glossary)|system elements]]. It deals with partitioning systems, system elements, and physical interfaces.<br />
# '''Dynamic domain''' relates to logical architecture models; in particular, to the representation of the behavior of the system. It includes a description of functions (i.e. transformations of input/output flows) and interactions between functions of the system and between those of the external objects or systems. It takes into account reactions to events that launch or stop the execution of functions of the system. It also deals with the effectiveness (i.e. performances, operational conditions) of the system.<br />
# '''Temporal domain''' relates to temporal invariance levels of the execution of functions of the system. This means that every function is executed according to cyclic or synchronous characteristics. It includes decisional levels that are asynchronous characteristics of the behavior of some functions.<br />
# '''Environmental domain''' relates to enablers (production, logistics support, etc.), but also to the [[Survivability (glossary)|survivability]] of the system in reaction to natural hazards or threats and to the [[Integrity (glossary)|integrity]] of the system in reaction to internal potential hazards. This includes, for example, climatic, mechanical, electromagnetic, and biological aspects.<br />
<br />
More detailed classification can be found in Maier and Rechtin (2009).<br />
<br />
===Transition from System Requirements to Physical Architecture===<br />
<br />
The aim of the approach is to progress from system requirements (representing the problem from a supplier/designer point of view, as independent of technology as possible) to an intermediate model of [[Logical Architecture (glossary)]], then to allocate the elements of the logical architecture to system elements of candidate [[Physical Architecture (glossary)|physical architectures]]. <br />
<br />
(System requirements and logical architecture share many characteristics, as they are both organized on functional lines, independently of the implementation. Some authors (Stevens et al 1998) go so far as to conflate the two, which simplifies the handling of multiple simultaneous views. Whether this approach is adopted depends on the specific practices of the development organization and where contractual boundaries are drawn.) <br />
<br />
Design decisions and technological solutions are selected according to performance criteria and non-functional requirements, such as operational conditions and life cycle constraints (e.g., environmental conditions, maintenance constraints, realization constraints, etc.), as illustrated in Figure 3. Creating intermediate models, such as logical architecture models, facilitates the validation of functional, behavioral, and temporal properties of the system against the system requirements that have no major technological influence impacts during the life of the system, the physical interfaces, or the technological layer without completely questioning the logical functioning of the system.<br />
<br />
[[File:SEBoKv075_KA-SystDef_Progressive_Approach_for_Designing.png|600px|thumb|center|'''Figure 3. Usage of Intermediate Logical Architecture Models During Architecture and Design (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
===Iterations between Logical and Physical Architecture Definition===<br />
<br />
Architecture and design activities require spending several iterations from logical architecture models definitions to physical architecture models definitions and vice versa, until both logical and physical architecture models are exhaustive and consistent. The first architecture and design activity is the creation of a logical architecture model based on nominal scenarios (of functions). Physical architecture is used to determine main system elements that could perform system functions and to organize them into a physical architecture model.<br />
<br />
A second logical architecture iteration can take into account allocations of functions to system elements and derived functions coming from physical solution choices. It also supplements the initial logical architecture model by introducing other scenarios, failure analyses, and every operational requirement not previously considered. Derived functions must be allocated to system elements; in turn, this affects the physical architecture models.<br />
<br />
Additional architecture and design iterations can produce a through and consistent logical and physical solution. During system design, technological choices can potentially lead to new functions, new input/output and control flows, and new physical interfaces. These new elements can lead to creation of new system requirements, called ''derived requirements''.<br />
<br />
===Concept of Interface===<br />
<br />
The concept of [[Interface (glossary)|interface]] is one of the most important to consider when defining the architecture of a system. The fundamental aspect of an interface is functional and is defined as inputs and outputs of functions. As functions are performed by physical elements (system elements), inputs/outputs of functions are also carried by physical elements; these are called physical interfaces. Consequentially, both functional and physical aspects are considered in the notion of interface. A detailed analysis of an interface shows the function ''“send”'' located in one system element, the function ''“receive”'' located in the other one, and the function ''“carry"'' as being performed by the physical interface that supports the input/output flow (see Figure 5).<br />
<br />
[[File:SEBoKv075_KA-SystDef_Complete_Interface_Representation.png|400px|thumb|center|'''Figure 4. Complete Interface Representation (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]] <br />
<br />
In the context of complex exchanges between system elements, particularly in software-intensive systems, a protocol is seen as a physical interface that carries exchanges of data.<br />
<br />
===Reuse of System Elements===<br />
Systems engineers frequently utilize existing system elements. This reuse constraint has to be identified as a system requirement and carefully taken into account during architecture and design. One can distinguish three general cases involving system element reuse, as shown in Table 1.<br />
<br />
<center><br />
{|<br />
|+'''Table 1. System Element Re-use Cases (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.<br />
!Re-use Case<br />
!Actions and Comments<br />
|-<br />
|'''Case 1:''' The requirements of the system element are up-to-date and it will be re-used with no modification required.<br />
|<br />
* The system architecture to be designed will have to adapt to the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element.<br />
* If the system element is not adapted, it is probable that costs, complexity, and risks will increase.<br />
|-<br />
|'''Case 2:''' The requirements of the system element are up-to-date and it will be re-used with possible modifications.<br />
|<br />
* The system architecture to be designed is flexible enough to accommodate the boundaries, interfaces, functions, effectiveness, and behavior of the re-used system element.<br />
* The design of the reused system element, including its test reports and other documentation, will be evaluated and potentially redesigned.<br />
|-<br />
|'''Case 3:''' The requirements are not up-to-date or do not exist.<br />
|<br />
* It is necessary to reverse engineer the system element to identify its boundaries, interfaces, functions, performances, and behavior.<br />
* This is a difficult activity, since the extant documentation for the re-used system element is likely unavailable or insufficient.<br />
* Reverse engineering is expensive in terms of both time and money, and brings with it increased risk.<br />
|}<br />
</center><br />
<br />
<br />
There is a common idea that reuse is ''free''; however, if not approached correctly, reuse may introduce risks that can be significant for the project (costs, deadlines, complexity).<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
<br />
ANSI/IEEE. 2000. ''Recommended Practice for Architectural Description for Software-Intensive Systems''. New York, NY, USA: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.<br />
<br />
ANSI/EIA. 1998. ''Processes for Engineering a System''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA-632-1998. <br />
<br />
DOD. 2010. “DOD Architecture Framework.” Version 2.02. Arlington, VA, USA: US Department of Defense. Available at: http://cio-nii.defense.gov/sites/dodaf20/<br />
<br />
Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.<br />
<br />
INCOSE. 2010. ''INCOSE Systems Engineering Handbook''. Version 3.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2. <br />
<br />
ISO/IEC 2008. ''Systems and Software Engineering -- System Life Cycle Processes.'' Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions. ISO/IEC/IEEE 15288:2008 (E).<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering - Requirements Engineering''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.<br />
<br />
ISO/IEC/IEEE. 2011. ''Systems and software engineering - Architecture description.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.<br />
<br />
Maier, M., and E. Rechtin. 2009. ''The Art of Systems Architecting.'' 3rd ed. Boca Raton, FL, USA: CRC Press. <br />
<br />
MOD. 2010. “MOD Architecture Framework”. Version 1.2.004. UK Ministry of Defence. Available at: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/.<br />
<br />
Stevens, R. P. Brook, K. Jackson, S. Arnold. 1998. ''Systems Engineering - Coping with Complexity''. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Wilkinson, M., A. James, M. Emes, P. King, P. Bryant. 2010. “Belief Systems in Systems Architecting: Method and Preliminary Applications," paper presented at the IEEE SMC Society’s 5th International Conference on System of Systems Engineering (SoSE). 22nd-24th June 2010. Loughborough University, UK.<br />
<br />
Wilkinson, M. K. 2010. “Z8: Systems Architecture”, in Z-guide series. INCOSE UK, available from INCOSE UK at: http://www.incoseonline.org.uk/Program_Files/Publications/zGuides.aspx?CatID=Publications<br />
<br />
===Primary References===<br />
<br />
ANSI/EIA. 1998. ''[[ANSI/EIA 632|Processes for Engineering a System]]''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), [[ANSI/EIA 632]]-1998. <br />
<br />
Blanchard, B. S., and W. J. Fabrycky. 2005. ''[[Systems Engineering and Analysis]].'' 4th ed. Prentice-Hall International Series in Industrial and Systems Engineering. Englewood Cliffs, NJ, USA: Prentice-Hall. <br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC. 2007. ''[[ISO/IEC 26702|Systems Engineering – Application and Management of The Systems Engineering Process]]''. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), [[ISO/IEC 26702]]:2007.<br />
<br />
ISO/IEC/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2008 (E).<br />
<br />
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 29148|Systems and Software Engineering - Requirements Engineering]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), [[ISO/IEC/IEEE 29148]].<br />
<br />
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|Systems and Software Engineering - Architecture Description]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 42010]].<br />
<br />
Martin, J.N. 1997. ''[[Systems Engineering Guidebook]]: A process for developing systems and products''. 1st ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
NASA. 2007. ''[[NASA Systems Engineering Handbook|Systems Engineering Handbook]].'' Washington, D.C.: National Aeronautics and Space Administration (NASA), NASA/SP-2007-6105.<br />
<br />
===Additional References===<br />
Baldwin, Carliss Y., and Kim B. Clark. 2000. ''Design Rules''. Cambridge, Mass: MIT Press.<br />
<br />
Buede, D.M. 2009. ''The Engineering Design of Systems: Models and Methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc. <br />
<br />
DoD. 2010. ''DOD Architecture Framework.'' Version 2.02. Arlington, VA, USA: US Department of Defense. Available at: http://cio-nii.defense.gov/sites/dodaf20/<br />
<br />
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.<br />
<br />
Hatley, Derek J., and Imtiaz A. Pirbhai. 1987. ''Strategies for Real-Time System Specification''. New York, NY: Dorset House Pub.<br />
<br />
MOD. 2010. ''MOD Architecture Framework''. Version 1.2.004. UK Ministry of Defence. Available at: http://www.mod.uk/DefenceInternet/AboutDefence/WhatWeDo/InformationManagement/MODAF/.<br />
<br />
Stevens, R. P. Brook, K. Jackson, S. Arnold. 1998. ''Systems Engineering - Coping with Complexity''. Englewood Cliffs, NJ, USA: Prentice-Hall.<br />
<br />
Wilkinson, M., A. James, M. Emes, P. King, P. Bryant. 2010. ''Belief Systems in Systems Architecting: Method and Preliminary Applications''. paper presented at the IEEE SMC Society’s 5th International Conference on System of Systems Engineering (SoSE). 22nd-24th June 2010. Loughborough University, UK.<br />
<br />
----<br />
<center>[[Stakeholder Needs and Requirements|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[System Requirements|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category: Part 3]][[Category:Knowledge Area]]<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Stakeholder_Needs_Definition&diff=48009
Stakeholder Needs Definition
2013-04-18T18:43:21Z
<p>Eleach: </p>
<hr />
<div>[[Stakeholder Requirement (glossary)|Stakeholder requirements]] represent the views of [[User (glossary)|users]], [[Acquirer (glossary)|acquirers]], [[Customer (glossary)|customers]], and other [[Stakeholder (glossary)|stakeholders]] as they relate to a the problem (or opportunity), as a set of requirements for a solution that can provide the services needed by the stakeholders in a defined environment. Stakeholder requirements describe the overall objectives of the system, its principal stakeholders, its context of use, the specific needs which should be satisfied, and how success will be assessed.<br />
<br />
Stakeholder requirements play major roles in systems engineering, as they:<br />
* Form the basis of [[System Requirement (glossary)|system requirements]] activities.<br />
* Form the basis of system [[Validation (glossary)|validation]] and stakeholder acceptance .<br />
* Act as a reference for [[Integration (glossary) | integration]] and [[Verification (glossary)|verification]] activities.<br />
* Serve as means of communication between the technical staff, management, finance department, and the stakeholder community.<br />
<br />
This topic provides knowledge about the idea of stakeholder needs and requirements which involves the activities necessary to elicit and prioritize the needs of the stakeholder(s), and transforming those needs into stakeholder requirements. The definition of the set of stakeholder requirements is the primary outcome of these activities which begin in [[Concept Definition (glossary) | concept definition]] stage. Defining the problem or the issue to be solved, identifying the opportunity for developing a new solution , or improving a system-of-interest (SoI) must begin prior to starting the activities necessary to define stakeholder needs and requirements. This means that an initial context of use of the new or modified mission, operation, or capability has already been characterized (see the [[Mission Analysis]] topic). System requirements are considered in detail during [[System Definition (glossary) | system definition]]. None of the above can be considered complete until consistency between the two has been achieved, as demonstrated by traceability, for which a number of iterations may be needed. <br />
<br />
<br />
==Purpose and Definition==<br />
The purpose of defining stakeholder requirements is to elicit a set of needs related to a new or changed mission for an enterprise (see [[Mission Analysis]] (MA) for information relevant to identifying and defining the mission or operation), and to transform these needs into clear, concise, and verifiable stakeholder requirements.<br />
<br />
[[Stakeholder (glossary)|stakeholder]] needs analysis is the elicitation, communication, [[Validation (glossary)|validation]] and refinement of the needs and objectives of the enterprise or set of stakeholders. Stakeholder needs analysis is aimed at understanding a potential capability (often identified through MA) that is required to address an identified problem or opportunity. Data from the needs analysis and the MA are used to transform the defined set of needs into stakeholder requirements (also known as mission requirements) that reflect these needs.<br />
<br />
The set of stakeholder needs, desires, and expectations may contain vague, ambiguous, and qualitative ''user-oriented'' need statements that are difficult to use for SE activities. These statements may need to be further clarified and translated into more ''engineering-oriented'' language to enable proper architecture definition and requirement activities. As an example, a need or an expectation such as, ''to easily maneuver a car in order to park'', will be transformed in a set of [[Stakeholder Requirement (glossary)|stakeholder requirements]] to a statement such as, ''increase the drivability of the car'', ''decrease the effort for handling'', ''assist the piloting'', ''protect the coachwork against shocks or scratch'', etc.<br />
<br />
==Principles and Concepts==<br />
<br />
===From the Capture of Needs to the Definition of Stakeholder Requirements===<br />
Several steps are necessary to understand the maturity of stakeholder needs and to understand how to improve upon that maturity. Figure 1 presents the ''cycle of needs'' as it can be deduced from Professor Shoji Shiba's and Professor Noriaki Kano's works and courses, and is adapted here for systems engineering (SE) purposes.<br />
<br />
[[File:SEBoKv05_KA-SystDef_Cycle_of_needs.png|600px|thumb|center| '''Figure 1. Cycle of Needs (Faisandier 2012).''' Permission granted by Singery'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
Figure 1 shows the steps and the position of the stakeholder requirements and system requirements in the engineering cycle. Below are explanations of each stage of requirements (Faisandier 2012); to illustrate this, consider this example of a system related to infectious disease identification: <br />
<br />
* '''Real needs''' are those that lie behind any perceived needs (see below); they are conditioned by the context in which people live. As an example, a generic need could be the ability to ''identify infectious diseases easily.'' Often, real needs appear to be simple tasks.<br />
* '''Perceived needs''' are based on a person’s awareness that something is wrong, that something is lacking, that improvements could be made, or that there are business, investment, or market opportunities that are not being capitalized upon. Perceived needs are often presented as a list of organized expectations resulting from an analysis of the usage conditions for the considered action (see the [[Mission Analysis]] topic). Following from the infectious disease example above, the real need might be perceived as a need to ''carry out medical tests in particular circumstances (laboratories, points of care, hospitals, and/or human dispensaries).'' Since the real need is seldom clearly expressed, richness of the knowledge of the perceived needs is used as a basis for potential solutions. This step has to be as complete as possible to cover all the contexts of use.<br />
* '''Expressed needs''' originate from perceived needs in the form of generic actions or constraints, and are typically prioritized. In the example, if safety is the primary concern, the expressed need to ''protect the operator against contamination'' may take priority over other expressed needs such as ''assist in the execution of tests.'' When determining the expressed needs, the analysis of the expected mission or services in terms of operational scenarios takes place. <br />
* '''Retained needs''' are selected from the expressed needs. The selection process uses the prioritization of expressed needs to achieve a solution or to make attaining solutions feasible. The retained needs allow the consideration of potential solutions for a SoI. These retained ''stakeholder intentions do not serve as stakeholder requirements, since they often lack definition, analysis, and possibly consistency and feasibility. Using the concept of operations to aid the understanding of the stakeholder intentions at the organizational level and the system operational concept from the system perspective, requirements engineering leads stakeholders from those initial intentions to structured and more formal stakeholder requirement statements'' (ISO/IEC/IEEE 29148 2011). Characteristics of good requirements can be found in ISO/IEC/IEEE 29148 (2011). Exploration of potential solutions must start from this step. The various solutions suggested at this step are not yet products, but describe means of satisfying the stakeholder requirements. Each potential solution imposes constraints on the potential future SoI.<br />
* '''Specified needs''', generally called [[System Requirement (glossary) |system requirements (glossary)]], are the translation of the stakeholder requirements to represent the views of the supplier, keeping in mind the potential, preferred, and feasible solutions. Consistent practice has shown this process requires [[Iteration (glossary)|iterative]] and [[Recursion (glossary)|recursive]] steps in parallel with other life cycle processes through the system design hierarchy (ISO/IEC/IEEE 29148 2011). <br />
* '''Realized needs''' are the product, service, or enterprise realized, taking into account every system requirement (and hence, the stakeholder requirements).<br />
<br />
Each class of needs listed above aligns with an area of the SE process. For example, the development of ''specified needs'' requirements is discussed in the [[System Requirements]] topic. For more information on how requirements are used in the systems engineering process, please see the [[System Definition]] knowledge area (KA).<br />
<br />
===Identifying Stakeholders and their Requirements===<br />
Stakeholders of a SoI may vary throughout the [[Life Cycle (glossary)|life cycle]]. Thus, in order to get a complete set of needs and subsequent requirements, it is important to consider all stages of the life cycle when identifying the stakeholders or classes of stakeholders. <br />
<br />
Every system has its own stages of life, which typically include stages such as concept, development, production, operations, sustainment, and retirement (for more information, please see [[Life Cycle Models]]). For each stage, a list of all stakeholders having an interest in the future system must be identified. The goal is to get every stakeholder’s point of view for every stage of the system life in order to consolidate a complete set of stakeholder needs that can be prioritized and transformed into the set of stakeholder requirements as exhaustively as possible. Examples of stakeholders are provided in Table 1.<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Stakeholder Identification Based on Life Cycle Stages.''' (SEBoK Original)<br />
!Life Cycle Stage<br />
!Example of Related Stakeholders<br />
|-<br />
|Engineering<br />
|Acquirer, panel of potential users, marketing division, research and development department, standardization body, suppliers, verification and validation team, production system, regulator/certification authorities, etc.<br />
|-<br />
|Development<br />
|Acquirer, suppliers (technical domains for components realization), design engineers, integration team, etc.<br />
|-<br />
|Transfer for Production or for Use<br />
|Quality control, production system, operators, etc.<br />
|-<br />
|Logistics and Maintenance<br />
|Supply chain, support services, trainers, etc.<br />
|-<br />
|Operation<br />
|Normal users, unexpected users, etc.<br />
|-<br />
|Disposal<br />
|Operators, certifying body, etc.<br />
|}<br />
</center><br />
<br />
<br />
There are many ways to collect stakeholder needs, expectations, and objectives. Some of the most common techniques are interviews (including user surveys), technical, operational, and strategy document reviews, analysis of potential hazards and threats coming from the context of use of the system, feedback from [[System Verification|verification]] and [[System Validation|validation]] processes, and review of the outcomes from the [[System Analysis|system analysis]] process (ISO/IEC 2008). Stakeholder requirements are developed from these needs.<br />
<br />
===Classification of Stakeholder Requirements===<br />
Several classifications of stakeholder requirements are possible, e.g. ISO/IEC 29148, section 9.4.2.3 (ISO/IEC 2011) provides a useful set of elements for classification. One possible way to classify the stakeholder requirements is under the categories indicated in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Example of Stakeholder Requirements Classification.''' (SEBoK Original)<br />
!Type of Stakeholder Requirement<br />
!Description<br />
|-<br />
|'''Service or Functional'''<br />
|Sets of actions to perform the mission or operation of the system-of-interest; enhanced by effectiveness or performance characteristics attached to the mission or operations.<br />
|-<br />
|'''Operational'''<br />
|This category may include:<br />
*Operational concepts that indicate the operational features to be provided without specifying design solutions.<br />
*Operational scenarios describing the sequence or series of activities supported by the system-of-interest.<br />
*Operational modes and transitions of modes between states/modes of the system-of-interest during its utilization to include dynamic interactions between the system-of-interest (viewed as a black box) and the system-of-interest's interface with external components in the context of its use.<br />
|-<br />
|'''Interface'''<br />
|Matter, energy, or information flows exchanged between the system-of-interest and its external components in the context of its use, including physical interfaces.<br />
|-<br />
|'''Environmental'''<br />
|External conditions that affect the system when in operation.<br />
|-<br />
|'''Utilization Characteristics'''<br />
|The '-ilities' used to indicate conditions of the utilization of the system-of-interest (e.g. usability, dependability, security, etc.).<br />
|-<br />
|'''Human Factors'''<br />
|Capabilities of users and operators, ergonomics, and associated constraints.<br />
|-<br />
|'''Logistical'''<br />
|Acquisition, transportation, and storage of elements needed by the system-of-interest to perform its services (e.g. constraints for logistical support).<br />
|-<br />
|'''Design and Realization Constraints'''<br />
|Reuse of existing system elements or forbidden materials, for example.<br />
|-<br />
|'''Process Constraints'''<br />
|These are stakeholder (usually acquirer or user) requirements imposed through the contract or statement of work. These requirements do not directly address the end-item system, but rather ''how'' the end-item system will be developed and provided. Process requirements include compliance with national, state, or local laws, such as environmental laws, administrative requirements, acquirer/supplier relationship requirements, and specific work directives. Process requirements may also be imposed on a program by corporate policy or practice. System or system element implementation process requirements, such as mandating a particular design method, are usually captured in project agreement documentation such as contracts, statements of work (SOW), and quality plans.<br />
|-<br />
|'''Project Constraints'''<br />
|Constraints to performing the project and/or the end-item system within cost and schedule.<br />
|-<br />
|'''Business Model Constraints'''<br />
|Constraints related to the expected business goal achieved by the system-of-interest, when this is relevant within the context of use, which may include: geographic position (local, national, international) of the future product, service, or organization resulting from the system-of-interest, distribution channels, alliance and partnership, finance and revenue model, etc.<br />
|}<br />
</center><br />
<br />
==Process Approach==<br />
<br />
===Activities of the Process===<br />
Major activities and tasks performed during this process include the following:<br />
* Identify the stakeholders or classes of stakeholders across the life cycle.<br />
* Elicit, capture, or consolidate the stakeholders' needs, expectations, and objectives as well as any constraints coming from the mission and business analysis processes.<br />
*Prioritize the stakeholder needs.<br />
*Transform the prioritized and retained stakeholder needs into stakeholder requirements.<br />
* Verify the quality of each stakeholder requirement and of the set of stakeholder requirements using the characteristics of good requirements identified in the [[System Requirements]] article.<br />
* Validate the content and the relevance of each stakeholder requirement with corresponding stakeholder representatives providing [[Rationale (glossary)|rationale (glossary)]] for the existence of the requirement.<br />
* Identify potential [[Risk (glossary) |risks]] (or threats and hazards) that could be generated by the stakeholder requirements (for further information, see [[Risk Management]]).<br />
* Synthesize, record, and manage the stakeholder requirements and potential associated risks.<br />
<br />
===Artifacts, Methods and Modeling Techniques===<br />
<br />
This process may create several artifacts, such as:<br />
* Stakeholder requirements documents<br />
* Stakeholder interview reports<br />
* Stakeholder requirements database<br />
* Stakeholder requirements justification documents (for traceability purposes)<br />
<br />
The content, format, layout and ownership of these artifacts will vary depending on who is creating them and in which domains they will be used. Between these artifacts and the outputs of the process, activities should cover the information identified in the first part of this article.<br />
<br />
It is recommended that several techniques or methods for identifying needs, expectations, and requirements be considered during the elicitation activity to better accommodate the diverse set of requirements sources, including: <br />
* Structured brainstorming workshops<br />
* Interviews and questionnaires <br />
* Technical, operational, and/or strategy documentation review <br />
* Simulations and visualizations<br />
* Prototyping<br />
* Modeling<br />
* Quality function deployment (QFD) - can be used during the needs analysis and is a technique for deploying the "voice of the customer” (It provides a fast way to translate customer needs into requirements)<br />
* Use case diagrams (OMG 2010)<br />
* Activity diagrams (OMG 2010)<br />
* Functional flow block diagrams<br />
<br />
==Practical Considerations==<br />
Major pitfalls encountered with stakeholder requirements are presented in Table 3.<br />
<br />
<center><br />
{|<br />
|+'''Table 3. Major Pitfalls for Stakeholder Requirements.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Operator Role Not Considered'''<br />
|Sometimes engineers do not take into account the humans acting as operators inside a system or those who use the system and are outside of the system. As a consequence, elements are forgotten (e.g. roles of operators).<br />
|-<br />
|'''Exchanges with External Objects Forgotten'''<br />
|The exhaustiveness of requirements can be an issue; in particular, the interfaces with external objects of the context of the system can be forgotten (exchanges of matter, energy, information).<br />
|-<br />
|'''Physical Connections with External Objects Forgotten'''<br />
|Within the interface issue, physical connections of the system-of-interest with external objects can be forgotten (technological constraints).<br />
|-<br />
|'''Forgotten Stakeholders'''<br />
|Stakeholders can be forgotten, as everyone thinks of direct users, customers, and suppliers; however, one may fail to consider those who do not want the system to exist and malevolent persons.<br />
|}<br />
</center><br />
<br />
<br />
Proven practices with stakeholder requirements are presented in Table 4.<br />
<br />
<center><br />
{|<br />
|+'''Table 4. Stakeholder Requirements Proven Practices.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|'''Involve Stakeholders'''<br />
|Involve the stakeholders early in the stakeholder requirements development process.<br />
|-<br />
|'''Presence of Rationale'''<br />
|Capture the rationale for each stakeholder requirement.<br />
|-<br />
|'''Analyze Sources before Starting'''<br />
|Complete stakeholder requirements as much as possible before starting the definition of the system requirements.<br />
|-<br />
|'''Modeling Techniques'''<br />
|Use modeling techniques as indicated in sections above.<br />
|-<br />
|'''Requirements Management Tool'''<br />
|Consider using a requirements management tool. This tool should have the capability to trace linkages between the stakeholder requirements and the system requirements and to record the source of each stakeholder requirement.<br />
|}<br />
</center><br />
<br />
==References==<br />
===Works Cited===<br />
Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.<br />
<br />
OMG. 2010. ''OMG Systems Modeling Language specification'', version 1.2, July 2010. http://www.omg.org/technology/documents/spec_catalog.htm.<br />
<br />
ISO/IEC/IEEE. 2011. Systems and software engineering - Requirements engineering. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.<br />
<br />
ISO/IEC/IEEE. 2008. ''Systems and Software Engineering - System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).<br />
<br />
===Primary References===<br />
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 29148|Systems and software engineering - Requirements engineering]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), ISO/IEC/IEEE 29148.<br />
<br />
ISO/IEC/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2008 (E).<br />
<br />
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|Systems and Software Engineering - Architecture Description]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 42010]].<br />
<br />
===Additional References===<br />
Buede, D.M. 2009. ''The engineering design of systems: Models and methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc. <br />
<br />
MITRE. 2011. "Requirements Engineering." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/se_lifecycle_building_blocks/requirements_engineering/]].<br />
<br />
MITRE. 2011. "Stakeholder Assessment and Management." ''Systems Engineering Guide. '' Accessed 9 March 2012 at [[http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/transformation_planning_org_change/stakeholder_assessment_management.html]].<br />
----<br />
<center>[[Mission Analysis|< Previous Article]] | [[Concept Definition|Parent Article]] | [[System Definition|Next Article >]]</center><br />
<br />
[[Category:Concept Definition]]<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Business_and_Mission_Analysis&diff=47888
Business and Mission Analysis
2013-04-17T21:25:44Z
<p>Eleach: </p>
<hr />
<div><html><br />
<meta name="citation_title" content="Concept Definition"><br />
<meta name="citation_author" content="Pyster, Art"><br />
<meta name="citation_author" content="Olwell, David H."><br />
<meta name="citation_author" content="Hutchison, Nicole"><br />
<meta name="citation_author" content="Enck, Stephanie"><br />
<meta name="citation_author" content="Anthony, James F., Jr."><br />
<meta name="citation_author" content="Henry, Devanandham"><br />
<meta name="citation_author" content="Squires, Alice (eds)"><br />
<meta name="citation_publication_date" content="2012/11/30"><br />
<meta name="citation_journal_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK)"><br />
<meta name="citation_volume" content="version 1.0.1"><br />
<meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page"></html><br />
[[Concept Definition (glossary) | Concept definition]] is the set of systems engineering (SE) activities in which the problem space and the needs of [[Stakeholder (glossary)|stakeholders]] are closely examined. This begins before any formal definition of the [[System-of-Interest (glossary)|system-of-interest]] (SoI) is developed. The activities are grouped and described as generic processes that are performed concurrently and/or iteratively depending on the selected [[Life Cycle Model (glossary) | life cycle model]].<br />
<br />
[[Mission Analysis (glossary)|Mission analysis]] focuses on defining the problem or opportunity that exists (often called the problem space), as well as understanding the constraints on and boundaries of the solution space. It examines why a solution is desired and what problem or opportunity it will address. [[Stakeholder Requirement (glossary)|Stakeholder needs and requirements]] explores and defines the operational aspects of a potential solution for the stakeholders from their point of view, independent of any specific solution. It describes ''what'' a solution should accomplish. Both ''why'' and ''what'' need to be answered before consideration is given to ''how'' the problem will be addressed (i.e., what type of solution will be implemented) and ''how'' the solution will be defined and developed. <br />
<br />
If a new or modified system is needed then [[System Definition (glossary) | system definition]] activities are performed to assess the system. The specific activities and sequence of concept activities and their involvement in the life cycle activities of any system solutions, will be dependent upon the type of life cycle model being utilized. <br />
<br />
Various authors use different terms to describe these phases. For example, Kossiakoff and Sweet (2005) call them ''needs analysis'' and ''concept exploration.''<br />
<br />
==Topics==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
*[[Mission Analysis]]<br />
*[[Stakeholder Needs and Requirements]]<br />
See the article [[Matrix of Implementation Examples]] for a mapping of case studies and vignettes included in Part 7 as well as topics covered in Part 3.<br />
<br />
==Concept Definition Activities==<br />
There are two primary activities discussed under concept definition: [[Mission Analysis (glossary)|mission analysis]] and the definition of [[Stakeholder Requirement (glossary)|stakeholder needs and requirements]]:<br />
<br />
# [[Mission Analysis]] begins an iteration of the life cycle of a potential SoI that could solve a problem or realize an opportunity for developing a new product, service, or enterprise. These activities define the problem space, identify the stakeholders, develop preliminary operational concepts, and distinguish environmental conditions and constraints that bound the solution space. In other words, mission analysis takes the enterprise capability gap or opportunity and defines the problem/opportunity in a manner that provides a common understanding. <br />
# [[Stakeholder Needs and Requirements]] works with stakeholders across the life cycle to elicit and capture a set of needs, expectations, goals, or objectives for a desired solution to the problem or opportunity, referred to as "stakeholder needs". The stakeholder needs are used to produce a clear, concise, and verifiable set of stakeholder requirements. Stakeholder needs and requirements identify and define the needs and requirements of the stakeholders in a manner that enables the characterization of the solution alternatives. <br />
<br />
Mission analysis takes the stakeholder's needs and requirements and carries the analysis down from problem space to solution space, including concept, requirement (stakeholder/mission) and boundary or context so that a solution concept (black box level) can be selected from the alternatives. Figure 1 in the [[Mission Analysis|mission analysis]] topic depicts this interaction. The products and artifacts produced during concept definition are then used in [[System Definition (glossary)|system definition]].<br />
<br />
The different aspects of how [[Systems Thinking (glossary) | systems thinking]] is applicable to concept definition are discussed in SEBoK Part 2. In particular, the use of a combination of [[Hard System (glossary) | hard system]] and [[Soft System (glossary) |soft system]] approaches depending on the type of problem or class of solution is discussed in the [[Identifying and Understanding Problems and Opportunities]] article.<br />
<br />
===Top-Down Approach: From Problem to Solution===<br />
In a top-down approach, concept definition activities are focused primarily on understanding the problem, the operational needs/requirements within the problem space, and the conditions that constrain the solution and bound the solution space. The concept definition activities determine the mission context, [[Mission Analysis (glossary)|mission analysis]], and the needs to be fulfilled in that context by a new or modified system (i.e., the SoI), and addresses [[Stakeholder Requirement (glossary)|stakeholder needs and requirements]]. <br />
<br />
The [[System Definition (glossary)|system definition]] activities consider functional, behavioral, temporal, and physical aspects of one or more solutions based on the results of concept definition. [[System Analysis (glossary)|System analysis]] considers the advantages and disadvantages of the proposed system solutions both in terms of how they satisfy the needs established in concept definition, as well as the relative cost, time scales and other development issues. This may require further refinement of the concept definition to ensure all legacy relationships and stakeholders relevant to a particular solution architecture have been considered in the stakeholder requirements.<br />
<br />
The outcomes of this iteration between concept definition and system definition define a required system solution and its associated problem context, which are used for [[System Realization (glossary)|system realization]], [[System Deployment and Use (glossary) | system deployment and use]], and [[Product and Service Life Management| product and service life management]] of one or more solution implementations. In this approach problem understanding and solution selection activities are completed in the front-end portion of system development and design and then maintained and refined as necessary throughout the life cycle of any resulting solution systems. Top-down activities can be sequential, iterative, recursive or evolutionary depending upon the life cycle model.<br />
<br />
For the concept definition, an appropriate architecture framework representation can be useful in the visualization and analysis of the mission and solution requirements. These includes the U.S. Department of Defense Architecture Framework (DoDAF) operations view (DoD 2010), the Zachman Framework (Rows1 and 2) (Zachman 2008), and The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM) (The Open Group 2010) Phases A and B within the concept definition when performing mission analysis and evaluating stakeholder needs and requirements.<br />
<br />
===Bottom-Up Approach: Evolution of the Solution===<br />
<br />
In some situations, the concept definition activities determine the need to evolve existing capabilities or add new capabilities to an existing system. During the concept definition, the alternatives to address the needs are evaluated. Engineers are then led to reconsider the system definition in order to modify or adapt some structural, functional, behavioral, or temporal properties during the [[Product (glossary)|product (glossary)]] or [[Service (glossary)|service (glossary)]] life cycle for a changing [[context (glossary)|context (glossary)]] of use or for the purpose of improving existing solutions. <br />
<br />
[[Reverse Engineering (glossary)|Reverse engineering]] is often necessary to enable system engineers to (re)characterize the properties of the system-of-interest (SoI) or its elements. This is an important step to ensure that system engineers understand the SoI before beginning modification. For more information on system definition, see the [[System Definition]] article.<br />
<br />
A bottom-up approach is necessary for analysis purposes, or for (re)using existing elements in the design [[Architecture (glossary)|architecture (glossary)]. Changes in the context of use or a need for improvement can prompt this. In contrast, a top-down approach is generally used to define an initial design solution corresponding to a problem or a set of needs.<br />
<br />
Bottom-up and top-down approaches can be, and often are, mixed.<br />
<br />
===Drivers of Solutions: Push Versus Pull===<br />
<br />
There are two paradigms that drive the concept definition: ''push'' and ''pull''. The ''pull'' paradigm is based on providing a solution to an identified problem or gap, such as a missing mission capability for defense or infrastructure. The ''push'' paradigm is based on creating a solution to address a perceived opportunity, such as the emergence of an anticipated product or service that is attractive to some portion of the population (i.e. whether a current market exists or not). This can have an effect on other lifecycle processes, such as in verification and validation, as it is performed in defense industries versus alpha/beta testing done in some commercial domains.<br />
<br />
===Separation and Iteration between Problem and Solution===<br />
<br />
Problem definition and solution design depend on each other. Solutions should be developed to respond appropriately to well-defined problems. Problem definitions should be constrained to what is feasible in the solution space. [[System Analysis (glossary)|System analysis]] activities are used to provide the link between problems and solutions. <br />
<br />
As systems generally integrate existing and new [[System Element (glossary)|system elements]], a bottom-up approach can be combined with a top-down approach to take into account legacy elements, as well as to identify the services and capabilities that must be provided in order to define applicable interface requirements and constraints. As discussed in [[System Life Cycle Process Models: Iterative]], this is iterative for these evolutionary systems.<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
DoD. 2010. ''DoD Architecture Framework'', version 2.02. Arlington, VA: U.S. Department of Defense. Accessed August 29, 2012. Available at: http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf.<br />
<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
Kossiakoff, A, and W. Sweet. 2009. ''Systems Engineering: Principles and Practice.'' Hoboken, NJ, USA: John Wiley and Sons. <br />
<br />
The Open Group. 2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.<br />
<br />
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™ (online)". Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.<br />
<br />
===Primary References===<br />
ANSI/EIA. 1998. ''[[ANSI/EIA 632|Processes for Engineering a System]]''. Philadelphia, PA, USA: American National Standards Institute (ANSI)/Electronic Industries Association (EIA), ANSI/EIA 632-1998.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities''. Version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2008 (E).<br />
<br />
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 29148|Systems and Software Engineering - Requirements Engineering]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission/ Institute of Electrical and Electronics Engineers (IEEE), (IEC), [[ISO/IEC/IEEE 29148]].<br />
<br />
===Additional References===<br />
ISO/IEC. 2003. Systems Engineering – A Guide for The Application of ISO/IEC 15288 System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 19760:2003 (E). <br />
<br />
ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 26702:2007. <br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight'' (April 2010): 41-43.<br />
<br />
NASA. 2007. Systems Engineering Handbook. Washington, D.C., USA: National Aeronautics and Space Administration (NASA). NASA/SP-2007-6105.<br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology.'' Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Hitchins, D. 2008. http://www.hitchins.net/EmergenceEtc.pdf.).<br />
<br />
----<br />
<center>[[Lean Engineering|< Previous Article]] | [[Systems Engineering and Management|Parent Article]] | [[Mission Analysis|Next Article >]]</center><br />
<br />
<br />
{{DISQUS}}<br />
<br />
<br />
[[Category:Part 3]][[Category:Knowledge Area]]</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Physical_Architecture&diff=47887
Physical Architecture
2013-04-17T21:03:17Z
<p>Eleach: </p>
<hr />
<div>The purpose of physical architecture definition (or [[Design (glossary) |design]]) is to create a physical, concrete solution that accommodates the [[Logical Architecture (glossary)|logical architecture]] and satisfies and trades-off system requirements. Once a logical architecture is defined (see [[Logical Architecture Design]]), concrete physical elements have to be identified that can support functional, behavioral, and temporal features as well as the expected properties of the system deduced from non-functional system requirements (e.g. constraint of replacement of obsolescence, and/or continued product support).<br />
<br />
A [[Physical Architecture (glossary)|physical architecture]] is an arrangement of physical elements, ([[System Element (glossary)|system elements]] and [[Physical Interface (glossary)|physical interfaces]]) that provides the designed solution for a [[Product (glossary)|product]], [[Service (glossary)|service]], or [[Enterprise (glossary)|enterprise]]. It is intended to satisfy logical architecture elements and system requirements (ISO/IEC 26702 2007). It is implementable through technological system elements. [[System Requirement (glossary)|System requirements]] are allocated to both the logical and physical architectures. The resulting system architecture is assessed with [[System Analysis (glossary)|system analysis]] and when completed becomes the basis for [[System Realization (glossary)|system realization]].<br />
<br />
In some cases, particularly when multiple systems are to be designed to a common physical architecture, one of the drivers for the physical architecture may be interface standards; these physical interfaces may well be one of the most important concerns for these systems. It is quite possible that such interface standards are mandated at a high level in the system requirements. On the other hand, it is equally possible for standards to be derived during physical architecture design and these can be critical enablers for desirable engineering outcomes, such as: families of systems, technology insertion, interoperability and “open systems”. For example, today’s video, hi-fi, and computer systems have all benefited from adoption of interface standards. Other examples exist in most fields of engineering from nuts and bolts, plumbing, electrical installations, rail gauges, TCP/IP, IT systems and software to modular defense and space systems.<br />
<br />
==Concepts and Principles==<br />
<br />
===System Element, Physical Interface, and Physical Architecture===<br />
A system element is a discrete part of a system that can be implemented to fulfill design properties. A system element can be hardware, software, data, humans, processes (e.g., processes that provide a service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities (e.g., water, organisms, and minerals), or any combination of these (ISO/IEC/IEEE 15288 2008). A [[Physical Interface (glossary)|physical interface]] binds two system elements together; this is similar to a link or a connector. Table 1 provides some examples of system elements and physical interfaces.<br />
<br />
{|<br />
|+'''Table 1. Types of System Elements and Physical Interfaces.''' (SEBoK Original)<br />
!Element<br />
!Product System<br />
!Service System<br />
!Enterprise System<br />
|-<br />
|'''System Element'''<br />
|<br />
* Hardware Parts (mechanics, electronics, electrical, plastic, chemical, etc.)<br />
* Operator Roles<br />
* Software Pieces<br />
|<br />
* Processes, Data Bases, Procedures, etc.<br />
* Operator Roles<br />
* Software Applications<br />
|<br />
* Corporate, Direction, Division, Department, Project, Technical Team, Leader, etc.<br />
* IT Components<br />
|-<br />
|'''Physical Interface'''<br />
|* Hardware Parts, Protocols, Procedures, etc.<br />
|* Protocols, Documents, etc.<br />
|* Protocols, Procedures, Documents, etc.<br />
|}<br />
<br />
A complex system composed of thousands of physical and/or intangible parts may be structured in several layers of [[System (glossary)|systems]] and [[System Element (glossary)|system elements]]. The number of elements in the decomposition of one system is limited to only a few, in order to facilitate the ease of mastering the system; a common guideline is ''five plus or minus two'' elements (see illustration in Figure 1). <br />
<br />
[[File:SEBoKv075_KA-SystDef_Limited_nb_in_decomposition.png|500px|thumb|center|'''Figure 1. Layers of Systems and System Elements (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
A physical architecture is built from systems, system elements, and all necessary physical interfaces between these elements, as well as from external elements (neighboring or enabling systems and/or system elements in the considered layer and concerned elements in the context of the global system-of-interest) - see illustration in Figure 2.<br />
<br />
[[File:SEBoKv075_KA-SystDef_Encapsulation.png|600px|thumb|center|'''Figure 2. Physical Architecture Representation (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
===Design Property===<br />
A [[Design Property (glossary)|design property]] is a property that is obtained during system architecture and created through the assignment of non-functional requirements, estimates, analyses, calculations, simulations of a specific aspect, or through the definition of an existing element associated with a system element, a physical interface, and/or a physical architecture. If the designed element complies with a requirement, the design property will relate to (or may equal) the requirement. Otherwise, one has to identify any discrepancy that could modify the requirement or design, and detect any deviations.<br />
<br />
Stakeholders have concerns that correspond to the expected behavior of a system within operational, environmental, and/or physical constraints as well as to more general life cycle constraints. [[Stakeholder Requirement (glossary)|Stakeholder requirements]] and [[System Requirement (glossary)|system requirements]] express these concerns as expected abilities from the system (e.g., usability, interoperability, security, expandability, environment suitability, etc.). Architects and/or designers identify these abilities from requirements and deduce corresponding quantitative or qualitative design properties to properly equip their physical architecture (e.g., reliability, availability, maintainability, modularity, robustness, operability, climatic environment resistance, dimensions limits, etc.). For further discussion on how some of these properties may be included in architecture and design, please see the article [[Systems Engineering and Specialty Engineering]] in the [[Related Disciplines]] knowledge area (KA).<br />
<br />
===Emergent Properties===<br />
The overarching physical architecture of a system may have design properties that emerge from the arrangement and interaction between technological system elements, but which may not be properties of any individual element. [[Emergence (glossary)|Emergence]] is the principle which states that entities exhibit properties which are meaningful only when attributed to the whole, not to its parts. <br />
<br />
The elements of an [[Engineered System (glossary) |engineered system]] interact among themselves and can create desirable or undesirable phenomena, such as inhibition, interference, resonance, or the reinforcement of any property. The definition of the system includes an analysis of interactions between [[System Element (glossary)|system elements]] in order to prevent undesirable properties and reinforce desirable ones.<br />
<br />
A property which emerges from a system can have various origins, from a single system element to the interactions among several elements (Thome, B. 1993). The system concept of emergence is discussed in SEBoK Part 2 (see [[Emergence]]). The term [[Emergent Property (glossary)|emergent properties]] is used by some authors to identify any property which emerges from a system, while other may refer to this as [[Synergy (glossary) |synergy]] and reserve emergent property for explaining unexpected properties or properties not considered fully during system development, but have emerged during operation. <br />
<br />
{|<br />
|+'''Table 2. Properties and Emergent Properties.''' (SEBoK Original)<br />
!Broad Categories of Properties<br />
!Description and Examples<br />
|-<br />
|'''Local Property'''<br />
|The property is located in a single system element – e.g. the capacity of a container is the capacity of the system.<br />
|-<br />
|'''Accumulative System Property'''<br />
|The property is located in several system elements and is obtained through the simple summation of elemental properties – e.g. the weight of the system results from the sum of the weights of its system elements. <br />
|-<br />
<br />
<br />
<br />
|'''Emergent Property Modified by Architecture and/or Interactions.'''<br />
|The property exists in several system elements and is modified by their interactions – e.g. the reliability/safety of a system results from the reliability/safety of each system element and the way they are organized. Architectural steps are often critical to meeting system requirements.<br />
|-<br />
|'''Emergent Property Created by Interactions'''<br />
|The property does not exist in system elements and results only from their interactions – e.g. electromechanical interfaces, electromagnetism, static electricity, etc.<br />
|-<br />
|'''Controlled Emergent Property'''<br />
|Property controlled or inhibited before going outside the system – e.g.: unbalance removed by the addition of a load; vibration deadened by a damper. <br />
|}<br />
<br />
Physical architecture design will include the identification of likely synergies and emergent properties and the inclusion of derived functions, components, arrangements, and/or environmental constraints in the logical or physical architectures to avoid, mitigate or restrain them within acceptable limits. Corresponding ''derived requirements'' should be added to the system requirements baseline when they impact the [[System-of-Interest (glossary)|system-of-interest]] (SoI). This may be achieved through the knowledge and experience of the systems engineer or through the application of [[Pattern (glossary)|system patterns]]. However, it is generally not possible to predict, avoid, or control all emergent properties in the physical architecture design. Fully dealing with the consequences of emergence can only be done via iteration between [[System Definition (glossary) |system definition]], [[System Realization (glossary) | system realization]] and [[System Deployment and Use (glossary) | system deployment and use]].<br />
<br />
The notion of emergence is applied during architecture and design to highlight necessary derived functions; additionally, internal physical emergence is often linked to the notion of [[Complexity (glossary)|complexity]]. This is the case with complex adaptive systems (CAS), in which the individual elements act independently, but behave jointly according to common constraints and goals (Flood and Carson 1993). Examples of CAS include: the global macroeconomic network within a country or group of countries, stock market, complex web of cross border holding companies, manufacturing businesses, geopolitical organizations, etc. (Holland, J. 1999 and 2006).<br />
<br />
===Allocation of Logical Elements to Physical Elements and Partitioning===<br />
Defining a candidate physical architecture for a system consists of first identifying the system elements that can perform functions of the logical architecture as well as identifying the interfaces capable of carrying out the input-output flows and control flows. When identifying potential elements, a systems engineer needs to allocate design properties within the logical architecture; these properties are deduced from the [[System Requirements|system requirements]]. Partitioning and allocation are activities to decompose, gather, or separate functions in order to facilitate the identification of feasible system elements that support these functions. Either they exist and can be reused or re-purposed, or they can be developed and technically implemented.<br />
<br />
Partitioning and allocation use criteria to find potential affinities between functions. Systems engineers use system requirements and/or design properties as criteria to assess and select physical candidate system elements and partitions of functions, such as similar transformations within the same technology, similar levels of efficiency, exchange of the same type of input-output flows (information, energy, and materials), centralized or distributed controls, execution with close frequency level, dependability conditions, environment resistance level, and other enterprise constraints.<br />
<br />
A concurrent engineering approach is necessary when several different sets of technologies, knowledge, and skills are necessary to establish a candidate physical architecture. This is particularly true during the partition and allocation of functions to various system elements, in which the systems engineer must account for compatibility issues and emergent properties.<br />
<br />
===Developing Physical Candidate Architectures===<br />
The goal of physical architecture and design activities is to provide the best possible physical architecture made of suitable systems, technological system elements, and physical interfaces (i.e., the architecture that answers, at best, all system requirements, depending on agreed limits or margins of each requirement). The best way to do this is to produce several candidate physical architecture models, assess and compare them, and then select the most suitable one.<br />
<br />
A candidate physical architecture is worked out according to affinity criteria in order to build a set of system elements (i.e., separate, gather, connect, and disconnect the network of system elements and their physical interfaces). These criteria are the same as those used for partitioning and allocating functions to system elements. The physical architecture definition may be focused in different ways, for example, it may address:<br />
<br />
* Reduction in the number of physical interfaces<br />
* System elements that can be tested separately<br />
* Compatible technology<br />
* Measures of the proximity of elements in space<br />
* Ease of handling (weight, volume, and transportation facilities) <br />
* Optimization of resources shared between elements<br />
* Modularity (i.e. elements have low interdependence)<br />
* Resilience (i.e. elements which are highly reliable, maintainable or replaceable)<br />
<br />
===Evaluating and Selecting the Preferred Candidate===<br />
Viable physical architectures enable all required functions or capabilities specified in the logical architecture to be realized. Architecture and design activity includes optimization to obtain a balance among design properties, costs, risks, etc. Generally, the physical architecture of a system is determined more strongly by non-functional requirements (e.g., performance, safety, security, environmental conditions, constraints, etc.) than by functions. There may be many (physical) ways to establish functions but fewer ways of satisfying non-functional requirements. The preferred physical architecture represents the selection of physical components, their physical relationships, and interfaces. Typically this physical architecture will still leave further systems engineering to be undertaken to achieve a fully optimized system design after any remaining trade-offs are made and algorithms and parameters of the system are finalized.<br />
<br />
Certain analyses (efficiency, dependability, cost, risks, etc.) are required to get sufficient data that characterize the global behavior and structure of the candidate architectures in regard to system requirements; this is often broadly referred to as [[System Analysis|system analysis]]. Other analyses and assessments require knowledge and skills from the different involved technologies and specialties (mechanics, electronics, software, thermodynamics, electro-magnetic compatibility, safety, security etc.). They are performed through corresponding specialist analysis of the physical architecture or system.<br />
<br />
===Legacy Systems and Systems of Systems===<br />
Few systems come into existence or operate without interacting with others in a [[System Context (glossary) | system context]]. These interactions may be with other operational systems, or maintenance and support systems, which in turn may be legacy (already in use) or future legacy (under development and likely to operate with the system of interest in the future). <br />
<br />
The best chosen approach will be dependent on the strength of interactions between the [[System-of-Interest (glossary)]] (SoI) and its wider context. While these interactions are small, they may be catered for by defining a set of static external interfaces (for example technical standards) with which the system must comply, by including these as constraints in the system requirements and ensuring compliance through design assurance. <br />
<br />
Where the interactions are more intense, for example where continuous information is to be exchanged with other systems, these will have to be recognized as part of a [[System of Systems (SoS) (glossary)|system of systems]] context and will instead be considered as part of an [[Enterprise Systems Engineering (ESE) (glossary) | enterprise systems engineering]] approach. <br />
<br />
Another important consideration may be the sharing of technology or system elements between the SoI and other systems, often as part of a family of systems (many examples occur in automotive and aerospace industries) or the re-use of system elements from existing legacy. Here a degree of top-down or middle-out design work will be necessary to ensure the system of interest embodies the required system elements, while conforming as far as possible to the user and system requirements, with any compromises being understood and managed. <br />
<br />
If a System-of-Interest is intended to be used in one or more [[Service System (glossary) | service systems]] or [[System of Systems (SoS) (glossary)|system of systems]] configurations this will affect its physical architecture. One of the features of these SoS is the late binding of component systems in use. Such component systems must be architected with open or configurable interfaces, must have clearly defined functions packaged in such a way as to be relevant to the SoS using them, and must include some method by which they can be identified and included in the SoS when needed. <br />
<br />
Both service systems and SoS will be defined by a high level physical architecture, which will be utilized to define the relevant SoS relationships, interfaces, and constraints that should be included in [[Concept Definition]]. The results will be embedded in the stakeholder and system requirements and handled through interface agreements and across-project communication during development, realization, and use. <br />
<br />
Please see SEBoK Part 4 [[Applications of Systems Engineering]] for more information on special considerations for architecting SoS.<br />
<br />
==Process Approach==<br />
===Purpose===<br />
The purpose of the physical architecture definition (design) process is to define, select, and synthesize a system physical architecture which can support the logical architecture. A physical architecture will have specific properties designed to address stakeholder concerns or environmental issues and to satisfy system requirements.<br />
<br />
Because of the evolution of the [[System Context (glossary)|context of use]] or technological possibilities, the physical architecture which is composed of [[System Element (glossary) |system elements]] is supposed to evolve along the life cycle of the system in order for it to continue to perform its mission within the limits of its required effectiveness. Depending on whether or not evolution impacts [[Logical Architecture (glossary)|logical architecture]] elements, allocations to system elements may change. A physical architecture is equipped with specific [[Design Property (glossary)|design properties (glossary)]] to continuously challenge the evolution.<br />
<br />
'''Generic inputs''' include the selected logical architecture, system requirements, generic patterns and properties that designers identify and utilize to answer requirements, outcomes from system analysis, and feedback from system verification and system validation.<br />
<br />
'''Generic outputs''' are the selected physical architecture, allocation matrix of functional elements to physical elements, traceability matrix with system requirements, stakeholder requirements of each system and system element composing the physical architecture, and rejected solutions.<br />
<br />
===Activities of the Process===<br />
Major activities and tasks to be performed during this process include the following:<br />
<br />
* Partition and allocate functional elements to system elements:<br />
** Search for system elements or technologies able to perform functions and physical interfaces to carry input-output and control flows. Ensure system elements exist or can be engineered. Assess each potential system element using criteria deduced from design properties (themselves deduced from non-functional system requirements).<br />
** Partition functional elements (functions, scenarios, input-outputs, triggers, etc.) using the given criteria and allocate partitioned sets to system elements (using the same criteria).<br />
** When it is impossible to identify a system element that corresponds to a partitioned functional set, decompose the function until the identification of implementable system elements is possible.<br />
** Check the compatibility of technologies and the compatibility of interfaces between selected system elements.<br />
* Model candidate physical architectures for each candidate.<br />
** Because partitioned sets of functions can be numerous, there are generally too many system elements. For defining controllable architectures, system elements have to be grouped into higher-level system elements known as (sub) systems.<br />
** Constitute several different sets of (sub) systems corresponding to different combinations of elementary system elements. One set of (sub) systems plus one or several non-decomposable system elements form a candidate physical architecture of the considered system.<br />
** Represent (using patterns) the physical architecture of each (sub) system connecting its system elements with physical Interfaces that carry input-output flows and triggers. Add physical interfaces as needed; in particular, add interfaces with external elements to the (sub) system.<br />
** Represent the synthesized physical architecture of the considered system built from (sub) systems, non-decomposable system, and physical interfaces inherited from the physical architecture of (sub) systems.<br />
** Equip the physical architecture with design properties such as modularity, evolution capability, adaptability to different environments, robustness, scalability, resistance to environmental conditions, etc.<br />
** If possible, use executable architecture prototypes (e.g., hardware-software (HW-SW)-in-the-loop prototypes) for identifying potential deficiencies and correct the architecture as needed.<br />
* Assess physical architecture candidates and select the most suitable one:<br />
** Constitute a decision model based on criteria deduced from non-functional requirements (effectiveness, environmental conditions, safety, human factors, cost, risks, etc.) and design properties (modularity, communication commonality, maintainability, etc.).<br />
** Assess physical architecture candidates against the given criteria. Select the most suitable one by comparing scores and rationales to determine which candidate best matches the criteria. Use the system analysis process to perform assessments (see the [[System Analysis]] topic).<br />
* Synthesize the selected physical architecture:<br />
** Formalize physical elements and properties. Verify that system requirements are satisfied and that the solution is realistic. <br />
** Identify the derived physical and functional elements created for the necessity of architecture and design and the corresponding system requirements.<br />
** Establish traceability between system requirements and physical elements as well as allocate matrices between functional and physical elements.<br />
* Prepare for the acquisition of each system or non-decomposable system element:<br />
** Define the system or system element’s mission and objectives from allocated functions and effectiveness.<br />
** Define the stakeholder requirements (consider the concerned stakeholder being the current studied system). Additional information about development of stakeholder requirements can be found in the [[Stakeholders Requirements]] topic.<br />
** Establish traceability between these stakeholder requirements and elements of the studied system (in particular design properties). This allows traceability of requirements between two layers of systems.<br />
<br />
===Artifacts, Methods and Modeling Techniques===<br />
This process may create several artifacts, such as:<br />
<br />
* System design documents (describe selected logical and physical architectures)<br />
* System design justification documents (traceability matrices and design choices)<br />
* System element stakeholder requirements documents (one for each system or system element)<br />
<br />
The content, format, layout and ownership of these artifacts will vary depending on who is creating them and in which domains they are to be used. Between these artifacts and the outputs of the process activities should cover the information identified in the first part of this article. <br />
<br />
Modeling techniques are used to create and represent physical architectures. Some common models include:<br />
<br />
* Physical block diagrams (PBD)<br />
* SysML block definition diagrams (BDD)<br />
* Internal block diagrams (IBD) (OMG 2010)<br />
* Executable architecture prototyping<br />
<br />
Depending on the type of domain for which it is to be used (defense, enterprise, etc.), architecture frameworks such as DoDAF (DoD 2010), TOGAF (The Open Group 2011), the Zachman framework (Zachman 2008), etc., may provide descriptions that can help to trade-off candidate architectures. Please see section 'Enterprise Architecture Frameworks & Methodologies' in [[Enterprise Systems Engineering Key Concepts]].<br />
<br />
==Practical Considerations==<br />
Key pitfalls and good practices related to physical architecture definition are described in the next two sections.<br />
<br />
===Pitfalls===<br />
Some of the key pitfalls encountered in planning and performing physical architecture definition are provided in Table 3.<br />
<br />
{|<br />
|+'''Table 4. Pitfalls with Physical Architecture Design.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|Too Many Levels in a Single System Block<br />
|The current system block includes too many levels of decomposition. The right practice is that the physical architecture of a system block is composed of one single level of systems and/or system elements.<br />
|-<br />
|No Functional Architecture<br />
|The developers perform a direct passage from system requirements to physical architecture without establishing a logical architecture; this is a common wrong practice that mainly takes place when dealing with repeating systems and products because the functions are already known. The issue is that a function is always associated with input-output flows defined in a specific domain set. If the domain set changes, the performance of the function can become invalid.<br />
|-<br />
|Direct Allocation on Technologies<br />
|At a high level of abstraction of multidisciplinary systems, directly allocating the functions onto technologies of the lowest level of abstraction, such as hardware or software, does not reflect a system comprehension. The right practice is to consider criteria to decompose the architecture into the appropriate number of levels, alternating logical and physical before reaching the technology level ( the last level of the system).<br />
|-<br />
|Reuse of System Elements<br />
|In some projects, for industrial purposes, existing products or services are imposed very early as design constraints in the stakeholder requirements or in the system requirements, without paying sufficient attention to the new context of use of the system in which they are also included. It is better to work in the right direction from the beginning. Design the system first, taking note of other requirements, and then see if any suitable commercial off-the-shelf (COTS) are available. Do not impose a system element from the beginning. The right reuse process consists of designing reusable system elements in every context of use.<br />
|}<br />
<br />
===Proven Practices===<br />
Some proven practices gathered from the references are provided in Table 4.<br />
<br />
{|<br />
|+'''Table 4. Proven Practices with Physical Architecture Design.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|Modularity<br />
|Restrict the number of interactions between the system elements and consider the modularity principle (maximum of consistency inside the system element, minimum of physical interfaces with outside) as the right way for architecting systems.<br />
|-<br />
|Focus on Interfaces<br />
|Focusing on interfaces rather than on system elements is another key element of a successful design for abstract levels of systems.<br />
|-<br />
|Emerging Properties<br />
|Control the emergent properties of the interactions between the systems or the system elements; obtain the required synergistic properties and control or avoid the undesirable behaviors (vibration, noise, instability, resonance, etc.).<br />
|}<br />
<br />
==References==<br />
===Works Cited===<br />
Checkland, P. B. 1999. ''Systems Thinking, Systems Practice''. Chichester, UK: John Wiley & Sons Ltd.<br />
<br />
DoD. 2010. ''DoD Architecture Framework'', version 2.02. Arlington, VA: U.S. Department of Defense. Accessed August 29, 2012. Available at: http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf.<br />
<br />
Flood, R.L., and E.R. Carson. 1993. ''Dealing with complexity: An Introduction to the Theory and Application of Systems Science'', 2nd ed. New York, NY, USA: Plenum Press<br />
<br />
Hitchins, D. 2008. "Emergence, Hierarchy, Complexity, Architecture: How do they all fit together? A guide for seekers after enlightenment." Self-published white paper. Accessed 4 September 2012. Available at: http://www.hitchins.net/EmergenceEtc.pdf.<br />
<br />
Holland, J.H. 1999. ''Emergence: from chaos to order''. Reading, Mass: Perseus Books. ISBN 0-7382-0142-1.<br />
<br />
Holland, J.H. 2006. "Studying Complex Adaptive Systems." Journal of Systems Science and Complexity 19 (1): 1-8. http://hdl.handle.net/2027.42/41486<br />
<br />
ISO/IEC. 2007. Systems Engineering – Application and Management of The Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electrotechnical Commission (IEC), ISO/IEC 26702:2007.<br />
<br />
OMG. 2010. ''OMG Systems Modeling Language specification'', version 1.2, July 2010. http://www.omg.org/technology/documents/spec_catalog.htm.<br />
<br />
The Open Group. 2011. TOGAF, version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.<br />
<br />
Thome, B. 1993. ''Systems Engineering, Principles & Practice of Computer-Based Systems Engineering''. New York, NY, USA: Wiley.<br />
<br />
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™ (online)". Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.<br />
<br />
===Primary References===<br />
ANSI/IEEE. 2000. ''[[IEEE 1471|Recommended practice for architectural description for software-intensive systems]]''. New York, NY: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/[[IEEE 1471]]-2000.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2008 (E).<br />
<br />
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|Systems and Software Engineering - Architecture Description]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 42010]].<br />
<br />
Maier, M., and E. Rechtin. 2009. ''[[The Art of Systems Architecting]].'' 3rd ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
===Additional References===<br />
<br />
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.<br />
<br />
Thome, B. 1993. ''Systems Engineering, Principles & Practice of Computer-Based Systems Engineering''. New York, NY, USA: Wiley.<br />
<br />
----<br />
<br />
<center>[[Logical Architecture Design|< Previous Article]] | [[System Definition|Parent Article]] | [[System Analysis|Next Article >]]</center><br />
<br />
[[Category:Part 1]][[Category:Topic]]<br />
[[Category:System Definition]]<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Logical_Architecture&diff=47783
Logical Architecture
2013-04-17T18:11:35Z
<p>Eleach: </p>
<hr />
<div>The purpose of logical architecture definition (or [[Design (glossary) |design]]) is to assess the functionality and behavior of the [[System (glossary)|system]], while in service. The [[Logical Architecture (glossary)|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 includes a [[Functional Architecture (glossary) |functional architecture]] view, a [[Behavioral Architecture (glossary)|behavioral architecture]] view, and a [[Temporal Architecture (glossary)|temporal architecture]] view. Other additional views are suggested in architectural frameworks, depending on the domain; refer to the Department of Defense (DoD) ''Architecture Framework'' (DoDAF) (DoD 2010), ''The Open Group Architectural Framework'' (TOGAF) (The Open Group 2011), etc).<br />
<br />
==Concepts and Principles==<br />
<br />
===Functional Architecture View===<br />
<br />
A [[Functional Architecture (glossary) |functional architecture]] is a set of functions and their sub-functions that defines the transformations performed by the system to complete its mission.<br />
<br />
'''Function and Input-Output Flow''' - A [[Function (glossary) |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 mathematical notation of a function is '''''y''''' ''= ƒ('' '''''x''''' '',t)'', in which '''y''' and '''x''' are vectors that may be represented graphically and t = time.<br />
<br />
In order to define the complete set of functions of the system, one must identify all the functions necessitated by the system and its derived requirements, as well as the corresponding inputs and outputs of those functions. Generally speaking, there are two kinds of functions:<br />
<br />
# Functions that are directly deduced from functional and interface requirements. These equations express the expected services of a system necessary to meet its [[System Requirement (glossary)|system requirements]].<br />
# Functions that are derived and issued from the alternative solutions of [[Physical Architecture (glossary)|physical architecture]] and are dependent upon the result of the design; additionally, they rely upon on technology choice to implement the logical architecture elements.<br />
<br />
'''Functional Hierarchy/Decomposition of Functions''' – At the highest level of a hierarchy (Figure 1), 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 Figure 1). 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. However, a static functional hierarchy does not represent how effectively the flows of inputs and outputs are exchanged.<br />
<br />
[[File:Decomposition_of_Functions_AF_071112(2).png|600px|thumb|center|'''Figure 1. Decomposition of Functions (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
===Behavioral Architecture View===<br />
<br />
A [[Behavioral Architecture (glossary) |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 Mode (glossary) |operational modes]].<br />
<br />
'''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.<br />
<br />
'''Scenario (of Functions)''' - A scenario of functions is a chain of functions that are performed as a sequence and synchronized by a set of control flows to work to achieve a global transformation of inputs into outputs, as seen in the figures below. A scenario of functions expresses the dynamic of an upper level function. A behavioral architecture is developed by 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 diagrams as modeling techniques, such as functional flow block diagrams (FFBD) (Oliver, Kelliher, and Keegan 1997) or activity diagrams, developed with SysML (OMG 2010). Figures 2 and 3 provide examples of these diagrams.<br />
<br />
[[File:Illustration_of_a_scenario_(eFFBD)_AF_071112.png|thumb|900px|center|'''Figure 2. Illustration of a Scenario (eFFBD).''' (SEBoK Original)]]<br />
<br />
[[File:Illustration_of_a_scenario_Activity_Diagram_AF_071112.png|thumb|900px|center|'''Figure 3. Illustration of a Scenario (Activity Diagram).''' (SEBoK Original)]]<br />
<br />
'''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'', which is 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, as demonstrated in Figure 4 below.<br />
<br />
[[File:SEBoKv075_KA-SystDef_Scenario_of_Operational_Modes.png|300px|thumb|center|'''Figure 4. Scenario of Operational Modes (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
'''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:<br />
* Basic patterns or constructs linking functions - such as sequence, iteration, selection, concurrence, multiple exits, loops with an exit, and replication.<br />
* 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.<br />
* Failure detection, identification, and recovery (FDIR) patterns - such as passive redundancies, active redundancies, semi-active redundancies, and treatments with reduced performance.<br />
<br />
===Temporal Architecture View===<br />
<br />
A [[Temporal Architecture (glossary) |temporal architecture]] is a classification of the functions of a system that is 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.<br />
<br />
'''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.<br />
<br />
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:<br />
<br />
# Disturbances on High Frequencies (bottom of figure 5) - 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 [[Failure (glossary)|failures]].<br />
# Changes on Low Frequencies (top of figure 5) - 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.<br />
<br />
[[File:SEBoKv05 KA-SystDef Temporal and decision hierarchy levels.png|450px|thumb|center|'''Figure 5. Temporal and Decision Hierarchy Levels (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]<br />
<br />
==Process Approach==<br />
<br />
===Purpose===<br />
The purpose of the logical architecture design process is to define, select, and synthesize a system’s logical architecture to provide a framework against which to verify that a future system will satisfy its system requirements in all operational scenarios, within which trade-offs between system requirements can be explored in developing such systems. <br />
<br />
Generic inputs to the process include system requirements, generic design patterns that designers identify and use to answer requirements, outcomes from system analysis processes, and feedback from system verification and validation processes. Depending on the Life Cycle Model that is chosen, there will be an element of iterative design through which these inputs and outputs, and the relationships between them evolve and change throughout the process. <br />
<br />
Generic outputs from the process are either a single logical architecture or a set of candidate logical architectures together with selected independent logical architecture and a rationale for its selection. They include, at minimum, views and models. These involve functional, behavioral, and temporal views; a traceability matrix between logical architecture elements and system requirements.<br />
<br />
===Activities of the Process===<br />
Major activities and tasks performed during this process include the following:<br />
<br />
* Identify and analyze functional and behavioral elements: <br />
** Identify functions, [[Input-Output Flow (glossary) |input-output flows]], [[Operational Mode (glossary)|operational modes]], [[Transition of Modes (glossary)|transition of modes]], and [[Operational Scenario (glossary)|operational scenarios]] from system requirements by analyzing the functional, interface, and operational requirements.<br />
** Define necessary inputs and controls (energy, material, and data flows) to each function and outputs that result in the deduction of the necessary functions to use, transform, move, and generate the input-output flows.<br />
* Assign system requirements to functional and behavioral elements:<br />
** Formally characterize functions expressions and their attributes through the assignment of performance, effectiveness, and constraints requirements. In particular, study the temporal aspects from requirements to assign duration, response time, and frequency to functions.<br />
** Formally characterize the input, output, and control flows expressions and their attributes through assignment of interface, effectiveness, operational, temporal and constraints requirements.<br />
** Establish traceability between system requirements and these functional and behavioral elements.<br />
* Define candidate logical architectures. For each candidate:<br />
** Analyze operational modes as stated in the system requirements (if any) and/or use previously defined elements to model sequences of operational modes and the transition of modes. Eventually decompose the modes into sub-modes and then establish for each operational mode one or several scenarios of functions recognizing and/or using relevant generic behavioral patterns.<br />
** Integrate these scenarios of functions in order to get a behavioral architecture model of the system (a complete picture of the dynamic behavior).<br />
** Decompose previously defined logical elements as necessary to look towards implementation.<br />
** Assign and incorporate temporal constraints to previously defined logical elements, such as the period of time, duration, frequency, response-time, timeout, stop conditions, etc.<br />
** Define several levels of execution frequency for functions that correspond to levels of decision, in order to monitor system operations, prioritize processing on this time basis, and share out functions among those execution frequency levels to get a temporal architecture model.<br />
** Perform functional failure modes and effects analysis and update the logical architecture elements as necessary.<br />
** Execute the models with simulators (when possible) and tune these models to obtain the expected characteristics.<br />
* Synthesize the selected independent logical architecture:<br />
** Select the logical architecture by assessing the candidate logical architectures against assessment criteria (related to system requirements) and compare them, using the system analysis process to perform assessments (see the [[System Analysis]] topic). This selected logical architecture is called ''independent logical architecture'' because, as much as possible, it is independent of implementation decisions.<br />
** Identify and define derived logical architecture elements created for the necessity of design and corresponding with the derived system requirements. Assign these requirements to the appropriate system (current studied system or external systems).<br />
** Verify and validate the selected logical architecture models (using as executable models as possible), make corrections as necessary, and establish traceability between system requirements and logical architecture elements.<br />
* Feedback logical architecture definition and system requirements. This activity is performed after the physical architecture definition (design) process:<br />
** Model the ''allocated logical architecture'' to systems and system elements, if such a representation is possible, and add any functional, behavioral, and temporal elements as needed to synchronize functions and treatments.<br />
** Define or consolidate derived logical and physical elements induced by the selected logical and physical architectures. Define the corresponding derived requirements and allocate them to appropriate logical and physical architectures elements. Incorporate these derived requirements into the requirements baselines of impacted systems.<br />
<br />
===Artifacts, Methods and Modeling Techniques===<br />
This process may create several artifacts, such as system design documents (used to describe the selected logical and physical architecture) and system design justification documents (traceability matrices and design choices).<br />
<br />
The content, format, layout, and ownership of these artifacts will vary depending on the person creating them and the domains in which they are being used. The outputs of the process activities should cover the information identified in the first part of this article. <br />
<br />
Logical architecture descriptions use modeling techniques that are grouped under the following types of models. Several methods have been developed to support these types of models (some are executable models):<br />
<br />
* Functional Models – These include models such as the structured analysis design technique (SADT/IDEF0), system analysis & real time (SA-RT), enhanced Functional Flow Block Diagrams (eFFBD), and the function analysis system technique (FAST).<br />
* Semantic Models- These include models such as entities-relationships diagrams, class diagrams, and data flow diagrams.<br />
* Dynamic Models – These include such models as state-transition diagrams, state-charts, eFFBDs, state machine diagrams (SysML), activity diagrams (SysML) (OMG. 2010), and petri nets.<br />
<br />
Depending on the type of domain (e.g. defense, enterprise), architecture frameworks such as DoDAF (DoD 2010), TOGAF (The Open Group 2011), the Zachman framework (Zachman 2008), etc. provide descriptions that can help to represent additional aspects/views of architectures - see the section 'Enterprise Architecture Frameworks & Methodologies' in [[Enterprise Systems Engineering Key Concepts]]. See also practical means for using general templates related to ISO/IEC/IEEE 42010 (2011), which are available at: [http://www.iso-architecture.org/42010/templates].<br />
<br />
==Practical Considerations==<br />
As stated above, the purpose of the logical architecture is to provide a description of what a system must be able to do to satisfy the stated need. This should help to ensure that the needs of all stakeholders are addressed by any solution, and that innovative solutions, as well as those based on current solution technologies, can be considered. In practice it is human nature for problem stakeholders to push their own agenda's and for solution designers to offer their familiar solutions. If a logical architecture is not properly enforced with the chosen life cycle, it is easy for both problem and solution stakeholders to ignore it and revert to their own biases (see Part 5 [[Enabling Systems Engineering]]). This is exacerbated if the logical architecture becomes an end in its own right or disconnected from the main lifecycle activities. This can occur either through the use of abstract language or notations, levels of detail, time taken, or an overly complex final architecture that does not match the purpose for which it was created. If the language, scope, and timeliness of the architecture are not matched to the problem stakeholder or solution providers, it is easier for them to overlook it. Key pitfalls and good practices which can help to avoid problems related to logical architecture design are described in the next two sections.<br />
<br />
===Pitfalls===<br />
Some of the key pitfalls encountered in planning and performing logical architecture design are provided in Table 1.<br />
<br />
<center><br />
{|<br />
|+'''Table 1. Pitfalls with Logical Architecture Design.''' (SEBoK Original)<br />
!Pitfall<br />
!Description<br />
|-<br />
|'''Problem Relevance'''<br />
|The logical architecture should relate back to the operational scenarios produced by [[Mission Analysis (glossary) | mission analysis]]. If the architecture is developed without input from the problem stakeholders, or cannot be understood and related back to their problems it might lose the investments of the stakeholder community.<br />
|-<br />
|'''Inputs for Design'''<br />
|The major input for design activity involves the set of system requirements and the instances in which that they do not address the right level of design. The consequence is that the designer allows the requirements to fall to the side and invents a solution with what he or she understands through the input.<br />
|-<br />
|'''Decomposition Too Deep'''<br />
| A common mistake many beginners in design consists of decomposing the functions too deeply or having too many functions and input/output flows in scenarios or in the functional architecture of the current system block.<br />
|-<br />
|'''Not Considering Inputs and Outputs Together with Functions'''<br />
|A common mistake is to consider only the actions supported by functions and decomposing them, while forgetting the inputs and the outputs or considering them too late. Inputs and outputs are integral parts of a function.<br />
|-<br />
|'''Considering Static Decomposition of Functions Only'''<br />
|Static function decomposition is the smallest functional design task and answers the basic question, "How is this done?" The purpose of the static decomposition is to facilitate the management or navigation through the list of functions. The static decomposition should be established only when scenarios have been created and the logical design is close to complete.<br />
|-<br />
|'''Mixing Governance, Management, and Operation'''<br />
|Governance (strategic monitoring), management (tactical monitoring), and basic operations are often mixed in complex systems. Functional design should deal with behavioral design as well as with temporal design.<br />
|}<br />
</center><br />
<br />
===Proven Practices===<br />
Some proven practices gathered from the references are provided in Table 2.<br />
<br />
<center><br />
{|<br />
|+'''Table 2. Proven Practices with Logical Architecture Design.''' (SEBoK Original)<br />
!Practice<br />
!Description<br />
|-<br />
|'''Constitute Scenarios of Functions'''<br />
|Before constituting a decomposition tree of functions, one must model the behavior of the system, establish scenarios of functions, and decompose functions as scenarios of sub-functions.<br />
|-<br />
|'''Analysis and Synthesis Cycles'''<br />
|When facing a system that contains a large number of functions, one should attempt to synthesize functions into higher abstraction levels of functions with the assistance of criteria. Do not perform analysis only; instead, conduct small cycles of analysis (decomposition) and synthesis. The technique of using scenarios includes this design practice.<br />
|-<br />
|'''Alternate Functional and Behavioral Views'''<br />
|A function (action verb; e.g. "to move") and its state of execution/operational mode (e.g. "moving") are two similar and complimentary views. Utilize this to consider a behavioral view of the system that allows for the transition from one operational mode to another.<br />
|-<br />
|''' The Order to Create a Scenario Of Functions'''<br />
|When creating a scenario of functions, it is more efficient from a mouthed viewpoint to first establish the (control) flow of functions, then to add input and output flows, and finally to add triggers or signals for synchronization.<br />
|}<br />
</center><br />
<br />
==References== <br />
<br />
===Works Cited===<br />
DoD. 2010. ''DoD Architecture Framework'', version 2.02. Arlington, VA: U.S. Department of Defense. Accessed August 29, 2012. Available at: http://dodcio.defense.gov/Portals/0/Documents/DODAF/DoDAF_v2-02_web.pdf.<br />
<br />
Gamma, E., R. Helm, R. Johnson, and J. Vlissides. 1995. ''Design Patterns: Elements of Reusable Object-Oriented Software''. Boston, MA, USA: Addison-Wesley.<br />
ISO/IEC/IEEE. 2008. ''Systems and Software Engineering - System Life Cycle Processes.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2008 (E).<br />
<br />
ISO/IEC/IEEE. 2011. Systems and software engineering - Architecture description. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.<br />
<br />
Oliver, D., T. Kelliher, and J. Keegan. 1997. ''Engineering complex systems with models and objects''. New York, NY, USA: McGraw-Hill. <br />
<br />
OMG. 2010. ''OMG Systems Modeling Language specification'', version 1.2, July 2010. http://www.omg.org/technology/documents/spec_catalog.htm.<br />
<br />
The Open Group. 2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.<br />
<br />
Zachman, J. 2008. "John Zachman's Concise Definition of The Zachman Framework™ (online)". Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.<br />
<br />
===Primary References===<br />
ANSI/IEEE. 2000. ''[[IEEE 1471|Recommended practice for architectural description for software-intensive systems]]''. New York, NY: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/[[IEEE 1471]]-2000.<br />
<br />
INCOSE. 2011. ''[[INCOSE Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.1. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.1.<br />
<br />
ISO/IEC. 2007. Systems Engineering – Application and Management of the Systems Engineering Process. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.<br />
<br />
ISO/IEC/IEEE. 2008. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering - System Life Cycle Processes]].'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC), Institute of Electrical and Electronics Engineers. [[ISO/IEC/IEEE 15288]]:2008 (E).<br />
<br />
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|Systems and Software Engineering - Architecture Description]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 42010]].<br />
<br />
Maier, M., and E. Rechtin. 2009. ''[[The Art of Systems Architecting]].'' 3rd ed. Boca Raton, FL, USA: CRC Press.<br />
<br />
OMG. 2010. ''MDA Foundation Model''. Needham, MA, USA: Object Management Group. ORMSC/2010-09-06.<br />
<br />
===Additional References===<br />
Alexander, C., S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. 1977. ''A Pattern Language: Towns, Buildings, Construction''. New York, NY, USA: Oxford University Press.<br />
<br />
Buede, D.M. 2009. ''The engineering design of systems: Models and methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc. <br />
<br />
Faisandier, A. 2012. Systems Architecture and Design. Belberaud, France: Sinergy'Com.<br />
<br />
Oliver, D., T. Kelliher, and J. Keegan. 1997. ''Engineering Complex Systems with Models and Objects''. New York, NY, USA: McGraw-Hill. <br />
<br />
Thome, B. 1993. ''Systems Engineering, Principles & Practice of Computer-Based Systems Engineering''. New York, NY, USA: Wiley.<br />
<br />
----<br />
<center>[[System Requirements|< Previous Article]] | [[System Definition|Parent Article]] | [[Physical Architecture Design|Next Article >]]</center><br />
<br />
<br />
[[Category: Part 3]][[Category:Topic]]<br />
[[Category:System Definition]]<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Foundations_of_Systems_Engineering&diff=47649
Foundations of Systems Engineering
2013-04-16T20:36:10Z
<p>Eleach: </p>
<hr />
<div><html><br />
<meta name="citation_title" content="Systems"><br />
<meta name="citation_author" content="Pyster, Art"><br />
<meta name="citation_author" content="Olwell, David H."><br />
<meta name="citation_author" content="Hutchison, Nicole"><br />
<meta name="citation_author" content="Enck, Stephanie"><br />
<meta name="citation_author" content="Anthony, James F., Jr."><br />
<meta name="citation_author" content="Henry, Devanandham"><br />
<meta name="citation_author" content="Squires, Alice (eds)"><br />
<meta name="citation_publication_date" content="2012/11/30"><br />
<meta name="citation_journal_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK)"><br />
<meta name="citation_volume" content="version 1.0.1"><br />
<meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Systems"></html><br />
<br />
Part 2 of the Guide to the SE Body of Knowledge (SEBoK) is a guide to knowledge associated with [[System (glossary)|systems]], particularly knowledge relevant to [[Systems Engineering (glossary)|systems engineering]] (SE). This knowledge is included in the SEBoK to help [[Systems Engineer (glossary) |systems engineers]] benefit from an understanding of the broader context for their discipline, in terms of the theories and practices of [[Systems Science (glossary)|systems science]] and other fields of systems practice. The goal of including the wider systems science context of SE is to make SE knowledge more accessible to a wider audience outside of its traditional [[Domain (glossary)|domains]].<br />
<br />
==Knowledge Areas in Part 2==<br />
Each part of the SEBoK is divided into knowledge areas (KAs), which are groupings of information with a related theme. Part 2 contains the following KAs: <br />
<br />
*[[Systems Fundamentals]]<br />
*[[Systems Science]]<br />
*[[Systems Thinking]]<br />
*[[Representing Systems with Models]]<br />
*[[Systems Approach Applied to Engineered Systems]]<br />
<br />
==Introduction==<br />
<br />
Most systems engineers are practitioners, applying [[Process (glossary) | processes]] and methods that have been developed and evolved over decades. SE is a pragmatic approach, inherently interdisciplinary, yet specialized. Systems engineers usually work within a specific domain, using processes and methods that are tailored to their domain’s unique [[Problem (glossary) | problems]], [[Constraint (glossary) | constraints]], [[Risk (glossary) | risks]] and [[Opportunity (glossary) | opportunities]]. These processes and methods have been found to capture domain experts’ knowledge regarding the best order to tackle issues as a problem in the particular domain is approached. <br />
<br />
Specific domains in which [[Systems Approach (glossary) | systems approaches]] are used and adapted include:<br />
* Technology products, integrating multiple [[Engineering (glossary) | engineering]] disciplines<br />
* Information-rich systems, e.g. command & control, air traffic management etc.<br />
* Platforms, e.g. aircraft, civil airliners, cars, trains, etc. <br />
* Organizational and enterprise systems, which may be focused on delivering service or capability<br />
* Civil engineering/infrastructure systems, e.g. roads networks, bridges, builds, communications networks, etc.<br />
<br />
The specific skill-sets for each domain and system scale may be quite different; however, there are certain underlying unifying [[Principle (glossary) | principles]] based on systems science and [[Systems Thinking (glossary) | systems thinking]] that will improve the effectiveness of the systems approach in any domain. In particular, shared knowledge of systems principles and terminology will enable communication and improve system engineers’ ability to integrate [[Complex (glossary)| complex]] systems that span traditional domain [[Boundary (glossary) | boundaries]] (Sillitto 2012). This integrated approach is increasingly needed to solve today’s complex system challenges, but as these different communities come together they may find that assumptions underpinning their world-views are not shared. <br />
<br />
To bridge the gap between different domains and communities of practice, it is important to first establish a well-grounded definition of the “intellectual foundations of systems engineering”, as well as a common language to describe the relevant [[Concept (glossary) | concepts]] and [[Paradigm (glossary) |paradigms]]. An integrated systems approach for solving complex problems needs to combine elements of systems science, systems thinking and systems approaches to practice. This may range from the technical-systems focus that has been dominant in systems engineering to the learning-systems focus of social systems intervention. An integrated systems approach needs to provide a framework and language that allow different communities, with highly divergent world-views and skill sets, to work together for a common [[Purpose (glossary) | purpose]].<br />
<br />
==The Systems Praxis Framework==<br />
<br />
The term '''“systems praxis”''' refers to the entire intellectual and practical endeavor for creating [[Holistic (glossary) | holistic]] solutions to today’s complex system challenges. [[Praxis (glossary)|Praxis]] is defined as “translating an idea into action” (Wordnet 2012) and suggests that the best holistic approach to a given complex challenge may require integrating appropriate theory and appropriate practice from a wide variety of sources. Systems praxis requires many communities to work together. To work together we must first communicate; and to communicate, we must first connect.<br />
<br />
A framework for unifying systems praxis was developed by members of International Council on Systems Engineering (INCOSE) and International Society for the System Sciences (ISSS) (International Federation for Systems Research (IFSR) 2012)) as the first step towards a “common language for systems praxis”. This '''Systems Praxis Framework''' is included here because it represents current thinking on the foundations and common language of systems engineering, making the concepts and principles of systems thinking and practice accessible to anyone applying a systems approach to [[Engineered System (glossary) | engineered system]] problems. This framework and thinking have been used to help organize the guide to systems knowledge in the SEBoK.<br />
<br />
The diagram below shows the flows and interconnections among elements of a “knowledge ecosystem” of systems theory and practice.<br />
<br />
[[File:IFSR_SPF.png|thumb|850px|center|'''Figure 1. The Systems Praxis Framework, Developed as a Joint Project of INCOSE and ISSS.''' (© 2012 International Federation for Systems Research) Released under Creative Commons Attribution 3.0 License. Source is available at http://systemspraxis.org/framework.pdf.]]<br />
<br />
In this framework, the following elements are connected:<br />
<br />
'''Systems Thinking''' is the core integrative element of the framework. It binds the foundations, theories and representations of systems science together with the hard, soft and pragmatic approaches of systems practice. In systems praxis, as in any practical discipline underpinned by science, there is constant interplay between theories and practice, with theory informing practice and outcomes from practice informing theory. Systems thinking is the ongoing activity of assessing and appreciating the [[System Context (glossary) | system context]], and guiding appropriate adaptation, throughout the praxis cycle. <br />
<br />
'''Integrative Systems Science''' has a very wide scope and is grouped into three broad areas: <br />
* '''Foundations''', which help to organize knowledge and promote learning and discovery including: meta-theories of methodology, ontology, epistemology, axiology, praxiology (theory of effective action), teleology, semiotics & semiosis, category theory, etc.<br />
* '''Theories''' pertaining to systems are abstracted from domains and specialties, so as to be universally applicable: [[General System Theory (glossary) | general system theory]], systems pathology, [[Complexity (glossary) | complexity]], anticipatory systems, cybernetics, autopoiesis, living systems, science of generic design, organization theory, etc.<br />
* '''Representations''' and corresponding theories describe, explore, analyze, and make predictions about systems and their wider contexts, whether in terms of [[Model (glossary) | models]], dynamics, networks, cellular automata, [[Life Cycle (glossary) | life cycles]], queues, graphs, rich pictures, narratives, games and dramas, agent-based [[Simulation (glossary) |simulations]], etc.<br />
<br />
'''Systems Approaches to Practice''' aim to act on real world experiences to produce desired outcomes without adverse, unintended consequences; ergo, practice needs to draw on the wide range of knowledge appropriate to the [[System-of-Interest (glossary) | system-of-interest]] and its wider context. No one branch of systems science or practice provides a satisfactory explanation for all aspects of a typical system “problematique”; therefore, a more pragmatic approach is needed. Traditional systems approaches are often described to be either hard or soft: <br />
<br />
* '''Hard''' approaches are suited to solving well-defined problems with reliable data and clear goals, using analytical methods and quantitative techniques. Strongly influenced by “machine” metaphors, they focus on technical systems, objective complexity, and optimization to achieve desired combinations of emergent properties. They are based on “realist” and “functionalist” foundations and worldview.<br />
* '''Soft''' approaches are suited to structuring problems involving incomplete data, unclear goals, and open inquiries, using a “learning system” metaphor, focus on communication, intersubjective complexity, interpretations and roles, and draw on subjective and “humanist” philosophies with constructivist and interpretivist foundations.<br />
<br />
'''Pragmatic''' (pluralist or critical) approaches judiciously select an appropriate set of tools and patterns that will give sufficient and appropriate insights to manage the issue at hand, by applying multiple methodologies drawn from different foundations as appropriate to the situation. [[Heuristic (glossary) |Heuristics]], boundary critiques, model unfolding, etc, enable the understanding of assumptions, contexts, and [[Constraint (glossary) | constraints]], including complexity due to different [[Stakeholder (glossary) | stakeholders’]] [[Value (glossary) | values]] and valuations. An appropriate mix of “hard”, “soft”, and custom methods draws on both systems and domain-specific traditions. Systems may be viewed as [[Network (glossary) | networks]], societies of agents, organisms, ecosystems, rhizomes, discourses, machines, etc.<br />
<br />
The set of “clouds” that collectively represents systems praxis is part of a wider ecosystem of knowledge, learning, and action. Successful [[Integration (glossary) | integration]] with this wider ecosystem is the key to success with real world systems. Systems science is augmented by “hard” scientific disciplines, such as physics and neuroscience, and by formal disciplines, such as mathematics, logic and computation. It is both enhanced by, and used in, humanistic disciplines, such as psychology, culture, and rhetoric, and pragmatic disciplines, such as accounting, design, and law. Systems practice depends on measured data and specified [[Metric (glossary) | metrics]] relevant to the problem situation and domain, the solicitation of local values and knowledge, and the pragmatic integration of experience, legacy practices, and discipline knowledge.<br />
<br />
In summary, '''Integrative Systems Science''' allows us to identify, explore, and understand patterns of complexity through contributions from the foundations, theories, and representations of systems science and other disciplines relevant to the “problematique”. '''Systems Approaches to Practice''' address complex problems and opportunities using methods, tools, frameworks, patterns, etc., drawn from the knowledge of integrative systems science, while the observation of the results of systems practice enhances the body of theory. '''Systems Thinking''' binds the two together through appreciative and reflective practice using systems concepts, principles, patterns, etc.<br />
<br />
==Scope of Part 2==<br />
<br />
Part 2 of the SEBoK contains a guide to knowledge about systems, which is relevant to a better understanding of SE. It does not try to capture all of this systems knowledge here; rather, it provides an overview of a number of key aspects of systems theory and practice especially relevant to SE. <br />
<br />
The organization of knowledge in Part 2 is based around the Praxis Framework discussed above (IFSR 2012). The need to develop a clear guide to the underpinning knowledge of SE is one of the motivations behind the praxis framework. It is expected that the coverage of systems knowledge will be significantly increased in future versions of the SEBoK as this work progresses.<br />
<br />
The following diagram summarizes the way in which the knowledge in SEBoK Part 2 is organized. <br />
<br />
[[File:IFSR_ISA_July_2012_REV.png|thumb|center|700px|'''Figure 2. The Relationships between Key Systems Ideas and SE.''' (SEBoK Original)]]<br />
<br />
The diagram is divided into five sections, each describing how systems knowledge is treated in the SEBoK. <br />
# The [[Systems Fundamentals]] Knowledge Area considers the question “What is a System?” It explores the wide range of system definitions and considers [[Open System (glossary) |open systems]], system types, groupings of systems, complexity, and [[Emergence (glossary) | emergence]]. All of these ideas are particularly relevant to engineered systems and to the groupings of such systems associated with the systems approach applied to engineered systems (i.e. [[Product System (glossary) |product system]], [[Service System (glossary) |service system]], [[Enterprise System (glossary) |enterprise system]] and [[System of Systems (SoS) (glossary)|system of systems]] [[Capability (glossary) |capability]]).<br />
# The [[Systems Science]] Knowledge Area presents some influential movements in systems science, including the chronological development of systems knowledge and underlying theories behind some of the approaches taken in applying systems science to real problems.<br />
# The [[Systems Thinking]] Knowledge Area describes key concepts, principles and patterns shared across systems research and practice.<br />
# The [[Representing Systems with Models]] Knowledge Area considers the key role that abstract models play in both the development of system theories and the application of systems approaches.<br />
# The [[Systems Approach Applied to Engineered Systems]] Knowledge Area defines a structured approach to problem/opportunity discovery, exploration, and resolution, that can be applied to all engineered systems. The approach is based on systems thinking and utilizes appropriate elements of system approaches and representations. This KA provides principles that map directly to SE practice.<br />
<br />
Systems thinking is a fundamental paradigm describing a way of looking at the world. People who think and act in a systems way are essential to the success of both the research and practice of system disciplines. In particular, individuals who have an awareness and/or active involvements in both research and practice of system disciplines are needed to help integrate these closely related activities. <br />
<br />
The knowledge presented in this part of the SEBoK has been organized into these areas to facilitate understanding; the intention is to present a rounded picture of research and practice based on system knowledge. These knowledge areas should be seen together as a “system of ideas” for connecting research, understanding, and practice, based on system knowledge which underpins a wide range of scientific, management, and engineering disciplines and applies to all types of domains.<br />
<br />
==References== <br />
===Works Cited===<br />
<br />
IFSR. 2012. ''The Systems Praxis Framework, developed as a joint project of INCOSE and ISSS''. Vienna, Austria: International Federation for Systems Research (IFSR). Source is available at http://systemspraxis.org/framework.pdf.<br />
<br />
Martin J, Bendz J, Chroust G, Hybertson D, Lawson H, Martin R, Sillitto H, Singer J, Singer M, Takaku T. “Towards a Common Language for Systems Praxis”, proceedings of the 23rd INCOSE International Symposium, Philadelphia, June 2013.<br />
<br />
Sillitto, H G, 2012. " Integrating Systems Science, Systems Thinking, and Systems Engineering: understanding the differences and exploiting the synergies", Proceedings of the 22nd INCOSE International Symposium, 9-12 July, 2012, Rome, Italy.<br />
<br />
Wordnet. 2012. “Praxis.” Accessed 4/16/2013 at http://wordnetweb.princeton.edu/perl/webwn?s=praxis&sub=Search+WordNet&o2=&o0=1&o8=1&o1=1&o7=&o5=&o9=&o6=&o3=&o4=&h=<br />
<br />
===Primary References===<br />
Bertalanffy, L., von. 1968. ''[[General System Theory: Foundations, Development, Applications]]'', rev. ed. New York, NY, USA: Braziller.<br />
<br />
Checkland, P. B. 1999. ''[[Systems Thinking, Systems Practice]].'' Chichester, UK: John Wiley & Sons.<br />
<br />
===Additional References===<br />
Blanchard, B., and Fabrycky, W. 2010. ''Systems Engineering and Analysis'', (5th edition). Saddle River, NJ, USA: Prentice Hall. <br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape''. London, UK: College Publications, Kings College, UK.<br />
<br />
MITRE Corporation. 2011. ''Systems Engineering Guide: Comprehensive Viewpoint.'' Accessed 2/28/2012 at http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/comprehensive_viewpoint/<br />
<br />
MITRE Corporation. 2011. ''Systems Engineering Guide: Systems Thinking.'' Accessed 2/28/2012 at http://www.mitre.org/work/systems_engineering/guide/enterprise_engineering/comprehensive_viewpoint/systems_thinking.html<br />
<br />
Senge, P. M. 1990. ''The Fifth Discipline: The Art & Practice of the Learning Organization.'' New York, NY: Doubleday Business.<br />
<br />
<br />
----<br />
<center>[[Acknowledgements|< Previous Article]] | [[SEBoK Table of Contents|Parent Article]] | [[Systems Fundamentals|Next Article >]]</center><br />
<br />
[[Category:Part]][[Category:Part 2]]<br />
<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Systems_Approach_Applied_to_Engineered_Systems&diff=47648
Systems Approach Applied to Engineered Systems
2013-04-16T18:01:30Z
<p>Eleach: </p>
<hr />
<div><html><br />
<meta name="citation_title" content="Systems Approach Applied to Engineered Systems"><br />
<meta name="citation_author" content="Pyster, Art"><br />
<meta name="citation_author" content="Olwell, David H."><br />
<meta name="citation_author" content="Hutchison, Nicole"><br />
<meta name="citation_author" content="Enck, Stephanie"><br />
<meta name="citation_author" content="Anthony, James F., Jr."><br />
<meta name="citation_author" content="Henry, Devanandham"><br />
<meta name="citation_author" content="Squires, Alice (eds)"><br />
<meta name="citation_publication_date" content="2012/11/30"><br />
<meta name="citation_journal_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK)"><br />
<meta name="citation_volume" content="version 1.0.1"><br />
<meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page"></html><br />
This knowledge area (KA) provides a guide for applying the [[Systems Approach (glossary)|systems approach]] as a means of identifying and understanding complex problems and opportunities, synthesizing possible alternatives, analyzing and selecting the best alternative, implementing and approving a solution, as well as deploying, using and sustaining [[Engineered System (glossary)|engineered system]] solutions. The active participation of stakeholders during all the activities of the systems approach is the key to the success of the systems approach. <br />
<br />
In an engineered system context, a systems approach is a holistic approach that spans the entire life of the system; however, it is usually applied in the development and operational/support life cycle stages. This knowledge area defines a systems approach using a common language and intellectual foundation to ensure that practical systems concepts, principles, patterns and tools are accessible to perform [[Systems Engineering (glossary)|systems engineering]] (SE), as is discussed in the introduction to [[Systems|Part 2: Systems]]. <br />
<br />
==Topics==<br />
Each part of the Guide to the SE Body of Knowledge (SEBoK) is divided into KAs, which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
*[[Overview of the Systems Approach]]<br />
*[[Engineered System Context]]<br />
*[[Identifying and Understanding Problems and Opportunities]]<br />
*[[Synthesizing Possible Solutions]]<br />
*[[Analysis and Selection between Alternative Solutions]]<br />
*[[Implementing and Proving a Solution]]<br />
*[[Deploying, Using, and Sustaining Systems to Solve Problems]]<br />
*[[Stakeholder Responsibility]]<br />
*[[Applying the Systems Approach]]<br />
<br />
==Systems Approach==<br />
This KA describes a high-level framework of activities and principles synthesized from the elements of the systems approach, as described earlier in Part 2 of the SEBoK, and is mapped to the articles [[Concepts of Systems Thinking]], [[Principles of Systems Thinking]], and [[Patterns of Systems Thinking]]. The concept map in Figure 1 describes how the knowledge is arranged in this KA and the linkage to the KA in Part 3. <br />
<br />
[[File:Fig_1_Systems_Engineering_and_the_Systems_Approach_RA.png|thumb|650px|center|'''Figure 1. Systems Engineering and the Systems Approach.''' (SEBoK Original)]]<br />
<br />
According to Jackson et al. (2010, 41-43), the systems approach to engineered systems is a problem-solving paradigm. It is a comprehensive problem identification and resolution approach based upon the principles, concepts, and tools of [[Systems Thinking (glossary)|systems thinking]] and [[Systems Science (glossary)|systems science]], along with the concepts inherent in engineering problem-solving. It incorporates a holistic systems view that covers the larger context of the system, including engineering and operational environments, stakeholders, and the entire life cycle. <br />
<br />
<br />
Successful systems practice should not only apply systems thinking to the system being created, but should also utilize systems thinking in consideration of the way in which work is planned and conducted. See [[Enabling Systems Engineering|Part 5: Enabling Systems Engineering]] for further discussions on how individuals, teams, businesses and enterprises may be enabled to perform systems engineering.<br />
<br />
==References== <br />
<br />
===Works Cited===<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "[[What is the Systems Approach?]]". INCOSE ''Insight.'' 13(1): 41-43.<br />
<br />
===Primary References===<br />
Checkland, P. 1999. ''[[Systems Thinking, Systems Practice]]''. New York, NY, USA: John Wiley & Sons.<br />
<br />
Hitchins, D. 2009. "[[What are the General Principles Applicable to Systems?]]". INCOSE ''Insight.'' 12(4).<br />
<br />
Jackson, S., D. Hitchins, and H. Eisner. 2010. "[[What is the Systems Approach?]]". INCOSE ''Insight.'' 13(1): 41-43.<br />
<br />
===Additional References=== <br />
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology''. Hoboken, NJ, USA: John Wiley & Sons.<br />
<br />
Lawson, H. 2010. ''A Journey Through the Systems Landscape''. London, UK: College Publications, Kings College.<br />
<br />
Senge, P. M. 1990. ''The Fifth Discipline: The Art and Practice of the Learning Organization''. New York, Doubleday/Currency.<br />
<br />
----<br />
<center>[[Modeling Standards|< Previous Article]] | [[Systems|Parent Article]] | [[Overview of the Systems Approach|Next Article >]]</center><br />
<br />
<br />
<br />
[[Category:Part 2]][[Category:Knowledge Area]]<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Representing_Systems_with_Models&diff=47616
Representing Systems with Models
2013-04-15T21:00:47Z
<p>Eleach: </p>
<hr />
<div><html><br />
<meta name="citation_title" content="Representing Systems with Models"><br />
<meta name="citation_author" content="Pyster, Art"><br />
<meta name="citation_author" content="Olwell, David H."><br />
<meta name="citation_author" content="Hutchison, Nicole"><br />
<meta name="citation_author" content="Enck, Stephanie"><br />
<meta name="citation_author" content="Anthony, James F., Jr."><br />
<meta name="citation_author" content="Henry, Devanandham"><br />
<meta name="citation_author" content="Squires, Alice (eds)"><br />
<meta name="citation_publication_date" content="2012/11/30"><br />
<meta name="citation_journal_title" content="Guide to the Systems Engineering Body of Knowledge (SEBoK)"><br />
<meta name="citation_volume" content="version 1.0.1"><br />
<meta name="citation_pdf_url" content="http://www.sebokwiki.org/1.0.1/index.php?title=Main_Page"></html><br />
A [[Model (glossary)|model (glossary)]] is an abstraction of a [[System (glossary)|system]] that offers insight about one or more of the system's aspects, such as its [[Function (glossary) |function]], [[Structure (glossary)|structure]], properties, performance, [[Behavior (glossary)|behavior]], or [[Cost (glossary)|cost]]. <br />
<br />
Modeling of systems as [[Holistic (glossary)|holistic]], [[Value (glossary) | value]]-providing entities, has been gaining recognition as a central process of [[Systems Engineering (glossary)|systems engineering]]. The use of modeling and simulation during the early stages of the system design of complex systems and architectures can document system functions and requirements, assess the mission performance, estimate costs, evaluate tradeoffs and provide insights to improve performance, reduce risk, and manage costs. Modeling and analysis can complement testing and evaluation which occur later in the life cycle. In some systems, modeling and simulation may be the only way to fully evaluate performance (e.g., ballistic missile defense) or to evaluate system performance in severe scenarios (e.g., response to weapons of mass destruction attacks on the homeland). Furthermore, advanced simulations, e.g. flight simulators and command and control center simulations, can be a cost-effective technique for personnel training in accompaniment with operational system training (INCOSE 2012). Modeling serves to make [[Concept (glossary)|concepts]] concrete and formal, enhance [[Quality (glossary)|quality]], productivity, documentation, and innovation, as well as to reduce the cost and [[Risk (glossary) | risk]] of [[Systems Development (glossary)| systems development]]. Different types of models may be needed to represent systems in support of the analysis, specification, [[Design (glossary)|design]], and [[Verification (glossary)|verification]] of systems. This knowledge area provides an overview of models used to represent different aspects of systems.<br />
<br />
Modeling occurs at many levels: component, subsystem, system, and systems-of-systems throughout the life cycle of a system. Modeling is a common practice that is shared by most [[Engineering (glossary) | engineering]] disciplines, including: <br />
* electrical engineering, which uses electrical circuit [[Design (glossary) | design]] models<br />
* mechanical engineering, which uses three-dimensional computer-aided design models<br />
* software engineering, which uses software design and architecture models<br />
Each of these disciplines has its own language with its syntax and [[Semantics (glossary) | semantics]], serving as a means of communication among professionals in that discipline. Analytic models are used to support power, thermal, structural, and embedded real-time analysis.<br />
Modeling standards play an important role in defining system modeling concepts that can be represented for a particular domain of interest and enable the integration of different types of models across domains of interest. <br />
<br />
==Topics==<br />
Each part of the Guide to the Systems Engineering Body of Knowledge (SEBoK) is divided into knowledge areas (KAs), which are groupings of information with a related theme. The KAs in turn are divided into topics. This KA contains the following topics: <br />
* [[What is a Model?]]<br />
* [[Why Model?]]<br />
* [[Types of Models]]<br />
* [[System Modeling Concepts]]<br />
* [[Modeling Standards]]<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
<br />
INCOSE. 2012. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]]: A Guide for System Life Cycle Processes and Activities'', version 3.2.2. San Diego, CA, USA: International Council on Systems Engineering (INCOSE), INCOSE-TP-2003-002-03.2.2<br />
<br />
===Primary References===<br />
Dori, D. 2002. ''[[Object-Process Methodology – A Holistic Systems Paradigm]]''. Berlin, Germany: Springer Verlag. <br />
<br />
Estefan, J. 2008. ''[[A Survey of Model-Based Systems Engineering (MBSE) Methodologies]]'', rev, B. Seattle, WA: International Council on Systems Engineering. INCOSE-TD-2007-003-02. Available at http://www.incose.org/ProductsPubs/pdf/techdata/MTTC/MBSE_Methodology_Survey_2008-0610_RevB-JAE2.pdf.<br />
<br />
Friedenthal, S., A. Moore, and R. Steiner. 2009. "Chapter 2". ''[[A Practical Guide to SysML: The Systems Modeling Language]]''. Needham, MA, USA: OMG Press.<br />
<br />
Guizzardi, G. 2007. ''[[On Ontology, Ontologies, Conceptualizations, Modeling Languages, and (Meta)Models]]''. Proceedings of the Databases and Information Systems IV Conference, Amsterdam, Netherlands. Available at http://portal.acm.org/citation.cfm?id=1565425.<br />
<br />
INCOSE. 2007. ''[[INCOSE Systems Engineering Vision 2020|Systems Engineering Vision 2020]]''. Seattle, WA, USA: International Council on Systems Engineering. September 2007. INCOSE-TP-2004-004-02. Available at http://www.incose.org/ProductsPubs/products/sevision2020.aspx.<br />
<br />
Wymore, A.W. 1993. ''[[Model-Based Systems Engineering]]''. Boca Raton, FL, USA: CRC Press, Inc.<br />
<br />
===Additional References===<br />
Holt, Jon, and Simon Perry. 2008. ''SysML for systems engineering''. Stevenage: Institution of Engineering and Technology. http://site.ebrary.com/id/10263845. <br />
<br />
Grobshtein, Y. and Dori, D. ''Generating SysML Views from an OPM Model: Design and Evaluation''. Systems Engineering, 14 (3), Sept. 2011.<br />
<br />
West, P., J. Kobza, and S. Goerger, "Chapter 4, Systems Modeling and Analysis," in Parnell, G.S., P.J. Driscoll, and D.L Henderson (eds). 2011. ''[[Decision Making for Systems Engineering and Management]]'', 2nd ed. Wiley Series in Systems Engineering. Hoboken, NJ: Wiley & Sons Inc.<br />
<br />
----<br />
<br />
<center>[[Patterns of Systems Thinking|< Previous Article]] | [[Systems|Parent Article]] | [[What is a Model?|Next Article >]]</center><br />
<br />
<br />
[[Category:Part 2]][[Category:Knowledge Area]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Economic_Value_of_Systems_Engineering&diff=47602
Economic Value of Systems Engineering
2013-04-15T17:47:53Z
<p>Eleach: </p>
<hr />
<div>==Trends Toward Increasing the Value of Systems Engineering==<br />
With traditional projects, such as railroads, reservoirs, and refrigerators, a [[Systems Engineer (glossary)|systems engineer]] faced a self-contained system that typically had relatively stable requirements, a sound scientific base, and numerous previous precedents. As most modern systems are intended to become parts within one or more evolving [[System of Systems (SoS) (glossary)|systems of systems]] (SoS), the performance of effective SE takes on an ever-higher economic value, as the systems feature a rapidly increasing scale, dynamism, interdependence, human-intensiveness, sources of vulnerability, and novelty.<br />
<br />
This is corroborated by the [[Case Studies]] and [[Vignettes]] in Part 7. Shortfalls in SE lead to either extremely expensive cancelled systems or much more expensive systems in terms of total cost of ownership or loss of human life, as illustrated by the problems in the United States Federal Aviation Administration (FAA) Advanced Automation System (AAS), United States Federal Bureau of Investigation (FBI) Virtual Case File System, the Hubble Space Telescope, the Boeing 787 Dreamliner, and the Therac-25 medical linear accelerator. On the other hand, the Global Positioning System (GPS), Miniature Seeker Technology Integration Project (MSTI), and Next Generation Medical Infusion Pump Project all demonstrate that investment in thorough SE results in highly cost-effective systems. Figure 1 summarizes the analyses data by Werner Gruhl, which relates investment levels in SE to cost overruns of the United States National Aeronautics and Space Administration (NASA) projects (Stutzke 2005). The results indicate that there is a general correlation between the amount invested in SE within a program and cost overruns, demonstrating the critical role of properly allocating SE resources.<br />
<br />
[[File:NASA Image Part 1.png|700px|thumb|center|'''Figure 1. Relation of SE Investments to NASA Program Cost Overruns (Stutzke 2005).''' Released by NASA HDQRT./Gruhl.]]<br />
<br />
==Further Quantitative Evidence of the Value of Systems Engineering==<br />
Analysis of the effects of shortfalls in systems [[Architecture (glossary)|architecture]] and [[Risk (glossary)|risk]] resolution (the results of insufficient SE) for software-intensive systems in the 161-project Constructive Cost Model II (COCOMO™ II) database, shows a statistically significant increase in rework costs as a function of project size measured in source lines of code (SLOC): averages of 18% rework for ten-thousand-SLOC projects and 91% rework for ten-million-SLOC projects. This data has influenced many major system projects to reconsider initial underinvestment in SE (e.g., Boehm et al. 2004), and well as to address “how much SE is enough” by balancing the risks of under-investing in SE against those of over-investing (often called “analysis paralysis”), as shown in Figure 2 (Boehm, Valerdi, & Honour 2008).<br />
<br />
[[File:P1_EconValueSE_RiskBalancedfig2_BB.jpg|600px|thumb|center|'''Figure 2. Risk-Balanced “How Much SE Is Enough” (Boehm, Valerdi, Honour 2008).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
Typically, small projects can quickly compensate for neglected SE interface definition and risk resolution; however, as projects grow larger and have more independently-developed components, the cost of late rework negates any savings in reduced SE effort. Additionally, medium-sized projects have relatively flat operating regions, while very large projects pay extremely large penalties for neglecting thorough SE. Extensive surveys and case study analyses corroborate these results.<br />
<br />
Survey data on software cost and schedule overruns in ''My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader'' (Johnson 2006) indicates that the primary sources of the roughly 50% of the commercial projects with serious “software overruns” are the result of shortfalls in SE (lack of user input, incomplete requirements, unrealistic expectations, unclear objectives, and unrealistic schedules). The extensive survey of 46 government-contracted industry projects conducted by the Software Engineering Institute (SEI)/National Defense Industrial Association (NDIA) illustrated a strong correlation between higher project SE capability and higher project performance (Elm et al. 2007). Ongoing research that combined project data and survey data reported in “Toward an Understanding of The Value of SE” (Honour 2003) and “Effective Characterization Parameters for Measuring SE” (Honour 2010) has provided additional evidence as to the economic value of SE and further insights on critical factors the affect SE success.<br />
<br />
A calibrated model for determining “how much SE is enough” has been developed and is discussed in (Valerdi 2008) called '''[COSYSMO][http://en.wikipedia.org/wiki/COSYSMO]''' (Constructive Systems Engineering Cost Model). It estimates the number of person-months that a project needs for SE as a function of system size (i.e., requirements, interfaces, algorithms, and operational scenarios), modified by 14 factors (i.e., requirements understanding, technology risk, personnel experience, etc.), which dictates the amount of SE effort needed. Other economic considerations of SE include the costs and benefits of reuse (Wang, Valerdi & Fortune 2010), the management of SE assets across product lines (Fortune & Valerdi, 2013), the impact of SE on project risk (Madachy & Valerdi 2010), and the role of requirements volatility on SE effort (Pena & Valerdi 2010).<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
Boehm, B., Brown, A.W., Basili, V., and Turner, R. 2004. "Spiral Acquisition of Software-Intensive Systems of Systems." ''CrossTalk''. May, pp. 4-9.<br />
<br />
Boehm, B., R. Valerdi, and E.C. Honour. 2008. "The ROI of Systems Engineering: Some Quantitative Results for Software-Intensive Systems." ''Systems Engineering''. 11(3): 221-234. <br />
<br />
Elm, J. P., D.R. Goldenson, K. El Emam, N. Donatelli, and A. Neisa. 2008. ''A Survey of Systems Engineering Effectiveness-Initial Results'' (with Detailed Survey Response Data). Pittsburgh, PA, USA: Software Engineering Institute, CMU/SEI-2008-SR-034. December 2008. <br />
<br />
Fortune, J., and R. Valerdi. 2013. "A Framework for Systems Engineering Reuse." ''Systems Engineering'' 16(2).<br />
<br />
Honour, E.C. 2003. "Toward An Understanding of The Value of Systems Engineering." Proceedings of the First Annual Conference on Systems Integration, March 2003, Hoboken, NJ, USA. <br />
<br />
Honour, E.C. 2010. "Effective Characterization Parameters for Measuring Systems Engineering." Proceedings of the 8th Annual Conference on Systems Engineering Research (CSER). March 17-19, 2010. Hoboken, NJ, USA. <br />
<br />
Johnson, J. 2006. ''My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader''. Boston, MA, USA: Standish Group International.<br />
<br />
Madachy, R., and R. Valerdi. 2010. ''Automating Systems Engineering Risk Assessment''. 8th Conference on Systems Engineering Research, Hoboken, NJ.<br />
<br />
Pena, M., and R. Valerdi. 2010. "Characterizing the Impact of Requirements Volatility on Systems Engineering Effort." 25th Forum on COCOMO and Systems/Software Cost Modeling, Los Angeles, CA.<br />
<br />
Stutzke, R. 2005. ''Estimating Software-Intensive Systems''. Boston, MA, USA: Addison Wesley.<br />
<br />
Valerdi, R. 2008. ''The Constructive Systems Engineering Cost Model (COSYSMO): Quantifying the Costs of Systems Engineering Effort in Complex Systems.'' Saarbrücken, Germany: VDM Verlag.<br />
<br />
Wang, G., R. Valerdi, and J. Fortune. 2010. “Reuse in Systems Engineering,” ''IEEE Systems Journal''. 4(3): 376-384.<br />
<br />
===Primary References===<br />
Boehm, B., R. Valerdi, and E.C. Honour. 2008. "[[The ROI of Systems Engineering]]: Some Quantitative Results for Software-Intensive Systems." ''Systems Engineering'', 11(3): 221-234. <br />
<br />
Honour, E.C. 2010. "[[Effective Characterization Parameters for Measuring Systems Engineering]]." Proceedings of the 8th Annual Conference on Systems Engineering Research (CSER). March 17-19, 2010. Hoboken, NJ, USA. <br />
<br />
Valerdi, R. 2008. ''[[The Constructive Systems Engineering Cost Model (COSYSMO)]]: Quantifying the Costs of Systems Engineering Effort in Complex Systems.'' Saarbrücken, Germany: VDM Verlag.<br />
<br />
===Additional References===<br />
Elm, J.P., D.R. Goldenson, K. El Emam, N. Donatelli, and A. Neisa. 2008. ''A Survey of Systems Engineering Effectiveness-Initial Results (with Detailed Survey Response Data)''. Pittsburgh, PA, USA: Software Engineering Institute, CMU/SEI-2008-SR-034. December 2008. <br />
<br />
Johnson, J. 2006. ''My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader''. Boston, MA, USA: Standish Group International.<br />
<br />
Vanek, F., R. Grzybowski, P. Jackson, and M. Whiting. 2010. "Effectiveness of Systems Engineering Techniques on New Product Development: Results from Interview Research at Corning Incorporated." Proceedings of the 20th Annual INCOSE International Symposium. 12-15 July 2010. Chicago, IL.<br />
<br />
----<br />
<br />
<center>[[Systems Engineering Overview|< Previous Article]] | [[SEBoK v. 1.1 Introduction|Parent Article]] | [[Systems Engineering: Historic and Future Challenges|Next Article >]]</center><br />
<br />
[[Category:Part 1]][[Category:Topic]]<br />
<br />
{{DISQUS}}</div>
Eleach
https://sandbox.sebokwiki.org/index.php?title=Economic_Value_of_Systems_Engineering&diff=47601
Economic Value of Systems Engineering
2013-04-15T17:45:13Z
<p>Eleach: </p>
<hr />
<div>==Trends Toward Increasing the Value of Systems Engineering==<br />
With traditional projects, such as railroads, reservoirs, and refrigerators, a [[Systems Engineer (glossary)|systems engineer]] faced a self-contained system that typically had relatively stable requirements, a sound scientific base, and numerous previous precedents. As most modern systems are intended to become parts within one or more evolving [[System of Systems (SoS) (glossary)|systems of systems]] (SoS), the performance of effective SE takes on an ever-higher economic value, as the systems feature a rapidly increasing scale, dynamism, interdependence, human-intensiveness, sources of vulnerability, and novelty.<br />
<br />
This is corroborated by the [[Case Studies]] and [[Vignettes]] in Part 7. Shortfalls in SE lead to either extremely expensive cancelled systems or much more expensive systems in terms of total cost of ownership or loss of human life, as illustrated by the problems in the United States Federal Aviation Administration (FAA) Advanced Automation System (AAS), United States Federal Bureau of Investigation (FBI) Virtual Case File System, the Hubble Space Telescope, the Boeing 787 Dreamliner, and the Therac-25 medical linear accelerator. On the other hand, the Global Positioning System (GPS), Miniature Seeker Technology Integration Project (MSTI), and Next Generation Medical Infusion Pump Project all demonstrate that investment in thorough SE results in highly cost-effective systems. Figure 1 summarizes the analyses data by Werner Gruhl, which relates investment levels in SE to cost overruns of the United States National Aeronautics and Space Administration (NASA) projects (Stutzke 2005). The results indicate that there is a general correlation between the amount invested in SE within a program and cost overruns, demonstrating the critical role of properly allocating SE resources.<br />
<br />
[[File:NASA Image Part 1.png|700px|thumb|center|'''Figure 1. Relation of SE Investments to NASA Program Cost Overruns (Stutzke 2005).''' Released by NASA HDQRT./Gruhl.]]<br />
<br />
==Further Quantitative Evidence of the Value of Systems Engineering==<br />
Analysis of the effects of shortfalls in systems [[Architecture (glossary)|architecture]] and [[Risk (glossary)|risk]] resolution (the results of insufficient SE) for software-intensive systems in the 161-project Constructive Cost Model II (COCOMO™ II) database, shows a statistically significant increase in rework costs as a function of project size measured in source lines of code (SLOC): averages of 18% rework for ten-thousand-SLOC projects and 91% rework for ten-million-SLOC projects. This data has influenced many major system projects to reconsider initial underinvestment in SE (e.g., Boehm et al. 2004), and well as to address “how much SE is enough” by balancing the risks of under-investing in SE against those of over-investing (often called “analysis paralysis”), as shown in Figure 2 (Boehm, Valerdi, & Honour 2008).<br />
<br />
[[File:P1_EconValueSE_RiskBalancedfig2_BB.jpg|600px|thumb|center|'''Figure 2. Risk-Balanced “How Much SE Is Enough” (Boehm, Valerdi, Honour 2008).''' Reprinted with permission of John Wiley & Sons Inc. All other rights are reserved by the copyright owner.]]<br />
<br />
Typically, small projects can quickly compensate for neglected SE interface definition and risk resolution; however, as projects grow larger and have more independently-developed components, the cost late-rework negates any savings in reduced SE effort. Additionally, medium-sized projects have relatively flat operating regions, while very large projects pay extremely large penalties for neglecting thorough SE. Extensive surveys and case study analyses corroborate these results.<br />
<br />
Survey data on software cost and schedule overruns in ''My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader'' (Johnson 2006) indicates that the primary sources of the roughly 50% of the commercial projects with serious “software overruns” are the result of shortfalls in SE (lack of user input, incomplete requirements, unrealistic expectations, unclear objectives, and unrealistic schedules). The extensive survey of 46 government-contracted industry projects conducted by the Software Engineering Institute (SEI)/National Defense Industrial Association (NDIA) illustrated a strong correlation between higher project SE capability and higher project performance (Elm et al. 2007). Ongoing research that combined project data and survey data reported in “Toward an Understanding of The Value of SE” (Honour 2003) and “Effective Characterization Parameters for Measuring SE” (Honour 2010) has provided additional evidence as to the economic value of SE and further insights on critical factors the affect SE success.<br />
<br />
A calibrated model for determining “how much SE is enough” has been developed and is discussed in (Valerdi 2008) called '''[COSYSMO][http://en.wikipedia.org/wiki/COSYSMO]''' (Constructive Systems Engineering Cost Model). It estimates the number of person-months that a project needs for SE as a function of system size (i.e., requirements, interfaces, algorithms, and operational scenarios), modified by 14 factors (i.e., requirements understanding, technology risk, personnel experience, etc.), which dictates the amount of SE effort needed. Other economic considerations of SE include the costs and benefits of reuse (Wang, Valerdi & Fortune 2010), the management of SE assets across product lines (Fortune & Valerdi, 2013), the impact of SE on project risk (Madachy & Valerdi 2010), and the role of requirements volatility on SE effort (Pena & Valerdi 2010).<br />
<br />
==References==<br />
<br />
===Works Cited===<br />
Boehm, B., Brown, A.W., Basili, V., and Turner, R. 2004. "Spiral Acquisition of Software-Intensive Systems of Systems." ''CrossTalk''. May, pp. 4-9.<br />
<br />
Boehm, B., R. Valerdi, and E.C. Honour. 2008. "The ROI of Systems Engineering: Some Quantitative Results for Software-Intensive Systems." ''Systems Engineering''. 11(3): 221-234. <br />
<br />
Elm, J. P., D.R. Goldenson, K. El Emam, N. Donatelli, and A. Neisa. 2008. ''A Survey of Systems Engineering Effectiveness-Initial Results'' (with Detailed Survey Response Data). Pittsburgh, PA, USA: Software Engineering Institute, CMU/SEI-2008-SR-034. December 2008. <br />
<br />
Fortune, J., and R. Valerdi. 2013. "A Framework for Systems Engineering Reuse." ''Systems Engineering'' 16(2).<br />
<br />
Honour, E.C. 2003. "Toward An Understanding of The Value of Systems Engineering." Proceedings of the First Annual Conference on Systems Integration, March 2003, Hoboken, NJ, USA. <br />
<br />
Honour, E.C. 2010. "Effective Characterization Parameters for Measuring Systems Engineering." Proceedings of the 8th Annual Conference on Systems Engineering Research (CSER). March 17-19, 2010. Hoboken, NJ, USA. <br />
<br />
Johnson, J. 2006. ''My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader''. Boston, MA, USA: Standish Group International.<br />
<br />
Madachy, R., and R. Valerdi. 2010. ''Automating Systems Engineering Risk Assessment''. 8th Conference on Systems Engineering Research, Hoboken, NJ.<br />
<br />
Pena, M., and R. Valerdi. 2010. "Characterizing the Impact of Requirements Volatility on Systems Engineering Effort." 25th Forum on COCOMO and Systems/Software Cost Modeling, Los Angeles, CA.<br />
<br />
Stutzke, R. 2005. ''Estimating Software-Intensive Systems''. Boston, MA, USA: Addison Wesley.<br />
<br />
Valerdi, R. 2008. ''The Constructive Systems Engineering Cost Model (COSYSMO): Quantifying the Costs of Systems Engineering Effort in Complex Systems.'' Saarbrücken, Germany: VDM Verlag.<br />
<br />
Wang, G., R. Valerdi, and J. Fortune. 2010. “Reuse in Systems Engineering,” ''IEEE Systems Journal''. 4(3): 376-384.<br />
<br />
===Primary References===<br />
Boehm, B., R. Valerdi, and E.C. Honour. 2008. "[[The ROI of Systems Engineering]]: Some Quantitative Results for Software-Intensive Systems." ''Systems Engineering'', 11(3): 221-234. <br />
<br />
Honour, E.C. 2010. "[[Effective Characterization Parameters for Measuring Systems Engineering]]." Proceedings of the 8th Annual Conference on Systems Engineering Research (CSER). March 17-19, 2010. Hoboken, NJ, USA. <br />
<br />
Valerdi, R. 2008. ''[[The Constructive Systems Engineering Cost Model (COSYSMO)]]: Quantifying the Costs of Systems Engineering Effort in Complex Systems.'' Saarbrücken, Germany: VDM Verlag.<br />
<br />
===Additional References===<br />
Elm, J.P., D.R. Goldenson, K. El Emam, N. Donatelli, and A. Neisa. 2008. ''A Survey of Systems Engineering Effectiveness-Initial Results (with Detailed Survey Response Data)''. Pittsburgh, PA, USA: Software Engineering Institute, CMU/SEI-2008-SR-034. December 2008. <br />
<br />
Johnson, J. 2006. ''My Life Is Failure: 100 Things You Should Know to Be a Better Project Leader''. Boston, MA, USA: Standish Group International.<br />
<br />
Vanek, F., R. Grzybowski, P. Jackson, and M. Whiting. 2010. "Effectiveness of Systems Engineering Techniques on New Product Development: Results from Interview Research at Corning Incorporated." Proceedings of the 20th Annual INCOSE International Symposium. 12-15 July 2010. Chicago, IL.<br />
<br />
----<br />
<br />
<center>[[Systems Engineering Overview|< Previous Article]] | [[SEBoK v. 1.1 Introduction|Parent Article]] | [[Systems Engineering: Historic and Future Challenges|Next Article >]]</center><br />
<br />
[[Category:Part 1]][[Category:Topic]]<br />
<br />
{{DISQUS}}</div>
Eleach