Let's say we have 5 functional software requirements (R1-R5). Our software design results in 6 modules (M1-M6) or classes to be implemented. I am assuming that the design is more or less optimal, each module having a well-defined purpose and the dependencies between the modules have been minimized.In one case the relation between requirements and modules will almost be one-to-one, as shown on the left side of the figure below. In another case (different project) it might be many-to-many as on the right side:The left version will probably be much easier to handle from a testing and project management point of view.My questions:Are there commonly used names for these different types of relations between requirements and modules?Can we say that in the highly interconnected case, the requirements are flawed and should be restructured somehow, or is it just an indication of a more complex system?
Mapping between functional requirements and software modules
design;project management;requirements
Relationship between requirements and modulesThe 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.  