How to Define Non-Functional Requirements of a Project?
How to Define Non-Functional Requirements of a Project?
There are two sides to requirements. There’s the functional “what are the features to be built to fulfill the user’s need?” – This part is usually defined on all projects and lies in the product owner’s domain. Then there’s the non-functional requirements like “The feature must not compromise security” or “Performance metrics can’t fall below X”. These are the non-functional requirements and usually fall under the quality domain.
Developing the product follows functional requirements but developing it the right way covers the non-functional requirements. Of course, for any requirement to work, they need to be well defined and clear. Requirements like “The system must be secure.”, “The system must not go down.”, or “The system must not have performance issues” do not clarify the right measurement as well as the right action to be taken. Hence, the whole purpose of non-functional requirements are lost.
If defined well, NFRs can be a great checklist for quality and performance for any software.
In this blog, we share how non-functional requirements are defined at Mindbowser. We usually divide quality into separate areas of focus and then define the NFRs for each.
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.
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
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
Now you can get started with automating your code review process.
Sign Up with Codegrip and get started for Free!
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
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
Here are the basics for building a secure software application:
- All communication should be using HTTPS over TLS 1.2
- APIs should have auth token (JWT token with SHA256 algorithm)
- 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.
Conclusively, Non Functional requirements enable you to understand the performance and health of your ongoing development so that you can make critical adjustments in your execution to achieve your goals. By defining non-functional requirements as above, you bring your team on board with the right development practices and the right way to do things.
Post a Comment