Log in

Relevant bibliographies by topics / Software requirements specification / Journal articles

To see the other types of publications on this topic, follow the link: Software requirements specification.

Journal articles 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 top 50 journal articles for your research 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.

Browse journal articles on a wide variety of disciplines and organise your bibliography correctly.

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

11

Muslah, Eman, and Said Ghoul. "Requirements Variability Specification for Data Intensive Software." International Journal of Software Engineering & Applications 10, no. 2 (March 31, 2019): 23–34. http://dx.doi.org/10.5121/ijsea.2019.10203.

Full text

APA, Harvard, Vancouver, ISO, and other styles

12

Singchai, Ponglikit, and Wanchai Rivepiboon. "FRAMEWORK FOR FAST BUILDING SOFTWARE REQUIREMENTS SPECIFICATION." Jurnal Sistem Informasi 9, no. 1 (November 28, 2013): 1. http://dx.doi.org/10.21609/jsi.v9i1.339.

Full text

Abstract:

Software Requirements is an important process in software project. If the information is inaccurate or delayed, the next steps may have problems. If system analyst has the initial or suggestion documents which use software requirements specification of past software projects with similar knowledge, it can help system analyst to building the software requirements specification involves gathering requirements from users more efficient and faster. Therefore, we propose a framework for fast building the relationships of the software requirements specification of past software projects from the similarity of the requirements in each project using Bayesian network model for retrieving requirements with similar knowledge to the new project.

APA, Harvard, Vancouver, ISO, and other styles

13

Broomfield, E. J., and P. W. H. Chung. "Safety assessment and the software requirements specification." Reliability Engineering & System Safety 55, no. 3 (March 1997): 295–309. http://dx.doi.org/10.1016/s0951-8320(96)00101-9.

Full text

APA, Harvard, Vancouver, ISO, and other styles

14

del Sagrado, José, and Isabel M. del Águila. "Stability prediction of the software requirements specification." Software Quality Journal 26, no. 2 (April 8, 2017): 585–605. http://dx.doi.org/10.1007/s11219-017-9362-x.

Full text

APA, Harvard, Vancouver, ISO, and other styles

15

POO, DANNY C. C. "AN OBJECT-ORIENTED SOFTWARE REQUIREMENTS ANALYSIS METHOD." International Journal of Software Engineering and Knowledge Engineering 02, no. 01 (March 1992): 145–68. http://dx.doi.org/10.1142/s0218194092000087.

Full text

Abstract:

This paper discusses an object-oriented software requirements analysis method. The approach adopted here draws clear distinction between a system's basic structure (i.e. the object model) and its functionalities. The analysis model generated is a description of a problem domain; it consists of a set of primary and secondary objects that characterize the problem domain, and a set of pseudo objects that define the functional requirements of a system. There are two stages of analysis in the proposed method: Object Modelling and Functional Requirements Modelling. These two stages are built upon one another. The aim of the object modelling stage is to derive a model of the problem domain in terms of objects, their classification and inter-relationships with one another. The functional requirements modelling stage builds upon this initial object model to complete the requirement analysis specification. This paper uses a real-life library environment to illustrate how the method can be applied in the specification of an object-oriented software system.

APA, Harvard, Vancouver, ISO, and other styles

16

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

17

Thronesbery, Carroll, Ayman Qaddumi, Michael Merta, Eugene McMahon, and Mike Monahan. "Autonomy Requirements Tester (ART): Assisting Clear Communications among Stakeholders." Proceedings of the Human Factors and Ergonomics Society Annual Meeting 61, no. 1 (September 2017): 2027–31. http://dx.doi.org/10.1177/1541931213601985.

Full text

Abstract:

Autonomy Requirements Tester (ART) is a software tool designed and prototyped in a NASA Phase I Small Business Innovative Research (SBIR) project to address the difficulties of testing autonomy requirements. It supports clear communications among engineers with different by translating requirements terms into software behavioral expectations, which can be used to drive test specifications and the reporting of test results. Also, because it helps translate the requirements into software behavior terms, it addresses some of the difficulties of testing autonomy requirements. Innovations in ART include a clear linking of requirements, expected software behavior, test plans, and test results. They also include the immersion of the Test Runner portion of the ART design within the Core Flight System (cFS) architecture, so that the application under test can be tested as it is intended to fly, even before the remainder of the flight software has been developed. ART also includes a reusable test specification for regression testing and employs a test plan template to ease the specification of multiple, detailed test plans for similarly formatted autonomy requirements.

APA, Harvard, Vancouver, ISO, and other styles

18

LIU, SHAOYING, TETSUO TAMAI, and SHIN NAKAJIMA. "A FRAMEWORK FOR INTEGRATING FORMAL SPECIFICATION, REVIEW, AND TESTING TO ENHANCE SOFTWARE RELIABILITY." International Journal of Software Engineering and Knowledge Engineering 21, no. 02 (March 2011): 259–88. http://dx.doi.org/10.1142/s0218194011005268.

Full text

Abstract:

Software risk comes mainly from its poor reliability, but how to effectively achieve high reliability still remains a challenge. This paper puts forward a framework for systematically integrating formal specification, review, and testing, and shows how it can be applied to effectively eliminate errors in the major phases of software development process to enhance software reliability. In this framework, requirements errors can be removed and missing requirements can be identified by formalizing requirements into formal specifications whose validity can be ensured by rigorous review. The valid specification can then be used as a firm foundation for implementation and for rigorous inspection, testing, and walkthrough of the implemented program. We discuss how formalization, review, and testing work together at different levels of software development to improve software reliability through detecting and removing errors in documentation.

APA, Harvard, Vancouver, ISO, and other styles

19

Daniel, Mworia, Nderu Lawrence, and Kimwele Michael. "Embedding Quality into Software Product Line Variability Artifacts." International Journal of Software Engineering & Applications 12, no. 3 (May 31, 2021): 11–25. http://dx.doi.org/10.5121/ijsea.2021.12302.

Full text

Abstract:

The success of any software product line development project is closely tied to its domain variability management. Whereas a lot of effort has been put into functional variability management by the SPL community, non-functional variability is considered implicit. The result has been dissatisfaction among clients due to resultant poor quality systems. This work presents an integrated requirement specification template for quality and functional requirements at software product line variation points. The implementation of this approach at the analytical description phase increases the visibility of quality requirements obliging developers to implement them. The approach proposes the use of decision tree classification techniques to support the weaving of functional quality attributes at respective variation points. This work, therefore, promotes software product line variability management objectives by proposing new functional quality artifacts during requirements specification phase. The approach is illustrated with an exemplar mobile phone family data storage requirements case study.

APA, Harvard, Vancouver, ISO, and other styles

20

KAZMIERCZAK, EDMUND, PHILIP DART, LEON STERLING, and MICHAEL WINIKOFF. "VERIFYING REQUIREMENTS THROUGH MATHEMATICAL MODELLING AND ANIMATION." International Journal of Software Engineering and Knowledge Engineering 10, no. 02 (April 2000): 251–73. http://dx.doi.org/10.1142/s0218194000000146.

Full text

Abstract:

Achieving confidence in the correctness, completeness and consistency of requirements specifications can be problematic and the consequences of incorrect requirements can be costly. In this paper we argue that specification and animation can provide reasonably high levels of assurance in the requirements without the overheads of using general purpose theorem proving tools. We propose a framework based on mode analysis and the operational semantics of logic programs for animating specifications. The framework allows us to combine prototyping and limited forms of automated deduction to increase our levels of confidence in specifications. Finally, we show how such a framework can be used to increase the level of confidence in the correctness of a simple dependency management system specification written in Z.

APA, Harvard, Vancouver, ISO, and other styles

21

Ahmad, Rais Aziz. "Interface-Driven Software Requirements Analysis." European Scientific Journal, ESJ 12, no. 30 (October 31, 2016): 40. http://dx.doi.org/10.19044/esj.2016.v12n30p40.

Full text

Abstract:

Software requirements are one of the root causes of failure for IT software development projects. Reasons for this may be that the requirements are high-level, many might simply be wishes, or frequently changed, or they might be unclear, missing, for example, goals, objectives, strategies, and so on. Another major reason for projects’ failure may also be the use of improper techniques for software requirements specification. Currently, most IT software development projects utilise textual techniques like use cases, user stories, scenarios, and features for software requirements elicitation, analysis and specification. While IT software development processes can construct software in different programming languages, the primary focus here will be those IT projects using object-oriented programming languages. Object-oriented programming itself has several characteristics worth noting, such as its popularity, reusability, modularity, concurrency, abstraction and encapsulation. Object-oriented analysis and design transforms software requirements gathered with textual techniques into object-oriented programming. This transformation can cause complexity in identifying objects, classes and interfaces, which, in turn, complicates the object-oriented analysis and design. Because requirements can change over the course of a project and, likewise, software design can evolve during software construction, the traceability of software requirements with objects and components can become difficult. Apart from leading to project complexity, such a process can impact software quality and, in the worst-case scenario, cause the project to fail entirely. The goal of this article is to provide interface-driven techniques that will reduce ambiguity among software requirements, improve traceability and simplify software requirements modelling.

APA, Harvard, Vancouver, ISO, and other styles

22

Nowakowski, Wiktor, Michał Śmiałek, Albert Ambroziewicz, and Tomasz Straszak. "Requirements-level language and tools for capturing software system essence." Computer Science and Information Systems 10, no. 4 (2013): 1499–524. http://dx.doi.org/10.2298/csis121210062n.

Full text

Abstract:

Creation of an unambiguous requirements specification with precise domain vocabulary is crucial for capturing the essence of any software system, either when developing a new system or when recovering knowledge from a legacy one. Software specifications usually maintain noun notions and include them in central vocabularies. Verb or adjective phrases are easily forgotten and their definitions buried inside imprecise paragraphs of text. This paper proposes a model-based language for comprehensive treatment of domain knowledge, expressed through constrained natural language phrases that are grouped by nouns and include verbs, adjectives and prepositions. In this language, vocabularies can be formulated to describe behavioural characteristics of a given problem domain. What is important, these characteristics can be linked from within other specifications similarly to a wiki. The application logic can be formulated through sequences of imperative subject-predicate sentences containing only links to the phrases in the vocabulary. The paper presents an advanced tooling framework to capture application logic specifications making them available for automated transformations down to code. The tools were validated through a controlled experiment.

APA, Harvard, Vancouver, ISO, and other styles

23

Mauw, S., and G. J. Veltink. "A Process Specification Formalism1." Fundamenta Informaticae 13, no. 2 (April 1, 1990): 85–139. http://dx.doi.org/10.3233/fi-1990-13202.

Full text

Abstract:

Traditional methods for programming sequential machines are inadequate for specifying parallel systems. Because debugging of parallel programs is hard, due to e.g. non-deterministic execution, verification of program correctness becomes an even more important issue. The Algebra of Communicating Processes (ACP) is a formal theory which emphasizes verification and can be applied to a large domain of problems ranging from electronic circuits to CAM architectures. The manual verification of specifications of small size has already been achieved, but this cannot easily be extended to the verification of larger industrially relevant systems. To deal with this problem we need computer tools to help with the specification, simulation, verification and implementation. The first requirement for building such a set of tools is a specification language. In this paper we introduce PSFd (Process Specification Formalism – draft) which can be used to formally express processes in ACP. In order to meet the modern requirements of software engineering, like reusability of software, PSFd supports the modular construction of specifications and parameterization of modules. To be able to deal with the notion of data, ASF (Algebraic Specification Formalism) is embedded in our formalism. As semantics for PSFd a combination of initial algebra semantics and operational semantics for concurrent processes is used. A comparison with programming languages and other formal description techniques for the specification of concurrent systems is included.

APA, Harvard, Vancouver, ISO, and other styles

24

Fuchs, Norbert E., and David Robertson. "Declarative specifications." Knowledge Engineering Review 11, no. 4 (December 1996): 317–31. http://dx.doi.org/10.1017/s0269888900008018.

Full text

Abstract:

AbstractDeriving formal specifications from informal requirements is extremely difficult since one has to overcome the conceptual gap between an application domain and the domain of formal specification methods. To reduce this gap we introduce application-specific specification languages, i.e., graphical and textual notations that can be unambiguously mapped to formal specifications in a logic language. We describe a number of realised approaches based on this idea, and evaluate them with respect to their domain specificity vs. generality.

APA, Harvard, Vancouver, ISO, and other styles

25

Hassani, Rachida, and Younès EL Bouzekri EL Idrissi. "Normalization of Requirements Specification Document on Software Project Management." Journal of Software 13, no. 4 (April 2018): 232–41. http://dx.doi.org/10.17706/jsw.13.4.232-241.

Full text

APA, Harvard, Vancouver, ISO, and other styles

26

Belfo, Fernando. "People, Organizational and Technological Dimensions of Software Requirements Specification." Procedia Technology 5 (2012): 310–18. http://dx.doi.org/10.1016/j.protcy.2012.09.034.

Full text

APA, Harvard, Vancouver, ISO, and other styles

27

Giakoumakis, E. A., and G. Xylomenos. "Evaluation and selection criteria for software requirements specification standards." Software Engineering Journal 11, no. 5 (1996): 307. http://dx.doi.org/10.1049/sej.1996.0041.

Full text

APA, Harvard, Vancouver, ISO, and other styles

28

Ghajar-Dowlatshahi, Jahangir, and Ashok Vernekar. "RAPID PROTOTYPING IN REQUIREMENTS SPECIFICATION PHASE OF SOFTWARE SYSTEMS." INCOSE International Symposium 4, no. 1 (August 1994): 125–30. http://dx.doi.org/10.1002/j.2334-5837.1994.tb01693.x.

Full text

APA, Harvard, Vancouver, ISO, and other styles

29

Jayatilleke, Shalinka, Richard Lai, and Karl Reed. "Managing software requirements changes through change specification and classification." Computer Science and Information Systems 15, no. 2 (2018): 321–46. http://dx.doi.org/10.2298/csis161130041j.

Full text

Abstract:

Software requirements changes are often inevitable due to the changing nature of running a business and operating the Information Technology (IT) system which supports the business. As such, managing software requirements changes is an important part of software development. Past research has shown that failing to manage software requirements changes effectively is a main contributor to project failure. One of the difficulties in managing requirements changes is the lack of effective methods for communicating changes from the business to the IT professionals. In this paper, we present an approach to managing requirements change by improving the change communication and elicitation through a method of change specification and a method of classification. Change specification provides a way such that communication ambiguities can be avoided between business and IT staff. The change classification mechanism identifies the type of the changes to be made and preliminary identification of the actions to be taken. We illustrate the usefulness of the methods by applying them to a case study of course management system.

APA, Harvard, Vancouver, ISO, and other styles

30

Walters, Neal. "Requirements specification for Ada software under DoD-STD-2167A." Journal of Systems and Software 15, no. 2 (May 1991): 173–83. http://dx.doi.org/10.1016/0164-1212(91)90054-a.

Full text

APA, Harvard, Vancouver, ISO, and other styles

31

Drusinsky, Doron. "Computer-aided discovery of formal specification behavioral requirements and requirement to implementation mappings." Innovations in Systems and Software Engineering 10, no. 4 (June 25, 2014): 271–81. http://dx.doi.org/10.1007/s11334-014-0235-1.

Full text

APA, Harvard, Vancouver, ISO, and other styles

32

Ali, Naveed, and Richard Lai. "A method of software requirements specification and validation for global software development." Requirements Engineering 22, no. 2 (November 19, 2015): 191–214. http://dx.doi.org/10.1007/s00766-015-0240-4.

Full text

APA, Harvard, Vancouver, ISO, and other styles

33

Mohd, Haslina, Fauziah Baharom, Norida Muhd Darus, Shafinah Farvin Packeer Mohamed, Zaharin Marzuki, and Muhammad Afdhal Muhammad Robie. "Functional Requirements Specification of E-Tendering Using Natural Language Approach: Towards Innovative Business Transformation." Journal of Computational and Theoretical Nanoscience 16, no. 12 (December 1, 2019): 5003–7. http://dx.doi.org/10.1166/jctn.2019.8555.

Full text

Abstract:

Recently, business transformation towards the used of Information and Communication Technology (ICT) is a necessity toward rapid industries and the paradigm shifted to sustain business competitiveness. The holistic electronic approach is one of business innovations, especially in handling a lot of tender documentations and process in an electronic environment namely as e-Tendering. Unfortunately, the existing tender process transformation in the electronic approach is not properly followed certain standard and guideline, especially in establishing a good e-Tendering functional requirements specification to ensure the organizations would be in the best served. This is important to ensure a good e-Tendering system can be developed by e-Tendering developers based on a good e-Tendering functional requirement specifications. The requirements specification is a process of documenting user and system requirements. Commonly, user and system requirements should be clear, unambiguous, easy to understand, complete, and consistent. In practice, this is difficult to achieve due to interpretation of the requirements in different ways by stakeholders, which are often inherent conflicts and inconsistencies of the requirements. The implementation of the existing e-tendering still remains uncertainties, especially in defining the functional requirements of the e-tendering system. Therefore, this study aims to construct the e-Tendering functional requirement model using requirement template in natural language representation approach. Moreover the development of this system requirement model may provide a consistency to the requirements representation. The study uses UN/CEFACT Business Standard of the e-Tendering Business. The identified functional requirements are designed by using Requirement Template to ensure the reliability and understandability of requirements. Besides, the proposed functional requirements is constructed by adapting the natural language and verified by expert review approaches. As a result, this study proposed a functional requirements specification of the e-Tendering that contains detailed description which can be referred by software practitioners in developing a secure e-tendering system effectively.

APA, Harvard, Vancouver, ISO, and other styles

34

Kotonya, G. "Practical Experience with Viewpoint-Oriented Requirements Specification." Requirements Engineering 4, no. 3 (September 1, 1999): 115–33. http://dx.doi.org/10.1007/s007660050023.

Full text

APA, Harvard, Vancouver, ISO, and other styles

35

Rombach, D. "A specification framework for software processes: formal specification and derivation of information base requirements." ACM SIGSOFT Software Engineering Notes 14, no. 4 (May 1989): 142–47. http://dx.doi.org/10.1145/75111.75137.

Full text

APA, Harvard, Vancouver, ISO, and other styles

36

Oktaviyani, Enny Dwi, and Licantik Licantik. "MENDETEKSI REDUNDANSI PASANGAN KALIMAT DALAM DOKUMEN SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK DENGAN PENDEKATAN KEMIRIPAN SEMANTIK." Jurnal Teknologi Informasi: Jurnal Keilmuan dan Aplikasi Bidang Teknik Informatika 15, no. 1 (January 10, 2021): 13–24. http://dx.doi.org/10.47111/jti.v15i1.1894.

Full text

Abstract:

Software Requirements Specification Document must be complete, unambiguous and correct because an incorrect Software Requirements Specification Document can lead to failure in software development. Software Requirements Specification document must contain non-redundant sentences. Meyer's Seven Sins describes several errors in Software Requirements Specification Document, one of which is redundancy which is a variant of noise. Redundancy is the repetition of the same information, but using different terms or phrases, thus giving the impression that new information is available. This study analyzes the performance of the framework and tools for detecting redundancy in sentence pairs in the software requirements specification document using the WordNet-based semantic similarity method. This study tries to develop the framework and tools that have been proposed in previous studies, namely by detecting redundancy in sentence pairs without fact extraction. The proposed approach and evaluation process uses Kappa values ??to determine whether the performance of the framework and assistive tools can be used to detect redundancy in sentence pairs properly. The method using literature study, data collection, problem analysis, making a framework, making auxiliary tools, and testing. The test uses the Kappa value with two scenarios, from the results of testing the framework and assistive tools can be used to detect redundancy in the Software Requirements Specification Document with a Kappa value of 0.777 with the interpretation of the kappa value is a substantial agreement at a threshold of 0.73

APA, Harvard, Vancouver, ISO, and other styles

37

Oktaviyani, Enny Dwi, and Licantik Licantik. "MENDETEKSI REDUNDANSI PASANGAN KALIMAT DALAM DOKUMEN SPESIFIKASI KEBUTUHAN PERANGKAT LUNAK DENGAN PENDEKATAN KEMIRIPAN SEMANTIK." Jurnal Teknologi Informasi: Jurnal Keilmuan dan Aplikasi Bidang Teknik Informatika 15, no. 1 (January 10, 2021): 13–24. http://dx.doi.org/10.47111/jti.v15i1.1894.

Full text

Abstract:

Software Requirements Specification Document must be complete, unambiguous and correct because an incorrect Software Requirements Specification Document can lead to failure in software development. Software Requirements Specification document must contain non-redundant sentences. Meyer's Seven Sins describes several errors in Software Requirements Specification Document, one of which is redundancy which is a variant of noise. Redundancy is the repetition of the same information, but using different terms or phrases, thus giving the impression that new information is available. This study analyzes the performance of the framework and tools for detecting redundancy in sentence pairs in the software requirements specification document using the WordNet-based semantic similarity method. This study tries to develop the framework and tools that have been proposed in previous studies, namely by detecting redundancy in sentence pairs without fact extraction. The proposed approach and evaluation process uses Kappa values ??to determine whether the performance of the framework and assistive tools can be used to detect redundancy in sentence pairs properly. The method using literature study, data collection, problem analysis, making a framework, making auxiliary tools, and testing. The test uses the Kappa value with two scenarios, from the results of testing the framework and assistive tools can be used to detect redundancy in the Software Requirements Specification Document with a Kappa value of 0.777 with the interpretation of the kappa value is a substantial agreement at a threshold of 0.73

APA, Harvard, Vancouver, ISO, and other styles

38

Marques, Johnny, and Adilson Marques da Cunha. "ARES: An Agile Requirements Specification Process for Regulated Environments." International Journal of Software Engineering and Knowledge Engineering 29, no. 10 (October 2019): 1403–38. http://dx.doi.org/10.1142/s021819401950044x.

Full text

Abstract:

Agile methods have provided significant contributions to Software Engineering. This work presents a new process for Software Requirements Specification, integrating Agile Properties and regulated environments, such as aviation, medical, nuclear and automotive, among others. The Software in Regulated Environments (SRE) involves plan-driven methods with needed documentation to ensure safety, reliability, security, and discipline. This paper proposes a balance between agile and plan-driven methods. We define a new process, which explores and investigates the usage of agile methods in SRE. The scope of this paper is Requirements Engineering, which is considered as a set of activities involved in the management, elicitation, documentation, and maintenance of requirements. The Adile Requirements Specification (ARES) process contains four methods, 13 activities, and some required artifacts to ensure compliance with the following six relevant Software Standards for regulated environments: RTCA DO-178C, IEC 62304:2015, ECSS-E-ST-40C, IEC 61508-3, ISO/IEC/IEEE 12207, and IAEA SSG-39. The process evaluation was performed using two experiments: a Cockpit Display System (CDS) and a Healthcare Information System (HIS). These experiments were measured with appropriate metrics to ensure improvements in Software Requirements Specification and traceability among artifacts. The experimental results revealed that the ARES process works better than the original Scrum for Software in Regulated Environments. The ARES process can also be integrated with traditional software life cycles (Waterfall, V, and Incremental and Iterative), when applied in the Requirements Engineering phase.

APA, Harvard, Vancouver, ISO, and other styles

39

Ciaccia, P., P. Ciancarini, and W. Penzo. "Formal Requirements and Design Specifications: The Clepsydra Methodology." International Journal of Software Engineering and Knowledge Engineering 07, no. 01 (March 1997): 1–42. http://dx.doi.org/10.1142/s0218194097000023.

Full text

Abstract:

The use of formal methods early in the development process has been advocated as a way of improving the quality of software products and their production process. Here we study the influence of a formal requirements document on the next phase in the software process, that is design. We suggest that formal design should coherently follow from formal requirements. We show that two different formal notations can be effectively used, one for writing requirements specification and one for design specification. We also consider how a design specification can be formally checked with respect to requirements specification. The notations we choose are well known: the Z notation for requirements and the Larch two-tiered language for design. We show how a number of tools based on these notations can be used to improve the quality of the documents produced during the development process.

APA, Harvard, Vancouver, ISO, and other styles

40

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

41

Macaulay, Linda, Chris Fowler, Mark Kirby, and Andrew Hutt. "USTM: a new approach to requirements specification." Interacting with Computers 2, no. 1 (April 1990): 92–118. http://dx.doi.org/10.1016/0953-5438(90)90017-c.

Full text

APA, Harvard, Vancouver, ISO, and other styles

42

Marques, Johnny, and Sarasuaty Yelisetty. "An Analysis of Software Requirements Specification Characteristics In Regulated Environments." International Journal of Software Engineering & Applications 10, no. 6 (November 30, 2019): 1–15. http://dx.doi.org/10.5121/ijsea.2019.10601.

Full text

APA, Harvard, Vancouver, ISO, and other styles

43

Broy, Manfred. "Multifunctional software systems: Structured modeling and specification of functional requirements." Science of Computer Programming 75, no. 12 (December 2010): 1193–214. http://dx.doi.org/10.1016/j.scico.2010.06.007.

Full text

APA, Harvard, Vancouver, ISO, and other styles

44

Manek, Patricia Gertrudis, and Daniel Siahaan. "NOISE DETECTION IN SOFTWARE REQUIREMENTS SPECIFICATION DOCUMENT USING SPECTRAL CLUSTERING." JUTI: Jurnal Ilmiah Teknologi Informasi 17, no. 1 (March 12, 2019): 30. http://dx.doi.org/10.12962/j24068535.v17i1.a771.

Full text

APA, Harvard, Vancouver, ISO, and other styles

45

Zmeyev, Oleg A., Arsenty M. Politov, and Yana M. Chayka. "Concept of unified use case model for software requirements specification." Vestnik Tomskogo gosudarstvennogo universiteta. Upravlenie, vychislitel'naya tekhnika i informatika, no. 3(32) (September 1, 2015): 91–98. http://dx.doi.org/10.17223/19988605/32/10.

Full text

APA, Harvard, Vancouver, ISO, and other styles

46

Zhi, Qiang, and Shuji Morisaki. "An Evaluation of Value-Oriented Review for Software Requirements Specification." Computer Systems Science and Engineering 37, no. 3 (2021): 443–61. http://dx.doi.org/10.32604/csse.2021.015157.

Full text

APA, Harvard, Vancouver, ISO, and other styles

47

Wijayarathna, P. G., Y. Kawata, A. Santosa, K. Isogai, and M. Maekawa. "GSL: a requirements specification language for end-user intelligibility." Software: Practice and Experience 28, no. 13 (November 1998): 1387–414. http://dx.doi.org/10.1002/(sici)1097-024x(1998110)28:13<1387::aid-spe208>3.0.co;2-#.

Full text

APA, Harvard, Vancouver, ISO, and other styles

48

EDWARDS, STEPHEN H. "COMMON INTERFACE MODELS FOR REUSABLE SOFTWARE." International Journal of Software Engineering and Knowledge Engineering 03, no. 02 (June 1993): 193–206. http://dx.doi.org/10.1142/s0218194093000094.

Full text

Abstract:

Related reusable components are often based on different conceptual models of behavior. This may unduly restrict the ways in which they can be composed. The conceptual model underlying the specification of one module’s parameter requirements may differ significantly from the model underlying the specification of another module’s exported features, even if the two modules intuitively seem compatible. There is no well understood groundwork of common models for component interaction, and the lack of guidance for applying these models exacerbates the composability problem. This article describes how varying interface models and techniques for describing a component’s interface requirements affect composability. These problems are illustrated in the context of common interface properties that are exhibited even in simple ADT components.

APA, Harvard, Vancouver, ISO, and other styles

49

Belfo, Fernando Paulo. "Software Requirements Management through the Lenses of People, Organizational and Technological Dimensions." International Journal of Web Portals 4, no. 3 (July 2012): 47–61. http://dx.doi.org/10.4018/jwp.2012070104.

Full text

Abstract:

The inadequate specification of requirements remains being indicated as one of the main reasons for the failure of software development projects. A possible explanation for this failure is that requirements management tends to overvalue the technology side of requirements. However, the requirements management depends on other important issues beyond technology which are sometimes neglected. Good requirements are only assured by the right balance of three dimensions: people, organization and technology. Through the lens of each of these three dimensions, this paper reviews significant literature, identifying some of the key issues and concerns about the management of software requirements, particularly the software requirements specification. Major software quality attributes, like clearness, completeness, correctness, understandability, verifiability or validity, consistency and feasibility, are used to analyse several important facets of software requirements management. Implications for future research are discussed.

APA, Harvard, Vancouver, ISO, and other styles

50

Wojaczek, Anna, Michael Scott Brown, and Tomasz Smal. "Developing Software Requirements Specification for a strategic goods air transportation system." Scientific Journal of the Military University of Land Forces 198, no. 4 (December 15, 2020): 906–17. http://dx.doi.org/10.5604/01.3001.0014.5875.

Full text

Abstract:

Management of air transportation of strategic goods is a very complex task with many challenges. This paper describes the method used in documenting the requirements for an IT system intended to support management of air transportation of military and dual-use goods. The work was completed in conjunction with a private logistics company. The project produced a Software Requirements Specification document and a working prototype. The document and prototype are held by the Military University of Land Forces of Poland. Requirements were solicited from numerous sources. A private logistics company, numerous books and personal experience of the team members all contributed to requirements. These requirements were then analyzed and a final set of requirements was produced. Screen mock-ups and a working prototype were developed. Selected screen shots are within the paper. The working prototype was developed by constructing a database and using a code generator to produce a web application.

APA, Harvard, Vancouver, ISO, and other styles

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!