Glossary

Alias The existence of two names in a data dictionary for the same item.

Allocated event-response model An event-response model showing the devices that will be used to implement the response.

Analysis model An abstracted representation of the system being studied. The model may include a set of data flow diagrams, event-response models, data models, data dictionary, and mini specifications.

Association The relationship between entities.

Asynchronous model A model in which the components act independently or in parallel. A data flow diagram is an asynchronous model, as it represents the system as a network of independent processes.

Attribute A data element that describes an entity or a relationship. Each attribute applies to every occurrence of its entity or relationship.

Balancing rule The requirement that the inputs and outputs of a parent diagram match the inputs and outputs of its child diagrams. For data stores, the rule is to show data stores at the highest level where they are used by more than one bubble and at every relevant lower level.

Behavioral model A model that specifies the control and/or behavior of a system. Commonly used to specify the behavior of interfaces between processors. Examples are transaction synchronization models, prototypes, and any type of state transition or synchronization model.

Boundary data flow A data flow that enters or leaves the system context. The term “boundary” is used because it crosses the perimeter of the system.

BASE (brain-aided software engineering) A term coined by our colleague Tim Lister to emphasize the importance of understanding the thinking behind software development before a CASE tool can be successfully used. The focus of this book is on BASE.

Bubble A popular name for process in a data flow diagram.

Business policy The set of rules and data that exist because of the essential purpose of the system; they are independent of the technology used to carry out the rules.

Cardinality The number of entities of each type participating in a relationship.

CASE (computer-aided software engineering) A software tool that automates the diagramming, storage, balancing, and accessing of the system specification.

Child diagram A diagram showing the decomposition of a higher-level process into its component processes, data flows, and data stores.

Context diagram The highest-level diagram of a leveled set of data flow diagrams. It shows the system being studied as a single bubble connected to the outside world by its boundary data flows. This diagram, or more precisely the boundary data flows, defines the domain of the analysis study.

Context of study The system as delimited by the boundary data flows in the context diagram. Sometimes this is shortened to “context.”

CRUD check A way of verifying that every data element within the context is being created, retrieved, updated, or deleted by at least one process; a way of checking that every data element needed by every process within the context of study has been defined. This powerful check leads to the discovery of missing and redundant events, processes, and data, and is an effective assessment of the completeness of the analysis.

Current physical model A model that focuses on how a system is currently implemented. It is a replica of the users’ existing operation; its purpose is to serve as a starting point for the analyst to understand unfamiliar subject matter and to communicate with the users.

Custodial activity An activity whose sole purpose is to maintain the system’s stored data and keep it current. For example, changing a customer’s address is custodial, and is done only so the business can continue to carry out its fundamental activity of sending that customer’s invoices to the correct address.

Custodial processing Processing related to maintaining the system’s essential data.

Data conservation See Rule of Data Conservation.

Data dictionary The collection of definitions of every piece of data used within a context of study; the part of the analysis model that provides definitions of the data flows, data elements, stores, entities, and relationships.

Data element A primitive item of data; one that has a value within the context of study and is not further decomposed.

Data element grouping A name that refers to a collection of data elements and that is defined in the data dictionary. The name might be included as part of many data flows or stores.

Data flow A path that carries packets of information of known composition; a roadway for data. Every data flow’s composition is recorded in the data dictionary.

Data flow diagram A model of the system that shows the system’s processes, the data that flow between them (hence the name), and the data stores used by the processes. The data flow diagram shows the system as a network of processes, and is thought to be the most easily recognized of all the analysis models.

Data model A statement of the business policy showing the essential entities and the relationships between them; it ignores the processing part of the system and focuses only on the information that is essential to the system. Also known as an entity-relationship diagram, Chen diagram, or information model.

Data object See entity.

Data store A time-delayed repository of information.

Decision table A tabular tool for specifying the action that will result from each combination of a set of conditions.

Decision tree A graphic tool for specifying the action that will result from each combination of a set of conditions.

Design The process of defining how a system will be implemented; the objective is to use the available technology to implement the essential requirements so that the implemented system looks as much like the essential system, and hence the problem, as possible.

Detailed analysis A comprehensive inspection and modeling effort to record the details of the system.

Detailed design The activity of deciding how the chosen technology can best be used to make the essential requirements work in the real world. Detailed design includes deciding the software components to make up a computer program, and determining how the people are to interact with the automated system.

Discrete element An element with a strictly limited number of possible values.

Domain of study The part of the business being analyzed. This is synonymous with context of study.

Entity A rational collection of data elements that describes something from the real world of importance to the business. Every entity must have a unique and definable role in the business and must have at least one attribute to describe it. Another name for data object.

Essence The part of the system that is implementation independent; the underlying business policy.

Essential Relating to the “perfect” view of the system, which concerns only the system requirements and excludes anything having to do with how the system is designed or implemented. Sometimes called “logical.”

Essential activity model An event-response model in which all the processes have been consolidated into a single bubble. For the least complex event-responses, this model is the same as the event-response model.

Essential analysis A major extension to structured analysis that focuses on the essential or logical view of analysis; the approach was introduced by the team of McMenamin and Palmer (see the Bibliography).

Essential policy The logic behind the system’s current activities.

Essential requirements The requirements that describe the business being done by the system with no bias toward implementation. They represent the fundamental business of the enterprise. Also known as logical or business policy requirements.

Essential requirements model Usually made up of event-response process models and data models. This model shows only the essential, or logical, requirements.

Essential viewpoint An abstract view of the system, showing only the requirements specific to the subject matter within the context of study and excluding anything that exists because of how the system is designed and implemented.

Event A happening that stimulates a system to respond in a unique fashion; each event produces a unique data flow and has a unique name. Events are of two types: An external event takes place outside the context of study; and a temporal event is stimulated by the arrival of a predetermined time.

Event list A practical tool for inventorying all the events to which the system responds. It contains the event name, along with its associated input and output, for every event that is the concern of a context of study.

Event partitioning A technique for breaking a system into the responses to each of its events. The result is a collection of logical, minimally connected pieces.

Event response The system’s preplanned response to an event, specified using a combination of event-response data and process models. It is a collection of all the actions that respond to the event regardless of where they happen in the current implementation.

Event-response data model A data model containing the entities, relationships, and attributes used, or stored by, one event-response.

Event-response model A model of the system’s reaction to an event containing the event-response process model, event-response data model, data dictionary definitions, and mini specifications.

Event-response process model A data flow diagram showing the processes, flows, and stores involved in one event-response.

Expanded diagram A diagram containing details that are normally shown in a set of low-level diagrams.

External design The design of the interfaces between the different processors in a system environment.

External event See event.

False data store A data store that is part of the current system for some reason connected to the implementation.

Foreign key One or more attributes that are included in one entity for the purpose of identifying another.

Functional partitioning A way of modeling the system so that similar processes are grouped together in such a way that the interfaces between them are minimal. This is often similar to logical partitioning.

Functional primitive A process that will not be further decomposed, because it is small enough to be specified in a one-page specification.

Function model See process model.

Fundamental activity This is an activity that is part of the reason for the systems existence, such as selling goods, monitoring traffic, and so on.

Fundamental processing Processing related to one of the system’s primary business activities.

Head-sized piece The portion of a system that fits comfortably inside an analyst’s head and is thus readily understood; it is a functional primitive and is described by a mini specification.

Implementation The activity of making the essential requirements work in the real world.

Implementation engine See processor.

Implementation model The highest-level blueprint for the construction of the system. Part of the new physical model, it summarizes the interprocessor interfaces for all the system events; it serves as a project management tool.

Instance One occurrence of something that has many occurrences, such as entities or objects. For example, April 4 is one instance of the BREAKCHART DAY entity.

Interface The connection between two components of a system. Analysis is concerned with the data content of an interface, and design is concerned with the behavior and appearance of the interface.

Internal design The design of the processes and interfaces within a processor in the system environment.

Key field The unique identifier of an entity or data store.

Leveling A technique for decomposing a system and modeling it at various levels of detail.

Logical See essential.

Logical partitioning A procedure for showing the system broken down into units that relate to the essential requirements of the system, and not simply to mirror the current situation.

Maxi specification A specification written for a process that is not a functional primitive.

Mini specification An analysis tool, named for its manageable size, for describing the policy to be carried out by a functional primitive, which can usually be described in a page or less. Also called a process specification, P-spec, function spec, or transformation spec; describes a single, discrete functional component of the system.

Model A miniature representation of chosen aspects of a system.

Narrow interface An interface in which only a small amount of data connects one process to another; functional processes have narrow interfaces.

New physical model A model used to illustrate, negotiate, and define the implementation of the new system. The model shows computers, humans, and machines; it also illustrates the physical details of interfaces. Also referred to as the new implementation environment or the preliminary design model.

New requirement A requirement that is outside the declared context of study.

Object An encapsulation of data and the processes that operate on the data.

Object-oriented design The craft of partitioning the system into objects, organizing the objects into class hierarchies, and devising messages that communicate between the objects. See the Bibliography for references on this subject.

Parent diagram A high-level summary of several detailed models.

Participation Participation rules are attached to relationships. They specify whether every instance of a connected entity has mandatory or optional participation in that relationship.

Partitioning Breaking a system into manageable and, finally, specifiable pieces.

Partitioning theme A way of breaking down the system. Current physical models typically use the existing processors and data flows as their theme. Essential models use events and logical data as their partitioning theme.

Perfect requirements Another name for essential requirements.

Perfect technology A concept proposed by McMenamin and Palmer as a way of seeing past the current implementation.

Physical A term used to refer to models that portray the implementation features of a system. Such features are “physical” because you can touch the devices, as opposed to the “essential” processes and data, which are conceptual in nature.

Preliminary design The process of defining the implementation interfaces. Doing enough of the external and internal design to reveal the design tasks and the interfaces between them.

Problem space See context of study.

Procedural Concerned with the sequence of actions used to carry out a task.

Process A system component that transforms input data into output data according to defined business policy.

Process model A model showing the processes carried out by a system and the data interfaces between those processes; same as a data flow model.

Processor Any person, job, department, organization, mechanical tool, or computer capable of implementing an essential requirement; also referred to as an implementation engine.

Process specification See mini specification.

Prototype A simulation, usually automated, of the computer system to be implemented.

Real requirements See essential requirements.

Relationship The association of two or more entities; through this association, it expresses the business policy of the data model.

Repeating group A collection of data items that occur more than once.

Repetition A structured programming construct that states that an action will be repeated whenever a condition is true.

Risk management A policy of determining the greatest potential failure associated with a project.

Rule of Data Conservation The rule that each system component must receive data that are both necessary and sufficient to produce its output.

Selection A structured programming construct whereby the control flow is diverted according to the results of a choice. This is implemented in most programming languages, and in structured language for mini specifications, as an IF statement.

Sequence This means the statements of a mini specification are read from top to bottom with each statement following the previous one.

Spiral development A systems development strategy that breaks a project into a number of subprojects whose size can range from a subsystem to an event. The systems development tasks within and between pieces overlap depending on the constraints of the particular project.

Structured analysis A system of analysis, popularized by Tom DeMarco and others, whereby the system is analyzed by building data flow models of it. This book proposes an analysis technique that is a progression beyond structured analysis.

Structured design A set of tools, concepts, and strategies involving hierarchical partitioning in a top-down manner, using coupling and cohesion analysis to refine the design.

Structured language A subset of natural language, used for writing mini specifications and restricted to a few verbs that manipulate the data items in the data dictionary. The language follows the same rules for combining statements as does structured programming.

Structured programming The convention, first proposed by the Italians Böhm and Jacopini, that computer programs are written using only selection and repetition to join the statements. This is commonly, and somewhat incorrectly, known as “goto-less” programming.

Subtype An entity that has its own unique characteristics and also shares the characteristics of its supertype entity.

Supertype A generalized entity; its business role and its attributes are common to all the subtypes.

Synchronization model See behavioral model.

System data model A data model showing all the entities and relationships within a context of study.

System environment The processing, data carrying, and data storage technology that is available for the implementation of a system.

System environment model A formal specification of the technology that is available to implement the system.

Systems analysis The craft of understanding and specifying systems by building models of them.

System scope See context of study.

Temporal event See event.

Terminating data store A data store that is owned by another system and so acts as a terminator.

Terminator A person, place, or system that is connected to the context via one or more boundary data flows. A terminator is considered outside the context of study; the systems analyst is only interested in the terminator as a provider or receiver of the boundary data flows.

Top-down approach A technique that first produces an overview before the analyst models the details.

Transaction synchronization model A model that shows the interaction between two processors during a defined time period. Typically used for defining the processing, screens, and control sequence across a human-machine boundary.

Trivial reject A data flow that shows rejected data leaving the system.

User knowledge Information held by the user or users about the business purpose and rules of the system.

Viewpoint A way of focusing on a system that highlights the characteristics germane to a particular viewpoint. The four viewpoints of use to systems analysts are current physical, essential, data, and new physical.

Waterfall model A systems development methodology that dictates the completion of one activity before beginning the next.

Working model A model that demonstrates that each process in the data flow diagram can manufacture its outputs from its inputs, and each entity and relationship in the data model can supply or store the data needed by all the processes.