473,202 research outputs found

    Scope Management of Non-Functional Requirements

    Get PDF
    In order to meet commitments in software projects, a realistic assessment must be made of project scope. Such an assessment relies on the availability of knowledge on the user-defined project requirements and their effort estimates and priorities, as well as their risk. This knowledge enables analysts, managers and software engineers to identify the most significant requirements from the list of requirements initially defined by the user. In practice, this scope assessment is applied to the Functional Requirements (FRs) provided by users who are unaware of, or ignore, the Non-Functional Requirements (NFRs). This paper presents ongoing research which aims at managing NFRs during the software development process. Establishing the relative priority of each NFR, and obtaining a rough estimate of the effort and risk associated with it, is integral to the software development process and to resource management. Our work extends the taxonomy of the NFR framework by integrating the concept of the "hardgoal". A functional size measure of NFRs is applied to facilitate the effort estimation process. The functional size measurement method we have chosen is COSMICFFP, which is theoretically sound and the de facto standard in the software industry

    Towards a scope management of non-functional requirements in requirements engineering

    Get PDF
    Getting business stakeholders’ goals formulated clearly and project scope defined realistically increases the chance of success for any application development process. As a consequence, stakeholders at early project stages acquire as much as possible knowledge about the requirements, their risk estimates and their prioritization. Current industrial practice suggests that in most software projects this scope assessment is performed on the user’s functional requirements (FRs), while the non-functional requirements (NFRs) remain, by and large, ignored. However, the increasing software complexity and competition in the software industry has highlighted the need to consider NFRs as an integral part of software modeling and development. This paper contributes towards harmonizing the need to build the functional behavior of a system with the need to model the associated NFRs while maintaining a scope management for NFRs. The paper presents a systematic and precisely defined model towards an early integration of NFRs within the requirements engineering (RE). Early experiences with the model indicate its ability to facilitate the process of acquiring the knowledge on the priority and risk of NFRs

    Towards a Scope Management of Non-Functional Requirements in Requirements Engineering

    Get PDF

    Generation of Network Service Descriptors from Network Service Requirements

    Get PDF
    Network Function Virtualization (NFV) is a new paradigm in Network Service (NS) provisioning. European Telecommunications Standards Institute (ETSI) proposed and standardized an architectural framework for NFV. By leveraging virtualization and Software-Defined Networking (SDN) technologies, NFV decouples network functionality from hardware infrastructure. This enables the automated provisioning of NSs and reduces the capital and operational costs for service operators. NFV Management and Orchestration (NFV-MANO) is a functional block in the NFV framework, and it is responsible for the deployment and life-cycle management of NSs. With NFV, the telecommunication industry is moving towards zero-touch, i.e. automation of all the processes. In order to orchestrate and manage an NS, NFV-MANO requires the NS’s deployment template. This template is referred to as NS Descriptor (NSD) and contains all the details for deployment and orchestration of the NS. De-signing such a descriptor requires the design of the NS, which is actually out of the NFV scope. Traditionally, service operators’ experts design NSs and NSDs. However, this design activity is time-consuming and error-prone; moreover, it is not fitting the Telecom’s vision of zero-touch. In this thesis, we will propose an approach to automate the process of NS and NSD design. The approach starts from a set of requirements provided as Network Service Requirements (NSReq). The NSReq describes the required network service at a high level of abstraction and focuses on the functional, architectural, and non-functional characteristics. With the help of an ontology representing the knowledge from Telecom standards and previous successful experiences, we decompose the NSReq. We select the set of Virtual Network Functions (VNF) from a catalog to design the NS. Considering all the levels of decomposition and the VNF’s dependencies captured from the ontology, we design all the possible for-warding graphs that can form an NS. We design each forwarding graph through different steps at different abstraction levels, i.e. functional, architectural, and VNF levels. According to each forwarding graph, we design an NSD along with the traffic flows in the NS. We re-fine each NSD by dimensioning its VNFs using the non-functional requirements in the NSReq. Accordingly, we refine the deployment flavor of each NSD. We have developed a prototype tool as a proof of concept for our proposed approach which we will discuss later in this thesis

    ICD Management (ICDM) tool for embedded systems on aircrafts

    Get PDF
    International audienceIn the scope of on-board systems development and integration for aircrafts, ICDs (Interface Control Document/Description) are fundamental sources of information at same level that the functional requirements. ICD description must include feasible (bus capacity not exceeded, processing load under specific limits) and accurate (data precision, data retransmission rate, data consistency) inter-connectivity mechanisms, to support the application requirements needs, as well as the information must be easy to update and to maintain.On the other hand, DOORS (IBM) is a tool specialized on requirements management. It faces with aspects as traceability, version control, security (access control), changes control, data persistency and accessibility. DOORS is widely used and it is recognized as a reference tool in the scope of aeronautic developments.Nevertheless, ICD information usually is not managed with DOORS. The reason can be found in the specificities of the nature of ICD information, which suggests other approaches more suitable than DOORS.The alternative approaches are very diverse but most of them focus on handling information typified according to specific meta-models for ICD: databases, customized spreadsheets, and tabular descriptions. But whatever is the solution, it must address also, by its own means, the features of ICD derived of its “requirement nature”.This paper presents a solution based on the integration of DOORS with a user front-end developed with Model Driven Architecture (MDA) and Open Source technologies. It is intended to provide means to manage ICD data in a robust way (guaranteeing the correctness -syntactic, completeness, non ambiguity- of data, changes, versions, dependencies, ...) and additionally, to provide mechanisms to focus the effort on the data transformation rather than on the manual elaboration of derived artefacts

    Enhancing Requirements Change Request Categorization and Prioritization in Agile Software Development Using Analytic Hierarchy Process (AHP)

    Get PDF
    Software development now relies heavily on agile methods, which call for the efficient administration and prioritization of change requests. In order to improve requirement prioritization using the Analytic Hierarchy Process (AHP) in Agile methods, this study article presents a new framework for classifying software requirements into Small Change Requests (SCRs) and Large Change Requests (LCRs). The paper examines the difficulties associated with requirement prioritization and categorization in Agile settings and offers a methodical system for dividing change requests into categories based on complexity, impact, and timeline. In order to provide a thorough grasp of the project scope and objectives, the framework considers both functional and non-functional needs. A case study containing several Agile software development projects is used to evaluate the performance of the suggested categorization and prioritization model. According to the findings, the combination of SCR and LCR categorization with AHP enables more effective teamwork and greater matching of development goals with partner objectives. The research also shows that the suggested framework's integration into the Agile development process results in a more efficient decision-making process, less time wasted on talks, and improved resource distribution. The model aids in risk mitigation by allowing a methodical and quantifiable approach to requirement prioritization. These risks are related to quick changes in project scope and changing client requirements. By presenting a fresh framework for requirement categorization and prioritization, this study adds to the current discussion on successful requirement management in Agile methods. Agile software development projects become more effective and adaptable overall thanks to the incorporation of AHP, which guarantees a more methodical and objective prioritization process. This study has the potential to greatly improve the administration of shifting needs and user expectations in Agile settings by offering a structured method to classify and rank change requests

    <i>Trace++</i>: A Traceability Approach for Agile Software Engineering

    Get PDF
    Agile methodologies have been introduced as an alternative to traditional software engineering methodologies. However, despite the advantages of using agile methodologies, the transition between traditional and agile methodologies is not an easy task. There are several problems associated with the use of agile methodologies. Examples of these problems are related to (i) lack of metrics to measure the amount of rework that occurs per sprint, (ii) interruption of a project after several iterations, (iii) changes in the requirements, (iv) lack of documentation, and (v) lack of management control. In this paper we present Trace++, a traceability technique that extends traditional traceability relationships with extra information in order to support the transition between traditional and agile software development. The use of Trace++ has been evaluated in two real projects of different software development companies to measure the benefits of using Trace++ to support agile software development

    An Empirical Study on Decision making for Quality Requirements

    Full text link
    [Context] Quality requirements are important for product success yet often handled poorly. The problems with scope decision lead to delayed handling and an unbalanced scope. [Objective] This study characterizes the scope decision process to understand influencing factors and properties affecting the scope decision of quality requirements. [Method] We studied one company's scope decision process over a period of five years. We analyzed the decisions artifacts and interviewed experienced engineers involved in the scope decision process. [Results] Features addressing quality aspects explicitly are a minor part (4.41%) of all features handled. The phase of the product line seems to influence the prevalence and acceptance rate of quality features. Lastly, relying on external stakeholders and upfront analysis seems to lead to long lead-times and an insufficient quality requirements scope. [Conclusions] There is a need to make quality mode explicit in the scope decision process. We propose a scope decision process at a strategic level and a tactical level. The former to address long-term planning and the latter to cater for a speedy process. Furthermore, we believe it is key to balance the stakeholder input with feedback from usage and market in a more direct way than through a long plan-driven process

    Enhanced Graph Rewriting Systems for Complex Software Domains (SoSyM Abstract)

    Get PDF
    International audienceMethodologies for correct by construction reconfigu-rations can efficiently solve consistency issues in dynamic software architecture. Graph-based models are appropriate for designing such architectures and methods. At the same time, they may be unfit to characterize a system from a non functional perspective. This stems from efficiency and applicability limitations in handling time-varying characteristics and their related dependencies. In order to lift these restrictions, an extension to graph rewriting systems is proposed herein. The suitability of this approach, as well as the restraints of currently available ones, are illustrated, analysed and experimentally evaluated with reference to a concrete example. This investigation demonstrates that the conceived solution can: (i) express any kind of algebraic dependencies between evolving requirements and properties; (ii) significantly ameliorate the efficiency and scalability of system modifications with respect to classic methodologies; (iii) provide an efficient access to attribute values; (iv) be fruitfully exploited in software management systems; (v) guarantee theoretical properties of a grammar, like its termination. This is an extended abstract for the Models 2015 Conference of the journal paper of the same name [1]. I. MOTIVATION Dynamic software architectures enable adaptation in evolving distributed systems. A crucial undesirable implication of such adaptations is a potential loss of correctness, the system withdrawing from its scope of consistency. Besides correctness, the system has evolving non-functional requirements, which are tightly linked to its appropriateness or efficiency. The satisfaction of these objectives depends on the properties of the system, its components, and their relations. On one hand, graph-based models are appropriate for the design of adaptation rules that necessarily preserve the system's consistency. On the other, currently available graph based methods exhibit limitations with regard to the description of system properties, in particular regarding their evolution and inter-dependencies
    • 

    corecore