Heavy requirements suck - I figured out last month that software development processes are a tool for managing the business of building software. Processes should really be orthogonal to the act of envisioning and crafting software, as when processes are coupled to the act of building software they trip up the focus on the end goal -- that of building quality software. Not that process themselves are bad, but they are an unbearable burden when tightly-coupled or overweight. In fact, a heavy set of processes attached to a software project will result in bad software, and likely project failure.

The problem is that the business of developing software is difficult. Processes are applied to mitigate the various risks, with the goal of optimizing the business and controlling various software qualities. The business of making software a business, though, makes it difficult to make the software itself (it gets in the way, obscuring the goal). This of course requires a careful balance between being a business and making software.

The concept of agile development is to decouple the process as much as possible. Use the good bits, but allow the crafting of the software to be done with minimal impediments. Agile development, and orthogonal processes require that the business can trust those crafting the software.

I think this makes the prospect of outsourcing development more difficult, as trust is harder to find. Interfacing two companies usually requires a great deal of business process, in addition to any mechanisms required to interface disparit software teams and product thinkers. All that process tends to get tangled into the craft of building things, to the point that software products become the output of the process.

It is a terrible thing for software, when it becomes the bastard child of business concerns. Applying techniques that are focused on business ideals, like symetrical decomposition (which makes traceability easier), makes it dificult to see the how particular features are meaningful to the end vision. In fact, the vision is usually lost in the retarded depths of detail.

Software development is complicated, and records of domain (and design) decomposition are useful -- but these things need to reflect the vision and passion of the application concept. Decomposing a problem using a process like the Unified Rational Process results in thousands of artifacts that all look the same. Any concept of importance is lost, passion is whitewashed away, and vision is lost.

There needs to be some balance towards making a good product, rather than meeting the busiess need of completing every point of decomposition (to prove completeness of a phase of a project). The whole point of decomposition is so that you can recompose the ideas into something that resembles the initial concept, so the further away from the idea the decomposition brings you, the more work you need to do to get back to it.

This is one of the reasons that the approach of Open Source Software is so productive: business concerns are removed from development. Many OSS projects apply various processes to their efforts, but they're generally agile, and used to improve various aspects of what they do ... and aren't often heavy.