The material for this part of the documentation package comes from the view template in Section 10.1 of this book.
Each ECS view is presented as a number of related view packets. A view packet is a small, relatively self-contained bundle of information about the system or a particular part of the system, rendered in the languageelement and relation typesof the view to which it belongs. Two view packets are related to each other as either parent/childbecause one shows a refinement of the information in the otheror as siblingsbecause both are children of another view packet.
This chapter describes the seven-part standard organization that the documentation for view packetsin Volume II of the ECS software architecture documentation packageobeys:
The primary presentation is usually graphical. If so, the presentation will include a key that explains the meaning of every symbol used. The first part of the key identifies the notation: If a defined notation is being used, the key will name it and cite the document that defines it or defines the version of it being used. If the notation is informal, the key will say so and proceed to define the symbology and the meaning, if any, of colors, position, or other information-carrying aspects of the diagram.
Environmental assumptions document what the architect assumes is available in the environment that can be used by the system being designed. They also include assumptions about invariants in the environment. For example, a navigation system architect might make assumptions about the stability of Earth's geographic and/or magnetic poles. Finally, assumptions about the environment may be about the development environment: tool suites available or the skill levels of the implementation teams, for example.
Assumptions about need state why the design provided is sufficient for what's needed. For example, if a navigation system's software interface provides location information in a single geographic frame of reference, the architect is assuming that is sufficient, and that alternative frames of reference are not useful.
 This section will not be filled in for the ECS example package. As discussed in Section 10.2, "other information" will usually include management or configuration control information, change histories, bibliographic references or lists of useful companion documents, mapping to requirements, and the like.
Software Architectures and Documentation
Part I. Software Architecture Viewtypes and Styles
The Module Viewtype
Styles of the Module Viewtype
The Component-and-Connector Viewtype
Styles of the Component-and-Connector Viewtype
The Allocation Viewtype and Styles
Part II. Software Architecture Documentation in Practice
Documenting Software Interfaces
Choosing the Views
Building the Documentation Package
Other Views and Beyond
Rationale, Background, and Design Constraints