If your software is being developed as part of a bigger system, especially with teams that don't communicate on a daily basis, you should include a functional view (as in the 4+1 model).
One important and often overlooked aspect of documenting your architecture is the definition of the interfaces you provide, despite it being one of the most important things to describe. Whether it's an interface between two of your components or an entry point for the outside world, you should take the time to document it clearly, describing the semantics of objects and calls, as well as usage examples (which you can sometimes reuse as tests).
Another great benefit of including a functional view in your documentation is that it clarifies the responsibilities between components of your system. Each team developing the system should understand where the boundaries are and who's responsible for developing which functionality. All requirements should be explicitly mapped to...