A requirement is a need or expectation that is stated, generally implied or obligatory. ‘Generally implied’ means that it
is custom or common practice for the organization, its customers, and other interested parties, that the need or expectation
under consideration is implied.
The term ‘requirement’ defines a bounded characterisation of the scope of the system. It contains the information essential
to support the operation/operators. Some of these requirements include product requirement, quality management requirement,
customer requirement, functional capacity, execution capability, operational usability, information needed to support validation,
installation and commissioning, SLC documentation required, user's manuals, training, maintenance manual, system maintenance,
system test plan, acceptance criteria and regulatory compliance (i.e., EU Annex 11).
Management starts with requirements gathering and concludes when all requirements have been verified or tested. Requirements
can be generated by different interested parties. The scope of the system generates many of the requirements for the operation
to be supported and these requirements are typically provided by the system owner. The majority of the development of computer
systems fails due to poor gathering of requirements, which negatively affects subsequent development activities and associated
The RS is the deliverable in which all requirements are identified. It describes what the system is supposed to do from process,
safety, user and compliance perspectives. The RS deliverable may be used as a framework to select the supplier/integrator
and to develop the PQ protocol.
The RS deliverable should include an overview of the process in order to familiarize the application software developer with
the user, process and data acquisition requirements of the system, and any special considerations for the project. The system
functionality must be well defined at the outset in order to provide the prospective supplier/integrator with enough information
to provide a detailed and meaningful quotation. Specifically, on data acquisition systems, the RS deliverable must include
definitions of the data to be collected, how the data will be used, how it will be stored and retention requirements, data
security requirements and where each operation will be completed.
The RS deliverable addresses:
- the scope of the system and strategic objectives
- the problem to be solved
- process overview, sequencing requirements, operational checks
- sufficient information to enable the supplier/integrator to work on a solution to the problem (e.g. device driven sequencing,
the methods required of the presentation of data, data security, data backup, data and status reporting and trending).
- redundancy and error-detection protocol
- operating environmental
- interfaces (e.g., to field devices, data acquisition systems, reports and HMI), I/O lists, communications protocols and data
- information gained from operators and supervisors on the system design requirements and expectations in order to influence
how the system is designed and operated
- type of control and process operations to be performed
- data storage requirements
- transaction/data timing requirements and considerations
- regulatory requirements
- preliminary evaluation of the technology
- feasibility studies and preliminary risk assessment
- safety and security considerations
- security, other requirements
- nonfunctional requirements (e.g., SLC development standards, programming language standards, program naming convention standards).
Each requirement in the RS deliverable must be unambiguous, verifiable, traceable, modifiable, usable, consistent (individual
requirements must not conflict with each other) and complete.
The RS deliverable is confirmed in a test and/or operating environments during the PQ. This must include the verification
of the procedural controls associated with the system that were identified in the RS deliverable. Some requirements may be
verified before reaching the qualification phase in the formal validation process.
After the approval of the requirements document, the requirements traceability initiates. It is a sub-discipline of requirements
management within software development and systems engineering. Requirements traceability documents the life of a requirement
and provides bi-directional traceability between various associated requirements. It enables users to find the origin of each
requirement and track every change that was made. For this purpose, it may be necessary to document every change made to the
requirement. Traceability is an essential aspect during the verification activities in the SLC, and provides important input
into design reviews.
The above represent my recommendations, but there are many ways to implement the management of computer system requirements.
Applicable from creation to eventual disposal, records management may include classifying, storing, securing, and destruction
(or in some cases, archival preservation) of records. The ISO 15489: 2001 standard defines records management as "The field
of management responsible for the efficient and systematic control of the creation, receipt, maintenance, use and disposition
of records, including the processes for capturing and maintaining evidence of and information about business activities and
transactions in the form of records".
The general principles of records management apply to records in any format. Digital records (almost always referred to as
electronic records or e-records) raise specific issues. It is more difficult to ensure that the content, context and structure
of records is preserved and protected when the records do not have a physical existence. Undoubtedly the area in which most
Annex 11 recommendations are made is e-records and how to manage them.
Annex 11 e-records management recommendations can be categorized according to the e-record life cycle concept. This is a requirement
in understanding any discussion about the controls necessary for proper treatment to ensure authenticity and reliability of
records. Such a life cycle may be characterized as periods representing creation, access and use, and destruction.