Script to fetch requirement?

[Hurra]

Hello!

This is more of a method question, perhaps the thread should be moved.

I have high level requirements, or capabilities, which is related to requirements. Depending of requirement level, 1, 2 or 3, the requirement have different requirement components.

Example:

High-level/capability: The application should have authorization control

Requirement: User should have an unique identity
Req component (depending on level): Everyone should have unique identity, an identity may not be re-used

Depending on how this requirement is leveled, different req components apply. Let's say level 1 corresponds to "Everyone should have unique identity" and level 2 is both of the req components.

Each high-level req/cap has several req, each req has several req comp.

My question is about the best approach to model this.

Should each of the requirement levels be an object? I.e. "User should have an unique identity LEVEL 1", "User should have an unique identity LEVEL 2", etc. Then it is easy to just collect corresponding req comp.

Or create instance of "User should have an unique identity" and set a tagged value of the level? But then I need a script or something to collect the correct req comp since the req comp depends on the chosen level of the req.

I would also like to for each req comp, relate it to an interpretation. So I guess all the req comp's needs to be instances and related an interpretation element, otherwise we can't know how the req comp was interpretated for a speficic project.

How do you see this? Model with elements and script, or instances? Would love some input!

Robert

[qwerty]

I don't think I get what you're really after, but this is what I did: Requirements go into two main packages, namely Functional and Non-Functional. Functional requirements will be sorted into sub-packages resembling identified use cases and will be linked with <<trace>>. The Non-Functional is more or less fixed subdivided into sub-packages you can find with a google for "non-functional requirement" and will end up in something like Performance, Legal, Security, etc. There's a bunch of possibilities but it will sort out into a dozen or so depending on the system under consideration. Whether or not you use some external RM tool depends (on the requirements :-).

I never found structuring requirements very useful, but I stayed rather with the flat structure described above. So I never had a super-requirement that links sub-requurements. Instead the identification of its system-relation and placing it near the right use case was more important. Non-Functional ones of course are not linked to any single use case but have a more general use and thus end up to be linked with lots of use cases.

q.

[Hurra]

Well, the thing is that we have a document defining "minimum" requirements in certain areas like functional security requirements. These will ALWAYS apply no matter project, but varies with the mentioned levels.

Therefore we would save a lot of time building up this requirement library and always reuse requirements. Of course each project will have project specific requirements but the minimum requirements should come from the requirements library.

And also, this is how the guideline/policy is structured, perhaps I don't have to follow the structure when I model it. But I would like to have a re-usable requirement library which takes account for chosen level.

[PeterHeintz]

Hi RWHurra,
there are so many ways how you can characterize the level of your requirements.

E.g. you can just put each level to a own package, or you can use a stereotype, or you can use a tagged value, or you can use a <derive> relationship, or you can use a….
There is no best approach, you need to now some approaches and you have to decide what fits best to your needs.

Thinking about requirement instances typically is not a good idea.
To get a requirements library to be used in other projects can also published this lib in several ways (without having a best approach). E.g. you can do that by XMI export/import, by a version control system, or by the EA-asset service (all in fact are based on xmi).

[Nizam]

Well, the thing is that we have a document defining "minimum" requirements in certain areas like functional security requirements. These will ALWAYS apply no matter project, but varies with the mentioned levels.

Therefore we would save a lot of time building up this requirement library and always reuse requirements. Of course each project will have project specific requirements but the minimum requirements should come from the requirements library.

And also, this is how the guideline/policy is structured, perhaps I don't have to follow the structure when I model it. But I would like to have a re-usable requirement library which takes account for chosen level.

There are quite a few ways as its mentioned in the thread, however We've implemented these things mostly using Tagged Values. To be more specific, we've defined a extended requirement, which on drag /drop will prompt(with a sub menu) on what level it is.

Once it is done this way, you can use EA queries, Kanban lanes, Graphs, Charts and reporting templates to work based on the tagged value.

Grouping in other ways are useful too, however  visualizing / reporting needs some additional efforts.

[Hurra]

Thanks for your replies!

I will read up on diferent approaches and choose accordingly.

Regarding not creating an instance of requirements and relate to intepretation. How would I collect the intepretation?

Lets say we are designing IT-system x. We relate to the minimum requirements mentioned earlier, with different levels and therefore know the "sub" or child requirements. However, if I go one step further, and collect related intepretations, we would collect all intepretations, including for other projects.

Im thinking scripting now. Start on IT-system x, the script collect all req and sub-req. Then we collect the intepretations. Then I guess I would need a loop to check if the intepretation is connected to IT-system x? This doesn't seem efficient. I'll go the same path twice..? From IT-syst to intepretation and then back.

[Geert Bellekens]

Using scripting to traverse a model is very slow in general.

Often SQL queries much better for this type of work. Major downside of using SQL is that it is hard to do anything recursive.
So if the (maximum) depth of the tree is unknown you might need to use some kind of scripting solution anyway.

But still then it will pay off to use SQL queries on each level recursively to get the elements, rather then iterating all the connectors of all the elements.

Geert