University of Twente

University of Twente EEMCS / Electrical Engineering Control Engineering Systems Engineering and Design The search for a knowledge exchange model or Wessel Ganzevoort Pre-doc Supervisors prof.dr.ir. J. van Amerongen dr.ir. J.F. Broenink October 2005 Report nr. 037CE2005 Control Engineering EE-Math-CS University of Twente P.O. Box 217 7500 AE Enschede The Netherlands

Systems Engineering and Design or The search for a knowledge exchange model Wessel Ganzevoort

The image on the previous page is a generated image based on the convergence of a sphere towards a 6 rule linear iterated function system (IFS) fractal in three dimensions with a scale ratio of 1:3.

Summary This document is the result of an individual assignment. The goal of this assignment was twofold. The first part was to give an overview of systems engineering as commonly used in every-day practice and to evaluate the use of the generally available process models as can be found in literature. This overview was regarded as useful because most literature only focuses on one particular process model and describes that model in detail. Although that might give a clear insight in that specific process model, it is not useful in deciding if that model is suitable for a specific problem or system. The second part of the assignment was to investigate the process of selection and development of a process model for the purpose of a knowledge exchange model. The reason for this followed partly from the first part; the results showed that selecting a general process model is not trivial and often not sufficient when a specific systems needs to be developed. The results of the first part of this assignment can be used in the course "systems engineering" to include a broader view of the systems engineering activities and process models. The results of the second part can be used as a guideline for future students doing their individual assignments. Keywords: systems engineering, process model, knowledge exchange, system life cycles, systems engineering methods and tools. Samenvatting Dit document is het resultaat van een predoctoraal-opdracht. Het doel van deze opdracht was tweeledig. Het eerste deel moest een overzicht geven van de dicipline "systems engineering, zoals deze tegenwoordig wordt bedreven. Daarnaast moest er een evaluatie worden gedaan van de algemeen beschikbare procesmodellen zoals die in de literatuur worden beschreven. Deze evaluatie werd als nuttig beschouwd omdat in de meeste literatuur slechts één processmodel in detail wordt beschreven. Hoewel dit een duidelijk beeld geeft van dat specifieke proces en al haar details, is het niet erg bruikbaar bij de keuze van een procesmodel voor een specifiek probleem. Het tweede deel van de opdracht moest dan ook het onderzoek beschrijven naar het kiezen en ontwikkelen van een procesmodel voor kennisuitwisseling. De reden hiervoor volgde deels uit het eerste deel van de opdracht waar het resultaat was dat de selectie van een generiek procesmodel niet triviaal is en vaak niet toereikend wanneer een specifiek systeem moet worden ontwikkeld. Het resultaat van het eerste deel van deze opdracht kan gebruikt worden in het vak "systems engineering", zodat een breder overzicht van de systems engineering activiteiten en processen kan worden gegeven. Het resultaat van het tweede deel kan worden gebruikt als een leidraad voor toekomstige studenten die een predoctoraal-opdracht of individuele onderzoeksopdracht (IOO) gaan doen. i

ii

Table of contents Summary Samenvatting i i 1 Introduction 1 2 The system life cycle approach 3 2.1 The system life cycles....................................................4 2.1.1 Conceptual phase............................................ 4 2.1.2 Preliminary phase............................................ 5 2.1.3 Detailed and development phase................................ 6 2.1.4 Production and construction phase.................................... 7 2.1.5 Product use, support and maintenance phase............................ 8 2.1.6 Phase-out and disposal phase........................................ 9 2.2 The systems engineering activities......................................... 10 2.2.1 System analysis.................................................. 10 2.2.2 Functional analysis............................................... 11 2.2.3 Requirements analysis............................................. 11 2.2.4 Architecture synthesis............................................. 12 2.2.5 Requirements verification.......................................... 13 2.2.6 Functional verification............................................. 14 2.2.7 System verification............................................... 14 2.3 Systems engineering methods and tools..................................... 15 2.3.1 Change control................................................... 15 2.3.2 Baselines....................................................... 16 2.3.3 Requirements management......................................... 17 2.3.4 Document reviews................................................ 18 2.3.5 Roadmapping.................................................... 19 2.3.6 Final note about systems engineering methods and tools.................. 20 iii

3 Systems engineering process models 21 3.1 Process model taxonomy................................................ 21 3.2 Waterfall model........................................................22 3.3 Waterfall model with limited feedback...................................... 23 3.4 Waterfall model with full feedback......................................... 25 3.5 V-model.............................................................. 26 3.6 Spiral model.......................................................... 27 3.7 CAFCR model........................................................ 28 4 The search for a knowledge exchange model 31 4.1 Choosing a systems engineering process model............................... 32 4.2 Developing a systems engineering process model............................. 32 4.3 Case study: individual assignment......................................... 33 4.3.1 Process model................................................... 33 4.3.2 Phase 1 Concept phase............................................ 35 4.3.3 Phase 2 Pre-study phase........................................... 35 4.3.4 Phase 3 Execution phase........................................... 35 4.3.5 Phase 4 Reporting phase........................................... 36 4.3.6 Final remarks.................................................... 36 5 Towards a knowledge exchange model 37 6 Conclusion and recommendations 39 6.1 Conclusion........................................................... 39 6.2 Recommendations...................................................... 39 Acronyms 41 References 43 iv

1 Introduction Systems Engineering is, as stated by the International Council on Systems Engineering (INCOSE), an engineering discipline whose responsibility is creating and executing an interdisciplinary process to ensure that the customer and stakeholder's needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system's entire life cycle. This definition of systems engineering is only one of many definitions that can be found. This is also reflected in the way systems engineering is practised; a vast number of methods, tools and processes are available and advocated in numerous books and articles about this subject. The goal of this assignment is to give an overview of systems engineering as commonly used in every-day practice and evaluates the use of the generally available process models. However, even though there are many process models to choose from, these process models seldom fit a specific problem or system to be developed. It is for that reason that additional to the overview of these process models, also the development of a new process model is considered. In most literature, for example (Blanchard, B. and Fabricky, W. 1998), the system life cycle is seen as a process and each individual cycle or phase has a set of specific activities in order to complete that phase. In this document a slightly different approach is used and the system life cycle is taken as a given and not having the completion of the system life cycle as a goal in itself. Specific tasks are used to structure the work that needs to be done during each phase in a systematic and ordered way. The systems engineering process models can than be seen as the glue that holds the system life cycle and the systems engineering activities together in a structured way. The systems engineering methods and tools are aids to help them stick (see figure 1). Systems life cycles Systems engineering activities Methods and tools Systems engineering process Figure 1 General overview A drawback of the system life-cycle approach is that it might imply some sort of linearity over time. This is not always correct. A better approach could be a more holistic approach to see the system and its and life cycles as a set of parallel activities. A model that takes this more holistic approach of systems engineering is the CAFCR model (Muller, G. 2004) as described in chapter 3. The method described by (Hatley, D., Hruschka, P. and Pirbhai, I. 2000) also takes a more concurrent development approach. Unfortunately, it is out of the scope of this assignment to explore this holistic idea in detail. This document focuses on technical systems engineering issues only. Project management issues like planning, budget control, resource allocation and securing are not in the scope of this assignment and will not be addressed here. 1

Some words about the terminology used in this document are in place. This is important because a lot of different definitions are in use and stating the terms used in this document will (hopefully) remove any confusion. In this document, the word "system" is used as a general term to describe the complete set of components of an entity consisting of hardware, software, people (customers), and processes; i.e. the whole set of operational capabilities of a product. The term "product" is used to reflect any outcome of a systems engineering process. It can be a piece of hardware, a piece of software or even a process. In that sense, it is a only a part of the system. A "customer" is anyone that has an interest in the project or outcome of the project. This means that the customer can be both internal and external. External customers are not connected to the company where the product is developed and an internal customer is anyone within the company with an interest in the product. This may include the and test engineers, production engineers, project management and end-users of the product. In other documentation the word "user" is also used to indicate the customer as is meant in this document. Document outline Chapter 2 starts with a discussion of the system life cycle that a system goes through during its complete life time. Next, the chapter describes a set of systems engineering activities that help the systems engineer to let the systems life cycle move smoothly. The chapter concludes with some systems engineering methods and tools that can aid the systems engineer to implement a systems engineering process. Chapter 3 gives an overview of commonly used systems engineering processes. These "off the shelf" processes are described and their application in specific development environments is discussed. The information in chapters 2 and 3 is not intended to be complete. It merely gives an overview and summary of the life cycle phases and systems engineering activities, methods and tools. A lot of documentation and good books are available on these subjects. The documentation used for this document, can be found in the references. In some cases additional details are included based on the author s own experience. These details are included because they are important to note and are often omitted in other books and documentation on the subject. Chapter 4 challenges the use of the generally available process models for use in specific projects and environments. It describes the development of a process model to fit the environment and the system to be ed and can therefore be seen as a metasystems engineering activity. The chapter ends with a case study for the development of a process model for doing an individual assignment at the university as an example. Chapter 5 proposes the use of Hitchins formal method for the development of a new process model. The chapter gives a broad outline of the method and how it can be used to develop a model for a system that involves the knowledge exchange between universities and (private) companies. In chapter 6, the conclusions and recommendations derived from this assignment are presented. 2

2 The system life cycle approach Current systems engineering is almost always based on the system life cycle approach. Although other, more ad-hoc methods and approaches are still used, this document will focus on the system life cycle approach. Many different names and definitions are in use for the life cycles of a system. In this document a generalization of these names and definitions has been made. The system life cycle in this document is organized in the following phases: Conceptual phase; Preliminary phase; Detailed and development phase; Production and construction phase; Product use, support and maintenance phase; Phase-out and disposal phase. In some cases these life cycles may be subdivided into additional phases. For example, the detailed and development phase can be divided into two phases; a detailed phase to finalize all requirements, and a development phase to do the actual implementation of the product. When a concurrent approach is used, a life cycle phase tends to span a broader range of sub phases. It is not the goal of this document to specify and describe all these phases in detail. In figure 2 the system life cycles are depicted. Note that this is not a process description. The figure only shows the life cycles order. A process description is needed to deal with the complexity and the relations between the different life cycles. Processes that can be used in the life cycle approach are described in chapter 3. Conceptual Preliminary Detailed Production/ Construction Support/ Maintenance Phase-out/ Disposal Figure 2 System life cycles Systems engineering activities encompass all specific activities that need to be accomplished during the lifetime of a product. As with the description for the system life cycles, there are a lot of different definitions and names in use. Again, these names and definitions have been generalized and organized into the following categories: System analysis; Functional analysis; Requirements analysis; Architecture synthesis; Requirements verification; Functional verification; System verification. 3

Of course these life cycles and activities can be broken down to include more details to match specific products, projects and organizations, but that is out of scope for this document. Section 2.1 deals with the system life cycles and describes the goals of the activities, sources, means, results and outputs of the different phases of the system life cycle and can be seen as the "what-to-do" part. Section 2.2 will go into more detail about the specific activities that need to be performed during the system life cycles and can therefore be seen as the "how-to-do-it" part. Section 2.3 describes the methods and tools available for the systems engineering activities and subsequently can be seen as the "whatto-do-it-with" part. 2.1 The system life cycles System life cycles are the phases a system goes through during its complete life. This section describes these phases in more detail. An extensive and elaborate discussion of these phases is out of scope for this document and can be found elsewhere in literature. 2.1.1 Conceptual phase Goal The goal of the activities in the conceptual phase is to establish a definition of the system with a focus on system products that are required to satisfy the operational requirements based on market opportunities or customer needs. During this phase, the first ideas about functionality and useability are conceived and a collection of ideas and investigations for new products is assembled. Sources These ideas can come from a customer (market pull) or from within the organisation (technology push). To see if those ideas are of any use, the conceptual phase should answer some important questions. The information and answers for these questions can come from several different sources. For market pull, the ideas should come from (external) customer needs. Often the customer does not know exactly what he needs in terms of requirements. Only a global idea of the functionality is present. The main challenge is to translate these global ideas into a set of requirements. In case of technology push, the information can come from a series of sources. Science, fundamental technological research and applied technological research are common sources of information. It is important that this phase is conducted with an open mind and to keep all options open. Means There are several means that the systems engineer can employ to characterize the new ideas from the aforementioned sources: Discussions; Queries; Risk assessments; Reviews. In some (most) cases there will be blank spots in the required functionality. To cope with these blank spots, the systems engineer should characterize these blank spots. 4

This can be done by characterizing the required functions, the required performance, the interface to other systems or subsystems and the operating environment of the product. Results The results of the activities in this phase should consist of one or more concepts for new or improved systems which have been approved by formal reviews. Output At the end of the conceptual phase (at least) the following items should have been produced: System specifications for products and interfaces; Use-cases for system verification against user needs; Baselines for requirements, documentation and ; Definition of the systems engineering process that fits the system and product development. More information about output documentation of the conceptual phase can be found in (IEEE 1998) and (Stevens, R., Brook, P., Jackson, K. and Arnold, S. 1998). 2.1.2 Preliminary phase Goal The goal of the activities in the preliminary phase is to refine the results of the conceptual with a clear positioning of their constituting system elements. During this phase the system requirements need to be developed which specify concrete and verifiable capabilities, behaviour and properties to meet customer needs. Additionally, the systems engineer should make trade-offs between performance, risk and costs of the product or project based on the output of the conceptual phase. Sources The inputs for this phase are the results of the conceptual phase. Additional discussions with customers or users may be needed to meet the goals of this phase. Means Important in this phase are risk assessments. (Bol, D. 2002) describes a useful scaling model to assess the maturity of the technologies that are applied in system elements. This technology maturity can be scaled as follows: Possible in theory; Proven by analysis or computer simulation; Working as a laboratory experiment; Already applied in a similar, but different situation; Applied in (almost) similar situation. Additional means that can be used are Failure Mode and Effect Analysis (FMEA) methods, Quality Function Deployment (QFD) methods and others. Also in this phase it is important to have regular discussions and reviews to align the viewpoints of all involved (especially the customer). Results The results of the activities in this preliminary phase should contain a recommendation with respect to system components and interfaces for the detailed 5

phase. These results should be based on the risk analysis and trade-offs between the concepts that where produced during the conceptual phase. This means that the system architecture is broken down into subsystems and that a (preliminary) function allocation is done. Before the activities in this phase can be concluded, formal reviews should be performed and passed with sufficient confidence to proceed to the next phase. Output At the end of the preliminary phase (at least) the following items should have been produced: Requirement specification document; Subsystem verification specifications; Configuration, system and documentation baselines. 2.1.3 Detailed and development phase Goal The goal of the activities in the detailed and development phase is to complete the (sub)system down to the (lowest) components, to a level ready for production and construction. This includes the implementation, verification and integration of all the system components. Sources During the of the system and its components, the teams can have questions about unclear requirements and non-existing or unfeasible requirements. The systems engineer should solve these uncertainties and if necessary, contact the customer to get the required information. Implementation issues can conflict with the constraints and can cause the development of the system or the components to come to a halt. It is possible that a trade-off with respect to (customer) requirements is necessary to deal with these implementation issues. The customer can still change his mind about some requirements and functionality. The organization should be able to cope with these issues in order to satisfy the customer. Means To cope with changing requirements from customers or even from within the organization or the teams, baselines can help to guide the process and to prevent adhoc solutions. Baselines, as described in section 2.3.2, that can support the detailed and development phase are: (Requirement) Specification baselines; Design baselines; Delivery baselines. All component risks should have been resolved after this phase. Possible means to resolve these risks are: Make or buy decisions on component level; Second sourcing of COTS components as a fall back solution for delivery and quality problems from manufacturers. Critical reviews should ensure that the meets the requirements. 6

Results At the end of this phase, the product should be ready for production. Besides a working and tested, this phase should also deliver documentation for industrialization. This means that all documents, source code, load modules, PCB layouts, production tests etc. needed for the production of the product are available for the production site. Also a production planning should have been made. Furthermore, the product should be ed for operational feasibility as described in, for instance, (Blanchard, B. and Fabricky, W. 1998). This means for: Reliability; Maintainability; Usability (human factors); Supportability (serviceability); Disposability; Affordability (life cycle cost). Output At the end of the detailed phase (at least) the following items should have been produced: Detailed functional, performance, interface and verification requirements; Design specification documentation; Design verification documentation; Phase-out and disposal plan; Operation and Maintenance (O&M) plan. 2.1.4 Production and construction phase Goal The goal of the activities in the production and construction phase is to verify that the and the end product satisfies the specifications and that the system is ready for mass-production and delivery to the customer. Furthermore, if larger and more complex systems are being developed, in this phase the complete system is integrated and assembled for the first time. Final system tests should be performed to verify compliance with the user requirements. Sources In a perfect world, the systems engineer would not have anything to do in this phase. In practice however, problems arise in several stages of this phase. When the is being produced, problems can arise for example from missing or late components, (COTS) components that do not meet the requirements, choices that are impossible or difficult to produce etc. Furthermore, additional problems with respect to the user requirements may arise; the system may fail to comply to some requirements and the systems engineer should make an analysis to assess the impact of these problems and find solutions. Means It is important that the production of the product is planned well and that the planning is agreed upon with the production site. Part of this planning should also consist of the delivery of the subsystems and components needed for assembly of the product. To cope with problems during the production and construction phase of the product, it is recommended that the company plans for (partial) res of the product. To collect, keep track of, and adequately handle production and test problems, the company can 7

use trouble/problem report procedures and associated databases. For the verification during the production phase it is recommended that there will be a complete set of use cases for system integration tests. Furthermore, walk-through of the production process and regular contacts about the production progress can help monitoring progress and identify possible problems in an early stage. Results The activities at the end of this phase should result in a working and producible system. Furthermore, the system documentation should be finalized and reviews should be held to verify that the system has passed all tests. Output: At the end of the production and construction phase (at least) the following items should have been produced: Final product; User guides; Manuals; Training material; Completed system specification; Production test reports. Also the documentation can be finalized during this phase, especially when a concurrent approach has been used. 2.1.5 Product use, support and maintenance phase Goal The goal of the activities in the product use, support and maintenance phase is to create a support organization and secure the possible need for the involvement of systems engineers and teams. In this phase, the product is in use and problems can arise. The support organization should deal with the problems from the customer or the user in an efficient way. This can include product updates for bug fixes and regular scheduled maintenance of the system. Sources During normal operation of the product or system, the customers and users of the system can encounter problems due to errors in the implementation or specification that were not discovered during the. If this happens, the customer will complain and the support organization should deal with these complaints. It can happen that product updates or changes are driven from within the company because of new constrains (for example lower production costs). These issues must be addressed if possible. However, every product or system update introduces new risks. It must always be kept in mind that the customer may not want or have asked for these product or system updates and a thorough risk assessment should be made before the customer is bothered with a product update that he or she did not ask for. Means During the specification and phases of the system, the systems engineers should have included reliability, maintainability, usability and supportability in the. To cope with the reported errors or problems from the customer, the organization can implement change requests (CR) and trouble report (TR) handling to keep track of the re- 8

ported issues from the customer. Also in this phase, the previously ed operation and maintenance plans should be executed. Results The result of the activities in this phase should aim at customer satisfaction. Fast and adequate solutions to problems will make the customer happy and will increase possibilities for new orders in the future. Careless handling of these problems may cause the customer to refrain from buying future products. Output The output of this phase may consist of product updates including updated documentation, new load modules, improved (sub)systems or system components that will be delivered to the customer. 2.1.6 Phase-out and disposal phase Goal After the product or system has completed its useful life time, it should be disposed of. The goal of the activities in this phase is to dispose and get rid of the superfluous product or system components in an orderly fashion. This applies also to serviced parts of the system that have been replaced. A disposal plan is already specified during earlier systems engineering work as an integral part of the system, so that this plan can be executed when this phase of the life cycle is reached. Sources Governments may pose requirements and regulations regarding the disposal of electronic and chemical products or components. Environmental laws and regulations can prescribe the way this should be done. Also the customer can request a proper disposal plan as part of the user requirements. Means A product or system decomposition can be made to categorize the recycling or demanufacturing of a product (see (Blanchard, B. and Fabricky, W. 1998)) in the following way: Reuse of the complete product; Remanufacturing or rebuilding (parts of) the system for new or similar products; Recovery of materials or reusable components from the product. If the product or parts of the product do not fall into one of these categories, then total destruction (annihilation) of the complete product can be considered. The company can redirect the responsibility for the disposal of the product by outsourcing it to other companies. Results The result of the activities in this phase is that the company shows that it takes responsibility for the proper disposal of its products and that by doing so minimizes the impact on the environment. Output There is no output associated with this phase, since all documentation and planning is done during earlier phases. 9

2.2 The systems engineering activities To let the system life cycle move smoothly, the systems engineer has several activities and tasks to complete. This section lists a number of these activities. It is not meant to be an exhaustive description of all possible tasks that can be defined, but is merely intended as an overview. During the execution of these activities, the systems engineer should produce a number of documents. This section describes the activities based on the documents that must be produced. It is obvious that all documentation produced should be carefully reviewed and approved by the customers of that document before the tasks are finished. Note that the activities do not necessarily specify roles within the company. Each activity can (and probably should) be subdivided into tasks. Different people from different disciplines can then be assigned to the different tasks and perform different roles. For example, functional specification and functional can be done by different people. Furthermore, it is assumed in this document that the, integration and verification is done by and verification engineers and that the systems engineer is only responsible for the outcome. Every activity is associated with a set of entry and exit criteria. These criteria must be met before an activity can start or before that activity is finished. It is good practice to make a checklist for these criteria and to make this part of the systems engineering process. Furthermore, all deliverables for an activity should have been reviewed and approved by all the customers of subsequent activities. It is out of scope for this document to identify these customers for each activity in detail; they are described in numerous sources on systems engineering. In general, the activities described here should be included in a development process to ensure that all activities are executed. This process can then also be used to indicate dependencies between the different activities in the development of the system and can aid the overall planning. All of these activities are, in principle, ongoing throughout the development. Only the level of effort changes over the system life cycle. In (Hatley, D., Hruschka, P. and Pirbhai, I. 2000), more can be found on concurrent development principles. 2.2.1 System analysis Purpose The purpose of the system analysis activities is to collect and define the needs of the customer. This activity can be seen as the pre-study activity. The output of this activity should be targeted towards (other) systems engineers and should be the base for further systems engineering activities. Tasks To structure the system analysis activities, several tasks can be identified: Identify all the customers and collect their needs with respect to the system; Evaluate the customers needs by establishing why they are needs and resolve any conflicts, inconsistencies, omissions or other issues arising from them; Make a cost / benefit analysis. Entry criteria The initial ideas for a product including its functions must be present to start the system analysis activity. 10

Exit criteria The exit criterium for this activity is, among others, that an approved list with functions and implementation items has been created. Furthermore, requirement traceability should have been started for referencing during the rest of the project. The result of the system analysis activity can be collected in a Systems Engineering Management Plan (SEMP) (see for example (Blanchard, B. and Fabricky, W. 1998) and (INCOSE 2004) for more details on a SEMP). 2.2.2 Functional analysis Purpose The purpose of the functional analysis activities is to investigate and set requirements for critical parts of the system, more specifically, on architecture, lead-time critical hardware and lead-time critical components. The output of this activity should be targeted towards systems engineers and ers and should be the base for further system development. Tasks The tasks that can be associated with this activity are: Evaluate the top level required capabilities and constraints with regard to possible system architectures that might satisfy them; Perform analyses, trade-off studies and prototype evaluations as needed to determine the architecture that best meets the top level requirements; Make functional decomposition and function allocation into system components. Create the functional specifications and interface descriptions; Establish the overall system integration and test strategy and write top-level verification specifications based on use cases. Entry criteria To start this activity, an approved list with functions and implementation items should be available. Exit criteria Top level functions and user requirements must have been allocated to different systems. 2.2.3 Requirements analysis Purpose The purpose of this activity is to set the boundaries for the. The systems engineer must make sure that all the requirements can be implemented and tested. The output of this activity should be targeted towards and verification engineers and should be the base for and verification of the system. Tasks Tasks associated with this activity are: Complete the top-level architecture; Enhance, derive and detail the requirements and allocate them to the major system components; Develop the requirements and architectures for all the system components; 11

Prepare integration, verification and test plans; Write the requirements specification, constraints and rules for ; Identify open issues, assumptions and pre-conditions; Create baselines and requirement traceability information. Writing good requirements is important and literature about how to write good information is widely available. A practical way to check the quality of the requirements is by using the acronym "SMART". which stands for Specific, Measurable, Achievable, Realistic and Traceable. Good requirement should contain all aspect of these five characteristics. The correct and pre-defined use of the words "shall", "should" and "may" shall be considered. Good practice is to use references to other system documentation instead of writing them down again. This will prevent the repeating of requirement text and thus possible inconsistencies between multiple documents. Requirements can and should also be broken down in specific areas to indicate all the aspects of a specific function. A possible (and useful) breakdown can be the following categories: Functional; Performance; Capacity; Compatibility (interface); Operation and maintenance; Other. Furthermore, a requirement should have a set of attributes describing the complete requirement. Depending on the organization, customer needs or project structure the number of these attributes can vary. Attributes that should at least be present for each requirement are: Requirement text; A unique number for each requirement to ensure traceability; The source of the requirement; Allocation to subsystems or components. Optional attributes that can be included are: Increment allocation in incremental projects; Requirement status information, for example: draft, approved, rejected. Entry criteria To enter this activity, the systems engineer should have the functional specifications and interface descriptions from the functional analysis at his disposal. Exit criteria The end of this activity is marked with the delivery of an approved requirements specification document. 2.2.4 Architecture synthesis Purpose The purpose of this activity is to finalize the function specification and on subsystem and component level. The allocation from the requirements analysis is broken down for and an allocation of requirements towards use cases is made. The output of this activity should be targeted towards and verification engineers and should be the base for and verification of the system. 12

Tasks The systems engineering tasks during these activities are: Write functional specifications, requirements specifications and rules for the appropriate levels of subsystem and component ; Write detailed functional descriptions for each function of the system; Write top level verification specifications based on use cases. Apart from the aforementioned tasks, the systems engineer has a support responsibility towards the and verification engineers. Because this document focuses on systems engineering activities, the roles of the and verification engineer are not included here. However, since the systems engineer has the technical responsibility for the project, the activities include the support of and verification and review of the associated documents. This is probably the most important role of the systems engineer during the execution phases of the system life cycle (see sections 2.1.3 and 2.1.4). The support tasks of the systems engineer consist (among others) of: Work with and verification engineers to coordinate their efforts, and assist them in interpreting the system requirements and in evaluating their ; Participate in the reviews of (component) specifications and descriptions; Ensure that all requirements are met; Check requirements traceability against source documents. Entry criteria This activity should be entered when the requirements specification is in the approved state and when the functional analysis has been completed. However, in practice, may already start before all the requirements are in place. In that case, there is a risk that the teams may implement functionality that is not according to the user needs. This risk must be identified and assessed. Exit criteria This activity can be concluded when the functional, requirements and verification specifications are in an approved state. Furthermore, the and verification of the product has finished and no support from the systems engineer is needed any more. 2.2.5 Requirements verification Purpose The purpose of this activity is to verify the requirements. The output of this activity should be targeted towards systems engineers performing the functional verification activities. Tasks The systems engineering tasks for this activity include the writing of requirements allocation and verification documentation. This document should state all requirements, where they are implemented and where they are verified. The documentation can be made for different levels of the system: component level, subsystem level and system level, according to the allocation that was made during the functional analysis. A requirement management tool may be used here (see section 2.3). Entry criteria This activity is entered when the architecture synthesis activities have been concluded. 13

Exit criteria The systems engineer has the technical responsibility for the and should therefore produce statements of compliance and verification to the subsystem and component requirements of the product. 2.2.6 Functional verification Purpose The purpose of this activity is twofold; on the one hand the functional integration and verification document is written and on the other hand the functionality of the system is verified. The output of these activities should be targeted towards system verification. Tasks For the functional verification activity the following tasks can be identified: Write functional verification specifications; Check and review integration and verification reports. Entry criteria To enter this activity, the functions to be verified must be implemented. This activity can be entered at different moments in the depending on the availability of the implemented functions. Exit criteria This activity can be concluded when all allocated requirements to a function are verified or when approved exemptions to the failure of specific requirements are available. 2.2.7 System verification Purpose As for the functional verification, this activity is also twofold; on the one hand the system verification documentation must be written and on the other hand, the system verification must be performed. The output of this activities should be targeted towards the customer. Tasks The tasks associated with this activity are: Integration plan; Top-level system tests and verification specifications; Complete set of testable use cases; System verification report; System statements of compliance and verification; Regression test plan; Check and review system verification reports. Entry criteria This activity can only be entered when all functionality is implemented and delivered to the system verification teams. 14

Exit criteria This activity can be completed when a sign-off of the product is done in collaboration with the customer. Only when the customer is completely satisfied with the delivered system, this activity can be concluded. Nevertheless, it must be kept in mind that when product updates, maintenance, or other agreements with the customer are made, this activity can be reopened. When new or updated functionality is added to the system, regression tests should ensure the overall system performance. 2.3 Systems engineering methods and tools Systems engineering methods and tools are often integrated in specific processes that are tailored to the way of working in the organization. A method can be considered as a pre-defined and organized collection of techniques and a set of rules which state by whom, in what order, and in what way the techniques are used to achieve or maintain some objectives. Tools are the physical entities that enables the methods to be executed. The combination of methods and tools are the aids that a systems engineer can deploy to implement a systems engineering process. This combination of methods and tools can be (and often is) seen as a subprocess within the systems engineering process. 2.3.1 Change control Change request and problem report handling are part of a configuration management process. As the project moves along, customers may change their mind about certain requirements or user needs. These changes can come from within or outside the development organization. Furthermore, during verification and integration, but also after delivery to the customers, problems may arise that cause the product to function improperly. All these issues should be tracked to ensure proper handling towards the customer. Change requests When a customer wants to change something to the initial requirements, a company might want to implement and include this change directly into the product. While this ad-hoc way might work for small and simple products or projects, for larger projects this is not the preferred way. It is better to collect a number of changes and then implement a set of these changes in a new (intermediate) release of the product. These sets can be included in work packages which in turn, could be planned using baselines. A change control board should be responsible for updating and maintaining these baselines. This control board should also prioritize the changes with respect to necessity. Some changes may not be implemented at all because they are merely nice-to-have features and might cause unacceptable delay to the project. It is good practice to have templates for issuing change requests. The templates ensure a consistent formulation of the requested change and make sure that all relevant information is available. Furthermore, the change requests can then be stored more easily in a database. Each change request should be carefully examined with respect to its need, impact, feasibility and implementation before it can be included in a work package. After implementing the changes, regression tests of the whole system should be done to ensure that the whole systems still complies to all requirements. Problem reports During the, verification and use of the product, problems may arise that were not discovered earlier. These problems may be caused by wrong or faulty require- 15

ments, errors or incomplete integration and verification. Although reviews are held throughout the project, problems are inevitable. As with changes, problems should in general not be solved in an ad-hoc way. The handling of these problems can be the same as for change requests and should be collected in sets of problems depending on the importance and impact of the problems. After solving and implementing the problems, regression tests of the whole system should be done to ensure that the whole system still complies with all requirements. 2.3.2 Baselines Because of the large number of documents and product releases that can and will be produced during the systems engineering process, it is important to keep track of all these documents and releases in an orderly fashion. Baselines can help to keep track of the different revisions of the documentation and product releases. A baseline is an approved unit of configuration that can be individually managed and versioned. In literature, there is no single consistent definition of the word baseline, however, the creation and maintenance of baselines is part of a configuration management process. During the development of the system, changes to requirements may be necessary and this can result in a new revision of the documents. It is important to know which documents belong to which delivery of a product. Apart from tracking changes, baselines are also useful for project planning and give clear boundaries to everyone within and outside the project with respect to the work that (still) needs to be done. A number of baselines can be kept for different purposes. Possible and often used baselines are briefly described below. Configuration baseline A Configuration baseline is the configuration of a product or system established at a specific point in time, which captures both the structure and details of a configuration. It serves as reference for further activities. A configuration baseline is used to keep track of the different levels of build configurations, which can be software, hardware, or both. Furthermore, it is used to assemble all relevant components in readiness for a change or release, and to provide the basis for a configuration audit and regression after a change. A configuration management system should be able to save, protect and report on a configuration baseline, its contents and documentation. A configuration baseline may be created for any or all of the following reasons: As a sound basis for future work; As a record of what configuration items were affected by a request for changed (RFC) and what items were actually changed; As a point you can fall back to if things go wrong. System baselines This baseline may be considered to be the final functional requirements developed for the system. By establishing and maintaining formal system baselines, project team members will not be able to add/delete requirements without the full team fully considering the ramifications. Since requirements can (and often will) change, it is not very convenient to update every single change and create a new document. To deal with this, a set of changed requirements can be collected and included in a planned update or new revision of the requirement specification. The system baseline keeps track of these different revisions of the documents along with a list of changed requirements per revision. 16

Documentation baselines All the documents that are written in the project should be baselined so that a consistent set of documentation can be retrieved for each delivered product. This baseline tracks the documents and their revisions including all the changes per document. Design baselines During of the product, the documentation may be updated and new or improved tools may be used. A baseline can be used to provide the ability to change or to rebuild a specific version at a later date including the associated documentation for that version. Delivery baselines To keep track of the different releases of the system with its subsystems and components, a delivery baseline can be used. This is especially useful with incremental s, to keep track of the delivered functionality and to plan for future updates or increments. 2.3.3 Requirements management During the systems engineering activities lots of requirements are collected. In the previous sections, much has already been said about requirements and how to deal with them. Requirements management is the process that manages all these requirements, both technical and nontechnical, in a structured way. Part of the management of requirements is to document requirements changes and maintain bidirectional traceability between source requirements and all product and product-component requirements. A good and complete process description for requirements management can be found in (CMMI 2002). The main issues involved in requirements management are: Obtain an understanding of requirements; Obtain commitment to requirements; Manage requirement changes; Maintain bidirectional traceability of requirements; Identify inconsistencies between project work and requirements. Change control and baselining as mentioned in the previous sections, are good practices to manage these issues. At present, several tools are available for requirements management. To integrate these tools into the requirement management process, (Jones, D. et al. 1997) have written a good overview of available tools and how to integrate them into a systems engineering process. These tools can use a database-like structure to store all requirements. This structure makes it convenient to store and maintain large amounts of requirements and to ensure good traceability of the requirements. On the (CMMI 2002) webpage, requirements traceability is divided into two categories: Vertical traceability identifies the origin of items (e.g., customer needs) and follows these same items as they travel through the hierarchy of the Work Breakdown Structure to the project teams and eventually to the customer. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source; 17