• risk: nature of software
• risk: team dynamics
• risk: roles
• risk: resources
• risk: analysis
• risk: architecture
• risk: design
• risk: implemention
• risk: quality assurance
• risk: project management
• risk: technologies
• risk: tools

There is no sharp distinction between software architecture versus design and requirements engineering. They are all part of a “chain of intentionality” from high-level intentions to low-level details. This reality is actually what makes the waterfall model incorrect.

It may seem too obvious of a mistake, but I've seen many projects where they start coding without any application design. In this case, there is a good chance of project cancellation because what coders produce in this scenario is just a guess.

If the project survives that, it will probably require a lot of iterations. Design iterations after significant coding or customer release are typically very expensive. Changes later in the SDLC tend to be a lot more expensive than earlier.

The best option is to iterate the design using mocked up wireframes. There are tremendous advantages to completing the design prior to coding. Developers will know what to develop, and testers will know how to test. With the design documented in an SRS, it becomes feasible to use off shore resources. This would normally increase project risk, unless one has found that very rare group of high quality resources.