Difference between revisions of "System Overview Diagram"
Line 16: | Line 16: | ||
'''Process''' | '''Process''' | ||
− | The Rich Picture | + | The Rich Picture basically shows the environment in which system-to-be should operate and the system-to-be is '''not''' a part of the Rich Picture. |
− | In order to make the first overview of the system-to-be the interfaces | + | In order to make the first overview of the system-to-be, the interfaces which the system needs can be found in the Rich Picture. |
− | From the System Definition the functionality can be determined. | + | From the System Definition, the functionality can be determined. |
Compose a diagram using squares to indicate a block that isolates related functionality. Do '''not''' at all think how the functionality can be implemented. Decisions about how to implement a specific functionality will be made later when considerations about the technical platform are done. | Compose a diagram using squares to indicate a block that isolates related functionality. Do '''not''' at all think how the functionality can be implemented. Decisions about how to implement a specific functionality will be made later when considerations about the technical platform are done. | ||
Line 29: | Line 29: | ||
== Why == | == Why == | ||
− | Often the developers " | + | Often the developers "think" in isolated "boxes" that have related functionality abstracting the environment with which the system-to-be interacts. In software development, these boxes are often called classes. In hardware development, the boxes are block of related components forming an unambiguous function. |
− | In the very early phases of a development project a diagram with boxes can be used to model the system-to-be in overall terms. Early in the development process there is no decision about how the functionality should be implemented, but only that the functionality is needed. Engineers | + | In the very early phases of a development project, a diagram with boxes can be used to model the system-to-be in overall terms. Early in the development process, there is no decision about how the functionality should be implemented, but only that the functionality is needed. Engineers tend to immediately go into "implementation mode", i.e. to immediately determine how a given functionality can be implemented. This is not a recommended way to go, because one tends to overlook obvious or simple solutions or even change the requirements away from what the customer expects, since the developer is locked on a specific solution that is well-known beforehand. |
− | Later in the process the System Overview Diagram will be more detailed and probably split into a hardware block diagram and a class diagram for the software part. But the decision about what should be implemented in hardware and which parts in software should be made on an enlightened base, when all requirements | + | Later in the process, the System Overview Diagram will be more detailed and probably split into a hardware block diagram and a class diagram for the software part. But the decision about what should be implemented in hardware and which parts in software should be made on an enlightened base, when all requirements have been analysed in detail. |
== Example == | == Example == | ||
An example will be presented later. Please return to this page later. | An example will be presented later. Please return to this page later. |
Revision as of 06:49, 24 August 2010
What
A overview in blocks of the system-to-be.
How
The dish
A diagram showing the system at-a-glance.
Ingredients
Process
The Rich Picture basically shows the environment in which system-to-be should operate and the system-to-be is not a part of the Rich Picture.
In order to make the first overview of the system-to-be, the interfaces which the system needs can be found in the Rich Picture.
From the System Definition, the functionality can be determined.
Compose a diagram using squares to indicate a block that isolates related functionality. Do not at all think how the functionality can be implemented. Decisions about how to implement a specific functionality will be made later when considerations about the technical platform are done.
Use simple lines or arrowed lines to indicate connections between the blocks. The arrows can indicate information flow direction. Descriptions or names can indicate the type of information flowing in the connection. Do not consider number of wires, bits or the like at this point.
Why
Often the developers "think" in isolated "boxes" that have related functionality abstracting the environment with which the system-to-be interacts. In software development, these boxes are often called classes. In hardware development, the boxes are block of related components forming an unambiguous function.
In the very early phases of a development project, a diagram with boxes can be used to model the system-to-be in overall terms. Early in the development process, there is no decision about how the functionality should be implemented, but only that the functionality is needed. Engineers tend to immediately go into "implementation mode", i.e. to immediately determine how a given functionality can be implemented. This is not a recommended way to go, because one tends to overlook obvious or simple solutions or even change the requirements away from what the customer expects, since the developer is locked on a specific solution that is well-known beforehand.
Later in the process, the System Overview Diagram will be more detailed and probably split into a hardware block diagram and a class diagram for the software part. But the decision about what should be implemented in hardware and which parts in software should be made on an enlightened base, when all requirements have been analysed in detail.
Example
An example will be presented later. Please return to this page later.