You will have several problems with that approach. First of all, requirements are very rarely (if ever) in one place and very rarely written in stone. You will not be able to find all the pieces of the puzzle and the pieces you find might be out of date.
Your best bet is to understand the 'requirement' on the class or method level. Most open source projects have good documentation on the source level. Once you read the documentation of the method or class, then start looking at the code and see how they try to implement it.
Another good exercise would be to look at the code and work backwards. Read the code and write down what the code does at a high level (pseudo code). Then look at its documentation and see how close you figured out what the method/class does.
These are good exercises when code is written well. If it is written badly, you can very quickly get overwhelmed and it can also teach you bad practices. You are lucky though, as most open source projects are tend to be written well especially when you have more people collaborating on them.