ANSWER

Different organizations have different methods and processes for eliciting and discovering non-functional requirements.  Common ways of discovering non-functional requirements (NFR) include:

1. Stakeholder goals, values, and concerns - Talk to the stakeholders!  What a novel idea! ;-)   The analyst must find out what is important to the stakeholders (including the users), what qualities are must have in order to achieve stated business and organizational goals.  For example: must be able to create a new transaction in under 2 minutes.  Also, find out what are the stakeholders worried about.  For example: Users are afraid that the new system will be too slow (because the current one is).

2. Legacy system and/or existing platform constraints - the analyst takes a look at constraints dictated by the environment into which the new system must fit, the existing systems with which it must integrate, and the technical platform(s) it must use.

3. Competitive analysis of system qualities - additional non-functional requirements can be discovered by analyzing the qualities of competing systems.  For example: how many users can the competing system support and do we need to do better?

4. Industry and market trends - try to understand the direction the industry or vertical market is taking and identify key trends.  For example: What is the average annual growth of the industry in number of transactions?  Do customers expect faster and faster response times?

5. Standard non-functional requirements templates and categories - in many organizations business analyst simply uses standard templates and categories in order to focus on and ask questions about each type of non-functional requirement (could be done using a questionnaire): usability, scalability, performance, availability, stability, extensibility, etc. 

6. Pre-established trigger questions - many teams develop a set of trigger questions to be asked of the stakeholders and development team.  For example:

• Documentation & Training
  • What kind of documentation is required and who will be the users of the documentation?
  • How quickly should a brand new user be up and running on the system?
  • Is there a need for context sensitive help?​

• Performance Characteristics

• Are there any speed, throughput, or response time constraints on the system?

• Are there size or capacity constraints on the data to be processed by the system?

• Do performance requirements vary by: time of day, day of the week, type of user, etc.?

• Error Handling and Extreme Conditions

• How should the system respond to input errors?

• Is there a need to track errors via a mechanism such as error logging?

• Are there expectations on reporting errors: per categories, by business channel, etc.?

• External Interfaces & Interoperability

• Is there data coming from (going to) external systems?

• Are there restrictions on the format or medium that must be used for input or output?

• How must the data exchange with external systems function: real-time, hourly, daily, etc.?

• System Modifications

• What parts of the system are likely candidates for later modification?

• What types of modifications are expected?

• How often do you expect the system will need to be modified?

• Security

• What data managed by the system must be secure?

• Who, when, where should be able to access the system?

• Disaster Recovery & Business Continuity

• How often will the system be backed up?

• Who will be responsible for the back up?

• What data must be saved in case of a disaster?

• How quickly after a major disaster must the system be up and running?

• What is the acceptable system downtime per 24-hour period?