How to address security during requirements gathering

In today's environment of readily available information and fast searching it is important to consider how you will protect confidential information. Not only at the first level of defense, such as who can log in to a system, but making sure enough information is available to other consumers who can benefit from the information your application will gather. At the same time you want to make sure you are not compromising anything confidential. For example, is it alright to let a user see how many patients were treated at a hospital as long as you don't let that user see the patient names? That may be one type of security requirement you would need to think through and build into your application.

In order to discover these security requirements, you have to consider the environment you work within. Some requirements may be dictated for you already if you work in a highly regulated industry or you may need to discover them. Consider who will have access to these systems. Brainstorm to gather your list of users beyond the obvious ones. For example, could an unauthorized user run a report against a database that would expose confidential information?

Security requirements will likely drive the architecture in a certain direction, and considering these requirements up front might also save time or money later on. You may discover there is a pre-packaged security module that can be purchased or that your company has a user authentication system already in place, enabling you to reduce your cost and time to completion. It is probably beneficial to work closely with the application architect during these discussions about security.

Security requirements resources: Authentication and authorization for Web applications Wachovia banks on entitlement management for fine-grained application security Integrating security into your software development life cycle

I worked on a project where a legacy application was being made available via the Internet to company employees. The legacy application did not have major security concerns, since it was installed on an employee's laptop and ran locally. That application benefited from the security of the operating system. However, during the process of making the application available via the Internet, the application team had to consider an entirely new security model. The legacy application as it was did not even require the user to login. That, of course, would no longer work with an Internet-based application, so the team had to consider the security requirements for accessing the system and adding a log-in capability. It turned out there was a single sign-on initiative under way and integrating with that system was the best bet. If we did not ask early on, we might have built yet another authentication system.

Requirements work continual during projects
I'd like to address the term "requirements phase" mentioned in the question. New requirements will be found throughout the lifecycle of the project. The question is how well you manage the change and what impact the new requirements will have on your plan. There is typically more requirements activity early in a project, but I caution against thinking that the "requirements phase" is complete until the next time.