Verification of software requirements with simulation

By Nikita Galkin (nsgalkin@edu.hse.ru)

Verification of software requirement is an essential key to make sure that a software system fulfills its intended purpose, specified requirements and functions. That makes verification a critical step in the software developing process, providing a quality control. As per IEEE: “Verification is the process of evaluating the system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase” [1]. Only verification is able to give feedback about the path of development, making the current base of software solid for further work.

Often verification tightly related with software testing, when the pack of trained testers from development team makes sure the result is satisfying whilst in the process of development. Development team is able to circulate the process of development and verification, finding mistakes in time and fixing them before it is too late. In scrum methodology testing allows to check the results and come back to fixing every sprint, maximizing the efficiency and the overall quality [2]. Thus, verification always enhances the way product reflects planned requirements, makes the result better, more comfortable for users and profitable for stakeholders.

After we see how important testing and verification in general are, we can get to the specific approach of verification – simulation.

Simulation refers to the process of using a computer program to model and study the behavior of a system. In many cases, that is the use of program itself and testing by interaction with the software product. For example, the game. We can use Unit testing to check the way every separate part works [3]. But it is faster and more comfortable to check the made program by simply launching it and “simulating” the work. One advantage of simulation is that it allows developers to identify and address potential issues early in the development process. Tester does not need to write any additional code and can check the output on the spot. This logic works with the most types of software.

Functional requirements define features and functionalities that a software application should have to meet the needs of users. They describe the behavior of system [4]. Exactly that behavior is testable through simulations, where users can launch the program and test desired scenarios. This testing might identify failures, that have to be fixed: not working buttons, glitched navigation panel, bug with no saved data, unpredictable errors and so on. For the whole process tester needs to operate software in place of user, applying imagination to find weak spots.

Simulation also can provide the test of need or correctness of these requirements. That can help developers that are not sure in realization or design, by testing it fictionally on themselves or a limited number of users before deployment.

Here are the lines from the book, that you can find in references [5]: “The non-functional requirements are those aspects of the IT system that, while not directly affecting the business functionality of the application but have a profound impact on the efficiency and effectiveness of business systems for end users, as well as the people responsible for supporting the program. The definition of these requirements is an essential factor in developing a total customer solution that delivers business goals”. Therefore, verification of these is the same important as validation of functional requirements. Exactly non-functional requirements describe operational aspects of application, preventing it from being undesirable. Furthermore, any functional requirements are made due to non-functional ones.

Simulation is a very wide term that can be variously used in software development. It can be used for verification of both functional and non-functional requirements. We can check functionality through testing, also simulate situations that are too risky to face in reality. For example, we can check the ability of system to hold the load of users by simply simulating their actions before any deployment. Or we can use team of unexperienced users to operate the software without any help or knowledge. Simulation should be used for the attempt to break the system, steal the confidential data, destroy user’s device. These actions done after release by unknown users on real people might lead to huge financial issues. Simulation can be used to verify various aspects of software requirements, such as performance, usability, operability, portability, security, safety and more…

Simulation is the fastest way of software testing, that is available for any developer and user, experienced and not. It displays the result the way it is when deployed into production, so matches the user experience perfectly. Can be used to accidently find unnoticeable weak spots, prevents from huge data leaks, problems. It is the universal method for both functional and non-functional requirements.

On the other hand, simulation might be too volumetric to give stable results. As number of functions in the software grows, tremendous number of overall scenarios appears. Sometimes it is a way too troublesome to simulate and test every scenario existing. It is much harder to keep a track of done actions, figure out issues in code and simulate repetitively every time, especially with programs that do not launch quickly.

Simulation is a necessary part of software requirements verification, that provides undeniable advantages in many aspects of software development. However, it shall not be the only tool for software testing either. Different tools fit different goals.

[1] IEEE01 | Institute of Electrical and Electronics Engineers website | https://www.ieee.org/

[2] Scrum Body of Knowledge 3rd edition | https://www.chardaeconsulting.com/wp-content/uploads/2019/01/SCRUMstudy-SBOK-Guide-3rd-edition.pdf

[3] The art of software testing by Glenford J. Myers| https://malenezi.github.io/malenezi/SE401/Books/114-the-art-of-software-testing-3-edition.pdf

[4] The Requirements Engineering Handbook by Ralph R. Young (pp. 51-52) | https://www.acqnotes.com/Attachments/The%20Requirements%20Engineering%20Handbook%20by%20Ralph%20R.%20Young.pdf

[5] Mastering Non-Functional Requirements by Sameer Paradkar (pp. 1-8) | https://books.google.ru/books?id=lHc5DwAAQBAJ&printsec=copyright&redir_esc=y#v=onepage&q&f=false