Introduction
Non-functional requirements are difficult to see from the user’s perspective, whereas functional requirements are easy to understand from the user’s perspective.
However, neglecting non-functional requirements can lead to major rework during development and post-release troubles. In this article, we will explain the flow and points of defining non-functional requirements while utilizing the non-functional requirements grade of IPA.
Difficulty and importance of non-functional requirements
The non-functional requirements are simply “to use the system safely and comfortably”. There are items such as performance, expandability, operation, and maintainability, and it is difficult to see and understand when using the system normally.
It is a non-functional requirement that is often neglected compared to the functional requirement, but it is an important foundation that supports the system. Inadequate non-functional requirements can lead to system unavailability in the first place.
A good engineer is someone who can successfully engage the people involved in this non-functional requirement, which is unfamiliar to anyone other than a system developer.
What if there are omissions in non-functional requirements?
What exactly happens when a non-functional requirement is flawed?
Non-functional requirements are broadly classified into six categories, and specific examples will be given for each.
availability
It becomes unusable when you want to use it because it stops frequently or stops for a long time.
Performance / expandability
The response is slow or does not come back. It will be difficult to increase resources
Operation and maintainability
It takes a lot of time to operate the system
Migration
Migration fails and it takes a lot of time to switch back
Security
The system is infected with a virus and customer information is leaked.
System environment / ecology
It violates the law and requires payment of a surcharge and system renovation.
All of them can be avoided if the requirements are properly defined and the cost is high. However, excessive requirements are costly and can be detrimental. For example, it should be noted that excessively increasing the level of security may lead to deterioration of usability and usability as well as cost.
Flow and points to define non-functional requirements
Non-functional requirements are difficult to define, and without experience, many omissions occur.
If you utilize the non-functional requirement grades created by the Information-technology Promotion Agency (IPA), there will be no omissions (a comprehensive list of items), no misunderstandings (specific numerical settings), and early (general confirmation with the model system) non-functional requirements. You can check the requirements.
Non-functional requirements affect the selection of infrastructure equipment, so it is a great advantage to be able to determine them early.
The non-functional requirements grade is created by a group of engineers from domestic SI companies who have been struggling to define non-functional requirements for many years, so there is no reason not to use it. Anyone can download and use it if they follow the terms of use that accompany the copyright.
Source: Strengthening the upstream process of system construction (non-functional requirement grade) | Information-technology Promotion Agency, Japan
The flow of application of non-functional requirements grades is large, and consists of three stages: “1. Selection of model system”, “2. Level determination of important items”, and “3. Level determination of non-important items”. You can step-by-step detail the non-functional requirements that tend to be ambiguous.
1. Selection of model system
First, select the model system that will be the basis for determining the level of each detailed item. Concerning the model system decided here, the provisional level of each item will be decided and adjusted.
There are three levels of model systems: “systems with almost no social impact” such as those used in specific departments within a company, and “systems with limited social impact” such as systems that form the basis of corporate activities. It can be divided into “systems that have an extremely large social impact” that serve as social infrastructure. Estimates such as operating rate, performance target, and operating time are also listed, so choose the one that is closest to you.
For example, in the case of a “system with limited social impact,” the operating rate is set at 99.99% (annual stoppage allowance time is less than 1 hour), and in the event of a disaster, recovery is set within a week.
2. Determining the level of important items
Next, determine the level of about 100 important items. The reference level is set by the model system determined in 1., so if there is a difference, consider changing it. According to the model system, the operating rate is set to 99.99%, but if you do not need that level, you can change it. The higher the level of each item, the higher the cost, so adjust the level after understanding the user’s budget.
3. Level determination other than important items
Finally, other than the important items, 200 or more detailed items will be decided in the same way as in 2. Since there are many items, you can proceed smoothly if you proceed while having the client imagine it by drawing it.
By deciding the level of each item together with the client in this way, the definition of non-functional requirements can be completed. Again, non-functional requirements are an important item. Let’s solidify the definition with the approval of the client’s key man such as the business manager.
In conclusion
It’s easy to think that defining non-functional requirements is difficult because the substance is invisible, but if you take advantage of non-functional requirements grades, don’t be afraid. Even if you are an engineer who cannot imagine non-functional requirements, why not take a look at the non-functional requirements grade and get an overall picture.
If you ever want to know about similar things, check out the Facebook page Maga Techs
