Agile for Software Development: Safety Critical-Environments

Agile improves development for many software and product developers. For those in safety-critical environments, however, modifications are necessary to ensure compliance is still met using an Agile approach to development.

How to Transition to Agile

Because compliance and safety are cornerstones of regulated industries, it’s important to identify how critical information will remain part of an Agile process. Here we will discuss:

• Agile team member(s) responsible for validation.
• Agile risk management.
• Using both user stories and requirements.

Need help making a case for Agile? Read Safety-Critical: Does Agile Really Work? >>

Agile Teams

A hallmark difference between Waterfall and Agile is the cross-functionality of the Agile team. Rather than siloing teams, one Agile team completes everything including design, development, and testing.

That means that there isn’t a separate team that handles compliance tasks. There’s no person whose sole job is validation. For regulated industries, verification, validation, traceability, and other activities that produce compliance documents typically falls on quality assurance members.

Want to help QA with Agile traceability? Watch The Best of Both Worlds: Agile Development and Fast Compliance >>

Agile Risk Management and Mitigation

While risk management is a little different in Agile than it is in Waterfall, the same basic steps are followed. You just need to identify where the core activities fall within the process. We can show this through an example.

The IEC 61508 functional safety standard applies to numerous industries. It’s the “Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems.”

The IEC 61508 defines its core activities as:

• Hazard identification
• Risk assessment
• Risk mitigation
• Assessment of residual risk
• Safety requirements specifications
• Hardware/software reliability specifications

The steps that don’t naturally fall within an Agile-based approach are hazard identification, risk assessment, and risk mitigation. But you can still easily fold them into your process.

Include these steps in the retrospective phase of every sprint. Maintain a backlog of requirements with their associated risk scores for each. Then use the score to evaluate and select requirements for the next sprint.

See how a product development solution helps with risk management — sign up to watch a demo of Helix ALM >>

Combine Requirements and User Stories

For unregulated industries, user stories define product features. They provide valuable context for developers and testers as to how end users will interact with features. However, user stories don’t have the precision and objectivity of requirements. And safety-critical product development needs these regimented requirements. 

The answer for regulated industries is to combine requirements and user stories. This is accomplished by taking advantage of the best qualities in both and linking the two together.

Requirements

Your requirements will be used to define exactly what will be implemented. They act as the agreement between the team and end user. This includes non-functional aspects of your product, like security and performance. One requirement can use more than one user story.

Requirements provide clarification when user stories leave out certain details. For example, developers may refer to them when designing and implementing features — even though they’re basing work on the user stories.

Testers will write and run test cases to support requirements. They more formally represent the agreement with users.

See the differences between Agile and traditional requirements gathering templates >>

User Stories

User stories provide context around requirements. They help the team understand how individual features will be used, providing a deeper understanding of purpose and functionality. One user story can support multiple requirements.

User stories will provide the content for developers when they design and implement features.

They also help testers structure tests by providing information about what makes a feature successful.  
 

Transition to Agile for Software Development – The Missing Link

In order for a user story/requirements hybrid to work, the two must be linked together.

Linking is necessary for traceability. Artifacts are linked to requirements, which are linked to user stories. This immediately shows the impact of change. If a requirement or user story changes, the team needs to understand things like which test cases are affected, and how the source code will change.

Traceability is also critical to compliance. Of course, you want to avoid manually linking requirements and user stories. That would take a tremendous amount of time and increase the likelihood of mistakes.

You can automate traceability with one tool — one that also makes it easier to transition to Agile or an Agile/Waterfall hybrid.

Make it Easy

Helix ALM provides end-to-end traceability. It streamlines development for efficiency. And it powers your agility at the pace that’s right for you.

Try it free for 30 days.

Go Agile, Stay Compliant