Difference between revisions of "System Overview Diagram"
| Line 22: | Line 22: | ||
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. | + | 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 == | == Why == | ||
| + | |||
| + | Often the developers "thinks" in isolated "boxes" that has related functionality abstracting the environment that the system-to-be interacts with. 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 tends to immediately to go into "implementation mode", that is to immediately determine how a give functionality can be implemented. | ||
== 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 10:51, 11 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 shows basically the environment that system-to-be should operate within 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 that 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 "thinks" in isolated "boxes" that has related functionality abstracting the environment that the system-to-be interacts with. 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 tends to immediately to go into "implementation mode", that is to immediately determine how a give functionality can be implemented.
Example
An example will be presented later. Please return to this page later.
