International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056
Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072
ReqClarity AI: A Hybrid Rule-Based NLP and LLM Pipeline for Quality Analysis and Rewriting of Software Requirements Specifications
Urza Rai
Student, Dept. of Computer Science, Vellore Institute of Technology, Vellore, Tamil Nadu, India
Abstract - ReqClarity AI is a web-based automated system designed to enhance the quality of Software Requirements Specifications (SRS), which frequently suffer from ambiguity, non-verifiability, and incompleteness issues that can leadto costly downstream errors during development and verification. Traditional SRS quality assurance is labourintensive, inconsistent across reviewers,andoftenneglectedin smaller teams and academic environments. To address this, ReqClarity AI integrates a deterministic rule-based natural language processing engine with a large language model (LLM) to both detect defects and generate improved, standards-compliant rewrites. The system evaluates each requirement using 15 structured rule patterns organized into three defect categories: ambiguity, non-verifiability, and incompleteness, each comprising five subtypes. Detected defects are weighted by severity, producing a quantitative quality score ranging from 0 to 100 at both the requirement and document levels, and mapped to five quality bands from Critical to Excellent. Requirements falling below a defined thresholdare processed through the GroqAPIusingtheLlama 3.3 (70B) model, which generates IEEE 830 / ISO/IEC/IEEE 29148-aligned rewrites based on structured prompts. The platform also features an interactive dashboard that allows users to review analyses, accept or reject suggested rewrites, and export annotated reports or finalized SRS documents. Evaluation across 15 SRS documents demonstratedpromising performance under controlled evaluation, achievingprecision of 0.84, recall of 0.79, and an F1-score of 0.82, while aligning with the intended quality levels of the constructed dataset; additionally, the rewrite pipeline eliminated 88.4% of defects while preserving 93.0% of the original intent.
Key Words: Software Requirements Specifications, Requirementsquality,Ambiguitydetection,Non-verifiability, Incompleteness, Natural Language Processing, Large Language Models, IEEE 830, Automated Rewriting, RequirementsEngineering
1. INTRODUCTION
1.1
Cost Related to Definition Errors
The cost of fixing defects originating at the requirements stage is significantly higher when addressed later in the software development lifecycle than during early requirement modelling. Studies in software engineering consistentlyshowthatcorrectingdefectsafterdeployment can be many times more expensive than resolving them duringtherequirementsphase.Despitethiswell-established
understanding, the quality of Software Requirements Specifications (SRS) remains an under-resourced concern globally, particularly in academic environments and small development teams, where formal quality assurance processesareoftenlimitedorabsent.
1.2 Nature of Quality Defects Associated with the SRS Document
Three primary categories of quality defects in SRS documents are ambiguity, non-verifiability, and incompleteness. As the SRS acts as a formal agreement between stakeholders, developers, and verification teams, ambiguityposesacriticalrisk.Forinstance,statementslike “System shall provide a user-friendly interface” lack measurable acceptance criteria, while “System should provide a user-friendly interface” weakens the obligation. Additionally,failingtodefinesystembehaviourunderunmet conditions creates implementation gaps that may lead to failures. These types of defects are widely studied in requirements engineeringliterature and have measurable impactsonsystemquality[1],[6],[9].
1.3 Limitations of Present Approaches
ExistingapproachestoSRSqualityassuranceincludemanual reviews,walkthroughs,andformalinspectionssuchasFagan inspections[1],aswellaschecklist-basedpeerreviews[2]. While effective, these methods are time-consuming and subjecttoreviewervariability.AutomatedtoolslikeQuARS [2] and TIGER [3] rely on linguistic pattern analysis but requirelocalinstallationandofferlimiteddefectcoverage, oftenpredatingmoderngenerativeAIadvancements.Other researchtoolsandapproachesfocusonambiguitydetection usingNLPtechniques[7],[11],buttypicallyaddressonlya subsetofdefecttypes.Currently,nofreelyavailablesolution integrates detection, scoring, and automated correction withinaunifiedworkflow.
1.4 Proposed System and Contributions
This paper introduces ReqClarity AI, a web-based system designed to address these limitations. The platform processes uploaded SRS documents through a five-step pipeline: parsing, defect detection, quality scoring, LLMbasedrewriting,andresultpersistence,allwithoutrequiring installation or registration. The system employs a deterministic 15-rule defect detection engine covering ambiguity,non-verifiability,andincompleteness,eliminating theneedfortrainingdata.Itskeycontributionsinclude: a rule-based defect detection engine; severity-weighted scoringmodelgeneratinga[0–100]qualityscorewithfive
International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056
Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072
classification bands, validated on 15 SRS documents; an LLM-basedrewritingpipelineutilizingmoderntransformerbased models [19], [20] to produce standards-compliant corrections while preserving intent; and a fully deployed, freely accessible web application integrating all functionalities into a single workflow. The hybrid architecture combiningdeterministicrule-basedanalysis for explainable defect detection with generative AI for naturallanguagecorrection demonstratesascalableand broadly applicable approach for quality assurance in softwareengineeringdomainsrequiringbothtransparency andautomatedimprovement.
2. LITERATURE REVIEW
2.1 Theoretical Foundations of Ambiguity Detection
Gervasiandcolleagueshaveestablishedthatambiguityisa multi-level phenomenon consisting of lexical, syntactic, semantic, and pragmatic dimensions, while also differentiatingambiguityfromvagueness,abstraction,and absence. Their examples of real-world SRSs provide an indication of some potential patterns of identifiable ambiguityusingvagueadjectives,modalverbs,passivevoice constructions, and omitted details, which informed the categories of detection used by ReqClarity AI. Pragmatic ambiguityhasalsobeendiscussedbyFerrarietal.,inwhich differences in how stakeholders interpret sentences arise fromtheircontextratherthanthestructureofthesentence itself.Theyjustifiedtheuseoflayeredarchitecturesthrough the application of rule-based detection and LLM-driven semanticanalysis.
Incomparingambiguitydetectiontools(NASAARM,QuARS, RETA, and RCM) against 180 industrial requirements, Bajceta et al. provided a quantitative assessment of the implicittrade-offpresent.Thatis,rule-basedtoolsprovide highrecall(upto0.98)andmoderateprecision(0.41-0.43) whiledomain-tunedtoolsprovidehigherprecisionatlower recall. This supports the use of hybrid design approaches, wheresyntacticrulesmaximizeinitialrecallandtheaddition ofanAIlayerenhancesprecisionviacontextualfiltering;this architectureisconsistentwiththecurrentwork.
2.2 NLP Evolution in Requirements Engineering Automation
AccordingtoZhaoetal.'ssystematicmappingstudyof404 primary studies published over a period of 36 years, requirements engineering (RE) primarily focuses on the defectidentificationofrequirementsqualityusingsyntactic techniques and shallow semantic techniques. The authors catalogued130RE-specificNLPtoolsbutidentifiedgapsin evaluating these tools in industry and gaps in evaluating more complex semantic processing. In Necula et al.'s complementary systematic review of 309 papers, the evolutionofNLPinREisdescribedstartingwithrule-based systemsthroughtodeeplearningandLLMsandhighlights
that three challenges persist: the use of domain-specific language,alackoflabelledcorpora,andarequirementfor explainability
Theoverallfindingsfromthetwostudiessuggesttheneed for hybrid architectures: a rule-based layer of fast, explainablescreeningfordefectsandanLLMlayertofillin the semantic gaps and generate contextually correct requirements which is exactly how ReqClarity AI was designed.
2.3 Transfer Learning and BERT-Based Classification
Heyetal.usedafine-tunedBERTmodelcalledNoRBERTto evaluatethePROMISENFRdataset.TheyreportedF1scores of up to 94% for projects that had already been seen and between 90% and 93% for those that were previously unseen Therefore,NoRBERToutperformedthelexicaland syntacticbaselinesbyasmuchas15pointswithouttheneed foranyproject-specificretraining.Thisindicatesthatusing transferlearningcanmitigatethechallengesofdatascarcity andcross-projectvariabilityinRE.Finally,inabroaderlook at LLMs, the general findings indicate that smaller model architectures that have been fine-tuned can perform very wellwithrichREcorpora,whilelargelanguagemodelsalso demonstrateimpressiveperformanceonzero-andfew-shot semantic tasks such as traceability or specification refinement. Hybrid LLM–rule-based architectures are recommended to combine contextual reasoning with explainability consistentwithReqClarityAI'sdesign.
2.4 Rule-Based and Hybrid NLP Tools
Femmeretal.'sSmellaisamethodfordetectingcodesmells inrequirementsusingISO/IEC/IEEE29148criteria,which wasimplementedwithPOStaggingandlemmatization.The authorsevaluatedthesystemonautomotive,chemical,and academic software requirements specification (SRS) documents,findingthatitdetectedanaverageof44findings per1,000wordsataprecisionrateof59%andarecallrate of 82%, supporting the idea that lightweight rule-based methodsprovidesufficientpracticaldefectcoveragewithout anoverheadassociatedwithmachinelearning(ML).Dalpiaz etal.usedREVV-Lighttovisualizeterminologicalambiguity withinuserstoriesandachievedprecisionandrecallrates comparable to manual inspection. Rempel and Maeder provided a measure for how complete traceability can reducedefectsindownstreamdevelopmentacross24opensourceprojects.Collectively,thesestudiessupportthatruleNLPhybridmethodswhichachieveaprecision/recallratein therangeof50-80%arepracticalforreal-worldSRSquality assurance, particularly when used with validation by practitionersforcontext-dependentissues
2.5 Gap in Existing Work
While the literature demonstrates strong individual proposalsfordefectidentification,scoring,andLLM-assisted rewriting,therearecurrentlynopubliclyavailabletoolsthat combine all three into a single unified pipeline for
International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056
Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072
practitioners.Availableresearchprototypes(e.g.,QuARSand TIGER)arenotaccessibletopractitioners.Commercialtools comewithveryhighlicensingcosts.Open-sourcetools do not provide scoring and/or correction of batches of identified defects from any of the activities. ReqClarity AI addressesthisgapbyprovidingafree,fullydeployed,endto-endrequirementsqualityanalysissystemcombiningrulebased detection, quantitative scoring, and LLM-assisted rewritinginasingleaccessiblewebapplication.
2.6 Large Language Models in Requirements
Engineering
Requirementsengineeringpresentsnewopportunitieswith the advent of large language models. Prior work demonstrates that prompt-engineered LLMs can rewrite ambiguous requirements into precise and well-structured specifications with minimal human intervention. Studies furtherindicatethatwhilesuchmodelsexhibitstronglexical capabilities in detecting inconsistencies and ambiguities, they often lack deeper semantic completeness, thereby highlighting the necessity of integrating rule-based componentstoenhanceoverallperformance.Additionally, incorporating explicit IEEE 830 context within prompts significantly improves the generation of standardscompliantrequirements.Theseinsightsdirectlyinformthe design of systems such as ReqClarity AI, which employ structured prompts based on IEEE 830 guidelines and produce outputs in a batched JSON format for efficient processing.
Together, these findings demonstrate that large language models effectively complement rule-based systems by addressing their limitations in generating fluent and contextuallyappropriaterequirementcorrections.
3. SYSTEM ARCHITECTURE
3.1
Architectural Overview
ReqClarityAIfollowsathree-tierclient-serverarchitectureaReact-basedpresentationlayer;aNode.jsapplicationlayer; andaMongoDBAtlaspersistencelayer,asshowninFigure1. ThefrontendandbackendcommunicateviaAxiosthrougha RESTful API using HTTPS protocol, where the frontend is hostedonVercelandthebackendishostedonRender.All resultsfromananalysisaresavedtoMongoDBAtlasandcan be retrieved using the analysis ID, keeping the backend stateless(i.e.,noserver-sidesession)
3.2 Frontend Layer (Tier 1)
ThefrontendisdevelopedusingReact18andVite,designed asasingle-pageapplicationwithReactRouterv7forclientside routing through 7 views: Home, Upload, Results, Dashboard, Rewrite, History, and Contact. The Dashboard visualizationsareproducedusingRecharts(scoregauge,pie chartofissues,barchartofrequirements).ThePDFfilesare exportedfromthefrontendviajsPDF(twodocumenttypes: anAnalysisReport; an SRS Document). Prioranalysesare storedinlocalstorageusinglightweightmetadata(filename, score,labelandanalysisID)toprovideanaccessiblemeans ofnavigatingtopreviousanalyseswithoutmakingadditional requeststotheserver.
3.3 Backend Layer (Tier 2)
UsingNode.jsandExpress,thebackendoffers sixRESTful APIendpointstocommunicateandperformactionsonthe data:
-TheAPIendpointtoPOST/api/uploadisthestartingpoint ofthewholeprocess.
- The API endpoint to GET /api/analysis/:id returns an existinganalysisresult'sinformation.
-ByusingtheDELETE/api/analysis/:idAPIendpoint,users can remove an analysis. - To accept a rewrite of a requirement, users can use PATCH /api/requirements/:id/accept.
-Whenausersubmitsamessageviathecontactform,this happensoverHTTPPOSTto/api/contact;
-GET/api/healthisanAPIendpointthatreturnsthehealth oftheentiredeployment.
BesidesbeingabletouploadfilesviaMultertoatemporary directory(/uploads)thatisprogrammaticallycreatedwhen the application starts, files are deleted immediately after parsing,sonodocumentsareretainedontheserver.
Fig. 1:SystemArchitecture
International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056
Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072
3.4 Five-Stage Analysis Pipeline
Fig 2:Documentuploadandpipelineexecutionin progress.
Everyuploadeddocumentisprocessedthroughasequential five-stagepipeline.
Stage 1 Parse: Rawtextisextractedviapdf-parse(PDF) orNode'sfsmodule(TXT),thensegmentedintoindividual requirements using line-by-line splitting with a sentencelevelfallbackforprose-formatteddocuments.
Stage 2 Detect: Eachrequirementpassesthroughthree independent detection modules ambiguity, nonverifiability, and incompleteness applying fifteen rule patternsvialexiconmatchingandregularexpressions.Each detected issue is tagged with type, severity, and flagged term.
Stage 3 Score: Each requirement receives a score via Score = max(0, 100 − Σ(Severity Weight × Type Weight)), usingseverityweightsH=25,M=15,L=8andtypemultipliers NT=1.2,IC=1.1,AM=1.0.Thedocumentscoreisthemeanof allrequirementscores,mappedtofivequalitybands.
Stage 4 Rewrite: Defective requirements are batched intoasingleGroqAPIcalltoLlama3.370B,underasystem promptenforcingIEEE830conventions(shall,activevoice, measurable specificity), with responses constrained to structuredJSONkeyedbyrequirementindex.
Stage 5 Save: The complete analysis and all perrequirementrecords are persisted toMongoDBAtlas,and the full JSON payload is returned to the frontend for immediaterendering.
3.5 Data Layer (Tier 3)
PersistenceisaccomplishedusingtwoMongoDBcollections (via Mongoose): Analysis and Requirement. The Analysis Collectionmaintainsdocument-levelmetadata:
-Thefilename
-Overallscore
-Qualitylabel
-Issuecategorycounts
-Totalnumberofrequirements
-Processingtimefordocument
The Requirement Collection maintains per-requirement data:
-Originaltext
-Scorefortherequirement
-Structuredarrayofissues(type,severity,flagged word,description)
-LLM-generatedrewriteoftheoriginal
-Aflagindicatingwhethertherewritewasaccepted (boolean, updated via PATCH when the user interacts)
4. METHODOLOGY
4.1
Document Parsing and Segmentation
Documentsuploadedtotheserverareprocessedusingpdfparse for PDF files and using Node's native fs module for plaintext. Once the texthas been extracted, it issplit into segmentsintwotiers.First,eachlineoftextissplitoutas separatelinesandanylines thatmatchanyofthespecific pattern-basedrulesforheaders,numbers,andboilerplateor othersimilartextareremoved.Allremaininglinesarethen treatedasseparaterequirementstatements.Inthecaseof documentsthatarewrittenincontinuousproseinsteadof broken into paragraph forms, we fall back on sentence segmentation,whichprovidesthateachrequirementwillbe separatedfromeachotherbasedontheperiodattheendof eachsentence.However,therequirementsthatfallbelowa minimumthresholdfortotalcharactersizearenotretained, becausethatwouldclassifythemasfragments
4.2 Defect Detection Engine
Fig 3: Resultsviewshowingper-requirementdefecttags, qualityscores,andfiltercontrols
Thedetectionengineappliesthreeindependentmodules–one per defect dimension. Each independent module is a combination of pre-defined lexicons and a set of regular expressions.
4.2.1 Ambiguity Detection
Fiverulecategoriesidentifyambiguouslanguage:
International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056
Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072
Vague adjectives and adverbs a lexicon of 23 terms including fast, reliable, adequate, and appropriate
Weak modal verbs should, may, might, could,and would inplaceoftheIEEE830-mandated shall
Passive voice constructions regex pattern detectingmissingactoridentification
Vague quantifiers several, many, few, some, various, numerous
Imprecise time references soon, quickly, periodically, in a timely manner.
4.2.2 Non-verifiability Detection
Five rule categories identify requirements that cannot be objectivelyverified:
Subjective quality terms a lexicon of 19 terms including user-friendly, intuitive, seamless, high quality
Unmeasurable performance claims performance verbswithoutadjacentnumericvalues
Missing metric patterns quantifiablebehaviours describedwithoutnumericbounds
Missing acceptance criteria verbssuchas ensure, guarantee, provide withoutmeasurableparameters
Subjective comparisons better than, faster than withoutadefinedbaseline
4.2.3
Incompleteness Detection
Five rule categories identify requirements with missing behaviouralspecification:
Missing actor requirementsbeginningwith shall withoutasubjectentity
Incomplete conditionals if/when/unless clauses withoutacorrespondingconsequence
Missing constraints sub-patternsforabsentsize, authentication,time,anddisplayconstraints
Incomplete sentence structures requirements lackingacompletepredicate
Missing error handling operationswithnofailure behaviourspecified
4.3 Quality Scoring Model
Eachrequirementisassignedaqualityscoreintherange[0, 100]usingaweightedpenaltymodel:
Severityweightsreflecttherelativeimpactofeachissueon requirement usability: High = 25, Medium = 15, Low = 8. Typemultipliersreflecttherelativedownstreamcostofeach defect dimension based on established requirements engineering literature: Non-verifiability = 1.2, Incompleteness=1.1,Ambiguity=1.0.Multipleissuesona singlerequirementaccumulatepenaltiesadditively,withthe scoreflooredatzero.
Table 1: Qualitybandclassificationthresholds
Score
Range Quality Label Interpretation
90–100 Excellent Minimalornodefectsdetected
75–89 Good Minor issues; light revision recommended
60–74 Fair Moderate defects; revision required
40–59 Poor Significant defects; substantial reworkneeded
0–39 Critical Pervasive defects; document requiresfullrevision
4.4 LLM-Assisted Requirement Rewriting
If a requirement receives a scorelower than Excellent, the system routes it to the LLM-based rewrite pipeline. The systembatchesdefectiverequirementsintoasingleAPIcall to the Groq inference API using the Llama 3.3 70B model, thereby reducing latency associated with sequential invocation.
The system prompt instructs the model to generate IEEE 830-compliantrewritesforeachrequirementwhileenforcing four correction principles:(1) replacement of weak modal verbswith shall;(2)transformationofpassiveconstructions intoactivevoice;(3)substitutionofvagueexpressionswith measurableandverifiablespecifications;and(4)inclusionof missingactors,constraints,orerror-handlingclausesinferred fromcontextualinformation.
The model returns its output as a structured JSON object keyedbyrequirementindex,enablingdeterministicparsing withoutrelianceonpost-processingheuristics.
Thesystemstoreseachrewrittenrequirementalongsideits originalcounterpartandpresentsboththroughtheRewrite interface for user validation. Upon user acceptance, the systemreplacestheoriginalrequirementwiththerewritten version during SRS PDF export; otherwise, it discards the rewriteandretainstheoriginaltext.
5. RESULTS AND EVALUATION
5.1 Evaluation Setup
AtestcorpusoffifteenSRSdocumentswascreatedusingfive different quality bands Critical, Poor, Fair, Good and Excellent with three documents for every band. The documentsusedforthecorpuscamefromseveraldomains: e-commerce, hospital management, mobile banking, inventory management, and university administrative support. The documents were deliberately constructed to represent a wide range of defect densities. Evaluation occurredacrossfourdimensions segmentationaccuracy, defect detection (performance), scoring consistency and qualityofAI-generatedrewrites.Theauthorindependently labelled 75 requirements to establish ground truth; this
International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056
Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072
sample was taken from a subset of five documents and included labelling each requirement for ambiguity, nonverifiability,andincompleteness.Tomitigatesubjectivebias, futureworkwillincludemulti-annotatorvalidationandinterrateragreementmetrics(e.g.,Cohen’skappa).
5.2 Segmentation Results
AllfifteenSRSdocumentsweresuccessfullysegmentedinto discrete (individual) requirements with no manual segmentationbeingperformedbytheauthor.Theparser’s primary segmentation engine processed line-formatted documents, while the secondary segmentation/formatting methodologyprocessedcontinuousprosedocumentsatthe sentence level. In total, 187 discrete requirements were identifiedacrossallfifteenSRSdocuments,andnoinstances of over-segmentation were found within compound requirementsthatincludedexplicitconjunctions.
5.3 Defect Detection Performance
Table 2 presents precision, recall, and F1 scores for each detection module evaluated against the 75 manually annotatedrequirements.
Table 2: Defectdetectionprecision,recall,andF1scores percategory.
5.4 Scoring Consistency
Fig. 4:Analysisdashboarddisplayingoverallquality scoreanddefectcategorybreakdown
Notably, all fifteen documents were assigned scores that reflected the quality level intended, suggesting that the weightedpenaltymodelcanefficientlyseparatedocuments that have varying quality levels. Mean scores also indicate thatadjacentscorebandsproducedsignificantmeanscore differences without overlap between observed ranges of scoresproducedwithtesteddocuments.
Table3presentsthesystem-assignedscoresforeachquality bandagainsttheirintendedranges.
Table 3: Scoringconsistencyacrossqualitybands.
TheambiguitymoduleachievedanF1scoreof0.85,reflecting theeffectivenessoflexicalmatchingagainsta well-defined set of vague terms. Non-verifiability and incompleteness modulesproducedF1scoresof0.80.Mostfalsenegativesthat occurred in the incompleteness module were due to requirementsomittingconstraintsindomainsnotcoveredby thepre-definedsetofkeywords.Mostofthefalsepositives that occurred in the non-verifiability module were due to using domain-specific technical terms that were matched incorrectly against the lexicon used for subjective quality terms.
5.5 AI Rewrite Quality
The rewrite pipeline was evaluated on 43 defective requirementsdrawnfromthetestcorpus,assessedmanually againstthreecriteria:defectelimination,intentpreservation, andIEEE830compliance.
International
Volume: 13 Issue: 03 | Mar 2026 www.irjet.net
Table 4: AIrewritequalityevaluationresults.
Themostcommonfailuremodewasover-specificationdueto theidentificationofnumericvalues(e.g.,specificresponse periods,datalimits)thatcouldnotbederivedfromwithin thecontextoftheoriginalrequirementandthatwouldhave needed verification from the stakeholder for acceptability. Over-specification is an inherent limitation of the use of single-turnLLMinferencewithoutaccesstodomaincontext thatgoesbeyondtheoriginalrequirementtext.
5.6 Pipeline Performance
Acrossallfifteentestdocuments,end-to-endprocessingtime wasmeasured.Theaveragetimefromthemomenttheuser uploadsadocumentuntiltheresultsaredisplayedwas6.3 seconds, with most of the total time (approximately 74%) relatingtothetimetakentorewritetherequirementsusing AI.Documentsthathadfewerthanfivedefectsintheirsetof requirements were processed in under 4 seconds. The maximumprocessingtimerecordedwas11.2seconds,forthe document containing 22 total requirements; 18 of the requirements required an AI rewrite. These results are deemedacceptableforweb-basedsystems,astheprocessing isdoneasynchronouslyandaloadingiconisdisplayedduring processing.
6. CONCLUSION
6.1
Summary
This research details ReqClarity AI, an automated quality assessment tool for Software Requirements Specifications (SRS)availableviaaweb-basedportal.ReqClarityAIemploys naturallanguageprocessing(NLP)techniquesandscoringto identifydefectsandprovidefeedbacktoauthors.Thisstudy demonstratesthatReqClarityAIaddressesasignificantgap in existing quality assessment solutions, particularly given theabsenceoffree,comprehensive,end-to-endsolutions.
Thedetectionenginecontaining15patternstodetectdefects withthreedefectcategoriesachievedatotalF1scoreof0.82 whenusingamanuallyannotatedtestdatasetandshowed thatcomputationallylightweightmethodsbasedonpattern matching could successfully identify defects within the variousdefectcreationcategoriesusingnomodeltrainingor collected labelled datasets. Similarly, the weighted scoring method matched all 15 of the test documents to their respectivequalitybandswithnooverlapintoadjacentbands Inaddition,theLLMrewritepipelineproducedIEEE830/ ISO/IEC/IEEE29148-alignedrewritesfor88.4%ofdefective
requirements with a mean processing time of 6.3 seconds end-to-end.
Furthermore, ReqClarity AI is proof that it is feasible to combine deterministic rule-based analysis for explainable defectdetectionwithgenerativeAItoolstocreateaseamless analyticalprocessflow.Therule-basedlayeridentifiesand records defects to provide evidence for corrective action. However, its inherent limitation isan inability to generate fluent,context-appropriatenaturallanguagecorrections a gap addressed by the LLM rewriting stage The overall performance of the hybrid model demonstrates effective detection and correction of software defects through the integration of deterministic rule-based processes and complexnaturallanguagegenerationdesignpatterns.
6.2 Limitations
Several limitations of the current system merit acknowledgment. The detection engine relies on fixed lexicons and regex patterns, which may not generalize to highly domain-specific SRS documents using specialized technicalvocabulariesoutsidethepredefinedkeywordsets. The scoring model's penalty weights and type multipliers weredeterminedempiricallyratherthanthroughaformal calibrationstudyagainsta large,annotated corpus. TheAI rewrite pipeline's tendency toward over-specification introducing numeric values not derivable from original requirement context is an inherent limitation of singleturn LLM inference without access to broader domain knowledge. Finally, the system does not currently detect cross-requirementconsistencydefects,acategoryidentified intheliteratureasasignificantcontributortodownstream developmenterrors.
6.3 Future Work
SeveraldirectionsareidentifiedforextendingReqClarityAI infuturework.
Cross-requirement consistency checking is the most immediately impactful extension. The current system analyses each requirement in isolation; detecting contradictions, duplicate specifications, and dependency conflicts across requirements requires semantic similarity measuresorgraph-baseddependencymodellingthatwillbe exploredinsubsequentiterations.
ML-based detection enhancement represents a natural evolutionoftherule-basedengine.Fine-tuningaBERT-based classifier on a requirements-specific annotated corpus such as the PROMISE NFR dataset would extend defect detection to semantic and pragmatic ambiguity categories thatlexiconandregexpatternscannotreliablycapture,while retainingtherule-basedlayerforhigh-recallinitialscreening.
Multi-turn LLM rewriting could address the overspecification failure mode identified in the evaluation. A conversationalrefinementloop wherethemodelrequests missingcontextualinformation(suchasperformancebounds or actor identities) before generating a rewrite would
International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056
Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072
producecorrectionsthatare both standard-compliantand stakeholder-validated.
Support for additional requirement formats including user stories, use case specifications, and Gherkin-style acceptance criteria would extend the tool's applicability beyond traditional IEEE 830-formatted SRS documents to agiledevelopmentcontexts.
User authentication and team collaboration features would enable shared SRS workspaces where multiple engineers can jointly review, accept, and track rewrites acrossdocumentversions aprerequisiteforadoptionin organizationalsettings.
Formal scoring calibration via a large-scale annotated requirementsdatasetwouldreplacethecurrentempirically determined penalty weights with statistically grounded values,improvingthescoringmodel'sgeneralizabilityacross domainsanddocumentstyles.
6.4 Closing Remarks
ReqClarity AI is freely accessible at https://req-clarityai.vercel.app and the source code is available at https://github.com/urzarai/ReqClarity_AI. The system is designed with a modular pipeline architecture that accommodates the extensions identified above without requiring fundamental restructuring, positioning it as a foundation for continued research and development in automatedrequirementsqualityassurance.
ACKNOWLEDGEMENT
TheauthorwishestothankProfessorDr.SrivaniA.forher invaluable guidance, motivation, and continuous support throughoutthedevelopmentofthisprojectonSRSanalysis andrewritingusingartificialintelligence.Herinsightsand constructivefeedback significantlycontributed toshaping boththedirectionandqualityofthiswork.
TheauthoralsowishestothankDr.SharmilaBanu,Headof the Department, for her constant encouragement, her invaluableguidance,andfor fosteringa positiveacademic environmentthatpromotescreativityandlearning. Finally, the author acknowledges Vellore Institute of Technology,Vellore,forprovidingthenecessaryresources, facilities, and opportunities to successfully complete this project.
REFERENCES
[1]V.Gervasi,A.Ferrari,D.Zowghi,P.Spoletini,“Ambiguity in Requirements Engineering: Towards a Unifying Framework,”n.d.
[2] G. Lami, C. Scondras, “QUARS: A Tool for Analyzing Requirements,” Carnegie Mellon University, Technical ReportCMU/SEI-2005-TR-014,2005.
[3]G.Lami,S.Gnesi,F.Fabbrini,M.Fusani,G.Trentanni,“An Automatic Tool for the Analysis of Natural Language Requirements,”n.d.
[4]A.Ferrari,G.Lipari,S.Gnesi,G.O.Spagnolo,“Pragmatic Ambiguity Detection in Natural Language Requirements,” AIRE 2014,2014.
[5] S. Ezzini, S. Abualhaija, C. Arora, M. Sabetzadeh, “Automated Handling of Anaphoric Ambiguity in Requirements:AMulti-SolutionStudy,” ICSE 2022,2022.
[6]D.M.Berry,E.Kamsties,M.M.Krieger,“FromContract Drafting to Software Specification: Linguistic Sources of Ambiguity,”2003.
[7] A. Bajceta, M. Leon, W. Afzal, P. Lindberg, M. Bohlin, “Using NLP Tools to Detect Ambiguities in System Requirements: A Comparison Study,” NLP4RE Workshop, 2021.
[8] A. Ramos, “Enhancing Requirements Quality Through AutomatedAmbiguityDetection:AComparativeAnalysisof Manual,Rule-BasedandGenerativeAITechniques,”Thesis, 2025.
[9] A. K. Massey, R. L. Rutledge, A. I. Antón, P. P. Swire, “Identifying and Classifying Ambiguity for Regulatory Requirements,”2021.
[10]A.Nigam,N.Arya,B.Nigam,D.Jain,“ToolforAutomatic Discovery of Ambiguity in Requirements,” International Journal of Computer Science Issues,vol.9,no.5,pp.350–357, 2012.
[11] L. Zhao, W. Alhoshan, A. Ferrari, K. J. Letsholo, M. A. Ajagbe, E.-V. Chioasca, “Natural Language Processing for Requirements Engineering: A Systematic Mapping Study,” ACM Computing Surveys,vol.54,no.3,2022.
[12] S.-C. Necula, F. Dumitriu, V. Greavu-S, “A Systematic LiteratureReviewonUsingNaturalLanguageProcessingin Software Requirements Engineering,” Electronics, vol. 13, 2024.
[13]A.Ferrari,G.Gori,B.Rosadini,I.Trotta,S.Bacherini,A. Fantechi, S. Gnesi, “Detecting Requirements Defects with NLP Patterns: An Industrial Experience in the Railway Domain,”2021.
[14] C. Arora, M. Sabetzadeh, L. C. Briand, F. Zimmer, R. Gnaga,“RUBRIC:AFlexibleToolforAutomatedCheckingof Conformance to Requirement Boilerplates,” ACM Transactions on Software Engineering and Methodology,vol. 30,no.4,2021.
[15] L. Zhao, W. Alhoshan, A. Ferrari, K. J. Letsholo, “ClassificationofNaturalLanguageProcessingTechniques forRequirementsEngineering,” IEEE RE 2021,2021.
[16] N. Kiyavitskaya, N. Zeni, L. Mich, D. M. Berry, “Requirements for Tools for Ambiguity Identification and
International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056
Volume: 13 Issue: 03 | Mar 2026 www.irjet.net p-ISSN: 2395-0072
Measurement in Natural Language Requirements Specifications,”2007.
[17]S.Ezzini,S.Abualhaija,C.Arora,M.Sabetzadeh,“Using Domain-Specific Corpora for Improved Handling of AmbiguityinRequirements,” IEEE Transactions on Software Engineering,2021.
[18] F. Dalpiaz, I. van der Schalk, S. Brinkkemper, F. B. Aydemir,G.Lucassen,“DetectingTerminologicalAmbiguity inUserStories:ToolandExperimentation,” Informationand Software Technology,vol.110,pp.3–16,2018.
[19]A.Vaswani,N.Shazeer,N.Parmar,J.Uszkoreit,L.Jones, A. N. Gomez, Ł. Kaiser, I. Polosukhin, “Attention Is All You Need,” NeurIPS,2017.
[20]J.Devlin,M.-W.Chang,K.Lee,K.Toutanova,“BERT:Pretraining of Deep Bidirectional Transformers for Language Understanding,” NAACL-HLT,2019.
BIOGRAPHY
Urza Rai is an undergraduate Computer Science student at Vellore Institute of Technology, with strong interests in software engineering,AI,andrequirements analysis.