Is security a key non-functional requirement?
Security is an important aspect of most systems, so it’s essential that it is thought about and documented clearly. Having a dedicated security section provides a way to explain how your architecture will meet security requirements such as authentication, authorisation, data confidentiality, etc. Some organisations have specialised security teams that will help with and/or need to review your work in this area before deploying your system into a production environment. Being explicit about security helps you spot any holes before it’s too late.
Is there a clear understanding of how security is handled within the architecture and how have any security requirements have been satisfied? This may cover:
- Confidentiality of data between components (e.g. during user login, during requests between components, using technologies such as web services or messaging, across public networks).
- Different types of users and their roles.
- The use of a security realm or integration with in-house single sign-on mechanisms.
- Network separation using firewalls and DMZs (red, amber, green model).
- Restricted access to resources.
- Permissioning of data of a per user/role/etc basis and the ability to modify those permissions.
- Storage of credentials (e.g. database logons).
- Distribution of certificates and keys.
- Runtime sandbox.
- Signed binaries.
- Essential code only on each architectural tier.