A major benefit of good software engineering practices is the improvement in communication that results at all levels – development to user organizations, project management to team members, requirements engineers to designers, designers to coders, coders to the machine, and quality assurance to developers and users alike. While much of this communication happens through tools, databases, and graphical representations, most of it occurs through the spoken and written word. And so, to expand the precision of our primary mode of communication, terms and phrases must be precisely defined and universally understood. It’s for that purpose that this glossary was created. The subset of the Software Engineering glossary provided below deals with the requirements domain. In future issues, you will find the other subsets interspersed among the pages of IEEE Software. Each definition, unless defined by the editor, identifies a reference source.

Reference sources that are clearly IEEE Software Engineering Standards can be found at http://standards.ieee.org/catalog/olis/se.html.


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


Glossary of Terms

abstract design -- (1)  A generic form that needs specialization (further design work) to produce concrete designs.  (2) Design aimed at producing designs; for example, design patterns.

acceptance testing --Testing conducted in an operational environment to determine whether a system satisfies its acceptance criteria (e.g., initial requirements and current needs of its user) and to enable the customer to determine whether to accept the system.  [IEEE Stds Glossary]

acquirer -- The individual or organization that specifies requirements for and accepts delivery of a new or modified software product and its documentation.  The acquirer may be internal or external to the supplier organization.  [IEEE/EIA Standard 12207-1997]  Acquisition of a software product may involve, but does not necessarily require, a legal contract or a financial transaction between acquirer and supplier.  [IEEE Standard 1058-1998]

action items -- An action item is the product of a review, which will define problems that were discovered during the review.  An action item defines the work to be accomplished, the responsible parties, and the response dates.  Action items must be tracked to closure. 

activity -- In project management, (1) A major unit of work to be completed in achieving the objectives of a software project.  An activity has precise starting and ending dates, incorporates a set of tasks to be completed, consumes resources, and results in work products.  An activity may contain tasks or other activities in a hierarchical manner.  [IEEE Standard 1058-1998]  (2) A defined work that is part of a process lifecycle phase.

activity group -- A set of related activities.  See also activity.  [IEEE Stds Glossary]

activity list -- In project management, a list of project activities that provide the name of the activity, the predecessor activities, and the estimated duration of the activity.

activity network -- In project management, a network graph using nodes with interconnecting edges to represent tasks and their planned sequence of completion, interdependence, and interrelationships that must be accomplished to reach the project goals.  Examples of an activity network are critical path method (CPM) and PERT chart.

actor -- In UML, someone or something outside the system that interacts with the system.  [geri@wyyzzk.com]

adaptive maintenance -- Modification of a software product performed after delivery to keep a computer program usable in a changed or changing environment.  [IEEE Stds Glossary]

ADR – Acronym for architectural design review.

allocation of tasks -- In project management, the assignment or distribution of tasks among functions, people, or processes.

alternate flow -- The part of a use case that describes its alternative implementations.  It is also used to describe error conditions, since errors can be considered a kind of alternative.  Also called alternate path.  [geri@wyyzzk.com]

annual performance review -- A management appraisal of an employee given annually. 

anomaly -- Any condition that deviates from the expected based on requirements, specifications, design, documents, user documents, standards, etc., or from someone’s perceptions or experiences.  Anomalies may be found during, but not limited to, the review, test, analysis, compilation, or use of software products or applicable documentation.  [IEEE Stds Glossary]

architectural design -- In system/software system engineering, (1) The process of defining a collection of hardware and software components and their interfaces to establish a framework for developing a system/ software system.  (2) The result of the architectural design process.  Also called high-level design, internal specification, preliminary design, system design, and top-level design.  [ANSI/ IEEE Std 610.12-1990]

architectural design phase -- The lifecycle phase in which a system’s general architecture is developed, thereby fulfilling the requirements laid down by the software requirements document and detailing the implementation plan in response to it. 

architectural design review -- A joint acquirer-supplier review to evaluate the technical adequacies of the software architectural design as depicted in the software design descriptions.  Sometimes synonymous with preliminary design review.

architectural structure -- A physical or logical layout of the components of a system design and their internal and external connections.  Examples are function-oriented (structured) design, object-oriented design, and data structure- oriented design. 

architectural style -- (1)  Defines a family of systems in terms of a pattern of structural organization.  Commonly used styles include pipes and filters, layers, rule-based systems, and blackboards.  (2) Characterizes a family of systems that are related by sharing structural and semantic properties.  architectural view.  A representation of a whole system from the perspective of a related set of concerns.  [IEEE Std 1471-2000]

architectural viewpoint -- (1)  A specification of the conventions for constructing and using a view.  (2) A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.  [IEEE Std 1471-2000]

asset -- Informally, anything of value that the company owns or is owed by others—for example, cash, accounts receivable, or equipment.  More formally, the term often refers to an item of value that is subject to depreciation accounting.  [steve.tockey@construx.com]

association -- In UML, a relationship between an actor and a use case that indicates that the actor interacts with the system by means of the use case.  [geri@wyyzzk.com]

assumption --In project management, a presumed truth for which the manager is unable or unwilling to verify its truthfulness.

audit -- An independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria.  It differs from a review in that it is more narrowly focused than a review and has a short-term goal identifying problems or resolving issues.

audit team -- An experienced group (team) of engineers and applications experts who audit a hardware/software engineering project to identify problems and initiate corrective action.  See also audit.  

author -- In an inspection or walkthrough, the individual this is responsible for the software product meeting its inspection criteria, for contributing to the inspection based on special understanding of the software product, and for performing any rework required.  [IEEE Std 1028-1997]

authority -- In management: (1) The legal or delegated right to give directions to subordinates and to command resources.  (2) The discretion given an employee or incumbent of an organizational position to use their judgment in decision-making.  (3) The right to use resources and make decisions in such a way that organizational objectives are set and achieved

baseline -- (1) A description of a system and its components (configuration items) at a particular period of time, and any approved updates to the baseline.  (2) A work product that has been placed under formal configuration management.  A baseline should be changed only through formal configuration management procedures.  Some baselines may be project deliverables while others provide the basis for further work.  See also work product.

baseline design -- A system design that has been agreed on by all stakeholders interested in the system development. 

baseline document -- A system/software document that defines a work product that has been place under configuration management.  Examples are system specifications, requirements specifications, and design specifications.  

baseline management review -- See milestone review, review.  

baseline review -- See milestone review, review.  

basic flow -- The part of a use case that describes its most common implementation.  The basic flow is written assuming that no errors or alternatives exist.  Also called basic path or happy day scenario [geri@wyyzzk.com]

benefit-cost analysis -- In not-for-profit decision analysis, this method bases the desirability of an alternative on the ratio of the net benefits to the population (measurable benefits minus measurable “dis-benefits”) divided by net costs to the sponsor (measurable costs minus measurable cost savings).  [steve.tockey@construx.com]

bond -- A form of investment that behaves like an interest only loan.  The investor buys the bond for some amount, receives interest-only payments over time, and then receives the initial investment plus the final interest installment at the end of the term.  Bonds are a typical means for government units to raise needed capital.  Revenue bonds are secured by future revenue generated from the activity being funded, whereas general obligation bonds are secured by the issuing entity’s ability to tax.  [steve.tockey@construx.com]

bottom-up cost-estimation model (method) -- Each component of the software is estimated separately and the results aggregated to produce an estimate for the overall project.

bottom-up design -- The process of designing a system by identifying low-level components, designing each component separately, and then designing a structure to integrate the low-level components into larger and larger subsystems until the design is finished. 

break-even analysis -- An analysis technique that analyzes two or more objective functions (cost functions or revenue functions) to find where, if at all, they have the same value.  [steve.tockey@construx.com]

budget review -- A formal meeting at which the monetary expenditures for a system/software engineering project are presented to the user, customer, or other interested parties for comment and approval.  The monetary expenditures are compared to the budget, and differences between the budget estimates and actual project expenditures are explained.  

build -- An operational version of a software product incorporating a specified subset of the capabilities that the final product will include.  Sometimes synonymous with version.

capital -- Money that is, or can be, used for making more money.  [steve.tockey@construx.com]

capital gains -- Passive increases in the value of a capital asset.  The term “passive” means that the change in value is due not to the owner’s active involvement but to other, external reasons.  If a person buys a plot of land and the value increases, say, because of development in that area, the difference between the current value and the original basis cost (what it cost the owner to acquire the asset) is considered a capital gain.  [steve.tockey@construx.com]

CARE -- Acronym for computer-assisted re-engineering.  [IEEE Stds Glossary]

CASE -- Acronym for computer-aided software engineering.  [IEEE Stds Glossary]

cash-flow statement -- One of the main financial statements, it shows how the company is paying for its current operations and future growth by detailing the actual flow of cash between the company and the outside.  It answers the question, “How much more or less cash does the company have now than it did before?”  [steve.tockey@construx.com]

CCB -- Acronym for configuration control board.

CDR –Acronym for critical design review.

CI – Acronym for configuration item.

CM -- Acronym for configuration management.

code audit -- An independent review of source code by a person, team, or tool to verify compliance with software design documentation and programming standards.  Correctness and efficiency may also be evaluated.  See also audit, inspection, walkthrough. 

cohesion -- In software design, a measure of the strength of association of the elements within a module.  Contrast with coupling

component testing -- Testing conducted to verify the correct implementation of the design and compliance with program requirements for one software element (e.g. unit, module) or a collection of software elements.  [IEEE Stds Glossary]

compound interest -- The form of interest calculation that adds unpaid interest to the loan principal.  [steve.tockey@construx.com]

computer-aided design -- The use of a computer to design a device or a system, display it on a computer monitor or printer, simulate its operation, and provide statistics on its performance.  The computer is provided with data concerning the item to be designed, how it is to function, and the rules for the way in which the different components can be joined. 

concept of operations (ConOps) document -- (1)  A user-oriented document, which describes the system characteristics from an end users' viewpoint.  The document is used to coordinate overall quantitative and non-quantitative system goals for the user, buyer, developer, and other interfacing organizations (e.g., training, facilities, staffing, and maintenance elements).  It describes the user organizations and mission from an integrated system point of view.  [IEEE-STD 1362-1998]  The ConOps document is a place to record non-quantitative systems requirements (also called design goals).  (2) A tool used in the elicitation of software requirements.  Also called operational concept document (OCD) [U.S. military]. 

concept of operations analysis -- The derivation and documentation of a system concept through the application of analysis.  See also software requirements analysis.  [IEEE-STD 1362-1998]

conciseness -- Those attributes of the software that provide implementation of a function with a minimum amount of code.  [McCall, Richards, and Walters, RADC, 1977]

configuration -- (1) The arrangement of a system or network as defined by the nature, number, and chief characteristics of its functional units.  More specifically, the term configuration may refer to a hardware configuration or a software configuration.  (2) The requirements, design, and implementation that define a particular version of a system or system component.  (3) The functional and/or physical characteristics of hardware/software as set forth in technical documentation and achieved in a product.  [Military Std 480B-1988]

configuration control -- An element of configuration management consisting of the evaluation, coordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification.  [IEEE Std 610.12-1990]  Sometimes erroneously used for configuration management (CM).

configuration control board (CCB) -- The authority responsible for evaluating, approving, and/or disapproving proposed engineering changes to hardware/software configurations.  This board should also insure the implementation of the approved changes.  [ANSI/IEEE Std 610.12-1990]  See also configuration management (CM), engineering change proposal. 

configuration item (CI) -- An aggregation of hardware, software, or both that is designated for configuration management and treated as a single entity in the configuration management process.  [ANSI/IEEE Std 610.12 1990]

configuration management (CM) -- A discipline applying technical and administrative direc­tion and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.  [IEEE Std 610.12-1990]

configuration management system -- The discipline of identifying the components of a continually evolving system for controlling changes to those components and maintaining integrity and traceability throughout the lifecycle.

consistency -- Those attributes of the software that provide uniform design and implementation techniques and notations.  [McCall, Richards, and Walters, RADC, 1977]

constraint -- A semantic condition or restriction that describes a limitation or state.  For example, a constraint might be a limitation on some data’s range of values or on some behavior of the application, or it could be a description of a required state of the system at a particular point in time.  [geri@wyyzzk.com]

contingency plan -- A plan for dealing with a risk factor, should it become a problem.  [d.fairley@computer.org]

continuous risk management -- The process of analyzing the progress of a planned activity, project, or program on a periodic, ongoing basis and handling identified risk factors; includes developing options and fallback positions to permit alternative solutions to reduce the impact if a risk factor becomes a problem.  [d.fairley@computer.org]

contractor -- In an engineering project, see supplier.  [IEEE/EIA 12207-1997]

control point (project control point) -- A project agreed on point in time or times when specified agreements or controls are applied to the software configuration items being developed, e.g., an approved baseline or release of a specified document/code.  [IEEE Std 828-1998]

correctability -- The degree of effort required to correct software defects and to cope with user complaints.  [Fenton & Pfleeger, 1997]. 

corrective maintenance -- Maintenance performed to correct faults in hardware or software system.

cost -- The dollar amount of cash expended, resources used, property transferred, services performed, or liability incurred inconsideration of goods and services received.

cost avoidance -- A form of revenue (positive cash flow) that comes as a result not of increasing income but rather of decreasing expenses.  [steve.tockey@construx.com]

cost-effectiveness analysis -- A form of not-for-profit analysis, derived from benefit-cost analysis, which seeks to maximize effectiveness for a minimum cost.  Fixed-cost analysis seeks to maximize the effectiveness that can be attained from a fixed, maximum investment.  Fixed-effectiveness analysis seeks to minimize the investment needed to attain a fixed, minimum degree of effectiveness.  [steve.tockey@construx.com]

COTS -- Acronym for commercial-off-the-shelf.  [IEEE Stds Glossary]

coupling -- In software design, a measure of the interdependence among modules in a computer program or the amount of information shared between two modules.  Contrast with cohesion.

CPU -- Acronym for central processing unit. [IEEE Stds Glossary]

crisis -- A critical state of affairs in which a decisive, probably undesirable outcome is impending.[d.fairley@computer.org]

crisis management -- Steps to take when a contingency plan doesn’t solve the associated problem. [d.fairley@computer.org]

critical design review -- An obsolete software development term for what is now called detailed design review.

criticality -- A subjective description of the intended use and application of the system.  Software criticality properties may include safety, security, complexity, reliability, performance, or other characteristics.  [IEEE Stds Glossary]

criticality analysis -- A structured evaluation of the software characteristics (e.g., safety, security, complexity, performance) for severity of impact of system failure, system degradation, or failure to meet software requirements or system objectives.  [IEEE Stds Glossary]

cross-reference tool -- A software maintenance tool that allows the user to determine where a variable is used or where a particular procedure is called on.  [Robson, J. Systems and Software, 1991]

CSA -- Acronyms for configuration status accounting.  [IEEE Stds Glossary]

customer -- In an engineering project, see acquirer. [IEEE/EIA 12207-1997]

customer -- The person, or persons, for whom the product is intended, and usually (but not necessarily) who decides the requirements.  [IEEE Stds Glossary]  In an engineering project, see acquirer. [IEEE/EIA 12207-1997]

site and all contents © 2013 Richard H. Thayer, all rights reserved