Towards a Unified Requirements Modeling Language Jonas Helming, Maximilian Koegel, Florian Schneider, Michael Haeger, Christine Kaminski, Bernd Bruegge
Siemens Corporate Research Princeton, NJ
Institut für Informatik Technische Universität München
[email protected]
Brian Berenbach
{helming, koegel, schneidf, haeger, bruegge}@in.tum.de
Abstract—Requirements engineering for complex systems often requires inter-disciplinary collaboration between domain experts who might not have software or systems engineering background. Existing requirements modeling languages unfortunately do not support this scenario well. First, the visual notation of languages like UML or SysML does not follow scientific heuristics and therefore does not provide a homogeneous and more important interdisciplinary comprehensible visualization. Second they provide isolated solutions for specific aspects like feature modeling or hazard modeling and therefore do not provide integrated and interdisciplinary traceability. We propose the Unified Requirements Modeling Language (URML) to overcome these two issues. URML integrates aspects like goal modeling, feature modeling and hazard analysis into one model and aims at a homogeneous and comprehensible visualization. In this paper we propose the meta-model for URML, describe the development of the corresponding visualization as well as initial tool support. Keywords-URML; Requirements; Unified; Modeling; Goal; Feature; Hazard; UNICASE; Language
I. INTRODUCTION Understanding the requirements and their interrelations for complex systems has always been a critical success factor for software and system projects [1]. Requirements, goals or potential hazards are in conflict. As an example, the nonfunctional requirement “maximum speed for a car greater then 200 km/h”, derived by a customer goal may conflict with the environmental requirement of low carbon emissions. The same requirement might also trigger a potential hazard “engine overheats”. We claim it is necessary to enable a dialog between different disciplines and understand the interdependencies between all the requirements. Languages such as UML [2] and SysML [3] offer traceability only limited to a certain aspect such as process modeling or use cases [4]. We propose the Unified Requirements Modeling Language (URML) offering explicit traceability between requirements from different domains [5]. For example it offers traceability between business goals, product features, functional requirements, possible threats and possible hazards and their mitigation. The analysis of complex systems usually involves the collaboration of domain experts from a range of different
disciplines such as business analysts, mechanical engineers and software engineers. This multi-disciplinary approach of requirements engineering requires a commonly understandable visual syntax. “Historically, SE researchers have ignored or undervalued the role of visual syntax” [6]. “The Details of Conceptual Modeling Notations are generally shrouded in mystery” [7]. URML focuses on visualization, which is intuitively understandable by nonsoftware engineers and therefore fosters inter-disciplinary collaboration. Finally the complexity of a unified requirements model requires integrating quality assurance into the requirements model. While languages like UML do not provide an explicit grammar and basically allow connecting “everything with everything” [4], our goal is to derive a defined grammar for URML from the meta-model. For this purpose URML also provides executable validation rules. For example the model can be checked to determine whether critical risks have been assigned sufficient mitigations. Although URML defines a language to express, validate, and interrelate requirements, it does not provide tooling or an implementation. Existing tools for requirements engineering provide isolated solutions for specific aspects [4]. UNICASE is a research platform for building pilot modeling applications with tooling for traceability, visualization, validation and collaboration [8]. Furthermore UNICASE provides a unified model avoiding the issue of tool integration. Therefore we propose UNICASE as a platform for the initial implementation of URML. In this paper we describe the current state of URML. We do not describe the draft taxonomy from which we derived the meta-model presented here. This will be subject to later publication. In section II we introduce the meta-model (in early draft form) containing all artifacts such as goals, features or non-functional requirements. In section III we describe, how we develop visualization for URML based on the criteria defined by Moody [6]. In section IV we give an overview of the available tool support for URML, implemented in UNICASE. Related work is mentioned in the sections, respectively. II.
META-MODEL
The scope of URML is to model the early requirements of a system consisting of hardware and software components
from a business level to the subsystem decomposition. The current version of the URML focuses on the application domain, not the solution domain. URML provides the abstract and solution independent concept of services, which are used to decompose the problem space. More detailed and solution dependant models can be traced through these services. In this section we describe the meta-model of URML in detail. The meta-model itself reflects the views of the authors and is no generally accepted principle yet. Although URML is an integrated Model, we structure this section by aspects. For every aspect we also describe the relationships to other aspects of URML. Since a description of the meta-model of URML including all attributes would go beyond the scope of this paper we will focus on the model elements and their interrelations and avoid describing all attributes in detail. Terms referencing elements of our meta-model are formatted with italic font style upon their first occurrence. A. Goal Modeling For any company product development, in our context of system development, shall add a maximum of value for the stakeholders [9]. Therefore the requirements for a system have to be carefully selected, which is a challenging activity [10]. Goal modeling has been suggested to perform a preliminary acquisition step for requirements engineering [11]. It offers ways to express business, customer and end user goals and to model how these goals influence each other. Many existing goal models allow refining goals down to a level of functional and non-functional requirements, and to visualize the relationship between reinforcing and conflicting goals. Therefore the difference between goals and requirements is not explicit. URML defines a goal to be product independent, while features and requirements are product or project dependent. This way, goals can be modeled independently from a concrete deliverable. Goals are expressed by a number of stakeholders (see Fig. 1). From goals the URML allows the deriving of realizing features for feature modeling (see Fig. 2). Goal Dependencies allow defining relationships among goals. They can either decompose a goal into sub-goals or model additional dependencies among goals to express that goals are in conflict with or strengthen one another.
B. Feature Modeling Feature modeling is typically used to model product lines and the features of different products of the same product line [12]. It can, however, also be used to express complex variation in a single product. For example, a hospital billing system might have extensive facilities for customer customization after delivery. In URML we use features to describe desirable properties and variability (user customization) of a specific product that are end-user visible. This product does not necessarily belong to a product line, but it can. In the next section we describe how to use features in URML to model product lines. We say here that features realize goals that were set forth in goal modeling. They can be refined into sub-features until they are small and feasible enough to be detailed into functional requirements and attached to their constraints that are modeled as non-functional requirements. Functional and non-functional requirements are not necessarily end-user visible, and more important, they are testable. Furthermore, requirements are not part of the product line modeling, as draft product features tend to overlap requirements elicitation, analysis, and early design (e.g. prototyping). Apart from decomposition, features can also be related by a feature dependency (see Fig. 3). A dependency can either be a «conflict» dependency or a «require» dependency. If a feature requires another feature, it cannot be realized without the other feature. If a feature conflicts with another feature, it cannot be realized if the other feature is present.
Figure 2. Features and Requirements
Figure 1. Goals and Stakeholders
C. Product Line Modeling Features cannot only be used to describe the properties of a single product and their decomposition or configuration, but they can also be used to describe products as part of a product line. A product may be something very abstract which is not directly tangible, e.g. like an infrastructure upgrade or machinery improvement. To allow expressing variations in products URML defines variation points. A variation point aggregates several features and defines a relation among those features by a selection constraint. The selection constraint can define for example that only one of
the features can be or must be part of a product. A variation point is a subtype of feature and therefore inherits all properties and associations of a feature. By instantiating all variation points a product can be defined. The instantiation of a variation point is a variation point instance. It defines a selection following in accordance with the selection constraint of the variation point.
Figure 3. Feature and product line modeling
D. Requirement Modeling Functional requirements describe the functionality of the system that can be tested and that can be implemented with a defined set of resources, such as development time. Similarly a non-functional requirement expresses a constraint the system needs to satisfy. Non-functional requirements are decomposed until they can be quantified and tested (or satisficed).
describing a typical travel behavior of a potential end user of a system. Use cases from the solution domain describe the interaction of an actor with the proposed system. It refers to objects in the solution domain. Therefore it can be used to detail features of the product that is being modeled. For example the feature “usable without external power supply” of a notebook can be detailed with a use case about how user interacts with the system to use it without external power.
Figure 5. Use case modeling
F. Subsystem Decomposition Services describe which particular functionality is offered by the system. Therefore a service is related to a functional requirement that is satisfied by that service. Services can be decomposed into sub-services. That allows us to describe exactly where the functionality is implemented and provides an abstraction to aggregate services into units of related functionality.
Figure 6. Subsystem decomposition
Figure 4. Requirements modeling
E. Use Case Modeling Use case modeling is used to describe the interaction of an actor (role of a system user) with the system [13]. Usually a use case consists of a name and a flow of events describing the interaction [14]. In URML, we use the term “use case” as the formalized documentation of a process. A use case has two subtypes: solution domain use case and application domain use case. Use cases from the application domain describe the behavior of an actor with the current system or environment as-is. This means without the system to be built and therefore without referencing any solution domain objects. Application domain use cases can be used to detail a goal. For example a goal of “high mobility” can be detailed with a use case
G. Danger Modeling URML integrates Hazard Modeling, Risk Modeling and Threat and Security Modeling into one joined set of abstractions. Existing models from these aspects contain very similar entities and relations. The most important ones are Hazard, Risk and Threat respectively. As these entities are overlapping, URML merges them into danger. A danger is an event that can occur with a given probability, which will harm assets and which can be mitigated by a mitigation. In this context assets can either be actors from the use case model or services from the subsystem decomposition model. Please note that danger does not include risks that affect the project itself, e.g. when an employee leaves the company. A Danger can be mitigated by a requirement from the requirement model or by a procedural mitigation. A procedural mitigation is a mitigation that is not built into the system but into the workflows and procedures on how to use
the system. For example it can be a warning in the user manual about a specific danger.
goals. They share one symbol, which can be altered by an overlay to hint the exact origin, as shown in Fig. 9.
Figure 9. Business goal and end user goal
The hardest part in constructing adequate icons is to find the simplest symbol, which sends the clearest message in a unique and easy way. The decision for certain proposed icons must be based on an evaluation among users from different disciplines and is part of future work. Another related issue is the determination as to when to use a new symbol vs. when to apply overlays to an existing symbol (see Figure 9. ). Figure 7. Danger modeling
III. VISUAL NOTATION URML has a visual notation that is intended to be intuitively understandable by non-engineers and to foster inter-disciplinary collaboration. The main design goal for this visual notation is cognitive effectiveness, which defines how fast, easy and accurate the processing of a representation by the human mind is [15]. All components, for example Stakeholders, Goals, Features or Requirements, are represented by distinct symbols. The notation follows the principles of Moody’s prescriptive theory for visual notations [6]: Semiotic Clarity, Perceptual Discriminability, Cognitive Fit, Cognitive Integration, Graphic Economy, Manageable Complexity, Semantic Transparency, Visual Expressiveness and Dual Coding. There are multiple ways to represent one component such as “Goals”. Fig. 8 shows four proposed visualizations of a goal. The hair cross line is the simplest of all. It represents the meaning of aiming at a goal, which is emphasized by the red mark. The circle-shaped background emphasizes the hair cross line and distinguishes it from the white background. Both should be used exclusively for Goals, e.g. Requirements need a different background color and shape. The treasure map is the most complex symbol and therefore probably the least convenient one. Both the finish flag and the target/arrow represent a slightly different meaning, which is not exactly intended: the goal has already been achieved.
IV. TOOL SUPPORT The complexity of URML requires tool support for an evaluation of the approach. We iteratively implement the current state of URML with UNICASE, a platform for model-based research. All model elements in UNICASE are part of a unified model and are stored in a model repository. UNICASE offers support for collaboration on model elements and versioning [16]. This supports multidisciplinary and distributed projects. Furthermore UNICASE offers support for tool instrumentation and project analysis based on historical data [17]. Model elements can be directly linked to each other, offering user visible traceability. UNICASE allows constructing diagram editors for arbitrary meta-models. Fig. 10 shows an example for a URML diagram in UNICASE.
Figure 10. Example of a URML diagram in UNICASE
Figure 8. Example visualizations of a goal
While there are unique symbols for each component there must not be too many at once. Even though there are ways to increase the Visual Expressiveness to make discriminability easier, complexity can be reduced by introducing graphical families, e.g. business and end user
UNICASE also offers other editors for browsing and modifying model elements: (1) A tabular view, showing a filtered and sort-able list of model elements, (2) A tree-based view, showing the containment structure of the model, and (3) A form-based editor to visualize and modify the content of one model element and its references. All views are generic and allow for frequently improving and refining the model (URML). Fig. 11 shows an example of the form-based editor. The danger “Engine overheats” is triggered by the service “High
performance engine” and can harm the driver and the service itself. In this example the danger is mitigated by a functional requirement for an “overheat sensor”. A user of UNICASE can simply navigate between the linked model elements
In parallel, we are developing tool-support for the current state of the language definition. The goal is to make the language applicable for real-life examples and case studies. We plan to evaluate on pilot projects whether the URML offers all the necessary facilities for modeling the requirements for complex systems and whether they are intuitively applicable. REFERENCES [1] [2] [3] [4] [5]
Figure 11. Form-based editor
UNICASE provides a facility to define and execute model validation rules. As an example shown in Fig. 12, the danger of the previous example would result in a warning, if it had no suitable mitigation. Note that the icons shown are only placeholders, as the work of creating the icons had just started at the time of the submission of this paper.
Figure 12. Result of a validation
[6] [7]
[8]
[9] [10]
V. CONCLUSION In this paper we presented the current state of the Unified Requirements Modeling Language. We introduced the metamodel and described the on-going definition of a crossdisciplinary understandable visualization of URML using well defined visual heuristics [6]. Finally we described the implementation of URML based on UNICASE. The taxonomy, meta-model, and visualizations are all works in progress at this time. The definition of the URML is quite challenging and we are using an interative approach. Our plan is to evaluate alternative visualizations with users from different disciplines. The most important research questions for the definition of the visualization of URML are: o Which visual representation including shape and style provides the best Semiotic Transparency and Expressiveness? o How are references between entities visualized? o Which entities are represented as distinct icons, which families are represented by altered tokens? o How to achieve Graphic Economy on complex models?
[11] [12] [13] [14] [15] [16]
[17]
R.N. Charette, “Why software fails”, IEEE spectrum, vol. 42, 2005, p. 36. “OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.3,” May. 2010. “OMG Systems Modeling Language (OMG SysML), Version 1.2,” Jun. 2010. B. Berenbach, “Requirements Engineering For Industrial Systems: No Easy Answers”, International Requirements Engineering Conference, Sydney 2010. B. Berenbach and T. Wolf, “A unified requirements model; integrating features, use cases, requirements, requirements analysis and hazard analysis”, Global Software Engineering, 2007. ICGSE 2007. Second IEEE International Conference on, 2007, pp. 197203. D.L. Moody, “The “Physics” of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering”, IEEE Transactions on Software Engineering, 2009, pp. 756–779. S. Hitchman, “The Details of Conceptual Modelling Notations are Important-A Comparison of Relationship Normative Language”, Communications of the Association for Information Systems, vol. 9, 2002, p. 10. B. Bruegge, O. Creighton, J. Helming, and M. Koegel, “Unicase – an Ecosystem for Unified Software Engineering Research Tools”, Workshop Distributed Software Development - Methods and Tools for Risk Management, Bangalore, India: 2008, pp. 12-17. S. Biffl, B. Boehm, and H. Erdogmus, "Value-based software engineering", Springer-Verlag New York Inc, 2006. L. Lehtola, M. Kauppinen, J. Vähäniitty, and M. Komssi, “Linking business and requirements engineering: is solution planning a missing activity in software product companies?,” Requirements Engineering, vol. 14, Jun. 2009, pp. 113-128. A. Dardenne, A.V. Lamsweerde and S. Fickas, “Goal-directed requirements acquisition”, Science of computer programming, 1993. K.C. Kang, J. Lee and P. Donohoe, “Feature-oriented product line engineering,” IEEE software, vol. 19, 2002, pp. 58–65. I. Jacobson and S. Bylund, The road to the unified software development process, Cambridge University Press, 2000. B. Bruegge and A.H. Dutoit, Object-oriented software engineering, Prentice Hall, 3rd edition, 2009 J.H. Larkin and H.A. Simon, “Why a Diagram is (Sometimes) Worth Ten Thousand Words” Cognitive science, vol. 11, 1987, pp. 65–100. M. Koegel, J. Helming, and S. Seyboth, “Operation-based conflict detection and resolution,” 2009 ICSE Workshop on Comparison and Versioning of Software Models, Vancouver, BC, Canada: 2009, pp. 43-48. M. Koegel, Y. Li, H. Naughton, and J. Helming, “Towards a Framework for Empirical Project Analysis for Software Engineering Models,” 2010 ASE VASE Workshop, Auckland, New Zealand: 2009.
