Use Cases are a popular method for recording requirements.  With little effort, ProR can make recording Use Cases easy and traceable. To demonstrate this, we use ProR itself as an example.  Below is a screenshot of ProR, recording the use case “Create a new SpecObject”.  You can download this requirements model from the Eclipse git repository.  In the following, we point out where this model specifically takes advantage of ProR’s features, and conclude in the end how further integration with other models (SysML modeling, testing), could be realized.

Line 1: Headline and IDs

The Use Case has an ID (UC-1).  This ID is generated by the ID Presentation.  Also, the line is shown in a large, boldface font.  This has been realized with the Headline Presentation.

Line 1 (below): Link to Actor

Use Cases have a primary actor, which is realized with a link.  In this example, the primary actor is the “Requirements Engineer”.  There is a separate document (Specification), where all actors are defined (see screenshot right).  The role “Primary Actor” is also selected from a list of pre-defined roles from a drop-down.

Line 1.1: Explanatory Text

Information text can be added anywhere and does not have an ID (as none is needed)

Lines 1.3, 1.4 and 1.5: Scenarios

Scenarios have their own SpecType.  Via the Headline Presentation, it is also formatted in a more visible manner. In addition, it has a status field, which allow the tracking of the implementation status of the various scenarios.

Benefits

The result of this approach is a document-like description of use casees.  A handful of SpecTypes are used to manage appearance and to keep the model free of formatting information.  This makes reuse and linking of models outside ProR easier.  References (Actors) and selection lists (Status, Relationship) are used to prevent duplicating of information and to lead and support the requirements engineer in their work.

Integration

What we just presented can be realized with ProR stand-alone.  However, we are currently investigating simple integrations that could add significant value.  These include:

UML/SysML (Use Cases, Actors)

Papyrus is an Eclipse-Project that allow UML and SysML modeling.  The approach for modeling use cases could leverage Papyrus for UML/SysML integration.  Such an integration would:

• Keep UML and ProR Use Cases synchronized: Creating a UML Use Case would automatically generate the corresponding elements in ProR.
• While in Papyrus, only Use Case ID and name would be shown, the content could be managed (and enriched) with ProR.
• Use Case-Actor-Associations could still be realized in Papyrus.  But the relationship would appear synchronized in ProR.

The benefit would be a textual representation, as preferred by many stakeholders, while allowing the reuse of modeling element is UML/SysML

Mylyn (Project Management)

Mylyn is a popular tool for bug and feature tracking that seamlessly integrates in Eclipse.  An Integration could create and track a Mylyn issue for each scenario.  The status shown in ProR could be taken directly from Mylyn.  Using Mylyn would abstract the tracking system from the integration: It would not matter whether Mylyn uses (for example) Bugzilla or Jira underneath.

JUnit (Implementation Status)

If would be possible to associate unit tests with individual scenarios. Then a status field could be managed automatically by analyzing the associated unit tests: If only one test fails, the scenario would be marked as broken.

Conclusion

We hope that this little example demonstrates how using a specialized tool can improve the requirements engineering process significantly.  While the integrations do not exists, they could be implemented with a few day’s work each by an experienced developer.  The Eclipse ecosystem ensures that the resulting code is compact and maintainable.