to structured programming′s control structures: "+" can map to a "sequence" of statements (although this is not necessarily so) "[|]" can map to "selection" (conditionals, switch statements) "{}", "()" can map to "iteration" (counting loop, pre-test loop, middle-test loop, post-test loop, and infinite loop) NB. The items defined may be "material" (e.g., room key) as well as "data" (e.g., arrival date-time). Identifying Requirements and Their Reasons The event-response information may be captured in a table. The event is the raison d’être for the response, which gives "traceability" from the response back to the environment. Defining requirements This approach helps the analyst to decompose the system into "mentally bite-sized" mini-systems using events that require a planned response. The level of detail of each response is at the level of "primary use cases". Each planned response may be modelled using DFD notation or as a single use case using use case diagram notation. The basic flow within a process or use case can usually be described in a relatively small number of steps, often fewer than twenty or thirty, possibly using something like "structured English". Ideally, all of the steps would be visible all at once (often a page or less). The intention is to reduce one of the risks associated with short-term memory, namely, forgetting what is not immediately visible ("out of sight, out of mind"). Alternatively, using the notations of structured techniques, an analyst could create a "Nassi–Shneiderman diagram". In the UML, the use case could be modelled using an activity diagram, a sequence diagram, or a communication diagram. This could be problematic if there are many complex scenarios of the use case; the analyst may wish to model all or most of the scenarios. Complexity versus fragmentation If the response is lengthy or complex (i.e., more than a page of text), an analyst may decompose ("factor out" or deduplicate) into smaller "secondary use cases" to keep the "parent" primary use case smaller and simpler. These secondary use cases may prove to be reusable as well. (In a UML use case diagram, they would be drawn as extended or included use cases, which are related to one or more primary use cases.) While describing a use case, an analyst may also uncover "business rules". Some analysts suggest capturing business rules in a separate document using the Object Constraint Language or some other formal notation. Then when a business rule must