1 Introduction

There has been a continuous effort to estimate the critical activities associated with the development of software, but previous researches reveal that very few proposals exist that can estimate the software development activities from software requirements itself. The requirement of the software is the capability, that a system must supply or a quality that a system must possess in order to solve a problem of poor estimation and to achieve an objective within the system’s conceptual domain [1]. Defining the user requirements is arguably one of the most difficult and challenging task for the development of complex systems [2]. Thus, before designing a software product, it is extremely necessary to understand the precise requirements of the customer and document them according to IEEE 830:1998 recommendations [3]. There are obligations that should be fulfilled for software to be developed along with other general and optional requirements. This paper considers the following issues that have not received much attention in majority of the research proposals that exist, till now, such as:

  • First, early estimation of requirement based complexity of software to be developed on the basis of software requirements written as per IEEE 830: 1998 recommendations, and,

  • A metric for early estimation of software testing effort from the requirement based complexity of software to be developed.

In order to address these issues, the proposed approach consists of the following two modules:

  • A measure for early estimation of software complexity on the basis of SRS is proposed for software to be developed, so that the design and code decisions pertaining to the software development can be made in advance.

  • Finally, the paper proposes a measure for the estimation of software testing effort, as derived from requirement based complexity. This shall enable the developer, tester and practitioner to plan the testing and its associated attributes like test cases generation, test team productivity, computation of function point etc. in advance.

This research work aims to shift the conventional practices of software engineering to the requirement based software engineering paradigm by estimating the software development activities at a much early phase of software development life cycle.

The rest of the paper is organized as follows. Section 2 discusses a survey of leading researches carried out so far in various areas related to proposed approaches. Section 3 discusses the broad structure and major constituents of SRS for documentation of elicited software requirement in IEEE 830:1998 format. It further proposes an improved requirement based complexity (IRBC) measure for early estimation of software complexity on the basis of attributes extracted from SRS of the proposed software. This measure is also evaluated against Weyuker’s properties for validation purposes. Section 4 proposes a measure for estimation of software testing effort based on IEEE SRS and IRBC measure. In Sect. 5, the proposed test effort estimation measure is compared with various prevalent development effort measures used by practitioners as proposed in the past. The final section concludes the work followed by references.

2 Related works

This section carries out a survey of leading papers describing the work carried out so far related to software complexity computation and software testing effort estimation.

2.1 Literature review for estimation of software complexity

Various research proposals have been put forward in establishing the code based complexities with different dimensions and parameters. The software complexity measures proposed in the past are broadly classified into code, cognitive and object oriented (OO), and requirement based complexity measures. These measures use source lines of code (LOC) for the estimation of software complexity. For the sake of completeness, a study and survey of leading papers for the estimation of software complexity are presented here. Mc Cabe [4] uses a fundamental assumption that, the software complexity is related to the number of control paths generated by the code. It describes a graph based complexity measure for control flow programs, that is independent of physical size of a program and depends on decision structure. Also there is no penalty for embedded loops and a series of single loops. Chaudhary and Shastrabuddhe [5] discuss about the study of the effect of meaningfulness of a program and its understanding and consider difficulty or psychological complexity of program. Hamer [6] describes the test made for the validity of the relationships and interpretations that form the foundation of software science. The measure depends on occurrence of operators and operands. Weyuker [7] discusses about the various axiomatic approaches for the evaluation of complexity measure using Weyuker properties. Davis and LeBlanc [8] discuss about how a complexity measure can serve as a good predictor based on the components, type of elements and structural relationship. Zweben and Gourlay [9] discusses about the fundamental nature of property and precision for the structural and mutant adequacy of a complexity measure. Chariniavsky and Smith [10] proposes complexity metric for mapping of program, tokens, variables and constants to estimates final complexity measure based on a recursive function. Halstead [11] proposes a measure for the estimation of difficulty based on the principle of count of operators and operands and their respective occurrences in the code for the length, vocabulary, volume, potential volume, estimated program length, difficulty and finally the estimation of effort and time. Yu and Zhou [12] provides a comprehensive survey of the metric for software complexity using some classic and efficient software complexity metrics, such as LOCs, halstead and cyclomatic complexity metric. Morozoff [13] discusses about the calculation of code rework based on code re-use. It considers various factors for rework such as—initial size, code added, code modified, total final size, final versus initial comparison, percentage of re-work for the calculation of effective LOC based on a tool.

Harrision [14] gives complexity measure based on information content of program and discusses that basic control structure (BCS), input, output and operands, have direct bearing on the cognitive complexity of the code. Tian and Zelkowitz [15] describes various axioms for defining the boundaries where complexity feasibility can fit and develops a technique for general complexity measure on the basis of formal model of complexity. Shao and Wang [16] uses cognitive weight as degree of difficulty for software using BCS. Gray et al. [17] describes the minimization of cognitive workload for interactive system and also defines architecture of cognition. Kushwaha and Misra [18] gives computation of cognitive information complexity measure (CICM) that uses identifiers, operands and LOC based on BCS. Further the measure is also evaluated through Weyuker’s properties. Auprasert and Limpiyakorn [19] considers various cognitive complexity measures and proposes structured complexity measure by decomposing the program into granular hierarchial structure and further computes structured cognitive information measure based on various definitions.

Aggrawal et al. [20] considers OO programs for complexity analysis on the basis of errors and exception handling. It proposes two new metrics i.e. number of catch block per class (NCBC) and exception handling routine (EHF). These metrics are also evaluated against Weyuker’s Properties. Chhabra and Gupta [21] evaluates OO spatial complexity measures using formal evaluation frameworks as proposed by Weyuker.

Baccarini [22] describes complexity with reference to project dimensions at organizational, technological and managerial levels. The project complexity is measured in terms of differentiation and interdependencies among levels. Klemola and Rilling [23] propose a kind of line of code identifier density (KLCID) based cognitive complexity measure. It defines identifiers as programmers’ defined labels (variable name, class name and object name) in order to define the identifier density (ID). Noble and Letsky [24] describes transactive memory model as collection of metric based on individual and team based structure for various collaboration models like team-work collaboration and task-work collaboration. Singh et al. [25] describes estimation of software complexity on the basis of requirements. It also provides a method based on strength of the individual and group, followed by dependency matrix. Din [26] defines a set of metrics to indicate the quality of software requirements based on the goodness property criteria and uses chunks as a basic language parsing unit for noun phrase count for coupling and cohesion. Boer and Vliet [27] gives arguments for notion of relationship between requirement problem description and software architecture. Kanjilal et al. [28] define Requirement Complexity Measurement Metric for measuring the complexity of the requirements and calculate the complexity factor based on sequence diagram. Fitsilis [29] presents a study and models the software complexity based on study carried out by Project Management Body of Knowledge. It also considers various patterns for complexity based on faith, fact and interaction to identify the uncertainties in project.

2.2 Literature review for estimation of software testing effort

During the last few decades, various models, methods and techniques have been developed to estimate the test effort for software to be developed. This section presents a survey of prevalent testing practices which are categorized into code based, requirement based and complexity & model based methods for the estimation of software testing effort.

Tai [30] proposes the exploration of testing complexity for several classes of programs, based on testing path that is obtained on the basis of test data. Ryser et al. [31] discusses about a comprehensive survey of requirement based validation and test of software. Aurum et al. [32] discusses various inspection methods with Fagan’s Inspection. Holden and Dalton [33] uses cumulative test analysis for test selection and produces an objective measure upon identifying and assigning impact of risk for test effectiveness. Bertilino [34] discusses testing roadmap for the achievements, challenges in software testing and discusses four dreams as, efficacy maximized test engineering, 100 % automatic testing, test based modelling and universal test theory, for the testing of any software. Aranha and Borba [35] discusses test execution and a test automation effort estimation model for the test case selection on the basis of a controlled natural language and uses a manual coverage and automated test case generation technique for effort estimation. Deckkers [36] provides a method called test point analysis, which uses function points for the estimation of final result. It considers three elements to compute test effort i.e. software size, strategy of testing, and the productivity level of test teams.

Whalen et al. [37] describes structural coverage metrics obtained directly from high-level formal software requirements. These metrics provides objective, implementation, and independent measures, of how well a black-box test suite exercises a set of requirements. Rajan et al. [38] proposed an approach to automate the generation of requirements based tests for the model validation, in order to formalize the requirement using linear temporal logic properties for the test case generation. Sneed [39] uses a test strategy and automatically performs requirement analysis by identifying keywords in requirement analysis phase and generates the test cases. Uusitalo et al. [40] provides a set of practices that can be applied to link the requirements with testing based on interdependencies and linking the people with requirement documentation. Yi et al. [41] presents an empirical study on early test execution effort estimation based on test case number prediction from use case and estimating the test effort using test execution complexity. Ramchandran [42] proposes a model for test process and investigates the possibility of deriving the test cases from system models and requirement analysis techniques. Nageshwaran [43], discuss a use-case based approach for the estimation of test effort based on use case weight, use case points (UCPs) and complexity factors. de Almeida et al. [44] describes a method for test effort based on the information contained in use case. It also considers the various parameters like actor ranking and technical environment factor in order to finally arrive at test effort estimation.

Vaysburg et al. [45] discusses an approach for the reduction of requirement based test suites using Extended Finite State Machine (EFSM) dependence analysis. The technique supports test case generation from EFSM system models. Kim and Sheldon [46] uses formal methods and language Z for the specification of testing that is to be carried out using finite state machine and data item based approach. Aranha et al. [47] uses a tool to convert test specification into natural language for the estimation of the test effort. It also finds test size and test execution complexity measure. Cabral and Tamai [48] uses a tool “Controlled Natural Language (CNL)” to specify requirement and support in testing and execution of the test cases with their implementation. It also uses formal methods for the purpose of verification. Guerreiro e Silva et al. [49] considers effort estimation model based on data analysis, hypothesis formulation, evaluation, accumulated efficiency and finally models the test effort. Lokan and Mendes [50] considers two types of chronological splits i.e. project by project split and date-base split. Further both splits are compared with each other in order to check which of the either leads to better prediction accuracy. Kushwaha and Misra [51] presents an approach of cognitive information based complexity measure (CICM) and models the software test effort based on component off the shelf and component based software engineering. It further correlates CICM with cyclomatic number. The approach is able to demonstrate that the cyclomatic number increases with increase in software complexity. Boehm [52] aims at estimating the development effort from COCOMO-I, for small to medium sized software projects. Further, Boehm et al. [53] discusses the revised version of COCOMO-I as COCOMO-II. It uses some fixed values for one constant and the other constant depends on the scaling factors.

Periyasamy and Liu [54] proposed a set of metrics for object-oriented programs that has been targeted towards estimating the testing efforts. Their metric set is divided into metrics based on inheritance hierarchy, polymorphism and interaction among objects. The metric value only provides the subjective estimation of testing effort.

3 Estimation of software complexity using SRS

This section aims at proposing a measure for early estimation of software complexity on the basis of the SRS of the proposed software.

SRS is an unambiguous and complete software specification document for software. IEEE 830:1998 [3] elaborates the recommended practices for documenting the software requirements to generate a Software Requirement Specification (SRS). The software development starts only after documenting the software requirements using SRS. The contemplation is that, if the entire software is implemented based on this document, can we not estimate the various software development activities too from this SRS?

Since complexity analysis has an extremely high payoff for the investment, hence it is necessary to carry out a precise and accurate estimation of software complexity for software to be developed.

The process starts by extracting the attributes from SRS of the proposed software and later the extracted attributes are arranged in order to obtain various contributing complexity measures for the estimation of requirement based software complexity. For more precise and accurate estimation, external references [52, 53] are also considered. Further, these contributing complexity measures are consolidated to build an IRBC measure.

3.1 Computation procedure

The computation method for the proposed complexity measure is explained in the following sections.

3.1.1 Input output complexity (IOC)

IOC is a combination of input complexity (IC), output complexity (OC) and storage complexity (SC). IC refers to the complexity of the information entering into the system. Similarly, OC refers to the complexity of the information received from the system. Both the IC and OC depend on two major parameters i.e. source and type of information. These two parameters are considered to differentiate various types of information either entering or leaving the system with different sources or locations for passing or receiving the input–output information. Tables 1 and 2 illustrate the details of various types and sources for information along with their relative weights. These weights are identified by considering the varying degree of difficulty at implementation level.

Table 1 Sources for input and output to system
Full size table
Table 2 Types of input and output
Full size table

Since, types and sources of input and output information have dependency and relationship on each other as illustrated in Table 3. Hence, we propose IC and OC as product of source and type of information (entering or leaving the system).

Table 3 Dependency and relationship between types and sources for IC and OC
Full size table

The IC is calculated on the basis of information entering into the system and is expressed as:

$$ Input\;complexity = \sum\limits_{i = 1}^{3} {\sum\limits_{j = 1}^{3} {N_{ij} \times (Source)_{i} \times (Type)_{j} } } , $$

where “N” is the number of external inputs for the proposed software.

Similarly OC is computed on the basis of the output produced by the system and is expressed as:

$$ Output\;complexity = \sum\limits_{i = 1}^{3} {\sum\limits_{j = 1}^{3} {O_{ij} \times (Source)_{i} \times (Type)_{j} } } , $$

where “O” is the number of external outputs for the proposed software.

Further, in order to obtain IOC, the data storage requirement for the proposed software is also to be considered using SC. The SC uses two major types of storage requirements i.e. local (data storage within the system) and remote (data storage outside the system) for the quantification of storage requirements. Table 4 shows the various types of data storage and their relative weights based on the varying levels of requirement.

Table 4 Types of data storage and relative count
Full size table

The SC is obtained by identifying the number of storage type and their corresponding count for the proposed system. A sum of product for number of storage and their associated count is taken for the computation of SC, this is expressed as:

$$ Storage\;complexity = \sum\limits_{i = 1}^{n} {(Storage\;requirement)_{i} } \times \sum\limits_{j = 1}^{2} {(Type\;count)_{ij} } . $$

Finally, the IOC is expressed as a combination of all three sub-complexities and expressed as

$$ IOC = Input\;complexity + output\;complexity + Storage\;complexity. $$

3.1.2 Functional requirement (FR)

A FR describes the functionality to be performed by the proposed software and/or its associated components. It also describes the fundamental action that is to be performed in order to accept and process the inputs and generate the subsequent output. It is appropriate to partition the FR into sub-functions or sub-processes in order to get complete functionality coverage. Hence FR with its decomposition is mathematically expressed as:

$$ Functional\;requirement = \sum\limits_{i = 1}^{n} {(functionality)_{i} } \times \sum\limits_{j = 1}^{m} {(SPF)_{ij} } , $$

where “SPF” is sub-processes functionality as obtained on decomposing the overall functionality of proposed software.

3.1.3 Non functional requirement (NFR)

NFRs include constraints and quality related attributes. Quality is the property or characteristics of the system that its stakeholders expect about and that shall affect their degree of satisfaction with the system. Constraints are not subject to negotiation and, unlike qualities, are a compulsory part of design. The NFRs, in contrast to the FRs, specifies the criteria to be used in order to judge the overall usability of the proposed system, rather than any specific behavior. There are various models available for the identification of quality related requirements, but we consider the famous ISO-9126 model [55] as shown in Fig. 1. The model uses six core quality attributes i.e. functionality, reliability, usability, efficiency, maintainability and portability and twenty sub-attributes. The basis for deriving the value of NFR is illustrated in Table 5. The need and applicability of these attributes, for the proposed software, is determined first and marked with “R” for required and “NR” for not required. Similarly, the status of corresponding sub attributes is marked with “Y” for yes and “N” for no. Finally, the value of NFR is obtained based on sum of product of attributes with corresponding sub-attributes.

Fig. 1
figure 1

ISO-9126 model for quality related requirements

Full size image
Table 5 Dependency and relationship between attributes and sub-attributes based on their existence
Full size table

In order to compute the value of NFR for the proposed software, the suitable attributes and their corresponding sub-attributes are to be identified from ISO-9126 model and a sum of product of these attributes is taken to compute the NFR. It is mathematically expressed as:

$$ NFR = \left\{ {\begin{array}{*{20}c} {\sum\limits_{i = 1}^{6} {(Attribute)_{i} } \sum\limits_{j = 1}^{m} { (Subattribute)_{ij} } } \hfill \\ {1\;otherwise\;for\;inbuilt\;quality\;attributes} \hfill \\ \end{array} } \right., $$

where “m” is number of sub attribute for corresponding quality attribute.

If NFR for the proposed software is not explicitly stated, then the minimum value of NFR will be 1, as built in quality attributes are also to be considered.

3.1.4 Requirement complexity (RC)

This complexity describes about the overall requirements of the proposed software. RC is defined as combination of functional and NFRs. The requirements (i.e. FR and NFR) must be explicitly specified, and if the value of NFR is unity, then the total RC of the proposed software will be equal to its FR. Hence the FR is added to the NFR in order to obtain the RC of the proposed software that is expressed as:

$$ RC = FR + NFR. $$

3.1.5 Product complexity (PC)

The PC for software to be developed is expressed as a product of RC with IOC. Both the contributing complexity i.e. RC (FR and NFR) and IOC (IC, OC and SC) comprises of the sub complexities that are sufficient to provide an estimate about end PC. Hence, the recursive call and addition of the sub complexities creates dependency between various contributing complexities i.e. RC and IOC, on the basis of overall requirements. Hence IOC is multiplied with RC in order to obtain PC and it is expressed as:

$$ PC = IOC \times RC. $$

3.1.6 Personal complexity attributes (PCA)

It refers to technical expertise of developer(s) involved in the development of proposed software based on their personal capabilities. This has been referenced through constructive cost model (COCOMO) of intermediate category [52, 53]. The details of PCA along with their associated ratings are illustrated in Table 6.

Table 6 Personal complexity attributes and their associated values
Full size table

The COCOMO describes four categories like project, product, hardware and personal as effort multipliers for cost drivers. The PCA includes five sub-attributes which range from very low to very high as illustrated in Table 6. The inclusion of these personal capability attributes provides a better estimate of the development effort. Hence, in order to carry out an effective software development and to provide better and accurate estimate for complexity of software to be developed, the PCA is considered for inclusion for estimation of software complexity. The PCA is obtained by applying sum of product of the personal attributes with their corresponding rating as:

$$ PCA = \prod\limits_{i = j = 1}^{5} {(AttributeValue)_{ij} } . $$

3.1.7 Design constraints imposed (DCI)

DCI describes the constraint imposed on the software development process. It considers various types of design constraints for the development of software. These design constraints are stated by any statuary body/internal-external agencies etc. These design constraints could be regulatory constraint, hardware constraint, software constraints, communication and network constraint, database constraint and other constraints associated to the software. Hence, DCI is mathematically expressed as:

$$ {\text{DCI}} = \sum\limits_{{{\text{i}} = 0}}^{\text{m}} {({\text{Type}}\;{\text{of}}\;{\text{constraint}})_{\text{i}} } \times \sum\limits_{{{\text{j}} = 0}}^{\text{n}} {({\text{Constraints}}\;{\text{count}})_{\text{ij}} } . $$

Further, in case of blind/no constraints, the value of DCI will be equal to zero.

3.1.8 Interface complexity (IFC)

This complexity describes the external integration/interfaces that are associated with the proposed software. These integrations could be hardware, software, network and communication based for the deployment of the proposed software. IFC is expressed as:

$$ IFC = \sum\limits_{i = 0}^{n} {(External\;interface)_{i} } \times \sum\limits_{j = 0}^{m} {(Externjal\;interface\;count)_{ij} } . $$

3.1.9 Improved requirement based complexity

Finally, the IRBC is calculated by combining all the sub complexities on the basis of their relevance and relative contributions for the computation of overall complexity for any physical system or software to be developed. This is mathematically expressed as:

$$ {\mathbf{IRBC}} = (({\mathbf{PC}} \times {\mathbf{PCA}}) + {\mathbf{DCI}} + {\mathbf{IFC}}). $$

The IRBC of any physical system primarily depends on the functionality that is derived from customer’s requirement and depends on developer’s capability. Due to this reason, the PC is multiplied with PCA in order to get a basic estimate of overall complexity. Further, in order to provide better estimate, there are also other contributing complexity measures like DCI and IFC that also have a very specific and significant contribution towards the computation of final complexity measure. These contributing complexity measures are dependent on the development process, environment and external integrations.

The next section illustrates the proposed IRBC measure with the help of a case study and also compared with other established complexity measures.

3.2 Results

The proposed IRBC measure is derived from the software requirement document written in IEEE-830:1998 standard for the generation of SRS. This section discusses the result of applying IRBC on 15 SRS’s and generating their source code too. Further the result of the proposed IRBC measure is compared with other established code, cognitive value and OO metric based measures. The result of applying various complexity measures on fifteen problems is illustrated in Tables 7 and 8.

Table 7 Comparison between IRBC and other established complexity measure
Full size table
Table 8 Comparison between IRBC and object oriented complexity measure
Full size table

Figure 2 shows the plot between IRBC and other established program based complexity measures i.e. code based (like Halstead and Mc Cabe) and cognitive complexity based (like KLCID, CFS and CICM). It can be observed from the plot that the proposed IRBC measure values, follow the similar trend in increasing and decreasing order with other existing approaches. KLCID has very small program complexity value due to the fact that, it is based on only number of identifiers and LOC. Higher values of CFS and CICM are there due to consideration of control structures and LOC.

Fig. 2
figure 2

IRBC versus other established measures

Full size image

However, for the rest of the cases, the trend is exactly matching with the code as well as cognitive based complexity measures. On the other hand, the IRBC values are higher for the programs, that have higher functionality to be performed and more quality attributes to be retained. For more prominent statistical analysis, IRBC is also individually compared with a group of code and cognitive complexity value based measures.

To move a step closer, the proposed IRBC measure is also compared with OO metric [20] i.e. NCBC and exception handling functions (EHF) as shown in the Table 8.

Since these metrics consider the code to be written in OO language. Hence, for the sake of comparison five programs written in OO language are considered and their SRS’s generated. Further, it is observed that IRBC follows exact trend with these measure too.

3.3 Comparison IRBC and other complexity measures based on Weyuker’s properties

This section presents a comparison between proposed IRBC measure and other established complexity measures in terms of all nine Weyuker’s properties [7] as shown in Table 9. Weyuker’s [37] properties play an important role in evaluating and validating software complexity measure as well as its robustness. Weyuker proposed nine properties to evaluate any software complexity measure.

Table 9 Comparison of IRBC with established measures in terms of Weyuker’s Property
Full size table

Property # 1

(∃P) (∃Q) (|P| ≠ |Q|) Where P and Q are program body

This property states that a measure should not rank all programs as equally complex.

Property # 2

Let c be a non-negative number. Then there are only finitely many programs of complexity c.

This property states that the measure should give complexity value by a non-negative number.

Property # 3

There are distinct programs P and Q such that |P| = |Q|.

This property states that the measure should neither rate too many programs as being of equal complexity nor assign every program a unique complexity.

Property # 4

(∃P) (∃Q) (P ≡ Q and |P| ≠ |Q|)

This property states that the measure should not consider the function being computed by a program for complexity calculations, but instead it should consider the implementation details i.e. a measure should be implementation dependent.

Property # 5

(∀P)(∀Q)(|P| ≤ |P;Q| and |Q| ≤ |P;Q|)

This property states that the measure should consider the interaction among the modules of a program after their concatenation.

Property # 6-a

(∃P) (∃Q)(∃R)(|P| = |Q|) and (|P;R| ≠ |Q;R|)

This property states that the measure should not rate the components of a program as more complex than the program itself.

Property # 6-b

(∃P) (∃Q)(∃R)(|P| = |Q|) and (|R;P| ≠ |R:Q|)

This property states that the measure should not rate the components of a program as more complex than the program itself.

Property # 7

There are program bodies P and Q such that Q is formed by permuting the order of the statement of P and (|P| ≠ |Q|).

This property states that the measure should be responsive to the order of the statements and hence the potential interaction among the statements.

Property # 8

If P is renaming of Q, then |P| = |Q|.

This property states that changing the program or variable name will not affect the functionality of the proposed software.

Property # 9

(∃P) (∃Q)(|P| + |Q|) < (|P;Q|) OR (∃P) (∃Q) (∃R)(|P| + |Q| + |R|) < (|P;Q;R|)

This property states that the measure should not rate the complexity of a program as less than the sum of the complexities of its components.

These properties also evaluate weaknesses of a measure in a concrete way and in turn lead to the definition of really good notion of software complexity. With the help of these properties, one is able to determine the most suitable measure among the different available complexity measures.

As can be seen from the Table 9, IRBC satisfies 8 out of 9 Weyuker’s properties.

However 7th property is not applicable to the proposed measure because of dependency on code. Hence, Weyuker’s 7th property is not applicable to IRBC.

4 Estimation of software testing effort using requirement based complexity

This section discusses the application of IRBC for the estimation of software testing effort for software to be developed. Since practitioners are generally short of time and resources, they tend to evade systematic testing as this is not considered to be so very lucrative job. This affects the whole of the software development because every type of testing technique demands adequate test case generation, modeling and documentation. Though many software testing measures have been proposed in the past research, but still it is far from being matured. If we go by the quality standards, then the estimation of the software testing effort has to be done before the tester(s) start writing the test cases. The proposed test effort measure empirically estimates the software testing effort for software to be developed from IRBC which has been obtained from software requirements in order to properly plan the testing process, reduce the testing cost, and computation of software testing effort in early phases of SDLC.

4.1 Computation procedure

In order to clearly understand the approach, the following paragraphs discuss about the estimation of software testing effort from IRBC measure.

4.1.1 Requirement based test function points (RBTFP)

IRBC comprises of all the attributes that are sufficient to obtain function point analysis (FPA) [37] for any software. The function point measure [37] consists of five attributes i.e. external input, external output, interfaces, file and enquiry. However IRBC encompasses an exhaustive set of quantified parameters like IOC consisting of IC, OC for the quantification of input output information, entering or leaving the proposed system and SC for the quantification of local and remote storage for the proposed system. IRBC uses IFC for computation of external interfaces and User Class Complexity (UCC) for quantification of user classes. In addition IRBC uses FR, NFR, PC, RC, DCI and SFC for the computation of RBTFP. These parameters serve a basis for the estimation of RBTFP that have not been considered in FPA. However, IRBC makes use of an exhaustive set of quantified parameters for its computation in order to compute the Requirement Based Function Point (RBTFP) measure. Therefore, in order to estimate RBTFP, we require technical and environmental factors (TEFs) [43, 44] pertaining to the testing activity. The details of nine different TEFs are illustrated in Table 10 along with their assigned weights.

Table 10 Technical and environmental factors
Full size table

These parameters have significant contribution to the software testing activity in order to obtain RBTFP of the proposed software. The need and applicability of these factors are calculated on the basis of the value of perceived impact or degree of influence (DI) of the above nine factors that ranges from zero (harmless) to four (essential). TEF is computed by summing the score of nine different factors on the basis of DI value that ranges from zero to four. Harmless = 0, Needless = 1, Desirable = 2, Necessary = 3, Essential = 4.

Mathematically, TEF is represented [43, 44] as:

$$ {\text{TEF}} = 0. 6 5+ 0.0 1\times \sum {\text{Fi}} . $$

IRBC has bearing on two basic parameters i.e. functionality and input. These parameters are sufficient to compute the test case requirement for the proposed software in both black box and white box scenarios. The functionality and input parameters are also supplemented by nine TEF, which is specifically meant for the testing purpose only. We propose the RBTFP as a product of IRBC and TEF that is expressed as:

$$ {\text{RBTFP}} = {\text{IRBC}} \times {\text{TEF}} . $$

RBTFP acts as basis for finding out the optimal number of test cases, which is required to carry out an exhaustive testing for software to be developed. The next sub section discusses the details of computation of number of requirement based test cases (NRBTC).

4.1.2 Number of requirement based test cases

NRBTC is a function of RBTFP. Because numbers of function point dictate the number of test cases that is to be designed [41]. This is expressed as:

$$ {\text{NRBTC}} = ({\text{RBTFP}})^{ 1\cdot 2} . $$

The estimation of test case requirement for the proposed software serves as basis for the estimation of test effort in man hours.

4.1.3 Requirement based test team productivity (RBTTP)

Test team productivity depends on the number of staff and personnel skill available to test the software. A model [56] for the estimation of tester rank with two different dimensions i.e. experience in testing and knowledge of target application is illustrated in Fig. 3. Tester rank helps in understanding tester behavior for test execution. Higher the rank of test team, lower is the need of number of tester. Hence, in order to derive the RBTTP, the number of testers and their relative rank is considered which can be expressed as:

$$ RBTTP = \sum\limits_{i = 1}^{n} {T_{i} } \times \sum\limits_{j = 1}^{4} {R_{ij} } , $$

where T is total number of testers and R is the respective rank of the tester from tester rank model.

Fig. 3
figure 3

Tester rank model

Full size image

Having obtained the value of number of requirement based test cases (NRBTC) and requirement based test team productivity (RBTTP), we compute the requirement based test effort estimation (RBTEE) in man-hours in next section.

4.1.4 Requirement based test effort estimation

In order to compute software testing effort for the proposed software, it is necessary to know the two significant parameters, first, the prior knowledge of number of test cases and second, the productivity of the test team. In this direction, we have already derived the contributing measures i.e. NRBTC, for the computation of number of test case and RBTTP, for the estimation of test team productivity in previous sub sections. Since higher productivity of test team(s) reduces the amount of required testing effort hence, a ratio of NRBTC and RBTTP is taken in order to get the final requirement based test effort estimate (RBTEE) in man-hours for the proposed software, this is expressed as:

$$ {\text{RBTEE}} = {\text{NRBTC}}/{\text{RBTTP}} \quad ({\text{man{-}hours}}). $$

Early estimation of software testing effort using IRBC will save tremendous amount of time, cost and man power for software to be developed.

4.2 Results and validation

This section categorically compares the proposed RBTEE measure with various other established test effort estimation measures proposed in the past. To analyze the validity of the proposed measure, fifteen SRS’s of various problem statements have been considered. In order to compare the proposed test effort measure with code based measures, the source code of all the fifteen problems is also generated. The comparison strictly considers various categories of test effort estimation measures like use case based, complexity value based and code & execution points based. Use case based test effort estimation methods are further classified into two broad categories i.e. UCP based method, and scenario based method. The measure based on use case include the parameters like actor weight, use case weight, conversion factors etc., for the estimation of test effort. The most important contributing factors such as input, output, interfaces, storage, FR and most importantly NFRs are not taken into consideration in the established testing measures. However, there are two other categories also for test effort estimation i.e. code based and complexity value based. Code based test effort estimation measures uses the LOC, computes the execution points and generates the test cases using a constant to compute test effort measure. However the complexity value based test effort estimation measures use LOC, control structure and finally correlates the test effort with complexity of the code. These two categories of approaches can work only when the code of the software is available.

Table 11 shows the results of various test effort estimation measures applied on fifteen problems.

Table 11 Comparison between proposed test effort estimation v/s other established test effort estimation
Full size table

Figure 4 shows the comparison between various categories of test effort estimation measures with the proposed measure. As it is seen from the plot of Fig. 4 that, program based complexity measures carries higher value of test effort than other approaches, because of the difference in coding style by different programmers. The calculation of these measures also depends on the number of statements in the program, their subsequent control structures and weighted count which makes the value of test effort higher in comparison of other approaches.

Fig. 4
figure 4

Plot between RBTEE v/s other test effort estimation measures

Full size image

Further, code and execution point based approaches carry higher values than the proposed measure and lower values than the complexity based measures because of the fact that, these approaches are based on the execution points. The execution points depend on the variables used in the program. Higher number of variables carries higher execution points, and hence higher value of test effort (in man hours) obtained.

The use case based measures have lower values of test effort (in man-hours) than code and execution point based measures because the values of test effort for these approaches are derived upon modeling the use case at requirement level. Also the variations observed in use case based measures are due to the difference in conversion factor i.e. 20 for UCP and 3 for scenario based UCP. The co-relation that is observed with use case based approaches and the proposed approach illustrate that:

  • The UCP based approach is close to five times of proposed measure.

  • The Scenario based approach is close to one-third of proposed measure.

4.3 Result analysis for larger programs

Having established the proposed measure for average size of programs, verification for its validity was carried out for larger programs approximating to about 1–2 KLOC. The results are illustrated in Table 12. Again, it is seen that the proposed measure is able to generate realistic estimates comparable with FPA, UCP and Scenario based UCP measures.

Table 12 Tabular comparison for larger programs with proposed RBDEE measure
Full size table

4.4 Result analysis for real life software industry projects

In order to prove the applicability of proposed RBTEE measure in software development industry, four large SRS of software projects of different areas has been used to compare and reaffirm the results. The SRS’s of these projects resulted in software with more than 10 KLOC as shown in Table 13. Based on IEEE SRS document of these projects, we have computed IRBC and NRBTC and RBTEE for all these four projects. It is observed that the value obtained from the proposed NRBTC measure is very close to the value of test cases obtained by Software Company for all these projects. The details of the value obtained from NRBTC and value of test cases received from Software Company is illustrated Fig. 5.

Table 13 Details of lines of code for industry projects
Full size table
Fig. 5
figure 5

Plot between NRBTC and industry values for test cases

Full size image

5 Strength of the proposed measure

FPA considers only five attributes i.e. external input, external output, internal logical file, external interface, and external inquiry at abstract level. It is performed after creation of design specifications. Also the method is quite time-consuming thus might result costly and the evaluation is basically subjective. It makes it difficult to be applied coherently and repeatedly. Further, it is not appropriate to sizeable software of other types, including real-time, scientific and embedded software. It needs subjective evaluations with a lot of expert judgment involved. However the proposed measure is drawn from the requirement based complexity that uses an exhaustive set of objective attributes along with their precise quantification. IRBC is computed immediately after freezing the requirements in requirement analysis phase of SDLC. Even the naïve developer can estimate the development and testing effort from IRBC unambiguously.

Further the Use Case Based Measures depends on the prudence of system analyst and it requires expert’s intervention. However the proposed measure is drawn from SRS and considers IRBC measure for precise estimation. Use Case based measures are categorized into simple, average and complex with multiplicative values of 5, 10, 15 respectively. But, these values for a particular software type are not properly quantified and, next, these values don’t converge with the size of the proposed software. Also, the actor classification is done as simple, average and complex with values 1, 2 and 3 respectively. But the type of user with privileges is not mentioned. However, proposed measure is quantified for every parameter and considers UCC for this consideration. Also, Use Case based measures computes UCPs only and estimates the testing effort on the basis of a conversion factor in man hour. However the proposed measures empirically estimates all the parameters required to compute the software testing effort in person - hour for the proposed software. Use cases are not well suited to capturing non-interaction based requirements of a system (such as algorithm or mathematical requirements) or NFRs (such as platform, performance, timing, or safety–critical aspects). However these requirements are taken into consideration in the proposed testing effort measure using ISO-9126 model. UCP does not automatically ensure clarity. Use cases are complex to write and to understand, for both end users and developers. The proposed measure is clear and understandable due to its derivation from SRS based IRBC. As there are no fully standard definitions of use cases, each project must form its own interpretation. Use case developers often find it difficult to determine the level of user interface dependency to incorporate in a use case. The proposed measure quantifies external interfaces on the basis of IFC.

6 Conclusion

The work presented in this paper makes an attempt to establish the metrics for estimation of software development activities like computation of software complexity and estimation of software testing effort using SRS of the proposed software.

At the onset, a measure for early estimation of software complexity based on SRS is proposed. The measure computes the complexity of software to be developed from the SRS document, because an SRS contains all the characteristics, content and functionality of the software to be developed. The results obtained are compared with control flow based, code based, cognitive complexity and OO metric based measures. It is seen that the proposed IRBC measure is comparable and closely follows the trend of other established complexity based measures. Since, IRBC computes the software complexity at a very early stage of the software development; hence it is able outperforms other comparable measures. The robustness of the proposed measure is evaluated and established against Weyuker properties.

Later, the paper proposes RBTEE metric on the basis of IRBC of proposed software. From the result and validation, it is observed that the proposed test effort measure follows the trend set by other established measures in a comprehensive fashion. Also, the values obtained through RBTEE are a approximate mean of use case based measures. This provides an aid to the developer and practitioner in reducing rework by delivering maximum coverage with minimum number of test cases for improving the test effectiveness. The approach presented here is also validated with realistic results pertaining to large projects of software development organization to ascertain validity of the proposed measures as compared with the conventional code based approaches. This will enable the developers and analysts to carry out effective, planned and systematic software development in requirement analysis phase of software development life cycle.