Identify non-functional requirements
Requirements are commonly referred to as either functional or non-functional. Functional requirements describe what the solution needs to do or its behaviors, and non-functional requirements describe non-behavior aspects of the solution such as performance requirements. This topic covers considerations for non-functional requirements.
Frequently, non-functional requirements might have dependencies on factors that are out of your control, such as age of computers, network bandwidth, network firewall and internet security software, and compliance officers. Accordingly, you need to identify any factors that might impact your ability to address the dependencies, or dependencies might exist that could risk your delivery schedule. If the customer needs to replace hardware, delays would likely occur. If the customer has legacy applications that require an older browser and they can't use modern browsers, your performance goals will be impacted. The goal is to identify these issues early in the project; if not addressed up front, you risk the customer perceiving that the application is defective.
Additionally, this situation frequently necessitates having a technical discovery session with the client's IT team. It is best not to overwhelm the business with deep technical discussions.
Non-functional requirements capture the elements that users might not directly care about but are important to support the proposed architecture and operational viability of the solution. Non-functional requirements often influence user adoption and perceived satisfaction with the solution. As with functional requirements, non-functional should be prioritized and can be delivered incrementally.
Examples of common non-functional requirement types include:
Availability
Compliance/regulatory
Data retention/residency
Performance (response time, and so on)
Privacy
Recovery time
Security
Scalability
Non-functional requirements examples
The following examples are of well-composed non-functional requirements:
Average screen load time for internal users that are not mobile will be less than three seconds.
External portal must be able to handle 100 concurrent users who are performing case submission.
The following examples are of poorly worded non-functional requirements:
All screens in the app should load as fast as possible.
External portal must be able to handle peak traffic.
System must be recoverable after a disaster.
Feasibility
While all requirements should be feasible, non-functional requirements are often more specific; therefore, extra consideration to the realities of budget and resources is appropriate. For example, specifying 99.999 percent availability when the core app availability is 99.9 percent isn't realistic. Additionally, it is possible to specify a requirement that is achievable with enough budget but not have budget to meet the requirement.
Measure compliance
When a non-functional requirement involves a measurement, it should specify how it will be measured and compared for compliance. For example, if you have a three-second form load time requirement, determine whether it is for on-campus only or if it includes mobile users.
Exercise: Find the non-functional requirements
Review the list of non-functional requirements types:
Availability
Compliance/regulatory
Data retention/residency
Performance (response time, and so on)
Privacy
Recovery time
Security
Scalability
Determine which of these non-functional requirements will likely be of concern to Woodgrove Bank. Consider what type of concerns you could anticipate and how you might address those concerns. Assess whether any other concerns might exist that you haven't yet thought of.