=Paper=
{{Paper
|id=Vol-2853/paper15
|storemode=property
|title=Method for Determining the Informativeness of the Software Requirements Specifications
|pdfUrl=https://ceur-ws.org/Vol-2853/paper15.pdf
|volume=Vol-2853
|authors=Ivan Lopatto,Mykyta Lebiga,Yurii Forkun,Artem Boyarchuk
|dblpUrl=https://dblp.org/rec/conf/intelitsis/LopattoLFB21
}}
==Method for Determining the Informativeness of the Software Requirements Specifications==
https://ceur-ws.org/Vol-2853/paper15.pdf
Method for Determining the Informativeness of the Software
Requirements Specifications
Ivan Lopattoa, Mykyta Lebigaa, Yurii Forkuna and Artem Boyarchukb
a
Khmelnytskyi National University, Institutska str., 11, Khmelnytskyi, 29016, Ukraine
b
National Aerospace University “Kharkiv Aviation Institute”, Chkalova str., 17, Kharkiv, 61000, Ukraine
Abstract
A critical influence on software projects and on the success of their realization is exerted by
issues related to the analysis and evaluation of the software requirements specifications
(SRS). Today, when the number of high-budget software projects is growing rapidly, it is
important to analyze the SRS, in particular, to determine their informativeness to assess the
quality of software according to ISO 25010: 2011. The conducted analysis of the known tools
for SRS’ analysis showed that none of the known tools provides the possibility of
determining the informativeness of the requirements specification. Therefore, it is necessary
to design and implement the criteria and method for determining the informativeness of the
SRS (which would be the theoretical basis for developing a future tool for determining the
informativeness of requirements specifications), which is the purpose of this study. The paper
proposes criteria and a method for determining the informativeness of the software
requirements specifications, which determine the informativeness of the specification in
terms of determining on its basis the characteristics of the software quality. The proposed
criteria and method for determining the informativeness of the specifications of the software
requirements allow determining the informativeness of the specification in terms of
determining on its basis each of the 8 characteristics of the software quality.
Keywords 1
Software requirements specification (SRS), the informativeness of the requirements
specification, criteria for determining the informativeness of the requirements specifications,
method for determining the informativeness of the requirements specifications.
1. Introduction
The software development life cycle begins with the formation of a set of requirements and
specification of software requirements based on them.
The largest number of software bugs are made at the stage of requirements formation [1, 2] – by
the statistics, 56% of all software bugs are introduced at the stage of formation of requirements; about
50% of the bugs in requirements are the result of poorly written, unclear, ambiguous or incorrect
requirements; the other 50% are due to incomplete specifications (incomplete and omitted
requirements) [3]. The distribution of software bugs by development phase is represented in Figure 1.
Clear requirements have 13% of the weight in project success factors [4]. The source of 56 percent of
all software bugs is the requirements formation phase (Figure 2) [3]. Statistics show that inaccurate
requirements are one of the primary causes of software failures [5, 6]. Software projects, the
specification of the requirements for which contains insufficient, inaccurate, incomplete, and
contradictory information, cannot be successfully realized [2]. The vast majority of software-related
IntelITSIS’2021: 2nd International Workshop on Intelligent Information Technologies and Systems of Information Security, March 24–26,
2021, Khmelnytskyi, Ukraine
EMAIL: ivan.lopatto@gmail.com (I. Lopatto); lebiganikita1996@gmail.com (M. Lebiga); forkun@ridne.net (Y. Forkun),
a.boyarchuk@csn.khai.edu (A. Boyarchuk)
ORCID: 0000-0001-6886-2238 (I. Lopatto); 0000-0002-5849-1514 (M. Lebiga); 0000-0002-7906-4191 (Y. Forkun), 0000-0001-7349-1371
(A. Boyarchuk)
© 2021 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR Workshop Proceedings (CEUR-WS.org)
accidents are caused by erroneous requirements, not coding errors. 60% time and cost are paid on
projects with requirements of poor quality [3].
Figure 1: Distribution of defects in software projects by development phase [3]
Figure 2: Time and cost premiums on requirements of low quality [3]
82% of application rework is related to requirements bugs [3]. The earlier the bug (error, violation,
defect, and malfunction) is detected, the cheaper it will be to correct it. As the interval between the
time of introduction and detection of the defect increases, the cost of its correction increases sharply.
The longer the bug persists in the software development chain, the more it penetrates other parts of
the software, the more damage it causes in the following stages, and the more money will have to be
spent on its elimination. By the statistics, the cost of correcting the software bugs, which are made in
the early stages of the life cycle, increases exponentially with each following stage of the life cycle
(Figure 3) [3]. Figure 3 shows a comparison of the system cost-to-fix results NASA obtained from
various methodologies, while Figure 4 compares system results with the software cost models from
the earlier examined studies [3]. The cost of correcting incorrect requirements in the specification,
which are identified after the release of the product, is almost 100 times higher than the cost of
correcting the shortcomings of the specification, which were identified at earlier stages, in particular,
at the same stage of requirements' formation [7].
The importance and impact of business requirements on the success of the enterprise through
software projects found that 68% of companies suffer from the poor practice of technical
requirements and that these companies [3]:
• Spent 49% more money on application delivery
• 79% of projects have overtime and overbudget
• More than 39% of the time was spent on application delivery
• More than 41.5% of new resources were used to develop projects for poorly defined
requirements
In fact, the study [3] showed that 79% of companies use “common” (unstructured) natural
language requirements' documents, 16% use “structured” natural language, templates and forms.
Only 5% of the surveyed companies said they were using formal approaches like Model-based system
engineering (MBSE) (Figure 5).
Figure 3: Comparison of System Cost Factors – Excluding Operations [3]
Figure 4: Comparison of Software and System Cost Factors [3]
Figure 5: Time and cost premiums on low quality requirements [3]
The risks of an insufficiently worked out stage of requirements formation are non-compliance with
project deadlines and financial overspending, which can lead to the closure of the project, and even
the collapse of the software company due to its financial instability [8-13].
In the requirements formation process, information losses emerge because of incompleteness and
difference of understanding of the users' needs and context of information – especially such losses are
significant for multidisciplinary software projects that are developed at the intersection of subject
areas [8-18]. Therefore, for ensuring the quality and safety of software, it is necessary to conduct a
study of software requirements – in order to identify and eliminate problems and shortcomings in the
early stages of the software life cycle and identify the lack of relevant information.
Thus, the critical impact on software projects and the success of their implementation are issues
related to the analysis and evaluation of the initial stages of the life cycle. Today, when the number of
high-budget software projects is growing rapidly, it is important to analyze the specifications of
software requirements, in particular, to determine their informativeness for assessing the quality of
software according to ISO 25010: 2011.
2. State-of-the-art
Today, the key to assessing the quality of the software is the approach based on the SQuaRE
model (ISO 25010:2011 standard). Software quality assessment according to ISO 25010:2011 [19] is
as follows: based on the quality attributes specified in ISO 25023: 2016 [20], sub-characteristics and
quality characteristics are evaluated.
Important criteria for specifying software requirements in terms of future software quality
assessment are:
1. Completeness of the requirements specification
2. Sufficiency of information in the requirements
3. Informativeness of the requirements specification
Let's explore the known tools of the analysis of requirements in order to determine such criteria, as
well as the possibility of their free use (Table 1).
Table 1
State-of-the-art on known tools for software requirements specifications’ analysis
Tools Completeness Sufficiency of Informativeness Free
of the information of the access
requirements in the requirements
specification requirements specification
CORE [21] + - - ?
Visure [22] + - - ?
Accompa [23] + - - -
Innoslate [24] + - - -
ReqView [25] + - - ?
Modern Requirements4TFS [22] + - - ?
QVscribe [3] + - - ?
Requirements Analysis Tool [23] + - - ?
QARCC [24] + - - ?
Requirements Assistant [25] + - - -
QuARS Requirements Analysis [24, 26] + - - -
DESIRe [27] + - - -
RQV Tool [27] - - - -
IT for assessing the initial stages of the - + - +
software life cycle [9, 10]
Software quality evaluation and - - - +
prediction system [28, 29]
Thus, as the conducted analysis of the known tools for software requirements specifications'
analysis showed that none of the known tools provides the possibility of determining the
informativeness of the requirements specification. Therefore, it is necessary to develop and implement
criteria and method for determining the informativeness of software requirements specifications
(which would be the theoretical basis for developing a future tool for determining the informativeness
of requirements specifications), which is the purpose of this study.
3. Criteria and method for determining the informativeness of the software
requirements specifications
Criteria for evaluating information, according to [30, 31], are:
1. Relevance – determining whether this information can help in the future to assess the quality
of software according to ISO 25010
2. Veracity – the extent to which the description of the information is true; how the description
of the information corresponds to reality
3. Significance – understanding of information, completeness of coverage of the subject of
interest, timeliness of the information and its sufficiency for decision-making
4. Novelty – how the information's description is new for the user
5. Actuality – the degree of compliance of information with the current time
6. Objectivity – characterizes the independence of information from someone's opinion or
consciousness, as well as from methods of obtaining
7. Completeness – information can be considered complete if it contains a minimum set of
quality measures, but sufficient to make a correct decision
8. Compliance – the degree of compliance of information to the needs of consumers
9. Adequacy – compliance with the content of the actually obtained information and its expected
content
10. Accessibility – a measure of the ability to obtain information
To assess the informativeness of the specification of software requirements, it is necessary to
assess the informativeness of the quality measures of the specification in terms of their impact on the
characteristics of the software quality.
Criteria of informativeness of quality measures of the SRS:
1. Relevance Rv = {Rsp, Abci}, where Rsp € [0;1] – the rank of the influence of the quality
measure of the specification on a certain characteristic, where 0 – corresponds to the smallest
influence of the quality measure of the specification on the characteristic, 1 – corresponds to the
greatest influence; Abci € [0;1] – the rank of the ability of the quality measure to clarify the value
of the software quality characteristic, where 0 means that the measure least clarifies the value of
the characteristic, 1 – means the greatest degree of clarification
2. Veracity Rb € [0;1], where 1 – it's possible to trust to the measure of determining the
characteristic of software quality; 0 – cannot be trusted in principle
3. Significance Sf = {Ust, Cnc}, where Ust € [0;1] – the rank of understanding the quality
measure, where 0 – the measure is unclear, 1 – the measure is clear; Cnc € [0;1] – the rank of
completeness of the coverage of the quality characteristic by the measure, where 0 – the measure
least covers the characteristic, 1 – the most illuminates the characteristic
4. Objectivity Obj € [0;1], where 0 – quality measure depends on someone's opinion or
consciousness, as well as on the methods of obtaining, 1 – independent measure
5. Compliance Qi € [0;1], where 0 – the lowest degree of conformity of the quality measure to
the characteristic, 1 – the highest degree
As for other criteria for evaluating information, they will not be needed to assess the
informativeness of the software specification due to their redundancy and repeatability.
Taking into account the above criteria of informativeness of the measures of the specification of
requirements, the method of determining the informativeness of the specification of software
requirements consists of the following stages:
1. Division of the interval into subintervals for each software quality characteristic
2. Evaluation of all measures of each quality characteristic according to each of the criteria of
informativeness of quality measures of the specification of requirements
3. Sorting of quality measures of the specification of requirements and assignment to each
measure of the corresponding rank
4. Formation of a matrix of informativeness of measures for each characteristic of the software
quality
5. Calculation of the indicator of informativeness of the specification on the definition of each of
the software quality characteristics
The interval [0; 1] is divided into subintervals depending on how many quality measures of the
specification affect the quality characteristic:
𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄 𝑜𝑜𝑜𝑜 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 = 𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄𝑄 𝑜𝑜𝑜𝑜 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚 − 1. (1)
Then for an ideal specification, in which there are absolutely all the measures on which the quality
characteristics depend, the number of subintervals, the step and the division of the interval into
subintervals for each software quality characteristic are presented in Table 2.
Table 2
The number of subintervals, the step and the division of the interval into subintervals for each
software quality characteristic – for an ideal specification, in which there are absolutely all the
measures on which the quality characteristics depend
Quality characteristic Quantity of Quantity of Step Dividing the
different subintervals interval into
measures subintervals
(to determine
the ranks)
Functional Suitability 9 8 1/8=0.125 [0; 0.125;…;
0.875; 1]
Performance Efficiency 23 22 1/22=0.0455 [0; 0.0455;…;
0.9545; 1]
Usability 44 43 1/43=0.0233 [0; 0.0233;…;
0.9767; 1]
Reliability 25 24 1/24=0.0417 [0; 0.0417;…;
0.9583; 1]
Compatibility 8 7 1/7=0.1429 [0; 0.1429;…;
0.8571; 1]
Security 15 14 1/14=0.0714 [0; 0.0714;…;
0.9286; 1]
Maintainability 26 25 1/25=0.04 [0; 0.04;…;
0.96; 1]
Portability 16 15 1/15=0.0667 [0; 0.0667;…;
0.9333; 1]
Then there is an expert assessment of the importance of each measure of quality characteristic
according to a certain criterion, sorting of measures is performed, and each measure is assigned a
corresponding rank.
The result of such assessments is the matrix of informativeness of measures for each j-th
characteristic (j=1..8):
Rsp1j Abci1j Rb1j Ust1j Cnc1j Obj1j Qi1j
Ij = … … … … … … …
Rspnj Abcinj Rbnj Ustnj Cncnj Objnj Qinj
where the first line contains estimates for the measure №1 of j-th characteristic, the second line
contains estimates for the measure №2 of j-th characteristic, etc., the last line contains estimates for
the measure №n of j-th characteristic (number of measures are different for each characteristic and
maximum of the number of measures are presented in Table 2 for each characteristic). Thus, we
obtain 8 matrices of informativeness of measures for 8 main characteristics of software quality.
Next, it is necessary to assess the informativeness of the specification for the definition of each of
the characteristics. To do this, it's necessary to calculate for each matrix the number of elements
belonging to a certain range – Qiij, after this to find the informativeness of the specification for
determining each of the characteristics as the ratio of the obtained number Qiij to the total size of each
j-th matrix (7*nj):
𝑄𝑄𝑄𝑄𝑄𝑄 𝑗𝑗 (2)
𝐼𝐼𝐼𝐼_𝑆𝑆𝑆𝑆𝑆𝑆𝑗𝑗 = � � ∗ 100%.
7 ∗ 𝑛𝑛 𝑗𝑗
The obtained indicator will reflect the informativeness of the specification for determining the j-th
characteristic of the software quality.
Thus, the criteria and method for determining the informativeness of the specifications of the
software requirements are proposed, which determine the informativeness of the specification in
terms of determining on its basis the characteristics of the software quality.
4. Results & discussion
For example, let's consider the measures on which Functional Suitability depends (according to
ISO 25010, ISO 25023):
1. Number of Functions
2. Functional Implementation Completeness
3. Functional Adequacy
4. Functional Implementation Coverage
5. Operation Time
6. Number of Inaccurate Computations Encountered by Users
7. Number of Data Items
8. Computational Accuracy
9. Precision
The number of measures on which the Functional Suitability characteristic depends is 9. All 9
measures of the Functional Suitability are present in the first considered specification. Then the
number of subintervals is 8, so the step is 1/8 = 0.125. We then divide the interval as follows:
[0; 0.125; …; 0.875; 1]. Next, we evaluate with the help of experts each measure of the characteristic
according to a certain criterion, sort the measures and assign each measure the appropriate rank.
For example, let's consider how the experts recommended assessing the influence of each quality
measures of the specification on the characteristic Functional Suitability. Thus, the most influential,
according to experts, is the measure Number of Functions (rank 1), next in influence is the measure
Operation Time (rank 0.875), then the measure Functional Implementation Completeness (rank 0.75),
then Functional Implementation Coverage (rank 0.625), then Functional Adequacy (rank 0.5), then
Precision (rank 0.375), then Number of Data Items (rank 0.25), then Computational Accuracy (rank
0.125), and the least influential is the Number of Inaccurate Computations Encountered by Users
(rank 0).
Similarly, the experts recommended assessing the rank of the ability of each quality measure to
clarify the value of Functional Suitability, the veracity of each measure to determine the characteristic
Functional Suitability, the rank of understanding of each quality measure of Functional Suitability, the
rank of completeness of the coverage of Functional Suitability by each measure, the objectivity of
each measure of the Functional Suitability characteristic, compliance of each measure concerning the
definition of the Functional Suitability characteristic.
The result of such estimates is a matrix of informativeness of measures for the Functional
Suitability characteristic:
1 0.625 1 0.875 1 0.875 0.625
0.75 1 0.875 0.625 0.875 0.25 0.875
0.5 0.875 0.75 0.375 0.625 0.125 0.75
0.625 0.75 0.625 0.5 0.75 0 1
IFS1 = 0.875 0.5 0.5 1 0.375 0.75 0.375
0 0.125 0 0 0.25 0.375 0.25
0.25 0.375 0.375 0.75 0.5 1 0.5
0.125 0.25 0.25 0.125 0.125 0.5 0
0.375 0 0.125 0.25 0 0.625 0.125
Let's calculate for the obtained matrix the number of elements that belong to a certain range – Qiij.
For example, let's calculate the number of elements that belong to the range [0.5; 1], because experts
recommend just such an interval for Functional Suitability. Under such conditions, Qiij = 35 for the
obtained matrix.
Then the informativeness of the specification for determining the Functional Suitability
characteristic is:
35
𝐼𝐼𝐼𝐼_𝑆𝑆𝑆𝑆𝑆𝑆 𝐹𝐹𝐹𝐹1 = �� ∗ 100% = 55.56%.
7∗9
Only 5 measures of the Functional Suitability (1.Number of Functions; 2.Functional
Implementation Completeness; 3.Functional Adequacy; 4.Functional Implementation Coverage;
5.Operation Time) are present in the second considered specification. Then the number of
subintervals is 4, so the step is 1/4 = 0.25. We then divide the interval: [0; 0.25; …; 0.75; 1]. Next, we
evaluate with the help of experts each measure of the characteristic according to a certain criterion,
sort the measures and assign each measure the appropriate rank. For example, the influence of each
quality measures on the Functional Suitability: Number of Functions – rank 1, Operation Time – rank
0.75, Functional Implementation Completeness – rank 0.5, Functional Implementation Coverage –
rank 0.25, Functional Adequacy – rank 0.
Similarly, the experts recommended assessing the remaining ranks of each of 5 present quality
measures of Functional Suitability.
The result of such estimates is a matrix of informativeness of 5 measures for the Functional
Suitability characteristic:
1 0. 25 1 0.75 1 1 0.25
0.5 1 0.75 0.5 0.75 0.5 0.75
IFS2 = 0 0.75 0.5 0 0.25 0.25 0.5
0.25 0.5 0.25 0.25 0.5 0 1
0.75 0 0 1 0 0.75 0
Let's calculate for the obtained matrix the number of elements that belong to a certain range – Qiij.
For example, let's calculate the number of elements that belong to the range [0.75; 1], because experts
recommend just such an interval for Functional Suitability, if Functional Suitability depends on not all
9 measures, but only 5 measures. Under such conditions, Qiij = 14 for the obtained matrix.
Then the informativeness of the specification for determining the Functional Suitability
characteristic is:
14
𝐼𝐼𝐼𝐼_𝑆𝑆𝑆𝑆𝑆𝑆 𝐹𝐹𝐹𝐹2 = �
� ∗ 100% = 40%.
7∗5
It is obvious that if the specification of requirements contains a smaller number of quality
measures for a certain characteristic, then the informativeness of the specification for determining
such a characteristic is lower (in the considered examples – by 15.56% while reducing the number of
measures by 4). Similarly, the matrices of the informativeness of the remaining 7 software quality
characteristics can be obtained and, accordingly, the informativeness of the specification for
determining each of the remaining 7 software quality characteristics can be calculated.
Therefore, the proposed criteria and method for determining the informativeness of the
specifications of the software requirements allow determining the informativeness of the specification
in terms of determining on its basis each of the 8 characteristics of software quality.
5. Conclusions
A critical influence on software projects and on the success of their realization is exerted by issues
related to the analysis and evaluation of the software requirements specifications (SRS). Today, when
the number of high-budget software projects is growing rapidly, it is important to analyze the SRS, in
particular, to determine their informativeness to assess the quality of software according to ISO 25010.
The conducted analysis of the known tools for SRS’ analysis showed that none of the known tools
provides the possibility of determining the informativeness of the requirements specification.
Therefore, it is necessary to design and implement the criteria and method for determining the
informativeness of the SRS (which would be the theoretical basis for developing a future tool for
determining the informativeness of requirements specifications), which is the purpose of this study.
The paper proposes criteria and a method for determining the informativeness of the software
requirements specifications, which determine the informativeness of the specification in terms of
determining on its basis the characteristics of the software quality. The proposed criteria and method
allow determining the informativeness of the specification in terms of determining on its basis each of
the 8 characteristics of the software quality.
6. References
[1] S. McConnell, Code complete, Microsoft Press, Redmond, 2013.
[2] N. Levenson, Engineering a safer world: systems thinking applied to safety, MIT Press,
Massachusetts, 2012.
[3] Leveraging natural language processing in requirements analysis: How to eliminate over half of
all design errors before they occur, 2020. URL: https://qracorp.com/wp-
content/uploads/2020/10/Leveraging-NLP-in-Requirements-Analysis.pdf.
[4] 4-Step project plan for 2020, 2020. URL: http://projexs.io/project-plan-made-easy/.
[5] PMI’s Pulse of the Profession 9-th Global Project Management Survey, 2017. URL:
https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-
of-the-profession-2017.pdf.
[6] Sh. Sarif, S. Ramly, R. Yusof, N. Fadzillah, N. Sulaiman, Investigation of success and failure
factors in IT project management. Advances in Intelligent Systems and Computing 739 (2018)
671-682. doi: 10.1007/978-981-10-8612-0_70.
[7] C. Shamieh, Systems engineering for dummies, Wiley Publishing, Hoboken, 2014.
[8] O. Pomorova, T. Hovorushchenko, The way to detection of software emergent properties, in:
Proceedings of the 2015 IEEE 8-th International Conference on Intelligent Data Acquisition and
Advanced Computing Systems: Technology and Applications, IDAACS’2015, Warsaw, 2015,
vol. 2, pp. 779-784. doi: 10.1109/IDAACS.2015.7341409.
[9] T. Hovorushchenko, O. Pavlova, M. Bodnar, Development of an intelligent agent for analysis of
nonfunctional characteristics in specifications of software requirements. Eastern-European
Journal of Enterprise Technologies 1 2 (2019) 6-17. doi: 10.15587/1729-4061.2019.154074.
[10] T. Hovorushchenko, O. Pavlova, Evaluating the software requirements specifications using
ontology-based intelligent agent, in: Proceedings of 2018 IEEE International Scientific and
Technical Conference “Computer Science and Information Technologies”, СSIT’2018, Lviv,
2018, vol.1, pp.215-218. doi: 10.1109/STC-CSIT.2018.8526730.
[11] T. Hovorushchenko, O. Pomorova, Evaluation of mutual influences of software quality
characteristics based ISO 25010:2011, in: Proceedings of 2016 International Scientific and
Technical Conference “Computer Science and Information Technologies”, CSІТ’2016, Lviv,
2016, pp. 80-83. doi: 10.1109/STC-CSIT.2016.7589874.
[12] A. Boyarchuk, O. Pavlova, M. Bodnar, I. Lopatto, Approach to the analysis of software
requirements specification on its structure correctness. CEUR-WS 2623 (2020) 85-95.
[13] A. Melnyk, B. Dunets, FFT processor IP Cores synthesis on the base of configurable pipeline
architecture, in: Proceedings of the 7th International Conference on Experience of Designing and
Application of CAD Systems in Microelectronics, CADSM’2003, Slavske, 2003, pp. 211–213.
doi: 10.1109/CADSM.2003.1255034.
[14] T. Hovorushchenko, A. Herts, Ye. Hnatchuk, Concept of intelligent decision support system in
the legal regulation of the surrogate motherhood. CEUR-WS 2488 (2019) 57-68.
[15] O. Drozd, M. Kuznietsov, O. Martynyuk, M. Drozd, A method of the hidden faults elimination in
FPGA projects for the critical applications, in: Proceedings of 2018 IEEE 9th International
Conference on Dependable Systems, Services and Technologies, DESSERT’2018, Kyiv, 2018,
pp. 231 – 234. doi: 10.1109/DESSERT.2018.8409131.
[16] A. Drozd, J. Drozd, S. Antoshchuk, V. Nikul, M. Al-dhabi, Objects and methods of on-line
testing: main requirements and perspectives of development, in: Proceedings of 2016 IEEE East-
West Design & Test Symposium, EWDTS’2016, Yerevan, 2016, pp. 72 – 76. doi:
10.1109/EWDTS.2016.7807750.
[17] M. Drozd, A. Drozd, Safety-related instrumentation and control systems and a problem of the
hidden faults, in: Proceedings of the 10th International Conference on Digital Technologies,
Zhilina, 2014, pp. 137–140. doi: 10.1109/DT.2014.6868692.
[18] A. Drozd, M. Drozd, V. Antonyuk, Features of hidden fault detection in pipeline components of
safety-related system. CEUR-WS 1356 (2015) 476–485.
[19] ISO/IEC 25010:2011. Systems and software engineering. Systems and software Quality
Requirements and Evaluation (SQuaRE). System and software quality models. [Introduced
01.03.2011]. Geneva (Switzerland), 2011. (International standard).
[20] ISO 25023:2016. Systems and software engineering. Systems and software Quality
Requirements and Evaluation (SQuaRE). Measurement of system and software product quality.
[Introduced 31.03.2016]. Geneva (Switzerland), 2016. (International standard).
[21] Software Requirements Engineering Tools, 2018. URL: http://ecomputernotes.com/software-
engineering/softwarerequirementsengineeringtools.
[22] 30 Best Requirements Management Tools in 2019, 2019, URL:
https://www.guru99.com/requirement-management-tools.html.
[23] K. Verma, A. Kass, Requirements analysis tool: a tool for automatically analyzing software
requirements documents. Lecture Notes in Computer Science 5318 (2008) 751-763. doi:
10.1007/978-3-540-88564-1_48.
[24] H. Mahmood, M. Rehman, Tools for software engineers. IMPACT: International Journal of
Research in Engineering & Technology 3 10 (2015) 75-86.
[25] V. Jones, J. Murray, Evaluation of current requirements analysis tools capabilities for IV&V in
the requirements analysis phase, 2017, URL: https://www.slideserve.com/shlomo/evaluation-of-
current-requirements-analysis-tools-capabilities-for-ivv-in-the-requirements-analysis-phase.
[26] D. Raffo, R. Ferguson, Evaluating the Impact of The QuARS Requirements Analysis Tool Using
Simulation, 2018, URL:
https://pdfs.semanticscholar.org/7e7d/4e6f5ab13d00ca57c87711e30cd080730f34.pdf.
[27] F. Konig, L. Ballejos, M. Ale, A semi-automatic verification tool for software requirements
specification documents, in: Proceedings of Simposio Argentino de Ingeniería de Software.
Argentina, 2017.
[28] O. Pomorova, T. Hovorushchenko, Research of artificial neural network's component of software
quality evaluation and prediction method, in: Proceedings of the 2011 IEEE 6-th International
Conference on Intelligent Data Acquisition and Advanced Computing Systems: Technology and
Applications, IDAACS’2011, Prague, 2011, vol. 2, pp. 959-962. doi:
10.1109/IDAACS.2011.6072916
[29] O. Pomorova, T. Hovorushchenko, Artificial neural network for software quality evaluation
based on the metric analysis, in: Proceedings of IEEE East-West Design & Test Symposium,
EWDTS’2013, Kharkiv, 2013, pp.200-203. doi: 10.1109/EWDTS.2013.6673193
[30] I. Nezhdanov, Information assessment criteria (importance, accuracy, significance), 2010. URL:
http://www.police-russia.ru/showthread.php?t=44683.
[31] Information bases of computing: Information, 2015. URL:
https://intuit.ru/studies/courses/3657/899/info.