6 research outputs found

    Rationale Management Challenges in Requirements Engineering

    Get PDF
    Rationale and rationale management have been playing an increasingly prominent role in software system development mainly due to the knowledge demand during system evaluation, maintenance, and evolution, especially for large and complex systems. The rationale management for requirements engineering, as a commencing and critical phase in software development life cycle, is still under-exploited. In this paper, we first survey briefly the state-of-the-art on rationale employment and applications in requirements engineering. Secondly, we identify the challenges in integrating rationale management in requirements engineering activities in order to promote further investigations and define a research agenda on rationale management in requirements engineering.

    Missing Requirements Information and its Impact on Software Architectures: A Case Study

    Get PDF
    [Context & motivation] In the development of large, software-intensive systems, the system’s requirements are seldom, if ever, concluded upon prior to commencing with systems architecture. Research shows that, in order to manage development and domain complexities, instances of requirements engineering (RE) and systems architecting (SA) processes tend to inter-weave. [Question/problem] However, missing requirements information can cause one to create (or recreate) the needed information during different SA activities. While backtracking in the software development process is known to be costly, the costs associated with missing requirements in the SA process have not been investigated empirically. [Principal ideas/results] We thus conducted a case study where we investigated to what extent requirements or requirements attributes’ information found missing during the SA process and impact of those missing information on SA in terms of effort. The study involved five architecting teams that involve final year undergraduate and graduate students enrolled in the university course on SA, working on architecting a system falls under “banking” domain. Our result shows that, architects did find requirements and requirements attributes’ information missing while architecting. Among requirements information, architects found that, system functionality information, constraints information and system interaction (users/systems) information are missing in requirements at higher percentages. Within requirements’ attributes, architects found requirements priority, dependency and rationale missing at higher percentages. It is also found that, out of total time spent on architecting the system, effort given to recreate missing requirements information is higher for group3 (21.5%), group1 (18%), and group2 (17%) other than group4 (12.37%) and group5(10.18%). [Contribution] The anticipated benefits of the findings are, it can motivate researchers to venture into other areas of software engineering (such as coding, testing, maintenance, etc.) from the view point of missing requirements information and its impact on those areas. This knowledge could help software practitioners to decide what kind of information need to take care of, during RE process, that could possibly ease SA process and later development phases. To the best of my knowledge, this is the first work which focuses on, to what extent requirements and requirements’ attributes information found missing during SA; characteristics and impact of those requirements missing information on SA process in terms of effort

    Supporting requirement analysis through requirement rationale capture and traceability

    Get PDF
    Manufacturers of complex engineering systems are increasingly recognising the importance of identifying, understanding and satisfying stakeholders’ needs in order to produce high-quality products. The analysis of these needs into a formal requirement specification is a time consuming and complex process for which little support is offered to design engineers. This can result in requirements being poorly documented and with little or no traceability to their origins. This dissertation reports an investigation to understand the process of requirement analysis and develop computational support for this important phase of the engineering design process. The key argument of this research is that the existing practice of requirement analysis can be improved by providing better support for requirement rationale capture and enabling greater requirement traceability. The research consisted of three main phases. In the first phase, literature related to the requirement analysis was reviewed and led to the creation of a requirement analysis model. In the second phase, the practices of a global engineering organisation were investigated using document analysis as well as interviews with and shadowing of company engineers. The research found that requirement analysis lacks support for requirement rationale capture and traceability. On the basis of this result, a workflow for requirement analysis was proposed. The workflow involves the use of the Decision Rationale editor tool to capture requirement rationale and enable requirement traceability. In the third phase, four studies were undertaken to validate the workflow. These studies investigated: 1) application of the workflow to requirements generated through reverse-engineering a low-complexity consumer product; 2) requirements extracted from documents produced by a graduate engineering team during a twelve-week project; 3) the requirement analysis process undertaken by two graduate engineering teams during twelve-week projects; and 4) requirements for a new aircraft engine development programme. The studies showed that the proposed workflow is feasible, practical, and scalable when applied to engineering projects. Requirement rationales were classified into categories, namely product design and use, pre-existing rationale, and project management. In order to fully support requirement traceability, it was found that it is important to make traceable four types of requirement transformations: newly introduced, copied, updated, and deleted requirements. The research demonstrated that the proposed workflow is a successful proof-of-concept and can lead to improved quality of requirement documentation and requirement traceability.Open Acces

    Rationale Management Challenges in Requirements Engineering

    No full text
    Rationale and rationale management have been playing an increasingly prominent role in software system development mainly due to the knowledge demand during system evaluation, maintenance, and evolution, especially for large and complex systems. The rationale management for requirements engineering, as a commencing and critical phase in software development life cycle, is still under-exploited. In this paper, we first survey briefly the state-of-the-art on rationale employment and applications in requirements engineering. Secondly, we identify the challenges in integrating rationale management in requirements engineering activities in order to promote further investigations and define a research agenda on rationale management in requirements engineering
    corecore