Yet Another Process Model

Is RePoSyD just a different model or the answer to all questions? Probably not,since the answer to all questions is “42”. But if you are wondering why “42”, “The Hitchhiker's Guide to the Galaxy e” by Douglas Adams is recommended as a lecture.

RePoSyD is a procedure model, an information model, and an idea how model-based systems engineering or systems engineering based on an information model can be implemented.

From my experience, Systems Engineering has always been model-based. For decades, many forms of representation and Models such as IDEFx, FFDB or SysML have been developed to represent the “System of Interest” in the form of a model. Today, as in the past, documents still serve as a means of transport for communication between the various stakeholders and form the basis for a contract between the client and the contractor, whether in paper or in electronic form.

For me, systems engineering should be understood as toolbox, which offers different methods and tools to allowing me better understand problems, to make necessary decisions with the help of valid information at the right time and to realize a balanced solution in the end.

• “First of all, we need to define the system boundaries, or rather the use cases?”
• “No, we need to conduct a stakeholder analysis first.”

I think everyone has had a similar discussion before when it comes to defining what would be the first step in the development process.

Companies tend to define their standard systems engineering process as part of the company's business process model. Great effort has been made to detail everything and projects must follow the details liad down in process descriptions and work instructions. A set KPIs allows the management to determine how effective the process is executed in comparison between the projects.

Before we start a lengthy discussion regarding the pros and cons, I would like to answer both questions with a quote from the IEEE-1220:

The requirements of this standard should be selectively applied for each specific system-development project…. IEEE-1220 Overview - Scope

…or with other words: Systems engineering should be seen more as a toolbox and less as a process. And what needs to be done first, simply depends on the type of system development project you are dealing with.

Considering the systems engineering process in detail, the above process elements are all correct and important. However, it is not uncommon to discuss details that are not always effective at the beginning of a project. Why not use a process model that can be used to explain Systems Engineering in the first step with the help of six process elements.

RePoSyD uses the IEEE-1220 “Standard for Application and Management of the Systems Engineering Process” as a guideline for defining it's process modell and subsequently the required information. The figure illstrates the process elements and the arrows indicate that this is a highly iterative process.

The purpose of the Requirements Analysis is to understand what the project is really about and consequently knowing what you don't know. The analysis is divided into sub-activities for

• defining the system context and system boundaries;
• the identification of user needs based on use cases and and functions on the operational level;
• identifying risks related to cost, schedule and performance;
• elicitation of requirements and conflicts resulting from customer requirements, enterprise requirements and external constraints.

The result of the Requirement Analysis is documented in the Requirement Baseline which will guide subsequent activities of the Systems Engineering Process.

The functional analysis is the definition of the top-level functions of the system from the user's point of view. It is not about what the system does, but rather what the user will use the system for and how. During the refinement process

• the function, interface and performance requirements collected during the requirements analysis are transformed into a consistent description of the system functions;
• the relevant features of these functions are identified; and
• the required functional interfaces are defined

The synthesis translates the functional architecture into

• a design architecture and its decomposition into system elements;
• the external and internal physical interfaces; and
• design constraints.

The result is a balanced Design Solution with respect to cost-effectiveness and maximum functionality based on the specified performance in the Requirement Baseline.

The verification should ensure that all requirements:

• are traceable to the functions, systems and components of the product;
• each requirement is provided with a verification method and acceptance criteria, and
• the system elements meet the requirements.