Back

Establish, implement, and maintain a system requirements specification.


CONTROL ID
01035
CONTROL TYPE
Systems Design, Build, and Implementation
CLASSIFICATION
Preventive

SUPPORTING AND SUPPORTED CONTROLS



This Control directly supports the implied Control(s):
  • Establish, implement, and maintain a system design project management framework., CC ID: 00990

This Control has the following implementation support Control(s):
  • Include relevant resources needed for the system design project in the system requirements specification., CC ID: 01036
  • Include system interoperability in the system requirements specification., CC ID: 16256
  • Include pertinent legal requirements in the system requirements specification., CC ID: 01037
  • Assign senior management to approve functional requirements in the system requirements specification., CC ID: 13067


SELECTED AUTHORITY DOCUMENTS COMPLIED WITH



  • AIs should adopt and implement a full project life cycle methodology governing the process of developing, implementing and maintaining major computer systems. In general, this should involve phases of project initiation, feasibility study, requirement definition, system design, program development, … (4.2.1, Hong Kong Monetary Authority: TM-G-1: General Principles for Technology Risk Management, V.1 – 24.06.03)
  • App 2-1 Item Number II.1(8): When formulating the development plan, the organization must consider the system development methodology, system characteristics, and scale of development and ensure they are based on a target scale and specific system requirements. This is a control item that constitute… (App 2-1 Item Number II.1(8), App 2-1 Item Number II.2(2), Appendix 1 Correspondence of the System Management Standards - Supplementary Edition to other standards)
  • The FI should identify, define and document the functional requirements for the IT system. In addition to functional requirements, key requirements such as system performance, resilience and security controls, should also be established and documented. (§ 5.5.1, Technology Risk Management Guidelines, January 2021)
  • Security requirements should minimally cover key control areas such as access control, authentication, authorisation, data integrity and confidentiality, system activity logging, security event tracking and exception handling. (§ 5.4.3, Technology Risk Management Guidelines, January 2021)
  • Identification of recordkeeping requirements through consultation of sources relevant to project requirements is called for, as is the identification of any regulatory requirements regarding the development or management of recordkeeping systems. (§ C.4, The DIRKS Manual: A Strategic Approach to Managing Business Information, rev. July 2003)
  • In their system description, the cloud provider provides comprehensible and transparent specifications regarding the cloud service, which allow an expert third party to assess the general suitability of the cloud service for the desired application. The system description describes the following asp… (Section 4 UP-01 Basic requirement ¶ 1, Cloud Computing Compliance Controls Catalogue (C5))
  • meet regulatory and contractual requirements. (5.2.6 ¶ 1 Bullet 5, ITIL Foundation, 4 Edition)
  • The user requirement specifications should be complete, definitive, realistic, and testable. (¶ 9.2, Good Practices For Computerized systems In Regulated GXP Environments)
  • There should be no conflicts between the requirements in the user requirement specifications. (¶ 9.3 Bullet 2, Good Practices For Computerized systems In Regulated GXP Environments)
  • The functional specifications should provide a precise and detailed description for each essential requirement, including functions, performances, design constraints, and attributes. (¶ 10.2, Good Practices For Computerized systems In Regulated GXP Environments)
  • Identify, prioritise, specify and agree on business functional and technical requirements covering the full scope of all initiatives required to achieve the expected outcomes of the IT-enabled investment programme. (AI1.1 Definition and Maintenance of Business Functional and Technical Requirements, CobiT, Version 4.1)
  • The systems development lifecycle should cover specifying requirements. (CF.17.01.02-1, The Standard of Good Practice for Information Security)
  • Business requirements should cover the need for system performance (e.g., processing speeds and response times). (CF.18.01.02a, The Standard of Good Practice for Information Security)
  • Business requirements should cover the need for system capacity (e.g., number of users or volume and size of transactions). (CF.18.01.02b, The Standard of Good Practice for Information Security)
  • Business requirements should cover the need for system continuity (e.g., maximum length of time to recover key components following a system failure / outage). (CF.18.01.02c, The Standard of Good Practice for Information Security)
  • Business requirements should cover the need for system scalability (e.g., to support future developments or changes). (CF.18.01.02d, The Standard of Good Practice for Information Security)
  • Business requirements should cover the need for system connectivity (e.g., interfaces to existing systems, networks, or external resources). (CF.18.01.02e, The Standard of Good Practice for Information Security)
  • Business requirements should cover the need for system compatibility (e.g., with particular technical environments or components). (CF.18.01.02f, The Standard of Good Practice for Information Security)
  • Business requirements should cover fall-back / contingency plans. (CF.18.01.04e, The Standard of Good Practice for Information Security)
  • Business requirements should cover the reduction or elimination of single-points-of-failure. (CF.18.01.04f, The Standard of Good Practice for Information Security)
  • Business requirements should cover requirements for access by particular types of user (e.g., internal users, support staff, external parties, or the general public). (CF.18.01.06a, The Standard of Good Practice for Information Security)
  • Business requirements should cover requirements for access from particular locations (e.g., home offices, external party premises, or mobile environments). (CF.18.01.06b, The Standard of Good Practice for Information Security)
  • Business requirements should cover the need for system performance (e.g., processing speeds and response times). (CF.18.01.02a, The Standard of Good Practice for Information Security, 2013)
  • Business requirements should cover the need for system capacity (e.g., number of users or volume and size of transactions). (CF.18.01.02b, The Standard of Good Practice for Information Security, 2013)
  • Business requirements should cover the need for system continuity (e.g., maximum length of time to recover key components following a system failure / outage). (CF.18.01.02c, The Standard of Good Practice for Information Security, 2013)
  • Business requirements should cover the need for system scalability (e.g., to support future developments or changes). (CF.18.01.02d, The Standard of Good Practice for Information Security, 2013)
  • Business requirements should cover the need for system connectivity (e.g., interfaces to existing systems, networks, or external resources). (CF.18.01.02e, The Standard of Good Practice for Information Security, 2013)
  • Business requirements should cover the need for system compatibility (e.g., with particular technical environments or components). (CF.18.01.02f, The Standard of Good Practice for Information Security, 2013)
  • Business requirements should cover fall-back / contingency plans. (CF.18.01.04e, The Standard of Good Practice for Information Security, 2013)
  • Business requirements should cover the reduction or elimination of single-points-of-failure. (CF.18.01.04f, The Standard of Good Practice for Information Security, 2013)
  • Business requirements should cover requirements for access by particular types of user (e.g., internal users, support staff, external parties, or the general public). (CF.18.01.06a, The Standard of Good Practice for Information Security, 2013)
  • Business requirements should cover requirements for access from particular locations (e.g., home offices, external party premises, or mobile environments). (CF.18.01.06b, The Standard of Good Practice for Information Security, 2013)
  • The project plan shall state the Risk Management activity requirements, including a plan to meet the requirements of the medical Information Technology network. (§ 4.5.2.3 ¶ 1(a)(2), Application of risk management for IT-networks incorporating medical devices Part 1: Roles, responsibilities and activities, Edition 1.0 2010-10)
  • The project plan shall state the project description, including the project requirements specification. (§ 4.5.2.3 ¶ 1(b)(2), Application of risk management for IT-networks incorporating medical devices Part 1: Roles, responsibilities and activities, Edition 1.0 2010-10)
  • § 7.1(b): The organization shall determine the need for establishing documents, processes, and providing resources specific to the product while planning product realization. § 7.2.1: The organization shall determine customer requirements, including delivery and post-delivery activities; customer … (§ 7.1(b), § 7.2.1, § 7.3.2, ISO 13485:2003 Medical devices -- Quality management systems -- Requirements for regulatory purposes, 2003)
  • The organization shall identify the objectives, goals, and outcomes for each project. (§ 6.2.3.3(a)(3), ISO 15288-2008 Systems and software engineering - System life cycle processes, R 2008)
  • The organization shall define sequences to identify the required services needed for anticipated operational scenarios and environments and support scenarios and environments. (§ 6.4.1.3(b)(2), ISO 15288-2008 Systems and software engineering - System life cycle processes, R 2008)
  • The organization shall state the stakeholder requirements and functions for health. (§ 6.4.1.3(b)(4), ISO 15288-2008 Systems and software engineering - System life cycle processes, R 2008)
  • The organization shall state the stakeholder requirements and functions for safety. (§ 6.4.1.3(b)(4), ISO 15288-2008 Systems and software engineering - System life cycle processes, R 2008)
  • The organization shall state the stakeholder requirements and functions for security. (§ 6.4.1.3(b)(4), ISO 15288-2008 Systems and software engineering - System life cycle processes, R 2008)
  • The organization shall state the stakeholder requirements and functions for the environment. (§ 6.4.1.3(b)(4), ISO 15288-2008 Systems and software engineering - System life cycle processes, R 2008)
  • (§ 8.4(c), ISO 15489-1:2001, Information and Documentation: Records management: Part 1: General)
  • § 5.2.1: For software systems assigned to Class A, Class B, and Class C software safety classes, the medical device manufacturer shall define and document software system requirements from the system level requirements for each of the software systems used by the medical device. § 5.2.2: For soft… (§ 5.2.1, § 5.2.2, ISO 62304 - 2006 Medical device software - Software life cycle processes, 2006)
  • the results to be achieved are defined; (8.3.4 ¶ 1(a), ISO 9001 Quality Management systems - Requirements, Fifth edition 2015-09-15)
  • Likewise, management usually discloses only the principal system requirements that are relevant to or affected by the trust services category or categories addressed by the examination. When identifying which system requirements to disclose, service organization management may consider matters such … (¶ 3.28, SOC 2® Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy, October 15, 2022)
  • An established software requirements specification is required to complete the software validation process. (§ 4.1, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, Version 2.0)
  • The software specification document must identify what, when, why, and how elements are to be achieved with an engineering level of detail, so that it can be confirmed through testing. (§ 5.2.5 ¶ 5, General Principles of Software Validation; Final Guidance for Industry and FDA Staff, Version 2.0)
  • Identification of functional requirements. (App A Objective 12:2b, FFIEC Information Technology Examination Handbook - Architecture, Infrastructure, and Operations, June 2021)
  • The security and control issues should be identified and should be considered throughout the lifecycle. (Pg 19, Pg 20, FFIEC IT Examination Handbook - Development and Acquisition)
  • The NIST 800 series calls for the identification of functional requirements but do not specifically address the identification of regulatory requirements as part of the project management control objective. (§ 3.4.3, Generally Accepted Principles and Practices for Securing Information Technology Systems, NIST SP 800-14, September 1996)
  • Develop supply chain, system, network, performance, and cybersecurity requirements. (T0414, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Develop detailed design documentation for component and interface specifications to support system design and development. (T0464, National Initiative for Cybersecurity Education (NICE) Cybersecurity Workforce Framework, NIST Special Publication 800-181)
  • Hardware and software requirements; (§ 3.6 ¶ 5 Bullet 5, NIST SP 800-34, Contingency Planning Guide for Federal Information Systems, Rev. 1 (Final))
  • When a development system is new, the process applied for selecting security controls is from a requirements definition perspective. The chosen security controls will serve as a security specification and should be incorporated into the system. (§ 3.3 ¶ New Development and Legacy Systems, Recommended Security Controls for Federal Information Systems, NIST SP 800-53)
  • Develop detailed design documentation for component and interface specifications to support system design and development. (T0464, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)
  • Develop supply chain, system, network, performance, and cybersecurity requirements. (T0414, Reference Spreadsheet for the Workforce Framework for Cybersecurity (NICE Framework)”, July 7, 2020)