Branch at the highest possible point in your tree. IE, it should include the code for all of your projects, shared modules...and probably things like documentation / build scripts / installers / etc as well. Why? Why not! Branches are cheap in all of the systems mentioned so far (SVN, TFS, Perforce, git).
This tactic is especially important in systems that use "path space" branching (TFS, Perforce). Otherwise, generating a build of the complete product suite that's consistent across different people's workspaces becomes a maintenance nightmare.
Once you've put this into practice, you're free to modify as much or as little of the codebase as you like in a given branch. You can always do a full build to verify integration issues; the option of merging any component(s) between any set of branches remains open to you. But the question of SDLC strategy is entirely orthogonal. You can branch per-feature, per-team, per-release or any combination of the above; you can define forward / reverse integration criteria however you like.* The fact that each branch happens to be a superset proves advantageous in many strategies, and should never be a con so long as your tools are up to the challenge.
*Picking a strategy is an individual matter that depends on lots of factors. Others have suggested some well known docs that help you decide. I'd put the most recent revision of Microsoft's TFS guidance up there with the best of them.