Problem Domain Analysis

Jump to: navigation, search



The architecture can initially be expressed as a block diagram with very few details. For SW-only projects, the UML class diagrams can be used. For mixed projects, SysML block diagrams are more capable. The remainder of the document will use the term block diagram or architecture diagram.

Blocks responding dynamically shall also have either a State Machine Diagram or an Activity Diagram depicting the dynamics in the object.


The Dish

A block diagram with a brief description of each object and its responsibilities.

Diagrams depicting the dynamics of blocks with dynamic states.


Rich Picture



Preliminary Use Cases

Captured requirements from the Requirements Analysis


Inspect already captured requirements and extract candidates for objects and events.

Inspect the Rich Picture, the Storytelling and the Preliminary Use Cases as these often contain candidates for objects and events.

Assess the candidates and draw the necessary block diagrams and other diagrams depicting the dynamics in objects which respond dynamically.

The objects are candidates for being a block. A block, when representing parts of the environment, can be implemented at a later state in hardware, software or in a combination of the two.

Events express the dynamics of the system. The events will often be represented in the System Behaviour Analysis.



Architecture: Architecture is an asset that describes the system as a whole. An architecture defines the system structure comprising the components, their externally visible properties and their relationships among each other. An architecture diagram is a static view of the system.

Problem Domain: The part of the environment which the system-to-be should control or administer.

Usage Domain: The users and other systems that control or administer a problem domain.

Block: A block defines an object's interface and implementation. It specifies the object's internal representation and defines the operations which the object can perform. Software developers can easily see the analogue Class in this description. In SysML, the block is a specialised UML class.

Object: A run-time entity (HW or SW) which packages both data and the procedures operating on that data. However, it may also be something physical or artificial existing in the environment.

Event: An instantaneous occurrence which will influence one or more objects.

Domain Model: An object model of the domain which incorporates both behaviour and data. This will become the heart of the system-to-be.


One of the first tasks is to create a model of the environment. Not the entire environment, but of those parts needed in order to fulfil what the system-to-be is required to do. We will do this by analysing the Problem Domain.

Box with eyes.svg.png
From the point of view of the system-to-be, we need a representation of the environment in the system, often called an abstraction of the environment. Only the parts of the environment which make sense for the system-to-be should be represented. If, for example, the system-to-be is to control a heating system, outdoor and indoor temperatures are good representatives of the environment to be candidates in the system-to-be. Early in the process, the temperature is important to note. At the end of the Launch Phase, considerations about how to measure and represent the temperature will be done, possibly, leading to extra blocks and/or classes of which some may be HW and some may be SW.

In the early phases of the analysis, we often draw one or more block diagrams to gain an overview of the system-to-be.

A Block is a general term, and by the time of identifying it, no decisions, whether to be implemented as HW or SW, exist.

The figure element 'Block' represents the object in the environment which shall be abstracted into the system. [1]

The block represents objects in the environment where each object can be a very abstract interpretation of the physical world. For example, temperature can be represented as a block. At this point in the analysis, we do not know how to retrieve the temperature or how to represent it in the system. What is interesting here is that a representation of the temperature in the operating environment is needed.

We do not yet take much notice of how to realise this (probably a HW sensor, an analogue to digital interface, SW for interfacing and converting...), but will leave this until later in the process.

Finding candidates

Candidates can be found in the Storytelling, Preliminary Use Cases, System Definition, user needs and especially in the requirements captured up to the time of starting the architecture components.

An open-minded approach using brainstorm-like processes suggesting candidates to be represented in the system leaves the developers with a gross list to pick from when modelling the first block diagram.

It is important to be open-minded in the process of finding candidates. Do not judge the candidates while collecting them from the sources. The judgement will be relevant later when composing the actual block diagram.

The result is a list or a table with candidates of which some may not survive in the final block diagram. Bear in mind that if you do not have enough candidates from the beginning, you may not have enough of them later in the development process.

After having produced a gross list of candidates to the block diagram, it can be helpful to also produce a list of candidates of important events in the environment on which the system-to-be has to react. This results in the first descriptions of the dynamics in the system.

Events are instantaneous occurrences on which the system-to-be reacts. Operators' usage of the system is a good candidate to reveal events. If the system-to-be has to interact with other systems, this interaction is also a good candidate. Of course, obvious events which occur in the environment also need to be considered. Finally, it may be necessary to express pseudo-events. A pseudo-event is an event that is derived indirectly from something happening in the environment, e.g. the temperature is rising above a certain predefined level.

As to block candidates, the same approach of brainstorming a list of event candidates is a good approach to generate a comprehensive list.

The first block diagram is called a Domain Model. It represents what is needed from the environment in order to control, monitor or administer it. The Domain Model will be the heart of the system-to-be. Having a solid Domain Model allows the developer to model and, possibly, later re-model the rest of the system-to-be without changing the base of the whole system.


After having gathered the candidate lists, the very first block diagram can be composed. First, assess each candidate to be a block. Assess each candidate by asking the following questions:

  • Is it possible to identify objects from the block?
  • Does the block contain unique information?
  • Does the block include more objects?
  • Is it possible to identify events that can change the blocks behaviour?
  • Will the block fit "logically" in between remaining blocks in the system?

If it is not possible to identify objects (remember that 'object' is very abstract here) of a block candidate, it is most certainly not the right candidate.

Selected candidates are modelled into a diagram. The blocks may be interconnected or, for the time being, left as a non-connected block. Again, remember that the block is an abstraction of the environment which should be used in the system-to-be to determine the system's action.

As for object candidates, the event candidates should be assessed.

  • Is the event instantaneous?
  • Can the event be divided into more parts?
  • Can it be identified when it occurs?

It is important that the event can be identified as instantaneous. If an event has a timespan, it might be necessary to divide the event into more parts, e.g. the beginning and the end of the event. On the other hand, if only the end of the timespan is interesting to the system, it should be chosen by renaming the event accordingly.

An event is always undividable. If we want to describe part-events, we should do so by selecting and naming the parts rather than the whole.

Finally, it is important that we can identify when the event occurs. If it is not possible to identify the exact time, try to see if another approach to the event may lead to an alternative event. As an example: If a customer should fill in an application form, the event FormFilled cannot be identified; we do not know when the customer really filled in the form. Another event like FormReceived might be a better choice, because we know when we received the form in the company.

Table preparation

In order to find the objects affected by the events, it can be very useful to compile a table with the objects as the column name and the events as the row name. Put an x in the cross section where you believe the event will affect the object.

For objects with "x"s, consider how each object will be affected. Will the object change state (where state here is information about two or more dynamically changeable states, and the object will react differently to the next event)? Should the stored information be updated (the state of the information is changed, but the object will have the same reaction to the next event)?

If the assessment results in the object having to react differently to the next event, draw a diagram illustrating the dynamics in the object. There are several diagrams available for illustrating the dynamics(e.g. a State Machine Diagram or an Activity Diagram). Select a diagram type which expresses the particular situation best.

Capture requirements

While working with blocks and events, requirements may emerge. To ensure that all requirements are captured, a Requirements Diagram from the Requirements Analysis is a useful feature. Already captured requirements can reveal candidates for objects and events.


Finally, note that the process of building the Domain Model is not a one-shot process. While analysing other parts, for instance, the Usage Domain or the System Dynamics, information emerges which should be kept in the Domain Model. Only after several iterations through all the analysis activities with no updates on the Domain Model, one can declare it to be solid and a good representation of the Problem Domain.

Software Only Projects

In SW-only projects, the block diagram can be substituted by a Class Diagram. The above recommendations and advice are still valid for classes.



An incomplete architecture diagram from early stages of the analysis.


[1] The OMG SysML official home page