Do Non-Functional Requirements for Security make sense for defining SDLC?

Question

I recently had engaged in a security discussion with my companies cyber security risk lead, discussing security controls and standards they would be holding the project to. The expectation of the Risk Lead was that these controls would trace back to architecturally driven Non-Functional Requirements defined for the project. It would be my responsibility for defining these Non-Functional Requirements for the development team to accomplish in Design or in Sprint.

This made sense for many of the controls defined, however some of the controls are less about qualities and properties of the system and more about expectations and requirements of the SDLC process itself. Eg. Production data should be masked and anonymized before cycling to a Test or QA system.

I argued on the call that it doesn't make sense for a Non-Functional requirement to define anything but a quality attribute of the System, and that the Software Development Lifecycle process is not a component of the system but of the project team.

Their reaction was that I have no idea what I am talking about and that I should do more research about Non-Functional Requirements.

Their conviction led me to question if I really understand Non-Functional Requirements correctly? The literature I read never mentions the scope of quality attributes extending to SDLC processes like cycling production data to a test system. I am not saying that capturing such requirements of the SDLC process is NOT important, I was just arguing that these are not Non-Functional Requirements. Am I wrong?

Answer 1

My understanding is the same as yours. Non-functional requirements (or quality attributes) describe the system and not the process or methods used to build the system. Everything from Wikipedia to Software Requirements, Third Edition seems to concur with this, as well. Security is an example of a valid non-functional requirement type, but only security as it is from the perspective of the system and not the people building the system or the methods and tools that they use.

I do think that it's also perfectly valid that a customer can levy requirements on your processes. You would need to track and trace these to your organization's and project's plans and procedures. I wouldn't group this with the non-functional requirements that describe the system under development, though.