How to Define Non-Functional Requirements of a Project?

1. UI Responsiveness 

UI is crisp and consistent across all major devices, standard and non-standard accepted viewports and resolutions are a standard requirement. 

Browsers for compatibility: Internet Explorer 10 and above. Google Chrome V19.0.1084 and above. Safari 5.1.10 and above. Firefox 10 and above.

Devices: iPhone 6 and above. Android KitKat and above including Android One. Device Sizes: iPhone 6 and above. Xiaomi Redmi 4 and above. One Plus 3 and above. Samsung Galaxy S7 and above.

The range of supported devices depends on app features, especially if we are developing an IoT app.

Display a pre-defined simple error image in case the device/browser/very low resolution is not supported

Testing should be done on multiple devices and test reports shall be produced.

Screen should seamlessly render and work across all the popular and possible device viewports without loss of data (in vision) or loss of functionality in the landscape as well as portrait mode on mobile devices.

Landscape mode support depends on the requirement. Landscape mode may also have a different UI than portrait mode

2. UI Response Time

UI Response time calculates how long it takes to completely load pages and extends lazy loading techniques for large data sets. The focus is on improving the page load speed, especially on slow network connections.

Complete Page loads can be expected in under 7 seconds. A page that has lots of data/tabulation/chart also can initially part load in under 2 seconds and rest later using lazy loading.

After the page loads, it should be responsive to user interaction in under 1 second. If there’s an animation or transition running, or the user is scrolling the pages, the browser needs to match the device’s refresh rate.

3. Navigation

Proper Navigation helps users find their way on the platform. Users should be able to get through different features based on their cognitive knowledge.

The navigation has to be smooth without halts or glitches and follow standard navigation guidelines:

• Modular UI architecture
• Load data fast (<2 seconds)
• Use as little data as possible
• Use static assets from a local cache
• Separate content from navigation
• Retrieve and display page-specific content (HTML, JSON, etc.)
• Optionally, cache dynamic content

4. Code Quality 

At Mindbowser, we use Codegrip to maintain the code quality. Codegrip is a cloud-based SaaS tool for code review and software analytics. It helps programmers to improve their code quality by identifying issues and bugs of their code that may affect the project’s performance, efficiency, etc. It also detects security vulnerabilities as early as possible in the software development life cycle with just one click.

Other recommendations include

• Use modular decoupled architecture which enables pluggability/replaceability of any layer without depending on the other layer too much [MVVM like structure]
• Follow secure coding practices and not store encryption keys in the code
• Pass the scan of any globally popular code scanning platform such as CodeGrip
• Pass the static code analysis scan with having no critical blockers or high priority errors or basic code sanity issues/blunders to be resolved
• Concise and reusable code written by following good object-oriented techniques such as SOLID principles

The standard code review process that we recommend is as follows

5. Network

Testing should be done on different networks for speed and behavior.

Testing on impaired NWs (impairment conditions of real-world IP networks such as network latency, network delay variation (jitter), bandwidth, congestion, packet loss, packet FCS errors, packet bit errors shall be tested).

Recommended checks are:

• Use timeouts (10s) to handle intermittent connectivity,
• Handle unreliable connectivity (3 continuous disconnections and packet loss testing)
• Prompt error messages of “loss of connection” on network loss, prompt “slow connections” message in case of impaired networks. Inform users of their current state and change of state
• Handling of switching between Wi-Fi and Cellular and vice versa within 10 seconds

We recommend following the Google guidelines to online and offline mode UX. Read more here

6. Benchmarks

Follow standards laid down by platforms to avoid rework and make the most out of platform offerings.

• Application deployment should strictly adhere to Apple App Store & Google Play Store submission requirements
• Should adhere to requirements such as Safety, Performance, Business, Design and Legal guidelines for both Apple and Google

7. Security

Here are the basics for building a secure software application:

• All communication should be using HTTPS over TLS 1.2
• All APIs should have auth token (JWT token with SHA256 algorithm)
• All Personal Identifiable data would be always encrypted
• Files on servers would be encrypted
• All documents generated should be password protected, display error message in case of the wrong password with the date it was set and a hint of standard documents – like ‘ this is the same password as all your other documents’
• Do not add sensitive data openly to request payload
• Use OAuth 2.0 for authentication using popular IDPs such as Google, MS ADFS etc.

8. Crash Reporting

Crash Reporting helps to identify bugs and errors as they happen. 

The software should have the ability to access the report/logs in case of issues. Tools like Crashlytics should be integrated.

Read more on 20 Tools That Any Non-Tech Founder Can Use To Manage Their Tech Product Development

9. Task & Delivery Management

Should also be able to track the progress of the project. 

The timely status report should be shared. Any red flags should be reported proactively.