{"id":2771,"date":"2017-05-28T16:00:16","date_gmt":"2017-05-28T15:00:16","guid":{"rendered":"https:\/\/thekua.com\/atwork\/?p=2771"},"modified":"2017-05-27T16:37:22","modified_gmt":"2017-05-27T15:37:22","slug":"three-ways-to-handle-cfrs","status":"publish","type":"post","link":"https:\/\/thekua.com\/atwork\/2017\/05\/three-ways-to-handle-cfrs\/","title":{"rendered":"Three ways to handle CFRs"},"content":{"rendered":"

Cross-Functional Requirements (CFRs)<\/strong> 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<\/strong> (NFRs) or System Quality Attributes<\/strong>, however their cross-cutting nature means you always need to consider the impact of CFRs on new or existing functionality.<\/p>\n

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.<\/p>\n

1. CFRs satisfied via user stories and acceptance criteria<\/h2>\n

Security<\/strong>, authentication<\/strong> and authorisation<\/strong> 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. <\/p>\n

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.<\/p>\n

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:<\/p>\n

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.<\/p><\/blockquote>\n

If this is the first time that this user story is implemented, then some acceptance criteria might look like:<\/p>\n

\n