Taxonomy for classification of requirements

[Michel777]

Hi,

the requirements in the current project belong to different organization unit, to different processes, to different existing it-systems, to .....

All the mentioned categories are built hierarchially. A requirements can belong to more then one elements in the hierarchy. E.g. it can belong to organization unit L1_1_L2_7 and L1_2_L2_5, whereby:

L1 = Level 1 (highest level)
L2 = Level 2 (Level under L1)

L1_1 = org. unit 1 on the level 1
L1_1_L2_7 org unit 7, on the level 2, under L1_1
L1_2 = org. unit 2 on the level 1
L1_2_L2_5 org unit 5, on the level 2, under L1_2


Our  requirements:

1) to be flexible
changing  structure of categories any time
adding categories any time
2) changing relationships between requiremenst and categories also outside of EA (e.g. with eaDocx, Excel, own DB Application)
3) Setting relationships during creation of requiremenst
4) Setting relationships without using visualization (we cannot use any diagram with elements on it, because the smallest piece of requirements will have more then 30 requirements)
5) If requirement R1 has relationship to L1_1_L2_7, it should be indicated on the higher level (L1): R1 has relationship to L1_1.

A possible solution:

    I ) Question: is there a better way ?

A) Choosing an element type, which can be arranged hierarchially

    II ) Question: which one ?

B) Building  for each category a hierarchy
C) Creating relationships between requitrements and  categories

    III ) Question: how to do it ? It is not possible adding link directly   on element properties.

Thanks a lot in advance,

Michel

[qwerty]

I guess you're doing something wrong (and that independent of EA). A requirement has no level. It is a requirement and self-standing. A requirement may be related to a number of elements. You might visualize that with a context/composite diagram. Vice versa elements can have an arbitrary number of requirements. Functional requirements can be found at use case level. Non-functional even in lowest case classes. A requirements diagram in each context/composite diagram for any element is always useful. Even with 30 or more requirements linked.

The structure is not in the requirements. Its in the system. And the requirement might be sorted according to that to identify the source/stakeholder. But finally it's the system that rules. And the stakeholder pay for the system, not the requirements. The are just conditions which must be met.

q.

[Michel777]

Hi,

my description was  obviously not clear enough.

I 'm going to filter the requirements, they belong e.g. to an org. unit or to a process.   We need it to be able to analyze the requirements from different perspective. From the perspective of organiazion, perspective of process. We have ca. 10 org. unit and the processes are across  the org. Units. As I mentioned before, we expect thousand of requirements.

Briefly: the requirements has no level, the have only relationship to other objects . We need an element type, they can represent all the related "objects" ( org.unit, processes, and so on) . Only for purpose of analyze. Simply to be able to filter the requirements.

BTW: We must not draw more al 10 elements per diagram - company policy.

Thanks,

Michel

[qwerty]

Fishy, to be honest. I'm not going to argue then...

If you want to categorize you could think about tagged values expressing these levels.

q.

[Michel777]

Hi,

I'm not going to use tagged values. I prefer relationships.

Simplified:

There is elements type "Requirement" used of course for representing for requirements, named R1, R2 and R3.

There is also elements (Type = ? - that was my original question) they represent the org. units L1_1, L1_1_L2_7, ...

The fact, that a requirements belongs to an org. unit will be represented with a connector (Type = Association).

E.g.  R1 belongs to L1_1  = R1  has relationship (Association) to L1_1.

I don't know, what kind of elements to use for the org. unit.

Thanks

Michel

[qwerty]

I don't know, what kind of elements to use for the org. unit.

Use a class stereotyped <<organization>>.

q.

[Michel777]

Hi,

very last question: why not type "Role", stereotype OC_Role ?

Thanks in advance,

Michel

[qwerty]

What? Where? In which context?

q.

[Michel777]

I don't know, what kind of elements to use for the org. unit.

Use a class stereotyped <<organization>>.
why not type "Role", stereotype OC_Role ?

q.

[qwerty]

You name it. It's your domain.

q.