While trying to create threat model template for customers, I analyzed many threat models inside and outside Microsoft.  It was insightful to see the patterns of what was useful across threat models and what was noise.

A good threat model has the following components:

• Security objectives.  What must you do vs. what's nice to do?  These set the boundaries of what's in scope vs. what's out of scope.  
• Key Scenarios.  Where and how will your software be used? These put your software in context and gives you context while evaluating.
• Security mechanisms.  These shine the spotlight on explicit security engineering decisions.
• Trust boundaries.  These help you focus on critical places where security trust levels change.  These also help prioritize entry points.
• Data flows.  These help you trace data through the system, to expose potential issues.
• Entry points.   Where do you accept input?  These are primary attack vectors.
• Exit points.  Where do you write output?
• Threats.  A list of these helps you put perspective when ranking vulnerabilities.  What's the worst that can happen?  What can you live with?
• Vulnerabilities.  A list of these helps you identify actionable places in your software to address security concerns.

A good threat model serves the following purposes:

• Informs your design
• Scopes your security testing
• Helps reviewers evaluate your security decisions

By far, the most tangible output of the threat modeling activity is a prioritized list of vulnerabilities.  These are action items for your developers and input for your testers.  The developer makes a call on whether and how to fix, and the tester will test the fix.

This sample Template for a Web Applications Threat Model comes very close to showing what I've empirically seen to be useful, though there's always a gap between reality and real-time.