.jpg)
by Sam Supakkul
Support for the NFR Framework | Support for the i*/Tropos Framework | Support for KAOS | Support for Problem Frames | Support for the WRSPM Reference Model
Download & Installation | System Requirements | User Guide | Q&A | License
The RE-Tools supports the following Requirements Engineering notations:
Different notations may be used standalone or together. Examples of the NFR Framework being used with KAOS and Use Case Modeling are illustrated below. More examples of integrated usage using multiple notations are available here.
The ability to model using different notations in the same tool environment allows requirements engineers to represent different concepts using notations that feel natural. For example, a requirements engineer could use the NFR Framework's softgoal concept instead of UML class to represent NFRs such as security. She could also use the i* Framework to model stakeholders and their inter-dependencies as actor-to-actor relationship concept is not supported by UML Use Case Modeling. Similarly, KAOS can be used to define certian goals more formally with temporal logic to capture critical timing constraints. Or Problem Frames can be used as an alternative to use case diagram to define requirements and specifications in a distinct and cohesive manner that can capture relevant domains and shared phenomena more precisely.
Additionally, supporting multiple notations in the same tool environment makes it is possible to provide traceability or perform model transformation between models from different notations or from different phases of the development. For example, traceability or model transformation can be defined or performed between a goal model and a corresponding problem frame diagram, and subsequently between the problem frame diagram and an architectural design. It is also possible to perform model-based reasoning across notations based on the semantics of the respective notations. For example, as discussed in this paper, if an on-line transaction use case is associated with an NFR such as fast/performance, the related specialized, extending, and included use cases inherently should also be fast, or if a payment system should be secure, its contained sub-systems or components should also be secure.
At this stage, the RE-Tools should provide reasonably useful modeling capability for the respective notations, but is incomplete in some respects. The tool is therefore released as an open-source tool under GPL to encourage more research and extensions to provide better support and better integration of the notations, and ultimately to create a useful integrated requirements and software engineering tool for practitioners.
The RE-Tools can be downloaded from here. Any questions and comments are welcome. Please email them to "ssupakkul (at) ieee (dot) org".
The RE-Tools implements the modeling and label evaluation concepts defined in the book and paper on the NFR Framework, with an extension to support both closed and open world assumptions for label evaluation. See evaluation catalogs and a discussion on this topic here.
A companion model called Problem Interdependency Graph has been developed to complement the NFR Framework for problem-oriented modeling for representing and dealing with stakeholder or system related problems.
The latest version (1.2) has implemented automated goal achievement evaluation based on the label evaluation procedure defined by the NFR Framework. Below is a demo of the feature. A larger video is available here.
Figure 1. A Softgoal Interdependency Graph
.jpg)
Figure 2: An Integrated Softgoal Interdependency Graph and Problem Interdependency Graph
.jpg)
Figure 3: An Integrated Use Case and NFRs Diagram
The tool panel for the i*/Tropos Framework provides icons for creating Strategic Dependency (SD) and Strategic Rationale (SR) diagrams, including Agent, Position, Role, Goal, Task, and Resource conceptual entities, as well as Dependency, AND/OR decomposition, and Means-end links. The support for modeling softgoals in SD or SR diagrams is available on the NFR Framework panel that is simultaneously accessible along with panels for other notations such as KAOS and Problem Frames.
.jpg)
Figure 3. A Strategic Dependency Diagram
.jpg)
Figure 4. A Strategic Rationale Diagram
The RE-Tools supports many concepts defined in the seminal paper on KAOS with influences from the KAOS UML Profile. Further extensions were made to support the following:
.jpg)
Figure 5. A KAOS Goal Model
The Problem Frames method was originally developed for system level requirements and specifications modeling, but has been adopted for business modeling. The RE-Tools implements many concepts defined in the book on Problem Frames, and provides different notations to differentiate business problem frames from system problem frames as inspired by the notations for differentiating business use cases from system use cases.
.jpg)
Figure 6. A Business Problem Diagram
.jpg)
Figure 7. A System Problem Diagram
The notations supported by the RE-Tools are available to the users regardless of which StarUML Approach is used by the user. But if the user selects the provided "WRSPM" Approach after launching StarUML. The RE-Tools creates a blank project with a pre-created model structure consisting of World, Requirements/Specifications, Program, and Machine modules based on the Reference Model, with an initial set of suggested diagrams for each artifact, which can be removed or additional diagrams can be added as needed.
Figure 8. Model Structure Supporting the WRSPM Reference Model
Using any StarUML Approach, (e.g. "4+1" or "WRSPM"), the supported diagrams can be created from the menu bar or from the Model Explorer as shown in Fig. 9 below. Notice that the RE-Tools provides augmented UML diagrams (e.g. Class-NFR, UseCase-NFR, Component-NFR) so that NFRs may be modeled in those diagrams as shown in Fig. 2. However, currently NFRs may not be modeled in statechart, sequence diagrams, and activity diagrams due to the restriction imposed by StarUML that UML class (the physical representation of NFR softgoals) is not allowed in those behavioral diagrams.
Figure 9. Creating a New Diagram
© 2007-2009 Sam Supakkul
Updated Nov. 18, 2009