This document defines the LIFE CYCLE requirements for development and maintenance of HEALTH SOFTWARE needed to support conformance to IEC 62443-4-1 – taking the specific needs for HEALTH SOFTWARE into account. The set of PROCESSES, ACTIVITIES, and TASKS described in this document establishes a common framework for secure HEALTH SOFTWARE LIFE CYCLE PROCESSES. The purpose is to increase the CYBERSECURITY of HEALTH SOFTWARE by establishing certain ACTIVITIES and TASKS in the HEALTH SOFTWARE LIFE CYCLE PROCESSES and also by increasing the SECURITY of SOFTWARE LIFE CYCLE PROCESSES themselves. It is important to maintain an appropriate balance of the key properties SAFETY, effectiveness and SECURITY as discussed in ISO 81001-1. This document excludes specification of ACCOMPANYING DOCUMENTATION contents.

  • Draft
    52 pages
    English language
    sale 15% off

This document defines enrichments, extensions and structuring mechanisms of Petri nets, applied on the definitions proposed in ISO/IEC 15909-1. This document facilitates the definitions of new kinds of Petri nets and their interoperability, while remaining compatible with those defined in ISO/IEC 15909-1. This document is written as a reference for designers of new Petri net variants, by defining common enrichments, extensions and structuring mechanisms, as well as a generalized process for defining new ones. This document is applicable to a wide variety of concurrent discrete event systems and in particular distributed systems. Generic fields of application include: —   requirements analysis; —   development of specifications, designs and test suites; —   descriptions of existing systems prior to re-engineering; —   modelling business and software processes; —   providing the semantics for concurrent languages; —   simulation of systems to increase confidence; —   formal analysis of the behaviour of systems; —   and development of Petri net support tools. This document can be applied to the design of a broad range of systems and processes, including aerospace, air traffic control, avionics, banking, biological and chemical processes, business processes, communication protocols, computer hardware architectures, control systems, databases, defence command and control systems, distributed computing, electronic commerce, fault-tolerant systems, games, hospital procedures, information systems, Internet protocols and applications, legal processes, logistics, manufacturing systems, metabolic processes, music, nuclear power systems, operating systems, transport systems (including railway control), security systems, telecommunications and workflow.

  • Standard
    15 pages
    English language
    sale 15% off

This document specifies test processes that can be used to govern, manage and implement software testing for any organization, project or testing activity. It comprises generic test process descriptions that define the software testing processes. Supporting informative diagrams describing the processes are also provided. This document is applicable to testing in all software development lifecycle models. This document is intended for, but not limited to, testers, test managers, developers and project managers, particularly those responsible for governing, managing and implementing software testing.

  • Standard
    54 pages
    English language
    sale 15% off
  • Draft
    54 pages
    English language
    sale 15% off

This document defines test design techniques that can be used during the test design and implementation process that is defined in ISO/IEC/IEEE 29119‑2. Each technique follows the test design and implementation process that is defined in ISO/IEC/IEEE 29119‑2 and shown in Figure 1. This document is intended for, but not limited to, testers, test managers, and developers, particularly those responsible for managing and implementing software testing.

  • Standard
    135 pages
    English language
    sale 15% off
  • Draft
    136 pages
    English language
    sale 15% off

This document specifies software test documentation templates that can be used for any organization, project or testing activity. It describes the test documentation that is an output of the processes specified in ISO/IEC/IEEEÂ 29119-2. This document is applicable to testing in all software development lifecycle models. This document is intended for, but not limited to, testers, test managers, developers, and project managers, particularly those responsible for governing, managing, and implementing software testing.

  • Standard
    84 pages
    English language
    sale 15% off
  • Draft
    84 pages
    English language
    sale 15% off

This document provides an overview of agile readiness factors that are likely to determine whether an organization, project, product or team is ready to start the transition to using an agile approach to their system and software development and maintenance activities. This document provides a general approach that is applicable to all agile methodologies and does not cover specific agile methodologies, such as Scrum, SAFe and eXtreme Programming (XP).

  • Technical report
    19 pages
    English language
    sale 15% off
  • Draft
    19 pages
    English language
    sale 15% off

This handbook provides assessors with a number of instruments needed to perform software process capability assessments using the assessment method described in EN 17603-80-11 (equivalent to ECSS-Q-HB-80-02 Part 1). It also provides instruments that help assessors to carry out their activities when performing assessments and supporting the implementation of software process improvement initiatives using the method for process improvement described in Part 1.
The instruments provided are:
• The Process Assessment Model (PAM) required to perform assessments including process descriptions and process attribute indicators
• Conformance statement to the requirements in ISO/IEC 15504 Part 2
• A definition of the Process Reference Model (PRM) on which TR 17603-80-11 and TR 17603-80-12 (equivalent to ECSS-Q-HB-80-02 Part 1 and 2) PAM are based (defined in TR 17603-80-11)
• Detailed traces from base practices in the PAM to standard clauses and from work products to expected outputs.

  • Technical report
    129 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Technical report
    129 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This handbook provides recommendations, methods and procedures that can be used for the selection and reuse of existing software in space software systems.
This handbook is applicable to all types of software of a space system, including the space segment, the launch service segment and the ground segment software (including EGSEs) whenever existing software is intended to be reused within them.
This handbook covers the following topics:
• Software reuse approach including guidelines to build the Software Reuse File
• Techniques to support completion of existing software qualification to allow its reuse in a particular project
• Tool qualification
• Risk management aspects of reusing existing software Existing software can be of any type: Purchased (or COTS), Legacy-Software, open-source software, customer-furnished items (CFI's), etc.
NOTE Special emphasis is put on guidance for the reuse of COTS software often available as-is and for which no code and documentation are often available.
Legal and contractual aspects of reuse are in principle out of scope; how ever guidelines to help in determine the
reusability of existing software from a contractual point of view is provided in [ESA/REG/002].
Any organization with the business objective of systematic reuse may need to implement the organizational reuse processes presented in [ISO12207]. These processes w ill support the identification of reusable software products and components within selected reuse domains, their classification, storage and systematic reuse within the projects of that organization, etc. But these processes are out of scope of this handbook as the handbook is centred on the specific project activities to reuse an existing software product, not part of those organizational reuse processes more oriented to ‘design for reuse’ processes.
In addition, this handbook provides guidelines to be used for the selection and analysis of tools for the development, verification and validation of the operational software.

  • Technical report
    58 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Technical report
    58 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This handbook defines methods for process assessment and improvement that may be used to meet the requirements on
process assessment and improvement of the EN16602-80 (equivalent to ECSS-Q-ST-80C) subclause 5.7. These methods constitute a clear and proven w ay of implementing those requirements. Alternative methods can be used provided that they meet the detailed instructions provided in this handbook for recognition of software process assessment schemes and results and process improvement.
This handbook provides a detailed method for the implementation of the requirements of the EN16602-80 for software process assessment and improvement. It also establishes detailed instructions for alternative methods intended to meet the same EN16602-80 requirements.
The process assessment and improvement scheme presented in this handbook is based on and conformant to the ISO/IEC 15504 International Standard. In designing this process assessment and improvement scheme the ISO/IEC 15504 exemplar process assessment model w as adopted and extended to address specific requirements.
The methods provided in this handbook can support organizations in meeting their business goals and in this context they can be tailored to suit their specific needs and requirements. How ever w hen used to claim compliance with relevant requirements in EN16602-80 only the steps and activities explicitly marked as recommended in this handbook may be omitted or modified.

  • Technical report
    122 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Technical report
    122 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This Handbook provides guidance on the application of the dependability and safety requirements relevant to software defined in EN 16602-80 (equivalent of ECSS-Q-ST-80).
This Handbook provides support for the selection and application of software dependability and safety methods and techniques that can be used in the development of software-intensive space systems.
This Handbook covers all of the different kinds of software for which EN 16602-80 (equivalent of ECSS-Q-ST-80) is applicable. Although the overall software dependability and safety workflow description is mainly targeted to the development of spacecraft, the described approach can be adapted to projects of different nature (e.g. launchers, ground systems).
The methods and techniques described in the scope of this Handbook are limited to assessment aspects, not including development and implementation techniques for dependability and safety (e.g. fault tolerance techniques, or development methods like coding standards, etc.).
Although dependability is a composite term, including reliability, availability and maintainability, this Handbook addresses in particular the reliability aspects. Software maintainability and availability are not covered in depth by this handbook, because the relevant methods and techniques are still undergoing improvement. Nevertheless, whenever a link can be made to either of these two characteristics, it is explicitly mentioned in the corresponding section.

  • Technical report
    43 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Technical report
    43 pages
    English language
    sale 10% off
    e-Library read for
    1 day

The scope of this Handbook is the software metrication as part of a space project, i.e. a space system, a subsystem including hardware and software, or ultimately a software product. It is intended to complement the EN 16602-80 (equivalent to ECSS-Q-ST-80) with specific guidelines related to use of different software metrics including their collection, analysis and reporting. Tailoring guidelines for the software metrication process are also provided to help to meet specific project requirements.
This Handbook provides recommendations, methods and procedures that can be used for the selection and application of appropriate metrics, but it does not include new requirements w ith respect to those provided by EN 16602-80 (equivalent to ECSS-ST-Q-80).
The scope of this Handbook covers the following topics:
• Specification of the goals and objectives for a metrication programme.
• Identification of criteria for selection of metrics in a specific project / environment (goal driven).
• Planning of metrication in the development life cycle.
• Interface of metrication with engineering processes.
• Data collection aspects (including use of tools).
• Approach to the analysis of the collected data.
• Feedback into the process and product based on the analysis results.
• Continuous improvement of measurement process.
• Use of metrics for process and product improvement.
This Handbook is applicable to all types of software of all major parts of a space system, including the space segment, the launch service segment and the ground segment software.

  • Technical report
    100 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Technical report
    100 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This document defines a method for the sizing of non-functional software requirements. It complements ISO/ IEC 20926:2009, which defines a method for the sizing of functional user requirements (FUR).1 This document also describes the complementarity of functional and non-functional sizes, so that sizing both functional and non-functional requirements (NFR) do not overlap. It also describes how non-functional size, together with functional size, should be used for measuring the performance of software projects, setting benchmarks, and estimating the cost and duration of software projects. In general, there are many types of non-functional software requirements. Moreover, non-functional aspects evolve over time and may include additional aspects in the as technology advances. This standard does not intend to define the type of NFR for a given context. Users may choose ISO 25010:2011 or any other standard for the definition of NFR. It is assumed that users will size the NFR based on the definitions they use. This document covers a subset of non-functional types. It is expected that, with time, the state of the art can improve and that potential future versions of this standard can define an extended coverage. The ultimate goal is a version that, together with ISO/IEC 20926:2009, covers every aspect that may be required of any prospective piece of software, including aspects such as process and project directives that are hard or impossible to trace to the software's algorithm or data. The combination of functional and non-functional size would then correspond to the total size necessary to bring the software into existence. Calculating the effort and duration of the implementation of the NFR is outside the scope of this standard.

  • Standard
    76 pages
    English language
    sale 15% off
  • Draft
    76 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the S390 architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures. This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.

  • Standard
    493 pages
    English language
    sale 15% off
  • Draft
    493 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the Itanium™ architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures. This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.Â

  • Standard
    237 pages
    English language
    sale 15% off
  • Draft
    237 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the X86 architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures. This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.Â

  • Standard
    493 pages
    English language
    sale 15% off
  • Draft
    492 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. The LSB specification set is divided into modules, each of which provides fundamental system interfaces, libraries, and runtime environment upon which all conforming applications and libraries using that module depend. The modules of the Linux Standard Base are: LSB Core - core components LSB Desktop - desktop related components LSB Languages - runtime languages LSB Imaging - printing and scanning LSB Trial Use - components that are not yet mandatory Interfaces described in the LSB Core module specification are supplemented by other LSB module specifications. All other modules depend on the presence of LSB Core. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. Architecture-specific parts of of an LSB module specification may also contain additional information that is not referenced in the common part. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification.

  • Standard
    12 pages
    English language
    sale 15% off
  • Draft
    12 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the S390X architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures. This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.

  • Standard
    493 pages
    English language
    sale 15% off
  • Draft
    493 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the S390X architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures. This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.

  • Standard
    250 pages
    English language
    sale 15% off
  • Draft
    250 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the PPC32 architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures. This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.

  • Standard
    256 pages
    English language
    sale 15% off
  • Draft
    256 pages
    English language
    sale 15% off

The LSB Languages specification defines components for runtime languages which are found on an LSB conforming system.Â

  • Standard
    186 pages
    English language
    sale 15% off
  • Draft
    186 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the PPC64 architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures. This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.

  • Standard
    252 pages
    English language
    sale 15% off
  • Draft
    252 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the Itanium™ architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures. This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.Â

  • Standard
    493 pages
    English language
    sale 15% off
  • Draft
    493 pages
    English language
    sale 15% off

The Trial Use Specification defines components which are not required parts of the LSB Specification.Â

  • Technical specification
    519 pages
    English language
    sale 15% off
  • Draft
    525 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the common part of the Desktop module of the Linux Standard Base (LSB). This module provides the fundamental system interfaces, libraries, and runtime environment upon which all conforming applications and libraries depend requiring the LSB Desktop module depend. The common part of LSB Desktop should be used in conjunction with an architecture-specific part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. Architecture-specific parts of LSB Desktop may also contain additional information that is not referenced in the common part. Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.

  • Standard
    2940 pages
    English language
    sale 15% off
  • Draft
    2940 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the PPC32 architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures. This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.

  • Standard
    493 pages
    English language
    sale 15% off
  • Draft
    493 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the S390 architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures. This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.

  • Standard
    253 pages
    English language
    sale 15% off
  • Draft
    253 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the PPC64 architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures. This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.

  • Standard
    493 pages
    English language
    sale 15% off
  • Draft
    493 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the Imaging module of the Linux Standard Base (LSB). This module provides the fundamental system interfaces, libraries, and runtime environment upon which conforming applications and libraries requiring the LSB Imaging module depend. Interfaces described in LSB Imaging are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Imaging module supplement those described in the LSB Core module. They do not depend on other LSB modules.Â

  • Standard
    79 pages
    English language
    sale 15% off
  • Draft
    79 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the X86-64 architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures. This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.Â

  • Standard
    230 pages
    English language
    sale 15% off
  • Draft
    230 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the X86 architecture specific part of the Core module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Core module with those interfaces that differ between architectures. This part should be used in conjunction with LSB Core - Generic, the common part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.Â

  • Standard
    231 pages
    English language
    sale 15% off
  • Draft
    231 pages
    English language
    sale 15% off

The Linux Standard Base (LSB) defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the X86-64 architecture specific part of the Desktop module of the Linux Standard Base (LSB). This part supplements the common part of the LSB Desktop module with those interfaces that differ between architectures. This part should be used in conjunction with the common part of LSB Desktop. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. This part may also contain additional information that is not referenced in the common part. Interfaces described in this part of LSB Desktop are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Desktop module supplement those described in the LSB Core module. They do not depend on other LSB modules.Â

  • Standard
    493 pages
    English language
    sale 15% off
  • Draft
    493 pages
    English language
    sale 15% off

This document defines a system interface for compiled applications and a minimal environment for support of installation scripts. Its purpose is to enable a uniform industry standard environment for high-volume applications conforming to the LSB. These specifications are composed of two basic parts: a common part describing those parts of the interface that remain constant across all implementations of the LSB, and an architecture-specific part describing the parts of the interface that vary by processor architecture. Together, the common part and the relevant architecture-specific part for a single hardware architecture provide a complete interface specification for compiled application programs on systems that share a common hardware architecture. The LSB contains both a set of Application Program Interfaces (APIs) and Application Binary Interfaces (ABIs). APIs may appear in the source code of portable applications, while the compiled binary of that application may use the larger set of ABIs. A conforming implementation provides all of the ABIs listed here. The compilation system may replace (e.g. by macro definition) certain APIs with calls to one or more of the underlying binary interfaces, and may insert calls to binary interfaces as needed. The LSB is primarily a binary interface definition. Not all of the source level APIs available to applications may be contained in this specification. This is the common part of the Core module of the Linux Standard Base (LSB), LSB Core - Generic. This module provides the fundamental system interfaces, libraries, and runtime environment upon which all conforming applications and libraries depend. LSB Core - Generic, the common part, should be used in conjunction with an architecture-specific part. Whenever a section of the common part is supplemented by architecture-specific information, the common part includes a reference to the architecture-specific part. Architecture-specific parts of the LSB Core Specification may also contain additional information that is not referenced in the common part. Interfaces described in this part of the LSB Core Specification are mandatory except where explicitly listed otherwise. Interfaces described in the LSB Core module are supplemented by other LSB modules. All other modules depend on the presence of LSB Core.Â

  • Standard
    1052 pages
    English language
    sale 15% off
  • Draft
    1052 pages
    English language
    sale 15% off

This European Technical Specification will provide a set of requirements for developers of health and wellness apps, intending to meet the needs of health care professionals, patients, carers and the wider public. It will include a set of quality criteria and cover the app project life cycle, through the development, testing, releasing and updating of an app, including native, hybrid and web based apps, those apps associated with wearable, ambient and other health equipment and apps that are linked to other apps. It will also address fitness for purpose and the monitoring of usage. The specification will inform the development of health and wellness apps irrespective of whether they are placed in the market, and including free of charge.
The specification will not cover the processes or criteria that an app developer or publisher follow to establish whether a health and wellness app is subject to regulatory control (e.g. as a medical device, or related to information governance).

  • Technical specification
    87 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This document elaborates requirements and recommendations for certifications schemes based on ISO/IEC 24773-1, which are specific to the domain of systems engineering.

  • Standard
    12 pages
    English language
    sale 15% off
  • Draft
    12 pages
    English language
    sale 15% off

This Software Package Data Exchange® (SPDX®) specification defines a standard data format for communicating the component and metadata information associated with software packages. An SPDX document can be associated with a set of software packages, files or snippets and contains information about the software in the SPDX format described in this specification.

  • Standard
    145 pages
    English language
    sale 15% off
  • Draft
    145 pages
    English language
    sale 15% off

This document provides quality requirements for health apps and defines a health app quality label in order to visualize the quality and reliability of health apps. This document is applicable to health apps, which are a special form of health software. It covers the entire life cycle of health apps. This document is intended for use by app manufacturers as well as app assessment organizations in order to communicate the quality and reliability of a health app. Consumers, patients, carers, health care professionals and their organizations, health authorities, health insurers and the wider public can use the health app quality label and report when recommending or selecting a health app for use, or for adoption in care guidelines, care pathways and care contracts. NOTE 1Â Â Health apps can be subject to national legislation, such as for medical devices. NOTE 2Â Â See Annex C for additional details on the scope. Outside the scope of this document are guidelines to comply to the medical device regulation.

  • Technical specification
    78 pages
    English language
    sale 15% off
  • Draft
    76 pages
    English language
    sale 15% off

This document provides quality requirements for health apps and defines a health app quality label in order to visualize the quality and reliability of health apps.
This document is applicable to health apps, which are a special form of health software. It covers the entire life cycle of health apps.
This document is intended for use by app manufacturers as well as app assessment organizations in order to communicate the quality and reliability of a health app. Consumers, patients, carers, health care professionals and their organizations, health authorities, health insurers and the wider public can use the health app quality label and report when recommending or selecting a health app for use, or for adoption in care guidelines, care pathways and care contracts.
NOTE 1 Health apps can be subject to national legislation, such as for medical devices.
NOTE 2 See Annex C for additional details on the scope.
Outside the scope of this document are guidelines to comply to the medical device regulation.

  • Technical specification
    78 pages
    English language
    sale 15% off

This document provides guidance for the application of ISO/IEC/IEEE 29119 (all parts) in agile life cycles. This document is intended for (and not limited to) testers, test managers, business analysts, product owners, Scrum masters and developers involved in agile projects. The mappings provided in this document are designed to benefit any team or organization that is either moving away from traditional/waterfall life cycles and into agile or vice versa as well as new organizations that are commencing agile as their chosen life cycle. It is designed to be understandable regardless of the reader's familiarity with ISO/IEC/IEEE 29119 (all parts).

  • Technical report
    45 pages
    English language
    sale 15% off
  • Draft
    45 pages
    English language
    sale 15% off

This document specifies requirements and provides guidance for certification bodies providing audit and certification of an ITAMS in accordance with ISO/IEC 19770-1. It does not change the requirements specified in ISO/IEC 19770-1. This document can also be used by accreditation bodies for the accreditation of certification bodies. However, this document does not specify requirements or provides guidance for accreditation bodies to audit certification bodies. A certification body providing ITAMS certification is expected to be able to demonstrate fulfilment of the requirements specified in this document, in addition to the requirements in ISO/IEC 17021-1.

  • Standard
    16 pages
    English language
    sale 15% off
  • Draft
    16 pages
    English language
    sale 15% off

This document provides guidance and recommendations for assurance of a selected claim about the system-of-interest by achieving the claim and showing the achievement. The guidance and recommendations are given in a system assurance process view on top of ISO/IEC/IEEEÂ 15288 and a software assurance process view on top of ISO/IEC/IEEEÂ 12207.

  • Standard
    38 pages
    English language
    sale 15% off
  • Draft
    44 pages
    English language
    sale 15% off

This document provides an explanation of considerations involved in defining a process. This document gives requirements and recommendations for the description of processes by identifying elements and rules for their formulation. This document also describes the use of process views. This document explains how conformance to a process can be defined, when the process is described in accordance with this document. This document does not describe how processes are composed or otherwise aggregated into larger frameworks or life cycle models. Nor does the document cover how to assess or evaluate the performance of a process, or the output (products) of a process. NOTEÂ Â Â Â Â Â Two prominent International Standards in process description for software and system engineering are ISO/IEC/IEEEÂ 12207 and ISO/IEC/IEEEÂ 15288. These two standards have very similar process models. The information items associated with their process definitions are given in ISO/IEC/IEEEÂ 15289. Other International Standards provide further characterization of a single life cycle process by elaborating the process elements and levying specific requirements on the execution of the process. This document is applicable when processes are described for various process definitions in any party, organization or standard relating to systems and software engineering processes.

  • Standard
    28 pages
    English language
    sale 15% off
  • Draft
    28 pages
    English language
    sale 15% off

This document is a specialization of the more general reference model for software and systems product line engineering and management described in ISO/IEC 26550. The specialization defined herein addresses a class of methods and tools referred to as feature-based software and systems product line engineering, or feature-based PLE, which has emerged as a proven and repeatable product line engineering and management (PLE) practice supported by commercial tool providers. This document: —   provides the terms and definitions specific to feature-based PLE; —   defines how feature-based PLE is a specialization within the general ISO/IEC 26550 reference model for product line engineering and management; —   defines a reference model for the overall structure and processes of feature-based PLE and describes how the elements of the reference model fit together; —   defines interrelationships and methods for applying the elements and tools of the product line reference model; —   defines required and supporting tool capabilities. In this document, products of feature-based PLE include digital work products that support the engineering of a system. Some of the artefacts are actually part of the delivered products, while other artefacts can be non-deliverable, such as physical or digital design models. The intended audience for this document comprises: —   technology providers who wish to provide automated tool support for the reference model and processes described in this document; —   champions within an organization who wish to introduce feature-based PLE throughout that organization; —   IT staff within a PLE organization who will introduce and maintain the necessary technology to support feature-based PLE; —   practitioner stakeholders who will use the provided technology to practice feature-based PLE; —   technical and business managers who will sponsor and direct the methods necessary to practice feature-based PLE; —   university professors, researchers, corporate trainers, and other educators who will create and share pedagogical materials about feature-based PLE and its benefits.

  • Standard
    51 pages
    English language
    sale 15% off
  • Draft
    51 pages
    English language
    sale 15% off

This document defines a process assessment model for software life cycle processes, conformant with the requirements of ISO/IEC 33004, for use in performing a conformant assessment in accordance with the requirements of ISO/IEC 33002.

  • Technical specification
    74 pages
    English language
    sale 15% off
  • Draft
    74 pages
    English language
    sale 15% off

The measures in this standard were calculated from detecting and counting violations of good architectural and coding practices in the source code that could result in unacceptable operational risks or excessive costs. Establishing standards for these measures at the source code level is important because they have been used in outsourcing and system development contracts without having international standards to reference. For instance, the ISO/IEC 25000 series of standards that govern software product quality provide only a small set of measures at the source code level. A primary objective of updating these measures was to extend their applicability to embedded software, which is especially important for the growing implementation of embedded devices and the Internet of Things. Functionality that has traditionally been implemented in IT applications is now being moved to embedded chips. Since the weaknesses included in the measures specified in this document have been found to be applicable to all forms of software, embedded software is not treated separately in this specification.

  • Standard
    235 pages
    English language
    sale 15% off
  • Draft
    235 pages
    English language
    sale 15% off

This document provides a profile specification for the organizational management profile. The organizational management profile applies to VSEs involved in systems engineering and/or software engineering development. This document provides links to the subset of ISO/IEC/IEEE 12207 and ISO 9001 organizational, resources, processes and project portfolio process elements from the organizational perspective.

  • Standard
    16 pages
    English language
    sale 15% off
  • Draft
    16 pages
    English language
    sale 15% off

This document defines quality measures useful for requirements and evaluation of IT service quality in terms of characteristics and sub-characteristics defined in ISO/IEC TS 25011. This document contains a basic set of quality measures for each characteristic and sub-characteristic. This document does not assign ranges of values of the quality measures to rated levels or to grades of compliance. Such values are defined based on the nature of the IT service, and so depends on factors such as category of the IT service or users' needs. Some attributes can have a desirable range of values, which does not depend on specific user needs but generic factors, for example, service downtime. This document includes, in Annex A, considerations for the selection and application of quality measures. The quality measures in this document are primarily intended to be used for quality evaluation and improvement of IT services during or after the development life cycle. The main users of this document are people carrying out quality requirements specification and evaluation activities for IT services as part of the following: — development: including requirements analysis, design, implementation, testing and deployment during the development life cycle; — quality management: monitoring activities of quality assurance and performing quality control of an IT service; — supply: making a contract with the user for supplying an IT service under the terms of a contract; — acquisition: including IT service selection, when acquiring or procuring an IT service from a service provider; — maintenance: improvement of an IT service based on quality measurement. The relationship of this document to domain-specific IT service quality model and its precedence over this document is determined by the user in a specific context of use.

  • Technical specification
    23 pages
    English language
    sale 15% off
  • Draft
    23 pages
    English language
    sale 15% off

This document provides a framework for assessor training aimed at training providers who design, develop, and/or deliver training courses for assessors conducting assessments conformant with ISO/IEC 33002. The document defines four training course elements: — Foundation — Process assessment model — Assessor — Practical assessment performance Whilst the training is defined as separate training course elements, the elements can be combined into one or more training courses for delivery. Furthermore, training modules and learning objectives can be addressed in training courses in any combination or sequence.

  • Technical report
    14 pages
    English language
    sale 15% off
  • Draft
    14 pages
    English language
    sale 15% off

This document specifies essential features of terminology management systems, regardless of specific software engineering paradigms, user interface and user assistance design principles, and specific data models. These features enable maximum efficiency and quality in terminology work and, thus, support creating, processing, and using high quality terminology. The intended audiences of this document are software engineers/developers as well as terminologists, technical communicators, translators, interpreters, language planners, and subject field experts.
This document describes all features needed for recording, editing, maintaining, exchanging, and presenting terminological data. Term extraction features used to identify new terms are out of the scope of this document.

  • Standard
    17 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Standard
    17 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Standard
    12 pages
    English language
    sale 15% off
  • Draft
    17 pages
    English language
    sale 10% off
    e-Library read for
    1 day

This document provides model, high-level functional requirements and associated guidance for software applications that are intended to manage digital records (including digital copies of analogue source records), either as the main purpose of the application or as a part of an application that is primarily intended to enable other business functions and processes.
It does not include:
— functional requirements for applications that manage analogue records;
— generic design requirements such as reporting, application administration and performance;
— requirements for the long-term preservation of digital records in a dedicated preservation environment;
NOTE The model requirements are intended to encourage the deployment of applications that do not hinder long-term preservation of records. As such, some of the requirements support long-term digital preservation outcomes.
— implementation guidance for applications that manages analogue and/or digital records. Such guidance can be found in ISO/TS 16175-2:—[1].
[1] Under development. Stage at the time of publication: ISO/DTS 16175-2:2020.

  • Standard
    44 pages
    English language
    sale 10% off
    e-Library read for
    1 day
  • Standard
    37 pages
    English language
    sale 15% off
  • Standard
    40 pages
    French language
    sale 15% off

This document provides a framework and consistent terminology for specifying user requirements. It specifies the common industry format (CIF) for a user requirement specification including the content elements and the format for stating those requirements.
NOTE 1 A user requirements specification is the formal documentation of a set of user requirements, which aids in the development and evaluation of usable interactive systems.
In this document, user requirements refers to:
a) user-system interaction requirements for achieving intended outcomes (including requirements for system outputs and their attributes);
b) use-related quality requirements that specify the quality criteria associated with the outcomes of users interacting with the interactive system and can be used as criteria for system acceptance.
NOTE 2 ISO/IEC 25030 introduces the concept of quality requirements. The use-related quality requirements in this document are a particular type of quality requirement.
The content elements of a user requirements specification are intended to be used as part of documentation resulting from the activities specified in ISO 9241-210, and from human centred design processes, such as those in ISO 9241-220.
This document is intended to be used by requirements engineers, business analysts, product managers, product owners, and people acquiring systems from third parties.
The CIF series of standards addresses usability-related information (as described in ISO 9241-11 and ISO/IEC TR 25060).
NOTE 3 In addition to usability, user requirements can include other perspectives, such as human-centred quality introduced in ISO 9241-220, and other quality perspectives presented in ISO/IEC 25010, ISO/IEC TS 25011, and ISO/IEC 25030.
NOTE 4 While this document was developed for interactive systems, the guidance can also be applied in other domains.
This document does not prescribe any kind of method, lifecycle or process. The content elements of a user requirements specification can be used in iterative development which includes the elaboration and evolution of requirements (e.g. as in agile development).

  • Standard
    30 pages
    English language
    sale 10% off
    e-Library read for
    1 day