I feel very strongly that the more complex your business process is, the more well-defined your requirements must be. The analysis of these requirements also becomes more and more important and less and less possible by the SMEs and end-users.
The reason for this has to do with the definition of ‘complex’ used in the context above. In this case, ‘complex’ refers to the number of connections between different parts of the system.
The more connections there are, the more impact a change or addition will have to the overall system.
This is an important difference from the traditional idea of complexity. It is not the sheer number of actors, use cases, and requirements that determine how difficult a system is to analyze. It is the number of connections and dependencies between these objects that leads to difficulty in analysis and documentation.
A system with a large number of use cases is ‘large’ as opposed to ‘complex’. The documentation for such a system may be much more extensive, but if the use cases are relatively isolated, the process will be easy to understand. The green figure represents a ‘large’ system while the blue figure represents one that I would consider ‘complex’.
How, then, should you document and analyze requirements for complex systems? The key is in segmentation and use of internal references.
Segmentation of requirements ensures that you don’t have too many connection points within a set of requirements. You try to have as many connections on the ‘ends’ as possible. In use case terminology, you should have more connections in your preconditions and postconditions than you do in the body of the use case.
Why? When reviewing and analyzing properly segmented requirements for a complex system, you can separate the analysis into two buckets – the individual subroutine-like components and the connections between them. Without this division of information, you will be forced to analyze a very complex flow and may never truly understand what is going on. Breaking the problem down into consumable ‘chunks’ gives you much greater confidence that you understand what is going on. You can verify each section independently and then circle back and verify the connections between them.
Internal references in the requirements are self explanatory. You should err on the side of too many internal references. I commonly insert a reference in a requirement that points to the requirement directly above it.
This strong referencing ensures that as one requirement changes, you can find all of the affected requirements quickly and accurately.
A requirements management tool can help with these references tremendously.
The next time the process flow for your system looks like a bowl of spaghetti, think about breaking down the problem and defining the relationships between the requirements at a more granular level.
