Mapping between functional requirements and software modules

Question

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:

1. Are there commonly used names for these different types of relations between requirements and modules?

2. 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?

Answer 1

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.

Answer 2

So, don't think of it in those terms. It's multiple perspectives which create the whole picture which is very important otherwise things get missed.

• BRD (business requirements document) are elicited from the customer.
• These are then written out to quantify the customer need from a business understanding
• Technical requirements are written to translate the business need into technical terms that can be programmed to. These then get added into the RTM (Requirements Traceability Matrix)
• Use Cases are written to exemplify the scenarios and work flows that are targeted to be the completion of the product.
• RTM/Use Cases are provided to architecture to work on the Arch Design
• RTM/Use Cases and Arch Design are provided to development to work the detailed design

This is the point we are at in your question. You detailed design should adhere 100% to the arch design, which should adhere to the technical requirements which should adhere to the business requirements. This can be a many to many relationship as the technical implementation may be simple or complex, but needs to do what's technically right, whereas the business needs to articulate in a way that is business right. So the business might have 400 things that are accomplished by 30 modules where it could also be that 40 modules accomplish 9 business things. Those perspectives need to be maintained which is why sometimes it's complex and other times it's really simple.

• Test is to verify the technical and business approach which will require different approaches to testing. Proper Test Engineering is reconstructing the original and the final to provide the full picture analysis of the final product in comparison with the original intent. The more complex, the more skilled the tester needs to be. This is also why it's a completely different job as it's a completely different way of thinking.

That being said it's important that your technical modules adhere to the parts as written regardless of the number of simple or complex relationships, just as it's equally important for the other perspectives and roles to do likewise. The "disagreements" or "multi-alignments" are there on purpose to ensure the full application success as those point to possible holes and re-thinking things that may otherwise be easily accepted.