Cross-Functional Requirements (CFRs) are some of the key system characteristics that are important to design and account for. Internally we refer to these as CFRs, although classically they might be called Non-Functional Requirements (NFRs) or System Quality Attributes, however their cross-cutting nature means you always need to consider the impact of CFRs on new or existing functionality.
In the Tech Lead courses that I run, we discuss how it’s important that the Tech Lead ensures that the relevant CFRs are identified and accounted for either in design or development. Here are three ways I have seen some CFRs accounted handled.
1. CFRs satisfied via user stories and acceptance criteria
Security, authentication and authorisation stories are CFRs that naturally lend themselves to actually building out testable functionality. It’s important to consider the effort the risk and, in my experience, is important to start implementing these early to make sure they meet the needs and can evolve.
For these sorts of CFRs, it’s useful to identify these as natural user stories, and once implemented become acceptance criteria on future user stories that touch that area of the system.
As as example, authorisation can be dealt with by introducing a new persona role and what they might do (or not do) that others can have:
As an administrator, I would like to change the email server settings via a user interface, so that I do not need to raise an IT change request for it.
If this is the first time that this user story is implemented, then some acceptance criteria might look like:
- Only a user with an administrator role can access this page
- Only a user with an administrator role can successfully update the email setting (check the API)
- Users with no administrator access receive a 403 or equivalent
This new role addition often means considering new acceptance criteria for every story going forward (if it should be accessible only by administrators or by all.
2. CFRs satisfied through architectural design
Scalability and durability are often CFRs that require upfront thinking about the architectural design, and perhaps planning for redundancy in the form of additional hardware, network, or bandwidth capacity. A web-based solution that needs to be scalable might draw upon the 12-factor application principles, as well as considering the underlying hardware. Failing to think about the architectural patterns that enable scalability and start coding will lead to additional rework later, or make it even impossible to scale.
3. CFRs satisfied via the development process
User experience is a CFR which often requires people, making automated testing much more difficult. An application where a high level of user experience is best dealt with by ensuring that a person with a background in UX is involved and that certain activities and feedback cycles are planned into the software development process to continually fine-tune the user experience as an application evolves.
Changes to the development process might include explicit user research activities, continuous user testing activities, the addition of an A/B capability and some training for product people and the development team to ensure that the developed software meets the desired level of user experience.
Conclusion
Every system has their own set of Cross-Functional Requirements (CFRs) and it is essential that teams focus on identifying the relevant and important CFRs and find ways to ensure they are met. In this article, I shared three typical ways that CFRs might be met.
How else have you seen these handled?
| Reference: | Three ways to handle CFRs from our JCG partner Patrick Kua at the THEKUA.COM@WORK blog. |
