Systems engineering has evolved as a multi-disciplinary technique capable of integrating several knowledge streams from science and engineering to design, develop, and deliver innovative systems that are more powerful, efficient, and cost-effective. The systems engineering process employs a number of new technology tools and methods that helps in identification of system functions, system requirements, design formulation, testing and validation. These include, among others, functional analysis and allocation, requirements analysis sheets, functional flow block diagrams, timeline analysis sheets, life cycle cost analysis, technical performance measures, and systems modeling.
This paper discusses how functional analysis and allocation (FAA) serves as an
important step in the systems engineering process by interfacing system requirements and operational functions with a view to optimizing design and performance. The first part gives a brief overview of the systems engineering structure and approaches, and a general understanding of the role and position that FAA occupies in the systems engineering process. The second part deals with the principles, practices, tools and methods that exist within the FAA framework, as also their interfaces and interactions that enable optimization of system design, architecture, and operations.
Systems engineering first emerged in the 1930s as a tool in the implementation of telephone systems on a commercial basis. Although early techniques in the systems engineering process were developed as part of the military logistic systems in World War II, the more significant developments in this discipline occurred in the context of the information and communication technology (ICT) revolution that the world has been witnessing since the latter half of the twentieth century. Most engineering projects usually depend upon the effective coordination of a host of experts drawn from different engineering disciplines, apart from integration of knowledge and information inputs that relate to complex systems and their functionalities. For instance, real-world knowledge inputs for a space exploration system design may be drawn from such fields as artificial intelligence and robotics, satellite imagery and GIS, bio-informatics and electrical circuitry.
Systems engineering aims at problem solving by a process of analysis of system-centric functional considerations that are then interfaced and integrated through synthesis to arrive at an optimized and cost-effective design. Rechtin (1991, p.1) simply defined a system as “a complex set of dissimilar elements or parts so connected or related as to form an organic whole.” A working system needs to integrate several subsystems in a harmonious and complete manner in order to be able to effectively deliver the expected outcomes. Adamsen (2000, p.2) quotes a more comprehensive definition from Dommasch and Laudeman:
A complete system is any complex of equipment, human beings, and interrelating logic designed to perform a given task, regardless of how complex the task may be. Logically, very large or complicated systems are broken into subsystems, to be fitted together like blocks to form the entire or total system.
The International Council on Systems Engineering (INCOSE, 2005) defines systems engineering thus:
Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem.
In other words, systems engineering can be seen as a comprehensive problem solving technique that uses technology and analytical tools to design and develop complex systems. Clark (2005) defines systems engineering as “a discipline that develops and exploits structured, efficient approaches to analysis and design to solve complex engineering problems.”
Systems engineering finds increasing applications in the design and development of large and complex systems. While a refrigerator or a washing machine may not fall within the ambit of a complex system, a remote sensing satellite, or an airline reservation system, or an air traffic control (ATC) system certainly does. So do artificial intelligence and robotic systems, advanced computing and information technology products, and GSM/CDMA-enabled communication systems.
Systems Engineering Process
Systems Engineering is a process that integrates different disciplines and expert work groups to facilitate a synergy that can successfully develop and deliver complex systems from the design stage through operational phase. This process calls for a precise understanding of business needs, system functionalities, and technical requirements in order to fulfill product quality and customer satisfaction. As Adamsen (2000, p.2) aptly noted, “the design and management of complex systems involves the execution of technical activities (e.g., requirements development, design, analysis, integration, verification, trade analysis, etc.) together with managerial activities (e.g., configuration management, risk management, etc.).”
The systems engineering process is easily distinguished from a manufacturing process. The latter aims at mass production of goods at lower time and cost through a series of repetitive jobs. Systems engineering, on the other hand, is at once a creative and analytical process that identifies and explores the dimensions of a problem in need of an appropriate solution capable of meeting the expectations of the user in terms of cost, performance, life cycle, and other operational metrics. Defining the problem can lead to formulation through needs analysis, requirements definition, identification of constraining factors and alternatives, feasibility studies, and synthesis. Bahill and Gissing (1998) explain the systems engineering process as consisting of seven steps (acronym: SIMILAR), not necessarily in sequence:
1. State the problem
2. Investigate alternatives
3. Model the system
5. Launch the system
6. Assess performance
(Figure 1: Systems Engineering Process, adapted from Bahill and Gissing, 1998).
Functional analysis is perceived as an early phase of activity in the systems development life cycle (SDLC) process. While the objective of systems engineering is to enable optimal design of the ultimate system that can deliver the expected outputs, the process must begin with a needs analysis that essentially makes an attempt to identify the system needs. In other words, a problem statement would be necessary that specifies what needs to be done (the characteristic functions of the system components), rather than how (the resource requirements). A problem statement could be conceived in terms of a mission statement, or scenario descriptions that depict system functions and interactions between subsystems in given contexts.
Needs analysis begins with the identification of the functions that the proposed system must accomplish at the top-level, as also the functional and operational environment, and the final output in terms of physical or knowledge items. Top-level allocations may call for trade studies in order “to make a knowledge-driven selection of the preferred description of the problem. This process begins with the recognition that the ultimate function is the need statement.” (Grady, 1998, p. 27). The new system must also be capable of remedying any deficiency that exists in the meta-system. End users are the primary source for inputs relating to the needs, while other interacting partners such as operators, vendors, OEMs, sponsors, and regulatory agencies can also contribute relevant information. The problem statement also identifies outputs in customer-centric terms, such as quantity or quality, time and cost. The test of a successful problem statement lies in its traceability to mandatory requirements, as also preference requirements after trade-offs.
Requirements Definition and Analysis
“The system is defined by function, and specific requirements are defined for each such function” (Eisner, 2002, p. 232). Requirements analysis follows from the identification of system needs, and is primarily intended to determine system component characteristics and requirements structuring. A clear understanding of the existing business processes is as much needed as the rationale and details relating to new business systems and change profile. Requirements structuring also involves the generation, selection and adoption of alternative strategies and systems. The objective of such an analysis is to determine the choice of the best systems and components that can enable realization of the chosen objectives and functional requirements of the organization.
Functional Analysis and Allocation
Functional analysis and allocation are discussed in detail later in this paper.
Systems Design Synthesis
Design synthesis is achieved through generation and selection of alternatives after a comparative analysis of effectiveness, performance, and cost parameters. The process involves partitioning of the whole system into subsystem components (CSCIs, HWCIs, etc). Alternative selection is largely based on system needs and objectives, while synthesis attempts in particular to identify decision support specifics in relation to multi-dimensional performance attributes. Important considerations in subsystems design include maintainability, support, flexibility, interoperability, optimality, and re-usability. Interface design would specify linkages and information flow between systems, subsystems, as well as externally interacting environment.
Systems Development Framework
Adamsen (2000, p.1) cites a time-tested pronouncement from Dommasch and Laudeman: “It is well to remember that any fool can design a complex system to do a simple job, but it is something else again to design a simple system to perform a complex task.” A standard model of systems development framework (SDF) proposed by Adamsen more importantly consists, among other things, of analysis and allocation, functional decomposition, and simulations. Analysis is primarily concerned with mission and objectives, functions and requirements, system characteristics (electrical, digital, RF, etc.), and failure modes and effects. Allocation pertains to the functionality, performance, and constraints as applicable to hardware and software systems and elements. Preliminary budget in terms of life cycle costs, technical performance measures, cost and schedule, risk and reliability are some other features that need to be integrated into the SDF.
Test and Validation
Notwithstanding the fact that design formulation might have been fully accomplished in accordance with requirements, a complex system still demands real-time test and evaluation in order to finally validate the efficacy of the system design. The type, extent, and tools of such validation would be determined by the phase of system development, although the approach remains common. Validation and verification is ideally carried out in a test environment created in a model of the functional system wherein the interactions, interfaces, and performance are critically evaluated.
A successful systems engineering management plan (SEMP) employs a top-down approach by looking at the system as a functional whole. “The whole is greater in some sense than the sum of the parts, that is, the system has properties beyond those of the parts. Indeed the purpose of building systems is to gain those properties.” (Rechtin, 1991, p. 1). The plan must provide key information that enables effective decision-making, and generate an iterative process flow that translates the needs of the user into the design of a comprehensive working solution. It employs suitable analytical techniques and tools (such as functional analysis and allocation) in order to define the problem and success determinants, and exploits matching resources in order to design and develop an advanced systems engineering process.
Other key activities in a SEMP include the identification and assessment of alternatives, cost analysis, systems control and support mechanism, and synthesis. It also focuses on “the interoperability and integration of all operational, functional, and physical interfaces” and ensures “that system definition and design reflect the requirements for all system elements: hardware, software, facilities, people, and data” (Blanchard, 2004, p. 16). Other considerations in an integrated system design solution include “all life cycle needs (i.e., development, manufacturing, test and evaluation, deployment, operations, support, training, and disposal)” as also the identification and management of technical and environmental risks (Blanchard).
Functional analysis is an early activity in the systems engineering process that examines and justifies system needs through an assessment of its states, modes, and capabilities (in terms of mission objectives, design features, manufacture, testing, deployment, support, reliability, etc.). This forms the background for evaluating and selecting alternative solutions that can effectively fulfill performance requirements and design criteria of the proposed system. Defining and acquiring system components must be taken up after a comprehensive functional analysis. Functions and sub-functions are then allocated appropriate requirements criteria in terms of design and performance.
“Functional analysis encompasses the process of translating system level requirements into detailed design criteria and results in the complete definition of the system configuration in functional terms” (Blanchard, p. 262).
Martin (1997, p. 128) identifies the whole process of functional analysis and allocation activities in nine steps as shown below:
? Define system states and modes
? Define system functions
? Define functional interfaces
? Define performance requirements and allocate to functions
? Analyze performance and scenarios
? Analyze timing and resources
? Analyze failure mode effects and criticality
? Define fault detection and recovery behavior
? Integrate functions
The functional analysis process begins with the identification of a range of system attributes. These include system states, modes, functions, and interfaces. Key system elements and functionalities need to be identified, and previously defined design requirements updated. This is achieved through a feedback loop in the functional flow diagram. A top-down approach becomes handy in functional analysis and allocation.
The mission analysis helps to determine top-level functions, such as the tasks to be performed by the system, their order of precedence, etc., by using software, hardware, and other system elements in order to implement different phases of the project. Functional analysis carries this process forwards iteratively to the specifics of lower-end functions such that appropriate system functionalities and operational principles can be identified.
Grady (1998, p. 27) illustrates the functional analysis activity by beginning with a function F that comprises the major block representing the need statement. The activity calls for a further creative process that aims at describing the lower level or subordinate functions in order “to decompose the grand problem represented by the need into a series of smaller, related problems and determine what kinds of resources could be applied to solving these smaller problems in a way that their synergism solves the greater problem” (Grady). If the mission objective is to transport a specified payload into space in a low earth orbit, the related functions may be listed as: Integrate and Prepare for Transport (F1); Launch (F2); Transport (F3); Release Payload (F4). These lower-end functions are then integrated into a rocket launching system. However, these functionalities would differ if the payload were to be launched by using a cannon, or the Pegasus of the Orbital Science Corporation (Grady).
“Functional analysis identifies WHATs from a requirements perspective, and this leads to the accomplishment of trade-offs and the description of the HOWs pertaining to the completion of functions.” (Blanchard, p. 18). The identification of functional characteristics would comprise of both quantitative and qualitative performance measures for systems and equipment, apart from dynamic requirements, such as rate, motion, etc. Performance constraints at the top-end and lower levels are also assessed. Functional analysis thus tells the system engineer as to what the system can be expected to deliver.
Functional analysis is thus conducted in an iterative manner by defining and refining system requirements, performance characteristics, system states, and operational modes in the light of the mission objectives, performance requirements, system needs, and synthesis. A time line analysis would be imperative in case of systems that are highly sensitive to the time factor.
Functional decomposition aims at describing what a system must do, irrespective of how it is to be done. The process begins with the context representation of the system as a whole, and then goes on to further decompose it into subsystem elements. Various activities to be performed by various system elements are analyzed, outputs identified, and costs estimated. The business model is then drawn up, both in terms of the existing profile and the future scenario. Functional decomposition therefore is a method for describing functions at the lower tier, and the order of their interacting relationships.
A variant of the functional analysis technique commonly applied in the avionics field is known as hierarchical functional analysis. The required lower level functionalities are listed as subordinate to the parent function, as contrasted from a sequencing of related functions in the functional flow diagramming method. Allocation within the architecture is done in a one-to-one interface (Grady, p.35). Although useful in the design of modular electronic devices, this technique does not enable time line analysis.
Kossiakoff and Sweet refer to an advanced concept of functional decomposition called function-class decomposition (FCD) that is a hybrid of object-oriented approach and conventional analysis. It aims at “the top-down decomposition of complex systems into a hierarchy of functional subsystems and components, while at the same time identifying objects associated with each unit” (p. 381). The standard object-oriented method that adopts a bottom-up platform for system design generally tends to result in a “flat” organization. On the other hand, the FCD technique relies upon functional decomposition and allocation, and “seeks to provide a top-down approach to system partitioning by using functional decomposition to define a hierarchical architecture, into which objects are integrated.” (Kossiakoff & Sweet). The success of FCD in the development of large and complex systems may be partly attributed to its use of UML class diagrams, and the iterative process that is capable of effectively partitioning the system at lower levels.
FAA Techniques and Tools
Functional analysis and allocation (FAA) attempts to translate the stated system objectives into a description of the expected functional behavior of system elements. The allocation task aims at forging traceability and interactions among requirements, functionalities, and system elements. Several tools and techniques are employed to accomplish this activity, such as the following:
? Data Flow Diagrams (DFD)
? Functional Flow Block Diagrams (FFBD)
? Context Diagrams (CD)
? Behavior Diagrams (BD)
? State/Mode Diagrams
? Structured Analysis and Design Technique (SADT)
? Integrated DEFinition Function Model (IDEF)
? Time Line Analysis Sheets (TLAS)
? Requirements Analysis Sheets (RAS)
A data flow diagram, for instance, is a versatile tool for not only facilitating the analytical process (including gap analysis) but also modeling a variety of systems in the logical or physical plane, or as part of the business process reengineering (BPR) process. Hoffer, George, and Valacich (2000, p. 303-304) cite the exemplary case of the IBM Credit Corporation experience reported by Hammer and Champy in 1993. Two innovative managers of the Corporation investigated the business process relating to finalizing a financial deal. They found to their dismay that from the time a salesperson took a call for credit sanction, the entire process took six business days to run through the mill of various desks (sales person – log request – credit files check – interest rates – loan agreement – quote letter – salesperson). Each of the process channels was independent, and transactions mostly manual, with papers and files shuttling back and forth. By reengineering the business process, these managers found that the task of generating a contract could actually be done in a matter of 90 minutes (as against 6 days) by positioning one generalist, supported by a networked computer system for information access and processing. The DFD below shows how this was accomplished through a business process reengineering that involved functional analysis, allocation, and design:
Functional Flow Block Diagram (FFBD)
“The accomplishment of functional analysis is facilitated through the development of functional flow block diagrams.” (Blanchard, p. 262). Functional flow block diagrams (FFBD) help the systems engineer to further analyze the multi-dimensional functions of systems and subsystems in relation to timeframes, series-parallel relationship specifications, and determination of key resource requirements (Blanchard). Block diagrams simplify system design representation, interfaces, and interactions. In this method, systems are represented as blocks, or transfer elements with the flow of action denoted by directional arrows. Each block has a minimum of an input and an output. The block diagram describes processes through connecting arrows between blocks.
Utilization of the functional flow block diagramming tool enables incorporation of several activities in the system life cycle, their order of occurrence, and relationships into the system design in an integrated manner. The purpose of this diagramming technique is “to progressively and systematically work down to the level where resources can be identified with how a task or function should be accomplished.” (Martin, 1997, p. 126). Functions are developed “concurrently and iteratively to define functional relationships and dependencies, including internal and external functional interfaces.” (Martin).
Process diagram is yet another tool in functional analysis. According to Grady (p.34), the fundamental distinction between a FFBD and a process diagram consists in the fact that the latter represents “a sequence of things that must happen whereas the latter is a model of physical reality.” The blocks in a process diagram stand for physical things while a functional flow diagram is incapable of reflecting the physical situation and the system configuration as such. The U.S. Air Force devised a variant of the process diagram called IDEF diagram. A combined acronym of ICAM (integrated computer-aided manufacture) analysis and DEFinition, the IDEF technique gradually evolved into “an IDEF0 for process analysis, IDEF1X for relational data analysis, IDEF2 for dynamic analysis, and IDEF3 for process description, and several others.” (Grady).
Functional flow block diagrams are versatile in applications and can be particularly useful in the analysis and design of large and complex systems. For example, the physical decomposition of a complex ATM system adapted from Ghafari (2006) given below highlights the advantages of the FFBD technique:
Time Line Analysis Sheets (TLAS)
While FFBDs help define the series-parallel relationships of system elements in general, time line analysis sheets (TLAS) are useful in developing these interactions in an objective and time-centered manner. This is achieved by the addition of more details relating to the definition as well as the tenure of different functions. More importantly, TLAS can specify time-bound functions that have a significant impact on various operational parameters, such as operating time, overlaps, availability of systems, and downtime for maintenance.
Requirements Allocation Sheets (RAS)
The task of functional analysis and allocation is closely dependent on, and follows from, the definition and analysis of requirements. These requirements may revolve around system needs as well as operational and maintenance requirements. “Requirements are characteristics that identify the accomplishment levels needed to achieve specific objectives for a given set of conditions. A requirement can be either a threshold or an objective.” (Martin, 1997, p. 8). Martin categorizes requirements as primary, derived, contractually binding, technical, or specifications-driven.
Performance requirements of system elements need to address a range of design features both on the qualitative and quantitative aspects, such as size, volume, output, weight, reliability, safety and supportability, maintainability, the need for human support, etc. Requirements allocation sheets are used “as the primary document for the identification of specific design requirements based on the functional analysis.” (Blanchard, 2004, p. 262). It is therefore useful to draw up RAS for every block in the FFBD. Information inputs in RAS would include, among other things, the basic objective and criticality of the function, the performance characteristics that the function is expected to deliver, and the design constraints that may arise in respect of that function.
System requirements basically concern software and hardware needs linked to system specifications, test requirements (such as integration and simulation, data, range, and equipment). Operational and technical management requirements relate to performance measures (such as accuracy, power, footprint, size and range, lethality), reliability parameters (such as readiness and failure rates, availability, cost benefit ratio), utilization needs (capacity, stress, and duty cycle), operating environment and lifecycle, and maintenance issues (downtime, upgrades, overhauls), etc. Other system-wide requirements (cost, schedule, etc.) also need to be defined and expressed as suitable models.
Requirements definition and analysis is an important precursor to the key approaches that concern functional analysis and allocation. Eisner (2002, p. 234) recommends a classification of requirement types by virtue of their levels of importance in terms of applicability in decreasing order as: “shall”; “shall, where practicable”; “preferred” or “should”; and “may”.
Life Cycle Considerations
A sound systems engineering process is invariably rooted in a life cycle approach that encompasses “all phases to include system design and development, production and/or construction, distribution, operation, sustaining maintenance and support, and retirement and material phase-out” (Blanchard, 2004, p. 16). Such an approach also facilitates a continuous appraisal and re-validation of the system in tune with the basic benchmark, apart from enabling continuous process improvement. Other benefits of life cycle considerations include better design and development, cost reduction, customer appeal, and enhanced reliability.
“The process of sub-dividing a system into modular building blocks is called functional allocation” (Kossiakoff and Sweet, 2003, p.10). In this context, Kossiakoff and Sweet define a system as “a set of interrelated components working together as an integrated whole to achieve some common objective.” Functional analysis activity can accomplish its objective only when functions and sub-functions within the system are allocated suitable requirements criteria in terms of both performance and design. Such requirements emerge in tandem with the identification of system capabilities, design and synthesis, time line and trade-off studies, and cost-benefit analysis.
Complex systems are decomposed into smaller building blocks precisely with a view to facilitating a performance-oriented integration of the parts into a working whole. Integration makes every block a perfect ‘fit’ in physical (interfaces) and functional (interactions) terms with its neighboring blocks and externally interacting environment. When systems are subdivided into building blocks, the concept of modularity emerges. “Modularity is a measure of the degree of mutual independence of the individual system components” (Kossiakoff & Sweet, p. 10). The design of an individual block impacts that of other system elements, and vice versa, ultimately resulting in the generation of a functional response that the system as a whole is expected to perform out of inputs from its overall operating environment. “An essential goal of systems engineering is to achieve a high degree of modularity – to make interfaces and interactions as simple as possible for efficient manufacture, system integration, test, operational maintenance, reliability, and ease of in-service upgrading.” (Kossiakoff & Sweet, p. 10).
Functions are represented by action verbs to signify the specified action or task. Such functions and interfaces are listed in function trees, lists or FFBDs. The characteristics and operational behavior of system elements indicate the tasks that the system needs to perform. System elements primarily constitute the basic functional building blocks. They exist at the component level, performing a specific function through a single medium, such as data, energy, signals, etc. These building blocks are further composed of functional subsystems at the lower tier. Functional design activity includes the selection and sub-division of functional elements corresponding to the prescribed tasks. System functional specifications thus form an important component of the systems engineering process. (Kossiakoff & Sweet, p. 74).
Functional specifications are linked to system requirements that define performance
parameters. Performance constraints need to be identified as part of design specifications in order to provide for selection of alternatives. Constraints may arise internally or from external environment, such as regulatory restrictions, or even time, energy, cost, and operational constraints. Refinement loops in the functional flow block diagrams are used to represent and remedy performance constraints.
Cost and budgets
Cost definition, budget estimates, and cost control measures form vital components in the systems engineering process, as the overriding goal is to achieve mission objectives in a cost-effective manner. Trade-studies in particular would be concerned with a comparison of costs assigned to different alternatives in order to rationally arrive at the selection of an optimal design. Cost modeling also acts as an effective control process at review stages in the project life cycle by ascertaining whether mission objectives are still attainable, given the cost and performance constraints. The life-cycle cost of a system is “the total of the direct, indirect, recurring, nonrecurring, and other related costs incurred, or estimated to be incurred in the design, development, production, operation, maintenance, support, and retirement [of it] over its planned life span” (NASA, 1995, p. 91). In other words, life cycle costs include the cost of acquisition, operation, support, and disposal of a working system during its lifetime.
It is also necessary to ensure that cost estimates keep pace with system design and developmental phases.
Technical Performance Measurement (TPM)
“Technical performance measurement is a technique for assessing progress toward meeting a technical performance requirement or objective.” (Martin, 1997, p. 8). Performance expectations are determined in advance against designated timeframes for a given project. Actual performance would depend to a large extent on the functions of the system and subsystems that have been previously identified and allocated. By using TPM, a systems engineer can review and compare actual performance with planned performance, and initiate changes for risk mitigation in respect of failing elements, requirements, or parameters through redefining or reallocation. Technical audits conducted at important transition phases in the SDLC help in reviewing technical progress vis-a-vis the projected technical parameters and requirements.
Systems engineering is an advanced discipline that employs scientific and technical knowledge and tools to create complex systems. It is multi-disciplinary in applications, and uses a wide range of methodologies, metrics, and algorithms for analysis, design, and synthesis. Systems engineering is concerned more with problem-solving methods than the solution as such. Analysis of system needs, requirements analysis, functional analysis and allocation, trade-off studies, technical performance measures and metrics, alternatives analysis, synthesis and optimization, testing and validation, modeling and simulation are some of the more important ingredients of the systems engineering process.
Functional analysis and allocation links various levels of system and subsystem functionalities with the specified requirements, and helps in drawing up the functional flow diagram that forms the basis for the successful design of a cost-effective system. As an effective tool in the systems engineering process, FAA decomposes a large problem into smaller inter-connected functional blocks to generate a synergy in accomplishing a final solution. With systems becoming more complex in keeping with the mind-boggling pace of technological advances in the new millennium, systems engineering is bound to retain a place of pride more as an unavoidable necessity than a comfort.
Adamsen, P.B. (2000). A framework for complex systems development. Florida: CRC Press.
Bahill, A.T., & Gissing, B. (1998). Re-evaluating systems engineering concepts using systems thinking, IEEE transaction on systems, man and cybernetics, Part C: Applications and reviews, 28(4), 516-527. Retrieved February 25, 2006, from http://g2sebok.incose.org
Blanchard, B.S. (2004). Systems engineering management. New Jersey: Wiley
Clark, A.J. (2005, May 4). An introduction to systems engineering. Retrieved February 22, 2006, from http://www.isr.umd.edu/ISR/about/definese.html
Eisner, H. (2002). Essentials of project and systems engineering management. New York: Wiley.
Ghafari, E. (2006). Functional analysis and allocation tools. Retrieved March 04, 2006, from http://g2sebok.incose.org
Grady, J.O. (1998). Systems validation and verification. Florida: CRC Press.
Hoffer, J.A., George, J.F., & Valacich, J.S. (2000). Modern systems analysis and design (2nd ed.). New York: Addison-Wesley.
INCOSE (2005). What is systems engineering? Retrieved February 26, 2006, from http://www.incose.org/practice/whatissystemseng.aspx
Kossiakoff, A., & Sweet, W.N. (2003). Systems engineering principles and practice. New Jersey: Wiley
Martin, J.N. (1997). Systems engineering guidebook. Florida: CRC Press.
NASA. (1995). Systems engineering handbook. Retrieved February 11, 2006, from
Rechtin, E. (1991). Systems architecting: Creating and building complex systems. Englewood Cliffs: Prentice Hall.