Requirement gathering - Thinking beyond functionality

Continuing from my last post about non functional requirements , here are some more pointers to consider while designing architecture of a software product.

These are mostly relevant for a SaaS based product targeted at wide variety of locations and audience.

These points need to accounted not only for design but also for testing:

1. Scalability : How will the product scale 
1. To different screen sizes : This involves a sound design strategy on how different parts of the screens will scale up or down based on the resolution and screen size of user. The key is to ensure that the usability and readability aspect is maintained at all variations. 
2. To different browsers : This is very important aspect that architects and designers need to be aware of from the very beginning. It is important to understand and analyse compatibility across browsers before deciding on client side components to be used for development.
3. To different platforms : Web, Mobile , OS etc
2. Handling date and time zone: If the users are going to be in different time zones then how date formats and timings are going to be handled. Here are some important aspects to consider :
• Date Time Format : 
• Fixed format for all
• Provide users with the flexibility of choosing format
• Pick a format based on user location and give ability to customize.  
• Activity Timings :  Normally activity log is maintained for all the activities performed by a user. These logs are used to show activity history in various forms. While the events are saved in database using a standard time zone , we might want to show the time to user based on his or her time zone.
• Scheduling :  Some products allow users to set up reminders and notifications. These notification need to trigger based on user' time selection and user time zone. 
3. User Types & Permissions:  Its important to identify few key User roles of the system and also the set of permission each type of role will have. We may want to group users using user groups. We may want to create an administrative interface to modify permissions given to a role. Based on the permission granted to the user , we will have to filter out the options available to the user. We may also want to filter data that is visible to a user. Also each user may have a different home screen based on the role and some parts of the system may be completely invisible.
4. Delete Operation : Following points are worth considering before finalizing any solution:
• Soft Delete Vs Hard Delete :  Delete operation can be performed in two ways. Soft delete which is just marking the data as deleted but leaving it in database and Hard Delete : which is physically deleting the data. Hard delete can be combined with archiving strategies.
• What happens to search ability of data which is soft deleted? How will the references to deleted data show up? What happens to the logs ?
5. Concurrency : How the system will respond if more that one user are trying to update same data? There are basically two important strategies : either lock the data which is being updated by one user or adopt the strategy of what ever was last saved would be the latest update.
6. Integration : Are there any integration requirements with other systems e.g integration with payment gateway, integration with user management systems, video streaming systems etc
7. Customization : Does the system support customization for different users. Customization can be enabled at various aspects:
• Color schemes : How various elements of system will be displayed.
• Home screen/ Dashboard : What will the user view on the landing screen after login
• Feature Labeling : Some features can be labeled differently for users of different domains as per industry standards of the domain.
8. User Account Management : Does the system support integration of login with other popular apps like facebook, linkedin, google etc.