How to find requirements/use case

[ebeb]

Hi,

I'm trying to find requirements, that do not have a use case associated and vice versa.

I can find them by looking at the relationship matrix. I've associated them using a requirement -> realizes -> use case relationship.

But I've got too many and I lost track using the rel matrix. Is there a way to use a custom search to find element have a special relationship or respectively not having it? I couln't find any useful search filter.

thanks a lot!

Jan

[Dave.B]

This is where you are forced to use SQL to traverse the underling EA database. The basic idea is to select the requirements in the t_object table, then traverse the links from each requirement via the t_connector table to other elements in the t_object table that are filtered down to just your use cases. It helps if you have been very consistent in the source->target direction of these links as it affects the design of the SQL query.

Since I'm no SQL expert I use SQL Drill to help me develop such queries. It's a free add on to MS Excel; find it with Google. (However, our model is held on a MySQL database which is easy to connect external database query tools to. If your are on a standalone .EAP model file then this might prove more tricky - I've never tried it.)

Hope this helps
Dave B.

[Luis J. Lobo]

Hi,

Right click over the Requirements package, and select "Documentation --> Implementation Report..."

But be carefull with the "realization" direction. The correct is:

requirement <- realizes <- use case

[ebeb]

Thanks, Luis...that seems much easier than using SQL since I'm really not the SQL expert.

But, it doesn't really work (it displays that all requirements are unimplemented) which are a result of the direction of the realization. I think this is a misunderstanding...

My idea was: Use Cases are a way to find requirements. That means I create use cases first. From the use cases, I deduce requirement. That's why I thought, the requirement realizes the use case.

Could please explain, why it should be the other way around?

But, I just found a way by selecting the use case package and using the Implementation report. That works and shows all requirements that "realize" a use case.

Thanks, Jan

[ebeb]

Ok, one additional comment: Using the use case packages only shows if all use cases do have requirements attached. But theres no way to find out if all requirements are related to a use case.

But there is no was to switch the relationship direction of the Implementation Report.

[Oscar]

My idea was: Use Cases are a way to find requirements. That means I create use cases first. From the use cases, I deduce requirement. That's why I thought, the requirement realizes the use case.

Could please explain, why it should be the other way around?

Well, in an ideal world you start with a set of (high level) requirements.
And then you create use cases to meet (realize) these requirements.


Looks like you're reverse engineering the requirements.

Hth,
Oscar

[paddler]

Hey there

 there is so much nack and forth on what requirements are that it is hard to get a consistent story. I have come to the personal "comfort zone" of realizing that there will always be "high level" functional requirements (ex: System must provide a secure login) together with Behavioural requirements - expressed in use cases that describe how the system meets the high-level requirement.

Compounding all of this, I don't think UML documents a precise means of capturing requirements!!!

 If you take a peek at "Use Case Driven Object Modeling with UML" by Doug Rosenberg ..p386 he advocates showing use case->realizes->requirements (i.e. The realize connector is pointed from the Use Case to the requirement). Since his books is centred around Enterprise Architect I like to stick to his thinking.

You can see more at www.iconixsw.com

Cheers
PT

[ebeb]

Hmm...intresting!

I was talking about functional requirements. Its clear, that there need to exist some high level architectual requirements containing the key ideas/features.

But as explained in http://www.bredemeyer.com/pdf_files/functreq.pdf:

Use cases are useful in capturing and communicating functional requirements, and as such they play a primary
role in product definition.

I was not trying to realize high-level requirements by use-cases but to realize use-cases by functional requirements.

[Geert Bellekens]

Ebeb,

I still think you somehow have mixed up how usecases and requirements are related.
A requirements is what a user wants.
A usecase expresses how the system will work (in a blackbox kind of way) to realize the requirements.
Of course the process of discovering the requirements, usecases and other model artifacts doesn't happen in a linear way. It is perfectly sensible to discover the requirements while documenting the usecases, but that doesn't reverse the relationship.

Anyway, if you want to have a clear view which requirements are realized by which usecases (and which requirements are NOT realized) I think you are best of creating a matrix crossing usecases and requirements.

Geert

[Oliver F.]

A requirements is what a user wants.
A usecase expresses how the system will work (in a blackbox kind of way) to realize the requirements.

Stop. I have to interrupt here as in staged development processes (call them waterfall, V model or whatever you like) the term "requirement" is often used in a different way. Eg. if you hand over artefacts to a different section of your process then these artefacts become input requirement for the new phase with the customer being the previous process actor.
Eg. a use case produced in the requirements analysis and engeneering phase can then be a requirement for a system design.

It is hard to stick with the term "requirement" in the strictest way when reality has just passed by

Oliver

[Paolo F Cantoni]

Hi Ebeb,

Listen to Geert - he has explained it properly.

By the way, if you are using the Bedemeyer paper as your guide then be aware that the use of Primary and Secondary for the Actors that is used in that paper is not in accord with normal usage.

An ordering, such as primary/secondary, is only valid when you are considering values in the same dimension.  In this case the paper isn't.

I haven't read the full paper yet - but I was surprised to find such an error so early on.

HTH,
Paolo

[Geert Bellekens]

Eg. a use case produced in the requirements analysis and engeneering phase can then be a requirement for a system design.

Oliver,

I agree with that, but I don't see the conflict with my statement.
As I see it the requirement is the "WHAT" and the usecases describes the "HOW".
Now in the development process I can imagine that the usecase is being used to pass on the requirements to the next stage. To me that only means that the requirements (the WHAT) at that moment are implicit, and have to be worked out by the system designers based on the description of the usecase.
If you really wanted to you could extract a set of explicit requirements from the usecase and pass that on to the next stage, but that I guess that is sometimes not worth the effort.


Geert

[Paolo F Cantoni]

[size=18]...[/size]
Stop. I have to interrupt here as in staged development processes (call them waterfall, V model or whatever you like) the term "requirement" is often used in a different way. Eg. if you hand over artefacts to a different section of your process then these artefacts become input requirement for the new phase with the customer being the previous process actor.
[size=18]...[/size]
Oliver

NO,

the output artifacts of one process become the input artifacts of another...  They don't become requirements!
  
Although I was born in the UK, English was NOT my first language.  English speakers tend to be the sloppiest and especially when speaking colloquially - so the rests of us who weren't native speakers can easily be led astray.  

It took me a LONG time (twenty odd - some of them very odd - years) to fully understand that there is NO substitute for rigour in systems development - starting with the definitions of terms in an ontology.  EA even provides an embryonic Glossary for this purpose!

As I've said before:  I got started on this, modelling "lark" thirty years ago when an obscure French professor of Informatics (J.R. Abrial on of Bertrand Meyers' teachers) wrote:  "The reason we can't build systems that work is that we can't unambiguously define what we want to each other".

Thirty some years later...  "The reason..."

Requirements are NOT Artifacts and Artifacts are NOT Requirements.  The (non)existence of an artifact may be a requirement.  Requirements many be contained, or discovered, in Artifacts.

We need to clearly separate the Validation from Verification processes (to quote the V-model).

See my previous post about the Bedemeyer paper...

HTH,
Paolo

[ebeb]

Hi Geert,

I know what you mean, but I still think the "workflow" I use still makes sense. Requirements are "older" compared to use cases. That means people once used only requirements (architectual and functional) to design the system. As of my understanding, use cases are a tool to find the functional requirements. You won't create use-cases to describe exactly how a system would work (this could be done by activity diagrams etc.). Instead you use it to get an overview of the structure and complexity of your system and then deduce the requirements from it. As I explained before, there surely must exist some high-level requirements before from which you build the use cases.

[Geert Bellekens]

Ebeb,

I'm absolutely not  trying to say that your workflow doesn't make sense. It does, but that doesn't change the fact there will always be requirements, whether made explicit or not.
It also doesn't change the fact that the usecase "realizes" these requirements, even if the usecase was created first, and the requirements were extracted from the usecase later. (or not extracted, and left implicit).

Geert