The approach to the problem is primarily top-down. However some parts of the modeling will be done bottom-up. The approach is a rough guideline and not a solid plan. It will be dynamically adapted if we detect that there is a better way. It's NOT a waterfall approach. Even if the steps described below looks like a waterfall. It's an iterative approach. It's not necessary and not wanted to proceed only with the next step if the previous step is completed.

The model includes at least two abstraction levels throughout analysis and design, without technical solutions and with technical solutions

Describe the objectives of the system and the modelling

    • Model elements: Requirements stereotyped with <<objective>>


Determine the requirements

    • Break-down the requirements if necessary
    • Model at least two levels: User and system requirements
    • Model elements: SysML requirements and relationships

Describe the context of the system, i.e. it's actors

    • Model elements: Block stereotyped with <<system>>, actors with stereotypes for categorisation purposes, e.g. sensor, actuator

Find the services of the systems, i.e. the use cases

    • Model the relationship of the use cases the functional requirements
    • Model elements: Use cases and relationships
    • Model the use case control and object flows with all important variants and exceptions
    •  Model elements: activities with all their related elements

 Define the domain values and blocks

    • Types of blocks used in the use case object flows, units of the domain
    • Model elements: Blocks, value types, units, dimensions, relationships

Derive a system design

    • At least use two levels, emphasising technology independent and technology dependent perspectives as required by the problem statement.

Define the various interfaces among blocks.

    • Allocate requirements, use case control and objects flows to system blocks and item flows
    • Model elements: Blocks, composition, ports, connectors, item flows, roles

Describe system blocks behaviour

    • State machines and activity diagrams are used to define physical processes and system behaviour
    • Model elements: State machines, activity diagrams and related elements

Describe parametric model

    • Model elements: Constraint blocks, Parametric model