Risk management is one of the key characteristcs of engineering that distinguishes it from crafts. Some authors have even posited that engineering is risk engineering. Risk is the probability of suffering losses while pursuing goals due to factors that are unpredictable or beyond . Risks can be internal or external. Internal risks arise because of inadequacies in process capability (including core and support functions), and organizational structure. External risks are caused by uncertainties in external conditions.
Boehm  identified the top ten risks items. The top four in this list were personnel shortfall, unrealistic schedule and budget, wrong function and properties, and wrong user interface. According to Brian A Will, the top most risks include creeping software requirements, requirement gold plating, low quality of released software, and unachievable schedule.
Keil et al provided categorization framework for software project risks . They categorized these risks into four quadrants. The first quadrant risks relate to customers and users. These risks have a high level of perceived importance but a low level of control possibility. Hence, mitigation is essentially done by increasing users’ participation and commitment to the software project. The second quadrant risks relate to ambiguities and uncertainties about scope and requirements. These risks have high perceived importance as well as a high level of control potential for project managers. The third quadrant risks relate to execution that has moderate perceived importance but high level of control is possible. The last quadrant risks relate to environment and have moderate perceived importance as well as low control possibility for project managers.
Wallace and Keil have further classified fifty software risks into these four categories . They also analyzed the effect of these risks on process and product outcome. They have concluded that for project managers, minimizing and managing the execution, scope and requirement related risks are critical from both perspectives. Further, they observed that in situations where product outcomes are more important than time and budget, the risks related to users and customers also become very critical.
SEI has proposed two taxonomies. First, they catalogued and classified one hundred and ninety-four risks into the three broad level categories  of product engineering, development environment, and program constraints Later, SEI proposed another taxonomy for software development risks for high-performance computing scientific/engineering applications . This taxonomy classifies the sources of software development risks into the three broad categories of development cycle risks, development environment risks, and programmatic risks.
Pandian has given a distribution of software development risks. As per his analysis, 70% risks are internal and only 30% are external. Project risks account for 30%, product risks for 30%, and process risks for 40%. In the process risks, the most vulnerable areas are related to human resource and requirement issues, and least vulnerability is found to exist in coding and testing .
The traditional software engineering courses do not included topics in risks and risk management. To repond to this vital gap, in 2009, we created a fast pace 5 week long undergraduate level elective course on “Software Risk Engineering” at JIIT. My colleagues Sangeeta Mittal, Anuja Arora, and Vivek Mishra taught different modules of this course. In 2010, this content was integrated with topics in in software documentation to create a new version of the full semester elective course, “Software Engineering Management.” Software risk engineering related topics in this course were taught by Sangeeta Mittal. In a future article, the objectives, content, pedagogy, references, and assessment method of these two courses shall be described.
In 2009, we also asked our final year BTech students to include a section about risks as per their specific experiences in the report of their final year capstone project. Subsequently it has become a more structured and important part of these reports.
I invite the software professionals to give their feedback about the following questions?
1. Wrt your professional experience what are the top software risks?
2. Did your university education address software risks and their management in some way?
3. How can software risks and their management be included in software development education?
 C. Ravindranath Pandian, Applied software risk management: A guide for software project managers, Auerbach Publications, USA, 2007.
 Boehm, B.: Software Risk Management: Principles and Practices. IEEE Software, pp 32-41, January 1991.
 Mark Keil, Paul E. Cule, Kalle Lyytinen, and Roy C. Schmidt, A Framework for Identifying, Software Project Risk, Communication of the ACM/Vol. 41, No. 11, pp 76-83, November 1998.
 Linda Wallace and Mark Keil, Software project risks and their effect on outcomes, Communication of the ACM /Vol. 47, No. 4, pp 69 –73, April 2004.
 Marvin J. Carr, Suresh L. Konda, Ira Monarch, F. Carol Ulrich, Taxonomy-Based Risk Identification, Technical Report CMU/SEI-93-TR-6, ESC-TR-93-183, Software Engineering Institute, Carnegie Mellon University, USA, June 1993.
 Richard P. Kendall, Douglass E. Post, Jeffrey C. Carver, Dale B. Henderson, David A. Fisher, A Proposed Taxonomy for Software Development Risks for High-Performance Computing (HPC) Scientific/Engineering Applications, Technical Note, CMU/SEI-2006-TN-039, Software Engineering Institute, Carnegie Mellon University, USA, January 2007.