Many people are familiar with information hierarchies in the form of menu structures - the path one needs to take in an application or website to access this or that function. These are ideally structured to fit users' mental models about how the information should be displayed.
However, when planning the development of a system, it can also be very helpful to define functional relationships at a more abstract level than just how the menus are arranged. Maybe there are completely different software applications used by different user groups that share some of the same information; a function structure is one way to map out these relationships between system components.
One benefit of this type of thinking is that the team can stay focused on the functions needed by the end user, rather than getting caught up in the limitations of a specific solution. For example, what if the function needed is for different people to communicate about system status? If you define that function as "email system", you've left out many other methods for communication such as instant messaging. The point is to focus on the functions needed, not the specific solutions. That comes later, after the functional relationships are known.
Another example: if one part of the system needs to work in a way similar to another part, a function structure can help the team identify opportunities to reuse the same code or component in the solution.
Here is an example of a function structure for health care charting, order entry and order management. Some functions have been obscured but the idea is that once the functions are organized and arranged in an affinity diagram, it is easier to see the relationships between functions and where meta-functions like data transfer will need to happen.
Function Structure