A systems engineering process is a process for applying systems engineering techniques to the development of all kinds of systems. Systems engineering processes are related to the stages in a system life cycle. The systems engineering process usually begins at an early stage of the system life cycle and at the very beginning of a project, but as stated by Bahill and Briggs (2001), systems engineering can also start at the middle. A variety of systems engineering processes have been proposed by different organizations. ...
Contents |
Several systems engineering methods and process guidelines have been developed since 1969. These methods describe all the activities and deliverables of a systems engineering project.
The first, Mil-Std-499 is a military standard of the U.S. Department of Defense and was used to create complex systems, for example, a nuclear submarine or missiles. The build up body of knowledge has become known as systems engineering. Since IEEE has developed 1220, the systems engineering standard has become commercial.
The early systems engineering methods, such as Mil-Std-499B (see figure 1), are focused on the verification and development life cycle functions, but the later methods cover almost the whole system life cycle. Systems engineering and software engineering have evolved as independent processes, but recent process guidelines and standards emphasize the need for integrating both these processes. (Boehm, 2005)
The meta-model in figure 2 shows a systems engineering method. The activities in the model can be somewhat different in a specific project. This is derived from several existing standards, marked in figure 1. ANSI/EIA 632 serves as the basis for this method, since many current systems engineering methods are based on this standard. Further, ISO/IEC 15288 and the INCOSE Systems Engineering Handbook, which are more recent, serve as source for this method. The final source is an older standard, MIL-STD-499B. The activities and concepts in the model are explained here. The model is separated in four main processes. The Agreement, Project, Technical and Evaluation processes. These will be explained in further detail below.
The first step in the systems engineering process is to establish an agreement with the customer, in order to build a new system. This order is set when the outcome of the feasibility study is positive: there is a need for a new system and there is no other system that can be used or it will be more cost effective to create a new system. When the outcome is negative, the project will end here. The input of the feasibility study is an acquisition phase and a problem definition. A well known way to acquire knowledge is the structured or unstructured interview. This technique and several other acquisition techniques can be used to define the needs of the customer, user and other stake holders.
After an agreement is made, the planning of the project will begin and this results in a project plan, which can be modified during the technical processes. In fact, the project processes are not sequential processes and go in parallel with the whole project, because at each moment a project needs planning, assessment and control. The design loop indicates that during the technical processes, after each step the project-management will assess whether changes have to be made in for example the schedule, which falls under project management. To ensure that a project will be successful the project management takes care that objectives are met within time, costs and a certain performance level, to help the project-management with this a work breakdown structure is made. Configuration management records the changes that are made in the design or requirements. This enables stakeholders to comment on a certain change proposal. But very important for a project success is risk control. Identifying risks and think about solutions in an early stage will save a lot of work and money in a later stage.
The technical processes cover the design, development and implementation phase of a system life cycle. In the earlier agreement phase top level (or customer) requirements have been established. This set of top level requirements are translated into software requirements which will define the functionalities of the software product. These software requirements can lead to a few alternate designs for the product. Each requirement is periodically examined for validity, consistency, desirability and attainability (see evaluation processes). With these examinations, or evaluations a decision can be made on the design. With the chosen design a requirements analysis will be performed and a functional design can be made. This functional design is a description of the product in the form of a model: the functional architecture. This model describes what the product does and of which items it consists of (allocation and synthesis). Thereafter, the product can actually be developed, integrated and implemented in the user environment.
Another loop in the model is the evaluation loop. During and after the creation of a software product the following questions have to be answered: Does the product do what it is intended to do? Are the requirements met? and as mentioned in the previous paragraph: Are the requirements valid and consistent? How is the requirements prioritization? This requires that the requirements are testable. For example a usability requirement, such as “the software product must be easy to use” can be tested through a heuristic evaluation. During the lifetime of a software product it will be continuously revised, updated and re-evaluated until the product is not used anymore and is disposed of.
To clarify the systems engineering process, figure 3 contains an example of such a process. It is a quite simple example and not every step of the process is mentioned. Furthermore, systems engineering might be more appropriate for a more complex system, but the example gives a slight idea of the practical use of systems engineering. The CEO of a software company encounters a problem: a (systems engineering) method has been made, but now he wants to share this method with his employees. To acquire all their needs, interviews with stake holders, including the CEO are performed. This results in a list with initial requirements. The feasibility study points out that there is no such system already available that would be appropriate and less expensive than creating a new framework to display the method. There are three possible solutions to the problem: A book that describes the method, a CD-ROM or some XML pages that can be used over an intranet. The Requirement that one has to be able to quickly search through the processes can be met by creating a CD-ROM or the XML pages. But during the project another requirement is added to the list: the content must be reusable. This rules out the CD-ROM, because with each update a new CD-ROM has to be given to the employees. This would also object the low-cost requirement. So, only the last alternative, the XML pages, is sufficient. Even when the requirements and solution are re-evaluated this alternative is the best design. Then, a functional architecture is made and the product is divided in sub functionalities. After creating the sub products, it is integrated and implemented in the organization. Because of all the evaluation and the involvement of the user the intranet is commonly used. The project is successful.
| Activity | Subactivity | Description |
|---|---|---|
| Agreement processes | Define needs | Through interviewing the users and other stakeholders of the product the user needs can be conducted. |
| State the problem | The problem (why do we need this product?) is described in the PROBLEM DEFINITION | |
| Project analysis | Research has to indicate if the project is feasible and in which degree beneficial. On basis of the FEASIBLITY REPORT the sponsor/steering committee/project manager decide whether or not to continue with the project. | |
| Project processes | Plan project | The project starts with creating a PROJECT PLAN that will be updated and revised through whole the technical processes phase. In fact the whole project processes phase will be continuously repeated. |
| Assess project | How is the project going? Are there any changes? These are questions of assessment. | |
| Control project | Control risks | System control includes technical management activities required to measure progress, evaluate and select alternatives, and document data and decisions. Control activities include risk management, configuration management and data management. These are closed concepts, because they are processes on their own and not in the scope of the high level systems engineering process. |
| Control data | ||
| Control configuration | ||
| Technical Processes Define Requirements |
Analyze missions and environments | Analyze the customer’s needs to identify the requirements |
| Identify functional requirements | Functional requirements define quantify (how many), qualify (how good), coverage (how far), time lines (when and how long), and availability (how often). | |
| Define performance and design constraint requirements | Design constraints define those factors that limit design flexibility. | |
| Model the system | The LIST OF REQUIREMENTS is the basis of the functions presented in the FUNCTIONAL ARCHITECTURE. This architecture can help to identify bottlenecks. It can be either a written document or a graphical representation of the functions of the system. | |
| Investigate alternatives | Investigate alternative designs and look which requirement is met by each design. | |
| Integrate the product | Bring the subsystems or functionalities | |
| Implement the product | The creation of the SOFTWARE PRODUCT is completed and can be implemented and delivered to the customer. | |
| Evaluation processes | Verification | After implementing the product it is important to verify and validate if the user needs are met and if the product fulfills the intended use. Several evaluation methods are available for this purpose. The outcomes are described in an EVALUATION report. But also during the technical processes evaluation will constantly take place, especially the evaluation of requirements. |
| Validation | ||
| Maintenance of the product | Together with possible complaints, the EVALUATION report is the basis for the maintaining process.
This is a closed concept and out of the scope of systems engineering. If adjustments to the product have been made, the product should be evaluated again. |
|
| Dispose of the product | When the product isn’t been used anymore the product is disposed.
This is a closed concept and out of the scope of systems engineering. |
| Concept | Definition |
|---|---|
| Top level/ Customer requirements | Identification of the user needs. Talking to customers and supplier’s is very useful for this matter (SIMILAR; Bahill & Dean, 2005). This will result in a general overview and initial requirements of the system. |
| Problem Definition | Description of the intended use of the system. The problem statement starts with a reason for change followed by vision and mission statements for the company (SIMILAR; Bahill, & Dean, 2005). |
| Feasibility Report | This contains benefits and costs of the software product that is to be made |
| Project Management/ Project Plan | Project management is the planning, organizing, directing and controlling of company resources to meet specific goals and objectives within time, within cost and at the desired performance level. This results in a project which is actually a collection of all documents created within the agreement processes and project processes and will change over time. ( ANSI/EIA 632; ISO/IEC 15288; SIMILAR; Bahill, & Dean, 2005) |
| Risk Management | Identification of risks and/or Opportunities. This results in a list of risks or opportunities and a plan how to deal with a certain risk or opportunity. |
| Data Management | Control of all documentation and activities of the systems engineering process. ( ANSI/EIA 632; Mil-Std-499B; ISO/IEC 15288; SIMILAR; Bahill, & Dean, 2005) |
| Configuration Management | Configuration management ensures that any changes in requirements, design or implementation are controlled. ( ANSI/EIA 632; Mil-Std-499B; ISO/IEC 15288; SIMILAR; Bahill, & Dean, 2005). Configuration management involves Configuration Identification, Control, Status Accounting, Audit and Planning. |
| Requirement List | Customer needs/requirements are translated into a set of requirements that define what the system must do and how well it must perform.
Requirements analysis must clarify and define functional requirements and design constraints. (Mil-Std-499B; US department of defense, 2001) |
| Requirement | A single requirement. It consists of a number, type, description and evaluation method that can be used to test the requirement. |
| Functional Architecture | Functions are analyzed by decomposing higher-level functions identified through requirements. (Mil-Std-499B; US department of defense, 2001) |
| Software Product | Definition of Systems Engineering according to INCOSE:
“Systems Engineering is an engineering discipline whose responsibility is creating and executing an interdisciplinary process to ensure that the customer’s and stake-holder's needs are satisfied throughout a system's entire life cycle.” (INCOSE SE handbook; Vasquez, 2003) The outcome of the Systems Engineering process is a SOFTWARE PRODUCT which satisfies the needs of the customer and stakeholders. |
| Evaluation | Each requirement must be verified and validated to determine whether the software product fulfils the requirements and if the final as-built software product fulfills its specific intended use. ( ANSI/EIA 632; Mil-Std-499B; ISO/IEC 15288) |
|
||||||||||||||||||||||||||