Exploiting a Goal-Decomposition Technique to Prioritize Non-functional Requirements

Business stakeholders need to have clear and realistic goals if they want to meet commitments in application development. As a consequence, at early stages they prioritize requirements. However, requirements do change. The effect of change forces the stakeholders to balance alternatives and reprioritize requirements accordingly. In this paper we discuss the problem of priorities to non-functional requirements subjected to change. We, then, propose an approach to help smooth the impact of such changes. Our approach favors the translation of nonoperational specifications into operational definitions that can be evaluated once the system is developed. It uses the goal-question-metric method as the major support to decompose non-operational specifications into operational ones. We claim that the effort invested in operationalizing NFRs helps dealing with changing requirements during system development. Based on\ud this transformation and in our experience, we provide guidelines to prioritize volatile non-functional requirements

The impacts of non-functional requirements in web system projects

In web system development, the Non-Functional Requirements (NFRs) are typically considered only briefly during the requirements elicitation stage and not rigorously articulated by either web developers or the client. This paper reports on an investigation into this issue involving interviews with web developers who were engaged in commercial web development projects. The results from this qualitative research highlight that web developers commonly do not pay sufficient attention to NFRs. This arises due to uncertainty, lack of time, lack of knowledge in the importance of NFRs and partly because NFRs are not readily available and documented from previous similar projects. Web developers also do not elicit NFR at the same time and at the same level of details as Functional Requirements (FRs). This study highlights that exploring the domain at an early stage of development will help developers to better understand NFR. A lack of rigour in articulating NFRs may significantly impact on the development effectiveness and the quality of the resulting web system. An evaluation of NFRs may also lead to discovering new FRs. © Copyright 2008, Inderscience Publishers

Development of a Control System for an Urban Electric Vehicle Compatible with Autonomous Driving Features

As cities continue to grow, the roads only become more congested, leading drivers to spend more time commuting, while vehicle accidents continue to rise. The Mechatronics Vehicle Systems Laboratory has developed its own urban electric vehicle in an attempt to combat congestion, as well as pollution concerns in urban areas. The focus of these thesis is a fault tolerant control system to improve the robustness of the vehicle, as well as allow for future autonomous vehicle functions to be tested on it. The development of the control system began with deriving the requirements from the vehicle’s hardware, the goal of the project and foreseeable changes in the future. From there, the processors were selected, electronic control units were ordered, the vehicle’s necessarily electrical connections were completed, and the control software was deigned. Once every part of the project was completed, the control system was integrated, and testing was completed at the university. The goal of the control software was to allow the vehicle to be drivable if a motor, motor controller or steering actuator failed due to an electrical, mechanical or feedback fault. Due to the vehicle’s modular design it allowed other components to compensate for failures, while maintaining vehicle controllability and predictable vehicle dynamics. Furthermore, the control system allows for autonomous vehicle functions to be added and tested on the vehicle. This was tested through the addition of a lane following models, along with the control system’s path following function. The developed control system was shown to improve vehicle controllability when faults occurred, as well as allowed lane following to work effectively with the system structure and communication channels chosen. Overall, validating the design as well as allowing future mechanical designs or autonomous functions to be tested on the vehicle