Technical Specification Analysis is one of the verification activities of the ISVV process (Figure 8). The Technical Specification Analysis is generally the first verification activity to be performed after the ISVV level definition at the software requirements level.
Figure 8 Technical Specification Analysis in context
The Technical Specification Analysis activity aims to verify the software requirements against the following criteria:
– correctness and completeness of the software requirements
– software requirements externally consistency to system partitioning and system requirements
– software requirements externally and internally consistent (not implying formal proof consistency)
– software requirements unambiguous and verifiable
– the software requirements related to safety and dependability correct (as shown by suitably rigorous methods)
The Activity also aims to identify potential test cases which may be given special attention during subsequent activities of the independent software verification and validation processes.
MAN. Management
IVA. Independent Validation IVE. Independent Verification
IVE.DA.Design Analysis IVE.CA.Code Analysis MAN.VV. ISVV level definition
IVA.Validation
MAN.PM.ISVV Process Management
IVE.TA.Technical Specification Analysis
System Requirements
Figure 9 Technical Specification Analysis activity8 5.1.1 Software requirements verification
The Technical Specification contains the software requirements which have been defined by the software supplier to represent the system requirements allocated to software in the Requirements Baseline. It is necessary to verify that this representation in terms of function, capability, performance, safety, dependability, qualification, human factors, data definitions, documentation, installation and acceptance, and operation and maintenance is complete, correct, consistent, accurate, readable, and testable.
This verification is shown in Figure 10 below.
Figure 10 Software Requirements Verification
8 Note that figure shows only the most important inputs and outputs.
SW Requirements
•Verify SW requirements correctness with respect to system requirements
•Verify consistent documentation of SW requirements
•Verify dependability and safety of requirements
•Verify readability of SW requirements
•Verify timing and sizing budgets of SW requirements
•Verify that SW requirements are testable
•Verify feasibility of producing an architectural design
•
•Verify SW requirements correctness with respect to system requirements and Interfaces
•Verify consistent documentation of SW requirements
•Verify dependability and safety of requirements
•Verify readability of SW requirements
•Verify timing and sizing budgets of SW requirements
•Verify that SW requirements are testable
•Verify SW requirements conformance with applicable standards
Software Requirements Verification
5.2 Activity Inputs and Prerequisites
The input work products are listed in Figure 9 showing the Technical Specification Analysis activity.
The inputs to the Technical Specification Analysis activity should comprise a mature, stable, and self-consistent set to ensure that the analysis conducted on them is useful. A set of inputs which meet these criteria is available for the customer’s Preliminary Design Review.
5.3 Activity Outputs
The output work products are listed in Figure 9 showing Technical Specification Analysis activity.
Verification reports include at least overall analysis of the work products analysed, findings, list of open issues to probe further on subsequent analysis, suggested modifications (if any), and inputs for independent validation test cases specification. Traceability matrices might be provided as annexes of verification reports or as separate documents.
5.4 Activity Management
5.4.1 Initiating and Terminating Events
The activity will be initiated on receipt of the required inputs. A suitable set of input documents will be contained in the Data pack submitted by the software supplier for the customer’s Preliminary Design Review.
The activity will be terminated on completion of the verification tasks which have been selected by the customer during verification process implementation as identified in the ISVV Plan. The final outputs will be submitted to the customer’s ISVV Technical Specification Analysis Review Meeting.
5.4.2 Completion Criteria
The completion of the Requirements Traceability Matrices and Requirements Verification Report and their submission to the ISVV customer contribute to the completion of the activity.
The customer’s ISVV Technical Specification Analysis Review Meeting, with the participation of all involved parties, will allocate final dispositions to the findings of the activity.
5.4.3 Relations to other Activities
Safety-critical and mission-critical design drivers may be identified for further analysis in the Design Analysis Activity. Potential test cases may be identified for the Validation Activity.
5.5 Task Descriptions
5.5.1 Software Requirements Verification
TASK DESCRIPTION
Title: Software Requirements Verification Task ID: IVE.TA.T1
Activity: IVE.TA - Technical Specification Analysis Start event: PDR - Preliminary Design Review
End event: TAR - Technical Specification Analysis Review Responsible: ISVV Supplier
Objectives: - Verify that the representation by the software requirements of the system requirements allocated to software is complete, correct, consistent, accurate, readable, and testable.
Inputs - From the ISVV Customer:
- System Requirements allocated to Software [RB; SRR]
- Software Requirements Specification [TS; PDR]
- Software Logical model [TS, PDR]
- Interface Control Document [ICD(TS); PDR]
- Hardware-Software Interface Requirements [RB; SRR]
- Software Criticality Analysis Report [PAF; SRR]
- From the ISVV Supplier:
- Critical Software Requirements List(refer to [MAN.VV.T2]) - ISVV level definition (refer to MAN.VV.T2)
Sub Tasks (per ISVV Level):
- ISVV Level 1 and Level 2:
- IVE.TA.T1.S1: Verify the Software Requirements external consistency with the system requirements (by Inspection - reviewing the traceability matrices produced by the software supplier):
Ensure that all system requirements allocated to software are traceable to software requirements (forward traceability).
Ensure that every software requirement is traceable to a system requirement (backward traceability).
Ensure that the relationships between the software requirements and their originating system requirements are specified in a uniform manner (in terms of level of detail and format).
Ensure that the characteristics specified in the system requirements allocated to software are accurately specified by the traced software requirements.
- IVE.TA.T1.S2: Verify the Interface Requirements external consistency with the system requirements (by Inspection - reviewing the traceability matrices produced by the software supplier and in case they do not exist, by producing them):
Ensure that all system requirements referring to interfaces and all interface requirements are traceable to interface specifications (forward traceability).
Ensure that every interface specification is traceable to a system or interface requirement (backward traceability).
Ensure that the interface specifications correctly represent the system interface requirements allocated to software and the interface requirements. Ensure that data and control flows, data usage and format, and performance are considered.
Ensure that the relationships between the interface specifications and their originating system or interface requirements are specified to a consistent level of detail.
Ensure that the characteristics specified in the system requirements referring to interfaces and the interface requirements are accurately specified by the traced interface specifications.
- IVE.TA.T1.S3: Verify software requirements correctness (by Inspection or Modelling9or Formal methods9) Ensure that the relationship between each software requirement and its originating system requirement is correct.
Ensure that the precision specified for interfaces and calculations represents the requirements of the system.
Ensure that the modelled physical phenomena agree with system accuracy requirements and physical laws.
- IVE.TA.T1.S4: Verify the consistent documentation of the software requirements (by Inspection or Modelling9or Formal Methods9)
9Applicable only to a range of software requirements.
Ensure that the software requirements are documented to a consistent level of detail.
Ensure that the interface specifications are documented to a consistent level of detail.
Ensure that interactions between software requirements and assumptions embedded in them are consistent and represent system requirements.
- IVE.TA.T1.S5: Verify software requirements completeness (by Inspection or Modelling9)
Ensure that the software requirements, within the assumptions and constraints of the system, represent all the characteristics of the system designated to the software including functional and performance specifications, software product quality requirements, security specifications, human factors engineering (ergonomics) specifications and data definition and database requirements.
Ensure that the software requirements include also the specification of the interfaces external to the software item.
When in flight modification is specified for flight software, ensure also that the software requirements include specifications for in flight.
- IVE.TA.T1.S6: Verify the dependability and safety requirements (by Inspection or SFMECA10 or Modelling) Ensure that the software requirements and interface specifications correctly represent the system requirements
relating to safety and dependability allocated to software.
Ensure that the software requirements and interface specifications address all the safety and dependability aspects introduced by the system requirements allocated to software.
Ensure that requirements are defined to control software’s contribution to system hazardous events by analysing software failure modes and their possible propagation to system level. (e.g. ensure robustness related mechanisms, such as exception handling, are properly defined.”).
Ensure that the software requirements describe proper features for Fault Detection Isolation And Recovery (FDIR) in accordance with the system requirements allocated to software.
Ensure that the implemented FDIR mechanisms are independent of the faults that they are supposed to deal with.
- IVE.TA.T1.S7: Verify the readability of the software requirements (by Inspection)
Ensure that the software requirements documentation has a clear and consistent structure and that software requirements are free from ambiguous terms.
Ensure that the documentation is intelligible for its target readers and that all the required elements for its understanding are provided (e.g. definition of acronyms, terms, and conventions).
- IVE.TA.T1.S8: Verify the timing and sizing budgets of the software requirements (by Inspection)
Ensure that the software requirements for timing and sizing budgets (e.g. memory usage, CPU utilization, etc.) correctly represent the system performance requirements allocated to software.
Ensure that the software requirements for timing and sizing budgets (e.g. memory usage, CPU utilization, etc.) are specified with the accuracy required by the system performance requirements allocated to software.
Ensure that the acceptance criteria for validating the software timing and sizing budgets (e.g. memory usage, CPU utilization, etc.) requirements are objective and quantified.
- IVE.TA.T1.S9: Identify test areas and test cases for Independent Validation (from IVE.TA.T1 tasks or Modelling) Identify software requirements which cannot be analysed adequately for independent verification and which,
therefore, require execution of independent validation tests. Annotate this information (e.g. requirements, test case.) as a contribution to the Independent Validation activities.
- IVE.TA.T1.S10: Verify that the software requirements are testable (by Inspection)
Ensure that the acceptance criteria for validating the software requirements are objective and quantified.
Ensure that each software requirement is testable to objective acceptance criteria.
Ensure that software requirements are unambiguous.
- IVE.TA.T1.S11: Verify software requirements conformance with applicable standards (by Inspection) Ensure that the software requirements are compliant to applicable standards, references, regulations, policies,
physical laws, and business rules.
Outputs: - Technical Specification Verification Report (including the ISVV findings) - Contribution to Independent Validation
10 In case the SFMECA was applied in the criticality analysis performed at requirements level for the ISVV level definition (MAN.VV activity) any RIDs generated then should be added to this technical specification verification report.
6.0 Design Analysis