Repetition between stakeholder (user) and system requirements

Stakeholder requirements (also known as user requirements) are defined at an early stage of a software project to describe the problem(s) to be solved. At a later stage, abstract solutions to those problems are prescribed in system requirements. The quality of these requirements has long been linked to the quality of the software system and its development or procurement process. However, little is known about the quality defect of redundancy between these two sets of requirements. Previous literature is anecdotal rather than exploratory, and so this paper empirically investigates its occurrence and consequences with a case study from a UK defense contractor. We report on a survey of sixteen consultants to understand their perception of the problem, and on an analysis of real-world software requirements documents using natural language processing techniques. We found that three quarters of the consultants had seen repetition in at least half of their projects. Additionally, we found that on average, a third of the requirement pairs’ (comprised of a system and its related stakeholder requirement) description fields were repeated such that one requirement in the pair added only trivial information. That is, solutions were described twice while their respective problems were not described, which ultimately lead to suboptimal decisions later in the development process, as well as reduced motivation to read the requirements set. Furthermore, the requirement fields considered to be secondary to the primary “description” field, such as the “rationale” or “fit criterion” fields, had considerably more repetition within UR–SysR pairs. Finally, given that the UR–SysR repetition phenomena received most of its discussion in the literature over a decade ago, it is interesting that the survey participants did not consider its occurrence to have declined since then. We provide recommendations on preventing the defect, and describe the freely available tool developed to automatically detect its occurrence and alleviate its consequences

A step towards the adoption of standards within the UK Ministry of Defence

A review of the literature shows that there is very limited empirical research into the factors that impact the adoption of ISO 10303, the Standard for the Exchange of Product Data (STEP). In particular no study has looked specifically at the adoption of STEP in the defence environment. Therefore, this paper seeks to identify factors that have impacted the adoption of STEP within the UK Ministry of Defence (MoD). A multi-case study approach is used to contrast the adoption of STEP, with the adoption of a regional and UK national defence standard within the MoD. This approach was taken to identify the factors that are unique to the adoption of STEP and the factors that are common to the general adoption of standards within the MoD. It is envisaged that these results will contribute towards a better understanding of the factors critical to the adoption of data-exchange standards like STEP