The system family statement is a concise description of the system family with emphasis on specifications, 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:
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.
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.
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.
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.
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.
The family statement will be expressed in prose, supplemented by figures.
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.
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.
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.
The activity may be subdivided according to the topics of a 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.
The system family dictionary is organised in the same way as the Domain dictionary. 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:
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.
The domain given terminology used in families shall be the same as in the domain dictionary.
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).
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.
Ensure that the relationships with the other family descriptions are maintained. See System family dictionary relationships.
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.
The family dictionary is made for the first time as part of the first requirements analysis, see: Making requirements.
The first family dictionary comes from the System family statement, the System studies and the 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?
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.
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.
Figure 20 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.
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.
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.
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.
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:
For any system family where evolution is an issue, one should try to define guidelines for how to perform evolution.
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:
How the code shall be divided into modules for ease of generation and handling?
The purpose is to enable cost effective production of system instances that:
This method should define the procedures and the tools that shall be used to generate system instances. Problems to solve are:
how to load and initialise the software.