Software Project Requirements Research Articles

A case study on the development of requirements for the comprehensive credits management system project at H University

Nowadays, in order to adapt to informatization and enhance management efficiency, universities have an increasing demand for the development of management systems. This paper conducts an in-depth study on the case of requirements development for the comprehensive credit management system project at H University. Taking the problems existing in software project requirements development management as a starting point, this paper analyzes and researches the issues in requirements acquisition, requirements analysis, and requirements development management processes of the current project development team through the study of relevant theoretical content on requirements development. The paper proposes solutions to problems such as inaccurate identification of software project stakeholders, lack of scientific requirements analysis tools, and absence of prioritization in requirements. Through analysis, this paper, by drawing stakeholder maps and utilizing the KANO model for prioritizing project requirements, ultimately formulates an effective requirements development management solution tailored to the software project of the development team for this particular project.

A Novel Software Quality Characteristic Recommendation Model to Handle the Dynamic Requirements of Software Projects that Improves Service Quality and Cost

A Novel Software Quality Characteristic Recommendation Model to Handle the Dynamic Requirements of Software Projects that Improves Service Quality and Cost

A classification approach for software requirements towards maintainable security

As trends continue to move toward the introduction of intelligent methods to automate software engineering processes, security requirements classification is rapidly turning into a highly potent field for the software engineering community. There are several models for classifying security requirements proposed in the literature. However, their adoption and use is constrained by the absence of substantial datasets to allow for the replication and generalization of studies, using more advanced machine-learning techniques. Furthermore, most researchers in this area, consider Maintainability as purely a non-functional requirement with no relation to security. This has been identified to be a major source of security concerns. The main objective of this study is to propose a software requirements classification approach that considers maintainability as a security requirement. This seeks to ensure that maintenance efforts don't lead to new software vulnerabilities that were previously not present during deployment. A mixed research methodology is adopted as qualitative data is collected from students’ project documentation, labelled, and transformed into quantitative form during analysis. As a culmination of this process, a validated original publicly accessible, labelled software requirements dataset of student software project requirements (DOSSPRE) is obtained and presented to support the approach. It contains 1317 software requirements, including security requirements, functional requirements, and other non-functional requirements. Two versions of the dataset are presented: one for binary classification of security requirements vs. non-security requirements and the other for multi-class classification tasks with various more granular security requirements vs. non-security requirements. In both instances, well-known machine learning algorithms are used to verify the dataset. Support Vector Machine (SVM) and Logistic Regression were the top performers in multi-class classification with an average Accuracy of 86% in both cases. Multinomial Nave Bayes topped the other machine learning techniques in binary classification with 91% Precision, 69% Recall, 78% F1-Score, and Accuracy of 86%. The dataset is accessible on this link https://data.mendeley.com/datasets/23xtbvk6yp/1

Review of requirements in software projects

بررسی نیازمندی‌ها در پروسۀ ساخت پروژه‌های نرم‌افزاری، ‌برای تشخیص و توضیح نیازهای ‌مشتری است، که میان دو فرد و یا گروه، که یکی مشکلاتی دارد و گروهی که در پی حل این مشکل، از طریق ساخت یک سیستم منظم است. استخراج نیازمندی‌ها، گاهی می‌تواند پروسه‌یی بسیار مشکل باشد. کم‌اهمیت قلم‌داد‌کردن استخراج نیازمندی‌ها ممکن است در مراحل پایانی ساخت و توسعۀ سیستم‌های نرم‌افزاری ‌بسیار پُر‌هزینه باشد و باعث اخلال در ایجاد سیستم گردد، و تحلیل‌گر را در این زمینه با مشکلات و موانع بسیاری مواجه سازد؛ لذا با‌توجه به این‌که جمع‌‌آوری نیازمندی‌ها اساس و پایة ساخت سیستم‌ها را تشکیل می‌دهد، می‌تواند امری فوق‌العاده مهم در این راستا به‌شمار بیاید؛ پس باید این پروسه به‌صورت درست و بر اساس واقعیت‌های اجتماعی به انجام برسد؛ بدین‌منظور، این پژوهش کتاب‌خانه‌یی با‌هدف نقد و بررسی چالش‌های جمع‌آوری نیازمندی‌ها، به‌خصوص در پروژه‌هایی‌ که در جغرافیای افغانستان انجام می‌شود، شکل گرفته است. پرسشی که در این پژوهش به دنبال پاسخ‌یابی به آن بوده‌ایم‌، این بوده است که‌: آیا می‌توان روش‌های امروزی جمع‌آوری نیازمندی‌ها را در ‌افغانستان با مختصات منحصر‌به‌فرد آن استفاده کرد یا خیر؟ یافته‌های پژوهش نشان می‌دهند که‌: جمع‌آوری نیازمندی‌ها نظر به جغرافیاها و فرهنگ یک ملت متفاوت، می‌تواند متفاوت باشد. به صورت کلی‌، جمع‌آوری نیازمندی‌ها، یک پروسۀ کاملاً وابسته به شرایط یک منطقۀ جغرافیایی است.

A MODEL OF CONSEQUENCES OF AMBIGUOUS REQUIREMENTS

A key objective in the requirements elicitation process is to ensure a common understanding of requirements between customers and users and software developers from the other. The traditional practices for preventing ambiguous requirements focused on writing requirements clearly without guidelines that help practitioners elicit requirements from customers and users unambiguously. Since multiple studies underlined the prevalence of ambiguous requirements in software projects, the key purpose of this article is to construct a conceptual model of the consequences of ambiguous requirements. The novelty of this model manifests itself in explaining the possible negative effects resultant from eliciting ambiguous requirements from customers and users across software development processes. Accordingly, this model can increase the awareness of practitioners' and academicians' potential threat of ambiguous requirements and act as a trigger to find the guidelines to prevent ambiguous requirements during requirements elicitation.

On the fulfillment of coordination requirements in open-source software projects: An exploratory study

In large-scale open-source software projects, where developers are often distributed across the entire planet, coordination among developers is crucial. To estimate whether a state of socio-technical congruence is achieved, which is associated with software quality and project success, we assess the alignment of collaboration and communication in such software projects in terms of coordination requirements. By means of an empirical study on a substantial set of large-scale open-source software projects—the development histories of all projects sum up to over 180 years—we aim at shedding light on this issue. To this end, to take a more semantic view on this phenomenon in comparison to previous work, we do not only identify coordination requirements arising from files and functions only, but also those arising from features. We found that open-source developers fulfill coordination requirements intentionally, but mostly those coordination requirements that arise from coupled source-code artifacts, while they resolve simpler ones independently. Furthermore, neither of the considered abstraction levels of source-code artifacts (files, functions, features) is more suitable to construct coordination requirements with respect to their fulfillment. This finding strongly indicates that features do not play an as important role in the development process as expected and commonly believed by the research community in the area of feature-oriented and feature-driven development. Finally, we identified notable evolutionary trends in the fulfillment of coordination requirements and showed that far-reaching social events (such as organizational issues) have a huge impact on their fulfillment, both negatively and positively. The key findings of our empirical study are that socio-technical relations are important to understand open-source development communities and that the incorporation of different abstraction levels for developer collaboration does yield important insights to further improve the evolution in open-source software projects.

A fuzzy framework for prioritization and partial selection of security requirements in software projects

Resource limitations in software projects rarely allow for the security requirements to be fully realized. As such, Prioritization and Selection (PAS) techniques are used to find an optimal subset of the requirements. Consequently, some of the secur

Dealing with Non-Functional Requirements in Model-Driven Development: A Survey

Context: Managing Non-Functional Requirements (NFRs) in software projects is challenging, and projects that adopt Model-Driven Development (MDD) are no exception. Although several methods and techniques have been proposed to face this challenge, there is still little evidence on how NFRs are handled in MDD by practitioners. Knowing more about the state of the practice may help researchers to steer their research and practitioners to improve their daily work. Objective: In this paper, we present our findings from an interview-based survey conducted with practitioners working in 18 different companies from 6 European countries. From a practitioner's point of view, the paper shows what barriers and benefits the management of NFRs as part of the MDD process can bring to companies, how NFRs are supported by MDD approaches, and which strategies are followed when (some) types of NFRs are not supported by MDD approaches. Results: Our study shows that practitioners perceive MDD adoption as a complex process with little to no tool support for NFRs, reporting productivity and maintainability as the types of NFRs expected to be supported when MDD is adopted. But in general, companies adapt MDD to deal with NFRs. When NFRs are not supported, the generated code is sometimes changed manually, thus compromising the maintainability of the software developed. However, the interviewed practitioners claim that the benefits of using MDD outweight the extra effort required by these manual adaptations. Conclusion: Overall, the results indicate that it is important for practitioners to handle `NFRs in MDD, but further research is necessary in order to lower the barrier for supporting a broad spectrum of NFRs with MDD. Still, much conceptual and tool implementation work seems to be necessary to lower the barrier of integrating the broad spectrum of NFRs in practice.

Requirements Prioritization Techniques Comparison

Requirements prioritization is considered as one of the most important approaches in the requirement engineering process. Requirements prioritization is used to define the ordering or schedule for executing requirement based on their priority or importance with respect to stakeholders’ viewpoints. Many prioritization techniques for requirement have been proposed by researchers, and there is no single technique can be used for all projects types. In this paper we give an overview of the requirement process and requirement prioritization concept. We also present the most popular techniques used to prioritize the software project requirements and a compression between these techniques. On the other hand, we spot the light on the importance of involving the non-functional requirements prioritization because of the great effects of non-functional on project success and quality; some approaches that used in prioritize non-functional requirements are discussed in this paper, in addition a general model is proposed based on reviewing the prioritization techniques in order to suggests a best suited technique for specific projects according to decision makers parameters.

Scatter search for trainees to software project requirements stable allocation

In this paper, we study a centralized, stable matching scheme, which allocates trainees to software project requirements, to minimize retraining and relocation costs when the preference lists of the project requirements may contain ties of arbitrary lengths. This particular trainees' assignment problem is important because the allocation decisions not only influence the costs but also impact software project deliverables and intern attrition rates. It is also an NP-hard problem because of the inclusion of the ties, and the costs in the stable allocation model. We, therefore, have designed a GRASP-based scatter search method, to solve the large size instances of our assignment problem efficiently. The GRASP method uses randomized algorithms to generate initial trial solutions. A repair heuristic based on regret minimization idea is designed to convert an unstable solution to a stable solution during an improvement phase. Computational experiments suggest that the proposed algorithm significantly reduces run time compared to the CPLEX, and produces solutions that are at an average 4.5% away from the best CPLEX solutions for the large size problem instances. Moreover, our scatter search method consistently provides better quality solutions than the two state of the art methods from the prior literature.

A comparative analysis between two techniques for the prediction of software defects: fuzzy and statistical linear regression

Software engineers should estimate the necessary resources (time, people, software tools among others) to satisfy software project requirements; this activity is carried out in the planning phase. The estimated time for developing software projects is a necessary element to establish the cost of software projects and to assign human resources to every phase of software projects. Most companies fail to finish software projects on time because of a poor estimation technique or the lack of the same. The estimated time must consider the time spent eliminating software defects injected during each of the software phases. A comparative analysis between two techniques (fuzzy linear regression and statistical linear regression) to perform software defect estimation is presented. These two techniques model uncertainty in a different way; statistical linear regression models uncertainty as randomness, whereas fuzzy linear regression models uncertainty as fuzziness. The main objective of this paper was to establish the kind of uncertainty associated with software defect prediction and to contrast these two prediction techniques. The KC1 NASA data set was used to do this analysis. Only six of the metrics included in KC1 data set and lines of code metric were used in this comparative analysis. Descriptive statistics was first used to have an overview of the main characteristics of the data set used in this research. Linearity property between predictor variables and the variable of interest number of defects was checked using scatter plots and Pearson's correlation coefficient. Then the problem of multicollinearity was verified using inter-correlations among metrics and the variance inflation factor. Best subset regression was applied to detect the most influencing subset of predictor variables; this subset was later used to build fuzzy and statistical regression models. Linearity property between metrics and number of defects was confirmed. The problem of multicollinearity was not detected in the predictor variables. Best subset regression found that the subset composed of 5 variables was the most influencing subset. The analysis showed that the statistical regression model in general outperformed the fuzzy regression model. Techniques for making software defect prediction should be carefully employed in order to have quality plans. Software engineers should consider and understand a set of prediction techniques and know their weaknesses and strengths. At least, in the KC1 data set, the uncertainty in the software defect prediction model is due to randomness so it is reasonable to use statistical linear regression instead of fuzzy linear regression to build a prediction model.

Assignment of trainees to software project requirements: A stable matching based approach

Greedy and optimization approaches used for assigning trainees to software project requirements can give rise to unstable pairs. The presence of unstable pairs can unnecessarily hamper both trainee and project requirement satisfaction. In this paper, we use the theory of stable matching to remove the unstable pairs. We propose an efficient method to predict preferences for both trainees and project requirements using the utility theory. Our computational experiments suggest that the stable matching approach performs better with average trainee and project requirement satisfaction in terms of the preference ranks of allocated choices. Compared to cost based optimization model, the proposed approach obtains significantly better trainee project match at the expense of small additional allocation cost.

Mastering Software Project Requirements: A Framework for Successful Planning, Development & Alignment

Mastering Software Project Requirements: A Framework for Successful Planning, Development & Alignment

Design and Implementation of the Software Testing Management System Based on Django

As the complexity and reliability requirements of software projects increase constantly, software testing is becoming more and more prominent and important in software engineering. Testing management system is the basis of constructing software testing management system. It regulates software testing processes, and ensures the entire testing process is under control. Based on the Django framework, this paper design and implement a test management system based on B/S architecture. It can operate as a common platform for software testing management, and reduce the cost and cycle of software testing, guarantee the quality and efficiency of software testing.

An Empirical Study of the Software Project Requirements Engineering Practice in Malaysia Public Sector – A Perspective from the Stakeholders’ Challenges

Stakeholder is one of the software success factors for software project in Malaysia Public Sector. The stakeholders are defined as person who are close to the business process and really know what the requirements needed. Requirement is an important factor for the development of any project and it defines what different stakeholders (users, customer, manager and developer) need and how system will fulfil these needs. They are the main actors in the business process. Requirements are used as input in the design, implementation and validation stage of product development. Eventually, a software project can succeed or failed at any time during project life cycle because of poor requirement gathering and managing process. Among the key problems of information systems requirements process is the gap between analysts and stakeholders. Therefore, this paper describes the empirical study performed in public sectors in Malaysia to identify the challenges and problems arising from the stakeholders.

Prioritisation of software requirements using grey relational analysis

While many efforts have been undertaken to prioritise requirements in software projects, almost none has shown practical methods to do so. Most methods that produce consistent results tend to be complex and consequently difficult to implement. On the other hand, informal methods can save time and are easy to implement, but lack the structure and consistency needed to reliably analyse requirements. This paper introduces a new approach for prioritising software requirements. Because of the imprecise nature of requirement and attribute data, this approach represents the problem as a grey multi-attribute decision problem by relying on grey relational analysis to address this decision problem. In addition, the approach allows decision makers to use an objective or subjective weighting scheme to model the importance of attributes before solving the decision problem. This approach is practical and can be easily implemented as a decision making tool to assist decision makers in prioritising requirements.

StakeRare: Using Social Networks and Collaborative Filtering for Large-Scale Requirements Elicitation

Requirements elicitation is the software engineering activity in which stakeholder needs are understood. It involves identifying and prioritizing requirements-a process difficult to scale to large software projects with many stakeholders. This paper proposes StakeRare, a novel method that uses social networks and collaborative filtering to identify and prioritize requirements in large software projects. StakeRare identifies stakeholders and asks them to recommend other stakeholders and stakeholder roles, builds a social network with stakeholders as nodes and their recommendations as links, and prioritizes stakeholders using a variety of social network measures to determine their project influence. It then asks the stakeholders to rate an initial list of requirements, recommends other relevant requirements to them using collaborative filtering, and prioritizes their requirements using their ratings weighted by their project influence. StakeRare was evaluated by applying it to a software project for a 30,000-user system, and a substantial empirical study of requirements elicitation was conducted. Using the data collected from surveying and interviewing 87 stakeholders, the study demonstrated that StakeRare predicts stakeholder needs accurately and arrives at a more complete and accurately prioritized list of requirements compared to the existing method used in the project, taking only a fraction of the time.

On teaching operating systems

This paper discusses teaching an Operating Systems Course. Different approaches to teaching the course are presented. An operating systems course is one of the kernel courses in computer curriculum of both China and other countries. This course is of critical importance for students to understand the working procedures and principles of modern computer systems, to understand the methodology and approach of the design of system software, and to gain an appreciation for the requirements of other large-scale software projects.