# I. Introduction uality Assurance ensures that the product manufactured is without defects. For this, the quality of the requirements should be fulfilled. Quality Assurance must be done in requirement engineering process, so that the most valuable requirements should be added. The Quality Assurance of Requirements is much important, as it is said by Boehm and Basili; "Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase." This research work is based on a survey related to the quality assurance in requirement engineering. The analysis of different on the perspective of different research paper is done using different parameters like quality, feasibility, maintainability, understanding, reusability etc. Each research paper has its own perspective to verify the quality of requirements. The evaluation criteria are given in the TABLE 1, for comparing effects of differrent parameters that are discuss in analysis. Brief sumaries of each survey papers are also mentioned below. # II. Experiences on Analysis of Requirements Quality [1] Requirement engineering is the most important and critical process in the software development life cycle. The quality of the system depends on the quality of requirements that are difficult to recognize in requirements development phase but it has a great impact on the product quality. This paper proposed a method known as LaQuSo Software Product Certification Model for certifying the quality of requirements specification. This method explains three different certification criteria for all product areas; Completeness of the required elements, Uniformity of the product area should be with respect to standards, Conformance of the elements should be according to the property that is subject of the certification. These all criteria focus on the verification of the requirements. # III. Assessing the Quality of Software Requirement Specification [2] In the initial stage it is difficult to determine whether the SRS will provide the final product. So, a quality model is needed known as Goal-Question-Matric (GQM) method. This paper gives the outline of researchers plan related to GQM, their findings, and finally proves that their quality assessment helps in the project success. IV. Improvement of Quality of Software Requirements with Requirements Ontology [3] Requirements elicitation is the most difficult task in requirement engineering. The quality and the quantity of elicit requirements depend on both analysts ability and his domain knowledge of the target system. This paper helps in the improvement of quality and quantity of the elicit requirements using requirements ontology model. This paper checks the correctness, completeness and quality of the requirements. V. Applying Case-based Reasoning to Software Requirements Specifications Quality Analysis System [4] This paper focuses on the quality of the prepare software requirement specification. The technique used is Software Quality Assurance audit to check whether the required standards and procedures within this phase are followed or not. This technique checks whether the requirements are complete, modifiable, consistent, ranked, correct, unambiguous, understandbleandtraceable. The case-based Reasoning technique is used to check the quality of requirements with respect to the previous quality based cases. Requirement engineering process is volatile. This paper developed a model that support the new artifact based philosophy. This approach helps in the improvements in syntactic and the semantic quality of created artifacts. This approach defines the reference model of the artifacts for development process. This paper also showed the increase in the completeness and consistency of artifact and also their flexibility. VII. What you Need is What you Get! the Vision of View-based Requirements Specifications [6] This paper worked on the improvement of high quality SRS that fit the particular requests for progressive record stakeholders. For the quality of requirements, its data and the system function and interaction, viewpoints of architectural experts, goals description and technical requirements are most important artefacts. # VIII. Defects in Natural Language Requirement Specifications at Mercedes-Benz: an Investigation using Acombination of Legacy Data and Expert Opinion [7] This paper works on the study of natural language of Software Requirement Specification. With respect to the quality model, the results obtained are: defect in natural language of SRS in automotive domain; for defect extremity, the associations of quality parameters; signs on the handling quality parameters; time needed information for defect association on the basis of quality parameters. The results ensure that the important quality parameters in investigated NL parameters are completeness, consistency and correctness. IX. Foreword Quality in Agile Methods [8] This paper worked on many different methods and views related to the quality of agile methods. The discoveries of these investigations assist developers, researchers and managers, in this agile method field. The discoveries are made to understand how to reduce the issues of quality while working on this method. X. A Framework of Software Requirements Quality Analysis System using Case-based Reasoning and Neural Network [9] This paper worked in the improvement of quality analysis process of Software Requirement Specification. It ensures that the Software Requirement Specification document must have some standards. Further, the analysis of SRS qualityis done by using Neural Network (ANN) and CBR techniques.CBR works in the improvement of quality by the reference of past experiences. ANN also works with CBR. # XI. A Process Improvement in Requirement Verification and Validation using Ontology [10] After developing the system, the verification and validation is always done but still there are issues of stakeholders in different domains. The problem arises in the verification and validation of requirement which are difficult activities in requirement engineering. This paper works on removing the conflicts of requirements, their consistencies and recognizing the failure due to requirements. These goals are achieved by ontology which is also used for the verification and validation of requirements. # XII. It's the Activities, Stupid! a New Perspective on Re Quality [11] Requirement engineering is the important process in System Development. Its Quality must be ensured for testing, development and other software activeties. This paper introduces a context-specific Requirement Engineering artifacts Quality and explain how the quality parameters of RE artefacts affect the activities of development. # XIII. Software Quality Control Via exit Criteria Methodology: An Industrial Experience Report [12] This paper introduces the Exit Criteria Methodology. This methodology helps in vast financial systems to improve the quality of the system from the beginning of a SCRUM sprint to the end. As a wholeprocess control of quality, the methodology is executed from the quality plan to the quality review. # XIV. Quality Assessment Method for Software Requirements Specifications based on Document characteristics and Its Structure [13] In this research it is presented that in software development process quality of SRS should be maintained. For this process different assessment methods are used by keeping in mind the three characteristics of SRS unambiguous variable and modifiable because it is necessary to satisfy the customers. # XV. Security Assurance Requirements Engineering (stare) for Trustworthy Service level Agreements [14] In this research through two case studies it is discussed that how STARE is effective in real world by evaluating that STARE from different techniques and easement criteria and how TSLA can be used to achieve TSLA can be used to achieve the trust worthless service. # XVI. Does Quality of Requirements Specifications Matter? Combined Results of Two Empirical Studies [15] Quality of SRS depends on efficient and effectiveness of quality assurance and by two correlations it is proved that SRS is less used for communication because of it defects. In future it is necessary to document SRS on certain degree. # XVII. Naming the Pain in Requirements Engineering [16] This paper explains that for better quality requirements, human interaction is important for elicitation regardless of project type and company size. For this standard process models and certifiable improvement standards are used. There is not necessary to use agile or non-agile methods for better quality. It is actually the way to solve the problems. The problem itself manifest in different ways. # XVIII. Quality Assurance of Component based Software Systems [17] On this latest technology our software's and web based applications are more complicated and with complex coding. Quality Assurance also maintains and reduces more work effort and also helps organization to develop application in the right path from the initial stage to the ending point. # XIX. Assessing the Quality of Software Requirements Specifications for Automotive Software Systems [18] In this paper we conclude that SRS can be depend on the software or application we need to develop. There some types of SRS std. IEEE 830 to 1998. Several standards organizations including the IEEE have identified some points during designing and writing an SRS; Interfaces, Functional Capabilities, Performance Levels, Data Structures/Elements, Safety, Reliability, Security/Privacy, Quality, Constraints and Limitations. ding to experts Q. A reduce 50% effort in final stage. It also helps developers and also help to track any bug. By applying all Q.A methodology you can also improve your application efficiency. # XXI. How Artifacts Support and Impede Requirements Communication [20] In this we collect information from different recourses that artificial mapping is not suitable for all types of project because in some cases it will be costly according to other, it should be suitable for linking bases modules. # XXII. Analysis of Quality Parameters for Requirements a) Feasibility The requirements must be feasible in perspective of the financial plan, timetable, and innovation limitations # b) Comprehensibility The definition of requirements must be intelligible by the general population who need to utilize them. # c) Good Structuring The document of the requirements ought to be composed as it were that highlights the auxiliary connections among its components # d) Modifiability It ought to be conceivable to change, adjust, develop, or contract the document of the requirements through adjustments that are as nearby as could reasonably be expected # e) Traceability The setting in which a thing of the requirements archive was made, adjusted, or utilized ought to be anything but difficult to recover. Such setting ought to incorporate the method of reasoning for creation, adjustment, or utilize. # f) Efficiency The requirements should be efficient that is they must fulfill the functionality and they also help in increasing the performance of the product. # g) Correctness The requirements that are going to be implemented must be correct. They must be related to the functionality of the product. # Global Journal of Computer Science and Technology Volume XVII Issue I Version I According to my opinion Q.A is most important part it plays as a back bone of any application. Accor # h) Completeness The requirements that are going to implemented must be complete. # XXIII. Conclusion The paper discusses different factors to improve the quality of the product from the initial stage Quality Assurance in Requirement Engineering that is requirement engineering. Different models like LaQuSo, ANN, CBR and many more are introduced for checking different quality parameters including correctness, completeness etc. The feasibility, comprehendsbility, Modifiability, good structuring, completeness etc. are the parameters that effect quality of requirements and by analyzing them a better quality of requirements can be achieved. For better quality product, the requirements must be of better quality. # XXIV. Acknowledgement I thank to my department of Software Engineering and my teacher, Ma'am MehreenSirshar, who have contributed towards the development of this research paper. # References Références Referencias 112. Xiaoqiong Zhao, Xiao Xuan, Aoyu Wangy , DongLiuz,Lingyun Zheng, Software Quality Control viaExit Criteria Methodology: An Industrial ExperienceReport, 2014 21st Asia-Pacific Software EngineeringConference13. Patra Thitisathienkul, NakornthipPrompoon, QualityAssessment Method for SoftwareRequirementsSpecifications based on Document Characteristicsand its Structure, 2015 2nd International Conferenceon Trustworthy Systems and Their Applications14. Yudhistira Nugraha, Security Assurance Require-Year 2017ments Engineering(STARE) for Trustworthy Service Level Agreements, 2015 15. Jakob Mund, Henning Femmer, Daniel M´endezFern´andez, Jonas Eckhardt, Does Quality of Req-4uirements Specifications matter? Combined Results1. Petra Heck, PäiviParviainen, Experiences on Ana-lysis of Requirements Quality, 2008 IEEE The Third International Conference on Software Engineering Advances. 2. Eric Knauss, Christian El Boustani, Assessing the Quality of Software Requirements Specifications, 2008 16th IEEE International Requirements Engine-ering Conference 3. Dang Viet Dzung, Atsushi Ohnishi, Improvement of Quality of Software Requirements with Require-ments Ontology, 2009 Ninth International Confe-rence on Quality Software 4. Hajar Mat Jani,Applying Case-Based Reasoning to Software Requirements Specifications Quality Analy-sis System, 5. Daniel M´endezFern´andez, Klaus Lochmann, Birgit Penzenstadler, Stefan Wagner, A Case Study on the Application of an Artefact-Based Requirements Engineering Approach, 2011 6. Anne Gross, JoergDoerr, What You Need Is What You Get! The Vision of View-Based Requirements Specifications, 2012 7. Daniel Ott, Defects in Natural Language Require-ment Specifications at Mercedes-Benz: AnInvesti-gation Using a Combination of Legacy Data and Expert Opinion, 2012 8. Panagiotis Sfetsos, ForewordQuality in Agile Methods, 9. Hajar Mat Jani, ABM Tariqul Islam, A Framework of Software Requirements Quality Analysis System using Case-Based Reasoning and Neural Network, 17. Global Journal of Computer Science and Technology 16. Daniel Méndez Fernández, Stefan Wagner, Marcos of Two Empirical Studies, 2015 Kalinowski, André Schekelmann, Ahmet Tuzcu, Tay-ana Conte, Rodrigo Spinola, and Rafael Prikladnicki, Naming the Painin Requirements Engineering, 2015 Volume XVII Issue I Version I ( )10. Sana Nazir, Yasir Hafeez Motla, Tahir Abbas, AsmaKhatoon, JavariaJabeen, MehwishIqr,KhushBakhat,A Process Improvement in RequirementVerificationand Validation using Ontology,11. Henning Femmer, JakobMund, Daniel M´endezFern´andez, It's the Activities, Stupid!A New Pers-pective on RE Quality, 2015 IEEE/ACM 2nd Interna-tional Workshop on Requirements Engineering andTesting 2No.ParametersDescriptionValue1. FeasibilityRequirements are easy to useYes, No2. Comprehensibility Requirements are understandable to other peopleYes, No3. Good StructuringRequirements are well structured and have links among its elements Yes, No4. ModifiabilityRequirements are revisable and adaptable.Yes, No5. TraceabilityEasy to trace the requirementsYes, No6. EfficiencyRequirements fulfill the functionality.Yes, No7. CorrectnessChecks whether the requirements are correct.Yes, No8. CompletenessChecks whether the requirements are complete.Yes/No © 2017 Global Journals Inc. (US) ## Auther ## Feasibility ## Compre hensibili ty ## Good Structurin g ## Modifiability ## Traceability ## Effici ency ## Correctness