System family statement
What is a system family statement?
The system family statement is a concise description of the system family with emphasis on
, i.e. the external properties. A system family statement is normally expressed in prose, but may well be supplemented by illustrations.
The system family statement is the first introduction to the system family. It serves two main purposes:
To concisely express the goals for the system development.
To serve as a top level introduction to the system family.
System family statement outline
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.
How it relates to the domain
Briefly about the domain (with reference to domain descriptions) and what needs in the domain the system family addresses. Which actors in the domain will be supported, and what other stake holders may benefit.
How it relates to the environment
Describe the system context with emphasis on the system boundary and the system environment Explain who are the users, operators and other systems that may connect to the system.
What services it provides
A summary of the main functionality with a list of all the main services, their purpose, and how they are performed.
A brief description of the interfaces with emphasis on user interfaces.
Give a brief account of the general properties and the non-functional properties provided. Emphasise positioning properties. If maintenance properties are important they should be mentioned.
Variability and evolution
Consider flexibility for change, variability and other issues related to market adaptation in space and time.
If technological principles used or other design aspects are important at this stage, they should be mentioned.
System family statement notations
The family statement will be expressed in prose, supplemented by figures.
Family statement relationships
The statement is likely to refer to the domain descriptions, but it may also use terminology from the domain. Therefore the domain given terminology used shall have entries in the domain dictionary.
The statement is likely to use some system family specific terminology. Such terminology shall be defined in the system family dictionary.
Harmonising system family statement
Be sure to use a terminology which is consistent with the domain terminology.
Every domain term used should be defined in the domain dictionary.
Every family specific term should be defined in the family dictionary.
For every service mentioned there shall be a corresponding entry in the Specifications.
Summary of static family statement rules
Developing system family statements
It is assumed that the creative work which actually determines what the system is is going to be is performed in other activities, mainly in the system Study activities and Specification activities. The task here is simply to express what has been decided. The form shall be suitable for a broad audience within the company (not only developers) and possibly for external use. It will be used for internal decision making and control.
The system family statement should be written jointly by market persons and developers. Management should be involved in approving it.
Making system family statement
The activity may be subdivided according to the topics of a system family statement:
Evolving system family statement
The system family Statement should be written in such a way that it can be kept as stable as possible. Nevertheless, some evolution is likely to occur either because the Statement needs improvement or because new features are added to the systems in the family.
How to proceed depends on the nature of the change.
System family dictionary
What is a system family dictionary?
The system family dictionary is organised in the same way as the
. The two dictionaries are used together to give full coverage of the relevant terms. They may even be organised as two parts of the same dictionary.
To define system family specific terminology in order to:
improve precision and efficiency in the process;
facilitate training of new people;
facilitate reading system documentation.
System family dictionary content
The general format is:
The family dictionary is related to the domain dictionary. The two dictionaries may physically be different parts of the same dictionary.
System family dictionary relationships
Relationships system family dictionary - domain
The domain given terminology used in families shall be the same as in the domain dictionary.
Harmonising system family dictionary - domain
Ensure that the general domain terminology is applied in the families. family dictionaries should refer to the domain dictionary for all domain given terminology and avoid redundant definitions (which may develop into inconsistent definitions).
Relationships system family dictionary - rest of family
For entries in the dictionary that correspond to concepts that will be represented directly by types (classes), it may be a good idea (if this is known) to use the same name on the type as the designation of the concepts.
Harmonising system family dictionary - rest of family
Ensure that the relationships with the other family descriptions are maintained. See
System family dictionary relationships
Summary of static system family dictionary rules
Represent each essential system family phenomena and concept by an entry in the dictionary.
Keep the dictionary updated throughout the development. If desired classify the entries as coming from analysis or design, domain, environment or system. This may help in updating the dictionary and also to answer questions like "Is this phenomenon covered by the domain of the system?" or "Is this type of entity handled by the system?"
Developing system family dictionary
In general, the dictionary comes from the other family 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.
The dictionary is most likely made by the developers.
Making system family dictionary
The family dictionary is made for the first time as part of the first requirements analysis, see:
The first family dictionary comes from the
System family statement
System family statement
. By studying the nouns in the
System family 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. It shall include every term used in the system specifications. Note that domain terminology is not to be covered.
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 system family dictionary
The dictionary is evolved as part of the evolution of family descriptions. Whenever existing terms are modified or new terms are introduced in any of the other family descriptions, the family dictionary should follow up.
Summary of dynamic system family dictionary rules
Develop the dictionary in parallel with other family descriptions.
Use the dictionary actively as a source of terminology when making the other descriptions.
Do not add new terms to any model without checking that there is no appropriate term in the dictionary already.
Analyse each entry checking that it is precisely and unambiguously defined. Look for similarities among entries. Avoid to use the same term for different things, and to use different terms for the same thing. If necessary define synonyms explicitly. Clarify relationships between related entries, e.g. subtype relationships.
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.
illustrates 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 20: Software implementation
Architecture models contain information that may be used to direct the transformation from application frameworks into implementation code and the building of a concrete system.
Automatic code generation
State-of-the-art tools allow the application framework software to be automatically derived. The code which is generated for the application framework must be adapted somehow to the software environment (operating system, input-output, middleware). 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.
Once the platform and the code generation strategy is defined, it is possible to rely on automatic code generation for those parts of applications and frameworks where SDL is used.
Why family auxiliaries?
In addition to the formal models and the less formal statements and dictionaries there is always a need for more informal descriptions.
An important category are made up by procedures, or methods, for handling of families.
Method for evolution
In order to stay ahead of competition today, it is necessary to shorten the lead times needed to introduce new services and service features. To this end TIMe seeks to achieve a requirements oriented mode of systems engineering, where service flexibility and incremental evolution is a key issue. Aspects to consider are:
Modularity in application property models. How to describe services (and other properties) in a modular way so that new services may be added or existing services modified with minimum impact on other services?
Application flexibility. How to structure applications in a modular way so that the impact of an new or changed service is limited, and how to incrementally evolve the application.
Implementation flexibility. How to follow up application increments in the generated implementation code, and how to update existing systems.
For any system family where evolution is an issue, one should try to define guidelines for how to perform evolution.
Method for framework code generation
Once the architecture is defined, much can be gained if the remaining development effort can concentrate on application evolution. That will be possible only if there is a well defined method, supported by automatic tools, for derivation of implementations.
The method needs to consider several issues:
Automatic code generation. How to produce implementation code that fits into the application software environment? How to handle incremental or piecewise generation?
Hand generated code. What are the rules that hand generated code shall follow?
Integration of automatically generated code with hand generated code, foreign code and support code.
How the code shall be divided into modules for ease of generation and handling?
Method for system instantiation
The purpose is to enable cost effective production of system instances that:
satisfy customer requirements;
supports future evolution and maintenance.
This method should define the procedures and the tools that shall be used to generate system instances. Problems to solve are:
how to specify configurations at the various abstraction levels: application, framework, platform;
how to generate or produce the various parts;
how to compose the parts into a system;
how to load and initialise the software.