Use Case Modeling

Software requirement artifacts such as manuals request for proposals, and software requirements specification (SRS) are commonly focused on functional requirements. In most SRS files, nonfunctional requirements do not formally encoded or encoded as a whole, not for an individual design problem. Moreover, these nonfunctional requirements are intermingled with functional requirements. Therefore, these nonfunctional requirements need special attention to understand for successful project development. These nonfunctional requirements have an impact on each other and optimal tradeoff is required for balanced nonfunctional requirements set. NFRs have a negative and positive tradeoff with each other such as increase confidentiality, decrease the availability, and enhance authenticity. So, an optimum tradeoff among these design problem within a module is required to have better design decisions. Instead of considering all nonfunctional requirements, the NFRs that have mutual tradeoff is considered. In this paper, we devised a novel document annotation scheme for SRS and extracted nonfunctional requirements from these annotated artifacts. In the next step, we classified NFRs into two classes security triad and performance triad, and the cost is assumed constant for each NFR. From the design problem, the tradeoff ratio is calculated among NFRs associated with it. Then, the production possibility graph is plotted to estimate the optimum tradeoff ratio within the module. For estimation economic optimum from a set of NFR, iso-cost graphs by assuming the constant cost. Some hypothetical variations in cost are also examined using 3D iso-cost graph. The reason to measure these tradeoff is to make design decision more empirical and helpful for the selection of design patterns, especially secure design patterns.

As Machine Learning (ML) becomes ever more ubiquitous, it is critical to increase the rigor of design and testing. In traditional software, this is done using the Requirements Engineering (RE) process, but RE looks different for ML because it is data-centric. There are different Non-Functional Requirements (NFRs) and standard testing techniques do not apply. While there are standards for verifying NFRs in traditional software, there is no standard measurement for ML NFRs, e.g. how is a model verified to meet an explainability NFR? In traditional software, NFRs are decomposed into Functional Requirements (FRs), but without clear measurements for ML NFRs, their decomposition into FRs is nearly impossible. However, recently, research has shown that provenance can help improve model transparency and reproducibility. This work builds on such literature and suggests provenance as a lower-level NFR to connect high-level NFRs, e.g. explainability and transparency, and FRs, thereby enabling concrete model verification based on requirement specifications. This work examines types of ML provenance and their use in decomposing model NFRs into verifiable FRs, thereby better aligning ML development with RE and increasing the rigor of ML testing. This paper aggregates current literature on provenance for ML and provides a method of measurement for otherwise unquantifiable NFRs. This work also analyzes trends in how provenance can decompose various ML NFRs and future directions for the field.

Many researchers try to make a comparison between various Internet-of-Things (IoT) platforms based on specific requirements. However, none of the reviewed studies proposed a thorough analysis of the variety of comparative methods. Since there is a lack of comparison frameworks for IoT platforms, individuals or companies have difficulties when selecting a suitable IoT platform matching their associated business requirements. In order to support this selection process, a set of functional and nonfunctional requirements is identified. A framework containing methods in selecting an IoT platform is presented. The methodology is based on statistical and visualization techniques to recommend a suitable IoT platform. Five IoT platforms: 1) Azure; 2) AWS; 3) SaS; 4) ThingWorx; and 5) Kaa IoT are studied to evaluate the performance of the framework. Different comparison methods are proposed and a multicriteria decision analysis method was applied by using an analytical hierarchical process (AHP). One of the methods clusters the functional requirements and compares the IoT platforms based on their ability in supporting a specific requirement or not. The <inline-formula xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink"> <tex-math notation="LaTeX">$K$ </tex-math></inline-formula> -means clustering was applied to determine the clusters of functional requirements. The comparison was made based on the hierarchical level of requirements per main requirement. The other methods use the following statistical tests: error bar test, one-way Anova test, and Tukey’s honest significant difference test. Based on the selected requirements, an approach is suggested for which IoT platform can be used.

Non-functional Requirements (NFRs) such as software quality attributes, software design constraints and software interface requirements hold crucial information about the constraints on the software system under development and its behavior. NFRs are subjective in nature and have a broad impact on the system as a whole. Being distinct from Functional Requirements (FR), NFRs are dealt with special attention, as they play an integral role during software modeling and development. However, since Software Requirements Specification (SRS) documents, in practice, are written in natural language, solely holding the perspectives of the clients, the documents often end up with FR and NFR statements mixed together in the same paragraphs. It is, therefore, left upon the software analysts to classify and separate them manually. The research, presented in this paper, aims to automate the process of detecting NFR sentences by using a text classifier equipped with a part-of-speech (POS) tagger. The results reported in this paper outperform the recent work in the field, and achieved a higher accuracy of 98.56% using 10-folds-cross-validation over the same data used in the literature. The research reported in this paper is part of a larger project aimed at applying Natural Language Processing techniques in Software Requirements Engineering.KeywordsRequirement EngineerCutoff ThresholdLinguistic KnowledgeRequirement ElicitationSyntactic FeatureThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Non-Functional requirements (NFRs) are overlooked whereas Functional Requirements (FRs) take the center stage in developing agile software. Research has shown that ignoring NFRs can have negative impacts on the software and could potentially cost more to fix at later stages. This research extends the Capture Elicit Prioritize (CEP) methodology to predict NFRs in the early stages agile software development. Research in other fields such as the medical field have shown that historical data can be beneficial in the long run. In the medical field it was found that historical data can be beneficial in determining patient treatments. The Capture Elicit Prioritize (CEP) methodology extended the NERV and NORMAP methodologies in previous research. The CEP methodology identified 56 out of 57 requirement sentences and was successful in eliciting 98.24% of the baseline an improvement of 10.53% of the NORMAP methodology and 1.75% improvement over the NERV methodology. The NFRs count for the CEP methodology was 86 out of 88 NFRs which was an improvement of 12.49% over the NORMAP methodology and 4.55% over the NERV methodology. The CEP was used and utilized the EU eProcument requirements document. The CEP methodology utilized the capture methodology by gathering potential NFRs using OCR from requirements images. The elicit part took the NFR Locator plus and takes sentences from documents and places them in distinct categories. The NFR categories are defined from the Chung's NFR framework utilizing a set of keywords utilized for training to locate NFRs. The e αβγ-framework was utilized to prioritize the NFRs. Utilizing the data from previous research of the CEP methodology and extending the CEP methodology to include a decision tree to predict future NFRs. A simple decision tree was utilized to make a prediction utilizing the past NFRs data. If a certain NFR appears three times or higher in the requirements document. It is most likely that NFRs will appear in the next iteration of the software requirements specification. If the NFRs is equivalent to three times it is likely it will appear in the next iteration. If the NFRs is between one and two it is not likely to appear in future iteration. The path can be traced from the root of the tree to a decision tree's leaf (yes or no) that determines whether the NFRs will appear in future iterations. This research showed that using the data available can be beneficial for the next iteration of software development. This research showed that historical metadata can help in predicting NFRs utilizing a decision tree to make a prediction where NFRs appear multiple times in a set of the EU procurement documents can predict the next iteration of software development. The NFRs Availability, Compliance, Confidentiality, Documentation, Performance, Security, and Usability were found and these NFRs are most likely to appear in the next iteration of the EU procurement software.

Breast cancer is the most common cancer in Jordan. Mutations in BReast CAncer susceptibility gene 1 and BReast CAncer susceptibility gene 2 (BRCA1/2 genes) greatly increase the lifetime risk of developing breast and/or ovarian cancer in women. The aim of this paper is to identify functional and non-functional requirements for BRCA 1/2 testing, as a corner stone for establishing BRCA 1/2 testing services in the country and as a case example for other susceptibility genetic testing for cancer. During two sessions, the authors outlined the functional and non-functional requirements for BRCA1/2 testing, as types of categories of requirements, using the Sommerville approach. Six functional requirements were identified. Non-functional requirements were divided to: 1. Product related 2. Process related and 3. Externally related (Interoperability and Legal, Social, Ethical and Professional (LSEP) Implications). The authors will continue to build on their work in order to produce a full model for BRCA1/2 testing to provide the most comprehensive and advanced cancer care for patients and facilitate future development of innovate measures in the battle against cancer.

The aim of this article is to describe a method that helps analysts to translate qualitative data gathered in the field, collected for the purpose of requirements specification, to a model usable for software engineers. Requirements specification constitutes three different parts: functional requirements, quality requirements, and nonfunctional requirements. The first one specifies how the software system should function, who are the actors, and what are the input and output of the functions. The second one specifies what quality requirements the software should meet while operating in context of its environment such as reliability, usability, efficiency, portability, and maintainability. Finally, the third part specifies other requirements including context of use and development constraints. Examples of context of use are where and when the system is used, and examples of development constraints are human resources, cost and time constraints, technological platforms, and development methods. The role of the requirements specification is to give software engineers a basis for software design, and, later in the software development life cycle, to validate the software system. Requirements specification can also serve the purpose of validating users’ or customers’ view of the requirements of the system. On one hand, there has been a growing trend towards analyzing needs of the user and abilities through participatory design (Kuhn &amp; Muller, 1993), activity theory (Bertelsen &amp; Bødker, 2003), contextual design (Beyer &amp; Holtzblatt, 1998), user-centered design (Gulliksen, Göransson, &amp; Lif, 2001), and co-design and observation as in ethnography (Hughes, O’Brien, Rodden, Rouncefield, &amp; Sommerville, 1995). Common to these methods is that qualitative data (Taylor &amp; Bogdan, 1998) is collected, to understand the future environment of the new system, by analyzing the work or the tasks, their frequency and criticality, the cognitive abilities of the user and the users’ collaborators. The scope of the information collected varies depending on the problem, and sometimes it is necessary to gather data about the regulatory, social, and organizational contexts of the problem (Jackson, 1995) to be solved. The temporal and spatial contexts describe when the work should be carried out and where. On the other hand, software engineers have specified requirements in several different modelling languages that range from semiformal to formal. Examples of semiformal languages are UML (Larman, 2002), SADT, and IDEF (Ross, 1985). Examples of the latter are Z (Potter, Sinclair, &amp; Till, 1996), VDM or ASM. Those are modelling languages for software development, but some languages or methods focus on task or work modelling such as Concurrent Task Trees (Paterno, 2003) and Cognitive Work Analysis (Vicente, 1999). Others emphasize more the specification method than a modelling language. Examples of the former are Scenario-Based Design (SBD) (Rosson &amp; Carroll, 2002) and Contextual Design (Beyer &amp; Holtzblatt, 1998). In practice, many software developers use informal methods to express requirements in text, e.g., as narrations or stories. Agile Development Methods (Abrahamsson, Warsta, Siponen, &amp; Ronkainen, 2003) emphasize this approach and thereby are consistent with their aim of de-emphasizing methods, processes, and languages in favor of getting things to work. A popular approach to requirements elicitation is developing prototypes. There has been less emphasis on bridging the gap between the above two efforts, for example, to deliver a method that gives practical guidelines on how to produce specifications from qualitative data (Hertzum, 2003). One reason for this gap can be that people from different disciplines work on the two aspects, for example, domain analysts or experts in HCI, and software engineers who read and use requirements specification as a basis for design. Another reason for this gap may be in the difference in the methods that the two sides have employed, that is, soft methods (i.e., informal) for elicitation and analysis and hard methods (i.e., formal) for specification. In this article, we suggest a method to translate qualitative data to requirements specification that we have applied in the development of a Smart Space for Learning. The process borrows ideas from or uses scenarios, interviews, feature-based development, soft systems methodology, claims analysis, phenomenology, and UML.

The European ECSS-E-40 series of standards for the aerospace industry includes interfaces as one of 16 types of non functional requirement (NFR) for embedded and real-time software. An interface is typically described at the system level as a non functional requirement, and a number of concepts and terms are provided in that series to describe various types of candidate interfaces. This paper collects and organizes these interface-related descriptions into a generic model for the specification of software interface requirements, and to measure their functional size for estimation purposes using the COSMIC ISO 19761 standard.

Providentia: Using search-based heuristics to optimize satisficement and competing concerns between functional and non-functional objectives in self-adaptive systems

Testing of product is perform to discover or detect the errors and defects in the developed system. But testing is usually time consuming especially when complex projects are canvass. Testing of a product lead off with generation of test cases. The Test case generation are based on three parts coding, design and specification. The Specification based testing deals with generation of test cases from the functional requirements. The proposed system deals with automatic generation of test cases from functional requirement using Natural Language Processing (NLP). The proposed system constructs test cases based on keywords in context from functional requirement of Software Requirement Specification document. The proposed system is beneficial as it can automatically analyze the functional requirement from Software Requirement Specification in order to extract test cases for testing. The goal of the proposed system is to reduce effort and time consumed by software tester to test the product.

As in traditional software development, non-functional requirements play also a crucial role in service-oriented development. Non-functional requirements are spread across the entire service-oriented system or within individual services and cannot be allocated to one specific system / service artefact (such as a package, component). This makes them often more difficult to handle than functional requirements. The specifics of service-oriented architectures (in particular highly distributed services) bring up additional difficulties. In this paper, we present a taxonomy for non-functional requirements in a service-oriented context. The taxonomy implements three main categories of non-functional requirements: process requirements, non-functional external requirements, and non-functional service requirements. The taxonomy can be applied with individual services as well as with a service-based system as a whole. This taxonomy is considered as a starting point and check list when handling non-functional issues in service-oriented and particularly highly distributed environments.

One of the primary responsibilities of requirement engineer is the elicitation of non-functional and functional requirements. Functional requirements sketch out the functionality, the system has to be performed while non-functional requirements compel the restrictions on this functionality. Software industry is raising its demand for not only the required functionality but the necessity of non-functional requirements too such as performance, security, usability, security, privacy etc. The current practice in the industry is to deal with functional requirements as first class requirements while non-functional requirements are only catered at design and implementation level. This approach leaves a serious flaw in the system design towards user satisfaction and often results in the failure of projects such as the classic example of London Ambulance System[1]. The chances of software success can be maximized when dealing with NFR at the requirements level. This literature survey is a first effort of its kind to seek key NFR challenges and issues while elicitation level of requirement engineering. It also find-outs the approaches and methods that are suggested in literature to deal with these issues.

It is not feasible to engineer requirements for adaptable and open service-oriented systems (AOSS) by specifying stakeholders’ expectations in detail during system development. Openness and adaptability allow new services to appear at runtime so that ways in, and degrees to which the initial functional and nonfunctional requirements will be satisfied may vary at runtime. To remain relevant after deployment, the initial requirements specification ought to be continually updated to reflect such variation. Depending on the frequency of updates, this paper separates the requirements engineering (RE) of AOSS onto the RE for: individual services (Service RE), service coordination mechanisms (Coordination RE), and quality parameters and constraints guiding service composition (Client RE). To assist existing RE methodologies in dealing with Client RE, the Dynamic Requirements Adaptation Method (DRAM) is proposed. DRAM updates a requirements specification at runtime to reflect change due to adaptability and openness.

Software requirements analysis is crucial for any software project and it is the basis of requirements reuse within Software Product Line engineering. Software requirements specifications are usually expressed in natural language, which are informal, imprecise and ambiguous, thus analyzing them automatically is a challenging task. Although methods towards automatic analysis of software requirements have been studied before, many of them have limitations and effective researches in this area are still lacking. Therefore, in this paper a new approach was proposed to automatically extract structured information of functional requirements from Software Requirements Specifications in natural language. The methods of machine learning, natural language processing and semantic analysis were employed and combined in this approach. With a 10-fold cross validation setting, the method was evaluated on a manually annotated corpus. The experiments show that this approach achieves a good performance. Moreover, it was found that the model trained on the requirements dataset of the E-commerce systems, can be used to extract semantic information from the requirements of auto-maker systems. The cross-domain extraction results show that the method of this paper is domain independent and robust to some extent.

Requirements Engineering (RE) is the area of softwa re engineering that deals with the discovery and specification of the objectives for the system unde r development and the environment in which it is us ed including the human activities it supports. Require ment Elicitation is process of gathering requiremen ts from stakeholders. Incorporating RE to identify non Functional Requirements (NFR) in early stages of design and implementation avoids ambiguities, confl icting requirement and other defects. The efficacy of the requirement engineering methodology is its abil ity to capture NFR in an efficient manner. In this study, we propose a novel method of elicitation using mobi le multimedia and to automatically trace the NFR. T he requirements description is captured in video using smart phones. Requirement document are prepared using voice to text converter. NFR is detected auto matically from the requirement document and hand gestures emphasise the importance of the requirement. It is observed that the precision and recall of the class ifiers is better using multimedia data. Features were extract ed from video frame and audio using image processing technique and speech processing. We investigated data mining approach to identify Non Functional Requirements (NFR) from Functional Requirement (FR) Documents. Results obtained were satisfactory.