Description of the modules of an optimal requirements management system for working with aviation projects

А bstract. The article provides information that reveals such concepts as requirement, requirements management. In particular, the necessary specifics for collecting requirements in aviation projects, the scheme for working with requirements, processing requirements, as well as necessary activities such as validation and verification are given. How the above processes interact with each other, as well as their attributes in the requirements management system. Data on the required level of rigor in the collection of requirements and their impact on certification processes are given. The purpose of the article is to show an approach to the development of a more mature requirements management system, to describe the necessary modules in the development of such a system. Show how the system can be divided into subsystems for more detailed study and organization of work with requirements. For each module of subsystems and the system as a whole, select data types and justify them.


Introduction
Aviation projects in modern realities are controlled according to the rules and within the framework of software products under the general name of PLM Software (Product Life Cycle Management or PLM Software). This type of management shows us that the main requirements come from business ideas in the first stage. At this stage, the main requirements are laid down in the commercial offer of the airline as a future product.
Before a newly created aircraft model is put into operation, the main regulatory authorities must verify that all aircraft type requirements are fully met. For an effective requirements management process, the right set of validated and verified requirements must be implemented [1].
The term "requirement" is defined in the Merriam-Webster Dictionary as "something necessary for the existence or occurrence of something else." According to the current specifics, this second "something" is an aviation project or product.
The IEEE 610.  standard explains the term "requirement" in the following sentence: a condition or capability that a user needs to solve a problem or achieve a goal. A condition or capability that a system or system component must meet or have in order to comply with a contract, standard, specification, or other legally mandated document.
Most of the requirements management solutions on the market are related to software development, and there are no solutions at all that can take into account critical moments in aviation projects. The main problem with the use of modern software products is the overly common methods of collecting, tracking and verifying requirements. Even most complex and expensive products on the market do not take into account aviation specifics such as levels of rigor or information architecture requirements. Cheap and free requirements management tools are mostly effective for software products with short validation/verification cycles [2].
According to aviation specifics, the main goal is to find an effective way to build a fundamentally new requirements management tool. This tool can play a role among other application tools or complex software products and provide a higher level of automation and assistance to requirements managers and stakeholders when they are working on projects with multiple iterations in the field of requirements management from multiple sources [3].
While working with requirements, we need to consider another important term for the topic. Requirements management is a series of processes whose main objectives are: -Collection of actions on requirements using various systems; -Analysis of requirements for the current goals of the project; -Tracking requirements from system level to subsystem or function level; -Prioritization and coordination of requirements; -Controlling changes and informing relevant stakeholders. All these activities are continuous processes throughout the project. Each requirement in itself can be a standard that the result of the project must meet.
We must also take into account the main activities that requirements management should support the project: the collection of requirements, as well as the validation and verification processes.
After analyzing the existing requirements tools both in application schemes for working with requirements, and in variable software solutions, including specific ones, and large PLM software systems, depending on the level of complexity of the project, they all provide mechanisms similar to each other for automating various processes to improve the collection requirements, validation and verification processes, or often just verification [4].
After a brief review of the options and tools provided to solve the main problem, it was revealed that the most relevant are RT-matrices (requirements traceability matrices) of various types. These tools are particularly interesting in that they can solve many problems in software projects, as they are widely used in such areas of requirements accounting. In aviation projects, a new approach based on these tools can help to improve the quality of requirements management in terms of the level of stringency and aspects of FDAL/IDAL. For the proposed system as a function, in order to improve the quality of the validation and verification processes, the main problems of requirements management processes that need to be solved are highlighted: usability and traceability improvements that make the conceptual diagrams easier to understand for requirements managers and stakeholders; -checking the level of severity, checking FDAL / IDAL; -correct choice of test method; -a control system that improves the whole process and the resulting scheme for the correct requirements management structure, or at least offers an option for the relevant personnel.
The idea of building a simple, flexible tool can fill a gap in the market between simple requirements capture in simple spreadsheets and complex requirements management solutions that are often part of large PLM tools with high annual costs. This work will focus on user-friendly interface, flexibility, ease of data transfer, and import/export actions. In the diagram above, we see the circles of activities, which basically represent the activities in the requirements management system for their validation and verification. The yellow line shows verification and the red line shows validation. In general, we can say that the red line represents the question: "Does the stated function achieve the goal of the stakeholder?" and the yellow line represents the question: "Are the goals achievable within the proposed function?"

Approach to Requirements Management Processes: Validation
First of all, the difference between validation and verification processes should be defined. In regards to the validation process, we say that something must be verified through an actionoriented approach. In an engineering sense, there is a system or project that must meet the requirements or needs of interested parties (or customers). In general, for aviation projects it is more appropriate to talk about stakeholders and certification regulators.
The objectives of requirements validation are derived from the objectives of the requirements [5]. To implement an improved approach to validation activities, the following objectives can be applied, which should be noted during the validation process: -Checking the compliance of the project with the expectations and requirements of stakeholders; -Testing a real product or application; -Detection, correction and reporting of errors or defects in the application; -Execution of the product; -Validation methods -functional testing, regression testing, system testing, system integration testing, user acceptance testing, non-functional testing, etc.
-Falls under the category of quality control. A comprehensive analysis shows that for complex projects, the following actions should be applied as part of an improved validation process: -In different requirements, logical consistency should be checked. This activity helps to formally verify that there is no logical inconsistency in the provided parts of the requirement and similar requirements; -Scenario Compatibility Check to verify that the scenario meets the given constraints and the parts of the requirement under consideration; -Checking whether the current setting of the requirement matches the actual setting of the function being tested.
The provided actions can provide additional diagnostic data about the requirements in various forms: -If the requirements management system checks for consistency and the script succeeds, you can generate a trace that indicates consistency. In this way, all constraints regarding the current requirement can be satisfied and, in case of contention, if the consistency and scenario checks fail, the requirements management system can provide trace evidence that the current requirement violates the applicable constraints; -When the specification for the current requirement is inconsistent and/or the scenario is incompatible, the requirements management system may indicate that it does not have a scenario that can be associated with the provided part of the requirement. The requirements management system indicates to the manager such information to support the identification of the required requirement and provides options on how it can be solved [6][7][8].

Approach to Requirements Management Processes: Verification
The verification process should take a function, system or subsystem oriented approach. In other words, this process occurs in order for a system or design to meet specifications or requirements that have been collected.
Verification assumes the structural correctness of the knowledge base, that is, its internal consistency and completeness. Among the challenges is the taxonomy, which refers to the key milestones and activities in the project implementation process. Such a taxonomy should be able to go beyond project types, and the tendency to redefine it for each project or subset of data should be avoided [9].
Improved verification processes should be accompanied by the following principles: -Uniqueness The requirement documentation has only one verification plan and one verification summary. The tool being developed will provide this part in the form of a requirements management matrix.
-Level To provide improved verification work from the system level to the subsystem level, it is required to separate the necessary processes into levels. The lower-level requirements verification evidence is used as input to the upper-level requirements integration verification, and each level requirement must ensure that the corresponding verification is correct and complete.
-Completeness The verification of each requirement must be completed by the process. The developed tool should display the degree of completion and help highlight those requirements for which there is no progress.
-Diversity The time required to verify different requirements of the same system can vary. Some requirements can be verified in a short time, but some requirements require a long period of time to be verified.
-Severity All functional requirements verification activities in the enhanced tool shall be formulated and selected according to the Functional Development Assurance Level (FDAL) and Element Development Assurance Level (IDAL) in the requirements verification activities. This activity is mandatory because aviation projects have certification requirements for a stakeholder analysis process that does not appear in other projects and thus is not reflected in ongoing verification process activities [10][11][12].

Suggested system for dealing with requirements
Lack of information regarding the level of rigor and the roles of requirements validation/verification will lead to excessive ambiguity and insufficient control.
Consideration should be given to a new system with improved validation and verification processes for aviation projects in relation to the following aspects: -SMART principles should be applicable to such a system; -Unambiguity must be applied to provide only one interpretation. Validators and verifiers should have the same understanding of the purpose of the requirement; -completeness. Requirements related processes such as decomposition, distribution and verification should have all the necessary data applicable for a proper verification and verification process; -feasibility. Thus, the requirements of the upper level can usually be confirmed in the technical and economic plan of the lower level; -verifiability. Different types of requirements need to be validated differently, and this will affect the way requirements are written, so the appropriate validation methods need to be validated synchronously after the requirements are written; -correctness and consistency. The interested party must be sure that there is a correct expression of each requirement and is written in strict accordance with the project and in accordance with uniform standards [13].
For a more detailed consideration of the system, it will be divided into two subsystems: -subsystem of validation processes; -subsystem of verification processes.

Subsystem of validation processes
The validation process is the establishment of the facts that a system or design must meet the requirements or needs of interested parties and certification regulators. The validation subsystem, based on the range of validation activity, should solve the following separate tasks: check whether the implemented design solutions are consistent and can be models.
-check whether the models provide the desired functions.
-check whether the purpose of this function is representative (validation process) in accordance with the stakeholder analysis.
In accordance with these tasks, it is possible to single out the main elements of the subsystem that must be implemented: -Validation method and executor -in this part, the method is closely related to the executor and can be considered as a whole. If each method is not associated with an executor, there should be two separate columns [14]. Methods can be selected according to the level of FDAL/IDAL -Validation status -the main marker that can control each requirement. The main function of this element is a signal to the main performers who are responsible for the requirements and push for action.
-Validation Conclusion -the decision made at the end of the requirements review by the reviewer responsible for the framework.
-Conclusion on the correctness and completeness -provides general information about the work performed for each requirement. This element shows if all processes around the requirement are in accordance with all procedures and complete information and provided by the main actors.
-The main text of the requirement in natural language or the plot of the requirement, which contains the initial description [15,16].
In essence, we can say that these elements are the main specifications of the solution model-based design approach.
Thus, the main modules that appear in the subsystem as elements of the entire system are highlighted: -Text module requirements -Validation method and executor module -Validation status module -Validation Conclusion Module -Module "Conclusion on correctness and completeness"

Subsystem of verification processes
This subsystem has to deal with the processes associated with the verification circle mentioned above. Thus, the verification subsystem must solve the following separate tasks: -Set requirements and target values; -Complete the development of the intended function; -Check whether the development of the goal brings the right design solution; -Check if the requirement is verified (satisfy the requirement).
In accordance with these tasks, it is possible to single out the main elements of the subsystem that must be implemented [17,18].
Requirement ID -A complex ID can be an effective tool for tracking requirements and automatically collecting metadata for efficient database operation.
Feature/Natural Language Text -The body or story of the requirement contains the initial description of the requirement.
Feature/Element Development Assurance Level -Represents the minimum level of rigor of the development assurance tasks performed on features and/or features. According to ARP4754, this element notifies which verification method should be used for the current requirement.
Requirement Type -defines the requirement, further highlights the validation method, and also helps to rank it in a complex database [19].
Verification data -to provide the necessary information about the implemented design solution in order to verify whether it is achievable for the target requirements value.
It is also worth noting that some elements from the validation subsystem should be duplicated here as service ones, but in a real system their source will be common [20][21]. We have placed the requirements module here to ensure the correct collection of requirements for the verification subsystem, functional analysis and architecture development.

Conclusion
Since we have determined that there must be a single solution to bring all subsystems together, we will use the Requirements Traceability Matrix as a common tool for organizing requirements data. The necessary elements of the subsystem in the future requirements management system mentioned in the article will have to move into the status of software modules, get their specific functions, acquire relationships and data types that should accompany information about the requirements in this particular case. Further development of this work should go towards clarifying the functionality of this module by adding the necessary data attributes for the subsequent development of the system, establishing data levels, communicating with the initiators of collecting and working with data, and testing the theoretical scheme of the requirements management system.