Use case realizes requirement

[DanG83616]

When I connect a requirement to a use case using a realization in a diagram EA always makes the use case realize the requirement. Is this a bug or am I thinking about the relationship incorrectly? Use case scenarios illuminate features and requiements so I think of them as being derived from the use case. Perhaps I should be using a trace instead?

Thanks,
Dang

[KP]

In UML, a Realization is an Abstraction (i.e. the source and target represent the same thing from different viewpoints or at different levels of abstraction) where the client (source) is more concrete/less abstract than the supplier (target).

The typical situation is that the Use Case adds detail to the Requirement, so a Realization from Use Case to Requirement is appropriate, and that's what EA's quick linker gives you. If your process uses Requirement elements to add detail to Use Cases, and there's no reason why it shouldn't, then you will need to draw the Realization in the opposite direction.

However, if the relationship is not an Abstraction as defined above then maybe a Dependency would be more appropriate. A Dependency is a relationship where the client (source) requires the supplier (target) for its specification or implementation, which is vague enough to be suitable for most purposes

[Geert Bellekens]

The idea behind this is that you start with requirements.
Your user wants some thing to be automated and these wants can be captured in requirements.
Then you start creating usecases where the requirements of the user are actually realised (therefore the realisation relation).
After the usecases are finished the actual design and implementation of your system is done based on the defined usecases.
So in levels of abstraction your requirements are higher then your usecases.
This is a representation of the classical (RUP like) analyses method. Offcourse the reality is never this linear; you will discouver requirements while working on usecase scenario's etc...

But, if it works better for you the other way around, by all means, go ahead. In analyses methods there are multiple "correct" answers.

[DanG83616]

Thank you for the helpful perspectives. I am finding that it is easy to get bogged down with requirements when there isn't a clear rationale. Starting with use cases helps to stipulate the user goals and establish a rationale. From there the scenarios describe how the user wishes to use the system to accomplish the goals. The requirements then tighten up the specification to enable verification. In this progression the use case tends to be more abstract than the associated requirements. Sounds like this isn't how things are normally done but is working for me at the moment. That said, I'm happy to get the guidance.

[«Midnight»]

Actually Dan, you've got a pretty clear picture.

Part of the problem is that in common usage "requirements" can mean two different things.

For some collective meaning of "we" it could go either or both of the following ways. Sometimes we're talking about "what I'd like to accomplish with the system" (which would be before the use cases). Sometimes we're talking about "what I'd like the system to do" in the sense of (some higher level of) specifications (which would be after the use cases).

What you are describing is a very reasonable take on the latter case.

HTH, David