Mirel  describes complex systems as those used to help structure and solve ill-structured problems. She defines the domains and tasks that give rise to complex systems development as characterized by some core attributes including:
−Indeterminacy of both task goals and criteria for task completion
−Requiring higher order cognitive skill and integrating knowledge from different areas
−Requiring advanced learning and instruction for effective performance Design for systems created to meet these challenges is correspondingly complex. The indeterminacy of task goals requires the design of flexible systems that rely on abstract software components. The higher the level of abstraction from a particular behavioral or structural requirement, the more difficult it becomes for developers and end users to reconstruct this process of abstraction later, and thereby relate the abstraction to the design delib-erations, or rationale, that gave rise to it . The integration of different knowledge in design and use, and the assumption of variable cognitive skills on the part of end users introduce additional complexity to the task of understanding how a particular system form emerges from a particular set of requirements. That these systems require advanced learning on the part of their users raises questions about where they obtain the information needed to facilitate this learning.
Today, many routine computing tasks are supported by high-functionality applications (HFAs, ), which typically include hundreds or even thousands of features and are used to manage large volumes of heterogeneous information. Each feature of such a system may be realized by a number of complexly interacting software components . Intra- and inter-component interactions, as well as the distributed, intersystem inter-actions that increasingly define the modern computing milieu, make comprehending these systems difficult because of the cognitive load introduced when attempting to comprehend their structure and functionality.
The nature of complex systems suggests that the kinds of explanations required to convey understanding go beyond relatively simple, descriptive knowledge to include how and, especially, why a design assumes a particular structure and set of behaviors. Explanation requests, compared to, say, requests for instructions, are usually concerned with acquiring some deep knowledge of the event or entity in question. Explanations are provided in response to why questions that appeal to the causal chain that resulted in occurrence of the event or existence of the entity. In the design context, this causal chain can potentially include a large, heterogeneous network of factors and influences that combine to inform the design decisions being made, in other words, the DR. For example, the second of the three development cases reported later in the chapter involved selection and implementation off certain decision-theoretic tools to support antiterrorism planning. The rationale for why a particular set of tools was selected, and how important domain concepts were translated into working software has proven to be of considerable interest to project stakeholders.