Rising complexity of systems has long been a major challenge in requirements engineering. This manifests in more extensive and harder to understand requirements documents. At the Daimler AG, an approach is applied that combines the use of activity diagrams with natural language specifications to specify system functions. The approach starts with an activity diagram that is created to get an early overview. The contained information is then transferred to a textual requirements document, where details are added and the behavior is refined. While the approach aims to reduce efforts needed to understand a system's behavior, the application of the approach itself causes new challenges on its own. By examining existing specifications at Daimler, we identified nine categories of inconsistencies and deviations between activity diagrams and their textual representations. In a case study, we examined one system in detail to assess how often these occur. In a follow-up survey, we presented instances of the categories to different stakeholders of the system and let them asses the categories regarding their severity. Our analysis indicates that a coexistence of textual and graphical representations of models without proper tool support results in inconsistencies and deviations that may cause severe maintenance costs or even provoke faults in subsequent development steps.
The success of requirements engineering depends critically on effective communication between business analysts and end users, yet empirical studies show that business stakeholders understand RE notations very poorly. This paper proposes a novel approach to designing RE visual notations that actively involves naïve users in the process. We use i*, one of the most influential RE notations, to demonstrate the approach, but the same approach could be applied to any RE notation. We present the results of 5 related empirical studies that show that novices outperform experts in designing symbols that are comprehensible to novices: the differences are both statistically significant and practically meaningful. Symbols designed by novices increased semantic transparency (their ability to be spontaneously interpreted by other novices) by almost 300% compared to the existing i* notation. The results challenge the conventional wisdom about visual notation design: that it should be conducted by a small group of experts; our research suggests that it should instead be conducted by large numbers of novices. The approach is consistent with Web 2.0, in that it harnesses the collective intelligence of end users and actively involves them in the notation design process as “prosumers” rather than passive consumers. We believe this approach has the potential to radically change the way visual notations are designed in the future.
We present the QM tool used to support our IQMC method for the construction of quality models for COTS domains. This tool also supports the organization of quality models in a taxonomy of COTS domains for supporting the reuse of these models.
Most problems in building and refining a system can be traced back to errors in requirements. Poorly organized requirements, most often in natural language are among the major causes of failures of software projects. In this paper, we present a requirements analysis tool called RETNA and the technology behind it. RETNA accepts natural language requirements, classifies them, interacts with the user to refine them, automatically translates natural language requirements to a logical format so that they can be validated and finally generates test cases from the requirements.
Assumptions are frequently made during requirements analysis of a system-to-be about the trustworthiness of its various components (including human components). These trust assumptions can affect the scope of the analysis, derivation of security requirements, and in some cases, how functionality is realized. This work presents trust assumptions in the context of analysis of security requirements. A running example shows how trust assumptions can be used by a requirements engineer to help define and limit the scope of analysis and to document the decisions made during the process. The paper concludes with a case study examining the impact of trust assumptions on software that uses the secure electronic transaction (SET) specification.
