top of page
  • Zdjęcie autoraKarolina Zmitrowicz

Business analysis and security requirements

In requirements engineering, we encounter two fundamental categories: functional requirements and quality requirements. Regrettably, there tends to be an overemphasis on functional aspects, often leading to the oversight of essential quality features. Among these quality requirements, security requirements hold a distinct significance, as they not only prove critical for numerous systems but also pose a considerable challenge in their specification and implementation due to the need for extensive technical expertise.

Security requirements assume utmost importance because they are directly tied to cybersecurity, a paramount concern in our digital landscape where virtually everything is interconnected through the World Wide Web. This interconnectedness spans across various domains, including our business support systems, home applications, automobiles, smartwatches, and even our smart homes. The pervasive reliance on interconnected technologies underscores the vital role that security requirements play in safeguarding our data, privacy, and overall digital well-being.

Cyber security is the practice of defending computers, servers, mobile devices, electronic systems, networks, and data from malicious attacks.

Security requirements

Let's first explain what security requirements are (IREB Glossary):

The degree to which a system protects its data and resources against unauthorized access or use and secures unobstructed access and use for its legitimate users.
Note: Security requirements may be stated as quality requirements or in terms of functional requirements.

In simple terms, security requirements refer to the mechanisms that protect a system from attacks. They are one of several types of requirements classified as quality requirements.

These requirements can pertain to different aspects:

  • Physical location (e.g., Servers must be located within the territory of the Republic of Poland).

  • Logical separation (e.g., On-premise or cloud-based division).

They may also involve compliance with various norms and standards. One of the most popular guidelines for security is the OWASP Top 10. This document serves as a standard awareness resource for developers and web application security, representing a widely accepted consensus on the most critical security risks to web applications.

Furthermore, security requirements can be imposed by regulators within specific sectors, such as the banking industry. These requirements may encompass both non-functional aspects (e.g., data encryption using AES-256 with key management and backup through Hardware Security Modules) and functional aspects (e.g., data access methods provided by the system).

Are security requirements really that important?

Yes, they are crucial because failing to meet them can lead to the rejection of a project by the client, even if everything else is executed correctly. Unfortunately, there is often very little room for negotiation in this regard, if any at all.

Security requirements hold significance in nearly every project, especially when the system handles sensitive data, such as customer information. However, they are not always clearly articulated, and this frequently becomes a problem. The client must know or at least have a clear understanding of the security level they expect and require, as it now serves as a major financial factor in the overall project.

Trust is the currency of security. Issues related to security vulnerabilities are highly visible and can expose a company to evaluation by the entire market. They not only result in significant financial losses and penalties but, perhaps even more importantly, can damage the company's reputation. After all, who would want to keep their money in a bank that "can't protect" their data from leaks?

In many cases, security requirements can be considered "MUST," leaving no room for completing the project or gaining client approval if these requirements are not fulfilled. It is essential to conduct a thorough analysis of these requirements and often refine them precisely to ensure they can be met within the project's constraints. Some specifications provided by the client may be vague or seemingly achievable, but without proper analysis, verification, and clarification, they may lead to serious problems in later project stages.

Examples of security issues:


Security requirements and other system requirements

Security requirements can have a significant impact on other requirements and often influence critical project or technical decisions. In some cases, the final system may lack certain functionalities expected by the client because they significantly lower or negatively affect the overall security level of the system. Conversely, specific functionalities may need to be included due to regulatory demands.

Moreover, architectural considerations and localization issues further compound the complexity. All of these factors not only influence the scope of the system but also have cost implications. Balancing security requirements with other system needs is a delicate task that requires careful planning and consideration to ensure the development of a robust and compliant solution.

Security requirements and the role of a business analyst

It is quite common to encounter the misconception that security requirements are purely technical and have nothing to do with business analysts or system analysts. In many projects, analysts primarily focus on gathering functional requirements from business stakeholders, leaving aspects like security and performance to be handled by others. However, this approach can lead to significant problems later in the project.

As previously mentioned, security requirements can impact the system's architecture and other aspects. Delaying their consideration often results in the need to make costly and risky changes to the system. While a typical business analyst may not possess deep technical knowledge, they are still knowledgeable about requirements and how to gather them.

Security requirements are just a specific type of requirements, and they can be gathered in the same way as functional or other types of requirements. Like with any other requirements, analysts can use documentation analysis, interviews, and other techniques to gather security requirements. It's essential to focus on understanding the business environment and identifying stakeholders, including regulators.

A business analyst's responsibility is to comprehend the business context and identify the needs of various stakeholders, including regulatory bodies. Based on this information, the analyst can determine security requirements that may arise, such as those related to data protection under regulations like GDPR. The specifics of how security measures are implemented are tasks for the development team, not the analyst.

Collaboration within a team is vital, and having members with both business and technical expertise ensures better understanding and minimizes misunderstandings when dealing with not just security requirements, but all technical requirements.

Prioritizing security requirements follows the same principles as prioritizing other functional requirements. By analyzing the potential risks associated with data breaches or other security issues, the team can prioritize security measures accordingly.

In conclusion, security requirements are just another set of requirements. The key lies in understanding their origins, the motivation behind them, and the specific risks they aim to mitigate. Business analysts play a vital role in gathering and analyzing these requirements, ensuring a comprehensive understanding of client needs, including security considerations.

I'm an analyst. I don't know much about security

What if you lack specific knowledge to effectively define and manage security requirements? What can help you, and where can you get basic information?

In such a situation, the first step is not to be afraid to admit your lack of expertise and seek assistance from colleagues or experts in the field. Cybersecurity is a complex and evolving domain, and it's entirely acceptable to acknowledge areas where you may not feel fully confident. Collaborating with colleagues who have the necessary knowledge can be beneficial and help fill in the gaps.

However, it's also essential to proactively work on expanding your knowledge and understanding of security requirements. There is a wealth of information available for free or at relatively low cost. One valuable resource to explore is the OWASP (Open Web Application Security Project), which offers a comprehensive range of resources related to web application security.

Another sources worth mentioning are norms by NIST (National Institute of Standards and Technology) like SP 800-160 Systems Security Engineering, SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations or SP 800-218 Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities.

A lot of valuable information can also be provided by the ISO (International Organization for Standardization) organization with their standards, in particular ISO/IEC 15408-1:2009 Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model or

ISO/IEC 13335-1:2004 Information technology — Security techniques — Management of information and communications technology security — Part 1: Concepts and models for information and communications technology security management.

There are many more valuable sources, however this could be the first step in acquiring some knowledge about security.

Keeping up with the latest developments in cybersecurity is crucial, as it is an ever-expanding field with new threats and solutions emerging regularly. Numerous sources, including blogs, online courses, and webinars, provide accessible and well-written content that can help you stay informed and learn about essential security concepts.

It's crucial to approach this learning process with a willingness to explore and a desire to improve your understanding of security requirements. By doing so, you can contribute more effectively to the overall project and make informed decisions that prioritize security.

Additionally, there should be no shame in admitting a lack of expertise in this area. Being transparent about your knowledge gaps and seeking support will lead to cost savings in later project stages and potentially at the project's client acceptance moment. Openly communicating about areas where you may need assistance demonstrates honesty and builds trust, which is foundational in security practices.

Ultimately, cybersecurity is a collective responsibility, and fostering a culture of learning and collaboration can greatly enhance an organization's security posture. Embrace opportunities to gain knowledge and work collaboratively with experts to ensure that security requirements are well-defined and effectively managed in your projects.

Author: Karolina Zmitrowicz and Grzegorz Skrzyński

5 wyświetleń0 komentarzy

Ostatnie posty

Zobacz wszystkie

Jak nie "pisać” wymagań? Krótka instrukcja.

Równoważnik zdań to nie jest opis wymagania. “Wymaganie” o brzmieniu "Dodawanie produktów" może być co najwyżej skróconym opisem wymagania, ale na pewno nie kompletną specyfikacją. Dostarcz informacje

Post: Blog2_Post
bottom of page