Requirements Analysts Research Articles

Identifying the implied: Findings from three differentiated replications on the use of security requirements templates

Identifying security requirements early on can lay the foundation for secure software development. Security requirements are often implied by existing functional requirements but are mostly left unspecified. The Security Discoverer (SD) process automatically identifies security implications of individual requirements sentences and suggests applicable security requirements templates. The objective of this research is to support requirements analysts in identifying security requirements by automating the suggestion of security requirements templates that are implied by existing functional requirements. We conducted a controlled experiment in a graduate-level security class at North Carolina State University (NCSU) to evaluate the SD process in eliciting implied security requirements in 2014. We have subsequently conducted three differentiated replications to evaluate the generalizability and applicability of the initial findings. The replications were conducted across three countries at the University of Trento, NCSU, and the University of Costa Rica. We evaluated the responses of the 205 total participants in terms of quality, coverage, relevance and efficiency. We also develop shared insights regarding the impact of context factors such as time, motivation and support, on the study outcomes and provide lessons learned in conducting the replications. Treatment group, using the SD process, performed significantly better than the control group (at p-value <0.05) in terms of the coverage of the identified security requirements and efficiency of the requirements elicitation process in two of the three replications, supporting the findings of the original study. Participants in the treatment group identified 84 % more security requirements in the oracle as compared to the control group on average. Overall, 80 % of the 111 participants in the treatment group were favorable towards the use of templates in identifying security requirements. Our qualitative findings indicate that participants may be able to differentiate between relevant and extraneous templates suggestions and be more inclined to fill in the templates with additional support. Security requirements templates capture the security knowledge of multiple experts and can support the security requirements elicitation process when automatically suggested, making the implied security requirements more evident. However, individual participants may still miss out on identifying a number of security requirements due to empirical constraints as well as potential limitations on knowledge and security expertise.

Sensitivity Analysis of the i* Optimisation Model

Requirement elicitation is an important activity in early requirement engineering. Several well- known approaches and goal models have been developed to deal with requirement elicitation. The i* goal model is used to represent the socio-technical domains and can be used for analysis in early requirement analysis. The elicitation process is complicated by the incomplete and imprecise input data available for analysis. Imprecise and unavailable data can be captured by fuzzy logic and then it can be managed by the popular operation research techniques known as optimisation. This paper presents a formal multi- objective optimisation model, for the i* framework, with regard to requirement elicitation. The optimisation model has the capacity to handle large and complex systems. The optimisation model has been expanded to include sensitivity analysis, in order to facilitate useful information on input data for the requirement analyst. The proposed approach is explained using the London Ambulance System case study and is evaluated using a simulation based analysis.

유스케이스 점수 측정의 신뢰도 향상을 위한 단위기능 중심의 유스케이스 정제 방법

Use The Use Case Points method is a software estimation method that is based on user requirements. When requirement analysts elicit user requirements, they obtain different use cases because different levels of detail are possible for the Use Case, and this affects the Use Case Points. In this paper, we suggest a method to refine the level of detail of the Use Case by using the concept of an elementary function. This refinement method achieves the desired reliability for the Use Case Points because it produces less of a deviation in the Use Case Points for different requirement analysts than other methods that are based on the step, transaction, and narrative of the Use Case.

Classification of NFRs for Information System

Software requirements are broadly classified into two parts, i.e., functional requirements (FR) and non-functional requirements (NFRs). In recent year, NFRs have received much attention by requirements engineering community. This can be verified from the importance of the NFR framework. This framework was developed to elicit and model only the NFRs. There are different NFRs for different types of system like information system, web based system, real time system etc. Elicitation of NFRs for these types of systems is an important research issue. Therefore, the objective of this paper is to classify various NFRs for Information System so that requirements analyst can easily identify the complete list of NFRs according to their need in early phase of requirements engineering.

Sistem Informasi Manajemen Surat pada Dinas Pendapatan, Pengelolaan Keuangan dan Aset Daerah Kabupaten Pati

Abstract - Documents handling at Dinas Pendapatan, Pengelolaan Keuangan dan Aset Daerah Kabupaten Pati was done manually and was not computerized. Because of that, it is needed to build documents management information system to automate the document control activity at department include the function of documents recording, documents making, and documents tracking. For gaining the purpose, a research must be done. That research used Framework for Application System Thinking (FAST) with eight phase, that is scope definition, problem analyst, requirement analyst, logical design, decision analyst, physical design and integration, construction and testing, and also installation and delivery. This research was implemented by using PHP, HTML, and Javascript as programming language and MySQL as database. System testing was done by using black box testing method.The result from this research is documents management information system.

Detecting defects in software requirements specification

This research is concerned with detecting defects in software requirements specification. Motivated by both the problem of producing reliable requirements and the limitations of existing taxonomies to provide a satisfactory level of information about defects in the requirements phase, we focus on providing a better tool for requirements analysts. Only few attempts have been made to classify defects and defect detection techniques. Scattered knowledge about defects and defect detection techniques needs compilation and re-evaluation in order to enhance the ability to discover defects in the requirements phase. Toward this end, this work presents a taxonomy of requirements defects and the causes of their occurrences. The purpose is to reach a comprehensive understanding of both the sources of the problem and the solutions of possible defects and defect detection techniques. The taxonomy’s design is based on the analysis of each defect and its sources. In addition, this paper proposes a combined-reading technique for defects in requirements. The proposed technique avoids the shortcomings of other reading techniques. The result of applying the recommendations of this work specifically improves the quality of the requirements specification and generally software quality.

Requirement Engineering Errors: Errors and Ambiguities of Visualization

Engineering encompasses the tasks that go into identifying, determining and understanding the customer needs as well as the expectations from the proposed software system or an application, taking account of possibly conflicting requirements of various stakeholders. Engineering, also referred to by names like requirement gathering or requirement analysis or requirement specification, is a well-defined stage in the software development life cycle. This stage is not only well defined but also very crucial to the success of software development. Most of the project failures have been attributed to this stage only. Its a general and very often heard statement: were not clear or Requirements were ambiguous. So, what does this word Requirement is all about, those requirement analysts try to establish and still, most of the projects fail due to lack of clarity in requirements. Requirements describe the behavior of the proposed software system but the roots of the same lie in the original real-time system for which software system has been proposed. Requirements engineering, in this manner, encompasses both the problem domain of the system as well as the solution domain of the system. The process of establishing the requirements is not an easy task as it is crossing over the boundaries of problem and the solution domain on a regular basis, and is bound to have errors. Errors in requirement engineering stage have many sources, ambiguous and unclear requirements are only a part of the problem. Having explored a number of common types of errors to find their source and strategies for dealing with them, Kurt Bittner (1) categorized requirement errors into three major groups: Errors of conceptualization (the ones that arise because of poorly conceived problem); Errors of specification (the ones that arise because of poor specification) and Error of implementation (the ones that arise because of poor coding and testing). This paper is an attempt to put forward an idea of one more category of requirement errors: Errors of visualization. The difference between errors of conceptualization and error of visualization though apparently seems vague but is as clear as the boundaries between problem and the solution domain. The paper attempts to study the differences between these two types of errors and also studies the symptoms and possible solution strategies for errors of visualization.

Defining and Validating a Feature-Driven Requirements Engineering Approach

The specification of requirements is a key activity for achieving the goals of any software project and it has long been established and recognized by researchers and practitioners. Within Software Product Lines (SPL), this activity is even more critical owing to the need to deal with common, variable, and product-specific requirements, not only for a single product but for the whole set of products. In this paper, we present a Feature-Driven Requirements Engineering approach (FeDRE) that provides support to the requirements specification of SPL. The approach realizes features into functional requirements by considering the variability captured in a feature model. It also provides detailed guidelines on how to associate chunks of features from a feature model and to consider them as the context for the Use Case specification. The evaluation of the approach is illustrated in a case study for developing an SPL of mobile applications for emergency notifications. This case study was applied within 14 subjects, 8 subjects from Universitat Politecnica de Valencia and 6 subjects from Federal University of Bahia. Evaluations concerning the perceived ease of use, perceived usefulness, effectiveness and efficiency as regards requirements analysts using the approach are also presented. The results show that FeDRE was perceived as easy to learn and useful by the participants.

Structured Language Requirement Elicitation Using Case Base Reasoning

Requirement elicitation is very difficult process in highly challenging and business based software as well as in real time software. Common problems associated with these types of software are rapidly changing the requirements and understanding the language of the layman person. In this study, a framework for requirement elicitation by using knowledge based system is proposed, which is very helpful for knowledge documentation, intelligent decision support, self-learning and more specifically it is very helpful for case based reasoning and explanation. Basically in this method requirements are gathered from Artificial Intelligence (AI) expert system from various sources e.g., via interviews, scenarios or use cases. Then, these are converted into structured natural language using ontology and this new problem/case is put forward to Case Based Reasoning (CBR). CBR based on its previous information having similar requirements combines with new case and suggests a proposed solution. Based on this solution a prototype is developed and delivered to customer. The use of case-based reasoning in requirements elicitation process has greatly reduced the burden and saved time of requirement analyst and results in an effective solution for handling complex or vague requirements during the elicitation process.

Viewpoint–participation–technique: A model of participative requirements elicitation

Requirements elicitation is an early phase process in systems development that captures user needs and represents them as a set of requirements. In view of increasing demand for products and services that target mass markets, requirements analysts have begun emphasising the need for participation of end users and customers during elicitation. This article proposes the viewpoint–participation–technique model of requirements elicitation that integrates functions for strategizing elicitation participation and selecting elicitation techniques. A step-by-step approach to using the viewpoint–participation–technique model is then presented, and the model is illustrated through a case study of the elicitation process for an interlibrary loan service. The article also discusses some applications and limitations of the viewpoint–participation–technique model and concludes by identifying possible future research directions.

Editorial

Editorial

A requirements data model for product service systems

Product service systems (PSS) are bundles of physical technological elements and service elements that are integrated to solve customer problems. In practice, most components of PSS are developed independently from each other, which leads to problems with coordination of development activities and integration of PSS components. Therefore, an integrated requirements engineering for PSS is needed that deals with the involvement of developers from product engineering, software engineering, and service engineering, as well as the inherent complexity of the PSS and the development process. In a case study with the development department of a PSS provider, we analyzed requirements documents and conducted expert interviews. We identified problems in the development, for example, that requirements on different levels of abstraction are intermingled, rationales for requirements are missing, and the concretization of requirements is unclear. To solve these problems, we propose a requirements data model (RDMod) for requirements to PSS. An RDMod describes different types of requirements and the relations between them. Thus, it is a scheme for the concretization of the requirements, which especially addresses the problems of structuring the requirements, enabling traceability, and finding conflicts. We then used an analytical evaluation, a feature-based evaluation and a retrospective application with requirements analysts of the industry partner. In a joint workshop, we specified requirements for a PSS with the RDMod. In structured interviews, we analyzed the perceived advantages of the RDMod. The experts confirmed that the RDMod is applicable in their development and it provides a clear structure for the requirements and therefore helps overcoming the identified problems.

Generating UML Diagrams from Natural Language Specifications

The process of generating UML Diagrams from natural language specification is a highly challenging task. This paper proposes a method and tool to facilitate the requirements analysis process and extract UML diagrams from textual requirements using natural language processing (NLP) and Domain Ontology techniques. Requirements engineers analyze requirements manually to understand the scope of the system. The time spent on the analysis and the low quality of human analysis justifies the need of a tool for better understanding of the system. “Requirement analysis to Provide Instant Diagrams (RAPID)” is a desktop tool to assist requirements analysts and Software Engineering students to analyze textual requirements, finding core concepts and its relationships, and extraction UML diagrams. The evaluation of RAPID system is in the process and will be conducted through two forms of evaluation, experimental and expert evaluation.

A study of methods for textual satisfaction assessment

Software projects requiring satisfaction assessment are often large scale systems containing hundreds of requirements and design elements. These projects may exist within a high assurance domain where human lives and millions of dollars are at stake. Satisfaction assessment can help identify unsatisfied requirements early in the software development lifecycle, when issues can be corrected with less impact and lower cost. Manual satisfaction assessment is expensive both in terms of human effort and project cost. Automated satisfaction assessment assists requirements analysts during the satisfaction assessment process to more quickly determine satisfied requirements and to reduce the satisfaction assessment search space. This paper introduces two new automated satisfaction assessment techniques and empirically demonstrates their effectiveness, as well as validates two previously existing automated satisfaction assessment techniques. Validation shows that automatically generated satisfaction assessments have high accuracy, thus reducing the workload of the analyst in the satisfaction assessment process.

Towards a competency model for requirements analysts

AbstractRequirements engineering is a software development discipline, executed by requirements analysts (RAs), that includes requirements elicitation, analysis, specification and validation. Its successful outcome is very often essential to overall project success. However, there is a lack of systematically conducted empirical research on the competencies of RAs. This paper addressed this gap by conducting 64 interviews at eight major North American and European financial services companies. Our qualitative research design follows an interpretive approach and uses critical incident technique. We develop a competency model, which specifies 16 critical competencies, and integrates contextual and situational factors as well as results variables. ‘Consulting others’, ‘Testing assumptions and investigating’ and ‘Explaining concepts and opinions’ were the most frequently identified competencies. This indicates that for an effective analyst, close interaction and communication with customers is indeed crucial – but of equally importance is the critical questioning of the expressed needs. Surprisingly, applying specific tools and advanced techniques did not seem to play a significant role from the interviewees' perspective. This study contributes to theory as it is the first to elaborate a competency model for RAs. It also provides a foundation for the development of competency‐based training in companies and universities.

Impacting Student Perceptions about Careers in Information Systems

A shortage of graduates prepared to fill the available jobs in Information Systems remains. Previous studies have verified the shortage and attempted to explain why students do not major in Information Technology related fields. Since prior studies identified lack of awareness regarding the discipline as a major reason in ignoring the major, the purpose of this study is to determine if reading an article about the work of a requirements analyst would positively impact the perceptions of student respondents about careers in Information Systems. It was found that perceptions about careers in Information Systems related fields can be improved by exposing students to the work-life activities of Information Systems professionals. Using a pretest/posttest experimental design, perceptions regarding careers in IS were collected before and after students read Karl Wiegers’ article “So You Want to be a Requirements Analyst?” Posttest findings indicate statistically significant positive changes in participant’s perceptions about careers in Information Systems related fields, especially related to Systems Analysts roles.

What Time Is It, Eccles?

Requirements analysts need a new toolbox with both the right tools and the instructions to use them including agile development and user-centered design for techniques such as analysis of Web analytics, wire-framing, and user stories. We can also look to the creativity literature and take techniques such as constraint removal, storytelling, and other worlds.

Natural language based component extraction from requirement engineering document and its complexity analysis

Requirement engineering document (IEEE-830: 1998) plays a very significant role in software development. The size and complexity of software systems are continuously increasing. As scale changes to more complex and larger systems, new problems occur that did not exist in smaller systems This leads to redefining priorities of the activities that go into developing software. As systems ges complex, it becomes evident that the goals of the entire system can't be easily comprehended. Hence the need of more rigorous requirement analysis arises. The requirement analyst has to identify the requirements by using various methods like interviews, brainstorming, FAST (facilitated application specification techniques), quality function deployment, use-case etc. To overcome these issues, this paper proposes object based semi-automated system that categorize the requirements and further identifies the component based on requirement engineering document in a component library and further analyses the complexity of components and its usage.

Modeling of Component Diagrams Using Petri Nets

With the growing use of UML diagrams for software architecture description and the importance of non-functional requirements evaluation at software architecture level, filling the scientific gap between architect and requirement analyst is considered to be significant. Software architects are not usually familiar with non-functional requirement analysis and are not able to analyze such requirements easily. On the other hand, non-functional requirements cannot be evaluated directly by UML diagrams. Therefore, the architect should annotate additional information of the nonfunctional requirements to software architecture description and then an executable model can be produced. These executable models can be petri nets, queuing networks, stochastic process algebra and etc. One kind of the UML diagrams that can be used to describe software architecture is component diagram. In this paper, we propose a new algorithm that enables an architect to transform a component diagram into an executable model based on different extensions of petri nets. Moreover, we show how to use this petri net model for performance evaluation and simulation and the implications of this transformation are described completely. Finally, to represent the usage of our proposed algorithm, we consider a case study as an example.

Software Functional Testing from the Perspective of Business Practice

Industrial firms build their respective value chains by purchasing and tailoring core software to their specific business scenarios. Software functional testing is an indispensible element in the software implementation cycle. To achieve the two major aims of the functional testing, namely effectiveness and economics, business specialist, requirements analysts and the testing team should work together closely. To perform the functional testing, business requirements must be extracted and a number of recommended black-box testing methodologies should be used. Successful testing activities should enlist the support from test plans and test tools.