Why is it important for organizations to include security and application performance considerations in the requirements management process, and how can they most effectively do this?
The most important reason to consider application security and performance during the requirements management process is that problems are easier and cheaper to address earlier in the system's development and deployment lifecycle. The classic reference for this is Software Engineering Economics by Barry Boehm, where he asserts that fixing an error in production costs 40 to 1000 times more than what it would have cost to fix during the requirements development phase.
When considering security, organizations need to consider the authentication and authorization requirements the system will need to meet at the beginning of the project. They also need to look at what data the system will handle, who will have access to that data and how that data should be stored. And as always, compliance needs must be considered as well. Systems handling credit card data, financial or health information or any personally identifiable information may be subject to compliance regulations such as PCI or HIPAA. Failing to plan to meet these regulatory requirements can lead to expensive remediation efforts down the road.
When it comes to performance, developing standards during the requirements process puts the implementation team in a position to shoot for specific goals rather than responding to qualitative objections down the road such as "it just feels slow." Having advance knowledge of the required performance characteristics can drive important design decisions such as the use of caching and deciding which system tiers data lives on. Another often overlooked concern for performance is the user interface – managing a list of 100 records is not the same as managing a list of 100,000 records. Having an explicit understanding of the expected data volumes during the requirements process helps to get important questions asked earlier rather than after binding decisions have been made.
Furthermore, in a cloud environment – specifically Platform as a Service (PaaS) and Software as a Service (SaaS) – organizations need to understand that they are beholden to their cloud vendor to provide systems with the required security and performance characteristics. In fact, a strong argument for using cloud-based systems is that it makes the cloud vendor responsible for certain aspects of performance and security. That is certainly valuable – assuming the cloud vendor can actually meet these goals.
To best address security and performance concerns during requirements development, system implementation teams need to make these concerns explicit. Teams should lay out explicit standards for key performance metrics like expected page response times and number of expected concurrent users. Similarly, they should also document expected security characteristics. When specifying security requirements, it is important to both address the security features required for the system as well as what is needed for the system's logic for application features to be considered secure. Security features refer to specific technologies that should be used during system implementation – for example, requiring the use of a Secure Socket Layer (SSL) to protect Web traffic. In addition to this, organizations need to specify how does the system logic respond to attacks and remain resilient in the face of malicious activity – for example, mandating code-level authorization checks before a user is shown different records from the database. Both are needed for sufficient security requirements coverage but many organizations myopically focus on security features at the expense of the deeper security requirements understanding represented by secure features.
If these things are made explicit during the requirements process, there needs to be a signoff step so that all parties involved have agreed on the security and performance requirements for the system before architecture and design begin. These standards may evolve as system implementation progresses, but having a baseline in place provides the project team with a common set of goals and as a result, it will be easier to evolve those goals rather than impose totally new concepts later in the lifecycle.
This was first published in September 2012