Part 2(assignment)-what goes into Technical Risks and what goes into Design decisions

Assumptions are straight forward-one should put what all assumptions he/she has made to arrive at the solution and moreover what all deviations he/she has made from the original assignment.

But what should go into Technical Risks and what goes into Design decisions?

Design is what were you thinking about when you created the architecture. Anything you want them to know.

Risks is what you can think of that could go wrong and cause a problem.

To add to what Jeanne has said

1. Any implicit/explicit assumptions you make while defining the architecture is a decision. Sun wants you to document such decisions under the 'assumptions' section and
explain the impact of such decisions(how did these decisions sway your architecture?).

2. A technical risk is a 'potential problem', What are the potential issues that can arise in such a problem statement. The part which sun is interested in is 'How valid are your problems - do they really have a impact and are you able to identify the major ones correctly?' . The next part which sun wants you to answer is 'How does your architecture mitigate these problems?'

Together, they help you defend your decisions and your architecture

HTH

Let me disagree a bit with Rahul. Risk is something that may happen after the SuD is implemented according to your architecture. If the SuD mitigates the risks - they are not risks any more. They are your technical decisions.

Copying the text from Mark Cade and Humphrey Sheil's book Sun Certified Enterprise Architect for Java EE Study Guide - 2nd edition:
"A technical risk is something that is unknown, unproven, or untested. Risks are usually associated with the service-level requirements and can occasionally be associated with a business requirement. Regardless of the type of risk, it is easier to address the risks early in the project while creating architecture, than to wait until the construction phase of the project, when you have a large developer base that could potentially be waiting while you are solving risks."

So i can deduce that technical risk is like- let's say SuD has some interface with external system-what if that external system is down or responding slowly? - it might impact the NFR of the SuD. So for me this is a technical risk and the proactive solution to take care of that risk is a mitigation.