ISO/IEC 25051:2014 ソフトウェアエンジニアリング—システムおよびソフトウェアの品質要件と評価（SQuaRE）—すぐに使用できるソフトウェア製品（RUSP）の品質要件とテスト手順 | ページ 6

4.1.1

acquirer

stakeholder that acquires or procures a product or service from a supplier

Note 1 to entry: The acquirer could be one of the following: buyer, customer, owner, purchaser.

[SOURCE:ISO/IEC 12207:2008]

4.1.2

anomaly

any condition that deviates from expectations based on requirements specifications, design documents, standards, etc. or from someone's perceptions or experiences

[SOURCE:IEEE Std 1044-2009]

4.1.3

application administration function

functions performed by users which include installation, configuration, application backup, maintenance (patching and upgrading) and uninstallation

4.1.4

conformity evaluation

systematic examination of the extent to which a product, process or service fulfils specified requirements

[SOURCE:ISO/IEC Guide 2:2004]

4.1.5

conformity evaluation report

document that describes the conduct and results of the evaluation carried out for a Ready to Use Software Product (RUSP)

Note 1 to entry: This was adapted from IEEE Std 610.12–1990.

4.1.6

Ready to Use Software Product

RUSP

software product available for any user, at cost or not, and use without the need to conduct development activities

Note 2 to entry: Software is mainly composed of programs and data.

Note 3 to entry: This definition applies also to product description, user documentation and software which are produced and supported as separate manufactured goods, but for which typical commercial fees and licensing considerations may not apply.

4.1.7

end user

individual person who ultimately benefits from the Ready to Use Software Product functionalities

Note 1 to entry: The end user may be a regular operator of the software product or a casual user such as a member of the public.

[SOURCE:ISO/IEC 25000:2005]

4.1.8

fault

incorrect step, process, or data definition in a computer program

[SOURCE:IEEE Std 610.12-1990]

4.1.9

maintenance

process of modifying a software system or component after delivery to correct faults, improve performance or others attributes, or adapt to a changed environment

[SOURCE:IEEE Std 610.12-1990]

4.1.10

pass/fail criteria

decision rules used to determine whether a software item or a software feature passes or fails a test

[SOURCE:IEEE Std 829.12-1998]

4.1.11

product description

document stating properties of software, with the main purpose of helping potential acquirers in the evaluation of the suitability for themselves of the software before purchasing it

4.1.12

product identification

software product name, version, variant, and date information

4.1.13

requirements document

document containing any combination of requirements or regulations to be met by a Ready to Use Software Product (RUSP)

Note 1 to entry: These documents may be technical reports, standards, requirements list (or model requirements specification) for a kind of user, or a statute or regulation imposed by a governing or regulatory body.

4.1.14

software function

implementation of an algorithm in the software with which the end user or the software can perform part or all of a work task

Note 1 to entry: A function does not need to be callable by the end user (e.g. automatic backup or saving of data).

4.1.15

software test environment

facilities, hardware, software, firmware, procedures, and documentation needed to perform qualification or other testing of software

[SOURCE:ISO/IEC/IEEE 24765:2010]

4.1.16

supplier

organization or individual that enters into an agreement with the acquirer for the supply of a product or service

Note 1 to entry: The “supplier” could be a contractor, producer, seller, or vendor.

Note 2 to entry: Sometimes the acquirer and the supplier are part of the same organization.

[SOURCE:ISO/IEC 12207:2008]

4.1.17

test

activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component

[SOURCE:IEEE Std 610.12-1990]

4.1.18

test case

set of inputs, execution conditions, and expected results developed for a particular objective, such as exercise a particular program path or to verify compliance with a specific requirement

[SOURCE:IEEE Std 610.12-1990]

4.1.19

test documentation

collection of the documentation inherent to the testing activities

4.1.20

test objective

identified set of software characteristics to be measured under specified conditions by comparing actual behaviour with the required behaviour

Note 1 to entry: This was adapted from IEEE Std 610.12–1990.

4.1.21

test plan

document describing the scope, approach, resources, and schedule of intended testing activities

Note 1 to entry: This was adapted from IEEE Std 610.12–1990.

4.1.22

test procedure

detailed instructions for the set-up, execution, and evaluation of results for a given test case

[SOURCE:IEEE Std 610.12-1990]

4.1.23

testing

process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component

[SOURCE:IEEE Std 610.12-1990]

4.1.24

testing description

description of the test execution conditions (i.e. test procedure)

4.1.25

user

individual or group that benefits from a RUSP during its utilization

Note 1 to entry: The role of user and the role of operator may be vested, simultaneously or sequentially, in the same individual or organization.

[SOURCE:ISO/IEC 12207:2008]

4.1.26

user documentation

information that is supplied with the software to help the user in their use of that software