Our team was wresting with various ways to document and track CCCs and NFRs. We came up with a pretty good approach, but I was wondering if we could do better. So I consulted a guru: ChatGPT. Here is our conversation.

Me:
You are a SDLC expert with 20 years of experience. I want to discuss with you how best to document and track cross cutting concerns (CCCs) and non-functional requirements (NFRs). We use Jira to track functional requirements. What are best practices for CCCs and NFRs?

GPT:
Great, I’d be glad to discuss this with you. Cross-cutting concerns (CCCs) and non-functional requirements (NFRs) are often overlooked but are critically important in the software development lifecycle. Here are some best practices for documenting and tracking these aspects:

Cross-Cutting Concerns (CCCs):

1. Identify early: Identify the cross-cutting concerns as early as possible in the project lifecycle, preferably during the design phase. This gives you ample time to make decisions on how to address them.
2. Document in detail: Each CCC should be properly documented, with a clear definition and potential impact on the application.
3. Assign ownership: Just like any functional requirement, CCCs should have owners who are responsible for them throughout the SDLC.
4. Use of Components and Services: Many cross-cutting concerns such as logging, security, data validation can be addressed by components or services that are used across the application. Document how these components/services address the CCCs.
5. Incorporate into Jira: In Jira, you can create “Epic” items that capture these cross-cutting concerns. Then, as various user stories or tasks come up that relate to these concerns, they can be linked to the appropriate Epic.

Non-Functional Requirements (NFRs):

1. Identify and Document Early: Just like CCCs, NFRs should be identified as early as possible. They should be documented clearly, with specifics about what is required. This could include details about performance, security, availability, and other ‘ilities’.
2. User Stories: One good practice is to write user stories for NFRs just as you would for functional requirements. This helps to make the NFRs more tangible and easier to understand.
3. Testing: Make sure to include tests to validate that NFRs have been met. This might involve performance testing, security testing, etc.
4. Use of Jira: Similar to CCCs, NFRs can be managed in Jira. Again, creating an “Epic” or a “Task” to represent each NFR could be a good practice. Each user story that has a relation to these NFRs could be linked back, enabling a traceability matrix.
5. Review and Update: NFRs should be reviewed regularly and updated if necessary. They can often change as the project progresses and as more is understood about the system.

General Tips for Managing CCCs and NFRs in Jira:

1. Custom Fields: Consider creating custom fields in Jira to flag issues as being related to specific NFRs or CCCs.
2. Reporting: Use Jira’s reporting capabilities to keep track of CCCs and NFRs. This can help you to see at a glance whether these aspects are being adequately addressed.
3. Labels or Tags: Use labels or tags in Jira to mark issues as being related to certain CCCs or NFRs. This can help with tracking and reporting.
4. Integration with Confluence: If you’re using Atlassian’s Confluence for documentation, you can integrate it with Jira. This allows you to link Jira issues directly to specific documentation in Confluence, which can be very useful for tracking CCCs and NFRs.

Remember, the aim of documenting and tracking CCCs and NFRs is not just for the sake of process. It’s about ensuring the quality and reliability of the software you’re building. As such, it’s important to think about these things not as separate from the rest of the development process, but as integral to it.

Me:
What is the fundamental difference between CCCs and NFRs? Why should I treat them differently?

GPT:
Cross-Cutting Concerns (CCCs) and Non-Functional Requirements (NFRs) have some fundamental differences, though they both have a significant impact on the quality of the software system. Understanding these differences can help you to better manage and document them.

Cross-Cutting Concerns (CCCs) are aspects of a system that affect multiple components and cannot be decomposed into the system’s primary functional segments. These concerns often cannot be neatly encapsulated in one module within the codebase, instead they “cut across” multiple modules. Examples of CCCs include logging, security, data validation, error handling, and communication among components. If not properly managed, these can lead to scattering and tangling of code, making the software difficult to maintain and evolve.

On the other hand, Non-Functional Requirements (NFRs) are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors. They relate to how the system should behave and impose constraints on the system’s functionality. These include requirements related to performance, scalability, reliability, usability, security, compliance, and so on.

While there is some overlap between CCCs and NFRs, especially when it comes to areas like security and error handling, the main difference lies in their nature and how they are addressed within a system.

Here are the key points why you might want to treat them differently:

1. Documenting and Tracking: NFRs are usually captured as part of the requirements documentation. They should be measurable and testable. In contrast, CCCs may not always be explicitly defined as part of the requirements but emerge during the design and coding phases. They are often addressed through design patterns, aspect-oriented programming, and middleware.
2. Testing: While you can write tests to verify if NFRs are met (e.g., a load test to verify a performance requirement), testing for CCCs often involves code review and architectural analysis to ensure that the code related to these concerns is properly modularized and not scattered and tangled across the codebase.
3. Impact on Design: CCCs have a significant impact on the system design, as they are concerns that “cut across” multiple components. On the other hand, NFRs have more of an impact on the system’s architecture, dictating the choice of architecture, technology, platform, etc.

To manage them effectively, it’s important to be able to identify and classify whether a particular concern is a CCC or an NFR, and then use appropriate techniques and tools for addressing, documenting, and tracking them.

Me:
Where does regulatory compliance fit it?

GPT:
Regulatory compliance typically falls under the category of Non-Functional Requirements (NFRs).

Compliance is not about the specific functionality of the system (i.e., what the system does), but rather it’s about how the system operates within a particular regulatory framework. For instance, a system might need to comply with data protection regulations like GDPR or HIPAA, financial regulations like Sarbanes-Oxley (SOX), or industry-specific regulations like those from the FDA for healthcare products.

When it comes to documenting and tracking compliance requirements, here are some best practices:

1. Explicit Documentation: Compliance requirements should be explicitly documented as part of your NFRs. Each relevant regulation should be clearly outlined along with its implications for your system.
2. Mapping to Functional Requirements: Although compliance is a non-functional concern, it often has implications for your functional requirements. For instance, a data protection regulation might require you to implement specific data handling or data deletion functionalities. These should be identified and documented as part of your functional requirements.
3. Regular Audits: Compliance is typically something that’s enforced through regular audits. You should have a process in place for conducting these audits, and for tracking and addressing any issues that they uncover.
4. Training: Ensuring compliance often requires training for members of your team, to ensure that they understand the relevant regulations and their implications.
5. Use of Jira: Like other NFRs, compliance requirements can be managed using Jira. You can create specific compliance-related “Epics” or “Issues” and link them to related user stories or tasks.
6. Traceability: There should be clear traceability from compliance requirements to the system requirements and implementation. This will help during audits to provide evidence of compliance.

Remember that failing to meet compliance requirements can have serious legal and financial implications, so it’s crucial that these are given the attention that they require.

Me:
I suppose the same applies to standards adherence?

GPT:
Absolutely, adherence to standards, similar to regulatory compliance, is typically categorized as a Non-Functional Requirement (NFR).

Standards can be industry-specific (like ISO 9001 for quality management, ISO 27001 for information security management, or IEEE standards for software engineering), technology-specific (like WCAG for web accessibility, or RFCs for internet technologies), or organization-specific (like internal coding or design standards).

Here’s how you can document and track adherence to standards:

1. Explicit Documentation: Like compliance, standards should be explicitly documented as part of your NFRs. Each relevant standard and its implications for your system should be outlined clearly.
2. Mapping to Functional and Non-Functional Requirements: Adherence to standards might have implications for both your functional and non-functional requirements. For example, adherence to the WCAG accessibility standard could affect your user interface design (a functional requirement), as well as your performance or usability criteria (non-functional requirements).
3. Regular Reviews: To ensure adherence to standards, you should have regular reviews or audits, and a process for tracking and addressing any issues identified.
4. Training: Your team members may need training to understand the relevant standards and how to adhere to them.
5. Use of Jira: You can manage standards adherence using Jira, by creating specific standards-related “Epics” or “Issues” and linking them to the relevant user stories or tasks.
6. Traceability: There should be clear traceability from the standards to the system requirements and implementation. This traceability is crucial during audits or reviews to provide evidence of adherence to standards.

Remember that adherence to standards can greatly affect the quality, interoperability, and maintainability of your software system. So, it’s essential to give this aspect the attention it requires.

Me:
Are there any other considerations that we haven’t talked about?

GPT:
We’ve covered a lot of ground on this topic, but there are a few additional points you might want to consider when it comes to handling Cross-Cutting Concerns (CCCs), Non-Functional Requirements (NFRs), regulatory compliance, and standards adherence:

Use of Aspect-Oriented Programming (AOP) for CCCs: One technique for handling CCCs in the codebase is the use of Aspect-Oriented Programming. This paradigm allows you to isolate concerns that cut across the system in separate modules called aspects. While this doesn’t affect the documentation or tracking, it can be a good practice to consider in the development process.

Involvement of Stakeholders: Involving stakeholders is a crucial aspect of the process. This not only includes the product owner or the client but also other stakeholders like end-users, regulatory authorities, etc. Their input can be critical in identifying and understanding the NFRs, CCCs, and compliance requirements.

Review and Update: This process should not be static. As the project evolves, so will your understanding of the system and its context. This could lead to changes in your NFRs, CCCs, and compliance requirements. Regular reviews and updates should be part of the process.

Invest in Tooling: Good tooling can make the process much easier. We’ve already talked about Jira, but there are also other tools for requirements management, code review, automated testing, and continuous integration/continuous deployment (CI/CD) that can help.

Continuous Learning: Finally, always be learning. The landscape of software development is always evolving, with new techniques, tools, and best practices. Stay up-to-date and continuously improve your process.

Remember, the ultimate goal is to build a software system that not only meets its functional requirements but also is reliable, maintainable, secure, and compliant with relevant regulations and standards. Treating CCCs, NFRs, compliance, and standards as first-class citizens in your process is a significant step towards that goal.