A-C | D-L | M-Q | R | S | T-Z

database design specification -- A document that describes the content and format of the permanent or semi permanent data necessary for the software to carry out its functions. 

data-structure-oriented design -- A design methodology used for business applications by basing the design on the logical data structures of the program specification.  Examples include the Jackson System Design and Warnier-Orr methods. 

DDR – Acronym to detailed design review. 

derived requirement -- In system/software system engineering (requirements), a lower level requirements that is determined to be necessary for a top-level requirement to be met.

design -- (1).  The process of defining the software architecture, components, modules, interfaces, and data for a software system to satisfy specified requirements.  (2). The results of the design process. 

design analysis -- (1).  The evaluation of a design to determine correctness with respect to stated requirements, conformance to design standards, system efficiency, and other criteria.  (2). The evaluation of alternative design approaches.  [ANSI/IEEE Std 830-1984]

design analyzer -- An automated design tool that accepts information about a program’s design and produces such outputs as module hierarchy diagrams, graphical representations of control and data structure, and lists of accessed data blocks. 

design concept -- A fundamental idea that can be applied to designing a system (for example, information hiding).  

design constraint -- Any requirement that affects or constrains the design of a software system or software system component (for example, physical requirements, performance requirements, software development standards, software quality assurance standards).  [ANSI/IEEE Std 610.12-1990]

design constraint (requirements) – (1).  A software requirement that affects or constrains the design of a software system or software system component.  Examples of design constraints are physical requirements, performance requirements, software development standards, and software quality assurance (SQA) standards.  

design entity -- A part of a design that is structurally, functionally, or otherwise distinct from other elements or that plays a different role relative to other design entities.  Each design entity is separately named and referenced.  Also called a design element.

design fault -- A design defect that results from a (human) error during system design that may or may not result in a design failure.

design inspection -- A static analysis technique that relies on visual examination of development products to detect errors, standards violations, and other problems.  [IEEE Std 610.12-1990]  Similar to design walkthroughs. 

design language -- A standardized notation, modeling technique, or other representation scheme and its usage conventions, shown to be effective in representing and communicating design information.

design level -- The design decomposition of the software item (for example, system, subsystem, program, or module).  [IEEE Std 610.12-1990]

design methodology -- A systematic approach to creating a design consisting of the ordered application of a specific collection of tools, techniques, and guidelines.

design pattern -- A description of the problem and the essence of its solution to enable the solution to be reused in different settings; not a detailed specification, but a description of accumulated wisdom and experience.

design phase -- The period in the software life cycle during which definitions for architecture, software components, interfaces, and data are created, documented, and verified to satisfy requirements.

design review -- Types include software architectural design review, software detailed design review, and system design review.  [ANSI/IEEE Std 610.12 1990]  Contrast with -- code review; formal qualification review; requirements review; test readiness review. 

design strategies -- An overall plan and direction for performing design (for example, functional decomposition).

design view -- A subset of design entity attributes that are specifically suited to the needs of a particular, participant, or stakeholder.  [IEEE Std 610.12-1990]

design-to-cost -- An approach to managing a system/software project to hold the project to a predetermined cost.  Actual and projected costs are closely tracked, and actions such as deleting or postponing lower-priority requirements are taken if costs threaten to exceed targets.  Also called cost as an independent variable (CAIV).

detailed design -- (1).  The process of refining and expanding software architectural designs to more detailed descriptions of the processing logic, data structures, and data definitions.  This continues until the design is sufficiently complete to be implemented.  (2). The result of the detailed design process.  Also called design, low-level design, module design, and program design.  [ANSI/IEEE Std 610.12-1990]

detailed design description -- A document that describes the exact detailed configuration of a computer program.  It identifies the input, output, control logic, algorithms, and data structure of each individual low-level component of the software product and is the primary product of the detailed design phase.  Also called detailed design specification.

detailed design phase --The software development lifecycle phase during which the detailed design process takes place, using the software system design and software architecture from the previous phase (architectural design) to produce the detailed logic for each unit such that it is ready for coding.  Also called detailed design stage

detailed design review (DDR) -- A meeting at which a system, hardware, or software design is presented to project personnel, managers, users, customers, or other interested parties for comment or approval.  The purpose of this review is to -- (1) Determine that the detail design of the configuration item under review satisfies the design requirements established in the architectural design specifications.  (2) Establish the exact interface relationships between the

developer --In an engineering project, the organizations that actually analyzes, design, codes, and tests the delivered system.  [IEEE/EIA 12207-1997]

discounted payback period -- The basis for comparison that represents the value of a cash-flow stream in terms of the time it will take (including interest) to recover the proposal’s initial investment.  It indicates exposure to risk.  If the proposal is cancelled before it reaches its payback period, the organization will, by definition, have lost money.  [steve.tockey@construx.com]

discounted payback period -- The basis for comparison that represents the value of a cash-flow stream in terms of the time it will take (including interest) to recover the proposal’s initial investment.  It indicates exposure to risk.  If the proposal is cancelled before it reaches its payback period, the organization will, by definition, have lost money.  [steve.tockey@construx.com]

document control -- The application of configuration management to the control of documents.

economic life -- A kind of optimization analysis that optimizes an asset’s costs of ownership based on the length of time the asset is kept.  Also called minimum cost life or economic replacement interval.  [steve.tockey@construx.com]

emergence maintenance --Unscheduled corrective maintenance performed to keep a system operational.  [IEEE-STD-P1219 1992]

engineering change -- An alteration in the configuration of a hardware/software configuration item or items, delivered, to be delivered, or under development, after formal establishment of its configuration identification.  See also engineering change proposal.  

engineering change proposal (ECP) -- A proposed engineering change and the documentation by which the change is described and suggested.  [ANSI/IEEE Std 610.12 1990]

event --A scheduled, zero duration, and activity used to measure progress, the initiation or completion of an activity or task, or a significant happening such a milestone review.

executable requirements specification – (1).  A software requirement specification that is represented in an executable requirements language. 

expandability -- The degree of effort required to improve or modify the efficiency of software functions.  [Fenton & Pfleeger, 1997]. 

extend -- In UML, a relationship from an extending use case to a base use case specifying how the behavior defined for the extending use case can be optionally inserted into the behavior defined for the base use case.  [geri@wyyzzk.com]

external -- An input information source or output information destination that is outside the scope of this standard and, therefore, may or may not exist.  [IEEE Stds Glossary]

external interface requirement -- A system/software requirement that specifies a hardware, software, or database element with which a system/software system or system/software component must interface, or that sets forth constraints on formats, timing, or other factors caused by such an interface.  

FCA -- Acronym for functional configuration audit. 

formal design -- The process of using a formal method for software design.

formal qualification review (FQR) -- The test, inspection, or analytical process by which a group of configuration items comprising a system are verified to have met specific contractual performance requirements.  Contrast with -- code review; design review; requirements review; test readiness review.  [ANSI/IEEE Std 610.12 1990]

formal requirements language -- An artificial language used to represent a software requirement.  The resulting formal requirements can be proven "correct" through proof-of-correctness methods.  Also known as verifiable requirements language.

FQR – Acronym for formal qualification review.

FR -- Acronym for feasibility report.  [IEEE Stds Glossary]

framework -- A partially completed software subsystem that can be extended by appropriately instantiating some specific plug-ins.

functional audit -- An audit that is held prior to software delivery in order to verify that all requirements specified in the software requirements document have been met.  See functional configuration audit.

functional baseline -- The initial configuration established at the end of the requirements definition phase. 

functional configuration audit (FCA) -- The formal examination of functional characteristics from test data for a hardware/software configuration item, prior to acceptance, to verify that the item has achieved the performance specified in its functional or allocated requirements.  [U.S. Department of Defense (DoD) usage]  [Military Standard 1521B-1985]  See also formal qualification review (FQR).  (2) An audit of functional characteristics test data for a configuration item, prior to acceptance, to verify that the item has achieved the performance specified in its functional or allocated configuration identification.

functional requirement -- A system/software requirement that specifies a function that a system/software system or system/software component must be capable of performing.  These are software requirements that define behavior of the system, that is, the fundamental process or transformation that software and hardware components of the system perform on inputs to produce outputs.  Contrast with nonfunctional requirement.  

function-oriented design -- The partitioning of a design into subsystems and modules, with each one handling one or more functions.  Contrast with object-oriented design, data-structure-oriented design.

hardware configuration item (HCI) -- A hardware entity that has been established as a configuration item.  The hardware configuration item exists where functional allocations have been made which clearly delineate the separation between equipment functions and software functions and the hardware has been established as a configuration item.  Contrast with software configuration item (SCI). 

hazard -- A source of potential harm or a situation with a potential for harm in terms of human injury, damage to health, property, or the environment, or some combination of these.  [IEEE Stds Glossary]

hazard analysis -- A systematic qualitative or quantitative evaluation of software for undesirable outcomes resulting from the development or operation of a system.  These outcomes may include injury, illness, death, mission failure, economic loss, property loss, environmental loss, or adverse social impact.  This evaluation may include screening or analysis methods to categorize, eliminate, reduce, or mitigate hazards.  [IEEE Stds Glossary]

hazard identification -- The process of recognizing that a hazard exists and defining its characteristics.  [IEEE Stds Glossary]

I/O -- Acronym for input/output.  [IEEE Stds Glossary]

IDD -- Acronyms for interface design document.  See also interface design document (IDD).  [IEEE Stds Glossary]

IEC -- Acronyms for International Electrotechnical Commission.  [IEEE Stds Glossary]

Impact analysis — Identifies all system and software products affected by a change request and develops an estimate of the resources needed to accomplish the change.  This includes (1) determining the scope of the changes in order to plan and implement work, (2) developing an accurate estimate of resources need to perform the work, and (3) analyzing the cost and/or benefits of the requested changes

include -- In UML, a relationship from a base use case to an included use case specifying how the behavior defined for the included use case can be inserted into the behavior defined for the base use case.  [geri@wyyzzk.com]

independent audit – See audit.

independent verification and validation (IV&V) -- V&V processes performed by an organization with a specified degree of technical, managerial, and financial independence from the development organization.  [IEEE Stds Glossary]

Infrastructure --The internal structure of an activity or process, to include hardware, software, tools, techniques, standards, and facilities needed for development, operation, or maintenance of the activity or process.  [IEEE/EIA Standard 12207-1997]

inspections -- A type of peer review which involves a group of the developers peers checking some product documents (e.g. design documents, code listings, test plans, etc.) at specific points in the development process in order to find any errors in the product.  Inspections are credited to Michael Fagan of IBM in 1976.

inspector -- In an inspection or walkthrough, the inspection team members identify and describe anomalies in the software product.  Inspectors should be chosen to represent different viewpoints at the meeting (for example, sponsor, requirements, design, code, safety, test, independent test, project management, quality management, and hardware engineering).  Only those viewpoints pertinent to the inspection of the product should be present.  Note that the author’s manager cannot attend the review.  [IEEE Std 1028-1997] 

instance -- The mapping of an activity that processes all of its input information and generates all of its output information.  Contrast with invocation; iteration.  See also mapping.  [IEEE Stds Glossary]

integral activity group -- An activity group that is needed to complete project activities, but is outside the management and development activity groups.  [IEEE Stds Glossary]

integration testing -- An orderly progression of testing of incremental pieces of the software program in which software elements, hardware elements, or both are combined and tested until the entire system has been integrated to show compliance with the program design, and capabilities and requirements of the system.  [IEEE Stds Glossary]

integrity level -- A denotation of a range of values of a property of an item necessary to maintain system risks within acceptable limits.  For items that perform mitigating functions, the property is the reliability with which the item must perform the mitigating function.  For items whose failure can lead to a threat, the property is the limit on the frequency of that failure.  [IEEE Stds Glossary]

interest -- Literally, a fee for renting money.  Someone who borrows money from another is usually obligated to return the original amount borrowed plus some additional money.  That additional money is the interest.  The interest rate is a measure of the rental fee for money in terms of a percentage over some period.  At 10 percent interest for a year, someone who borrows $100 is obligated to pay $110 back at the end of one year.  [steve.tockey@construx.com]

interface control -- The process of (1) identifying all functional and physical characteristics relevant to the interfacing of two or more configuration items provided by one or more organizations, and (2) ensuring that proposed changes to these characteristics are evaluated and approved prior to implementation.

interface design document (IDD) -- Documentation that describes the architecture and design of interfaces between system and components.  These descriptions include control algorithms, protocols, data contents and formats, and performance.  [IEEE Stds Glossary]

interface requirement specification (IRS) -- Documentation that specifies requirements for interfaces between systems or components.  These requirements include constraints on formats and timing.  [IEEE Stds Glossary]

internal rate of return (IRR) -- The basis for comparison that represents the value of a cash-flow stream in terms of a compound interest rate over the planning horizon.  [steve.tockey@construx.com]

interoperability testing -- Testing conducted to ensure that a modified system retains the capability of exchanging information with systems of different types, and of using that information.  [IEEE Stds Glossary]

inverse engineering -- In software engineering (maintenance), the process of obtaining high-level representation of the software from the source code.  Inverse engineering provides a more abstract view of the system with the intent of recapturing design and requirements information.  [British view]  [Robson, J. Systems and Software, 1991]

investigative audit --See audit.  

invocation -- The mapping of a parallel initiation of activities of an integral activity group that perform a distinct function and return to the initiating activity.  Contrast with instance; iteration.  See also mapping.  [IEEE Stds Glossary]

IOS -- Acronyms for International Organization for Standardization.  [IEEE Stds Glossary]

IRS -- Acronyms for interface requirements specification.  See also interface requirements specification (IRS).  [IEEE Stds Glossary]

iteration -- The mapping of any execution of an activity where at least some input information is processed and some output information is created.  One or more iterations comprise an instance.  Contrast with instance; invocation.  See also mapping.  [IEEE Stds Glossary]

Jackson Structured Design Method (JSD) -- A structured software development methodology for the analysis and design of both data processing and real-time systems developed by Michael Jackson Systems.

joint acquirer-supplier review – Similar or identical to joint reviews [IEEE/EIA Standard 12207.0-1997]. 

Joint review -- A review process for evaluating the status and products of an activity of a project as appropriate.  It is frequently a mechanism for determining project status at the completion of a major software development milestone.  The reviews are normally conducted jointly between acquirer of the system that represent the user, and the supplier that represents the software developer.  Joint acquirer-developer reviews are usually thought of as visibility and status mechanisms; however, the gate-keeping and action item aspects of joint acquirer-developer reviews are also powerful control mechanisms

LC -- Acronym for linear circuit.  [IEEE Stds Glossary]