Semantic Analysis of Functional and Non-Functional Requirements in Software Requirements Specifications

Author(s):  
Abderahman Rashwan
2021 ◽  
Vol 26 (4) ◽  
Author(s):  
Alvaro Veizaga ◽  
Mauricio Alferez ◽  
Damiano Torre ◽  
Mehrdad Sabetzadeh ◽  
Lionel Briand

AbstractNatural language (NL) is pervasive in software requirements specifications (SRSs). However, despite its popularity and widespread use, NL is highly prone to quality issues such as vagueness, ambiguity, and incompleteness. Controlled natural languages (CNLs) have been proposed as a way to prevent quality problems in requirements documents, while maintaining the flexibility to write and communicate requirements in an intuitive and universally understood manner. In collaboration with an industrial partner from the financial domain, we systematically develop and evaluate a CNL, named Rimay, intended at helping analysts write functional requirements. We rely on Grounded Theory for building Rimay and follow well-known guidelines for conducting and reporting industrial case study research. Our main contributions are: (1) a qualitative methodology to systematically define a CNL for functional requirements; this methodology is intended to be general for use across information-system domains, (2) a CNL grammar to represent functional requirements; this grammar is derived from our experience in the financial domain, but should be applicable, possibly with adaptations, to other information-system domains, and (3) an empirical evaluation of our CNL (Rimay) through an industrial case study. Our contributions draw on 15 representative SRSs, collectively containing 3215 NL requirements statements from the financial domain. Our evaluation shows that Rimay is expressive enough to capture, on average, 88% (405 out of 460) of the NL requirements statements in four previously unseen SRSs from the financial domain.


2020 ◽  
Vol 9 (2) ◽  
pp. 215
Author(s):  
Dwi Januarita AK

The rapid development of technology makes this technology have an impact on many fields, one of which is the business world. The number of businesses that have emerged both small and large businesses that have an impact on competition between these businesses. Today, business in the culinary field is getting tougher. The culinary business sector of restaurants is increasingly popping up in this age. We need to overcome the competition in the emerging restaurant business. By using the stages of making software requirements specifications based on ISO / IEC / IEEE 29148-2018, this restaurant business will have an international standard information system. The result of this method is a software requirements specification document (SKPL) as a reference document for all activities carried out during the development of this information system.


Author(s):  
Agostino Cortesi ◽  
Francesco Logozzo

This chapter investigates a formal approach to the verification of non-functional software requirements that are crucial in Service-oriented Systems, like portability, time and space efficiency, and dependability/robustness. The key-idea is the notion of observable, i.e., an abstraction of the concrete semantics when focusing on a behavioral property of interest. By applying an abstract interpretation-based static analysis of the source program, and by a suitable choice of abstract domains, it is possible to design formal and effective tools for non-functional requirements validation.


Author(s):  
Norman F. Schneidewind

In order to continue to make progress in software measurement, as it pertains to reliability and maintainability, there must be a shift in emphasis from design and code metrics to metrics that characterize the risk of making requirements changes. By doing so, the quality of delivered software can be improved because defects related to problems in requirements specifications will be identified early in the life cycle. An approach is described for identifying requirements change risk factors as predictors of reliability and maintainability problems. This approach can be generalized to other applications with numerical results that would vary according to application. An example is provided that consists of 24 space shuttle change requests, 19 risk factors, and the associated failures and software metrics.


Sign in / Sign up

Export Citation Format

Share Document