Relationship between requirements and modules
The relation between requirements and modules is in general not obvious, so that you'll always end up with many-to-many:
- it is very rare that one module implements one single requirement. Usually a module implements several related requirements.
- there are often some general requirements (e.g. non-functional security requirements, or user-interface requirements such as for example the availability of a help button) that are supposed to be implemented in many if not all of the modules.
Therefore, having a highly interconnected schema doesn't necessarily mean that the requirements are flawed. It can also suggest that you're dealing with a complex system. Or that you have identified many general requirements.
How to simplify the picture ?
A first step for mastering the complexity is to decide what you want to represent:
- do you try to represent how the requirements are implemented in the system ? In this case, you can reduce the links you'll show in the diagram, by limiting the links to "is implemented in" relations. So if a general requirement is implemented in a utility module that provides the functionality to the other module, you would have only one link.
- do you want to show how modules comply with requirements from the user perspective ? In this case you can't avoid links of type "is offered to the user by", which will multiply the links.
Another approach is to envisage categories of requirements. For example:
- general requirements non functional (expected in all modules)
- use case requirements (transactional requirements, related to specific business functions: these would be expected in one module)
- utility requirements (includes or extents, used in several different use cases: you'd expect these either in a utility module or in several modules)
- user-interface requirements (expected in modules interacting with user interface modules)
How to use this this diagram to improve your system ?
So in general, high interconnections doesn't mean flawed requirements.
However, some fundamental theory on systems, like for example Herbert's Simon's "Science of the artificial", suggest that in an optimal structured system, one would expect more interrelation within a subsystem than between subsystems.
Therefore, if you draw only "is implemented in" links, and remove all the general requirements (or better, take only the use-case transactional requirements), then you should come more to a situation like the diagram to the left.
With such a simplified/filtered diagram, a high interconnection might suggest that either the use-cases requirements are flawed (still too general, or too ambiguous). Or that the grouping into modules was not ideally thought.