Towards Measuring Software Requirements Volatility: A Retrospective Analysis

Abstract

Requirement management (RM) is a fundamental activity in requirements engineering. It keeps track of all the requirements changes that would cause errors or resulted in software delays or cost overruns. When requirements have many changes over time, they have a tendency to be highly volatile. This volatility depends on several factors such as organizational complexity, process maturity of the company, and development phase. Managing the requirements quantitatively by metrics is a good way to understand whether RM is efficient or not. In this paper, we propose a new metric to measure the requirements volatility of object-oriented systems in terms of use cases; we use retrospective analysis that examines the amount of change applied in successive versions of a software product. We theoretically validated our metric through a set of prominent mathematical properties. We also empirically validated our metrics using three versions of an open source project, JHotDraw. Measurements of the metric were shown to be consistent with previous measurements of the JHotDraw versions conducted at the architecture design level. The study results in a foundation for further empirical retrospective studies of the requirements properties.Keywords: requirements engineering, requirements volatility, requirements management, software metrics, use cases, software evolution. INTRODUCTIONSoftware requirements describe the services provided by the system and its operational constraints [1] [2]. These requirements reflect the needs of system stakeholders (including paying customers, users and developers). The process of finding out, analyzing, documenting, and checking these services and constraints is called requirements engineering (RE) . From an evolution perspective, volatile requirements are likely to change after the system has been become operational or during the system development process. An example, is the requirements resulting from government healthcare policies [2]. These requirements must evolve to reflect the changed view of the system in development. Furthermore, the

The influencing causes of software unavailability: A case study from industry

“…This retrospective analysis looks at the successive version of the artifact to investigate why the unavailability took place. 33 It is clear that looking at such type of data has a strong influence on reducing the risk. By looking back, someone can emulate things that worked and improve areas where problems arose through avoiding of past difficulties and reducing the overall risk.…”

“…() This type of data can be evaluated by using retrospective analysis. This retrospective analysis looks at the successive version of the artifact to investigate why the unavailability took place . It is clear that looking at such type of data has a strong influence on reducing the risk.…”