Activities and Descriptions

Content and scope


The core of The Integrated Method (TIMe) will be presented in the following. TIMe is centered around a number of descriptions which are developed by activities . These descriptions express domain knowledge, specifications in terms of external properties, system family designs in terms of structure and behaviour, implementation mappings and system instantiation. They are organised in three main areas of concern: the domain, the system family and the system instance areas.

It is assumed that the Languages and Notations Used to make descriptions and the Foundation of TIMe are known to the reader.


The content is organised as follows:
  1. Description overview which introduces the main descriptions and how they are organised.
  2. Activity overview which introduces the main activities and how they are organised.
  3. Description modules. Here we present the various descriptions as modules with associated operations. They are organised according to the three areas of concern:

    Domain: Domain models, Domain statement and Domain dictionary;

    Family: Application models, Framework models, Architecture models, System family statement, System family dictionary and Family implementations;

    Instance: instance models, instance implementations.

Description overview

The main descriptions

Figure 1: The main descriptions used in TIMe

Areas of concern

As can be seen from Figure 1, the descriptions are organised within three areas of concern: domain, system family and system instance. In each area there are formal models and there are other descriptions (dictionaries, statements and auxiliary). The formal core of the methodology is the models which are expressed using the well defined languages UML , MSC and SDL.


These descriptions are necessary and sufficient to achieve central goals of TIMe:
  1. to improve common understanding and communication among the people involved in all areas of concern;
  2. to achieve a controlled process towards quality results;
  3. to achieve flexibility in services and system designs;
  4. to minimise cost and lead times and to increase reuse.
The descriptions have been carefully selected. They are neither too few, nor too many. There is little redundancy, as they describe different aspects and complement each other in a complete, concise and readable documentation. TIMe keeps the amount of temporary (throw away) descriptions to a minimum, and emphasizes descriptions that end up as final documentation. This does not prevent us from identifying partial descriptions that are useful in their own right, such as specifications, and to issue them in separate documents when needed.

Textual explanations

Textual explanations may be attached to models as well as to other descriptions.


Domain descriptions are organised in:


Family descriptions are organised in:


Instance Descriptions are organised in:

Model organisation

As explained in Objects and properties, models have the facets illustrated in Figure 2. In general there are object models and property models. Seen together they define a context and a content. The context represents the entity being defined (e.g. a system type) as a "black" box and details its environment, while the content details its internal composition in terms of object structures and behaviour.

Figure 2: The facets of a type model

A specification covers those aspects of a model that are relevant for its external representation and use, while the design cover the internal composition and the internal properties.

The distinction between specifications and designs is not so important in domain models, while in system family models it is important. This has been illustrated for application, framework and architecture models in Figure 1.


A specification covers those aspects of a model that are relevant for its external representation and use. The context part is often sufficient as a specification, but if parts of the content are important it may be included in the specification. Specifications are associated with the abstractions they belong to.

Specifications are partial models

TIMe emphasises that specifications are not special models, but integral parts of type models. The reason is that we want to minimise the amount of descriptions that are thrown away. In stead we want to make use of specifications throughout the lifetime of a model:
  1. first to express the required properties so they can be verified and validated;
  2. then to synthesise the design in a way that satisfies the specification;
  3. finally to describe its provided properties for later assessment, (re)use, validation and evolution purposes.

Specifications vs design

System Family specifications contain the specification parts of application, framework and Architecture models. These are related to the design parts, as indicated below.
Figure 3: Specification and design related

Specifications and designs are often developed in different phases. Specifications are produced early and play a central role in quality and process control. Designs are produced later. Therefore, in a development project they are developed by separate steps as illustrated in Figure 4.

Requirements specification

In TIMe we consider a requirements specification as a document. It is normally produced early in a development project and used as a contract for the design work. It will contain specifications and other items of relevance at that stage.

Specifications should be kept consistent with the properties provided by a design. We foresee that specification are used:

Qualities of specifications

Important qualities of specifications are:

Some specification rules

Context specification

Content specification

<Click for example>

Development steps


The descriptions within different areas of concern and on different abstraction levels are developed in steps that help to reduce risk, and to improve quality and control. This help to give better control and also to use the skills of different people better and to run activities in parallel.

Each model is developed in two main steps: first the specification step where the specification part (interfaces and the required properties) is made, and then the synthesis step where the design part is developed.The main development cycles are illustrated in Figure 4.

Figure 4: The main cycles

This is of course a simplified illustration of the main steps. Considered over time we will see that the descriptions evolve gradually, that there are many iterations and that changes take place due to better insight, new requirements and new technology. We will also see that there are other, smaller cycles. For instance: to add a new service or feature to an existing product we need not modify the domain. To produce a customized instance we only need to add a new instance configuration.

Not only waterfall

Please do not jump to the conclusion that TIMe only supports the classical "waterfall" model! It is up to the actual projects to determine whether they will adopt a waterfall strategy, a prototyping strategy, use incremental development or whatever.

What TIMe provides is a set of descriptions and some general development activities including strategies and rules, see Figure 7. The activities are described in Activity overview.

Domain descriptions

What is a domain?

A domain is a part of the world where a system instance may be a (partial) solution to some need (the problem).

As a part of the real world the domain may be very large and not well delimited from other parts of the world. Obviously, the domain descriptions cannot describe it all. It is necessary to focus on those parts that are important for the family of systems in consideration. A natural consequence is to consider only a subset of the world that may somehow be served by a family member

The domain consists of physical entities such as persons, cards and doors as well as conceptual entities such as transactions and rules. The entities may be linked by physical connections that enable entities to communicate or by associations.

Important entity classes are:

In general the entities seeks to accomplish some services or transformation processes. Their basic need is to provide these in the best possible way.
Figure 5: Elements of the Domain
The domain descriptions help to describe and clarify the needs of all the stake holders. Needs may be classified as needs to:

know about entities and relationships, e.g. the identity of users and which doors they are allowed to pass;

communicate among objects, e.g. for two persons to communicate;

transform objects from one form to another, e.g. to peel shrimps, to send a fax or to compile a program;

control something, i.e. to control or manipulate knowledge, transformations and communications, e.g. to control a fax machine.

Difference from systems

The problem domain has a wider scope than any system in the domain, as its focus is on what the systems are (to be) used for, i.e.WHY the systems are needed. Compared to a system context, it should be wider and more general. By studying the whole it is easier to see the purpose of the parts.

Thus, by studying a wider context, it is possible to get a better understanding of WHY the system is needed and what properties it should have. For instance, if the system is a communication system, we may consider why the communication is needed. In what kind of processes is the communication to be used? What are the success criteria for those?

By asking such questions we get a better understanding of the underlying needs and may be able to suggest new solutions. Perhaps the real need is not for a communication system after all? Or, perhaps the need is for a completely new kind of integration between communication and transaction systems?

A problem domain may well be modelled as any other system. Compared to systems in the solution domain there are some differences, however:

System independence

The enterprise view in ODP serves the same purpose as the domain here. However, in the domain we do not wish to identify a particular system or system context. We want the domain to be general and independent of particular systems for several reasons:


In principle, the problem domain can be modelled as a (socio-technical) system, more ore less, like any other system. In practice a more fragmented view, with focus on the needs of various stake holders is more useful. It enables us to describe and to analyse different viewpoints without enforcing the completeness and consistency required in a system model at this stage.

The domain may be described on all three abstraction levels (see Abstractions in models). Normally only the abstract application level is considered and this is what most methods consider as the "domain". It is also what we shall consider the domain unless otherwise stated.

However, it is also possible to describe e.g. the infrastructure domain and the platform domain. Here we may describe common features of infrastructures, say user interfaces, and platforms, say middelware like CORBA [145]. These other domains will end up in other parts of the system such as the interface given parts or the platform.

It is not always obvious what to include in the problem domain. One should avoid system specific solutions, but concentrate on more general concepts and properties that will be common to many systems. For information systems this will typically be types of passive objects (see Active and passive objects) and associations that will be represented in every system in the domain. For instance it is reasonable to believe that every seat reservation system will handle flights, seats and passengers.

System specific solutions should be avoided, but general objects/types and functions performed by (parts of) systems shall be covered.

Why make domain descriptions?

Domain descriptions are used to define a domain and its terminology. domain descriptions serve three main purposes:

Domain description content

Domain descriptions contain the following description modules:

Domain statement, Domain dictionary, Domain models and auxiliary domain descriptions.

Domain relationships

With Families

The domain will normally include entities that will be part of (the domain given part of) systems, see Figure 6.
Figure 6: Parts of the (application) domain will be realised in the domain given part of systems

We seek to keep the domain given parts of systems formally related to the domain. These parts may not only contain "data objects" (passive objects), but also active objects. In the end, the domain models should cover all the domain given parts of systems.

Harmonising domain descriptions

Within domain

The various domain descriptions should be harmonised as much as possible with each other: phenomena and concepts in the dictionary should have their counterparts in the domain object model. If properties are properties of entities in the dictionary, then the terminology introduced there should be used in the property models.

Domain harmonisation

As an example of this guideline, look at the example descriptions and see how Access Zone , Access Point and User are treated in them.

Details will be given for the component descriptions: Domain statement, Domain dictionary, Domain object models and Domain property models.

With family

When system families are introduced, domain descriptions will be harmonised and extended to cover what is common for many systems or system types. Domain descriptions are extended and detailed so that they take domain specific system elements into consideration. The purposes are:

  1. to promote reuse;
  2. to improve traceability;
  3. to simplify maintenance;
  4. to simplify design.
There are two sub-activities:
Details will be given for each description module: Domain statement, Domain dictionary, Developing domain object models and Domain property models.

Family descriptions

What is a family?


A system family contains the generic result of systems development. It represent a product base on which a company may capitalise by producing and selling system instances. As explained in Abstractions in models, systems are modelled on several levels of abstraction:
Each level is developed in two main steps: the specification step which emphasises external properties and the design step which emphasises the internal content. The general approach is to work from the application level towards the implementation level and from the specification towards the design within each level.

Note that applications, frameworks, and architectures are somewhat independent and interchangeable. An application may, for instance, fit into several frameworks, and a framework may accommodate several applications. Each may use components that are shared between families.

In most cases a system family is designed to serve one market segment within a domain. As the application level is closest to the market needs, it seems natural that the system family should be defined on the application level. However, to fully generate system instances, we need information provided in the framework, architecture and implementation levels. Therefore these levels must be included when we want to produce concrete system instances. To produce an abstract system instance for simulation purposes, on the other hand, the application level is sufficient.

Types and Families

Object models in the family area will contain types defined with a context and a content, see Anatomy of object models. To some extent it is possible to define a system family formally as a type, e.g a System Type in SDL. But to define the family as just one type would probably be too restrictive:
In stead we consider the system family as a more loose organisation (library) of types and other generic entities, which are used to generate system instances within a domain. A system family need not be self contained. It may well import parts from and export to other system families.

When to use

There are cases (one-of-a-kind systems) where a family may seem to be overkill. But even in such cases it appears that most results are generic in the sense that they can be used to produce many similar system instances. They may also contain parts that can be used in different systems. Therefore there is an implicit system family, which is made up by the generic system descriptions that are produced anyhow, even in these cases.

In more interesting cases many instances with a range of different properties shall be produced. In such cases it is desirable to analyse the needs for variability, and to design the family so that instances can be configurated and build as cost effectively as possible. This may require some additional design effort that has to be balanced by savings later on when system instances are configurated and built.


Variability can be represented in two principally different ways:
Our main focus here will be on the latter kind of internal variability. It involve all the descriptions in a system family.

Why make family descriptions?

The central idea behind the system family concept is that companies will benefit from being more "product oriented". Rather than being driven by the short term goals of individual system deliveries, which is tempting since each system sold give immediate payback, development effort should be invested in lasting results that can generate a better business in the long run. Companies that focus too much on individual systems tend not to have a clear picture of what their products are and how they relate to the market. They often have difficulties in keeping the cost down and to keep schedules. After some time they get trapped in vicious circles where they never have time nor money to improve.


The family concept is introduced to achieve these goals and to given an overall cost reduction.

Content of family descriptions

A system family contains the following main description modules:

System family statement - a concise prose statement that characterises systems in the family.

System family dictionary - a dictionary over family specific terminology.

System studies - which are temporary descriptions of alternative system principles made in order to assess alternatives and choose the best

Application models - which define the system behaviour related to user needs.

Framework models - which define additional behaviour needed to support the application.

Architecture models - which define the physical platform and how the framework functionality is implemented.

Family implementations - which contain the implementation details in programming languages and hardware description languages.

Family auxiliary - which contain other descriptions such as methods for evolution and instantiation.

The needs for variability is considered on each abstraction level and for the system family as whole. An important result is a method for binding the variability and configuring system instances.

Another important result is a method for flexible introduction of new services. One main goal is that the method shall lead to a flexible framework and Architecture that will allow us to add new services mainly by working on the application level.

System studies


System studies are made in order to create deeper understanding of the technical problems and solution possibilities at an early stage. By exploring the "solution space" for a given problem they seek to find innovative solutions that will lead to better systems. "Better" in the sense that the quality is good, that the cost is competitive the solution is flexible for change.


System studies are not a special kind of descriptions, but rather incomplete family descriptions that are sufficiently detailed that alternative solutions may be compared and assessed. This means that it must be possible to compare development costs, production costs, risks and potential user satisfaction. It may be necessary to perform prototype developments and laboratory experiments.

Note that system studies involves all the abstraction levels, and builds on the activities described for those. It can be seen as the start of system specification.

The results are system sketches consisting of rough specifications and content outlines. They need not be very detailed, but sufficiently detailed to identify all critical parts and the principle for implementing all services. They should be more detailed where there is uncertainty concerning technology, performance or cost.

Note that the resulting descriptions (for the selected system concept) are not to be thrown away. They are to be gradually elaborated into complete descriptions. However, if well formed, they may later serve as an executive introduction to the system.

Two cases:

  1. Feasibility studies which are performed when a new system family is to be made.
  2. Impact studies which are performed when an existing system family is to be evolved.

System study notations


A system instance is a (real system which can perform behaviour and provide services.

The system instance area of concern contains system instances produced from system families. An instance description describes a system instance.

When a system family is defined, a system instance can be defined by reference to a system family using relatively simple configuration statements to binds the variability in the family. If there is no family however, it is necessary to define each system instance completely in self a contained instance description.This can only be recommended for one-of-a-kind developments.

In TIMe, system instance descriptions are organised in:

Relations and traceability


It is clearly necessary to establish and maintain clear and traceable relationships between the various descriptions and models. There are several reasons:


Relationships between all the models and other descriptions shown in the Figure "The main descriptions used in TIMe" must be defined. There are:
The precise definition of relationships depend on the languages that are used. They will be elaborated under the various description modules.

Activity overview

Figure 7: The main activities in TIMe

General activities

As illustrated in Figure 7, TIMe consists of five main activities:
For each activity we seek to give practical strategies and rules that will help to produce high quality descriptions and target systems. As far as possible the approach will be illustrated by practical Examples.

These main activities consists of sub-activities. At the lowest level, sub-activities are seen as tasks (operations) that "belong to" description modules, for instance domain object models. Such tasks will be described under the description modules they belong to.

Specifications and designs have been identified as separate entities in Figure 7 in order to distinguish the specification and design activities. The reader should we aware that this does not imply a separation of the models.

System development is rarely a straight forward process where the optimal solution is found at first attempt. It is more of a trial and error process. By working with a particular solution we often learn how it can be improved or get ideas for radically better solutions. Therefore it is recommended to spend some time investigating the solution space before selecting the system concept to develop. For this purpose we develop System studies which are compared and analysed with respect to cost, technical feasibility and market potential. The most favorable alternative is then selected for further development, if indeed it has sufficient business potential.


There is no specific ordering imposed on the activities themselves, but in practical projects they will be ordered, and indeed the ordering is significant. It is essential that specifications, designs and implementations follow each other in that order for each part of the system. But it is not necessary that every part is developed at the same time. Therefore it is possible to start design before all parts are specified, and to start implementation before all parts are designed. This is further elaborated in the Process models.

It is important to note that the activities are not independent, but influence each other in various ways. As an example, a design activity may lead to insight that triggers a change in the domain models. These mutual interactions are not indicated in Figure 7, but will be explained in the text. We have sought to describe the activities in a generic way that can be used in most processes. However, the best way to carry out an activity depends on the actual state of its input descriptions and output descriptions at the time when it is invoked. In order to take this into account, we provide some alternative strategies and activity subcategories.

Activity categories

Activity categories

As explained in Activity categories there are three main categories of development activities:

Making family

We may distinguish two cases:

  1. Developing from scratch, where a new domain and a new system family is developed without any product base to start from. The starting point is just some needs or a product idea.
  2. Developing from existing families where a new system family is developed using existing families as basis. In principle we go through the same steps as when developing from scratch, but now we seek to utilise as much as possible from the existing Families. Design by reuse is a central concern. This case is considered the normal for development of new system families in a company that have used TIMe for some time. Such companies have established extensive domain descriptions and component libraries which are taken into account in all new developments.
Both cases will follow the same overall strategy, but the detailed activities will be different. Normal development will put more emphasis on reuse and adaptation of existing solutions. If, for instance the framework and the architecture is reused from an existing family and only the family is modified, then the effort will be far less than when developing from scratch.

Evolving family

Evolution is caused by new requirements. It may be requirements for new services or service features, it may be requirements for a new platform, or requirements for a new interface. The abstractions and the system reference model we use in TIMe has been chosen with evolution in mind. Areas that are likely to change independently of each other are separated:

The situation today is characterised by increasing demands for service flexibility. In order to stay ahead of competition, the lead time for specifying and implementing new services must be as short as possible. At the same time, many products must be supported on a range of different platforms. This means that system Families should be designed with flexibility and diversity in mind and supported by tools.

The various evolution activities are dealt with for each description module separately.

Harmonising family

The harmonising activities take care of the iterations and feed-back between the various descriptions.



The objectives of analysing are:


Analysing is part of product planning which is a more or less, continuous task in any prosperous company. It is constrained by the company's strategic plans and seeks to come up with ideas for new products or enhancements to existing products.
Figure 8:  Analysing
Central to the task is a deep knowledge about a problem domain and existing system solutions. It seeks to identify a problem, i.e. some deficiency or opportunity for improvement, that a new system family may solve. This should not be just any problem, but something that would mean considerable improvement and thus have sufficient value for some stake holders to justify an investment in the new system. Thus the core of the task is to understand needs and find solutions.

The concrete results are domain descriptions, system studies and specifications for system families that may create future businesses. A business is created when a product and a production meets a market. Thus, commercial success depends on more than the product qualities. It also depend on the marketing and the production. Consequently it is recommended to develop the product, the market and the production in parallel.The domain relates clearly to the market, and the instances to production. In this way TIMe supports integrated development of all three areas.


Analysis consists of two activities:


Analysis require multidisciplinary teams. Key personnel are domain experts such as marketing people and real users, but system developers should also participate both to improve their own problem understanding and to help finding improvements. It is a task where experts in the problem domain meets experts in the solution domain and new opportunities arise out of their combined effort.

There may also be existing literature, existing systems and possibly existing domain descriptions to use. Existing systems is an important source. Consider what parts of the domain they cover. Can competitive advantage be gained if we cover more? or less?

What to do

"How can you possibly find the solution if you haven't grasped the problem?" (adapted form a wise saying at Ericsson).

This wisdom tells us that understanding the problem should come first: start by describing and analysing the domain, and go from there towards possible solutions. However, when the domain is well defined and the challenge is to gain competitive edge through innovative solutions, the solution comes first.

Therefore, the strategy will depend on the quality of existing domain descriptions, and whether the challenge lies in the problem or in the solution.


Note that domains are not entirely independent of design concepts or technology. New technology enable improvements that were not feasible and perhaps even not imaginable before. For instance: the access control domain was different before cards were introduced than after. Before there were keys, but no need for person identification. After, person identification is a central issue.
Figure 9: Domain - system iterations
The old solution was traditional keys that were hard coded according to access zones. With new technology it became feasible to use personal cards and PIN codes instead and thereby achieve more flexibility and security. This change led to a changed domain model where person identification and authentication is a central issue.

In order to get a good start with the first domain descriptions it may be a good idea simply to model the current reality first. If the challenge is to reengineer existing systems, then first establish a domain description corresponding to the usage of the existing systems.

When initial understanding of the problem domain is established, the next step is to start looking for improvements in terms of new technologies, innovative system solutions or just better ways to organise work. What are the problems today, and what may be improved? Answering these questions and setting goals for improvement is the soul of product planning and should not be taken lightly.

If the improvements have effect on the domain, then make an new or updated domain description.

When the goals for improvement has been set it is time to start looking for technical principles and solutions. We start by Analysing solutions seeking to come up with alternative system ideas that may be evaluated and compared. How this is to be done depends on the problem, but it will involve making a mixture of object models and property models for the new family (or system instance if it is a one-shot development). These models are called System studies.

In the beginning, these models may be independent of any particular system boundary. In fact it may be a good idea not to identify the system initially, but use the models to analyse what shall be done, and how it may be done. When this is well understood, the next step is to decide what shall be done by the system, and what shall be done by the environment.

The result will be a number of alternative product outlines that may be analysed with respect to technical feasibility, risks, cost and schedules.

Finally, the most promising system concept is selected among the alternatives, and a go/no-go decision is made based on business criteria, available resources and schedules. If it is go, then a specification is developed.

A major goal for analysing is to decide what parts of a problem domain to include or support by a new product. Obviously the domain analysis should be more detailed for those parts. Therefore there is a mutual influence between domain analysis and solution analysis.


We define two main strategies: analysing from scratch and analysing from existing domain.

Analysing from scratch

If the problem domain is new or the quality of existing domain descriptions low the following strategy can be used.

It is quite normal that domain models and system family models influence each other. Therefore it may be a good strategy to start analysing solutions before the domain models are completed.

Analysing from existing domain

If the problem domain is well described, and the main challenge is to find new technical solutions, then the following strategy is recommended.

Analysing domain


We perform domain analysis in order to:


Domain analysis is primarily concerned with the problem domain. In addition to general knowledge of the problem domain, knowledge about existing systems is important. It is important to identify the strong and the weak sides of existing solutions. It may be useful to first model the existing domain including existing systems, and then look for ways the domain may be improved. As a result a future domain may be described. If systems are used in different markets for different purposes, several domains may be described.
Figure 10: Analysing domain


We perform domain analysis by means of the following sub-activities:


The people to involve are stake holders in the domain such as users and other actors, market people and other domain experts.

What to do

Which sub-activity to start with will be a matter of choice. For a new domain it is recommended to start with the domain statement and the dictionary, and continue with the object models and the property models. For an existing domain, it may be better to start with object and property models. In both cases there will be iterations between domain descriptions and design descriptions.

Making domain descriptions 

In this activity we seek to define a domain for the first time. The main purpose is to understand the domain in terms of concepts, objects and relationships and to understand the needs that various stake holders have (the problem). We have no existing system family to consider (but there may be other existing systems in the domain).

Work on the object and property models will normally lead to clarification and more complete understanding which should be used to improve the dictionary and domain statement.

Evolving domain descriptions 

Here the purpose is to analyse and improve existing domain descriptions. A typical reason may be that we have revealed imperfections or are looking for improvements that will lead to a new and better domain description or that we need to add details. This will typically be the case when we plan new products in an existing domain. The strategy will depend on the circumstances, but since we already have a domain statement and a dictionary, it may be a good idea to start with the formal models in this case.

Summary of dynamic domain rules

Domain modelling approach

Finding domain objects

Model the actors

Analysing Requirements


Analysing requirements is performed in order to analyse needs and to develop specifications. Not just any specifications, but specifications for system Families with a business potential. domain descriptions where needs for improvement are identified is a good starting point for this activity.
Figure 11: Analysing requirements
The activity is crucial for the success of a system family as it seeks to answer questions like:


A central issue is to balance the needs against technical feasibility and cost. To this end, system studies are made where alternative system concept can be evaluated and compared. (These may be seen as mini developments.) If any of the alternatives seems feasible and attractive from a business viewpoint, the best is chosen for further development.

For the selected concept a specification is produced.

It is of course possible to make specifications without (explicitly) analysing the domain and analysing solutions first, but it will be more difficult. Parts of these activities will then have to be done implicitly in the specification activity. With explicit domain descriptions and system studies, the goals for the system development are known, and the task of specification is to express them precisely and detailed.


Developers, market persons, and stake holders in the domain should all participate. Go/no-go decisions will of course involve management.

What to do

The first thing to do is to make system studies seeking for a viable overall system concept. If such a concept is found the next step is to develop a system family statement and start on a dictionary, and then to develop specifications.

Making requirements

When making requirements for the first time, we assume there are domain descriptions to use as input, but there is no existing family (apart from those that other companies might have on the market).

Evolving Requirements

In this case we have existing system family descriptions to start from. We assume the reason for evolution is that some external requirements have been added or changed. (Changes caused by internal iterations are handled by harmonising) In this case too, we start with the formal specifications

Summary of dynamic requirements rules

Requirements analysis approach

Initial requirements

State explicitly the project and product requirements. These requirements are often requirements to the tools and languages of the project.

Analysing solutions


The purpose of analysing solutions is too consider the needs and how they may be satisfied. It is an interplay between the what and the how.

Inputs to the activity are needs and domain descriptions. Central decisions to be made are what needs to satisfy, in particular which services to provide, and what technology to use.

The activity is the first step in turning needs into solutions. It can consist of many mini-development projects with the purpose of exploring alternative solutions. The activity may therefore produce a number of alternative system Sketches. The detailing of these sketches depends upon the knowledge about the desired system and the risks involved.

Feasibility study

For each system concept:
  1. Selecting services to support.
  2. Sketching the environment.
  3. Sketching the application.
  4. Sketching the architecture.
  5. Identification of and assessment of risk and critical issues.
  6. Assessing cost and schedules.
  7. Evolution and maintenance.
When some promising alternatives have been sketched they shall be compared and the best selected. This forms the input to make family statement and Make Specifications.



The main inputs to this activity are informal statements about needs, the domain descriptions and system Studies.

Outputs are precise specifications expressed on the relevant abstraction levels. The focus is on properties and context. The challenge is to structure the input information, find missing detail and organise the specification. Clarifications and iterations will be needed.


Specifications are developed by development persons in close cooperation with users and other stake holders. System and market departments should also take part, if not in the detailed work, at least in major decisions.

What to do

Turning needs into specifications is not always straight forward. On one hand it is necessary to clarify the needs in order to make the specifications sufficiently precise and detailed. On the other hand it is necessary to consider technical feasibility, economy and schedules. Finally it is necessary to consider how each particular requirement will interact with other requirements. An iterative process is required where users and other stake holders take actively part.

It is assumed here that specification is proceeded by system studies where an overall system concept has been selected. It is clear roughly what parts of the domain that shall be covered by the system family, and what properties it shall have. The goal is to state this more precisely and with more detail.

For a general approach to making specifications more precise and detailed, see The dialectics of refinement.

Making specifications

When specifications are developed for the first time, the following strategy may be used.

Evolving specifications

When new requirements lead to changes in specifications, follow this strategy:

Summary of dynamic specification rules

Incremental specifications



The main inputs to this activity are the formal specifications: Application specification, Framework specification and Architecture specification.

The main outputs are the corresponding design models: Application design, Framework design and Designing architecture. In addition one should consider how implementations shall be generated, how instances shall be produced and how evolution is to be done, in particular how services shall be added. This is described as part of the Family auxiliary descriptions.

Figure 12:  Designing

Designing is not a monolithic activity. It is composed from activities that each require considerable effort, especially when developing from scratch:


Implementations are detailed and precise descriptions of the hardware and the software that a concrete system is made of. They define the physical construction of systems in a family. The software part will be expressed in programming languages such as C++ or Pascal, while the hardware part will be expressed in a mixture of hardware description languages such as circuit diagrams, cabinet layout diagrams and VHDL. Software plays a dual role. Firstly, as a description to be read and understood outside the system, and secondly as an exact prescription of behaviour to be interpreted inside the system.

Concrete system

Concrete systems consist of:

What to do

For every new system development, the platform is an important design issue, as it determines important properties such as cost, reliability and flexibility. It also influences the way that applications and frameworks are implemented.

Figure 13 illustrate some aspects of implementations. Note that the code generated from application frameworks will interface with code coming from different sources. To produce a concrete system these various parts of code must be linked together and loaded on the the hardware.

Figure 13: Software implementation
Once the platform and the code generation strategy is defined, it is possible to rely on automatic code generation for application and framework evolution for those parts where SDL is used. The code which is generated for the application and the framework must be adapted somehow to the platform. Here the Vendors of code generators use two different strategies. One is to adapt the code generator so the generated code fits the platform. Another is to adapt the generated code to fit different platforms by means of interface modules and/or macros.

It should be noted that even if automatic code generation is used, there is likely to be some hand generated code (e.g. for input/output drivers) and possibly legacy code from existing solutions. It may also happen that different parts are generated using different tools, e.g. SDL tools for the control parts and UML tools for database parts.

Consequently there are many issues to consider, and many tool problems to solve before the implementation activity is well defined for a new system family. However, once defined it may be used over and over again to produce new implementations.


In the instance area of concern, the main thing is to configurate and to build a system instance. This can be done both on the abstract level, using SDL, in the implementation architecture, and in the implementation. The common practice in most companies is to do this on the implementation level using configuration files and tools like Make. An alternative is to use special configuration languages in this area.



System instances are what companies sell and customers buy. The purpose of instantiation is to produce system instances from family descriptions and instance configuration descriptions.


In the instance area of concern, the main thing is to configurate and to build system instances. Ideally we should perform configuration at the level where it belongs: functionality at the application and/or framework levels, and implementation at the architecture and/or implementation levels.

It is possible to perform some configuration at the application and framework levels using SDL, but due to limitations in the language, this is restricted.

The common practice in most companies today is therefore to do configuration on the implementation level using configuration files and tools like Make. (An alternative is to use special configuration languages.)

We recommend that a method for configuration and building of system instances is defined as part of the architecture design work.

Domain statement


The domain statement leads to the very first understanding of what this problem domain is all about. It helps to clarify needs and to understand the real purpose of systems in the domain. It also serves as an introduction to the other domain descriptions.


A (problem) domain statement is a concise description of the problem domain with focus on stake holders and their needs, the essential concepts, functions and work processes, rules and principles. It should also clearly state the nature of the problem, i.e. what one tries to achieve.

It will normally be sufficient to express the domain statement informally using natural language and drawings, but one should try to be as clear and precise as possible.

The domain statement can often be based on existing prose descriptions. There may be descriptions of earlier systems, there may be textbooks on the subject and there may be informal statements about the system.

The domain statement may also contain required properties if these exist at this point of time, but for an initial development of a new system these may be vague or non-existing.

Domain statement outline

Executive summary

This should be a very brief summary with focus on the key issues. It may well be written in a style directly suitable for market purposes. Stake holders in the domain should immediately recognise and accept the description.

Area of concern/context

High level description of the area of concern or the context of the domain. E.g. the interbank financial market, the security in buildings area.

Stake holders

Stake holders are persons or institutions with direct or indirect interest in the domain: companies, users, operators, owners, etc. The various stake holders have responsibilities and tasks to perform that give rise to needs. Therefore the domain statement should mention every class of stake holders, their overall objectives, needs and responsibilities. The Actors are of course important, but do not forget other stake holders that have a more indirect interest (often economic), e.g. managers or owners.

Subject entities

These are all the entities that are manipulated, represented or controlled in the domain:

Be sure to mention every category of subject entities and explain their role in the domain.


These are the entities that are used by the actors to perform services and transformation processes. Be careful not to make the helpers too system specific. Try to capture the general features needed irrespective of particular systems.


List all the main functions, their purpose, which objects that collaborate and describe how they are performed in terms of textual use cases.

Work processes and materials

If the domain contains non-trivial transformations, describe each transformation stating its inputs, outputs and constraints. This is particularly useful for material transformation processes, e.g. to pick potatoes or peel scrimps.

Rules and principles

State general rules and principles that apply to the domain as a whole or to specific parts of the domain.


If there are trends in how the domain will develop: describe them.

Existing systems

Brief summary of systems that are common to use in the domain, their strengths and weaknesses.

Problems - improvements needed

Identification of problems or shortcomings that need to be solved.

Domain statement relationships

Within domain

Every domain term used in the domain statement shall be defined in the dictionary.

Every type of actor and entity shall be represented in the object models under the same name as in the statement.

Every service and transformation shall be represented in the property models under the same name as in the statement

With family

No particular constraints.

Harmonising domain statement

Make sure the relationships with other domain descriptions are satisfied. Make an entry in the dictionary for every domain specific term . Important objects, classes, relationships and properties in the domain models shall be mentioned in the statement.

Developing domain statement


To collect domain knowledge and make a Domain statement, and to keep the domain statement updated and in harmony with other descriptions


The source information will normally be fragmented, informal and imprecise by e.g. not using the same terminology or by stating the same required property twice, but with a slight difference. It may also be unbalanced in its coverage of essential versus not so essential information. This activity, together with the one making the dictionary, shall transform these informal specifications to a more precise, yet informal, specification, where the essential parts are emphasised.


As for the domain at large.

Making domain statement

This activity may well be subdivided according to the topics of a domain statement, for instance like this:

Make executive summary

This part is best written after the other parts of the domain statement. Consider what is the essential message of the problem domain descriptions. Express it in a way everybody can understand. Make it short (half a page).

Describe area of concern/context

Try to state concisely what the area of concern is about and what its environment is.

Describe stake holders

Ask yourself who has an interest in this domain? Try to identify every type of stake holder/person-role in the domain and describe their overall responsibilities and tasks. Note down what kind of problems they have and what kind of improvements they would consider valuable.

Describe subject entities

Try to identify all passive entities (including the stake holders), manipulated entities and controlled entities. Explain their roles in the domain and how they are connected and related to each other. Do they communicate? How? Consider only entities and associations that are relevant to some services or work processes in the domain.

Describe helpers

Are any helpers needed to perform the services? Try to abstract from particular system solutions and identify the general features needed. Note that the helpers are likely candidates for improvement. If it is very difficult to generalise, then describe the existing helpers, and consider improvements afterwards.

Describe services

List all services (functions) needed and give a concise description of what each does. Again it it important to abstract as much as possible from how services are implemented in existing systems. Try to focus on what essentially needs to be done.

Describe work processes and materials

For each material transformation, give a concise description of what it does. What are the inputs and the outputs? What are the sub-transformations? What are the constraints? Note that the purpose is not to describe technical solutions, but to clarify the goals.

Describe rules and principles

Rules that regulate the problem domain should be referenced, as should general principles. You will have to consult domain experts to find out about these issues. Be aware that law may severely constrain the technical solutions that are available, as well as it may create new business opportunities.

Describe trends

Important trends regarding functionality, work processes, regulations and technology should be stated.

Describe existing systems

The purpose here is to briefly explain the main features of existing systems with emphasis on their strong and weak points. Consider also the competition here. This will help to identify duty bound and success properties for new products.

Describe problems and improvements needed

Analyse the domain described so far and try to identify the problems with existing solutions and how they may be improved. Interviews with domain Actors and other stake holders will be important here.

Evolving domain statement

When new insight or new requirements leads to a modification of the domain descriptions, then the domain statement shall be updated accordingly. This activity follows from other activities in domain analysis or solution analysis.

Note that the domain shall be relatively stable compared to the system solutions. It shall not be updated so often. However, a new domain is likely to be updated more frequently than a well established one.

Summary of dynamic domain statement rules

Consistent domain statement

Maintainable domain statement

Domain dictionary


The objectives of a domain dictionary are to define terminology and thereby enable precision and efficiency through:


A dictionary is a reference book listing words or terms and giving information about a particular subject or activity (Collins 86).

A dictionary in TIMe need not be a book, but it shall contain a list of terms with an explanation of their meaning.

An informal Domain statement is normally not sufficient. We will need a more precise definition of the most important phenomena and concepts and the corresponding terminology. We therefore improve our understanding by listing the concepts in a dictionary. For some domains, dictionaries are readily available, but for other areas, an important task is to define one.

A dictionary is based upon the three aspects of concepts: designation, intention and extension. The designation is the entry in the dictionary and the explaining text is a description of the properties that phenomena shall have in order to belong to this concept. The extension are all the phenomena covered by the concept.

Producing a dictionary adds to the understanding of the subject being analysed. Furthermore, it will help people to communicate more precisely. A dictionary helps to bridge the gap between people with specific knowledge of the application area and people new to the area. Later in the development the concepts in the dictionary will often find their way into the system description as types (of objects). We suggest that the dictionary should be maintained along with the other permanent documents.

Be aware of the difference between concepts and sets. A set has cardinality, and a given entity may or may not be member of the set. A concept is not a set of phenomena, but just a definition of the properties of the corresponding phenomena. This should be reflected in the wording of the dictionary - the reason is that the domain may have real sets.

Domain dictionary content

The dictionary may simply be an alphabetic list of terms with informal explanation. All terms used in the problem domain should be included, such as :


Within domain

There is a more or less direct road from a dictionary to an object model. Concepts are represented by classes: the name of the class corresponds to the designation and the class definition to the intention of the concept. objects according to the class represent the extension. Therefore the names used for object types shall be the same as the name used for the corresponding concept in the dictionary.

With family

The domain given terminology used in Families shall be the same as in the domain dictionary. It is possible to define additional terminology in separate Family dictionaries.

Harmonising domain dictionary

Within domain

Ensure that the relationships with the other domain Descriptions are maintained. See Relationships.

With family

Ensure that the general domain terminology is applied in the Families. If family specific Dictionaries are developed, they should refer to the domain dictionary for all domain given terminology and avoid redundant definitions (which may develop into inconsistent definitions).

Summary of static domain dictionary rules

Domain dictionary entries

Update d domain dictionary

Domain specialisation hierarchies

Developing domain dictionary


To make a Domain dictionary.


The activity makes an entry in the dictionary for each term in problem domain.

In general, the dictionary comes from the other domain Descriptions, as its purpose is to define the terminology used there. Thus, the dictionary is developed more as a spin-off from making the other descriptions, than as an independent activity.

When object models and property models are developed, the dictionary should cover all the objects/types, associations and properties represented in those models.


Same as for domain Analysis at large.

Making domain dictionary

The dictionary is made for the first time as part of the first domain analysis, see: Making domain descriptions.

The first dictionary comes from a (prose) Domain statement. By studying the nouns in the Domain statement we can make the initial dictionary. But the dictionary shall contain more than the nouns, it shall also include services or functions and associations which may be visible in the domain statement as verbs.

A practical approach is to analyse the text of the domain statement and mark every term that refer to a domain specific concept or phenomena.

For each term thus marked, make an entry in the dictionary which define the term.


  1. should the dictionary be organised in some way? e.g. according to the domain statement categories, according to the kind of entity (concept, property, entity, relationship, service)
  2. should the dictionary contain references to object models and property models?

Evolving domain dictionary

The dictionary is evolved as part of the evolution of domain Descriptions, see Evolving domain descriptions. Changes may be due to evolution of the domain statement as well as the domain models. Whenever existing terms are modified or new terms are introduced in any of the other domain Descriptions, the dictionary should follow up.

Summary of dynamic domain dictionary rules

Finding domain dictionary entries

Domain models


The purposes of domain models are:


Domain models are composed from Domain object models and Domain property models, and organised as illustrated in Figure 14.
Figure 14: Domain Models
Domain models will mostly be application abstractions. But the possibility to model more concrete aspects (e.g. infrastructure and platform) will not be excluded. It may for instance be useful to model various technical solutions which are common for the problem domain. It is perfectly relevant to make more concrete object models whenever there are concrete matters in the domain needing to be described, e.g. physical materials, concrete interfaces. Implementations are not part of domain models.
Figure 15: Domain model notations

Domain object models


Domain object models serve:


Domain object models describes the problem domain from an object oriented perspective.
Figure 16: Domain Object Models
It defines types which represent concepts in the problem domain, and objects which represent phenomena in the problem domain. It defines the attributes, the operations and the behaviour of objects as well as associations and communication links between objects. It shall be complemented by Domain property models.

Domain object models will describe active objects as well as passive objects.

Active and passive objects

Objects of the real world are by nature active. They interact with other objects and have a dynamic behaviour. When we consider the domain as a part of the real world, all objects are potentially active. However, we do not need to model them all as active objects in the domain models. Some may be active, some may be passive and some may be both. This is a decision we make in the models.

At some stage we must decide the level of detail and the kind of behaviour we will specify for each object type. For active objects, we specify a "real" behaviour, whereas for passive objects we specify a "data" behaviour which is very different from the "real" behaviour. Considered as an active object an AccessPoint in the Access Control domain have a reactive behaviour that interact with real users. As a passive object, represented in the validation database, is has a simpler behaviour that responds to validation queries.

Normally there will be only one active object representation of a domain entity, but there may be several passive object representations. The behaviour, the attributes and the context may be very different in each case. Therefore we may need to develop one active and several passive component models representing the same domain entity.

The advantage of the object models over prose descriptions are that they show the relationships between objects in a rigorous way, and that they use a graphical notation.

The domain object model is not only made in order to get a better understanding of the domain. It is also made to identify types that are common to all systems in the domain. It is a goal to describe at least every object type that will be part of the domain given parts of systems and system environments. It may be difficult to find all of those without considering any system. It will normally help to study existing systems, and also to work on the new system design. Consequently, when complete, the domain object models will be influenced by existing systems as well as the design of new ones.

However domain object models may well include more objects than those that will eventually be in systems or system environments. They should also describe related objects that are important for the purpose of systems in the domain.

Components for reuse are supposed to be identified in this activity, and correspondingly components identified in earlier domain object models are used here. Classes of objects that are identified as belonging to the problem domain will have more chances for being reused in other systems than classes being made in the design of a specific system. Types (classes) identified in the domain object model are therefore supposed to be made as general as possible, and there may even be sub-activities that have this as their main purposes: to prepare for reuse. Apart from this, TIMe believes in the fact that reuse comes after a successful first use.

Since the domain as we consider it, is a generalisation it may be modelled as a type (in SDL) or a class (in UML). It will normally contain components that are defined with reference to other types (SDL) or classes (UML), see Anatomy of object models. In most cases these component types are more useful than the domain model itself.

There are several reasons for this:

For this reason we recommend the following rule

Make component type models

In order to get a better overview, one should try to put the components together in complete or partial domain models where possible. A useful compromise may be to develop several viewpoint models.

Consequently, domain object models will normally contain two main parts:

Figure 17: The access control domain
Figure 18: The class definition of Access Zone

Domain object modelling belongs to a subset of more general object modelling. Object models can be described using either UML or SDL, depending on whether they are domain or design object models and depending on the formality needed.

Domain object model languages and notations

Object models are expressed using UML or SDL. It should be noted that UML is made primarily for passive objects, while SDL are for active objects. For purely passive objects, pure UML is sufficient.

Domain object notations

Make separate object models for active and passive objects?

Abstract domain object models

Domain object models are abstract models unless otherwise stated. They are abstract in two senses:

The abstract models will normally concentrate on the application abstraction, and only consider infrastructure in special cases where the infrastructure is general for the domain. Frameworks are normally not considered as they belong to the family area.


At this level we find the bulk of domain object models. Every actor, helper and subject entity should be represented in a component model.

In addition the domain structure may be represented in a number of viewpoint models or in a single model.


This level will consist of component models for infrastructure components that are common to the entire domain. System and family specific components should not be included.

Make component type models

Concrete domain object models


At this level we find models for platform components that are general for the entire domain.

models at this level are only made if the domain is about platforms, or if the platform is standard for the domain.

Domain object model relationships

Within domain

With Design

Harmonising domain object models

In this case the domain object model is harmonised within the domain and with design.

Within domain

Ensure that the rules for domain internal relationships are correctly maintained:

With Design

Ensure that the rules for Design relationships are correctly maintained:

Summary of static domain object model rules

Use the general rules for object modelling and the following special rules:

Make component type models

Domain object notations

Domain property models


To improve understanding and communication about the domain by rigorously describing the properties applying to domain objects, services and interfaces.


Domain property models are used to describe the problem domain from the property perspective. It includes functional and non-functional properties.

Functional properties are considered as projections of object behaviour, and described using text, role structures and MSC, see Figure 14.

Text is used to give a textual explanation of a service or interface. Role structures are UML instance diagrams that represents the roles of the service or the interface. The objects in role structure diagrams can be considered as anonymous objects. They will be related to object model objects by role association links, and to the instances in the service MSCs through the same name.

When the system is designed, the domain property models will also be valid property models of the corresponding (domain specific) system objects. Properties belonging to the domain will be candidates for properties of several system in the domain.

It is an implicit assumption that models of the domain will not cover design dependent properties. Such properties will be added in design models. However, the domain may well cover concrete properties as long as they are general for the domain and not specific to particular systems or families. Domain properties shall be related to domain objects if they can, but it is allowed to describe properties without reference to objects. One example is roles where the actor objects are unknown or irrelevant in the domain. Another example is general properties applying to the domain at large. property descriptions will typically be quite fragmented.

Abstract domain properties


Services: Text, role structure diagram and UseCases in MSC.

Interfaces: Text, Role structure diagram and Use Cases in MSC.

General properties: safety, liveness, user friendliness etc.


Services: as above.

Interfaces: as above.

General properties: as above.

Property modularity

Concrete domain properties

Application implementation

General constraints and requirements that are common to the domain:

reliability, safety, modularity, performance, size, technology.


As above.


About general properties of the environment, materials, processes, etc.

Domain property model relationships

Within domain

With Design

Harmonising domain property models

Within domain

Ensure that the rules for property-object model relationships within the domain are satisfied, see Domain property model relationships.

Ensure that every service mentioned in the dictionary and statement has an entry in the service lists and corresponding MSCs.

With design

Ensure that the property-property relationships with design are satisfied, see Domain property model relationships.

Summary of static domain property model rules

Property modularity

Developing domain models


The goal is to make domain object models and domain property models and to keep them aligned and in harmony with other descriptions.
Figure 19: Developing domain models

The main inputs are domain knowledge that come from people, and general domain knowledge that can be found in the literature. The domain statement and the domain dictionary give important input too. When a system family has been defined, it may influence the domain models. The outputs are the domain object models and the domain property models.


This activity is composed from two sub-activities:

Summary of static domain model rules

Developing domain object models



This activity produces a (set of) Developing domain object models, some of which may be adaptations of existing object models (which will be the normal case during evolution and reengineering).

The main inputs to this activity are existing domain object models (if any) the Domain statement and the Domain dictionary supplemented by domain knowledge and the Domain property models. It is also influenced by existing systems and the design of new ones.

As explained in Domain object models, it is possible to model the domain as a single structure, but we recommend to develop viewpoint models and component type models as well. In a single domain structure it is not so easy to distinguish between active and passive objects. Therefore we may start to develop the domain structure without considering whether objects are active or passive. In viewpoint models we are more likely to see differences, and in the component models we must be clear about it. The following guidelines help to identify active and passive objects:

Active and passive domain objects

As an example consider the user of the Access control system, see Figure "The access control domain". The model indicates that there will be two user concepts: active users seeking services, and passive users representing those that are valid users in the domain.

What to do?

Making domain object models

In this case we have no existing object model or property model, only a first domain statement and a domain dictionary. The task is to develop the first domain object model.

In all steps above, variability, generalisation and specialisation should be considered.

Using this strategy it is natural to develop two models, an active object model and a passive (information) object model. Here the active model will map to active (domain given) objects in the systems while the passive will map to known entities represented by passive (domain given) objects in the systems.

An alternative is to combine active and passive objects in the same models.

Evolving domain object models

In this case an existing domain object model is evolved to take new domain knowledge or requirements into account. Inputs are the existing models and knowledge about the changes to be made. The reasons for change are either:

Note that updates due to system design normally is handled in the harmonising activities.

Summary of dynamic domain object model rules

Domain object modelling approach

Make component models

Using domain object notation

Domain object modelling is a special kind of object modelling. In addition to the general guidelines for object modelling; the following special guidelines apply:

Developing domain property models



This activity produces the Domain property models, including only properties of entities visible in the Domain object models. Functional Properties that can be expressed as Use Cases by means of function lists and MSC are considered the most important, but Non-Functional Properties are also considered when they are part of the domain. A speciality of TIMe is that objects in the domain object model are not just passive "data objects" - they may also be active objects. If such active objects are identified in the analysis of the domain, then an analysis of their properties also belong here.

Who to involve

The people to involve are the same as for domain analysis in general. However, in order to get the service properties right, it is important to consult actors in the domain, and in particular those that may become users of the systems.

What to do

Consider each of the active object types in all their different roles and describe, by means of role structures, text and MSC, what they need to do or need others to do for them. For each service, identify the roles or actors involved in role structures, and describe the collaborations using MSC.

Be sure to cover all general tasks where systems in the domain are involved. Consider also work situations and tasks to be achieved by means of the systems, i.e. consider a wider context of purposes than the systems in question.

Making domain property models

As part of the Developing domain models activity this activity runs in parallel with Making domain object models.

The main inputs are the domain statement and the domain dictionary together with the object model developed so far and general domain and system knowledge.

Evolving domain property models

In this case the starting point is existing domain models and some requirements for new or modified properties. TIMe seeks to support property flexibility by promoting modular property models. However, undesirable interactions may occur between properties and they should be detected and resolved.

Summary of dynamic domain property model rules

Domain property modelling approach

Follow the rule for MSC usage:

Rule for MSC usage

Domain behaviour properties

Domain non-functional properties