Avoiding the Security Black Hole with Non-Functional Requirements
As an avid Skype user, I couldn’t believe it when I read that Microsoft (Skype’s new owner) temporarily suspended the software’s password reset function to avoid falling foul of an alleged security vulnerability. I immediately felt at risk. How could such a useful and ubiquitous service, and one that I use every day, be vulnerable to such a seemingly simple shortcoming?
Of course, security vulnerabilities aren’t limited to Skype. I’m sure we’ve all heard the stories and read news articles about security hazards in the software and hardware we use every day. What is equally worrying is that there appears to be an emerging marketplace where details of security vulnerabilities are disclosed for cold, hard cash.
The Next Web (TNW) site recently reported how details of an alleged Adobe X security flaw were apparently offered for $30,000–$50,000. A French security company is allegedly selling details of a Windows 8 vulnerability. Scary stuff indeed!
With stories about security covered in the media regularly, consumers and businesses are (quite rightly) aware and concerned about the robustness of the security that protects their organizational and personal data. However, sometimes this due diligence drops when we start working on projects with tight deadlines.
Security is an important non-functional requirement of any system. As any business analyst will tell you, it can be a real challenge to carry out non-functional requirements elicitation. When talking about security, it’s easy for stakeholders to say things like “Ah, we just need whatever the old system had” or “Yeah, go with whatever the vendor recommends.” The trouble with these statements is that they are rather knee-jerk reactions, and they really only skim the surface.
Vulnerabilities like the ones mentioned above highlight the importance of the non-functional side of systems. Creating confident security starts by spending sufficient time eliciting and analyzing non-functional requirements in detail. It also involves ensuring that the development and/or technical architecture team are engaged, have active involvement throughout, and see the requirements early.
The technical team can often provide valuable insight into industry best practice and provide guidance into what is possible, based on the potential solution architectures being considered. This helps inform requirements—although clearly it should not dictate them.
As business analysts, we have the opportunity to work with our stakeholders to understand the security standards to which each solution needs to adhere. We can help understand who needs to access what, where, and when, and we can help assess the level of confidentiality of any stored data. This involves asking specific questions about angles such as access security and data security, and working with stakeholders until we fully understand their needs.
Non-functional requirements might not seem sexy, and stakeholders might struggle to feel inspired by them. But the next time you are eliciting non-functional requirements, why not bring along one of the articles linked above. It might help your stakeholders see the relevance!
