Journal articles: '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

11

Hovorushchenko, Tetiana. "Method of Evaluating the Weights of Software Quality Measures and Indicators." Application and Theory of Computer Technology 2, no. 2 (February 28, 2017): 16. http://dx.doi.org/10.22496/atct20170128136.

Full text

Abstract:

Nowadays the actual task is evaluating the mutual influences of the software quality characteristics and subcharacteristics by the measures and software quality metrics – by the indicators. The aim of this study is the development of the method of evaluating the weights of software quality measures and indicators. The first time developed method of evaluating the weights of the software quality measures and indicators differs from known methods that: considers the correlation of software quality subchcaracteristics by the measures and metrics by the indicators, calculates the weights of exactly measures and indicators, provides the conclusion about the presence of which measures and indicators in the software requirements specification (SRS) is necessary for the appropriate level of veracity of the software quality assessment. The weights of the software quality measures and indicators provide the sorting of all missing in the SRS measures and indicators in descending of their significance (in descending of their weights), i.e. the priority of their further addition in the SRS.

APA, Harvard, Vancouver, ISO, and other styles

12

Gupta, Ashok Kumar Gupta, and Aziz Deraman. "A framework for software requirement ambiguity avoidance." International Journal of Electrical and Computer Engineering (IJECE) 9, no. 6 (December 1, 2019): 5436. http://dx.doi.org/10.11591/ijece.v9i6.pp5436-5445.

Full text

Abstract:

This research deals with software requirements ambiguity problems. Among these are incomplete, incorrect, improper, inaccurate and unambiguous requirements. Interestingly, published material related to Software Requirements Specifications (SRS) problems discusses ambiguity as one of the most conversed problems. This paper proposes a Software Requirement Ambiguity Avoidance Framework (SRAAF) to assist and support requirement engineers to write unambiguous requirements, by selecting correct elicitation technique based on the evaluation of various attributes and by applying the W6H technique. We explored existing theories and the outcomes of experimental research to construct the framework. On the basis of existing and inferred knowledge, we tried to justify proposed frameworks components. Our selection process focuses on various situational attributes. We added various situational attributes related to project, stakeholders and requirement engineer for the selection process. Newly devised approach chooses techniques other than traditional techniques or most common techniques and deals with ambiguity to capture the correct requirements information from stakeholders. The framework will be able to address the selection and ambiguity issues in a more effective way and can handle vagueness. New evidence related to attributes and adequacy matrix can be easily added to the framework without any inconvenience.

APA, Harvard, Vancouver, ISO, and other styles

13

Marcheta, Noorlela. "EFFORT ESTIMATION MODELING OF E-GOVERNMENT APPLICATION DEVELOPMENT USING FUNCTION POINTS BASED ON TOR AND SRS DOCUMENT." Journal of Information Technology and Its Utilization 3, no. 1 (August 26, 2020): 5. http://dx.doi.org/10.30818/jitu.3.1.2839.

Full text

Abstract:

Software cost estimation is important for information systems management and is generally taught in software engineering courses especially to terms of the ever-increasing development of E-Government. A significant challenge for Software Sizing (SS) is to determine cost estimates based on TOR documents that do not yet contain complete Software Requirements Specifications (SRS). This study uses Function Points as one of the measurement methods that can make cost estimates and expert needs based on the desired functional system. On the other hand, there are cases where estimation needs after the SRS document have been made. Thus in this study, the authors discuss the implementation of SS based on TOR and SRS documents for E-Government. The results of this study indicate the closeness of the actual and estimated values of 81.9% for TOR and 93.4% for SRS.

APA, Harvard, Vancouver, ISO, and other styles

14

Miao, Weikai, and Xi Wang. "An Evolutionary Method for the Formal Specification Construction of Service-Based Software." International Journal of Software Engineering and Knowledge Engineering 26, no. 04 (May 2016): 587–610. http://dx.doi.org/10.1142/s0218194016400039.

Full text

Abstract:

Service-based software (SBS) modeling is considered as a promising way to develop high-quality service-based systems. One major challenge of this methodology is how to effectively utilize existing software services in the process of system modeling to ensure the reliability of the system while reducing the development cost. In this paper, we propose an evolutionary method for the formal specification construction of SBS to tackle this problem. Initial requirements are gradually transformed into a formal design specification through three steps during which existing services are discovered, filtered, selected and adopted. Candidate services are discovered through a keyword-based searching. Then the services are analyzed from both the structural and behavioral perspectives for filtering. A specification-based testing technique is exploited to rigorously determine which candidate services are finally selected. The selected services are incorporated into the formal design model of the system. We present a case study that was conducted for evaluating the usability of the method. We have also developed a prototype tool for supporting the method to be applied in practice.

APA, Harvard, Vancouver, ISO, and other styles

15

PALMA, FRANCIS, MATHIEU NAYROLLES, NAOUEL MOHA, YANN-GAËL GUÉHÉNEUC, BENOIT BAUDRY, and JEAN-MARC JÉZÉQUEL. "SOA ANTIPATTERNS: AN APPROACH FOR THEIR SPECIFICATION AND DETECTION." International Journal of Cooperative Information Systems 22, no. 04 (December 2013): 1341004. http://dx.doi.org/10.1142/s0218843013410049.

Full text

Abstract:

Like any other large and complex software systems, Service-Based Systems (SBSs) must evolve to fit new user requirements and execution contexts. The changes resulting from the evolution of SBSs may degrade their design and quality of service (QoS) and may often cause the appearance of common poor solutions in their architecture, called antipatterns, in opposition to design patterns, which are good solutions to recurring problems. Antipatterns resulting from these changes may hinder the future maintenance and evolution of SBSs. The detection of antipatterns is thus crucial to assess the design and QoS of SBSs and facilitate their maintenance and evolution. However, methods and techniques for the detection of antipatterns in SBSs are still in their infancy despite their importance. In this paper, we introduce a novel and innovative approach supported by a framework for specifying and detecting antipatterns in SBSs. Using our approach, we specify 10 well-known and common antipatterns, including Multi Service and Tiny Service, and automatically generate their detection algorithms. We apply and validate the detection algorithms in terms of precision and recall two systems developed independently, (1) Home-Automation, an SBS with 13 services, and (2) FraSCAti, an open-source implementation of the Service Component Architecture (SCA) standard with more than 100 services. This validation demonstrates that our approach enables the specification and detection of Service Oriented Architecture (SOA) antipatterns with an average precision of 90% and recall of 97.5%.

APA, Harvard, Vancouver, ISO, and other styles

16

Naimatullah, Syed. "Abstraction of View Elements from Software Requirement Specifications (SRS)." International Journal of Computer Applications 155, no. 4 (December 15, 2016): 44–48. http://dx.doi.org/10.5120/ijca2016912301.

Full text

APA, Harvard, Vancouver, ISO, and other styles

17

Dessai, Sanket, Deepa Kannan, and Shiva Prasa Yadav. "Implementation of video surveillance system using embedded Blackfin processor." International Journal of Reconfigurable and Embedded Systems (IJRES) 10, no. 2 (July 1, 2021): 115. http://dx.doi.org/10.11591/ijres.v10.i2.pp115-122.

Full text

Abstract:

<p class="NormalLinespacing15lines">The video surveillance is critical system to track the people at the various places and to track and monitor the nuciencess bound to be happened. On the other side several studies have proved and showed the hit and miss nature of human intervention to spot change in a surrounding environment which increasing the designer challenges for the development of video surveillance system with the help of embedded processor. The designer faces a greater challenge to apply the principle of embedded systems and develop the system smart features with low power and cost for the required applications of VSS. System requirement specification (SRS), Hardware design document (HDD), Software design document and test procedure has been arrived and developed to achieve VSS system. Blackfin processor has high end video engines and is more suitable for development of video surveillance system (VSS). The VSS is designed and developed using ADSP BF533 Ez-kit lite board. Peripheral like parallel peripheral interface (PPI) is used to interface between camera and processor. Also, it is used for interfacing processor and TV. The master-slave communication is established between two Blackfin processors through SPORT to transfer the captured frame from camera to display on TV. Power management is also implemented to save the power of the system.</p>

APA, Harvard, Vancouver, ISO, and other styles

18

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

19

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

20

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

21

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

22

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

23

Eyal Salman, Hamzeh, Mustafa Hammad, Abdelhak-Djamel Seriai, and Ahed Al-Sbou. "Semantic Clustering of Functional Requirements Using Agglomerative Hierarchical Clustering." Information 9, no. 9 (September 3, 2018): 222. http://dx.doi.org/10.3390/info9090222.

Full text

Abstract:

Software applications have become a fundamental part in the daily work of modern society as they meet different needs of users in different domains. Such needs are known as software requirements (SRs) which are separated into functional (software services) and non-functional (quality attributes). The first step of every software development project is SR elicitation. This step is a challenge task for developers as they need to understand and analyze SRs manually. For example, the collected functional SRs need to be categorized into different clusters to break-down the project into a set of sub-projects with related SRs and devote each sub-project to a separate development team. However, functional SRs clustering has never been considered in the literature. Therefore, in this paper, we propose an approach to automatically cluster functional requirements based on semantic measure. An empirical evaluation is conducted using four open-access software projects to evaluate our proposal. The experimental results demonstrate that the proposed approach identifies semantic clusters according to well-known used measures in the subject.

APA, Harvard, Vancouver, ISO, and other styles

24

Imron, Hefmi Fauzan, R. Rizal Isnanto, and Eko Didik Widianto. "Perancangan Sistem Kendali pada Alat Listrik Rumah Tangga Menggunakan Media Pesan Singkat (SMS)." Jurnal Teknologi dan Sistem Komputer 4, no. 3 (August 10, 2016): 454. http://dx.doi.org/10.14710/jtsiskom.4.3.2016.454-462.

Full text

Abstract:

Listrik merupakan salah satu kebutuhan penting dalam kehidupan dan selama ini ketergantungan manusia terhadap listrik menimbulkan kebiasaan buruk. Banyak orang terkadang membiarkan suatu alat listrik ditinggal dalam kondisi menyala yang dapat menyebabkan pemborosan dan pemborosan sendiri bukanlah satu satunya masalah yang akan timbul namun juga dapat menyebabkan kebakaran. Oleh sebab itu, perlu dilakukan penelitian dengan mengembangkan sistem yang dapat mengontrol dan mengetahui status alat listrik yang bisa diakses dari jarak jauh, contohnya melalui pesan singkat (SMS). Sistem terdiri atas perangkat keras dan perangkat lunak. Perangkat keras terdiri atas sensor arus sebagai masukan arus listrik, Arduino Mega sebagai mikrokontroler, sensor PIR sebagai inputan mendeteksi keberadaan panas tubuh manusia, relay sebagai keluaran yang berfungsi sebagai saklar dan SIM900 Mini Modul sebagai penerima dan pengirim pesan singkat (SMS). Perangkat lunak dibuat menggunakan bahasa C dengan Arduino IDE. Kegiatan penelitian meliputi studi literatur, analisis spesifikasi kebutuhan, perancangan sistem, implementasi, dan pengujian. Hasil pengujian menunjukkan sistem mampu menyalakan dan mematikan terminal yang terhubung dengan alat listrik menggunakan perintah pesan singkat (SMS), sistem mampu mendeteksi keberadaan panas tubuh manusia, sistem mampu memeriksa keadaan terminal dalam posisi menyala ataupun tidak, sistem mampu memberi notifikasi melalui pesan singkat (SMS) tentang penggunaan komponen listrik yang dilalaikan dan bila ada orang asing yang ingin masuk kedalam sistem. Electricity is one of the important needs in life and for human dependency on electricity cause bad habits. Many people sometimes let an electrical appliance was left in light conditions that can cause waste and waste itself is not the only issue that will arise, but also can cause a fire. Therefore, research must be done to develop a system that can control and know the status of power tools that can be accessed remotely, for example via short messages service (SMS). The system consists of hardware and software. The hardware consists of a current sensor as an input electrical current, Arduino Mega as microcontroller, the PIR sensor as an input to detect the presence of human body heat, as the output relay that function as a switch and SIM900 Mini Module as the receiver and sender short messages services (SMS). The software is built using C with the Arduino IDE. The research activities include the study of literature, analysis of requirements specification, system design, implementation and testing The test result show the system can turn on and off the terminal that is connected to the power tool using the command short message services (SMS), the system is able to detect the presence of human body heat, the system is able to check the state of the terminal in a position on or off, the system is able to give notification via short message services (SMS) on the use of electrical components is neglected and if there are foreigners who wish to enter into the system.

APA, Harvard, Vancouver, ISO, and other styles

25

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

26

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

27

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

28

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

29

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

30

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

31

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

32

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

33

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

34

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

35

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

36

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

37

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

38

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

39

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

40

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

41

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

42

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

43

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

44

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

45

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

46

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

47

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

48

Moore, A. P. "The specification and verified decomposition of system requirements using CSP." IEEE Transactions on Software Engineering 16, no. 9 (1990): 932–48. http://dx.doi.org/10.1109/32.58782.

Full text

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

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

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

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