1. Agreement processes

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.

2. Project processes

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.

3. Technical processes

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.

4. Evaluation processes

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 and 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.