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

technical review – A review to evaluate products or services under consideration and provide evidence that -- (1) They are complete, (2) they comply with their standards and specifications, and (3) they are ready for the next activity.

tender – Same as proposal.  United Kingdom usage.

test -- (1) A set of one or more test cases, (2) A set of one or more test procedures, or (C) A set of one or more test cases and procedures.  [IEEE Stds Glossary]

test case -- Documentation that specifies inputs, predicted results, and a set of execution conditions for a test item.  [IEEE Stds Glossary]

test case specification -- A document specifying inputs, predicted results, and a set of execution conditions for a test item.  [IEEE Stds Glossary]

test design -- Documentation that specifies the details of the test approach for a software feature or combination of software features and identifying the associated tests.  [IEEE Stds Glossary]

test design specification -- A document specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests.  [ANSI/IEEE Std 829-1983]

test design specification -- A document specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests.  [IEEE Stds Glossary]

test incident report -- A document reporting on any event that occurs during the testing process, which requires investigation.  [IEEE Stds Glossary]

test item -- A software item that is an object of testing.  [IEEE Stds Glossary]

test item transmittal report -- A document identifying test items.  It contains status and location information.  [IEEE Stds Glossary]

test log -- A chronological record of relevant details about the execution of tests.  [IEEE Stds Glossary]

test plan -- A document describing the scope, approach, resources, and schedule of intended testing activities.  It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning.  [IEEE Stds Glossary]

test procedure -- Documentation that specifies a sequence of actions for the execution of a test.  [IEEE Stds Glossary]

test procedure specification -- A document specifying a sequence of actions for the execution of a test.  [IEEE Stds Glossary]

test readiness review (TRR) -- A milestone review to determine that the software test procedures are complete and to ensure that the software developer is prepared for formal software performance testing.  The results of informal testing also are reviewed.  [Military Standard 1521B-1985].  See also milestone review, review, test, testing.  

test summary report -- A document summarizing testing activities and results.  It also contains an evaluation of the corresponding test items.  [IEEE Stds Glossary]

testability -- The effort required to test software.  [Fenton & Pfleeger, 1997]. 

testing -- The process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features of the software item.  [IEEE Stds Glossary]

top-down cost-estimation models (method) -- An overall cost estimate for the project is derived from global properties of the software product and project

top-down design -- The process of designing a system by identifying its major components, decomposing them into their low-level components, and iterating until the desired level of detail is achieved.  Contrast with bottom-up design.

traceability — The identification and documentation of derivation paths (upward) and allocation or flow down paths (downward) of work products in the work product hierarchy.  Important kinds of traceability include -- to or from external sources to or from system requirements; to or from system requirements to or from lowest level requirements; to or from requirements to or from design; to or from design to or from implementation; to or from implementation to test; and to or from requirements to test.  [IEEE-STD 1362-1998]

TRR – Acronym for test readiness review

two-phase acquisition -- A means to deal with inherent uncertainty in software projects by delaying the final decision.  The project is broken into an early phase that focuses on gathering requirements, addressing major risks, and project planning, and a later phase that completes the project if the first phase’s outcome is favorable.  The final decision on whether to do the full project is deferred from the point when the uncertainties are the greatest (the beginning) to a point where the uncertainties are significantly reduced (the end of the first phase).  [steve.tockey@construx.com]

uncertainty -- The result of not having accurate or sufficient knowledge of a situation; often the root cause of a risk factor.  [d.fairley@computer.org]

Unified Modeling Language (UML) -- A graphical language for visualizing, specifying, constructing, and documenting an object-oriented software-intensive system’s artifacts.  [geri@wyyzzk.com]

use case -- In UML, a complete task of a system that provides a measurable result of value for an actor.  More formally, a use case defines a set of use case instances or scenarios.  [geri@wyyzzk.com]

use case diagram -- A UML diagram that shows actors, use cases, and their relationships.  [geri@wyyzzk.com]

use case model -- A model that describes a system’s functional requirements in terms of use cases.  [geri@wyyzzk.com]

use case specification -- A document that describes a use case.  A use case specification’s fundamental parts are the use case name, brief description, precondition, basic flow, post condition, and alternate flow.  [geri@wyyzzk.com]

user -- The person or persons operating or interacting directly with the system.  [IEEE Stds Glossary]

utility -- A measure of value within a given value system, often measured on a scale of 0 to 100.  [d.fairley@computer.org]

V&V -- Acronym for verification and validation.  [IEEE Stds Glossary]

validation -- Confirmation by examination and provisions of objective evidence that the particular requirements for a specific intended use are fulfilled.  In design and development, validation concerns the process of examining a product to determine conformity with user needs.  [IEEE Stds Glossary]

VDD -- Acronym for version description document.  [IEEE Stds Glossary]

verification -- Confirmation by examination and provisions of objective evidence that specified requirements have been fulfilled.  In design and development, verification concerns the process of examining the result of a given activity to determine conformity with the stated requirement for that activity.  [IEEE Stds Glossary]

version -- (1) An initial release or re-release of a computer software configuration item, associated with a complete compilation or recompilation of the computer software configuration item.  (2)  An initial release or complete re-release of a document, as opposed to a revision resulting from issuing change pages to a previous release.  [CSDP Glossary]  (3) An operational software product that differs from other like products as to capability, environmental requirements, and configuration.  Sometimes synonymous with build.

walkthrough -- A software peer review, conducted by the peers of the software developer, to evaluate a software element.  Although usually associated with code examination, this process is also applicable to the software requirements and software design.  The major objectives of the walkthrough are to find defects (e.g., omissions, unwanted additions, and contradictions) in a specification and other products and to consider alternative functionality, performance objectives, or representations.  [Hollocker 1990]  Seealso inspection.  Walkthroughs are credited to a well-known scientist by the name of Dr. Gerald Weinberg.  He developed the theory of an egoless review.  An egoless review (now called a walkthrough) is a review by peers of the author of the code. 

WBS -- Acronym for work breakdown structure

work activity -- A collection of work tasks spanning a fixed duration within the schedule of a software project.  Work activities may contain other work activities, as in a work breakdown structure.  The lowest-level work activities in a hierarchy of activities are work tasks.  Typical work activities include project planning, requirements specification, software design, implementation, and testing.

work breakdown structure (WBS) -- In software engineering project management, a method of representing in a hierarchical manner the parts of a product or process.  A WBS can be used to represent a process (requirement analysis, design, code, or software test) or a product (application programs, utility programs, or operating systems).

work package -- A well-defined work to be accomplished in completing a function, activity, or task.  Most work packages are relatively small in nature and can be accomplished by 2-4 individuals in 2-4 weeks.  A work package should have a unique name and identifier, preconditions for initiating the work, staffing requirements, other needed resources, work products to be generated estimated duration, risks factors, predecessor and successor work tasks, any special considerations for the work and the completion criteria for the work package - including quality criteria for the work products to be generated.  See work package specification...

work package specification -- A specification of the work that must be accomplished to complete a work package.

work product --Any tangible item produced during the process of developing or modifying software.  Examples of work products include the project plan, supporting process requirements, design documentation, source code, test plans, meeting minutes, schedules, budgets, and problem report.  Some subset of the work products will be baselined and some will form the set of project deliverables.

work task --The smallest unit of work subject to management accountability.  A work task must be small enough to allow adequate planning and control of a software project, but large enough to avoid micro-management.  The specification of work to be accomplished in completing a work task should be documented in a work package.  Related work tasks should be grouped to form supporting processes and work activities.