A SYSTEM DESIGN PROCESS
TAILORED FOR REVERSE
ENGINEERING AND REENGINEERING
Tae-Hun Yoon
Department of Systems Engineering, Ajou University, San 5, Woncheon-dong, Teontong-gu, Suwon-si, 443-749, Korea
minus044@lycos.co.kr
Young-Won Park
Department of Systems Engineering, Ajou University, San 5, Woncheon-dong, Teontong-gu, Suwon-si, 443-749, Korea
ywpark@ajou.ac.kr
Abstract: This paper discusses a system design process using a reverse engineering. The Reverse Engineering Approach, if possible, is a cost-effective and easy approach to be used in a system design. All industries use this approach consciously or unconsciously to reduce system development risks. It can be a part of formal process, simple requirement reuse, or adoption of industry standards. The reverse engineering approach can be considered as an effective system design method in immature system engineering environments. This paper proposes a system design process using reverse engineering which can be tailored for large complex system development projects. The proposed process composed of two stages to produce system specification generation. The reverse engineering stage is performed to define functional and physical architecture of legacy system used as reference model when they are not available. The reengineering stage takes outputs of the reverse engineering stage to define the rest of logical and physical solutions.
Keywords: Systems Engineering; Reverse Engineering; System Design Process; Requirements Reuse; Specification Development; System Architecture.
1. Introduction
1.1.Objective & Scope
The purpose of this paper is to propose a system design process using reverse engineering approach. The proposed system design process is refined through the problems and lessons learned from a case study. The reverse engineering approach is a common method for requirement reuse or specification analysis. The reverse engineering approach plays an important role in helping to understand a target system and to develop alternatives, particularly for immature systems engineering environments where does not support IPPT activities. In spite of this situation, there are not many researches and case studies.
This paper is based on case study. The case is about systems requirements database development project for maglev system. Computer-aided systems engineering tool (SW) is used to develop the database in the project. The project considers all systems that are related to maglev system operation and support. The main role of system engineering is to perform requirements definition and solution definition in this project. This paper focuses on standard analysis and case study in order to define the system design process tailored for reverse engineering approach.
1.2.Approach
This study is performed through standard analysis and case study. Analyzing systems engineering standard aims to define forward system design process. This enables necessary or essential activities to be defined, and it helps simplify system design process. The result of standard analysis is applied to the project.
Fig. 1 Approach
2. System Design Process Standard
2.1.Systems Engineering Standards
Before defining the reverse engineering process, it is required to define a forward engineering process. There are system engineering standards such as EIA-632, ISO/IEC 15288, IEEE 1220 and so on. Comparison analyses among these standards have been studied in many literatures. Referring to joint technique committee of international standardization organization, EIA-632 covers well from being conceptualized until operations in comparison of system life with other standards. It deals with high level practices. Therefore, the project chose EIA-632 as system design process standard.
Fig. 2 Scope of SE Standards
Most of system engineering process defines ‘What to do’. EIA-632 also defines tasks which are required for doing systems engineering. The tasks are called ‘Requirements’ in this standard. And EIA-632 describes the relationship among ‘Requirements’. Because of this descriptive way, it is more difficult to identify a flow among tasks than other standards. <Fig.3> shows the relationship among ‘Requirements’ conceptually.
Each ‘Requirement’ in system design process of EIA-632 is merged in terms of similarity and repetition of representative tasks, and deleted the part that is difficult to apply. Refined system design process aims to implement under immature environment of systems engineering.
As shown in <Fig.3>, the system design process of EIA-632 consists of ‘Requirements Definition Process’ and ‘Solutions Definition Process’. It takes into account tasks of ‘Requirements Validation Process’ and ‘System Analysis Process’. But this study mainly focuses on system design process tailored for reverse engineering, and ‘System Analysis Process’ is less considered.
2.2.Requirements Definition Process
‘Requirements Definition Process’ of EIA-632 consists of ‘Requirement.14 (acquirer requirements)’, ‘Requirement.15 (other stakeholder requirements)’ and ‘Requirement.16 (system technical requirements)’. Each requirement is needed to perform ‘Requirements Validation Process’. It includes tasks for ‘Requirement.25, 26, 27 and 28’.
Fig. 4 Requirements Definition Process for EIA-632
As seen in <Fig.4>, necessary tasks for ‘Requirements’ of ‘Requirements Definition Process’ are selected and it is simplified by merging repetitive tasks for ‘Requirements Validation Process’. ‘Requirements Definition Process’ described in <Fig.5> is the result of simplifying and merging. It is modified from the process of “A study on system requirements analysis process by model- based system engineering”.
‘Requirement.25, 26, 27 and 28’ of ‘Requirements Validation Process’ include similar tasks repeatedly performed in ‘Requirements Definition Process’. The repeated tasks of ‘Requirement.25 (Requirements Statements Validation)’ are divided into ‘Requirement statement validation’ and ‘Requirements set validation’. The similar tasks of ‘Requirement.26, 27 and 28’ are classified as ‘Hierarchical structuralization of requirements’ and ‘Categorization of requirements’. This simplification still possesses the purpose of core tasks in each ‘Requirements’ of ‘Requirements Validation Process’ and helps ‘Requirements Definition Process’ to be implemented efficiently.
‘Refined Requirements Definition Process’ seen in <Fig.5> starts from collecting requirements of acquirer and stakeholder. It uses template to collect requirements and validate requirement statement. This task includes ‘Requirements.25 (Requirements Statements Validation)’. The template is a kind of checklist helping requirements developer to validate 11 attributes of requirements. ‘Requirements.25’ of EIA-632 defines the attributes such as clarity, correctness, feasibility and etc. This means, the effort for ‘Requirements Validation Process’ will be minimized if the requirements are described righty in the initial time. These tasks can be easily performed by integrated template of requirements collecting and validation.
The refined initial stakeholder requirements divided into functional and non-functional requirements are defined as initial system technical requirements. The refined initial system technical requirements are validated in terms of hierarchical structuralization, categorization and set validation. ‘Hierarchical structuralization of requirements’ is a major task of ‘Requirement.26, 27 and 28’. It is performed to ensure vertical traceability of requirements. ‘Categorization of requirements’ is for validating the requirements omission. It ensures where or not all requirements satisfy every category of standards such as MIL-STD-961E. ‘Requirements set validation’ is for validating repetition and contradiction among requirements. The validated system technical requirements are defined after performing all these validation processes including review by stakeholder and domain specialist group.
Fig. 6 Solution Definition Process for EIA-632
2.3.Solution Definition Process
‘Solution Definition Process’ is the one for acquiring specified requirements based on system technical requirements after ‘Requirements Definition Process’. ‘Solution Definition Process’ is also refined by analyzing and merging the core tasks of standard to implement efficiently. Blocks highlighted in <Fig.6> show the core tasks. <Fig.7> shows simplified and refined ‘Solution Definition Process’. ‘Solution Definition Process’ consists of ‘Logical Solutions Representation’ and ‘Physical Solutions Representation’.
Fig. 7 Refined Solution Definition Process
Above defined logical solutions and non-assigned derived technical requirements are assigned to conceptual object in regard to physical components in the ‘Physical Solution Representation’. Defining conceptual objects is performed simultaneously with development of alternative physical solutions at this point. Hence, the output of logical solutions is assigned to alternative physical solutions. Derived requirements are identified again by assigning logical solution representation to physical solution. A result of ‘Physical Solution Representation’ is verified in terms of hierarchical structure, traceability and data flow among components.
When the design solution has been defined by defined logical solutions and physical solutions, and it can be verified by simulation, demonstration, test and so on. By verification, traceability between requirements and solutions can be investigated, and omission and contradiction of requirements can be evaluated and revised. The validated solution is documented according to standard of organization.
3. A Problem of System Design Process Application
3.1.Problems
The refined system design process consists of minimal tasks, which are refined from the standard analysis and the case study. However, there are limitations for applying simplified forward system design process. They are mostly caused by systems engineering environment.
First of all, most of problems are caused by time limitation, which systems engineering is started in program. Many systems engineering projects are often demonstration projects in immature systems engineering environments. Systems engineering have to develop conceptual design solutions of high-level system, but it is not started at proper time. Designing system synchronizes designing subsystem. It limits system engineering roles to project management or configuration management.
Secondly, the integrated product development team that plays an important role in the system engineering is defective, and the organization of system engineering team cannot have multidisciplinary characteristics. Therefore, it is difficult to develop various requirements considering the target system’s whole life cycle and specific parts. Thus, it takes longer time to analyze and review issues.
Thirdly, the supports of tools and methods are insufficient. Many computer-aided systems engineering tool to support systems engineering have been developing. However, its support is limited in project because many decision makers don’t understand usefulness of these computer-aided systems engineering tools and methods.
engineering. Perhaps it is because of difficulties of proving usefulness of system engineering application at an initial stage. Although time and cost is limited, it is able to achieve the right results in order to improve the systems engineering environment and grow the maturity. Reverse engineering approach is one of the best ways to enhance the maturity of systems engineering.
3.2.Concept of Reverse Engineering
The reverse engineering approach is often used for reducing the risk that forward engineering approach has and satisfying time and resource constraints. It is common method for using in not only software engineering field but also mechanical and electrical engineering field. The reverse engineering approach can be considered methodology to reduce risk and satisfy constraints in systems engineering.
Fig. 8 Concept of Reverse Engineering
The reverse engineering approach is effective when there is a legacy system. Its usefulness was proposed by Andrew P. sage. Concept of reverse engineering and reengineering process Andrew P. sage proposed is shown in <Fig.4>. An important goal of reverse engineering is to understand existing system specifications. Based on this, it can develop new system specifications. It is possible to satisfy the new system requirements in the reengineering process.
The background of reengineering development methodology by reverse engineering is to effectively accomplish the major goals such as time, resources, efficiency and risk constraints better than forward engineering. Moreover, as the technical environment has been changed rapidly, development environment like s time, resource and technology is getting competitive. Sage mentioned that it is unavoidable to develop and improve the system by reverse engineering and reengineering in order to effectively achieve the system requirements under the competitive development environment.
4. Reverse Engineering Application Case Study
4.1.Overview
Fig. 9 Reverse Engineering Process
The purpose of ‘Reverse Engineering Stage’ is to understand better about target system and find reusable requirements. Requirements for new system can be defined from legacy systems in ‘Requirements Definition Process’. Hence, system developers can focus new functions and performances of new system to be developed. Both requirements for existing system and new system are addressed in the ‘Requirement Definition Process’, and then ‘Solution Definition Process’ is performed using functional and physical hierarchical structure defined in ‘Reverse Engineering Stage’.
This aims to enhance understanding of target system when the domain specialists is absent in systems engineering team. In addition, it can develop large amount of requirements within a short time and invigorate brainstorming.
Fig. 10 Reverse Engineering stage
4.2.Reverse Engineering Stage
were added into identified functions. Finally, new functional hierarchical structure was defined using KJ or DSM method.
The reason why the hierarchical structure of components couldn’t be identified from initial source documents is from existing specifications. They do not adapt system engineering concept, and mostly have space-oriented physical hierarchical structure. Therefore, we firstly accomplished the functional hierarchical structure and carried out the physical hierarchical structure.
Hereby, the derived functional hierarchical structure was referred to establishing hierarchy of system technical requirements and logical solution in reengineering. The derived physical hierarchical structure was referred to developing physical solution alternatives in ‘Reengineering Stage’.
Furthermore, each element that composes a functional and a physical hierarchical structure can be reused as requirements in reengineering since it contains function, performance requirements and design solutions derived from existing system specifications.
The target system is the large and complex system(SoS), which includes vehicle system and operating and supporting system. The maglev system has subsystems such as vehicle system, signal system, communication system, power system, infrastructure system, station system, and vehicle station system. In the project, 88 requirements for high level system and 662 requirements for 5 subsystems have been derived by reverse engineering approach. The goal of using reverse engineering identified in this case study is to study existing system and develop the reusable requirements, generate references for logical solutions, and generate physical solution alternatives.
Table 1 statistic of requirements captured by reverse engineering
Requirement Category Requirement Number
system requirements 88
Vehicle subsystem requirements 251
Infrastructure subsystem requirements 142
Signal & communication subsystem requirements 112
Power subsystem requirements 157
4.3.Reengineering Process
The reengineering process follows abovementioned ‘Requirements Definition Process’ and ‘Solution Definition Process’, and is performed based on functional and physical hierarchical structure defined in ‘Reverse Engineering Stage’. 1~5 various levels of requirements exist in a Spec.A or Spec.B that is used as source documents in reverse engineering. These requirements are assigned to the hierarchical structure derived from ‘Reverse Engineering Stage’. However, when there are no requirements for system level or there are requirements that have to be changed by new system, it has to be redefined or abstracted according to ‘Requirements.25’. As a result, system technical requirements from the outcome of ‘Requirement Definition Process’ are redefined as system level requirements.
The ‘Solution Definition Process’ is performed based on functional and physical hierarchical structure defined in ‘Reverse Engineering Stage’. In the case of logical solution, it is performed according to definition of functional hierarchical structure, while physical solution is generated physical solution alternatives by physical hierarchical structure. This ‘Solution Definition Process’ is performed repeatedly until all system technical requirements are assigned appropriately.
5. System Design Process by Using Reverse Engineering
5.1.Lesson & Learned
An advantage of reverse engineering is in development of design solution quickly. All outcomes from reverse engineering and reengineering would be better managed by computer-aided systems engineering tool in order to improve this advantage. The requirements and functional and physical architecture built in reverse engineering have to be reusable in reengineering. It should be able to achieve the architecture for new system by modifying the established architecture.
It is difficult to get the requirements for system level since most source documents are composed of requirements for subsystem. Therefore, it needs to generate high level requirements by abstracting subsystem or components requirements in the reverse engineering process.
used in reengineering. To reflect sufficient requirements for new system in reengineering, it also needs ‘Requirements Definition Process’ of forward engineering for new system.
Fig. 11 Conceptual Relation of Architecture in Reverse Engineering & & Reengineering
6. Conclusions
This paper proposed the reverse engineering approach in order to carry out the system design solutions performed under the immature system engineering environment. The purposes of using reverse engineering in the system design process are to learn the existing system, develop the reusable requirements, generate reference data for logical solution and generate alternatives for physical solution.
It is explained what kind of relationship exists between these purposes and reengineering and forward engineering process through the process model of the case study. Also, architecture reusability using computer-aided systems engineering tool and connectivity of reverse engineering and reengineering are mentioned based on lessons and problems from case study.
A development of large and complex system should make the best use of advantages of systems engineering under environmental constraints of system development. It is expected to be a transition period approach to improve maturity of systems engineering. Furthermore, as a future work, it is needed to improve efficiency of system analysis in the system design process of reverse engineering.
References
[1] EIA-632-1998, Processes for Engineering a System, electronic Industries Alliance, January 1999. [2] James N. Martin, Systems Engineering Guide Book – a process for developing systems and products.
[3] Sheard, S. A. 1996. Twelve systems engineering roles. In Proceedings of the Sixth Annual International Symposium of the International Council on Systems Engineering (Boston, MA). Seattle: INCOSE.
[4] A. Terry bahill, , the systems Engineering started in the middle process : a consensus of systems engineers and project managers. [5] Joong-yoon Lee, 2003, Automatic train control system development through application of reverse and re systems engineering
process, ICASE 9-10.
[6] INCOSE 2006 systems engineering handbook - a guide for system life cycle processes and activities, Version 3. ed. Cecilia Haskins. [7] INCOSE 2000 systems engineering handbook - a guide for system life cycle processes and activities, Version 2. ed. Cecilia Haskins.
