Answer the question
In order to leave comments, you need to log in
Answer the question
In order to leave comments, you need to log in
Here's a similar list I would paint:
1. Errors that lead to an abnormal termination of the program (memory crashes, all sorts of critical runtime exceptions) are not allowed. Attribute scenarios in which they are valid (it is unlikely that this is possible in the release version, but it may be in beta).
2. What will happen if, nevertheless, the program abnormally completed its work, will the data be lost. In general, what will happen to the data, saving the state. This must be written down.
3. Does the program work everywhere or only where there is a connection. What are the requirements for the quality of communication, connection speed.
4. Necessary functions of the device that are needed for operation. accelerometer, camera, etc.
for a mobile application, it is more about the ability to restore the application after an unexpected termination. Preferably from the same point where the user stopped.
This section implies the operating conditions of the application under which reliable operation is ensured.
For example, "Reliable operation is ensured when an Internet connection is available at a speed of at least N kB / s ...".
If there are no special requirements, you can write something like "Reliable operation is ensured under the operating conditions of the mobile device." Then you will not have any claims due to a hanging application if the phone was left under the sun and it overheated.
Didn't find what you were looking for?
Ask your questionAsk a Question
731 491 924 answers to any question