Use Cases documentation
Use Cases are the way to define the System of Interest (SOI) expected operational behavior. It is also the basis for eliciting stakeholder and Enabling Systems (that we also call context systems) requirements and needs.
We consider Use Cases are a very similar tool to external functional analysis. In arKITect, Use case objects could be for instance Service functions for which you caracterize the interface with the environment.
In arKItect beside being a tool to elicit external requirements, the Use Cases in arKItect can also linked to life cycle phases and are compatible with arKItect options&variants native mechanisms.
Defining Use Cases
Use Cases diagrams are build upon Flow Chains in view 1.1.
Adding for instance « Cools carbody » object of type "Flow Chains" enable defining the related Use case diagram. Once the object is created, you double click on it in order to edit the Use Case diagram as below.
In a Use Case diagram (Flow Chain), it is possible to define one or several Use Cases (yellow objects) and their interactions with context systems (blue objects). A "Use Case" object shall be understood as "The system of interest(SOI) performing one or several functions in one ore several phases of its lifecycle". Use cases also allow describing expected features of the SOI through interactions of the SOI with its environment.
It is possible to define data flow and physical flow links between a Use Case and Context Systems although normally at this early stage, you should specify interactions as « sequence information » flows (the blue flows in the image above). It is also possible to add functions and requirements to a Use Case.
« Sequence information » flows represent high level interactions that will not be translated directly into operational flows. Sequence information are rather used to identify interactions and elicit creation of requirements that will be refined into technical functions or technical requirements during design. You may also use Sequence information to mention a relationship with a Stakeholder.
Specifying the behavior of a Use Case
Note the story object at the bottom right in the diagram above: it is carrying a sequence diagram that will allow describing the behavior of the Use Case.
It is possible to add requirements in a context system or in a Stakeholder or in a Use Case object. When reusing an object, e.g. a context system, it comes with all its requirements and functions and you need to select the one you want to keep by a right click on the object and selecting "Edit children..." the list of functions and requirements will be displayed and you can select the ones you want to keep.
At this stage, these are external requirements (when you edit them in context systems (blue boxes)
Here the Story object is of type « Sequence diagram ».
To define a sequence diagram, you need to right click on a Sequence Diagram object and select the « Define sequence diagram » script.
Once you launch the « Define sequence diagram » script, you should get a starting point for your diagram where all objects of the Use Case are reported and need to be organized. Refer to the Message Sequence Chart (MSC) documentation for reorganizing the diagram.
Blue objects are new objects existing since the latest opening of the MSC. At initialization, all objects are colored in blue. To get rid of the color, right click somewhere in the diagram and « Unmark all objects » for instance.
You can then organize your scenario and tell the story of your Use Case.
It is possible to add requirements objects in the Use Case or on any object. This is a very natural way ot proceed as the scenario will raise questions and needs.
The requirements (yellow shapes) you add in this diagram will be saved to arKItect once you save and quit the Message Sequence Chart Editor.
Note that if you reopen the MSC after having saved it the requirements are displayed in a cyan blue color.
Pushing Use Case analysis results downstream in the design process
When you define new objects in a Use Case: new stakholder, new context system or even new requirements, new functions and flows, these new objects are pushed in other views. The simple case is when you add a requirement in an enabling system, this requirements also appears in views 2.1 or 3.2. This is just the normal behavior in arKItect when content of an object is always consistent in all views. In case you create a new Stakeholder or a new Enabling system, these objects are pushed in view 2.1 under a flashy purple object. It is the same case when you add a requirement to a Use Case, it is added in view 2.1 Define requirements automatically.
In the image above, we look at top level of view 2.1 Define requirements. when you add a requirement in a use case, the requirement is pushed in view 2.1 in a purple box "Operational Requirements". Under this box, a second box is created named with the author of the new requirments. The same principle is applied in case a new Stakeholder is added to a Use Case. The manager of the 2.1 view is invited to move the newly added object in view 2.1 and deleted the purple containers as soon they are empty.
At this stage, any requirement added in a Use Case should be considered as an external requirement (a need in fact) and transfered to a specific enabling system. From a methodological point of view, we recommand you add a "Product needs" context system gathering all expectations from the needs elicitation. Whether these needs will be accepted or not, met or not by the design, will be the decision of the system engineer.
In case you add a function in the Use Case object, this function will be pushed in view "3.1 Define functional architecture" as a SOI internal function with similar conventions as for requirements in view "2.1 Define requirements".
Managing Variants and life cycle in Use Cases
Variants and Phases selection are available for use cases as for any other object in arKItect.
For each use case you may define relevant life cycle phases. Using the phases propagation algorithms, the phase information will be refined downstream to all requirements or parts of the Use Case diagram. This is a very normal use as Use Cases normally specify the SOI operational behavior in a given phase.