During forming and formulating the requirements, it is important to comply with the standards that govern the software development process. The main basic standard for specifying the software requirements is ISO/IEC/IEEE 29148:2018, which regulates the structure and required items of the specification. Result of such analysis is: the known models, methods and tools don't solve the problem of software requirements specification analysis on its structure correctness (according to ISO/IEC/IEEE 29148:2018). In this paper, the authors have proposed the formalization of the structure of software requirements specification (according to ISO/IEC/IEEE 29148:2018) in the form of set-theoretical models of sections of the specification. The approach to the analysis of software requirements specification on its structure correctness (according to ISO/IEC/IEEE 29148:2018) was developed. This approach made it possible to perform a quick automated check of the software requirements specification on consideration of the above-defined specification's items. Such check allows making the automatic conclusion about the correctness/incorrectness of the structure of the specification, about the possibility of further work on the project according to such specification or about the need for re-work of the specification.
Nowadays, software systems are large and complex. They operate in complex and changing environments. The entire infrastructure (languages, libraries, operating systems, and computers) changes continuously. Often software systems are crucial for the operation of the entire business; hence there are quality, schedule and budget pressures. Software systems are part of larger systems (involving humans), which often need to change along changing/developing a software system. Frequent failures of software projects today reassure us that the problems of software construction have not been solved. The main reason of software's failures and crashes is bad documentation at the design stage. Bad documentation leads to many bugs and decreases efficiency at every stage of a software’s development, causes the software project's failure or challenges [1].
In the past, the Standish Group International defined the success of software project considering the triple constraint (standard for the Project Management Institute) and classified software projects as successful, challenged or failed projects. The software project was a successful project if it met all three constraints (schedule, cost, and scope). The software project was a challenged project if it met two from three constraints (for example, on time and on the budget but with incomplete functionality). The software project was a failed project if it is cancelled before it is completed. Now the Standish Group International considers the customer value's delivery, compliance with the strategic objectives and satisfaction of the customer in determining the success of projects [2].
To date, software projects success rates are as follows – Figure 1 [2].
As Figure 1 shows, Agile-projects are more successful than Waterfall-projects, but Agile-methodology is not suitable for all types of software projects (for example, only Waterfall-methodology is acceptable for critical application software). In addition, among both Agile-projects and Waterfall-projects, half (1/2) of all projects are challenged, i.e. they usually have development time delays, budget overruns, or lack the required features.
Software project success factors are represented on Figure 2 [3]. Obviously, the clear requirements make up 13% in project success factors.
Many of the developers of software think that “documentation (in particular, requirements)” is a set of verbose, poorly structured, introductory descriptions which count the thousands of pages. Many of the traditional engineers consider the documentation as the primary design means. Developers of software consider the documentation as an afterthought because they don't know how software documents must be precisely composed. In fact, it should represent forethought, not an afterthought. Advantages of good documentation are facilitating the reuse of previous designs, improving the communication on requirements, increasing the efficiency of design reviews, facilitating the integration of individual modules, increasing the efficiency of inspection of code, increasing the efficiency of testing, and increasing the efficiency of corrections and improvements [1].
In [4] the authors proved that many software-related incidents and catastrophes due
to erroneous requirements, due to their lack of clarity, due to incorrect specification
structure, etc., therefore, the dependence of success of the software project
implementation from the specification of requirements exists, so an in-depth analysis of the
specification of software requirements is necessary. In [5] - [7] concept of estimating
the information sufficiency in the specifications of the requirements for the software
was developed, which has some actuality and necessity. The structure of the
specifications
Then analysis of software requirements specification on its structure correctness
Let's review the results of research to search the known tools, techniques and models, which are devoted for analysis of specifications of requirements for software – Figure 3.
Fig. 3. Tools, techniques and models for analysis of specifications of requirements for software
Therefore, the results of such analysis - the known tools, techniques and models
don't solve the problem of structure correctness
Considering the defined urgency and importance of the problem of determination
of structure correctness of specification of requirements for the software, the goal of
such study is the development of the approach to the determination of structure
correctness
Given the structure of the specification of the software requirements in accordance with ISO 29148:2018, let's represent the specification in the following formalized form:
SRS=<S_1,…,S_19>, where S_1 – section “Purpose” of the software requirements specification, S_2 – section “Scope”, S_3 – section “Product perspective”, S_4 – section “Product functions”, S_5 – section “User chararcteristics”, S_6 – section “Limitations”, S_7 – section “Assumptions and dependencies”, S_8 – section “Apportioning of requirements”, S_9 – section “Specific requirements”, S_10 – section “External interfaces”, S_11 – section “Functions”, S_12 – section “Usability requirements”, S_13 – section “Performance requirements”, S_14 – section “Logical database requirements”, S_15 – section “Design constraints”, S_16 – section “Standards compliance”, S_17 – section “Software system attributes”, S_18 – section “Verification”, S_19 – section “Supporting information” of the software requirements specification.
Sections of specification of the requirements for the software consist of a set of
items
S_1 = {ps},
S_2 = {isp, spd, spb, spo, spg, cssh}, S_3 = {srrp, sosi, soui, sohi, soswi, soci, som, soo, sosar},
S_4 = {mf}, (1) (2) (3) (4) S_6 = {rp, hwl, ioa, plo, af, cf, holr, shp, quar, ca, ssc, pmc},
S_5 = {gcigu, gciu},
S_7 = {far}, S_8 = {asrse, crtf, crte, rduf},
S_9 = {rlds, iss, oss, fss}, S_10 = {ni, dp, sido, vrat, um, tg, roio, sfo, wfo, df, cmf, emsg},
S_11 = {faapi, fapgo, vci, eso, ras, ep, rsoi},
S_12 = {ubr, mec, mefc, msc}, S_13 = {snr, dnr, nts, nssu, athi, nota, not, adnw, adpw, prq},
S_14 = {tiuvf, fqu, asc, der, ics, drr},
S_15 = {ces, crr, cpl},
S_16 = {rf, dn, ap, at}, S_17 = {rb, avb, scr, cct, slhd, fdm, csa, dicv, dp, mb, pb, pehdc, pchd, uppl, upcls, upos},
S_18 = {va, mqs}, S_19 = {siof, dcas, rus, sbi, dpss, spi}, (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) where ps – purpose of software; isp – the software product's identifying, spd – what software product will provide, spb – benefit of the software product, spo – objectives of the software product, spg – goals of the software product, cssh – consistency with the same statements in high-level specifications; srrp – software system's relationship to other related products, sosi – software operation within the system interfaces, soui – software operation within the user interfaces, sohi – software operation within the hardware interfaces, soswi – software operation within the software interfaces, soci – software operation within the communications interfacse, som – software operation within the memory, soo – software operation within the operations, sosar – software operation within the site adaprion requirements; mf – major future functions of the software; gcigu – general characteristics of the software product's groups of users, gciu – general characteristics which influence usability; rp – regulatory policies, hwl – limitations of hardware, ioa – interfaces to other applications, plo – parallel operation, af – audit functions, cf – control functions, holr – requirements of higher-order language, shp – protocols of signal handshake, quar – quality requirements, ca – criticality of the application, ssc – considerations of safety and security, pmc – physical/mental considerations; far – factors which influence the requirements; asrse – distribution the requirements to elements of software, crtf – cross-reference table by function, crte – cross-reference table by element, rduf – requirements that can be transferred in software's future versions; rlds – requirements to a detail sufficient level, iss – inputs into the software system, oss – outputs from the software system, fss – functions of the software system in response to the input or in support of the output; ni – item's name, dp – purpose's description, sido – input's source or output's destination, vrat – valid range, accuracy, and/or tolerance, um – measuring units, tg – timing, roio – relationships to other inputs/outputs, sfo – formats/organization of screen, wfo – formats/organization of window, df – formats of data, cmf – formats of command, emsg – endmessages; faapi – basic actions that must take place in the software when receiving and processing inputs, fapgo – basic actions that must occur in the software when processing and generating outputs, vci – checks of validity on the inputs, eso – exact sequence of operations, ras – responses to abnormal situations, ep – parameters' effect, rsoi – relationship of inputs and outputs; ubr – usability requirements, mec – measurable criteria of effectiveness in specific use contexts, mefc – measurable criteria of efficiency in specific use contexts, msc – measurable criteria of satisfaction in specific use contexts; snr – static numerical requirements, dnr – dynamic numerical requirements, nts – number of supported terminals, nssu – number of supported simultaneous users, athi – amount and type of handled information, nota – numbers of transactions, not – number of tasks, adnw – amount of the processed data within certain time periods for normal workload conditions, adpw – amount of the processed data within certain time periods for peak workload conditions, prq – requirements of performance; tiuvf – types of used information, fqu – frequency of use, asc – accessing the capabilities, der – entities of data and their relationships, ics – constraints of integrity, drr – requirements of data retention; ces – the software system design's constraints which are imposed by external standards, crr – the software system design's constraints which are imposed by requlatory requirements, cpl – the software system design's constraints which are imposed by project limitations; rf – report format, dn – data naming, ap – accounting procedures, at – audit tracing; rb – reliability, avb – availability, scr – security, cct – certain techniques of cryptographic, slhd – data sets of specific log or history, fdm – certain functions to different modules, csa – communications between some areas of the software product, dicv – integrity of data for critical variables, dp – privacy of data, mb – maintainability, pb – portability, pehdc – the percentage of elements with host-dependent code, pchd – the percentage of hostdependent code, uppl – portable language use, upcls – particular compiler or language subset use, upos – operating system use; va – approaches for verification, mqs – methods for qualifying the software; siof – sample input/output formats, dcas – cost analysis studies' descriptions, rus – user surveys' results, sbi – supporting or background information that can help the readers of the SRS, dpss – description of the problems which will be solved by the software, spi – special packaging instructions for the code and the media for security, export, initial loading.
Approach to the analysis of software requirements specification on its structure
correctness
Software Requirements Specification
yes Structure of software
requirements specification is incorrect Re-work of the specification
Real ontology
Ideal ontology
Comparing Missing items of specification Are missing items?
no Structure of software
requirements specification is correct
Further work Fig. 4. Approach to the analysis of software requirements specification on its structure correctness (according to ISO/IEC/IEEE 29148:2018)
The equations (2) - (20) represent all the necessary items of the software requirements specification in terms of ISO/IEC/IEEE 29148:2018, structured by the sections of the specification. Therefore, for the structure of the specification of requirements to be recognized as correct, it is necessary that the specification contains all the listed items. For acceleration and automation of such a procedure of check for all items availability, it is proposed to develop an ideal ontology based on the equations (2) (20), as well as to develop a real ontology based on each analyzed specification. Next, a comparison of the two ontologies (ideal and real) will result in missing items of specification being set. If such missing items are available, then the structure of specification is incorrect and re-work of the specification is proposed. If there are no such missing items, then the structure of specification is correct and further work is proposed.
The use of ontologies in this approach to the analysis of software requirements
specification on its structure correctness
Checking the correctness of the structure of the finished (in mind of the developers) specification of requirements for a software system for providing the resilience of computer systems was conducted with the help of the developed approach. This checking identified that the prepared document has not the following items: “software operation within the system interfaces”, “factors which influence the requirements”, “crossreference table by function”, “dynamic numerical requirements”, “requirements that can be transferred in software's future versions”, “basic actions that must take place in the software when receiving and processing inputs”, “accessing the capabilities”, “percentage of elements with host-dependent code”, “types of used information”, “requirements of performance”, “communications between some areas of the software product”, “portable language use”, “particular compiler or language subset use”, “sample input/output formats”, “supporting or background information that can help the readers of the SRS”. It was concluded that "Structure of software requirements specification is incorrect" and re-work of the specification is proposed. The developers finalized the specification, re-analyzed the specification using the developed approach, resulting in the conclusion that there are no missing items, and thus concluded that "Structure of software requirements specification is correct" and further work is proposed.
The proposed set-theoretical models of software requirements specification's sections
The conducted experiment showed the effectiveness of the proposed approach to the
determination of structure correctness
During developing the software, software organizations must be guided by standards
for both software development and evaluation processes. During forming and
formulating the requirements, it is important to comply with the standards that govern
the software development process. The main basic standard for specifying the
software requirements is ISO/IEC/IEEE 29148:2018, which regulates the structure
and required items of the specification. The conducted analysis has shown that the
known models, methods and tools for analysis of software requirements specification
do not solve the problem of analysis of software requirements specification on its
structure correctness
Given the regulated structure and mandatory items of specification, in this paper,
the authors have proposed the formalization of the structure of software requirements
specification
Based on the proposed formalization of the specification, the approach to the
analysis of software requirements specification on its structure correctness
The prospective research of authors will be devoted to the development of the ideal
ontology on the basis of the developed set-theoretical models of specification's
sections; to the development of a method of activity and to the realization of the
ontology-based intelligent agent, which will work on the basis of the developed approach
and will perform automatic verification of the correctness of structure of the
specification
Eastern-European Journal of Enterprise Technologies 1(2), 6-17 (2019).
18. Ahmad, S., Asmai, S.A.: Measuring software requirements quality following negotiation
through empirical study. International Journal of Applied Engineering Research 11(6),
4190-4196 (2016).
19. Thitisathienkul, P., Prompoon, N.: Quality Assessment Method for Software Requirements
Specifications Based on Document Characteristics and Its Structure. In: The Second
International Conference on Trustworthy Systems and their Applications Proceedings. Hualien (2015).
20. Jain, H.K., Vitharana, P., Zahedi, F.: An assessment model for requirements identification
in componentbased software development. Association for Computing Machinery New
York NY United States 34(4), 48-63 (2003).
21. Audytra, H., Hendradjaya, B., Sunindyo, W.D.: A proposal for quality assessment model
for software requirements specification in Indonesian language for e-Government. In
International Conference on Data and Software Engineering Proceedings. Denpasar (2016).
22. Nazaruka, E., Osis, J.: The Formal Reference Model for Software Requirements.
Communications in Computer and Information Science 1023, 352-37