Page 1/13

Shift Left: Strengthening the Requirements Elicitation Processfor Improving Quality Software in Software DevelopmentProjectsUdhayakumar S P  ( spuk19@gmail.com )

Sathyabama Institute of Science and TechnologySivasubramanian M 

Sathyabama Institute of Science and Technology

Research Article

Keywords: Software Quality Management, Requirements Elicitation, Defects Injection, Shift Left, Defect Fixing.

Posted Date: May 4th, 2022

DOI: https://doi.org/10.21203/rs.3.rs-1583925/v1

License: This work is licensed under a Creative Commons Attribution 4.0 International License.   Read Full License

Page 2/13

AbstractWith new methodologies accelerating software delivery, software developers are expected to follow DRIFT (Do it right the �rsttime) and ensure that the delivered software is error-free and works as expected. While the software development community hasadopted and accelerated many delivery methodologies, it still �nds delivering defect-free software a challenging task. To deliverdefect-free software, identifying and eliminating the defects prior to delivery is key. However, to develop defect-free software, thefocus on quality must start very early in the lifecycle. This paper is an attempt by the authors to get to the underlying cause ofdefect injection and identify ways to reduce defect injection. In this paper, the authors aim to analyse the requirements elicitationprocess and its effect to software defects. This paper aims to identify the source of defect injection with a speci�c focus onpeople and process aspects. The authors performed Phase Containment E�ciency (PCE) analysis on the selected softwareprojects using the phase injected and phase detected categorization of defects. Root cause analysis was also performed on thesame to identify the phase and cause of injection. Subsequently, the cost of �xing those defects was ascertained using industry-standard cost data. Using these analysis outcomes, the authors developed a framework to address the causes and prevent defectinjection. A systemic review and analysis of the source data are performed in this paper, based on the same solution themes toprevent defect injection are recommended which are to be part of the requirements elicitation process. 

IntroductionRequirement elicitation is the practice of researching and discovering the requirements of a system from users, businesses,customers, and other stakeholders (Wiki).  The outcome of the requirements elicitation process is a key contributor to the qualityof the software and in turn, impacts the cost of software development [1]. Requirement elicitation is the crucial �rst step in thesoftware development process. It involves envisioning software as a solution for the customer’s business problem, looking at itfrom the customer’s perspective, and documenting and validating the requirements. It also involves converting the businessrequirements into technical requirements that can be subsequently used for designing and developing the solution [2][3]

While poor requirement elicitation may not be the sole contributor to defects in the software development lifecycle, the quality ofthe requirements elicitation process also has a signi�cant in�uence on the quality of the product [4][5]. Many studies have shownthat requirements errors are very costly. By one estimate (in an article by Donald Firesmith for the Software Engineering Institute),requirements errors cost US businesses more than $30 billion per year and often result in failed or abandoned projects anddamaged careers. The common wisdom is to �nd and �x requirements errors early in the lifecycle of a project [6].

Without a good understanding of the customer requirements, the defects injections increase exponentially during the softwaredevelopment lifecycle [7][8].  Requirement elicitation is seldom well done leading to an inaccurate or incomplete understanding ofuser/customer requirements. This results in increased failures in delivered software [9].

Most defects injected in the software development process are due to incomplete requirements from stakeholders,misunderstanding of stated requirements, wrong requirements, incorrect development due to misunderstanding of requirements,etc. The root cause of all the above is not getting the requirements properly from the customers/users or not understanding thecustomer requirements [10]. Further analysis reveals that there are parameters that affect the requirement collection which resultsin wrong or misunderstood requirements.   There is no silver bullet that addresses these concerns.  Realizing the importance ofrequirements elicitation and its effect on the quality, an all-inclusive, simple, and scienti�c approach is required where therequirement elicitation process to be re-engineered to address the above causes to ensure the quality of the software.  

Review Of LiteratureFrom the studies made by various software development communities, it is evident that most failures in software products aredue to errors in the requirements and design phases as high as 64 percent of total defect costs (Figure 3), according to Crosstalk,the Journal of Défense Software Engineering. 

Page 3/13

[11] provided a new method for improving the requirements elicitation for multidisciplinary teams. They highlighted the impact ofthe effectiveness of designers. They have selected two methods for requirement elicitation, one was generally used by engineers,and another was commonly used by ergonomists 

[12] discussed the impact of agile software development for de�ning the mapping between the agile software developmentprocess and various quality attributes. 

[13] brought objectivity for the security requirements management and identify the possible gaps for the requirements gatheringteam and the customer’s business team. Also, the security requirements are managed to identify the possible gaps between themanagement and impact of generated models. 

[14] envisaged Q-Rapids elicitation for software development. That system investigated the collection and analysis of design andruntime data for quality alerts, the impact of requirements in visualizing the effect on a set of indicators rendered in thedashboard, the backlog requirements documentation

[15] discussed order ful�lment process for the requirement analysis of elicitation and collaboration methodology to gainknowledge about users’ requirements and expectations. They have utilized the order ful�lment application for producing the needof organizations support and activities.  

[16] conducted analysis on the review by comprehensive set of 22 elicitation techniques based on quality assessment criteria,including time and cost factors, resource effectiveness, and domain understanding. Then the challenges in requirementselicitation are also grouped into eight different categories based on their applicability. They also highlighted the elicitationrequirements techniques in mobile application development.

[17] proposed a data-driven tooled approach for the semi-automatic generation and documentation of quality requirements in thecontext of the software development process. The approach was based on the declaration of thresholds over quality-relatedissues, whose violation triggers user-de�ned alerts. These alerts are used to browse a catalog of requirements patterns that werepresented to the development team by means of a dashboard that implements several analysis techniques

Design Thinking was utilized as a requirements elicitation technique by [18] and immersion in the process areas, which broughtthe client closer to the software project team and enabled the creation of better projects. With the use of data triangulation, theyreviewed the challenges in software requirements elicitation in agile methodologies and the use of Design Thinking

[19] developed Wargame-Augmented Knowledge Elicitation (WAKE) method to identify information requirements andassumptions in operator decision-making concurrently with operational concepts. The developed WAKE method incorporatednaturalistic observations of operator decision-making in a wargaming scenario with freeze-probe queries and structured analytictechniques to identify and prioritize information requirements for a novel human machine interface. 

[20] proposed the analytic network process as one of the multicriteria decision-making processes for the elicitation techniqueselection process with respect to criterion attributes. They utilized the analytic network process for the selection of requirementselection technique that were dependencies existing among attributes of the project elements. 

Purpose Of ResearchA software delivery project is considered successful when the software delivered addresses all stated and implied requirements ofthe customer/user and meet, schedule and budget targets of all stakeholders. If the software delivered is defective, it leads torework. This impacts all the targets and the stability and dependability of the delivered software.

The purpose of this research is to identify the problems in the requirements elicitation area using root cause analysis and toascertain the origin of the injects defects. This paper is restricted to studying the impact due to the requirements elicitationprocess on the quality of the software.

Null Hypothesis: There is no signi�cant relationship between Requirement elicitation and defect injection 

Page 4/13

Alternate Hypothesis: There is a signi�cant relationship between Requirement elicitation and defect injection.

Research Objectives1. To ascertain the underlying factors of defects by assessing the data from the completed project restricted to Requirement’s

elicitation areas.

2. To arrive at a reengineered process for Requirement’s elicitation (considering the affecting factors) process and check theimpact on the new reengineered process.

Research MethodCase study-based methodology is used to collect data.   An action-research study is adapted in this paper, to solve the high defectrate in the company.   Action research is as an approach in which the researcher and a subject matter expert do the diagnosis andbrainstorming the real-time problem and develop a new way of working based on the diagnosis.    The study presented as part ofthis paper helps the readers to understand the practice of effective requirement elicitation process for reducing the defects in thesoftware development lifecycle. The article illustrates the underlying problem of higher defects leading to low operationale�ciency.   The key features of this study are its scienti�c credentials and its evidence base for professional application.    As partof this research, Project data (Primary) is collected, consolidated, validated, sanitized, and is subjected to RCA (Root causeanalysis). As a part of the PCE (phase containment effectiveness) analysis, Phase detected and phase injected are attributed tothe defects, and calculations are derived. The PCE helps to gain insight into the phases in which most defects are injected and theeffectiveness of the detection mechanisms at each phase in containing the defects within the same phase.  The PCE technique ispreferred as it identi�es the defect injections (the software lifecycle phase in which the defect is injected) and identi�cation in theappropriate phases (the software lifecycle phase where the defect is detected) and �shbone helps to identify the root cause ofsuch injections. This is a useful and valuable method of research, with distinctive characteristics applicable to different types ofresearch which helps closer access to the company data.

Concepts7.1 Requirements Elicitation 

Requirement elicitation is obtaining the requirements of a software application or a product to be built from the Business, Endusers, Customers, and other Stakeholders.  Requirement’s elicitation process helps to understand and collect the requirements. 

 The requirements phase is the �rst phase where the defects will enter, a proper elicitation mechanism will play a gate to arrestthose injection.   If an error occurs in the requirements stage, it will percolate to subsequent development phases which will resultin a higher failure cost and sometimes lead to shelving the project itself. 

One of the most common reasons for project failures is inadequate attention to customer /user requirements elicitation.Approximately 50–60 % of the defects occur due to poor requirement management.  If we do not involve the customer su�cientlyin the requirements elicitation process or only take what the customer says he wants without dwelling on it, then there are morechances of the requirements is not properly collected and misunderstood at the analysis stage.  Any defect injected in therequirement stage then with each next stage of the project the amount of work needed to be done increases to �x the errors –around 40 % of the work at the design stage and around 70 % at the implementation stage etc. The requirements elicitationprocess is an important part of the project requirements analysis that ensures product stability and lower cost of quality. Therelative costs have been shown in the below diagram. 

A survey conducted on European companies found that more than 60% of them considered requirements elicitation problems asvery signi�cant.

The requirements (need of the customer) obtained correctly and understood in its entirety solves much of the quality issues.  Therequirements are not only the Functional Requirements and Non-Functional Requirements of the product, but also the internal andexternal quality standards set by the customers/contractors to be considered

Page 5/13

Requirements Engineering is pivotal and critical to every successful software development project. There are several reasons whysoftware projects fail; however, poorly elicited, documented, validated, and managed requirements contribute grossly to softwareprojects' failure.

Though a variety of techniques may be used to elicit system requirements like Brainstorming, Questionnaire, Group Discussions,Document Analysis, interviews, Prototyping, etc, all these techniques have their own limitations.   Organisation has developeddifferent requirements elicitation techniques and kept is as guidelines in the process framework.  People use such techniqueswhich they feel appropriate for the eliciting requirements.

7.2 Defects

Quality is de�ned as conformance to requirements.  Quality is the absence of Bug (when the software does not perform asexpected), Defect (When the software has an undesirable feature), and Error (when the software deviates from a correction value). In software engineering, the words Defect, Bug, and Error are interchangeably used though the ultimate consequence is the same. In this paper “Defect” is used as a common word for all three types.

Whatever has been asked by the customer or user, giving the same in its entirety is Quality.  The product or application deliveredshould satisfy the purpose.   So, understanding the requirement is key to developing the product/application without defects.Without a thorough understanding of the requirements, the defects injection increase multi-fold challenging the quality andstability of the product and in an increased failure and maintenance cost.

As customer needs keep on increasing and changing, the application or the product required to meet these will be more complex. If the application or product is more sensitive (say a medical product or aerospace application), the defects will be very damaging

7.3 Shift Left

Shift Left is a simple but powerful concept of uncovering all the defects upfront in the development lifecycle itself.   In simplewords Shift Left concepts guide you to detect the defects early and over a period to prevent the defects.   It is used in Softwaretesting as it attempts to move the validation upfront in the lifecycle, however in this paper the concept of Shift Left is used for theprocess, i.e., preventing the defects through strong process coupled with techniques.   Detecting defects early and preventing themis most crucial at the same time the most neglected activity in any software organization.  This is because the rework has beeninstitutionalized as normal work in many organizations.  

Defect Fix is always a non-value added (NVA) activity and it should be avoided to the maximum extent.   Using the Shift Leftconcept a big chunk of NVA can be eliminated.  The key to successful project delivery is to invest early in preventive activitieswhich will minimize rework and the risk of downstream business impact

In software development, the defects are injected in Requirements, Design, and coding phases.   The cost of defect removalincreases exponentially as the development lifecycle progresses. In addition, later the defects are found and �xed, the greater therisk to the business they pose.

The objective of Shift left is concentrate on left side of the Lifecyle i.e. instead of deducting the defects in testing and production,move to left and prevent the defects during the defect injection stage itself.  This will bring more product stability and overall costreduction. Shift left initiatives will have a positive impact in reducing the Total cost of Quality.

Finding & ImplicationDefects are the outcome of not implementing the customer requirement properly.   Analyzing those defects will reveal whereexactly it got injected. Analysis of defects taken from a set of application development projects reveals two major areas ofweakness where the defects occur most, i.e., wrong, or incomplete requirements and misunderstanding of requirements by theteam.  The author has taken primary data from the already completed projects.  Accordingly, three waterfall methodology projectsdata (of similar size, technology, and complexity) have been taken for analysis.

Page 6/13

The selected data was analyzed using Phase Containment E�ciency (PCE) method.   PCE is a statistical measurement of theproblems (bugs) uncovered at the earliest possible review (or containment) point compared to the total faults uncovered.  Themore effective the containment (the higher the PCE metric), the more likely the project will proceed smoothly and not experiencedownstream delays, quality problems, and/or cost overruns.  Then root cause of the identi�ed defects revealed the real reasonbehind the defect injection.

The elicitation techniques and their advantages and limitations were collected as secondary data through various literaturereviews.

8.1 Select Projects

Two projects have been taken for this analysis. All the projects follow the waterfall methodology as their software developmentlifecycle. All the projects are Application development projects of similar size, Technology, and complexity and same domain. Allthese projects got concluded recently (in the last 6 months). All these projects followed the brainstorming techniques forcollecting the requirements from the customer. All these projects strictly followed the company’s existing processes.   One projectwhere the new process is implemented followed the new elicitation process that has been developed.  

Project Lifecycle Dev TeamCapability

ElicitationMethod

ProjectSize

Technology Year ofCompletion

Complexity Purpose

P-1 Waterfall 7 Brainstorming Medium Java 2019 Medium Study

P-2 Waterfall 7 Brainstorming Medium Java 2019 Medium Study

P-3 Waterfall 7 NewElicitationProcess

Medium Java 2020 Medium Implementation

Table 1: Sample project selected for Analysis

Development Team capability scale is 7 i.e., in the 10-point scale, (Capability is calculated

Project Size is Medium (executed 6-8 months project)

Complexity of the project is Medium (qualitative based on project managed a�rmation)

Purpose – Whether the project is taken for Study purpose or for implementing the new process.

Elicitation Method: Brainstorming used for all the three projects which was taken for study purpose while new elicitationprocess is used for the fourth project.

Brainstorming is a group technique in which stakeholders from different domains share ideas openly and rapidly. It is mostly usedat the start of the elicitation process and has two phases: the generation phase, where ideas are generated, and the evolutionphase, where they are discussed 

8.2 Root Cause 

The Root cause for all the defects was done with the help of the project managers.   Two levels of causal analysis were done i.e.,initial cause and the root cause.  The parameters affecting the root cause were identi�ed for each defect.  

Table 3: Data Collection & Root Cause Template

8.3 Root Cause of the Defects 

First level of root cause shows that the Developer (coding phase) has injected more defects, but after a defect-by-defect analysiswe found that the defects are injected not because of the coder’s capability issue, of course, there is some percentage due to

Page 7/13

capability issue, but the main reason for such injection is due not understanding the requirements correctly.   Though Phasecontainment analysis shows only 4% of defects in the requirement phase, most of the defects in the lifecycle are due to wrongrequirement and requirements not understood correctly. 

 Cause Wrong / Missing requirements Correct requirements - Wrongly understood Team's capability Others

Defects 1450 1571 1177 998

%age 28% 30% 23% 19%

Table 4: Root Cause of the Defects (Project 1)

Out of the 5197 defects, 3021 defects related to the requirements phase, in turn, shows poor elicitation.  The Project followed abrainstorming technique to collect the requirements from the customer.  Around 58% of the defects are injected in requirementphase due to poor requirements elicitation. The defect due to the team's capability and others (like con�guration issues, accessissues, etc) is not considered for this analysis and it requires a different study.

Table 5: PCE analysis performed using defect data collected from waterfall projects - Project 2 (*Primary Data)

Cause Wrong / Missing requirements Correct requirements - Wrongly understood Team's capability Others

Defects 1980 1440 600 469

%age 44% 32% 13% 10%

Table 6: Root Cause of the Defects (Project 2)

The root cause of the defects (through �shbone diagram) was done for all the samples; Out of the 4489 defects, 3420 defectsrelated to the requirements phase in turn shows poor elicitation.  The Project followed the brainstorming technique to collect therequirements from the customer.  Around 76% of the defects attributed to poor requirement collection.  Team capability issuesand other defects contribute to a balance of 23% of defects.  If the requirements elicitation is strengthened, there is a chance of76% of the defects can be avoided. At least 70% of the defects are prevented, it might have a great saving on rework cost

8.4 existing process �ow of requirements elicitation

The company already has a de�ned process which was followed for all the software application development projects.  The high-level �ow of the project is given below: 

1. Get the proposed initiative from customer

2. Identify the Business Analyst who will work with the Customer on collecting the requirement

3. Review the requirements given by the customer

4. Conduct a Brainstorming session or any other technique mentioned in the company process

Page 8/13

5. Create / Update the Speci�cation document.  Speci�cation document includes all functional and

6. Analyse and document the requirements for the following elements:

6.1.1 Type

6.1.2 Priority

6.1.3 Commercial Feasibility

6.1.4 Veri�cation/Testing Method

6.1.5 Level of Testing

7. Get clari�cation from the customer on Functional and non-functional requirements if any

8. Negotiate any commitments resulting out of the additional requirements identi�ed during the review, with the affectedstakeholders

9. If the document is ready, baseline the same else take it to the customer for further clari�cation.

Managerial Implications – Making Requirements Elicitation Effective To ReduceDefectsMany researchers have attempted to give a solution for this issue by studying different elicitation techniques, but the solutionsdid not make a big impact as the defects continue to soar.  So, it is imperative to have a new solution/process not onlyconcentrating on the technique but to �nd out the root cause and stop the injection. As per the analysis, it is found that one of themajor reasons for defect injection is the way requirements are elicited i.e., understanding the requirements as per customer/usethinking. The solution lies in how effective the Requirements elicitation process is de�ned and executed. 

The whole Team's involvement with customers plays a major part in the success of the requirements elicitation phase, thoughelicitation technique may be selected based on the team that thinks �t. The author recommends effective communication to beheld by way of a workshop between the software development team and the customer face to face to get high quality and clearrequirements. The author suggests a new process for requirements elicitation process where the Brainstorming techniques is alsoconsidered as an element in the process. It is recommended to have all the Team Members or representatives from all phases bepart of elicitation sessions, so that there may be internal quality gates established by default i.e., if a designer commits a mistake,developer can correct it instead of developing on the wrong design. 

The following process is drafted and used in the current scenario.  This core component can be used for any type of requirementselicitation; however, it can still be customized without compromising the effectiveness.

Three aspects considered strongly for the new process i.e. (1) All Stakeholders (2) The Process (3) Scienti�c method (Apart frommere Brainstorming, we are using more inclusive, quantitative method for collecting requirements) 

The solution should involve all the stakeholders in the elicitation. all the development team members should be present ingetting the requirement from the customer.

A traditional requirement analysis may take a couple of hours or a day with the Business Analyst, while involving all thestakeholder in the requirements elicitation exercise may take 3 to 4 days.  The cost of this exercise will be high, but it willoutweigh the cost that is saved from avoiding rework. The customer / user needs to be informed on the extra time involvedand get their consent as well.

Create a method / Technique to track the understanding of all the stakeholders.   

The requirement analysis meeting should be attended by all the development team members and customer (from whom therequirement is obtained),

Page 9/13

Use Brainstorming techniques and use case diagrams while doing the elicitation 

The method should use all the parameters that came out of root cause analysis.  

Involve the Business/Customer/user to understand the development and architectural challenges as they will understandwhat can be developed and what are the alternative ways if there is a challenge.

Collaboration with the stakeholders and subject matter experts during elicitation will help the successors in the lifecycle tocorrect the mistakes done by the predecessors.

Customers need to elaborate the use cases during the elicitation sessions by adding more detail, adding sub-processes thatare automatically linked 

Use the parameters (arrived based on the root cause done) on which the requirements elicitation and analysis can be done. 

Request approval from all the stakeholders on each of the requirements. For example, if “Ambiguity” is a parameter, the wholeteam must give clearance that they are no ambiguity on the requirement, and it can be designed / developed / Tested etc. This con�rmation needs to be given by the respective practitioner / stakeholder in the development team

Wherever there are more details required, brainstorm the requirements provider to collect the details

It is the responsibility of the development team to get all the requirements clear for their respective areas.

Have a weighing mechanism so that a toll gate can be established.  For e.g., Greater than a 95% score will make therequirements qualify to be taken up for development

Track the rate of change of requirements through a mechanism so that those areas can be covered in the next projectsRequirement Elicitation processes.

Those areas where there is more clarity required but details not immediately available can be deferred for now (fordevelopment) or should be backed up with a proper risk management process.

Produce the �nal requirements speci�cation document or product backlog document. 

The technique is lifecycle agnostic as both waterfall and Agile methods can follow the technique. (In a waterfall model, aspart of requirement analysis and in Agile projects as part of Product backlog re�nement) as this challenge is there in all typesof projects

 

 

 Table 7: PCE analysis performed using defect data collected from waterfall projects - Project 3 (*Primary Data)

 

Cause Wrong / Missing requirements Correct requirements - Wrongly understood Team's capability Others

Defects 113 102 800 119

%Age 10% 9% 71% 10%

Page 10/13

Table 8: Root Cause of the Defects (Project 3)

The overall defects injection has come down drastically as we have concentrated on prevention than deduction i.e. shifted left. Out of the 1134 defects, only 215 defects related to the requirements phase show an effective elicitation process.   100% of therequirements related defect injection preventions cannot be achieved due to human factor involvement, however the same can beoptimized which is proven above.   The Project followed the above-recommended process to collect the requirements from thecustomer. Previous projects had an average of 65% defects injection rate which came down to 19% after following the newprocess.

This process / technique enables the development team to evaluate and re�ne the requirements with respect to the followingparameters during requirement elicitation / collection. 

 

Table 9: Root Cause Parameters details and examples

Each of the requirements is taken and brainstormed under all the parameters and got accepted by all the stakeholders present inthe meeting / workshop.   Once it is accepted, the requirements qualify for execution.  In case some development team membersgive consent, and some have doubts, it is the duty of the customer/user/Business to clarify the doubts.  There may be somecases where it will still not be clear, those cases can be low prioritized and can be reassessed later else it can be taken forexecution after an exception approval and proper risk management plan for the same.  

This process strengthens the development teams understanding on the requirements, thus reducing the occurrence ofrequirements related defects such as incorrect requirements, missing requirements and ambiguous requirements further results inhigh quality workable component or working software at the end of each sprint 

This method improves the development team’s e�ciency on requirement gathering and prevents the seepage of requirementdefects to testing 

This method empowers the development team to accept the requirements for development or reject during product backloggrooming or re�nement  

This method proactively recommends the development team to identify & mitigate the risk associated with each requirementbefore development.

ConclusionThis paper has attempted to have a simple, practical way to prevent defect injection by shifting left i.e. concentrating on arrestingdefects in the requirements stage itself instead of identifying in Testing and leaking it into production.    It was found out throughimplementation of new concentrating on the left side of the lifecycle process i.e. in the Requirement’s elicitation process;substantial number of defects has been prevented. Hence the alternative hypothesis is proved.

As discussed in the paper, the Requirements elicitation process is a highly in�uential and plays a major role in preventing defectsand providing application/product stability. If a process is developed around the �ndings and using the solution parametersdiscussed in the paper, organisations may well be able to improve the quality of requirements, achieve a steep reduction in thecost of �nding and �xing defects in downstream phases and as a result achieve better project outcomes.   

Projects in any Organisation can create their process / method after doing the analysis of defects and identify the root causeparameters. By adding this new process / method in the organisation process framework with the room for customization, thebest practice and the savings coming out of such process do not remain localised for one project.

This method can be implemented to other projects irrespective of the size as the impact is on the process, and not on the size ofthe project or the size of the Organisation.  The cost saved through rework directly contributes to the pro�tability of theOrganisation    Organisation operational cost goes down and organisation can develop and supply the products and services at

Page 11/13

Parameters De�nition Factors

Adequate  All the requirements are uniquely marked with a requirement identi�er.  All therelevant sections are addressed adequately, and no pertinent information ismissing, and the requirements are good enough to “build the system right”(analysis, design, and Development.) The uniqueness and correctness are notanalyzed with this attribute

✓ User Pro�les (R&R) 

✓ Operational Scenarios

✓ Business Rules

✓ Data �les / �elds/information

✓ Non-functionalRequirements

✓ Events

✓ Form/ReportSpeci�cation

Correctness(SoundBusinessReasoning)

The requirement provides sound business reasoning. LogicalTraceability/alignment among CBT Strategy, Problem Statement / BusinessCase, Operational Scenarios, Stakeholder List, Quantitative Goals. To a largeextent information is fact based and hypothetical scenarios are minimum to“build the right system”.

✓ Reason for Change

✓ Problem Statement

✓ Quantitative Goal

✓ Business Work�ow

✓ Stakeholder List ofRequirements

✓ Users

✓ Operational Scenarios

✓ Business Rules

Uniqueness(Clearlystated)

Uniqueness: This attribute is used to determines whether the requirements areuniquely explained and understood by all the relevant stakeholders

✓ Comprehensive

✓ Terms and De�nition

✓ English and Grammar

Consistency Relationship between User, Operational Scenarios, Data �les/�elds/informationand Business Rules is established and projects standards (Naming standards,versioning etc.) are applied. Individual requirements do not contradict eachother or describe the same requirement using different wording

✓ User Pro�les 

✓ Operational Scenarios

✓ Business Rules

✓ Data �les / �elds /information

✓ Events

✓Organizational/OperationalBoundaries

✓ Compliance toDocumentation Standards

cheaper cost.    The requirements are the re�ection of the customer / user needs, if that is given exactly as they need with theabove bene�ts, the customers / user will be happy. 

Industry can use this method for improving the operational e�ciencies in any software development project and avoid defectsand optimize costs.  (1) Companies can collect the defect data for the past one-year (2) Data to be segregated based on the typesof projects (Technology and Complexity wise (3) Do the root cause analysis for the defects along with the subject matter experts(3) Identify the top defects by a Pareto Analysis. (4) Further analysis on what are the defects can be attributed to requirementselicitation area, (5) Identify the parameters. (6) Develop a process or technique using these parameters for requirement elicitationin future projects.   These parameters may be different for different types of projects, the elicitation process or technique can be

Page 12/13

customized based on the parameters.  This makes the model more �exible for any type of project irrespective of domain andlifecycle.  With this study, we intend to provide a solution by throwing light on a crucial problem the companies face on reducingthe cost.

With this case, it is also demonstrated the applicability of qualitative techniques in a requirements elicitation area where its usehas been scarcely used. Further study on this can be customized with respect to different standard elicitation techniques andparameters can be selected using AI.

DeclarationsFunding Declaration

This project is not funded at all.

Author Contribution

The Corresponding Author is the original author who has done this study and arrived with the solutions.   The author collected theprimary data through a template (questionnaire) and the same has been analysed, two levels of root cause been done andidenti�ed the parameters that are affecting the Quality of the product.  The origin of the same has been identi�ed and areengineered process has been developed / recommended to overcome the issues.  The reengineered process has beenimplemented to check the e�ciency of the process

Con�ict of Interest Statement.  

The authors listed certify that they have NO a�liations with or involvement in any organization or entity with any �nancial interestor non-�nancial interest (such as personal or professional relationships, 

a�liations, knowledge, or beliefs) in the subject matter or materials discussed in this manuscript.

References1. Caiado, R.G.G., Quelhas, O.L.G., Nascimento, D.L.D.M., Anholon, R. and Leal Filho, W., 2019. Towards sustainability by aligning

operational programmes and sustainable performance measures. Production Planning & Control, 30(5-6), pp.413-425.

2. Aldave, A., Vara, J.M., Granada, D. and Marcos, E., 2019. Leveraging creativity in requirements elicitation within agile softwaredevelopment: A systematic literature review. Journal of Systems and Software, 157, p.110396.

3. Machuca-Villegas, L. and Gasca-Hurtado, G.P., 2018, October. Gami�cation for improving software project managementprocesses: a systematic literature review. In International Conference on Software Process Improvement (pp. 41-54). Springer,Cham.

4. Pacheco, C., García, I. and Reyes, M., 2018. Requirement’s elicitation techniques: a systematic literature review based on thematurity of the techniques. IET Software, 12(4), pp.365-378.

5. Sánchez-Gordón, M. and Colomo-Palacios, R., 2018, October. Characterizing DevOps culture: a systematic literature review. InInternational Conference on Software Process Improvement and Capability Determination (pp. 3-15). Springer, Cham.

�. Curcio, K., Navarro, T., Malucelli, A. and Reinehr, S., 2018. Requirement’s engineering: A systematic mapping study in agilesoftware development. Journal of Systems and Software, 139, pp.32-50.

7. Saeeda, H., Dong, J., Wang, Y. and Abid, M.A., 2020. A proposed framework for improved software requirements elicitationprocess in SCRUM: Implementation by a real‐life Norway‐based IT project. Journal of Software: Evolution and Process, 32(7),p.e2247.

�. Albarqi, A.A. and Qureshi, R., 2018. The proposed L-Scrumban methodology to improve the e�ciency of agile softwaredevelopment. International Journal of Information Engineering and Electronic Business, 11(3), p.23.

9. de Vicente Mohino, J., Bermejo Higuera, J., Bermejo Higuera, J.R. and Sicilia Montalvo, J.A., 2019. The application of a newsecure software development life cycle (S-SDLC) with agile methodologies. Electronics, 8(11), p.1218.

Page 13/13

10. Lunesu, M.I., Münch, J., Marchesi, M. and Kuhrmann, M., 2018. Using simulation for understanding and reproducingdistributed software development processes in the cloud. Information and Software Technology, 103, pp.226-238.

11. Barré, J., Buisine, S. and Aoussat, A., 2018. Persona logical thinking: improving requirements elicitation for multidisciplinaryteams. CoDesign, 14(3), pp.218-237.

12. Jain, P., Sharma, A. and Ahuja, L., 2018, August. The impact of agile software development process on the quality of softwareproduct. In 2018 7th International Conference on Reliability, Infocom Technologies and Optimization (Trends and FutureDirections) (ICRITO) (pp. 812-815). IEEE.

13. Althar, R.R. and Samanta, D., 2021. The realist approach for evaluation of computational intelligence in software engineering.Innovations in Systems and Software Engineering, 17(1), pp.17-27.

14. Franch, X., Gómez, C., Jedlitschka, A., López, L., Martínez-Fernández, S., Oriol, M. and Partanen, J., 2018, June. Data-drivenelicitation, assessment and documentation of quality requirements in agile software development. In InternationalConference on Advanced Information Systems Engineering (pp. 587-602). Springer, Cham.

15. Andry, J.F., Tannady, H. and Nurprihatin, F., 2020, March. Eliciting requirements of order ful�lment in a company. In IOPConference Series: Materials Science and Engineering (Vol. 771, No. 1, p. 012023). IOP Publishing.

1�. Dar, H., Lali, M.I., Ashraf, H., Ramzan, M., Amjad, T. and Shahzad, B., 2018. A systematic study on software requirementselicitation techniques and its challenges in mobile application development. IEEE Access, 6, pp.63859-63867.

17. Oriol, M., Martínez-Fernández, S., Behutiye, W., Farré, C., Kozik, R., Seppänen, P., Vollmer, A.M., Rodríguez, P., Franch, X.,Aaramaa, S. and Abhervé, A., 2020. Data-driven and tool-supported elicitation of quality requirements in agile companies.Software Quality Journal, 28(3), pp.931-963.

1�. Ferreira Martins, H., Carvalho de Oliveira Junior, A., Dias Canedo, E., Dias Kosloski, R.A., Ávila Paldês, R. and Costa Oliveira, E.,2019. Design thinking: Challenges for software requirements elicitation. Information, 10(12), p.371.

19. Dorton, S.L., Maryeski, L.R., Ogren, L., Dykens, I.T. and Main, A., 2020. A wargame-augmented knowledge elicitation methodfor the agile development of novel systems. Systems, 8(3), p.27.

20. Li, J., Ullah, A., Li, J., Nazir, S., Khan, H.U., Ur Rehman, H. and Haq, A.U., 2020. Attributes-based decision making for selectionof requirement elicitation techniques using the analytic network process. Mathematical Problems in Engineering, 2020.

21. Vijaya Sundar M, Indian School of Business, rejects reduction in a retail bank using Lean Six Sigma Article in ProductionPlanning and Control, May 2016

SupplementaryDiagram 1-7 are available in Supplementary Files section.

Supplementary Files

This is a list of supplementary �les associated with this preprint. Click to download.

d1.png

d2.png

d3.png

d4.png

d5.png

d6.png

d7.png