Relevant bibliographies by topics / Software requirements specification

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'

Author: Grafiati
Published: 4 June 2021
Last updated: 5 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.'

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"

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

Souza, Rafael Gorski M., and Paulo Cézar Stadzisz. "PROBLEM-BASED SOFTWARE REQUIREMENTS SPECIFICATION." Revista Eletrônica de Sistemas de Informação 15, no. 2 (August 31, 2016): 2. http://dx.doi.org/10.21529/resi.2016.1502002.

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

Firesmith, Donald. "Modern Requirements Specification." Journal of Object Technology 2, no. 2 (2003): 53. http://dx.doi.org/10.5381/jot.2003.2.2.c6.

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

Chen, Shu, and Ming Kai Chen. "A Semantical Approach for Automatically Transforming Software Requirement Specification into Formal Presentation." Advanced Materials Research 225-226 (April 2011): 776–79. http://dx.doi.org/10.4028/www.scientific.net/amr.225-226.776.

Full text
Abstract:
Software engineering is a critical step in obtaining high quality production. However, requirement specifications that written in natural language is inevitably has ambiguity. Modern driven architecture makes use of requirement model for the complement of requirement specification to eliminate such ambiguity. However, currently, the transformation from requirement specification into formal model only limited in syntax level, thus lack of correctness and precision. This paper proposed an approach in semantical level to process textual specifications of the requirements of unlimited natural language and their automatic mapping to the formal presentation.
APA, Harvard, Vancouver, ISO, and other styles
5

Györkös, J. "Measurements in software requirements specification process." Microprocessing and Microprogramming 40, no. 10-12 (December 1994): 893–96. http://dx.doi.org/10.1016/0165-6074(94)90063-9.

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

Alshazly, Amira A., Ahmed M. Elfatatry, and Mohamed S. Abougabal. "Detecting defects in software requirements specification." Alexandria Engineering Journal 53, no. 3 (September 2014): 513–27. http://dx.doi.org/10.1016/j.aej.2014.06.001.

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

Abualhaija, Sallam, Chetan Arora, Mehrdad Sabetzadeh, Lionel C. Briand, and Michael Traynor. "Automated demarcation of requirements in textual specifications: a machine learning-based approach." Empirical Software Engineering 25, no. 6 (September 13, 2020): 5454–97. http://dx.doi.org/10.1007/s10664-020-09864-1.

Full text
Abstract:
Abstract A simple but important task during the analysis of a textual requirements specification is to determine which statements in the specification represent requirements. In principle, by following suitable writing and markup conventions, one can provide an immediate and unequivocal demarcation of requirements at the time a specification is being developed. However, neither the presence nor a fully accurate enforcement of such conventions is guaranteed. The result is that, in many practical situations, analysts end up resorting to after-the-fact reviews for sifting requirements from other material in a requirements specification. This is both tedious and time-consuming. We propose an automated approach for demarcating requirements in free-form requirements specifications. The approach, which is based on machine learning, can be applied to a wide variety of specifications in different domains and with different writing styles. We train and evaluate our approach over an independently labeled dataset comprised of 33 industrial requirements specifications. Over this dataset, our approach yields an average precision of 81.2% and an average recall of 95.7%. Compared to simple baselines that demarcate requirements based on the presence of modal verbs and identifiers, our approach leads to an average gain of 16.4% in precision and 25.5% in recall. We collect and analyze expert feedback on the demarcations produced by our approach for industrial requirements specifications. The results indicate that experts find our approach useful and efficient in practice. We developed a prototype tool, named DemaRQ, in support of our approach. To facilitate replication, we make available to the research community this prototype tool alongside the non-proprietary portion of our training data.
APA, Harvard, Vancouver, ISO, and other styles
8

Mu, Kedian, Weiru Liu, and Zhi Jin. "A Blame-Based Approach to Generating Proposals for Handling Inconsistency in Software Requirements." International Journal of Knowledge and Systems Science 3, no. 1 (January 2012): 1–17. http://dx.doi.org/10.4018/jkss.2012010101.

Full text
Abstract:
Inconsistency has been considered one of the main classes of defects in software requirements specification. Various logic-based techniques have been proposed to manage inconsistencies in requirements engineering. However, identifying an appropriate proposal for resolving inconsistencies in software requirements is still a challenging problem. This paper proposes a logic-based approach to generating appropriate proposals for handling inconsistency in software requirements. Informally speaking, given an inconsistent requirements specification, the authors identify which requirements should be given priority to be changed for resolving the inconsistency in that specification, by balancing the blame of each requirement for the inconsistency against its value for that requirements specification. The authors follow the viewpoint that minimal inconsistent subsets of a set of formulas are the purest forms of inconsistencies in that set. According to this viewpoint, a potential proposal for resolving inconsistencies can be described by a possible combination of some requirements to be changed that can eliminate minimal inconsistent subsets. Then a method is proposed of evaluating the degree of disputability of each requirement involved in the inconsistency in a requirements specification. Finally, an algorithm is provided of generating appropriate proposals for resolving the inconsistency in a given requirements specification based on the degree of disputability of requirements.
APA, Harvard, Vancouver, ISO, and other styles
9

KÖRNER, SVEN J., and TORBEN BRUMM. "NATURAL LANGUAGE SPECIFICATION IMPROVEMENT WITH ONTOLOGIES." International Journal of Semantic Computing 03, no. 04 (December 2009): 445–70. http://dx.doi.org/10.1142/s1793351x09000872.

Full text
Abstract:
Requirements engineering can solve and cause many problems in a software development cycle. The difficulties in understanding and eliciting the desired functionality from the customer and then delivering the correct implementation of a software system lead to delays, mistakes, and high costs. Working with requirements means handling incomplete or faulty textual specifications. It is vital for a project to fully understand the purpose and the functionality of a software. The earlier specifications are corrected and improved, the better. We created a tool called RESI to support requirement analysts working with textual specifications. RESI checks for linguistic defects [1, 2] in specifications and offers a dialog-system which makes suggestions to improve the text. It points out to the user which parts of the specification are ambiguous, faulty or inaccurate and therefore need to be changed. For this task, RESI needs additional semantic information which is inherent to natural language specifications. It receives this information by utilizing ontologies.
APA, Harvard, Vancouver, ISO, and other styles
10

Turner, K. J. "Incremental requirements specification withLotos." Requirements Engineering 2, no. 3 (September 1997): 132–51. http://dx.doi.org/10.1007/bf02802772.

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

Dissertations / Theses on the topic "Software requirements specification"

1

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
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

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
7

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
8

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
9

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
10

Chantatub, Wachara. "The integration of software specification, verification, and testing techniques with software requirements and design processes." Thesis, University of Sheffield, 1995. http://etheses.whiterose.ac.uk/1850/.

Full text
Abstract:
Specifying, verifying, and testing software requirements and design are very important tasks in the software development process and must be taken seriously. By investing more up-front effort in these tasks, software projects will gain the benefits of reduced maintenance costs, higher software reliability, and more user-responsive software. However, many individuals involved in these tasks still find that the techniques available for the tasks are either too difficult and far from practical or if not difficult, inadequate for the tasks. This thesis proposes practical and capable techniques for specifying and verifying software requirements and design and for generating test requirements for acceptance and system testing. The proposed software requirements and design specification techniques emerge from integrating three categories of software specification languages, namely an infonnal specification language (e.g. English), semiformal specification languages (Entity-Relationship Diagrams, Data Flow Diagrams, and Data Structure Diagrams), and a formal specification language (Z with an extended subset). The four specification languages mentioned above are used to specify both software requirements and design. Both software requirements and design of a system are defined graphically in Entity-Relationship Diagrams, Data Flow Diagrams, and Data Structure Diagrams, and defined formally in Z specifications. The proposed software requirements and design verification techniques are a combination of informal and formal proofs. The informal proofs are applied to check the consistency of the semiformal specification and to check the consistency, correctness, and completeness of the formal specification against the semiformal specification. The formal proofs are applied to mathematically prove the consistency of the formal specification. Finally, the proposed technique for generating test requirements for acceptance and system testing from the formal requirements specification is presented. Two sets of test requirements are generated: test requirements for testing the critical requirements, and test requirements for testing the operations of the system.
APA, Harvard, Vancouver, ISO, and other styles
More sources

Books on the topic "Software requirements specification"

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

Sodhi, Jag. Software requirements analysis and specifications. New York: McGraw-Hill, 1992.

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

Goitia, I. Project management system specifications and software requirements. Manchester: UMIST, 1994.

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

Software requirements & specifications: A lexicon of practice, principles, and prejudices. New York: ACM Press, 1995.

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

Requirements engineering: From system goals to UML models to software specifications. Hoboken, NJ: John Wiley, 2009.

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"

1

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
2

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
3

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
4

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
5

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
6

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
7

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
8

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
9

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
10

Filho, Francisco C. Simplício. "Modelling Cognitive Behaviour in Specification Understanding." In User-Centred Requirements for Software Engineering Environments, 91–97. Berlin, Heidelberg: Springer Berlin Heidelberg, 1994. http://dx.doi.org/10.1007/978-3-662-03035-6_8.

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

Conference papers on the topic "Software requirements specification"

1

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
2

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
3

Š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
4

Š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
5

Kirner, Tereza G., and Janaina C. Abib. "Inspection of software requirements specification documents." In the 15th annual international conference. New York, New York, USA: ACM Press, 1997. http://dx.doi.org/10.1145/263367.263389.

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

Chikh, Azeddine, and Hessah Alajmi. "Towards a dynamic software requirements specification." In 2014 World Congress on Computer Applications and Information Systems (WCCAIS). IEEE, 2014. http://dx.doi.org/10.1109/wccais.2014.6916656.

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

Babamir, Seyed Morteza, and Faezeh Sadat Babamir. "Behavioral Specification of Real-Time Requirements." In 2008 15th Asia-Pacific Software Engineering Conference. IEEE, 2008. http://dx.doi.org/10.1109/apsec.2008.22.

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

Mello, Rafael Maiani de, Wallace Martinho Pereira, and Guilherme Horta Travassos. "Activity Diagram Inspection on Requirements Specification." In 2010 Brazilian Symposium on Software Engineering (SBES). IEEE, 2010. http://dx.doi.org/10.1109/sbes.2010.29.

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

Thongglin, K., S. Cardey, and P. Greenfield. "Controlled Syntax for Thai Software Requirements Specification." In 2012 IEEE 24th International Conference on Tools with Artificial Intelligence (ICTAI 2012). IEEE, 2012. http://dx.doi.org/10.1109/ictai.2012.136.

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

Eckroth, Joshua, and Guy-Alain Amoussou. "Improving software quality from the requirements specification." In the 2007 Symposium. New York, New York, USA: ACM Press, 2007. http://dx.doi.org/10.1145/1496630.1496651.

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

Reports on the topic "Software requirements specification"

1

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
2

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
3

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
4

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
5

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
6

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
7

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
8

Kiebel, G. R. Light duty utility arm software requirements specification. Office of Scientific and Technical Information (OSTI), December 1995. http://dx.doi.org/10.2172/434914.

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

Hedberg Jr., Thomas, Moneer Helu, and Marcus Newrock. Software requirements specification to distribute manufacturing data. Gaithersburg, MD: National Institute of Standards and Technology, December 2017. http://dx.doi.org/10.6028/nist.ams.300-2.

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

Holmes, V. P., D. L. Harris, C. R. Borgman, and G. S. Davidson. Software requirements specification for the HAWK operating system. Office of Scientific and Technical Information (OSTI), March 1989. http://dx.doi.org/10.2172/6316515.

Full text
APA, Harvard, Vancouver, ISO, and other styles
You might also be interested in the extended bibliographies on the topic 'Software requirements specification' 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