328 CHAPTER 13 Modeling Text-Based Requirements matrix. In this example, the requirements properties have been excluded, and only the derive and satisfy relationships have been included. These relationships are discussed later in this chapter. Again, this is an example of a mechanism that a tool vendor might use to construct a view of the model. 13.8 MODELING REQUIREMENT HIERARCHIES IN PACKAGES Requirements can be organized into a package structure. A typical structure may include a top-level package for all requirements in the model. Each nested package within this package may contain requirements from different specifications, such as the system specification, element specifications, and component specifications. Each specification package contains the text-based requirements for that specification. This package structure corresponds to a typical specification tree that is a useful artifact for describing the scope of requirements for a project. An example of a requirements package structure, or specification tree, is shown in the package diagram in Figure 13.10. The containment with the crosshairs symbol at the owning end is used to indicate that the Customer Specification package, the System Specification, and the Camera Specification are contained in the Requirements package. An alternative representation of a speci- fication tree using the requirements diagram and trace relationships is described in Chapter 17, Section 17.3.7. Organizing requirements into packages corresponding to various specifications provides famil- iarity and consistency with document-based approaches and facilitates configuration management of individual specifications at the package level. Also, a specification document or report can be generated directly from the contents of the appropriate package. 13.9 MODELING A REQUIREMENTS CONTAINMENT HIERARCHY Containment is used to represent how a compound requirement can be partitioned into a set of simpler requirements. Containment can be viewed as logically anding (conjunction) of the contained requirements with the container requirement. The partitioning of compound requirements into simpler requirements helps establish full traceability and show how individual requirements are the basis for further derivation, and how they are satisfied and verified. Figure 13.11 shows a requirement diagram with a simple containment hierarchy. The Customer Specification package from Figure 13.10 represents a top-level specification that serves as a container for all other customer-generated requirements. In this example, the Customer Specification package contains two other requirements, as depicted by the crosshairs symbol. Note that instead of using a package, a specification may be modeled as a «requirement» that contains a hierarchy of other requirements, such as shown in Chapter 17, Figure 17.53. A typical specification may contain from hundreds to thousands of individual requirements, but they generally can be organized into a hierarchy that corresponds to the organization of a specification document. Figure 13.12 shows how containment hierarchies can be used to create multiple levels of nested requirements. In this example, the Operating Environment requirement contains two additional requirements for All Weather Operation and 24/7 Operation.