Relevant bibliographies by topics / Software requirements specification (SRS)

Contents

  1. Journal articles
  2. Dissertations / Theses
  3. Books
  4. Book chapters
  5. Conference papers
  6. Reports

Academic literature on the topic 'Software requirements specification (SRS)'

Author: Grafiati
Published: 4 June 2021
Last updated: 1 February 2022

Create a spot-on reference in APA, MLA, Chicago, Harvard, and other styles

Select a source type:

Consult the lists of relevant articles, books, theses, conference reports, and other scholarly sources on the topic 'Software requirements specification (SRS).'

Next to every source in the list of references, there is an 'Add to bibliography' button. Press on it, and we will generate automatically the bibliographic reference to the chosen work in the citation style you need: APA, MLA, Harvard, Chicago, Vancouver, etc.

You can also download the full text of the academic publication as pdf and read online its abstract whenever available in the metadata.

Journal articles on the topic "Software requirements specification (SRS)"

1

Et.al, Osman, M. H. "Ambi Detect: An Ambiguous Software Requirements Specification Detection Tool." Turkish Journal of Computer and Mathematics Education (TURCOMAT) 12, no. 3 (April 10, 2021): 2023–28. http://dx.doi.org/10.17762/turcomat.v12i3.1066.

Full text
Abstract:
Software Requirements Specification (SRS) is considered a highly critical artifact in the software development. All phases in software development are influenced by this artifact. Defects in software requirements may higher the risk of project overschedule that contributes to cost overrun of the project.Researchers have shown that finding defects in the initial software development phase is important becausethe cost of the bug is cheaper if it is fixed early. Hence, our main goal is to provide a platform for requirement engineers to produce better requirement specifications. We propose AmbiDetect, a (prototype) tool toautomatically classify ambiguous software requirements. AmbiDetect combines text mining and machine learning for ambiguous requirement specification detection. The text mining technique is used to extract classification features as well as generating the training set.AmbiDetect usesa machine learning technique to perform the ambiguous requirement specification detection. From an initial user study to validate the tool, the result indicates that the accuracy of detection is reasonably acceptable.Although AmbiDetect is an early experimental tool, we optimist that this tool can be a platform to improve SRS quality.
APA, Harvard, Vancouver, ISO, and other styles
2

Et.al, Naveen N. Kulkarni. "Tailoring effective requirement's specification for ingenuity in Software Development Life Cycle." Turkish Journal of Computer and Mathematics Education (TURCOMAT) 12, no. 3 (April 11, 2021): 3338–44. http://dx.doi.org/10.17762/turcomat.v12i3.1590.

Full text
Abstract:
Software Requirements Engineering (SRE) process define software manuscripts with sustaining Software Requirement Specification (SRS) and its activities. SRE comprises many tasks requirement analysis, elicitation, documentation, conciliation and validation. Natural language is most popular and commonly used to form the SRS document. However, natural language has its own limitations wrt quality approach for SRS. The constraints include incomplete, incorrect, ambiguous, and inconsistency. In software engineering, most applications are object-oriented. So requirements are unlike problem domain need to be developed. So software documentation is completed in such a way that, all authorized users like clients, analysts, managers, and developers can understand it. These are the basis for success of any planned project. Most of the work is still dependent on intensive human (domain expert) work. consequences of the project success still depend on timeliness with tending errors. The fundamental quality intended for each activity is specified during the software development process. This paper concludes critically with best practices in writing SRS. This approach helps to mitigate SRS limitation up to some extent. An initial review highlights capable results for the proposed practices
APA, Harvard, Vancouver, ISO, and other styles
3

Mahalakshmi, K., Udayakumar Allimuthu, L. Jayakumar, and Ankur Dumka. "A Timeline Optimization Approach of Green Requirement Engineering Framework for Efficient Categorized Natural Language Documents in Non-Functional Requirements." International Journal of Business Analytics 8, no. 1 (January 2021): 21–37. http://dx.doi.org/10.4018/ijban.2021010102.

Full text
Abstract:
The system's functional requirements (FR) and non-functional requirements (NFR) are derived from the software requirements specification (SRS). The requirement specification is challenging in classification process of FR and NFR requirements. To overcome these issues, the work contains various significant contributions towards SRS, such as green requirements engineering (GRE), to achieve the natural language processing, requirement specification, extraction, classification, requirement specification, feature selection, and testing the quality attributes improvement of NFRs. In addition to this, the test pad-based quality study to determine accuracy, quality, and condition providence to the classification of non-functional requirements (NFR) is also carried out. The resulted classification accuracy was implemented in the MATLAB R2014; the resulted graphical record shows the efficient non-functional requirements (NFR) classification with green requirements engineering (GRE) framework.
APA, Harvard, Vancouver, ISO, and other styles
4

Hayman Oo, Khin, Azlin Nordin, Amelia Ritahani Ismail, and Suriani Sulaiman. "An Analysis of Ambiguity Detection Techniques for Software Requirements Specification (SRS)." International Journal of Engineering & Technology 7, no. 2.29 (May 22, 2018): 501. http://dx.doi.org/10.14419/ijet.v7i2.29.13808.

Full text
Abstract:
Ambiguity is the major problem in Software Requirements Specification (SRS) documents because most of the SRS documents are written in natural language and natural language is generally ambiguous. There are various types of techniques that have been used to detect ambiguity in SRS documents. Based on an analysis of the existing work, the ambiguity detection techniques can be categorized into three approaches: (1) manual approach, (2) semi-automatic approach using natural language processing, (3) semi-automatic approach using machine learning. Among them, one of the semi-automatic approaches that uses the Naïve Bayes (NB) text classification technique obtained high accuracy and performed effectively in detecting ambiguities in SRS.
APA, Harvard, Vancouver, ISO, and other styles
5

Haris, M. Syauqi, Tri Astoto Kurniawan, and Fatwa Ramdani. "Automated Features Extraction from Software Requirements Specification (SRS) Documents as The Basis of Software Product Line (SPL) Engineering." Journal of Information Technology and Computer Science 5, no. 3 (December 31, 2020): 279. http://dx.doi.org/10.25126/jitecs.202053219.

Full text
Abstract:
Extractive Software Product Line Engineering (SPLE) puts features on the foremost aspect in domain analysis that needs to be extracted from the existing system's artifact. Feature in SPLE, which is closely related to system functionality, has been previously studied to be extracted from source code, models, and various text documents that exist along the software development process. Source code, with its concise and normative standard, has become the most focus target for feature extraction source on many kinds of research. However, in the software engineering principle, the Software Requirements Specification (SRS) document is the basis or main reference for system functionality conformance. Meanwhile, previous researches of feature extraction from text document are conducted on a list of functional requirement sentences that have been previously prepared, not literally SRS as a whole document. So, this research proposes direct processing on the SRS document that uses requirement boilerplates for requirement sentence statement. The proposed method uses Natural Language Processing (NLP) approach on the SRS document. Sequence Part-of-Speech (POS) tagging technique is used for automatic requirement sentence identification and extraction. The features are acquired afterward from extracted requirement sentences automatically using the word dependency parsing technique. Besides, mostly the previous researches about feature extraction were using non-public available SRS document that remains classified or not accessible, so this work uses selected SRS from publicly available SRS dataset to add reproducible research value. This research proves that requirement sentence extraction directly from the SRS document is viable with precision value from 64% to 100% and recall value from 64% to 89%. While features extraction from extracted requirement sentences has success rate from 65% to 88%.
APA, Harvard, Vancouver, ISO, and other styles
6

Asif, Muhammad, Ishfaq Ali, Muhamad Sheraz Arshed Malik, Muhammad Hasanain Chaudary, Shahzadi Tayyaba, and Muhammad Tariq Mahmood. "Annotation of Software Requirements Specification (SRS), Extractions of Nonfunctional Requirements, and Measurement of Their Tradeoff." IEEE Access 7 (2019): 36164–76. http://dx.doi.org/10.1109/access.2019.2903133.

Full text
APA, Harvard, Vancouver, ISO, and other styles
7

Sharma, Ashish, Manu Vardhan, and Dharmender Singh Kushwaha. "A Versatile Approach for the Estimation of Software Development Effort Based on SRS Document." International Journal of Software Engineering and Knowledge Engineering 24, no. 01 (February 2014): 1–42. http://dx.doi.org/10.1142/s0218194014500016.

Full text
Abstract:
Requirement engineering is a disciplined application of proven principles, methods, tools and notations to describe the behavior of a system. Generally a project suffers because of improper determination and documentation of software requirements. The intricacies in software development processes are often not understood by the client. Hence, requirements submitted by client need a careful examination. In order to produce proper artifact, it is necessary that the software requirements should be documented into the software requirement specification (SRS) on the basis of the recommendations of IEEE 830:1998 document. To address these issues, a measure for early estimation of software complexity based on SRS of the yet to be developed software is proposed. Further, this complexity measure serves as a basis for computing and deriving early estimation of software development effort too. The results obtained from the proposed measure are able to establish that the measure is accurate and precise as compared to various other existing measures that are based on the algorithm/parameters, software code, function point analysis and use case points. All this is accomplished using SRS document at an early phase of software development process. The proposed measure is robust, comprehensive, early alarming and compares well with other development effort estimation measures proposed in the past.
APA, Harvard, Vancouver, ISO, and other styles
8

Mohanan, Murali, and Imran Sarwar Bajwa. "Requirements to Class Model via SBVR." International Journal of Open Source Software and Processes 10, no. 2 (April 2019): 70–87. http://dx.doi.org/10.4018/ijossp.2019040104.

Full text
Abstract:
A user's software requirements are represented in natural language or a speech such as English. Translating these requirements into the object-oriented models is a tough process for designers. This article proposes a neoteric approach to generate Unified Modeling Language (UML) class models instantly from software requirement specifications (SRS). Here the authors make use of the Open Natural language processing tool (OpenNLP) for lexical analysis and to generate the necessary parts of speech (POS) tags from these requirement specifications. Then, the Semantics of Business Vocabulary and Rules (SBVR) standard is used to extract the object-oriented elements from the natural language (NL) processed SRS. From this, the authors generate UML class models. The prototype tool can generate accurate models in less time. This automated system for designing object-oriented models from SRS reduces the cost and budget for both the designers and the users.
APA, Harvard, Vancouver, ISO, and other styles
9

Ashfaq, Fariha, Imran Sarwar Bajwa, Rafaqut Kazmi, Akmal Khan, and Muhammad Ilyas. "An Intelligent Analytics Approach to Minimize Complexity in Ambiguous Software Requirements." Scientific Programming 2021 (March 22, 2021): 1–20. http://dx.doi.org/10.1155/2021/6616564.

Full text
Abstract:
An inconsistent and ambiguous Software Requirement Specification (SRS) document results in an erroneous/failed software project. Hence, it is a serious challenge to handle and process complex and ambiguous requirements. Most of the literature work focuses on detection and resolution of ambiguity in software requirements. Also, there is no standardized way to write unambiguous and consistent requirements. The goal of this research was to generate an ambiguity-less SRS document. This paper presents a new approach to write ambiguity-less requirements. Furthermore, we design a framework for Natural Language (NL) to Controlled Natural Language (CNL) (such as Semantic Business Vocabulary and Rules (SBVR)) transition and develop a prototype. The prototype also generates Resource Description Framework (RDF) representation. The SBVR has a shared meaning concept that minimizes ambiguity, and RDF representation is supported by query language such as SPARQL Protocol and RDF Query Language (SPARQL). The proposed approach can help software engineers to translate NL requirements into a format that is understandable by all stakeholders and also is machine processable. The results of our prototype are encouraging, exhibiting the efficient performance of our developed prototype in terms of usability and correctness.
APA, Harvard, Vancouver, ISO, and other styles
10

Dinata, Surya, and Martinus Raditia Sigit Surendra. "Penyusunan Kebutuhan Perangkat E-Banking dengan Pendekatan UI Analysis." Jurnal ULTIMA InfoSys 5, no. 2 (December 1, 2014): 75–82. http://dx.doi.org/10.31937/si.v5i2.268.

Full text
Abstract:
This paper propose a method to collect software requirement (Software Requirement Specification – SRS) using user interface analysis on several running and stable system. In this paper we analyzed user interfaces of five internet banking system in Indonesia. The result are list of internet banking features. Then the features are categorized into three category, which are most important, important, and addiontal. Index Terms: Software Requirement Specification (SRS), Use case (UC), Internet banking, Reverse Engineering
APA, Harvard, Vancouver, ISO, and other styles
More sources

Dissertations / Theses on the topic "Software requirements specification (SRS)"

1

Sulehri, Latif. "Comparative Selection of Requirements Validation Techniques Based on Industrial Survey." Thesis, Blekinge Tekniska Högskola, Sektionen för datavetenskap och kommunikation, 2010. http://urn.kb.se/resolve?urn=urn:nbn:se:bth-1178.

Full text
Abstract:
In software engineering the requirements validation has very core importance. The requirements validation very helpful to judge that software requirements specification (SRS) is complete and free of bugs. The requirements validation is a assurance that the software requirements document is free of unwanted requirements and completely consistent. In order to remove inconsistency, detect defects and make the software requirements document fully functional the requirements validation is key factor. All possible requirements validation techniques available in academia such requirements reviews , requirements prototyping, requirements testing and viewpoint-oriented requirements validation are explained properly in this thesis report. In a very readable and understandable way the thesis presents all pros and cons of these requirements validation techniques practiced in different software companies in Sweden and available in academia. This report explains all possible advantages and issues related with these RVTs. In order to judge the best performance of these RVTs and to make their comparison I used a proper channel. I have designed a very effective survey questionnaire with the help of my colleges and literature review. To make creative comparison I conduct interviews and send survey questionnaire to different people working in requirements engineering departments in different software industries in Sweden. Finally the satisfaction levels of different software industries with these requirements validation techniques presents in this thesis report. These variables such as defect detection, time and cost are used to measure the satisfaction levels.
I Software Engineering kraven validering har en mycket central betydelse. Den kravvalidering very helpful att bedöma att Kravspecifikation (SRS) är klar och felfria. Kraven validering är en garanti för att programvaran kravdokument är fri från oönskade krav och helt konsekvent. För att undanröja inkonsekvens, upptäcka brister och göra programvaran kravdokument fullt funktionella kraven validering är viktig faktor. Alla möjliga kravvalidering tekniker inom den akademiska sådana krav recensioner, krav prototyper, provning och synpunkt-orienterade kravvalidering förklaras ordentligt i denna avhandling rapport. I ett mycket lättläst och begripligt sätt avhandling presenterar alla fördelar och nackdelar med dessa krav validera metoder praktiseras i olika mjukvaruföretag i Sverige och finns i den akademiska världen. Denna rapport förklarar alla möjliga fördelar och frågor kring dessa RVTs. För att bedöma de bästa resultaten i dessa RVTs och göra en jämförelse av dem använde jag en riktig kanal. Jag har skapat en mycket effektiv frågeformulär med hjälp av min högskolor och litteraturgenomgång. Skapa kreativa jämförelse jag intervjua och skicka frågeformuläret till olika personer som arbetar inom tekniska kraven för dessa avdelningar i olika programvaruföretag i Sverige. Slutligen tillfredsställande nivåer av olika programvaruföretag med dessa krav validering teknik presenteras i denna avhandling rapport. Dessa variabler såsom Upptäcka, tid och kostnader används för att mäta tillfredsställande nivåer.
Author: Latif Hussain Sulehri E-mail: latifsulehry@hotmail.com Phone: +46 704 917 140
APA, Harvard, Vancouver, ISO, and other styles
2

Chidambaram, Jeyashree. "Software reuse using formal specification of requirements." Thesis, National Library of Canada = Bibliothèque nationale du Canada, 1997. http://www.collectionscanada.ca/obj/s4/f2/dsk3/ftp04/mq23250.pdf.

Full text
APA, Harvard, Vancouver, ISO, and other styles
3

Schneider, Gary David. "A requirements specification software cost estimation tool." Thesis, Kansas State University, 1986. http://hdl.handle.net/2097/9952.

Full text
APA, Harvard, Vancouver, ISO, and other styles
4

Levin, Lukas, and Christoffer Stjernlöf. "Automated Testing Toolkit Service : Software Requirements Specification." Thesis, KTH, Skolan för informations- och kommunikationsteknik (ICT), 2017. http://urn.kb.se/resolve?urn=urn:nbn:se:kth:diva-227859.

Full text
Abstract:
Frequent automated testing of software services is vital to speed up the development cycle and ensure upgrades do not break existing features. With a centralised testing service, it is also possible to catch errors at customer sites before they become severe enough that the customers (or in the end – regular people) start suffering from them. It also gives the customers an insight into how well their services are working at a predictable cost. When developing a larger software system such as an automated testing service toolkit, a requirements specification can drastically cut development costs at the expense of a larger up-front investment. We discover some of the immediately important requirements for the first version of such an automated testing toolkit.
Upprepade automatiserade tester av mjukvarutjänster är mycket viktiga för att öka utvecklingshastigheten och försäkra att uppgraderingar inte påverkar existerande, äldre delar av systemet. Med en centraliserad testningstjänst är det också möjligt att upptäcka fel i kundens miljö innan de blir allvarliga nog att kunden märker av dem. Det ger även kunden en möjlighet att se hur väl deras tjänster fungerar utan att behöva betala oförutsedda driftrelaterade kostnader. När större mjukvarusystem, som en centraliserad tjänst för automatiserade tester, kan en kravspecifikation drastiskt minska utvecklingskostnaden mot en större initial investering. Vi har undersökt vilka några av de omedelbart viktiga kraven är för en första version av denna typ av tjänst.
APA, Harvard, Vancouver, ISO, and other styles
5

Thongglin, Kanjana. "Controlled language for Thai software requirements specification." Thesis, Besançon, 2014. http://www.theses.fr/2014BESA1003.

Full text
Abstract:
Cette thèse porte sur l’utilisation d’une langue contrôlée pour les spécifications des besoins du logiciel en thaï. L’étudedécrit les ambiguïtés syntaxiques et sémantiques ainsi que les problèmes rencontrés dans les spécifications des besoins dulogiciel en thaï. Ce travail explique également la nature de la langue thaïe. Le modèle de la langue contrôlée pour lesspécifications des besoins du logiciel en thaï, proposé dans cette étude, comprend trois composantes: l’analyse lexicale,l’analyse syntaxique et l’analyse sémantique. Pour l’analyse syntaxique, une syntaxe contrôlée est conçue en utilisant laforme du Backus-Naur (BNF). Quant à l’analyse lexicale, nous créons une ressource lexicale sous forme de langage XMLpour stocker tous les mots classés selon leur domaine. Les mots reçus de la ressource XML sont corrects d’un point de vueconceptuel mais ne sont pas pertinents d’un point de vue sémantique. Pour résoudre ce problème, nous faisons alors usage dematrices booléennes pour aligner les phrases sémantiquement. Ainsi les phrases produites par le modèle serontsyntaxiquement et sémantiquement correctes.Après avoir créé le modèle, nous avons construit un logiciel pour tester son efficacité. Il est ainsi évalué par quatreméthodes d’évaluation : 1. le test de fonctionnement syntaxique pour vérifier la syntaxe de la phrase; 2. le test defonctionnement sémantique pour tester la sémantique de la phrase; 3. le test d’acceptation en terme de satisfaction desutilisateurs avec le logiciel; et 4. le test d’acceptation en terme d’acception des données de sortie.Des résultats positifs montrent que : 1. les phrases produites par le modèle proposé sont syntaxiquement correctes; 2. lesphrases produites par le modèle proposé sont sémantiquement correctes; 3. les utilisateurs sont satisfaits et acceptent lelogiciel; et 4. les utilisateurs acceptent et comprennent les phrases produites par ce modèle
This thesis focuses on using controlled language for Thai software requirements specifications. The studydescribes the ambiguities and problems encountered in Thai software requirements specifications; both syntacticambiguity and semantic ambiguity. The study also describes the nature of the Thai language. The model of controlledlanguage for Thai software requirements specifications is composed of three main components: lexical analysis,syntactic analysis, and semantic analysis. For syntactic analysis, a controlled syntax is created using Backus-NaurForm (BNF). In the lexical analysis stage, an XML format lexical resource is built to store words according to theirdomain. The words received from the XML resource are conceptually correct but may be semantically irrelevant. Tosolve this issue, the model applies Boolean Matrices to align sentences semantically. As a result, the sentencesproduced from the model are guaranteed to be syntactically and semantically correct.After having created this model, a program for testing the efficiency of the model is developed. The model isevaluated using four testing methods as follows: 1. functional testing for the correctness of the sentence’s syntax, 2.functional testing for the semantic correctness of the sentences produced by the model, 3. acceptance testing in termsof user satisfaction with the program, and 4. acceptance testing in terms of the validity of the outputs.The positive results signify that: 1. the sentences produced by the proposed model are syntactically correct, 2. thesentences produced by the proposed model are semantically correct, 3. the users are satisfied and accept the softwarecreated, and 4. the users approve and understand the sentences produced from this model
APA, Harvard, Vancouver, ISO, and other styles
6

Au, Oliver T. S. "Requirements specification using concrete scenarios." Thesis, Loughborough University, 2009. https://dspace.lboro.ac.uk/2134/6642.

Full text
Abstract:
The precision of formal specifications allows us to prove program correctness. Even if formal methods are not used throughout the software project, formalisation improves our understanding of the problem. Formal specifications are amenable to automated analysis and consistency checking. However using them is challenging. Customers do not understand formal notations. Specifiers have difficulty tackling large problems. Once systems are built, formal specifications quickly become outdated during software maintenance. A method of developing formal specifications using concrete scenarios is proposed to tackle the disadvantages just mentioned. A concrete scenario describes system behaviour with successive steps. The pre- and post-states of scenario steps are expressed with actual data rather than variables. Concrete scenarios are expressed in a natural language or formal notation. They increase customer involvement in the creation of formal specifications. Scenarios may be ranked by priorities allowing specifiers to focus on a small part of the system. Formal specifications are constructed incrementally. New requirements are also captured in concrete scenarios which guide the modification of formal specifications. On one hand, concrete scenarios assist the creation and maintenance of formal specifications. On the other hand, they facilitate program correctness proofs without using conventional formal specifications. This is achieved by adding implementation details to customer scenarios. The resulting developer scenarios, encapsulating decisions of data structures and algorithms, are generalised to operation schemas. With the implementation details, the schemas written in formal notations are programs rather than specifications.
APA, Harvard, Vancouver, ISO, and other styles
7

Alderman, Robert Bruce. "Software requirements specification for an ammunition management system." Thesis, Monterey, California: U.S. Naval Postgraduate School, 1986. http://hdl.handle.net/10945/22109.

Full text
Abstract:
Approved for public release; distribution is unlimited.
This thesis concerns the software requirements necessary to automate the present manual effort associated with ammunition inventory management and reporting at the afloat end-user level. Functional characteristics for the application software are developed, program and data structures are proposed and possible sources of data are identified. The end-product of this research is the software requirements specification. This document supports further design development of the application software and is independent of programming language and system hardware configuration. Ammunition management, Ammunition inventory management, Automated ammunition management, automated ammunition inventory management. (eg)
APA, Harvard, Vancouver, ISO, and other styles
8

Knapp, James Robert. "Specification for Visual Requirements of Work-Centered Software Systems." Wright State University / OhioLINK, 2006. http://rave.ohiolink.edu/etdc/view?acc_num=wright1165518140.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

MEDEIROS, Juliana Dantas Ribeiro Viana de. "An approach to support the requirements specification in agile software development." Universidade Federal de Pernambuco, 2017. https://repositorio.ufpe.br/handle/123456789/25327.

Full text
Abstract:
SCHUENEMANN, Carla Taciana Lima Lourenco Silva, também é conhecida em citações bibliográficas por: SILVA, Carla
Submitted by Fernanda Rodrigues de Lima (fernanda.rlima@ufpe.br) on 2018-07-31T22:18:30Z No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) TESE Juliana Dantas Ribeiro Viana de Medeiros.pdf: 2161644 bytes, checksum: e9d1db641ca49230902d1d8963b8bb68 (MD5)
Approved for entry into archive by Alice Araujo (alice.caraujo@ufpe.br) on 2018-08-01T22:34:12Z (GMT) No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) TESE Juliana Dantas Ribeiro Viana de Medeiros.pdf: 2161644 bytes, checksum: e9d1db641ca49230902d1d8963b8bb68 (MD5)
Made available in DSpace on 2018-08-01T22:34:12Z (GMT). No. of bitstreams: 2 license_rdf: 811 bytes, checksum: e39d27027a6cc9cb039ad269a5db8e34 (MD5) TESE Juliana Dantas Ribeiro Viana de Medeiros.pdf: 2161644 bytes, checksum: e9d1db641ca49230902d1d8963b8bb68 (MD5) Previous issue date: 2017-03-13
Although Agile Software Development (ASD) has grown in recent years, research evidence points out several limitations concerning its requirements engineering activities. It was observed that an inadequate specification acts as a catalyst to others problems, such as low productivity of the team and difficulty in maintaining software. Improving the quality of Software Requirements Specifications (SRS) may help gaining a competitive advantage in the software industry. The goal of this study is to investigate the phenomenon of the requirements specification activity in ASD, discuss relevant findings of this phenomenon to industrial practice, and propose practices to write a SRS targeted to development team. First, a Systematic Mapping (SM) study was conducted to characterize the landscape of requirements engineering in ASD. The thematic synthesis method was used to code and synthesize the data collected from the primary studies selected. After that, some of the challenges pointed out in the SM were investigated in more depth in six industrial case studies. Data collected from documents, observations, and interviews with software engineers were triangulated, analyzed, and synthesized using techniques of grounded theory and metaethnography. The analysis and cross-synthesis of the case studies resulted in a model that defines the simplicity and objectivity as essential quality factors of SRS in ASD. The main factors that affect the quality are related to the customer-driven nature that tends to leave the prolix SRS, hindering the understanding of the software engineers, as they are, at the same time, insufficient to support coding, testing and maintenance tasks. One approach was proposed to provide a SRS closer to the development needs, addressing some of the quality factors of the model. Empirical studies that evaluated the approach show that the design practices used in the proposed approach have the potential to reduce the gap between the problem and the solution domains, producing an objective SRS that is team-driven and closer to that will be implemented.
Embora o Desenvolvimento Ágil de Software (DAS) tenha crescido nos últimos anos, estudos empíricos apontam vários problemas relacionados com as atividades de engenharia de requisitos. Observou-se que a especificação inadequada age como um catalizador para outros problemas, como por exemplo, baixa produtividade da equipe e dificuldades na manutenção do software. Melhorar a qualidade da Especificação de Requisitos de Software (ERS) pode ajudar a ganhar uma vantagem competitiva na indústria de software. O objetivo deste estudo é investigar o fenômeno da especificação de requisitos no DAS, discutir relevantes implicações desse fenômeno para a indústria, e propor práticas para escrever ERS voltadas para a equipe de desenvolvimento. Primeiro, um Mapeamento Sistemático (MS) foi realizado para caracterizar o panorama da engenharia de requisitos no DAS. O método de síntese temática foi utilizado para codificar e sintetizar os dados coletados a partir dos estudos primários selecionados. Em seguida, alguns dos desafios apontados no MS foram investigados com mais profundidade em seis estudos de caso industriais. Os dados coletados a partir de documentos, observações e entrevistas com engenheiros de software foram triangulados, analisados e sintetizados usando técnicas de teoria fundamentada e meta-etnografia. A análise e síntese cruzada dos estudos de caso resultaram em um modelo de qualidade que define a simplicidade e objetividade como fatores essenciais na ERS no DAS. Os principais fatores que afetam a qualidade estão relacionados à natureza orientada para o cliente que tende a deixar a ERS prolixa, dificultando a compreensão do engenheiro de software, ao mesmo tempo que é insuficiente para a codificação, testes e manutenção. Uma abordagem foi proposta para fornecer uma especificação de requisitos mais próxima das necessidades de desenvolvimento, atendendo alguns dos fatores de qualidade do modelo. Os estudos empíricos que avaliaram a abordagem demonstram que as práticas de design utilizadas pela abordagem tem o potencial de reduzir a distância entre o domínio do problema e o da solução, produzindo uma ERS objetiva, voltada para o desenvolvedor, e próxima do que vai ser implementado.
APA, Harvard, Vancouver, ISO, and other styles
10

Silva, Araujo Joao Baptista da. "Metamorphosis : an integrated object oriented requirements analysis and specification method." Thesis, Lancaster University, 1996. http://ethos.bl.uk/OrderDetails.do?uin=uk.bl.ethos.337663.

Full text
APA, Harvard, Vancouver, ISO, and other styles
More sources

Books on the topic "Software requirements specification (SRS)"

1

CSR Workshop (1984 University of East Anglia). Software: Requirements, specification and testing. Oxford: Blackwell Scientific, 1985.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
2

Davis, Alan M. Software requirements: Analysis and specification. London: Prentice-Hall International, 1990.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
3

Software requirements: Analysis and specification. Englewood Cliffs, N.J: Prentice Hall, 1990.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
4

Requirements modelling and specification for service oriented architecture. Chichester, West Sussex, Eng: Wiley, 2008.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
5

Butler, Ricky W. An introduction to requirements capture using PVS: Specification of a simple autopilot. Hampton, Va: National Aeronautics and Space Administration, Langley Research Center, 1996.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
6

O, Salas A., and Langley Research Center, eds. HSCT4.0 application: Software requirements specification. Hampton, Va: National Aeronautics and Space Administration, Langley Research Center, 2001.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
7

O, Salas A., and Langley Research Center, eds. HSCT4.0 application: Software requirements specification. Hampton, Va: National Aeronautics and Space Administration, Langley Research Center, 2001.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
8

Davis, Alan M. Software Requirements Analysis and Specification. Prentice Hall (Higher Education Division, Pearson Education), 1991.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
9

HSCT4.0 application: Software requirements specification. Hampton, Va: National Aeronautics and Space Administration, Langley Research Center, 2001.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
10

O, Salas A., and Langley Research Center, eds. HSCT4.0 application: Software requirements specification. Hampton, Va: National Aeronautics and Space Administration, Langley Research Center, 2001.

Find full text
APA, Harvard, Vancouver, ISO, and other styles
More sources

Book chapters on the topic "Software requirements specification (SRS)"

1

Ismail, Muhammad. "Ontology Learning from Software Requirements Specification (SRS)." In Lecture Notes in Computer Science, 251–55. Cham: Springer International Publishing, 2017. http://dx.doi.org/10.1007/978-3-319-58694-6_39.

Full text
APA, Harvard, Vancouver, ISO, and other styles
2

Foster, Elvis C. "The Requirements Specification." In Software Engineering, 61–68. Berkeley, CA: Apress, 2014. http://dx.doi.org/10.1007/978-1-4842-0847-2_4.

Full text
APA, Harvard, Vancouver, ISO, and other styles
3

Foster, Elvis C. "The Requirements Specification." In Software Engineering, 89–96. 2nd ed. Boca Raton: Auerbach Publications, 2021. http://dx.doi.org/10.1201/9780367746025-8.

Full text
APA, Harvard, Vancouver, ISO, and other styles
4

Jalote, Pankaj. "Software Requirements Specification." In Springer Compass International, 33–83. New York, NY: Springer New York, 1991. http://dx.doi.org/10.1007/978-1-4757-3857-5_2.

Full text
APA, Harvard, Vancouver, ISO, and other styles
5

Wieringa, Roel J. "Requirements Specification." In Design Science Methodology for Information Systems and Software Engineering, 51–57. Berlin, Heidelberg: Springer Berlin Heidelberg, 2014. http://dx.doi.org/10.1007/978-3-662-43839-8_6.

Full text
APA, Harvard, Vancouver, ISO, and other styles
6

Berry, Daniel M., and Erik Kamsties. "Ambiguity in Requirements Specification." In Perspectives on Software Requirements, 7–44. Boston, MA: Springer US, 2004. http://dx.doi.org/10.1007/978-1-4615-0465-8_2.

Full text
APA, Harvard, Vancouver, ISO, and other styles
7

Jalote, Pankaj. "Software Requirements Analysis and Specification." In An Integrated Approach to Software Engineering, 73–158. New York, NY: Springer New York, 1997. http://dx.doi.org/10.1007/978-1-4684-9312-2_3.

Full text
APA, Harvard, Vancouver, ISO, and other styles
8

Jalote, Pankaj. "Software Requirements Analysis and Specification." In A Concise Introduction to Software Engineering, 1–31. London: Springer London, 2008. http://dx.doi.org/10.1007/978-1-84800-302-6_3.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

Foster, Elvis C. "Requirements Specification for a Generic Inventory Management System." In Software Engineering, 455–73. Berkeley, CA: Apress, 2014. http://dx.doi.org/10.1007/978-1-4842-0847-2_29.

Full text
APA, Harvard, Vancouver, ISO, and other styles
10

Cooling, J. E. "First steps — requirements analysis and specification." In Software Design for Real-time Systems, 51–88. Boston, MA: Springer US, 1991. http://dx.doi.org/10.1007/978-1-4899-2957-0_3.

Full text
APA, Harvard, Vancouver, ISO, and other styles

Conference papers on the topic "Software requirements specification (SRS)"

1

Aman, Hannani, and Rosziati Ibrahim. "XML_DocTracker: Generating Software Requirements Specification (SRS) from XML Schema." In 2016 International Conference on Information Science and Security (ICISS). IEEE, 2016. http://dx.doi.org/10.1109/icissec.2016.7885872.

Full text
APA, Harvard, Vancouver, ISO, and other styles
2

Georgiades, Marinos G., and Andreas S. Andreou. "Automatic generation of a Software Requirements Specification (SRS) document." In 2010 10th International Conference on Intelligent Systems Design and Applications (ISDA). IEEE, 2010. http://dx.doi.org/10.1109/isda.2010.5687039.

Full text
APA, Harvard, Vancouver, ISO, and other styles
3

"A SOFTWARE TOOL FOR REQUIREMENTS SPECIFICATION - On using the STORM Environment to Create SRS Documents." In 2nd International Conference on Software and Data Technologies. SciTePress - Science and and Technology Publications, 2007. http://dx.doi.org/10.5220/0001345303190326.

Full text
APA, Harvard, Vancouver, ISO, and other styles
4

Nur Fathin Najwa Binti Mustaffa, Siti, Jamaludin Bin Sallim, and Rozlina Binti Mohamed. "Semi – Automated Software Requirement Specification (SRS) Document Generator: The Guideline to Novice System Analyst." In 2021 International Conference on Software Engineering & Computer Systems and 4th International Conference on Computational Science and Information Management (ICSECS-ICOCSIM). IEEE, 2021. http://dx.doi.org/10.1109/icsecs52883.2021.00022.

Full text
APA, Harvard, Vancouver, ISO, and other styles
5

Rocha, Fabiana Ferreira, Elisa Cerri E Cerri, Ricardo Melo Bastos, and Marcelo Hideki Yamaguti. "Uma Proposta de Modelo para Avaliação da Qualidade da Tradução de Requisitos para Casos de Uso." In III Simpósio Brasileiro de Sistemas de Informação. Sociedade Brasileira de Computação, 2006. http://dx.doi.org/10.5753/sbsi.2006.14721.

Full text
Abstract:
O documento de especificação de requisitos de software (Software Requirements Specification - SRS) é decisivo para o desenvolvimento de um bom produto final. As métricas desempenham um papel essencial na detecção de defeitos dos requisitos, fornecendo meios para a visualização de discrepâncias e identificação de pontos fora de uma situação projetada. Assim, o objetivo deste trabalho é propor um modelo com a finalidade de avaliar a qualidade da tradução de requisitos para casos de uso.
APA, Harvard, Vancouver, ISO, and other styles
6

Vilela, Jéssyka. "An Empirical Evaluation about Using Models to Improve Preliminary Safety Analysis." In Workshop em Modelagem e Simulação de Sistemas Intensivos em Software. Sociedade Brasileira de Computação - SBC, 2020. http://dx.doi.org/10.5753/mssis.2020.12496.

Full text
Abstract:
Context: Safety analysis is an activity of fundamental importance in the development of safety-critical systems (SCS) to ensure that hazardous situations are properly found and mitigated. Such analysis is usually performed after a system requirements specification is available. Therefore, it is then worthwhile to investigate specification techniques to detect their strengths and weaknesses with respect to finding and documenting hazards early in the development process. Objective: In this paper, we investigate similarities and differences in the results of a preliminary safety analysis from requirements specified using Textual Use Cases (TUC) and Business Process Modeling Notation (BPMN). Method: We adopted a controlled experiment as research method using computer engineering students as subjects. Results: The subjects of BPMN group found more accidents, hazards as well as more causes of hazards. Moreover, they have a higher preference for the template used for safety analysis documentation. Conclusions: The use of BPMN to represent the interactions among actors in a system probably lead to the discovery of more accidents and hazards, but more experiments are necessary to test this hypothesis since the results are not statistically significant.
APA, Harvard, Vancouver, ISO, and other styles
7

Awan, Misbah Mehboob, Farooque Azam, Muhammad Waseem Anwar, and Yawar Rasheed. "Formal Requirements Specification." In ICSIE 2020: 2020 9th International Conference on Software and Information Engineering. New York, NY, USA: ACM, 2020. http://dx.doi.org/10.1145/3436829.3436845.

Full text
APA, Harvard, Vancouver, ISO, and other styles
8

Thongglin, Kanjana, Sylviane Cardey, and Peter Greenfield. "Thai software requirements specification pattern." In 2013 IEEE 12th International Conference on Intelligent Software Methodologies, Tools and Techniques (SoMeT). IEEE, 2013. http://dx.doi.org/10.1109/somet.2013.6645650.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

Šenkýř, David, and Petr Kroha. "Patterns in Textual Requirements Specification." In 13th International Conference on Software Technologies. SCITEPRESS - Science and Technology Publications, 2018. http://dx.doi.org/10.5220/0006827301970204.

Full text
APA, Harvard, Vancouver, ISO, and other styles
10

Šenkýř, David, and Petr Kroha. "Patterns in Textual Requirements Specification." In 13th International Conference on Software Technologies. SCITEPRESS - Science and Technology Publications, 2018. http://dx.doi.org/10.5220/0006827302310238.

Full text
APA, Harvard, Vancouver, ISO, and other styles

Reports on the topic "Software requirements specification (SRS)"

1

Glasscock, J. A., and M. J. Flanagan. Surveillance Analysis Computer System (SACS) software requirements specification (SRS). Office of Scientific and Technical Information (OSTI), September 1995. http://dx.doi.org/10.2172/436527.

Full text
APA, Harvard, Vancouver, ISO, and other styles
2

Glasscock, J. A. Surveillance Analysis Computer System (SACS): Software requirements specification (SRS). Revision 2. Office of Scientific and Technical Information (OSTI), March 1995. http://dx.doi.org/10.2172/33085.

Full text
APA, Harvard, Vancouver, ISO, and other styles
3

Clark, R. E. Solid Waste Information Tracking System (SWITS), Backlog Waste Modifications, Software Requirements Specification (SRS). Office of Scientific and Technical Information (OSTI), May 1995. http://dx.doi.org/10.2172/67204.

Full text
APA, Harvard, Vancouver, ISO, and other styles
4

Gneiting, B. C. RMACS software requirements specification. Office of Scientific and Technical Information (OSTI), October 1996. http://dx.doi.org/10.2172/331653.

Full text
APA, Harvard, Vancouver, ISO, and other styles
5

Frank, D. D. Requirements management system browser software requirements specification. Office of Scientific and Technical Information (OSTI), October 1996. http://dx.doi.org/10.2172/331654.

Full text
APA, Harvard, Vancouver, ISO, and other styles
6

Zhang, Hongbin, David Andrs, Richard Martineau, Nancy Kyle, Hollis Henry, and Stella McKirdy. Software Requirements Specification for RELAP-7. Office of Scientific and Technical Information (OSTI), April 2017. http://dx.doi.org/10.2172/1374509.

Full text
APA, Harvard, Vancouver, ISO, and other styles
7

Grush, W. H., and E. S. Marwil. In Situ Vitrification software requirements specification. Office of Scientific and Technical Information (OSTI), September 1990. http://dx.doi.org/10.2172/6496101.

Full text
APA, Harvard, Vancouver, ISO, and other styles
8

Vargo, G. F., and M. Gimera. Software requirements specification of low moisture monitor. Office of Scientific and Technical Information (OSTI), November 1995. http://dx.doi.org/10.2172/442532.

Full text
APA, Harvard, Vancouver, ISO, and other styles
9

Gimera, M. Software requirements specification for surface moisture monitor. Office of Scientific and Technical Information (OSTI), November 1995. http://dx.doi.org/10.2172/443105.

Full text
APA, Harvard, Vancouver, ISO, and other styles
10

Sisk, Daniel R., Michael R. Brambley, Teresa A. Carlon, and Robert S. Briggs. Automated Diagnostics Software Requirements Specification, Version 1.1. Office of Scientific and Technical Information (OSTI), September 2003. http://dx.doi.org/10.2172/15010305.

Full text
APA, Harvard, Vancouver, ISO, and other styles
You might also be interested in the extended bibliographies on the topic 'Software requirements specification (SRS)' for particular source types:
Journal articles Dissertations / Theses Books
We offer discounts on all premium plans for authors whose works are included in thematic literature selections. Contact us to get a unique promo code!

To the bibliography