In all my experience decomposing functional requirements from the top down through a hierarchy and successfully using that hierarchy as the basis for building and implementing some pretty cool systems from the bottom up, it shames me to admit that I do not have a guaranteed method for ensuring that all the levels in the functional decomposition hierarchy are at that perfect place to decompose no further.
The question is: What are the tangible flags or indicators or signals to use that confirm that functional decomposition to a given leaf is both complete and correct so that algorithm design can commence.
Continue decomposing functional requirements into smaller requirements until it becomes possible to write a clear, specific, measurable test for each and every smaller requirement such that, when the test is executed and passes, both the customer and the development/QA teams can unambiguously declare that the requirement has been met.
A requirement describes something that a software has to comply with, no matter how the software is written. Example: “As a sales clerk, I need to register the customer’s order“.
You decompose requirements into finer grained requirements, as long as those still describe the problem and not the solution. Example: “As a sales clerk, in order to register the customer’s order, I need to find existing customer records and, if necessary create a new customer record with identity and address“.
As soon as you start describing the solution, you’ve started the design. Example: “I need to enter the name in customer’s field, and if the the name is not known, a pop up has to appear to register a new customer“. Here you describe a solution and not a requirement: your software could solve the problem in another way, if you’d wanted.
The sliding from problem world into the solution world is not always that obvious. As a rule of thumb, you should as yourself: “Could it be done differently ?”. If yes, there are chances that you’re already in the design.