Exporting internal requirements to documentation

[david_mantripp]

Hi,

I'm a complete beginner here, so I apologise if this is a stupid question.

I'm using EA principally as a requirements management tool. I am experimenting with document creation, and I cannot find any template which includes internal requirements, created within Use Cases.  I find this a very powerful way of defining requirements, but if I cannot get the information into a report, it is of less use...

I tried setting the requirements as External, but then, it seems, I lose all linkage with the Use Case from the perspective of the requirement. I would have expected that a realisation relationship was created between the externalised requirement and the parent Use Case.

What I'm trying to acheive is this:

A document which includes:

A: all external requirements
B: all Use Cases, each with internal requirements and scenarios

Is this possible ?

Thanks
David

[Paolo F Cantoni]

Hi David and welcome,

If you search for: Responsibilities Requirements
posted by:  PaoloFCantoni
going back: 999 days

You'll find some discussion on the "internal requirements"  - which really aren't.

Conceptually, the notion that a requirement can apply to ONLY to a single element is fundamentally flawed.  However, the notion that there should ONLY be one element to discharge a specific responsibility is the basis of the object oriented paradigm.

If, after searching, you have specific questions, we'll (the forum participants) be glad to answer them.  Similarly, if you have contrary viewpoints, we'd love to hear them...

HTH,
Paolo

[david_mantripp]

Phew....  can of worms+  

I do agree that there is some degree of confusing in the concet, but then again, the day somebody finds a requirements methodolgy that everybody agrees with, Satan will be skating to the office.

I was starting to think of "internal requirements" as, basically, lower level requirements responding to the specific needs expressed through a Use Case, and "external requirements" as higher level more generic statements.  There are writers who argue that you can model a complete system's requirements using Use Cases only (I don't actually agree, and the reasoning behind it is laboured at best), in which case you'd have a very solid argument in support of responsibilities = requirements.  

I think it depends on how you approach modelling. If you tend to start off with Use Cases, then naturally you tend to associate requirements with these. EA seems to support both a top & bottom down approach, which is, inevitably, as prone to confusion as it is to flexibility.  Where I have a problem is that fundamentally a requirement is a requirement, and if I generate a doc using the requirements template for the whole model, I expect to see both internal and external requirements, and I expect to see internal requirements assocations with use cases in the Relationship Matrix.

Having said all this, EA is a fantastic tool at a remarkable price.

[Paolo F Cantoni]

EA Requirements are just requirements (not internal/external) - you are still a newbie (no offence meant) and haven't yet figured out that EA's UI (Unique Interface) is not self consistent.

Things are not what they seem.  More importantly, things are not necessarily as documented.  You've already struck one example - forget what EA calls them; "External" requirements are just requirements.  If you absolutely need to to differentiate between the two kinds, then stereotype the requirement accordingly.  You can even (theoretically - since EA doesn't yet provide this level of OCL support) impose a constraint that an internal requirement cannot be connected to more than one element.  This has the benefit that all requirements are now listed in the Relationship Matrix and will appear in your documentation.  You can visually check that any "internal" requirements have only one link specified.

YMMV HTH,
Paolo

[david_mantripp]

Thanks for your help Paolo, much appreciated!