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

SC – Acronym for software component.

SCA -- Acronym for software change authorization.  [IEEE Stds Glossary]

scenario -- A description of a specific sequence of actions.  In use case scenarios, specific persons or actor instances replace actors, and only one path is taken through the use case’s possible basic and alternate flows.  Also called use case instance.  [geri@wyyzzk.com]

SCI – Acronym for software configuration item.

SCM -- Acronym for software configuration management.  

SCMPI -- Acronym for software configuration management planned information.  [IEEE Stds Glossary]

SCR -- Acronym for system/software change request.  [IEEE Stds Glossary]

SDD -- Acronym for software design document.

SDR -- Acronym for system design review.  

SE -- Acronym for software engineering.  [IEEE Stds Glossary]  See also SWE.

self-descriptiveness -- Those attributes of the software that provide an explanation of the implementation of a function.  [McCall, Richards, and Walters, RADC, 1977]

sensitivity analysis -- A technique that studies how changes in the values of estimated parameters affect an alternative’s desirability.  Parameters where small changes in estimated values cause larger changes in desirability are said to be more sensitive.  Sensitivity analysis guides the decision maker in identifying the estimated parameters that deserve more careful study to make sure those estimates are accurate.  [steve.tockey@construx.com]

simplicity -- Those attributes of software that provide implementation of functions in the most understandable manner.  [McCall, Richards, and Walters, RADC, 1977]

SLC -- Acronyms for software life cycle.  [IEEE Stds Glossary]

SLCM -- Acronyms for software life cycle model.  [IEEE Stds Glossary]

SLCP -- Acronyms for software life cycle process.  [IEEE Stds Glossary]

SLOC -- Acronyms for source lines of code.  [IEEE Stds Glossary]

software change control -- The process by which a software change is proposed, evaluated, approved or rejected, scheduled, and tracked [ANSI/IEEE Std 610.12 1990]  See also software configuration control, configuration management (CM).  

software component (SC) -- A functionally or logically distinct part of a software configuration item (SCI) distinguished for purposes of convenience in designing and specifying a complex SCI as an assembly of subordinate elements. 

software configuration (1) The arrangement of a computer system or component as defined by the number, nature, and interconnections of its constituent parts.  (2) The functional and physical characteristics of a software system as set forth in technical documentation or achieved in a product.  [ANSI/IEEE Std 610.12 1990]

software configuration auditing -- The process of verifying that all required hardware/software configuration items have been produced, that the current version agrees with specified requirements, that the technical documentation completely and accurately describes the configuration items, and that all change requests have been resolved.  [ANSI/IEEE Std 610.12 1990]  See also software configuration management.

software configuration control -- 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]  See also software configuration management.

software configuration identification --(1) An element of configuration management consisting of selecting the configuration items for a software system and recording their functional and physical characteristics in technical documentation.  (2)  The current approved technical documentation for a software configuration item as set forth in specifica­tions, drawings, associated lists, and documents referenced therein.  [IEEE Std 610.12-1990]  See also software configuration management.

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

software configuration management (SCM) -- A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a software configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.  See also software configuration auditing, software configuration control, software configuration identification, software configuration status accounting, and software release management.

software configuration management plan -- A document setting forth the configuration items of a system and the plan for configuration management of each of them, including schedules, procedures, personnel, and equipment to be utilized.  [IEEE Std 828-1998]

software configuration status accounting – The process of recording and reporting of information needed to manage a configuration effectively.  This information includes a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of approved changes.  [ANSI/IEEE Std 610.12 1990]  See also software configuration management.

software cost-estimation model -- Any one of several quantitative methods of estimating the expected cost (and some times schedule) of a software project.  Quantitative techniques are generally based on empirically derived cost estimating relationships.  Generally, the major independent parameter (input) is lines of source code and/or type of project.  See also top-down and bottom-up cost models.

software design -- The use of scientific principles, technical information, and imagination in the definition of a software system to perform prespecified functions with maximum economy and efficiency.  See also design.

software design audit -- A review of a software product to determine compliance with requirements, standards, and contractual documents.

software design concept -- A fundamental idea (such as information hiding) that can be applied to designing a system.

software design description -- (1)  A representation of software created to facilitate analysis, planning, implementation, and decision-making.  The software design description serves as a medium for communicating software design information and can be thought of as a blueprint or model of the system.  [IEEE Std 1012-1986]  (2) A representation of a software system created to facilitate analysis, planning, implementation, and decision-making.  A blueprint or model of the software system.  The SDD serves as the primary medium for communicating software design information.  See also detailed design description.  [IEEE Std 1016- 1987]

software design description (SDD) -- A representation of software created to facilitate analysis, planning, implementation, and decision-making.  The software design description is used as a medium for communicating software design information, and may be thought of as a blueprint or model of the system.  [IEEE Stds Glossary]

software design document -- See software design description.  [IEEE Std 610.12-1990]

software design notation -- A means of describing a software design.  It can be diagramatic, symbolic, or textual.  For example, structure charts and pseudocode are software design notations.  Also called software design representation.

software design requirement -- See design constraint.

software design review -- A formal meeting at which a system’s preliminary or detailed design is presented to the user, customer, or other interested parties for comment and approval.  [ANSI/IEEE Std 610.12-1990]

software design specification -- A document that specifies the design of a system or component.  Typical contents include algorithms, system or component architecture, control logic, data structures, input/output formats, and interface descriptions.  Also called software design description, internal specifications.  Contrast with software requirements specification, external specifications.  [ANSI/IEEE Std 610.12-1990]

software design specification -- See software design description.

software design strategy -- The overall plan and direction for performing design.  For example, functional decomposition is a software design strategy.  See also design strategy.

software design verification -- The evaluation of a design to determine correctness with respect to stated requirements, conformance to design standards, system efficiency, and other criteria.

software development plan --See software project management plan.  [U.S. Department of Defense (DoD) usage].

software engineering project --The set of work activities, both technical and managerial, required to satisfy the terms and conditions of a project agreement.  A software project should have specific starting and ending dates, well-defined objectives and constraints, established responsibilities, and a budget and schedule.  A software project may be self-contained or may be part of a larger project.  In some cases, a software project may span only a portion of the software development cycle.  In other cases, a software project may span many years and consist of numerous subprojects, each being a well-defined and self-contained software project.

software engineering project management --A system of management procedures, practices, technologies, skill, and experience that is necessary to manage successfully a software development

software engineering project manager --The manager of a software engineering project is called a software engineering project manager, a software project manager, or in many cases just a protect manager.

software feature -- A distinguishing characteristic of a software item (e.g., performance, portability, or functionality).  [IEEE Stds Glossary]

software integrity level -- The integrity level of a software item.  [IEEE Stds Glossary]

software item -- An aggregation of software, such as a computer program or database that satisfies an end use function and is designated for purposes of specification, qualification testing, interfacing, configuration management, or other purposes.  Software items are selected based on tradeoffs among software function, size, host or target computers, developer, support strategy, plans for reuse, criticality, interface considerations, need to be separately documented and controlled, and other factors.  A software item is made up of one or more software units.

software item -- Source code, object code, job control code, control data, or a collection of these items.  [IEEE Stds Glossary]

software librarian -- See program librarian.   

software life cycle (SLC) -- The project-specific sequence of activities that is created by mapping the activities of this standard onto a selected software life cycle model (SLCM).  Contrast with software life cycle model (SLCM); software life cycle process (SLCP).  [IEEE Stds Glossary]

software life cycle model (SLCM) -- The framework, selected by each using organization, on which to map the activities of this standard to produce the software life cycle (SLC).  Contrast with software life cycle (SLC); software life cycle process (SLCP).  [IEEE Stds Glossary]

software life cycle process (SLCP) -- The project-specific description of the process that is based on a project’s software life cycle (SLC) and the organizational process assets (OPA).  Contrast with software life cycle (SLC); software life cycle model (SLCM).  See also organizational process asset (OPA).  [IEEE Stds Glossary]

software maintainability -- Maintainability is the average effort required to locate and fix a software failure [RADC-TR-83-17].  (1) Maintainability measurements consist of correctability, expandability, and testability.  See also correctability, expandability, and testability.  [Fenton & Pfleeger, 1997].  (2) Software maintainability measurements consist of consistency, simplicity, conciseness, modularity, self-descriptiveness.  [McCall, Richards, and Walters, RADC, 1977]  See also consistency, simplicity, conciseness, modularity, and self-descriptiveness

software maintenance – The process of modifying a software system or component after delivery to correct faults, improve performance, add new capabilities, or adapt to a changed environment [IEEE Std 610.12-1991]

software project management plan (SPMP) --The controlling document for managing a software project.  A software project management plan establishes policies, procedures, rules, tasks, schedules, and resources necessary to complete the project.  Synonymous with software development plan, software engineering project plan.

software release management -- Management of activities surrounding release of one or more versions of software to one or more customers.  This activity encompasses the identification, packaging, and delivery of the elements of a product.  See also software configuration management, version. 

software requirement -- (1).  A software capability needed by a user to solve a problem to achieve an objective.  (2). A software capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.  3. The set of all software requirements that forms the basis for subsequent development of the software or software component.  [ANSI/IEEE Standard 729-1983]  4.  A collective term for following types of software requirements -- functional requirements, performance requirements, external interface requirements, design constraints, and quality attributes [IEEE Std 830-1998] 5.  A short description sometimes used in place of the term software requirements specification. 

software requirements analysis -- (1) The process of studying user needs to arrive at a definition of system, hardware, or software requirements.  (2)  The process of studying and refining system, hardware, or software requirements.  [IEEE Std 610.12-1990]

software requirements elicitation -- The process through which the software acquirers (customers or users) and the suppliers (contractor) of a software system discover, review, articulate, understand and document  the users' needs and the constraints on the software system and the development activity.  See also concept of operation analysis and concept of operations (ConOps) documents.  Sometimes called needs analysis.

software requirementsengineering – (1).  The science and discipline concerned with analyzing and documenting software requirements.  It involves transforming system requirements into a description of software requirements, performance parameters, and a software configuration using an iterative process of definition, analysis, tradeoff studies, and prototyping.  (2). Software requirements engineering is comprised of software requirements elicitation, software requirements analysis, software requirements specification, software requirements verification, and software requirements management.  Sometimes synonymous with software requirements analysis. 

software requirements management --The process of planning and controlling the identification, allocation, and flow down of requirements from the system level to the module or part level, including interfaces, verification, modifications, and status monitoring

software requirements phase -- The software development lifecycle phase during which the requirements for a software product, such as the functional and performance capabilities, are defined, documented, and reviewed. 

software requirements review (SRR) -- Synonymous with software specification review (SSR). 

software requirements specification (SRS) -- Documentation of the essential requirements (e.g., functions, performance, design constraints, and attributes) of the software and its external interfaces.  The software requirements are derived from the system specification.  [IEEE Stds Glossary]

software requirements specification (SRS) -- (1).  A document that clearly and precisely describes each of the essential requirements (functions, performance, design constraints, and quality attributes) of the software and the external interfaces.  Each requirement is defined in such a way that its achievement can be objectively verified by a prescribed method, for example, inspection, demonstration, analysis, or test.  [ANSI/IEEE Standard 830-1984]  Sometime called external specifications.  Contrast with internal specifications (design specifications)

software requirements verification – The process of ensuring that the software requirements specification complies with the system requirements, conforms to document standards of the requirements phase, and is an adequate basis for the architectural (preliminary) design phase. 

software specification review (SSR) -- A milestone review conducted to finalize software configuration item (SCI) requirements so that the software developer can initiate preliminary software design.  The SSR is conducted when SCI requirements have been sufficiently defined to evaluate the developer's responsiveness to and interpretation of the system/segment level technical requirements.  A successful SSR is predicated on the developer's determination that the software requirements specification and interface specifications form a satisfactory basis for proceeding into the preliminary design phase.  [Military Standard 1521B-1985]  See also milestone review, review.  

software specification review (SSR) -- In software system engineering, a joint acquirer-supplier review conducted to finalize software configuration item (SCI) requirements so that the software developer can initiate the next step in the software development process.  The SSR is conducted when SCI requirements have been sufficiently defined to evaluate the developer's responsiveness to and interpretation of the system/segment level technical requirements.  A successful SSR is predicated on the developer's determination that the software requirements specification and interface specifications form a satisfactory basis for proceeding into the preliminary design phase.  [Military Standard 1521B-1985] 

software verification and validation plan (SVVP) -- A plan describing the conduct of software V&V. [IEEE Stds Glossary]

software verification and validation report (SVVR) -- Documentation of V&V results and software quality assessments.  [IEEE Stds Glossary]

software version control -- A process for controlling the different versions of a software system.  See also configuration management.

SPMPI -- Acronym for software project management planned information.  [IEEE Stds Glossary]

SQA -- Acronym for software quality assurance.  [IEEE Stds Glossary]

SRR – Acronym for system requirements review.

SRS --Acronym for software requirements specification, system requirements specification.  Note that SRS is normally not used for software requirements review; the preferred name is software specification review (SSR).

SSR --Acronym for software specification review. 

structured design -- A disciplined approach to software design that adheres to a specified set of rules based on principles such as top-down design, stepwise refinement, and dataflow analysis.

sunk cost -- Any cost that is irrecoverable by future actions.  Psychologically, people tend to pay attention to sunk costs even though they are irrelevant in business decisions [steve.tockey@construx.com]

supplier --An organization that develops some or all of the project deliverables for an acquirer.  Suppliers may include organizations that have primary responsibility for project deliverables and subcontractors that deliver some part of the project deliverables to a primary supplier.  In the latter case, the primary supplier is also an acquirer.  [IEEE/EIA Standard 12207-1997]

supporting process --A collection of work activities that supports the software development environment.  Examples of supporting processes include software documentation, software quality assurance, software verification and validation, software configuration management, software reviews, audit processes, and problem resolution activities.  [IEEE/EIA Standard 12207­1997].  Supporting processes are to the development process as the organizational staff activities are to organizational line activities.

SVVP -- Acronym for software verification and validation plan.  [IEEE Stds Glossary]

SVVR -- Acronym for software verification and validation report [IEEE Stds Glossary]

SWE – Acronym for software engineering

system – (1) A conceptual entity defined by its boundaries.  Examples include companies, divisions, sets of software applications, components, machines, and devices.  (2) A set of interlinked units organized to accomplish one or several specific functions.  [IEEE Stds Glossary]

system design review (SDR) -- In system engineering, a system milestone review conducted when the definition effort has proceeded to the point where system requirements and the design approach are defined.  Alternative design approaches and corresponding test requirements have been considered and the developer has defined and selected the required equipment, logistic support, personnel, procedural data, and facilities.  This normally is late in the definition phase.  This review is conducted in sufficient detail to ensure a technical understanding between the system developer and the customer.  The system segments are identified in the system design specification, and the hardware/software configuration items are identified in the requirements specifications.  See also milestone reviews, reviews.  

system requirements review (SRR) -- In system engineering, a system milestone review that ascertains the adequacy of the system developer's efforts in defining system requirements.  It will be conducted when a significant portion of the system functional and performance requirements has been established, normally in the definition phase (or equivalent effort).  See also milestone review, review.  

system testing -- The activities of testing an integrated hardware and software system to verify and validate whether the system meets its original objectives.  [IEEE Stds Glossary]