{"id":878,"date":"2013-11-27T20:03:53","date_gmt":"2013-11-28T04:03:53","guid":{"rendered":"https:\/\/blogs.plm.automation.siemens.com\/t5\/Polarion-Blog\/Risk-Analysis-How-to-Make-It-a-34-First-class-34-Citizen-in-Your\/ba-p\/380806"},"modified":"2026-03-26T05:31:58","modified_gmt":"2026-03-26T09:31:58","slug":"risk-analysis-how-to-make-it-a-first-class-citizen-in-your-development","status":"publish","type":"post","link":"https:\/\/blogs.sw.siemens.com\/polarion\/risk-analysis-how-to-make-it-a-first-class-citizen-in-your-development\/","title":{"rendered":"Risk Analysis: How to Make It a "First-class" Citizen in Your Development"},"content":{"rendered":"

In a recent article, the editors of the Tibco Blog claim “Major Plane Crashes Are Always Technology Failures, Not Human Error”<\/STRONG><\/A>. You can agree with that statement and the premise of the article or not, but it did at least get us thinking about the subject of Risk Analysis<\/STRONG>, and where (and more importantly how<\/EM>) it fits into product development<\/STRONG>.<\/p>\n

<\/p>\n

\"Mountain<\/A>The whole process of analyzing risk is frequently a thing apart from the process of developing an application or product. What happens is that “these guys over here” do a FMEA<\/A> (or whatever other process) and send the results (usually in some document or set of documents) to “those guys over there” who write up requirements and develop the system or product. (The requirements guys are all too often “siloed” from the development guys too… but that’s another story.)<\/p>\n

Understanding how the results of the FMEA risk study actually apply to what artifacts in development is difficult because the former isn’t integrated with the latter. Risk Analysis is in effect, a “second-class citizen” in the actual development project.<\/STRONG> And it’s really more important than that, if you think about it (which you probably do every time you fly).<\/p>\n

You may not know that Polarion’s application lifecycle management solution<\/A> integrates the risk analysis phase of systems or product engineering with the rest of the application\/product development process… requirements management, Agile development, test management and testing, and so on. You’ll find out-of-box features including a custom Work Item type “Risk”, FMEA template documents, and pre-configured workflow that involves before and after Risk Priority calculations (RPN) from user-defined values of Severity, Occurrence, and Detection.<\/p>\n

\"Screenshot:<\/A>
Risk analysis and management is an integral part of development projects in Polarion ALM<\/SPAN><\/DIV> <\/DIV><\/p>\n

Having risk analysis as a “first-class” citizen in a project means you can easily achieve traceability from the granular risks identified in a FMEA (represented in “Risk” type Work Items), to mitigating requirements and subsystem designs, and from there outward to test cases that verify requirements, the results from executing the test cases, right on into the the source code implementing the software components. Thanks to extensions such as the Polarion Connector for MATLAB Simulink<\/A> it’s even possible to get traceability into model elements.<\/p>\n

We have a couple of webinars that you might find helpful in your quest to make risk analysis an integral component of your product development:
\n