Best way to link requirements to each other

[pittagentskip007]

Hi all,

Trying to decide what the best way to link requirements to each other is in EA? So far I can compose, aggregrate, associate, or trace requirements elements to each other. I can also make requirements own each other by putting them as parent-child in the project browser.

What is the best way in particular for business requirements -> functional requirements -> system requirements?

[qwerty]

YMMV. I'd propose a <<derive>> dependency.

q.

[pittagentskip007]

thats an interesting thought. So far when navigating around the traceability window it looks at a relationship like this usign the dependency connector (with trace sterotype) as follows:

Bus Requirement 1 -> Functional Requirement 2

Business Requirement 1 depends on Functional Requirement 2
Functional Requirement 2 is needed by Business Requirement 1

I think this is an OK way to do it as it makes logical sense that a business requirement cannot be met unless a functional requirement is met.

That said, not sure why Business Requirement cannot be realized by Functional Requirement using the realization connector?

P.S. what does YMMV stand for?

[qwerty]

Your Milage May Vary

Requirements realizing Requirements: that does not make sense, does it? For that reason UML has quite some restrictions on what connectors can be used.

q.

[Geert Bellekens]

Hmm, I'm not following.
How can a Business requirement be dependent on a functional requirement?
It's the functional requirements that exists because of the existence of the business requirement isn't it?
Look at it this way, if my Business requirement changes is my functional requirement affected? In that case my functional requirement depends on my business requirement.
If I were you I would do trace relations, but in the other direction.
so technical -> functional -> business

Geert

[OpenIT Solutions]

Doesn't some of the built in Sparx capability expect a "realisation" between a requirment and an element (which would include another requirment). Ie the RTF requirement sections look for realisations

If so despite what might be best in UML, you might end up using a realisation ?

Just a thought...

Regards,

Jon.

[qwerty]

Hmm, I'm not following.
How can a Business requirement be dependent on a functional requirement?

Right now I have a real example. Due due a technical constraint the business is influenced (some cabling limits business functionality). So you can have dependencies in all directions.

q.

[Geert Bellekens]

hmm, you might be right.

Geert

PS. Damn, its hard to admit you're wrong

[qwerty]

I wasn't aware of this since mid last week...

q.

[pittagentskip007]

Look at it this way, if my Business requirement changes is my functional requirement affected? In that case my functional requirement depends on my business requirement.
If I were you I would do trace relations, but in the other direction.
so technical -> functional -> business

Yup that works for me and that is how I originally had thought of it i.e. I normally think of traceability backwards: system requirement was derived from functional requirement. Just was wondering what others thought.

[Doug Blake]

I have a hierarchy of requirements, and in the end, the leaves of the tree are the true requirements of the system. Linking between nodes of the tree I use realisations. The reason is that if you do a Model Validation of a package (Ctl-Alt-V) EA warns that requirements arent realised.

I would encourage all to look at the options for validation, they can be insightful when questions like this arise.

[Robert Sheridan]

We tend to reserve the realization link to show that the requirement has been incorporated into a design element such as a use case.  

I use connectors between requirements only when there is some form of dependency between requirements in different parts of the hierarchy, my reasoning is that I have often inherited complex requirements from contracts which have unrelated elements. Decomposing the requirements is difficult and it is easy to forget to delete connectors which no longer apply as the parts of the requirement are distinquished and moved into different bits of the hierarchy.  The original structure can either be retained by using a tag value for the original id or by keeping the originals in a separate node and linking the decomposed parts of each back to it.

[qwerty]

We finally came to the conclusion that it is not worth while to decompose requirements (and thus to build relations between them). The reason is the following. In their specification the customers request "something" which is written down as words/sentences/paragraphs/chapters in a specification document. What the customer actually thinks of this "something" must be read and interpreted out of this document. A good way to reflect (and show the understanding) of this "something" is to write use cases. Once you synthesized all use cases this is a good way to negotiate with the customer about that "something" and it is more likely to deliver what the customer was thinking of. So-called requirements are only linked via satisfy or realize from the use cases to the original sentence/paragraph. Break-down of the customer specification into single identifiable objects can be done using a tool like DOORS. (Of course the whole process is much more complicated than what I wrote here. Not to mention non-functional requirements and a lot of other bits and pieces.) The use case documentation is signed finally by both parties.

q.

[Matt Thomas]

Hmm, I'm not following.
How can a Business requirement be dependent on a functional requirement?

Right now I have a real example. Due due a technical constraint the business is influenced (some cabling limits business functionality). So you can have dependencies in all directions.

q.

I think where a constraint reigns in the business requirement, there are different ways to express this. One way would be to have a domain model where constraints are identified (i.e. don't think of them in terms of functional requirements) and then you've a simpler job of recording the fact that your business requirements trace back to some technical constraints in the domain.

Then you can get on with cleanly representing the solution requirements  to meet the business requirements using UML consistent dependencies.

You see, just because the constraint may have been identified after the business requirement was initially mooted, doesn't mean you have to consider it as a functional requirement.

Only a suggestion.