Use Case and Requirement

[Kamal Hammoutene]

I have have a trouble choosing between the right connector and connection direction between a Use Case and a Requirement in a specific modelling style:

I create Use Cases and in the Scenario window, I enter a text that I want to be a Requirement shown on the Use Case diagram. What I am trying to model is that the requirement is derived from the Use Case; for example, in an ATM contect, I would create a Use Case "Identify bank customer" and I would write a scenario and in the course of the scenario, elicit a requirement such as "The ATM shall prompt the user for the card PIN".

But when it comes to showing the relationship between the Use Case to the Requirement, I don't know which type of Requirement relationship I should use and in which direction i should draw the relationship (either from the Use Case to the Requirement, or from the Requirement to the Use Case). The relationship and direction choices have a big impact of the type of information that is shown in the traceability window.

If you use SysML, you may want to use the "Trace" or "Refine" relationship. if you don't use SysML, you have only the choice between an Association and the Implements relationship.

As EA is allowing to trace a lot of relationship types, what is your advice and practice?

[g.makulik]

Intuitively I'd say a Use Case implements a Requirement, where a Requirement might need to be implemented by more than one Use Case.

But I can't tell if this would be the 'right' way to do it. I've been using simple <<trace>> dependencies (directed from Requirement to Use Cases) earlier on Requirement Analysis and it worked well for me (I could report the Requirements coverage with Use Cases defined).

HTH
Günther

[qwerty]

<<trace>> is common use. SysML uses <<satisfy>> which is a bit stronger in its meaning. In the end it is up to the model users which convention they stick to. However, what Günther said is right. A single requirement must be satisfied by at least a single use case. It is also possible to <<refine>> requirements. That is if you have an unspecific requirement formulated by the customer you might need to ask for the specific meaning. From my personal view it's not a good way to model requirements since they should be atomic (you might google for SMART requirements).

q.

[g.makulik]

It is also possible to <<refine>> requirements.

Good point. I'm actually using hierarchical organized requirement specifications (Polarion painfully, not EA  ), and usually I can't assume requirements to be atomic as they come from our Product Management Department, neither from HW development team as well.
But they'll boil down to atomic requirements of course. We're even trying to use a 1-2 sentence schema (with similar consistent semantic keyword styles as used for e.g. RFC documents -> MUST, SHALL, CAN etc.) to formulate the atomic requirements.

[Ian Mitchell]

In these areas where there are several alternatives, and where the average reader of the diagram won't instinctively know the right answer, my advice would be to pick a fairly obvious connector type (any of the above suggestions are fine) then:
- document it (maybe on each diagram)
- stick to that style.
I'll prefer readable consistency to UML purity any time. (and I teach UML...)

[philchudley]

By using the quicklinker, you should see a Realization link, (satisfy in SysML) which would be my choice. The direction is from Use Case to Requirement

Why Realization, well a use case realises the requirement, but more importantly certain tools in EA make use of the fact the Realization links exist between elements and requirements. One, is the [highlight]Project | Model Validation | Validate Selected... [/highlight]which will give a list of those requirements with no Realization link (also for Satisfy in SysML), the other is should you choose to use EA's RTF documentation generator  :-/, then the list of realised requirements is available as an output selection alongside the element data.

Best regards

Phil

[Gary]

Another school of thought.
A use case cannot <<satisfy>> or <<realise>> a requirement because it is not a physical thing and does not end up as a physical thing. It is there to describe functionality and <<refine>> our understanding but does not implement functionality in a real tangible way. Classes/blocks/interfaces that are identified and then created as part of use case development are tangiable elements that can <<realise>> or <<satisfy>> requirements.
So i would say use cases refine requirements. You could create a new stereotype in your model called <<refine>> and then use that.
That is just my thoughts on the matter and how we do it at my company. Feel free to ignore or implement as you see fit
Just for information the <<realize>> connector is only mentioned in the SysML spec as applying between blocks/classes and interfaces and block/class to block/class.

[qwerty]

If you look down from a UC you will find that they are realized by Collaborations which contain finally classes that actually <<realize>> a requirement. But from a customer perspective you must tell that all requirements are to be found somewhere in the system. <<refine>> (my point of view) has a different semantic. Only if you draw it from the Requirement to the UC. But that's not system analysis. It would be just the opposite: you have an exiting system and verify that the customers requirements are met.

It probably depends on the system philosophy.

q.

[Graham_Moir]

I have have a trouble choosing between the right connector and connection direction between a Use Case and a Requirement in a specific modelling style:

You may want to have a look at this interesting thread on this topic !

http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1254384857/0