B-Sec 4: Compliance NFRs & Agility:  a fictional example

The fictitious example presented in this blog illustrates the concrete implementation of the concept “Dealing with compliance-relevant NFRs in Scaled Agile Environments”, which the previous three blogs in the series presented.

Let’s take a company that offers its customers a personal self-service area on the www.Mycompany.com website. As part of the expansion of www.Mycompany.com, the company would like to provide the customer with confidential health data as an additional feature. GDPR are therefore mandatory for this customer data.

The company has reached the following maturity and has the following items in place before starting development of the feature, some from previous activities:

• The company’s development process is based on the Scaled Agile Framework SAFe, i.e. a product feature is implemented as part of a so-called portfolio epic. From a management point of view, a portfolio epic is an administrative unit of work on portfolio level, the outcome of an epic provides value to the customer.
• The Cyber & Information Security Office (CISO) has a complete list of the relevant, comprehensive, integral, and holistic NFRs to be fulfilled in the context of the company.
• For each individual NFR on the list, there are detailed requirements and their acceptance criteria, which must be met by the various operational units or in development.
• There is a risk classification questionnaire for portfolio epics. The risk classification, carried out in cooperation between the CISO and the person responsible for the portfolio epic (the epic owner), results in the list of comprehensive, integral, and holistic NFRs to be fulfilled for a specific portfolio epic.
• A roles and rights concept, the IAM (Identity & Access Mgmt) concept, was developed in cooperation between the CISO and Human Resources. This regulates which access rights a person in a defined role has to data and applications in the company.
• In the last two years, in cooperation between CISO and Software Architecture, software components have been developed for cross-cutting services such as access management, principles of data management in cloud environments, data encryption, interface technologies. These components meet a set of detailed requirements and acceptance criteria for the NFR and are to be used by the development teams in development.
• The software development uses the Atlassian tools Jira and Confluence.

Meeting the overarching and integral NFR for Portfolio Epic could proceed as described below. This is just one possible way of implementing the conceptual approach.

Implementing the concept in the Atlassian tool suite

If the company creates a new portfolio epic, a ticket is opened in the company’s Jira system, which represents the portfolio epic. The ticket is managed along with other portfolio epics in a Jira-Kanban as the company’s lean portfolio.

From the portfolio epic ticket, a link points to a Confluence page that represents the lean business case [1] of the epic (see Figure 1). Confluence is a wiki system that is tightly integrated with Jira. The lean business case includes basic data of the portfolio epic such as hypothesis and scope, priority in development, expected value after realization, etc.

When creating the portfolio epic “Provision and management of health data in the customer area”, the CISO leads together with the BO (=business owner, the role responsible for the customer area) and the EO (=epic owner, the role responsible to generate the expected value of the portfolio epic) carries out the risk assessment. The result is the relevant subset of the NFR in the context of the epic.

This subset of the NFR, including all the detailed requirements derived from it and their acceptance criteria, is documented in a separate Confluence page, which is stored directly below the Lean Business Case (see Figure 1). This Confluence page is of particular importance insofar as the validation of the detailed requirements is step by step documented in the course of development – and thus ultimately the complete fulfillment of the NFR.

We have now created the conditions for starting the implementation of the portfolio epic, in the context of which the detailed requirements have to be met.

According to SAFe, a portfolio epic is decomposed in several stages. These three stages are as follows:

• The Portfolio Epic: It describes a business or technical scope that provides value to the customer. For an exact definition of what a portfolio epic is, refer to the Scaled Agile Framework documentation (www.scaledagileframework.com).
• A feature: A greater partial functionality of the Portfolio Epic. According to SAFe, in order to realize this, several agile development teams are required to work together in a cooperative manner. SAFe names a number of development teams that work closely together on the agile release train (ART).
• A story: A partial functionality of a feature that is realized by a single team.
• In our example, the portfolio epic is broken down into a number of features, and a single feature is broken down into a number of stories. An ART realizes a feature, a team a story. If a company works according to a different scalable agile framework than SAFe, for example based on LeSS, there is a similar form of decomposition to well defined levels of abstraction.
• The implementation of the concept for handling the NFR uses this decomposition as follows. Decomposed requirements of an NFR are assigned to an abstraction level of the decomposition epic, feature or story. For example:
• The NFRs themselves apply at the highest level of abstraction of the portfolio epic. We arbitrarily call this level «Level 1».
• A subset of detailed requirements of the NFR apply at the feature level. We arbitrarily call this level “Level 2”.
• Another subset of detailed requirements of the NFR applies at story level, «Level 3».
• Each detailed requirement of a Level 1 NFR is clearly assigned to either a Level 2 or 3. This ensures that a Level 1 NFR is fully and completely covered.

Since acceptance criteria are defined for the NFR at Level 1 and for all derived detailed requirements at Levels 2 and 3, it is also defined which validations are to be carried out and which validations require documentation for auditable proof.

Decomposing a portfolio epic is the task of the ART. When working with the Jira tool, a feature is also represented as a ticket, which is subordinate to the portfolio epic ticket. A feature in turn breaks down into stories, which are represented in Jira as tickets. This creates a hierarchical tree of tickets (see Figure 1).

For the example of the portfolio epic “Providing and managing health data in the customer area”, an ART generates the feature “As an authorized user of Mycompany.com, I would like to be able to view and manage my pharmaceutical history so that I can consult it for future prescriptions and can check.”

Agile good practices in dealing with generally applicable NFR

Now a good practice for dealing with quality requirements (NFR) [2] by agile teams is applied. If an agile team works with a physical backlog on a pinboard, for example, it writes generally applicable quality requirements such as usability, performance or regulations on a flip and hangs it next to the backlog. The Definition of Done (DoD) of a story states that the quality requirements on the flip must be observed and verified. The team is required to take a look at the flip at the end of each individual story and to verify the quality requirements that apply in the context of the story.

We transfer this good practice to the digital world as follows: the moment the feature is created, an Jira NFR ticket is created and linked to the feature ticket.

All the detailed requirements of levels 2 and 3, as well as their acceptance criteria, are stored in the NFR ticket. With Jira, this step of creating the NFR ticket can be automated, as well as the filing of the detailed requirements of levels 2 and 3 and their acceptance criteria in this ticket. The NFR ticket in Jira does the job of the physical flip. It lists all the detailed Epic Level 1 NFR requirements to be considered and fulfilled for the feature and all stories under the feature.

The NFR ticket also fulfills the purpose of documentation. For regulatory reasons, the fulfillment of specific detailed requirements requires proof of the test, i.e. documentation that the requirement has been met and verified. This proof can be a reference to a test that has been carried out or an artifact such as a zone concept for an infrastructure.

Such proof is documented in the NFR ticket (see Table 1). If the verification of a detailed request requires documentation, this is done in the NFR ticket for the corresponding detailed request. This can be done, for example, via a corresponding link to a test that has been carried out or an artifact that has been created, such as a document.

Applied to the example, the NFR ticket contains, among other things

• The Level 2 detailed requirement for a GDPR NFR: “Roles and rights must be defined in an overarching Identity & Access Management concept” with the acceptance criteria: “The IAM concept has been created; The IAM concept has been approved by HR and the Security Office»
• The Level 3 detailed requirement for a GDPR NFR: “Access to personal data is exclusively with the identity of the owner of the personal data” with the acceptance criterion: “The correct implementation of the authorization of access to personal data according to the IAM concept must be verified and to document”.

In the decomposition of the Portolio Epic “Providing and managing health data in the customer area”, an ART creates the feature “As an authorized user of Mycompany.com, I would like to be able to view and manage my pharmaceutical history so that I can consult and check it for future prescriptions can”.

The moment the feature is created, the NFR ticket is created and linked to the feature ticket. The “Arkansas” development team in the ART is now creating the story for the feature “As an authorized user of Mycompany.com, I would like to see my pharmaceutical history from all available sources processed chronologically and filtered and sorted according to criteria to be defined”. The story is linked to the feature as «parent» (see Figure 2)

Creation of an auditable documentation of the validation

In the implementation of the story by the team, the NFR ticket serves on the one hand as a checklist of which detailed requirements have to be met, on the other hand it serves to document proof that the requirements have been met. Each team’s DoD states that the requirements in the NFR ticket are to be met and, if required, evidence of compliance is to be documented in the ticket. If a feature is fully implemented by the teams, the required proof of verification of the NFR detailed requirements is documented in the NFR ticket.

The ART and the team in the ART will now approach the implementation of the feature and story as follows:

• In the ART, the teams agree on which team is responsible for fulfilling the Level 2 detailed requirement “Roles and rights must be defined in an overarching Identity & Access Management concept”. The team “ObiWanKenobi” takes responsibility and creates the story «In order to ensure the security of access to personal data in the Mycompany.com app, our company has an IAM concept for all access to data in the Mycompany.com app to create; Acceptance criterion: The IAM concept has been approved by HR and CISO».
• The team “ObiWanKenobi”is now creating the IAM concept together with HR and CISO. The result is a document. The acceptance criterion is secured by noting in the header of the document which people in which roles from HR and CISO have approved the document.
• The link to the document is stored in the feature’s NFR ticket for the detailed requirement “Roles and rights must be defined in an overarching Identity & Access Management concept”. This link serves as proof of compliance with this requirement in the audit.

This method also supports incremental development based on a DevOps approach. The checklist stored in the NFR ticket together with the DoD ensure that both an individual story and a feature are implemented in compliance with the NFR requirements.

At the level of the portfolio epic, proof is provided that all NFRs have been met when all features of the portfolio epic have been completed and the verification of the detailed requirements is confirmed and documented in the NFR tickets for the features. The fulfillment of all detailed requirements also fulfills the NFR of the Portfolio Epic. Ideally, all NFR tickets are referenced in the NFR Confluence page at portfolio level.

The formal proof of the fulfillment of the NFR, for example for an audit organization, is available via the Confluence page plus the documentation of the verification of the detailed requirements in the NFR tickets of the features. An audit organization is thus able to check whether the NFR at the level of the portfolio epic and the corresponding detailed requirements at the level of the features and stories have been met and checked.

This step can also be automated with the tools of Jira and Confluence, in which a PDF document is created from the corresponding NFR tickets and the Confluence page, which is stored as proof in a corresponding repository. The automation can be pushed even further in that the corresponding audit report is generated for each release of a deployment unit and stored in a repository linked to the versioned release. This automation could, for example, be part of a DevOps build pipeline, which not only includes the software, but also the documentation assigned to a software release.

Appendix: Auszug aus dem Jira NFR-Tickets

Summary

The blog series presented a conceptual approach on how to deal with overarching, regulatory requirements that are subject to an audit or certification in a scaled, agile development system.

This approach and exemplary form of implementation is suitable for environments and industries in which the level of regulation to be observed does not exceed a certain level. These are, for example, trade, insurance or large areas in banks and transport, as well as for functional areas such as administration or accounting. According to the author, this is the vast majority of product and service development.

The approach is not suitable in strictly regulated environments such as medical technology and aviation, in which not only the product has to be verifiably and traceably validated, but also the manufacturing process. According to the author, agile approaches can be used here, an incremental approach in fast iterations is not possible due to the effort for documentation and certification.

The approach requires a certain agile maturity of the organization as a prerequisite (see blog 3). It builds on agile and modern methods such as decentralized responsibility, DevOps and test automation. Companies that invest in this agile maturity benefit precisely from the opportunity to build higher-quality skills on this maturity, such as dealing with overarching, regulatory and verifiable quality requirements.

It must be clearly emphasized that the successful implementation of this decentralized approach requires a further dimension. In order for the interaction of the decentralized organizational areas to function successfully in the sense of the big picture, an overarching understanding is required, collective self-discipline is required, and a striving for the right amount of simplicity and standardization. Creating a corresponding attitude among employees in the company is clearly a management task. According to the author, there is still potential here.

Cyber security and compliance have meanwhile arrived as important topics that urgently need to be addressed by the companies. Typically, one executive member is responsible for getting these issues under control. Unfortunately, it has not yet arrived everywhere that investing in modern work – I deliberately avoid the terms “agile” and “lean” here – with current technologies in a decentralized approach requires more than a technical cloud transformation or a microservice architecture. It also requires a change in behavior, in the attitude of all employees to the values mentioned above. This transformation is just as important if companies want to be successful in the future.

Well, with the discussion about behavior, I digressed somewhat from the actual topic of the blog series. I beg your pardon. I hope the blog series was able to give you as a reader some food for thought and impulses. I am also available for an exchange of experiences. Just get in touch with me. You can find my contact details on LinkedIn or simply by using Dr. Google.

[1] SAFe Template for a Lean Business Case: https://www.scaledagileframework.com/wp-content/uploads/delightful-downloads/2020/06/Lean-Business-Case-V7.docx

[2] See Article «Non-functional Requirements Documentation in Agile Software Development: Challenges and Solution Proposal», Woubshet Behutiye, Pertti Karhapää, Q-Rapids project, which has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement N° 732253.