This blog post is part of a series on non functional requirements, and how they take most of the effort.
The scenario
You want a third party to implement an application package to allow people to buy and sell widgets from their phone. Once the package has been developed, they will hand it over to you to sell, support, maintain and upgrade and you will be responsible for it,
At the back-end is a web server.
Requirements you have been given.
- We expect this application package to be used by all the major banks in the world.
- For the UK we expect the number of people who have an account to be about 10 million people
- We expect about 1 million trades a day.
See start here for additional topics.
What security?
Security covers
- Application users – for example using their mobile phone to authenticate
- What userid will be used on the web server to run the transactions. Is this related to the end user’s id?
- What fields are visible to the application user
- What fields are available to the help desk staff. For example can they see the full date of birth – or they type the DOB into a field and it is validated.
- Are you going to provide audit information for any changes to the database; for all fields, or only for some fields.
- Are you going to report on read only access to some fields.
- How are you going to report violations
- Are you going to use encryption on fields. How do you protect the keys.
- Is your database going to be encrypted – so if someone copies the database file they are unable to read it, or are you going to rely on the fields being encrypted.
- What encryption are you going to use – some encryption is weak (quantum computers will be able to decrypt some ciphers in an instant)
- Are your backups encrypted?
- Able your backup and disaster recovery sites able to restored from backups. Do they have the correct certificates?
- If someone phones in and says they have forgotten their password – how do you validate the request – bearing in mind the phone may have been stolen.
ColinPaice 