Risk Analysis in Requirements Engineering: FMEA

In a couple of industries like Automotive, Aerospace and Medical Devices Risk Analysis becomes more and more important because lots of standards and regulations require Risk Analysis for safety critical systems. In many cases the manufacturer of such a safety critical system is forced proving that they did Risk Analysis in a proper way.

FMEA (Failure Mode and Effects Analysis) is one of the most famous techniques for analysing risks. In FMEA an interdisciplinary team derives risks from the requirements which are then evaluated in a structured way. For each risk three values are specified:

• Severity
• Occurence
• Detection

The Risk Priority Number (RPN) is then calculated by multiplying these three values. If the RPN is lower than a certain threshold the risk is seen as acceptable and no further actions need to be taken. If the RPN is too high additional actions must be taken to either decrease the probability of occurrence or to increase the probability of detection by the system.

Whenever an action was defined to reduce a certain risk a re-evaluation needs to be done. If the RPN for risk + action is still too high another action must be defined.

While preforming Risk Analysis we obviously create different types of information which are related to each other. So, why not using the requirements management solution with its dedicated support for managing such relations not only for the requirements but also for Risk Analysis?

Using the traceability capabilities of such a solution eases up approvement processes with certification authorities tremendously.

And if you need to create a nice looking report for the certification authority, just click a button (or generate them in batch mode while you relax at home…):

Life could be so easy…

By: Andreas Plette

Implementing a Requirements Management Tool on a Complex System

Many years ago I spent several years working on a very complex weapon control system. As you can imagine the requirements were large, complex, and changed often. We spent a lot of time just trying to manage those pesky changes that continued to be submitted, both from customers and from the developers. In those early days, we did not have any requirements management tools to help use assess these changes. We were using Interleaf and Excel (I can hear groans of pain now). Everything was manual, including our complex traceability. We had a couple of folks who did nothing but maintain the traceability matrices and assess the impact of changes. At this time we only had traceability from the Concept of Operations to System Requirements to Subsystem Requirements. I say “only” but at that time just having this level of traceability was a big accomplishment.

When we had enough changes we issued a new system requirements document and new subsystem requirements document. Those poor contractors had to go through the massive subsystem requirements and manually determine what had changes. I can’t imagine the time the contractors spent just trying to figure out what changes they needed to be concerned about.

It was in the middle of this upgrade project that the customer said enough and tasked my team with evaluating and selecting a requirements management tool. The tool we selected is not important to this particular discussion, but what we learned from this tool selection and implementation is important. Here are some lessons learned.

(1) - There is not a single tool which is going to please everyone. We had users who loved our selection and those who fought us every step of the way. Without a customer supporting and enforcing the change it would not be possible on a large program like this one. One user complained about the column size of the tool generated traceability matrix, totally ignoring the fact that it saved him days of manual effort.

(2) - Our manual traceability was not very clean. Once we imported all of our information into the tool and linked it up we found many gaps in the traceability. What was more disturbing was that we had links that really didn’t make any sense. We had to do a lot of work to clean up our traceability matrices.

(3) - Just tracing requirements was great, but now we could use the same effort to link requirements to test plans, and went so far as to link subsystem requirements to design documents that we could review. This didn’t happen overnight, but it did happen. Eventually we could trace system requirements to a subsystem requirement to a design document to a code module. We even used a tool to determine the complexity of code modules and used this to help determine how difficult a change would be to implement and test.

(4) - Metrics from a requirements tool are key to understanding completeness of testing activities. We often thought we were 50% complete with testing. After all, 50% of the tests were completed. However, what we found was that we were prone to testing the simplest and most understood parts of the system first. So even thought we were 50% complete, everything left was very high risk. We learned to prioritize our testing by looking at requirements priorities and software complexity, information we could not determine through manual traceability.

(5) - It was very easy to get overwhelmed. Start simple. We had to back off our ambitious ideas and begin with a simple traceability model. As we learned and gained more experience with the tool, we added more information to our model. We were constantly assessing our process to figure out what else we could do to make it better.

- Don’t skimp on training and mentoring. We trained everyone on the project and created experts who helped users get over initial hurdles. We sent our experts to our contractors for weeks at a time to help them get up to speed in using the tool. We even had our own internal users group. Be prepared for this kind of effort.

What a great leargning experience this was for me. If you´re interested in embarking on a change like this to improve your requirements process, contact Visure Solutions. We will be happy to discuss your process with you.

By: Marcia Stinson

Compliance to standards

Today there is almost no industry not being penetrated by standards and regulations such as IEC 61508 and its derived standards for the different industries.

Those standards are typically provided in PDF format and contain often hundreds of pages from which only a certain subset might be relevant for a specific project. For another project a different subset of the standard might be relevant. So how to prove compliance efficiently with such a standard if there is no way to:

• Trace the project requirements back to individual statements of the standard?
• Check if all relevant statements from the standard are covered in the project requirements (how to identify quickly the relevant aspects contained in a huge PDF and whether they are already covered by the project?)?

Appropriate solutions by Visure Solutions may help here: first of all you would need to import the relevant part of the standard into a requirements management solution where each statement is its own referenceable unit. Of course this should be done in an automated way (who really likes to copy/paste thousands of sentences from a PDF to some other tool?). Then you can use the capabilities provided by such a tool to create relationships between individual statements of the standard and the requirements derived from them, proving compliance to the standard by using the numerous capabilities provided by requirements management solutions for analyzing traceability and coverage

But what if you need to see the details of a statement in the original PDF?

Just navigate there!

By: Andreas Plette

Using Use Cases for Requirements Definition and Management

Several years ago I found a book titled “Use Cases: Requirements in Context”. I had to think about that for just a second before realizing that precisely describes what a use case does. Use cases describe requirements in the context of a process flow or process narrative, thus stating a requirement in the context of that narrative.

Use cases are an effective tool in documenting how the user does their job. Often called “as is” and “to be”, these narratives help ensure that we understand how the user does their job today (as is) as well as how they may envision doing their job tomorrow (to be). Use cases are becoming more and more popular as analysts continue to struggle with the issues around the relationship of requirements.

However, sometimes use cases are used effectively during requirements elicitation and definition, but get lost when the transition is made to requirements management. If you think about the steps in a use case, each step describes an action by either the user or the system. Depending on the granularity you want in your requirements and traceability, consider making each step in the use case a requirements statement. Take the following simple use case as an example.

The System displays the account information to the Customer.

The Customer reviews the account information.

The Customer selects the Pay Option.

The System displays the payment options to the Customer.

It is pretty clear from this use case that there are two System steps and two Customer (i.e. User) steps. If we extract the two System statements and, if required, add “shall” to them we get the following two system requirements:

The System shall display the account information to the Customer.

The System shall display the payment options to the Customer.

These two requirements begin to form the basis for the system requirements. These system requirements will likely be decomposed into many system requirements, but we can trace them directly back to the system steps in the use case.

Remember that use cases contain very valuable information for systems analysis and development. Use cases are never really finished since they must be continually reviewed throughout development to make sure they accurately reflect how the product behaves when it is delivered. Make sure that use cases are not put on a shelf, but are traced to both tests and system requirements.

By: Marcia Stinson