CC BY-NC-ND
80
Verification of requirements for the simulation model of a production enterprise
Tatiana K. Kravchenko
Professor, Head of Department of Business Analytics National Research University Higher School of Economics Address: 20, Myasnitskaya Street, Moscow, 101000, Russian Federation E-mail: [email protected]
Nikolay I. Golov
Senior Lecturer, Department of Business Analytics National Research University Higher School of Economics Address: 20, Myasnitskaya Street, Moscow, 101000, Russian Federation E-mail: [email protected]
Aleksey V. Fomin
Senior Lecturer, Department of Business Analytics National Research University Higher School of Economics Address: 20, Myasnitskaya Street, Moscow, 101000, Russian Federation E-mail: [email protected]
Aleksey Y. Lipatnikov
Graduate of MSc Program
National Research University Higher School of Economics Address: 20, Myasnitskaya Street, Moscow, 101000, Russian Federation E-mail: [email protected]
Abstract
Developing variants of scenarios for a production enterprise's achieving a desirable financial position using simulation modeling tools requires a specification and verification of requirements for the simulation model. Availability of such variants of scenarios allows stakeholders to select the most efficient solution. The verification is performed by business analysts and key stakeholders; the aim is to assess readiness of the requirements for final approval and to check that the requirements provide all material information for future work. Verification includes evaluating the requirements regarding their compliance with the company's business analysis standards, as well as assessment of the model's completeness and common terminology used for description of the requirements. Understanding the desired solution, which meets all the stakeholders' requirements, is the most important element in requirements verification.
For developing a simulation model, which is essential for determining variants of development scenarios and covers financial flows of a typical production company, a list of verified requirements is determined. Criteria of requirements verification include not only acceptance criteria, but also the Graphical Requirements Analysis framework (GRA framework), that is used for verification of functional requirements. In contrast with other notations, representation of requirements for using
the GRA framework allows one to understand their structure and internal logic, as well as to detect emergent effects. The result of determining the verification criteria is the Verification Cross Reference Matrix (VCRM) that includes all the requirements, methods and criteria. In the final stage, we present an example of a diagram for one of the functional requirements.
The verified requirements should be used at different stages of constructing the simulation model, which is focused on development of scenarios for achieving the production enterprise's desired future financial position. Modeling scenarios of future development of the types "what will happen, if...?" and "what to do to achieve the goal?", using simulation modeling systems allows one to dramatically increase the quality of decision making.
Key words: requirements, verification of requirements, criteria for verification, simulation model, scenario analysis, acceptance criteria, GRA framework.
Citation: Kravchenko T.K., Golov N.I., Fomin A.V., Lipatnikov A.Y. (2018) Verification of requirements for the simulation model of a production enterprise. Business Informatics, no. 2 (44), pp. 65—78. DOI: 10.17323/1998-0663.2018.2.65.78.
Introduction
The purpose of requirements verification is to ensure that requirements meet quality standards and are usable for the purpose to which they apply. Verification of correctness of requirements imposed on a future solution is a very important task identified in the analysis and design definition area. Verified requirements should be easily understood by all the stakeholders.
Both solution structure and features of the business area of its implementation greatly affect the requirements verification procedure and, particularly, its key element — verification criteria. Therefore, identification of a verification criteria list taking into consideration specifics of the solution becomes a primary task in the entire verification process and promotes its successful completion.
A standard production enterprise needs to maintain a high level of financial stability. Management decisions intended to facilitate the organization's financial development have to be developed, based on thorough analysis of different alternatives for its future performance. Constructing the simulation model is required to prepare development scenarios for the production enterprise. The purpose of verifica-
tion of requirements for the simulation model is to check their correctness and implementation readiness. Defining the requirements list should rely on a number of particular verification criteria, using a range of business analysis techniques.
The object of the research is a standard production enterprise. The subject of the research is the group of financial characteristics of the core operations of the enterprise. The research goal is to define the requirements for a simulation model of a standard production enterprise to manage financial characteristics, one that is verified using a number of different criteria.
1. Simulation modeling of a production enterprise
Scenario planning aimed at identification of the future state of the production enterprise can be performed using multiple simulation modeling methods, for example system dynamics [1, 2] and agent-based modeling [1, 3]. At the present time, simulation modeling is widely applied for rational planning and management of the key characteristics of enterprises. For instance, it may be used for predictive modeling of oil production dynamics for
an oil company [4] or for scenario planning of the ecological reengineering of enterprises [5]. Other applications of simulation models include investment portfolio planning subject to macroeconomic conditions and maximization of the shareholder value of a vertically integrated oil company [6], scenario management of the characteristics of lending financial institutions and commercial banks [7], and scenario management of enterprises operating in the fuel and energy complex [8].
The important requirements imposed on the simulation models of the production enterprise include the following: application of multiple simulation modeling methods (for example, system dynamics and agent-based modeling) for a single model building, with variation of control parameters. Support of the Monte-Carlo methods and genetic optimization algorithms is supposed to be a significant feature of many models as well. Moreover, the essential requirements are presented by verifiability of the model outputs, external database integration and visualization of the simulation modeling results [1].
The present paper is concerned with analysis of a standard production enterprise which is characterized by a discrete manufacturing process. The development scenario of such an enterprise represents a sequence of execution of a certain set of contracts during a particular period in order to gain profits. Each contract execution is associated with incoming and outgoing cash flow generation. If at a given time the net outgoing cash flow exceeds the net incoming cash flow, a cash gap occurs and the enterprise quits staying liable for the present debts. The desirable future financial position of the enterprise should be presented by the absence of cash gaps and the maximum possible level of the profit, gained resulting from of the execution of contracts selected from the total number of available contracts. Therefore, scenario planning should be aimed at developing a production program which ensures both minimization of the cash gaps sum and maximization of the
profit during a predefined period, considering actual restrictions.
Since the contract represents a separate entity having its own characteristics, there is a need to use the agent-based method while building the simulation model. Creation of the agent of the "Contract" type during the model run indicates the start of contract execution, and its elimination means completion of work. A number of simulation modeling tools may be used not only while scenario planning by varying control parameters and conducting multiple runs of the simulation model, but also while performing experiments, aimed at finding the conditionally optimal solution of multi-objective optimization problems. Furthermore, the model should support import of input parameters and export of output measures into external applications. The simulation model is also required to have the dashboard needed to provide input of values in order to set various initial parameters and visual representation of dynamics of the financial indicators.
Therefore, both the requirements imposed on the simulation model of a standard production enterprise for managing financial characteristics and their verification criteria should consider the following features of simulation modeling:
♦ application of the agent-based approach;
♦ scenario planning by varying control parameters;
♦ support of genetic optimization algorithms;
4 capability of import of initial parameters
and export of simulation results;
4 availability of a dashboard for setting initial values of model parameters;
4 visualization of the characteristics dynamics of the production enterprise.
2. The concept of verification criteria for requirements of a production enterprise simulation model
The verification criterion is a solution requirement characteristic, which should
make sure that it has been defined correctly and fits for future use [9]. If the requirement is stated in an inappropriate way, contains errors or is not aligned with other requirements for the simulation model, it should be corrected or excluded from the list of requirements.
There are a number of common requirements characteristics which are proposed for use as verification criteria [9]:
atomicity: the requirement must be self-contained and capable of being understood independently of other requirements;
completeness: the requirement should be complete enough to guide further work and at the appropriate level of detail for work to continue;
consistency: the requirement must be aligned with the identified needs of the stakeholders and not conflicting with other requirements;
conciseness: the requirement contains no extraneous and unnecessary content;
feasibility: the requirement should be reasonable and possible within the agreed-upon risk, schedule, and budget;
unambiguity: the requirement must be clearly stated in such a way as to make it clear whether a solution does or does not meet the associated need;
testability: the requirement allows for verification that the requirement or design has been fulfilled;
clarity: the requirement ought to be represented using common terminology.
Aside from the above common requirements characteristics, it is necessary to illustrate a range of verification criteria for requirements for the simulation model [10—12] that provide more sophisticated detailing of the common criteria:
♦ success/failure discretization: result of the requirement test can only have one of two alternative results, represented by "success" and "failure";
♦ aggregation absence: the requirement may not be a result of aggregation of two similar, but distinct requirements;
♦ dependencies indication: if any requirement is known to have dependencies, it needs to be re-analyzed ensuring that all dependencies are covered in its specification;
♦ lack of recommendations for specific implementation: if the requirement is linked to specific technologies, it will demonstrate a severely low level of adaptation to any change.
3. Acceptance and evaluation criteria for requirements verification
Acceptance and evaluation criteria are one of the common requirements verification techniques introduced in the business analysis competency model [13].
Acceptance criteria define a number of characteristics that the requirements should possess to be accepted by all the stakeholders. In many cases, the result of separate acceptance criterion fulfillment is represented by the binary type and, accordingly, should be expressed as one of two alternative values: "yes / no", "true / false".
While using the acceptance criteria, it is primarily required that you identify the set of characteristics that will be used for formal inspection of requirements for the simulation model. Next, each separate requirement should be analyzed in order to establish that it corresponds to the appropriate acceptance criteria. If the requirement does not satisfy even a single criterion, it must be corrected or excluded from the list of requirements involved in verification.
There is no need to apply evaluation criteria while verifying requirements for the simulation model, since they are recommended to be used when many alternatives of the same requirement are to be compared in order to select the most appropriate option.
4. Conceptual basis of the Graphical Requirements Analysis (GRA) framework
A Graphical Requirements Analysis (GRA) framework [14-16] is supposed to be a semi-formal requirements verification method [16]. This technique is designed to evaluate the correctness of software requirements based on their graphical representation. The core concept of the GRA framework is derived from the functional modeling methodology as defined in the standard IEEE 610.12 [17]. However, the framework also captures some system and software engineering approaches, including hierarchy theory, the function block diagram paradigm, modular programming, and the functional size measurement procedure called COSMIC-FFP [18]. While using the GRA framework, it is recommended to perform the following steps: decomposing the distinct functional requirement into a set of elements, identifying inputs, outputs and functional blocks, defining the relationships between the components.
The GRA framework is utilized to define functionality in full detail based on the set of graphical primitives, each of which is applied to visualize a particular component of the functional requirement [19].
In order to explain the rationale for selection of the GRA framework for the purpose of visual representation of the functional requirements compared to the most popular business process modeling notations, it is necessary to identify the groups of notations that are most commonly used for business process modeling. Next, the key differences between the GRA framework and each group should be defined.
There are three groups of notations identified in the result of the analysis [20]:
♦ notations that allow us to describe business rules (IDEF3, BPMN, ARIS eEPC) [21];
♦ notations aimed to develop specifications based on flowcharts (Basic Flowchart, Cross Functional Flowchart) [22];
♦ notations using the object-oriented approach (Unified Modeling Language, UML) [23].
The advantage of the GRA framework compared to the business process modeling notations IDEF3, BPMN and ARIS eEPC consists in the absence of redundant graphical objects. This contributes to development of the diagrams which can be understood by both business analysts and other stakeholders who do not have any relevant knowledge.
Notations aimed at building specifications based on flowcharts (Basic Flowchart, Cross Functional Flowchart) are used to specify separate consequences of data conversion and do not support integration of many functional user requirements by connecting respective diagrams' outputs and inputs. Conversely, the GRA notation can be aided to synthesize the low-level requirements in order to construct the higherlevel requirements. The requirements of the high level do not include implementation details, and thus can be approved by the consumer.
A group comprised of notations resting upon the unified modeling language (UML), is intended to model the components of complex systems based on the object-oriented approach.
The differences between the GRA framework and three groups of process modeling notations listed above contribute to explaining the rationale for selection of the GRA framework for the purpose of visualizing functional requirements for the simulation model in order to complete their verification. While verifying requirements for the simulation model of a standard production enterprise, you must use the acceptance and evaluation criteria (to check correctness of all the requirements) and the GRA framework (to analyze the functional requirements).
5. Specification of requirements for the simulation model of a production enterprise
A number of activities including analysis of the current financial state of the production
enterprise, interviews with the subject matter experts and regulatory document analysis serve as the foundation for specification of the requirements for the simulation model, as listed in Table 1. The unique identifier (ID) associated with each requirement is a result of merging the symbol "R" ("Requirement") and the index of requirements.
Scenarios of development of a standard production enterprise expected to be identified
with the aid of the agent-based simulation model [24] should consider the multi-objective optimization problem that ensures both minimization of the cash gap sum and maximization of the profit gained during a period, comprising one calendar year. Such a rigid restriction imposed on the duration of the scenario planning period is caused by the discrete production process and high level of uncertainty associated with definition of the potential structure of the portfolio in the long-term perspective.
Table 1.
Specification of requirements for the simulation model
Requirement ID Requirement
R1 The simulation model should describe enterprise's financial flows related to its operating activities.
R2 A separate repair contract created during simulation experiment execution should be an independent entity.
R3 A scenario resulting from a certain run of the simulation model is a plan specifying the execution order of a fixed number of contracts during a particular period.
R4 The simulation model should be stored in a separate file which can be executed on different personal computers.
R5 The graphical user interface in a single run mode should be presented by the dashboard, including a number of input controls and the diagrams designed to visualize dynamics of key performance indicators.
R6 The execution time of the simulation model is one calendar year with a model time step which equals one day.
R7 The simulation model should perform contract portfolio building considering maximization of annual profits realized by the company.
R8 The simulation model should support execution of an optimization experiment to minimize the enterprise's cash gaps emerging during a single model run.
R9 The contracts pool should be loaded into the environment of the simulation model from a workbook created using MS Excel.
R10 The contract portfolio structure and yearly production plan should be loaded from a text file.
R11 Optimization experiment targets should include the enterprise's planned monthly cash gaps sum and monthly cash balances changes sum, which are calculated during the model execution time.
R12 Incoming cash flows related to the enterprise's operating activities include advance payment and final payment following completion of overhaul works. Outgoing cash flows related to the enterprise's operating activities include material costs, salaries, production overhead costs and general running costs.
R13 Recommended system requirements for the environment of the simulation model: OS Microsoft Windows Vista SP2, x86-32 or x64, 2GB RAM, 500MB free hard disk space.
R14 The simulation model should support export of indexes of the contracts included in the production plan to the spreadsheet and their mapping with contracts listed in the respective rows.
R15 Diagrams of the simulation model dashboard should include the following elements: contracts execution timetable, a graph that depicts dynamics of the cash balance of the enterprise, a graph that illustrates dynamics of the enterprise's monthly cash gaps accumulated sum.
While developing the requirement for the environment of the simulation model (R13), we considered the requirements necessary to ensure the proper work of the recent simulation systems supporting an agent-based approach to simulation modeling and having the incorporated optimization module (AnyLogic, iThink/ STELLA).
While identifying verification criteria for requirements for the simulation model of a standard production enterprise, it is necessary to consider their types. Requirements with identifiers R7, R9—11 and R14 comprise the subset of functional requirements, because they are used to specify the sequence of data conversion, which takes place in separate functional blocks. Thus, requirements with identifiers R1—6, R8, R12—13 and R15 constitute the subset of nonfunctional requirements, since they are intended to describe business rules (restrictions, imposed by the subject area) and certain properties of the simulation model, its implementation peculiarities and characteristics of the dashboard, which serves to set input parameters and analyze results of the simulation.
6. Identification of requirements verification criteria
The set of verification criteria for the requirements for the simulation model, including the common acceptance criteria and the specialized verification criteria, are listed in Table 2. The unique identifier (ID) associated with each verification criterion is a result of merging the symbol "AC" ("Acceptance Criterion") and the index of criterion.
Using a single criterion "Completeness" is not enough to check completeness of the functional requirements R7, R9—11, R14 so that their verification is accomplished. This is due to the fact that the functional requirement for the simulation model presented as a specification does not allow us to correctly identify input and output parameters and to properly define the sequence
Table 2.
Verification criteria of requirements for the simulation model
Criterion ID Verification criterion
AC1 Atomicity
AC2 Completeness
AC3 Consistency
AC4 Conciseness
AC5 Feasibility
AC6 Unambiguity
AC7 Testability
AC8 Clarity
AC9 Success/failure discretization
AC10 No aggregation
AC11 Indication of dependencies
AC12 Lack of recommendations for specific implementation
of execution of the functional blocks serving to process information. Therefore, in order to check the correctness of the requirements R7, R9—11, R14 it is necessary to additionally apply the GRA framework. This should help complete evaluation of those requirements from the perspective of completeness.
AVerification Cross Reference Matrix (VCRM) [25] that aggregates all the requirements as well as their verification techniques and criteria is shown in Table 3. The third column of the table is used to list the unique identifiers of those verification criteria recommended to verify correctness of the respective requirement.
It is important to mention that the criterion "Indication of dependencies" (AC11) cannot be applied while verifying the requirements R4 and R13. The first requirement (R4) is used to specify the storage format of the simulation model, and the second requirement (R13) represents the set of software and hardware requirements imposed on the environ-
Table 3.
Verification cross reference matrix
Requirement ID Verification technique Verification criteria ID
R1 Acceptance criteria AC1-AC12
R2 Acceptance criteria AC1-AC12
R3 Acceptance criteria AC1-AC12
R4 Acceptance criteria AC1-AC10, AC12
R5 Acceptance criteria AC1-AC12
R6 Acceptance criteria AC1-AC12
R7 Acceptance criteria, GRA framework AC1-AC12
R8 Acceptance criteria AC1-AC12
R9 Acceptance criteria, GRA framework AC1-AC12
R10 Acceptance criteria, GRA framework AC1-AC12
R11 Acceptance criteria, GRA framework AC1-AC12
R12 Acceptance criteria AC1-AC12
R13 Acceptance criteria AC1-AC10, AC12
R14 Acceptance criteria, GRA framework AC1-AC12
R15 Acceptance criteria AC1-AC12
ment where the model should be executed. Each of these two requirements contains technical information and is prevented from being linked to the other requirements, which serve to describe restrictions of the subject area and functional capabilities of the simulation model. Therefore, there is no need to conduct a check of correctness of the requirements R4 and R13 based on the criterion AC11. However, it is necessary to use this criterion while verifying the other requirements, since each of them is characterized by at least one connection to the other requirement. The acceptance criteria AC1—AC10, AC12 are suitable for verification of all the specified requirements.
7. Verification of requirements for the simulation model
Analysis of the results of requirements verification based on the acceptance criteria (Table 4) has resulted in the conclusion that no one requirement has been completely verified by all the criteria. Since the successful implementation of the simulation model cannot be recognized in case any requirement has been excluded from the specification, it is necessary to save the entire list of requirements. However, their specifications should be modified.
The final target of modification of each requirement is to obtain a statement which meets the corresponding acceptance criteria specified in Table 2. While considering the examples of such modification, it is necessary to examine the correction of several requirements, which statements are characterized by multiple values "no" assigned to different verification criteria (Table 4). For instance, the requirement R1 does not satisfy the criteria, such as AC7 ("Testability"), AC9 ("Success/ failure discretization") and AC 11 ("Indication of dependencies"). In order to make the requirement testable against the criterion AC7, you need to properly define the concept of cash flow used in its specification. In the course of identifying the fact that the requirement is fulfilled, it is sufficient to ensure the presence of incoming and outgoing cash flows incorporated in the simulation model. Meeting the criterion AC7 allows us to automatically satisfy the criterion AC9, according to which the result of testing a requirement should be represented by a binary variable. In fact, while establishing that the model describes the incoming or outgoing cash flow there can actually be only two alternative outcomes: the flow is either implemented or not implemented. Finally, indication of the link between the requirement R1 and the requirement R12 can be reached by including the apparent reference to the requirement R12, specifying the incoming and outgoing cash flows of the production enterprise, in
Table 4.
Result of formal inspection of requirements based on the acceptance criteria
AC1 AC2 AC3 AC4 AC5 AC6 AC7 AC8 AC9 AC10 AC11 AC12
R1 yes yes yes yes yes yes no yes no yes no yes
R2 yes no yes yes yes no yes yes yes yes no yes
R3 yes no yes yes yes yes yes yes yes yes no yes
R4 yes no yes yes yes yes yes yes yes yes - yes
R5 yes no yes yes yes yes yes yes yes yes no yes
R6 yes yes yes yes yes yes yes yes yes yes no yes
R7 yes no yes yes yes yes yes yes yes yes no yes
R8 yes no yes yes yes yes yes no yes yes no yes
R9 yes no yes yes yes yes yes yes yes yes no yes
R10 yes no yes yes yes yes yes yes yes yes no yes
R11 yes no yes yes yes yes yes no yes yes no yes
R12 yes no yes yes yes yes yes no yes yes no yes
R13 yes no yes yes yes no yes yes yes yes - yes
R14 yes no yes yes yes no yes yes yes yes no yes
R15 yes no yes no yes yes yes yes yes yes no yes
specification of the requirement R1. As a result, the requirement R1 is recognized to be accepted upon the full criteria list. The renewed identifier of the modified requirement receives the value "RA1," which is a result of merging the symbols "RA" ("Requirement Accepted") and the index of initial requirement.
The requirement R2 does not satisfy the criteria AC2 ("Completeness"), AC6 ("Unambigu-ity") and AC11 ("Indication of dependencies"). In order to enrich the requirement, it is necessary to properly define the concept of the entity serving to represent each production contract created during simulation modeling. The need associated with the requirement R2 consists in ensuring traceability of the contract execution dynamics. Adding this need to the requirement specification helps satisfy the criterion AC6. Indication of the link between the requirement R2 and the requirements R9 and R10 can be
reached by including apparent reference to the requirement R2 in specifications of the connected requirements. The renewed identifier of the modified requirement receives the value "RA2", which is a result of merging the symbols "RA" and the index of the initial requirement.
All the requirements which are characterized by the value "no" assigned at least to one criterion should be exposed to the modification procedure analyzed in the above examples.
The requirements resulting from conducting formal inspection based on the acceptance criteria are listed in Table 5. It is important to pay attention to the occurrence of the new terms "Public" and "Commercial" in specifications of the requirements RA7 and RA8. These concepts have resulted from applying the modification procedure aimed at meeting the criterion AC2 ("Completeness"). The necessity to use
these terms is caused by the fact that the contract portfolio of public enterprises is always partially comprised by state orders (orders of the type "Public"), while commercial production enterprises mainly undertake commercial contracts (orders of the type "Commercial"). Substantial differences between the logics of cash flow generation tailored to the execution of contracts of both types (advance payments schedule, duration of period of material costs generation), point to the need to explicitly state the contracts types ("Public" or "Commercial") in the requirements associated with these concepts. Furthermore, including precise characteristics of the term "Contract type" in specifications of the requirements RA7 and RA8 gives us the opportunity to ensure flexibility of the simulation model as well as the ability to use it while planning scenarios for development of both public and commercial enterprises.
While examining application of the GRA framework, it is proposed to consider the example of verification of the requirement RA7 (Figure 1). The process of diagram building includes identifying input and output structures, and identifying functional blocks for data conversion.
Input and output parameters are represented by the rectangles, the border ofwhich is depicted by a double line. Inputs are located in the lower left part of the diagram. Output parameters are placed in the upper area of the figure. Graphic elements of the "rhombus" type serve to visualize control blocks aimed at transformation of the input data into the output data. Rectangles the border of which is depicted by single line specify functional blocks and internal parameters involved in their execution. The graphic items of the "cycle" type represent internal inputs and outputs and external inputs. External inputs do not have indexes and are used to display values of parameters consumed by the functional blocks. Internal inputs and outputs are local variables and have assigned indexes which are necessary to visualize the sequence of data conversion conducted to complete the requirement.
Each functional block has a unique identifier. In conformance with the GRA notation, it is required to read the diagram from left to right and from bottom to top.
The requirement RA7 includes the set of initial parameters which are explicitly defined: the contract portfolio structure, profit list on contracts loaded from the pool stored in an MS Excel workbook. The requirement specification also contains information about the input data, which is presented by two populations (sets) of entities of the types "Public" and "Commercial." In the course of aggregate description of the sequence of data processing, it is necessary to define key functional blocks that serve to transform transitional inputs into outputs. In order to specify functional blocks, verbal nouns should be used; for example, calculation, creation and initialization.
Analysis of the diagram depicted by Figure 1 allows us to understand the principle underlying generation of identifiers of the blocks which serve to transform information. In accordance with the rule defined in the GRA framework, each identifier is a result of merging indexes of input and output parameters sorted in ascending order. If one of the inputs of the functional block is an external input parameter that does not have index, the symbol "0" is added to the beginning of identifier. This makes sure that all input parameters are accounted for. Moreover, in order to eliminate the risk of occurrence of two identical numbers associated with diagram elements presented by functional blocks, inputs and outputs, the additional symbol "1" should be inserted before the first symbol of identifier of each functional block. Therefore, the rule used to build identifiers of the functional blocks ensures that they are unique and helps explicitly state the structure of input and output parameters in their names. It is necessary to consider a specific example of application of the rule we have examined. The identifier "123" of the last functional block of the diagram depicted by Figure 1 represents the string comprising three
Modified requirements that meet the acceptance criteria Table 5.
Modified requirement ID Modified requirement Initial requirement ID
RAI Simulation model should describe two key enterprise financial flows related to its operating activities: incoming cash flow and outgoing cash flow. The main components of flows are defined in the requirement RA12. R1
RA2 A separate repair contract created during a single simulation experiment execution should be an independent entity which is an object having its own behavior pattern and a set of states and parameters that are initialized in an order declared in the requirements RA9, RA10. This should be accomplished to ensure traceability of the contract execution dynamics. R2
RA3 The scenario originating as a result of a certain run of simulation model is a plan specifying the execution order of a number of contracts comprising a portfolio. Portfolio size is calculated based on the labor intensity in a particular period. Model execution time is defined in the requirement rA6. R3
RA4 Simulation model should be stored in a separate file which is capable of being executed on different personal computers with the aid of a selected simulation modeling tool. R4
RA5 The graphical user interface in a single run mode should be presented by the dashboard, including a set of input parameters (number of employees involved in production operations, contracts portfolio structure) controls and the diagrams designed to visualize dynamics of the key performance indicators listed in the requirement RA15. R5
RA6 Execution time of the simulation model is one calendar year with a model time step which equals one day. The concept of model execution time is used in the requirements RA3, RA8, RA11. R6
RA7 Simulation model should perform contract portfolio building considering maximization of annual profit realized by the company. Inputs include contracts portfolio structure, array of profits on contracts loaded from the pool stored in an MS Excel workbook (RA9). Outputs are two populations of entities of the types "Public" and "Commercial." The concept of entity is examined in the requirement RA2. R7
RA8 Simulation model should support execution of the optimization experiment to minimize the enterprise's cash balance decrements emerging during a single model run, which is defined in the requirement RA6. The following decision variables are supposed to be changed: contracts execution start dates, ratios of contracts of the types "Public" and "Commercial," comprising the portfolio structure. R8
RA9 There should be a procedure aimed at loading of parameters of contracts (contract sum excluding VAT, profit ratio, advance payment) from an MS Excel workbook into the environment of the simulation model in order to initialize characteristics of the objects specified in the requirement RA2. R9
RA10 There should be a procedure aimed at loading the contracts portfolio structure and contracts execution start dates from a text file into the environment of the simulation model in order to initialize characteristics of the objects specified in the requirement RA2. R10
RA11 Simulation model should provide determination of the following targets of the optimization experiment for minimization: enterprise's planned monthly cash gaps sum and monthly cash balances changes sum calculated during the model execution time specified in the requirement RA6. R11
RA12 Incoming cash flows related to the enterprise's operating activities include advance payment and final payment, following completion of overhaul works. Outgoing cash flows related to the enterprise's operating activities include cost of goods sold. The concepts of incoming and outgoing cash flows are introduced in the requirement RA1. R12
Modified Initial
requirement Modified requirement requirement
ID ID
RA13
Necessary and sufficient system requirements which must be implemented to ensure successful start of the simulation model on personal computers of end users: OS Microsoft Windows Vista SP2, x86-32 or x64, 2Gb RAM, 500Mb free hard disk space.
R13
RA14
Simulation model should support export of indexes of the contracts included in the production plan and their mapping with contracts listed in the respective rows of an MS Excel workbook that serves as an import data source specified in the requirement RA9.
R14
RA15
Diagrams of the simulation model dashboard specified in the requirement RA5 should include the following elements: production works execution timetable, graph that depicts dynamics of cash balance of the enterprise, graph that illustrates dynamics of the enterprise's monthly cash gaps accumulated sum.
R15
symbols: the additional symbol "1", the index of the internal input parameter ("2") and the index of the internal input parameter ("3"). Since the internal output parameter is the same as the external output parameter, it is not displayed in the diagram in order to avoid data redundancy.
Verification of the functional requirement presented in the form of the diagram conforming to the GRA notation is carried out to check if the following essential conditions are fulfilled:
♦ each external input parameter should be used in at least one functional block;
♦ each functional block should have at least one input and one output parameter;
♦ the external output structure defined for the functional requirement should be presented by a set which is the result of joining all internal output parameters that are not consumed by other functional blocks;
♦ the minimal cardinality of a set of output parameters, comprising external output structure, is required to be greater than zero.
A diagram conforming to the GRA notation depicted by Figure 1 meets all the listed conditions, and thus verification of the requirement RA7 can be successfully completed. Specification of the verified requirement and its functional diagram are ready to be used for further development of the simulation model of the production enterprise.
The diagrams built for the other functional requirements RA9—11 and RA14 should be verified in the same way. Eventually, the figures created with application of the rules defined within the GRA framework are expected to complete verification of the set of the functional requirements RA7, RA9-11 and RA14 against the acceptance criterion "Completeness". However, they are required to include the key implementation elements (internal inputs and outputs, transitional inputs and outputs, functional blocks) and to fulfill all the conditions which ensure correct application of the selected notation. Graphical representations of the functional requirements are supposed to make sure that they have been defined correctly and are ready for future use while developing the simulation model.
Therefore, verification of initial requirements (Table 1) has resulted in a set of modified requirements which meet the acceptance criteria (Table 2), and a number of diagrams visualizing the process of data conversion in order to satisfy the functional requirements. The list of verified requirements for the simulation model of a standard production enterprise is expected to serve as the foundation for its constructing. The simulation model, in turn, should be focused on development of scenarios for achieving the production enterprise's desired future financial position and ensuring a high level of financial stability.
Populations of contracts of the types "Public" and "Commercial," parameters of which are initialized by values of appropriate characteristics of mostly profitable contracts.
Share of contracts of the "Public" type.
Profit lists of contracts of the "Public" and "Commercial" types.
O ©
©
Number of contracts of the "Public" and "Commercial" types.
Populations of contracts of the "Public" and "Commercial" types.
Contracts' profit values lists, sorted in descending order.
Calculation of the number of contracts of the "Public" and "Commercial" types.
Creation of the populations of contracts of the "Public" and "Commercial" types.
Sorting contracts' profit values lists in descending order.
Initialization of parameters of the contracts populations by values of appropriate characteristics of the most profitable contracts.
Fig. 1. Diagram in the GRA notation for verification of the requirement RA7
Conclusion
The research has resulted in the list of verified requirements for the simulation model of a standard production enterprise aimed at development of scenarios for achieving the desired future financial position.
While performing verification of requirements for the simulation model, they were inspected to see if they could satisfy acceptance criteria. In case any requirement did not meet a single criterion, it underwent modification.
In the final verification stage, we presented an example of building a diagram for one of
the functional requirements based on the GRA framework. The diagram so constructed helps to properly define the structure and internal logic of the requirement, and thus to ensure that it is suitable for future use while developing the simulation model of the enterprise.
The research findings may be used while performing multistage verification of requirements for simulation models aimed at scenario planning of the future financial position of production enterprises which are characterized by a discrete manufacturing process. ■
References
1. Akopov AS. (2014) Imitatsionnoe modelirovanie [Simulation modeling]. Moscow: Urait (in Russian).
2. Bruskin S.N., Dovzhenko A.Y., Nikolaenko V.A., Petrov L.F., Romanov V.P. (2010) Intellektual'nyy analiz dinamikibiznes-sistem [Intellectual analysis of business systems dynamics]. Moscow: INFRA-M (in Russian).
3. Akopov A.S., Khachatryan N.K. (2016) Agentnoe modelirovanie [Agent based modeling]. Moscow: CEMI (in Russian).
4. Akopov A.S., Beklaryan A.L., Fomin A.V., Khachatryan N.K. (2017) Sistema prognozirovaniya dinamiki dobychi nefti s ispol'zovaniem imitatsionnogo modelirovaniya [A system of oil extraction dynamics forecasting using simulation modeling]. Information Technologies, vol. 23, no. 6, pp. 431—436 (in Russian).
5. Akopov A.S., Beklaryan A.L., Saghatelyan A.K., Sahakyan L.V. (2016) Control system for ecological modernization of enterprises (on the example of the Republic of Armenia). Business Informatics, no. 2 (36), pp. 71—78.
6. Akopov A.S. (2012) Designing of integrated system-dynamics models for an oil company. International Journal ofComputerApplications in Technology, vol. 45, no. 4, pp. 220—230.
7. Akopov A.S. (2012) Sistemno-dinamicheskoe modelirovanie strategii bankovskoy gruppy [System dynamics modeling of a banking group's strategy]. Business Informatics, no. 2 (20), pp. 10—19 (in Russian).
8. Akopov A.S. (2004) Ispol'zovanie sredstv dinamicheskogo imitatsionnogo modelirovaniya dlya podgotovki upravlencheskih resheniy v TEK [Using dynamic simulation modeling tools for preparation of management decisions in the field of fuel and energy]. Management Systems and Information Technologies, no. 2, pp. 72—79 (in Russian).
9. IIBA (2015) A Guide to the Business Analysis Body of Knowledge (BABOKGuide). Version 3.0. Toronto: IIBA.
10. Boehm B.W. (1979) Guidelines for verifying and validating software requirements and design specifications. Available at: http://csse.usc.edu/TECHRPTS/1979/usccse79-501/usccse79-501.pdf (accessed 08 May 2018).
11. Heck P., Zaidman E. (2014) A quality framework for agile requirements: A practitioner's perspective. Available at: https://www.researchgate.net/publication/263237832_A_Quality_Framework_for_Agile_Requirements_A_ Practitioner's_Perspective (accessed 08 May 2018).
12. Lucassen G., Dalpiaz F., van der Werf J.M. E.M., Brinkkemper S. (2016) Improving agile requirements: The quality user story framework and tool. Requirements Engineering, vol. 21, no. 3, pp. 383—403.
13. IIBA (2017) Business Analysis Competency Model. Version 4.0. Toronto: IIBA.
14. Kececi N., Halang W.A., Abran A. (2002) A semi-formal method to verify correctness offunctional requirements specifications of complex systems. Design and analysis ofdistributed embedded systems
(eds. B. Kleinjohann, K.H. Kim, L. Kleinjohann, A. Rettberg). Boston, MA: Springer, vol. 91, pp. 61—69.
15. Kececi N., Modarres M., Smidts C. (1999) System software interface for safety related digital I&C systems. Proceedings of the 10th European European Conference on Safety and Reliability (ESREL 99). Munich-Garching, Germany, 13—17September 1999, pp. 433—438.
16. Kececi N., Abran A. (2001) Analyzing, measuring and assessing software quality in a logic based graphical model. Proceedings of the 41th International Conference on Quality and Dependability (QUALITA 2001). Annecy, France, 22-23March 2001, pp. 48-55.
17. Standardinform (2002) Glossary ofsoftware engineering terminology. Available at: http://www.standards.ru/ document/ 4552110.aspx (accessed 08 May 2018).
18. IEEE (1990) IEEE standards glossary ofsoftware engineering standards. IEEE Std 610.12-1990. IEEE.
19. Kececi N., Abran A. (2001) An integrated measure for functional requirements correctness. Proceedings of the 11th International Workshop on Software Measurement (IWSM2001). Montreal, Canada, 28-29August 2001, pp. 137-150.
20. Pereira J.L., Silva D. (2016) Business process modeling languages: A comparative framework. New Advances in Information Systems and Technologies, vol. 444, pp. 619-628.
21. ABPMP (2013) A Guide to the Business Process Management Common Body ofKnowledge (BPM CBOK). Version 3.0. Pensacola, FL: ABPMP.
22. Wynn D.C., Clarkson P.J. (2018) Process models in design and development. Research in Engineering and Design, vol. 29, no. 2, pp. 161-202.
23. Peixoto D.C.C., Batista V.A., Atayde A.P., Borges E.P., Resende R.F, Padua C.I.P.S. (2008) A comparison of BPMN and UML 2.0 activity diagrams. VIISimpisio Brasileiro de Qualidade de Software, Floriampolis, Santa Catarina, Brazil, 30May 2008, pp. 64-75.
24. Borshchev A. (2013) Kak stroit' prostye, krasivye i poleznye modeli slozhnyh sistem [How to build simple, beautiful and useful models of complex systems]. Proceedings of the Simulation Modeling Theory and Practice Conference, Kazan, 16-18 October 2013, vol. 1, pp. 21-34 (in Russian).
25. Scucanec S.J., van Gaasbeek J.R. (2008) A day in the life of a verification requirement. Proceedings
of the US Air Force T&E Days Conference, Los Angeles, 5-7 February 2008, pp. 104-116.
