# #
BACKGROUND
The present invention relates to performance engineering. More specifically, the present invention relates to a method and system for managing the non¬functional requirements (NFRs) of various applications that interact in an enterprise.
Performance engineering defines the set of roles, tools and practices applied to a system-development lifecycle, which ensures that a solution is designed, implemented and operationally supported to meet the non-functionai requirements defined for the solution. The process of defining requirements in a typical project includes delineating the functional requirements and non-functional requirements. These functional and non-functional requirements are defined in a Service Level /^v Agreement (SLA), which is a contract between a service provider and the customer. Here, the service provider will be the application / system development team, such as an IS team, and the customer is the end user, such as a business user, of the application. Functional requirements are the system/software requirements that specify a function a system/software system should be able to perform. NFRs relate to how the software will perform the specified function, for example, the performance requirements of the software, the external interface requirements of the software, maintainability requirements, availability requirements etc.
in general, different teams handle functional and non-functional requirements- functional requirements are managed by a team of analysts and subject matter experts, and non-functional requirements by a team of business analysts, architects and other experts. The separation of these requirements requires different subject- matter experts and tool sets. Therefore, the probability of the subject-matter experts reviewing each other's work is minimal. Hence, the functional requirements discovered during an architectural session may not be communicated to the requirements team, and the non-functionai requirements discovered during modeling may not be communicated to the architectural team. Further, this coupled with an enterprise's business being supported by various systems and applications makes the situation unrelated and chaotic. Consequently, it is difficult to trace the NFRs that interact with each other within and across the various applications.
Currently, there are techniques and templates available for recording the NFR of various applications in an enterprise. The templates capture the different
transactions in a system, the corresponding response time, and the throughput requirements. Further, to realize the transactions in an enterprise, these templates capture information on other external applications, which interact or interface with the applications under consideration. The specifications pertaining to external systems include the average response that can be expected from the system. However, the drawback of using these templates is that they store the captured information in isolation. Further, there is no linkage or communication between the NFR of an application and the NFR of other applications interacting with the application under consideration. A change in the NFR of one application would inevitably change the NFR of all its interfacing applications These drawbacks prevent the system from reflecting the change of the NFR of an application to the NFRs of other inter¬dependent applications.
NFR dependencies can be changed or tracked manually. However, this requires a great deal of time and effort, which makes it difficult to manage a large number of interacting and interfacing applications. Further, the process of tracking the NFRs manually is prone to errors.
In light of the foregoing, there is a need for a method that can overcome the problems related to the lack of a linkage between the NFRs of various interdependent applications. Further, there is a need for a method that enables a change in the NFR of an application to be reflected in the NFR of other interfacing or interacting applications. Furthermore, the method should be able to handle the dependencies of the NFRs of a large number of applications and be less prone to human errors. Subsequently, the method should enable an NFR to be traced across various applications that interact with each other.
SUMMARY
An object of the present invention is to provide a method and system for calculating one or more non-functional requirements (NFRs) of one or more interacting applications in an enterprise.
Another object of the present invention is to provide a method and system for maintaining traceability of the one or more NFRs across the one or more interacting applications in an enterprise.
Yet another object of the present invention is to set up realistic and achievable Service Level Agreement (SLAs) for the response time of one or more transactions in a system.
To achieve the foregoing objectives, the present invention describes a method and system for calculating the one or more NFRs of one or more interacting applications. The method includes collecting and maintaining NFR information corresponding to each of the one or more interacting applications in an enterprise. Subsequently, the one or more NFRs of the one or more interacting applications are calculated, based on the NFR information corresponding to each of the one or more interacting applications. The calculation of the one or more NFRs comprises a calculation of the direct load and the indirect load on each of the one or more interacting applications. The direct load corresponds to one or more direct transactions and the indirect load corresponds to one or more indirect transactions. To calculate the throughput requirements and response time of the one or more interacting applications, two basic performance-engineering laws from the queuing theory are applied to the stored NFRs of the one or more interacting applications. The two basic performance-engineering laws include the Forced Flow Law and the Flow Balance Assumption. The one or more interacting applications are tracked to calculate the throughput requirements by using the basic performance-engineering laws. Further, realistic and achievable SLAs are set up for the response time of one or more transactions in a system.
The present invention overcomes the problem related to the lack of NFR linkage between various interdependent applications. Further, the present invention handles the dependencies of a large number of NFRs of the one or more interacting applications at the same time and is less prone to human errors. Furthermore, the method is capable of tracing the one or more NFRs across various applications that interact with each other.
BRIEF DESCRIPTION OF THE DRAWINGS
The preferred embodiments of the invention will hereinafter be described in conjunction with the appended drawings, provided to illustrate and not to limit the invention, wherein like designations denote like elements, and in which:
FIG. 1ar 1b and 1c illustrates various environments in which various embodiments of the present invention may be practiced.
FIG. 2 illustrates a block diagram of the various components of a system for tracking the non-functional requirements (NFRs) of various interacting applications, in accordance with an embodiment of the present invention.
FIG. 3 is a flowchart for calculating the NFRs of one or more interacting applications in an enterprise, in accordance with an embodiment of the present invention.
FIG. 4 is a flowchart showing the sub-steps for calculating the NFRs of the one or more interacting applications.
DESCRIPTION OF VARIOUS EMBODIMENTS
The present invention illustrates a method and system for managing the non¬functional requirements (NFRs) of one or more interacting applications in an enterprise. Specifically, the invention aims at calculating the one or more NFRs of one or more interacting applications in an enterprise. These one or more interacting applications have one or more direct transactions and one or more indirect transactions.
The invention includes the collection and maintenance of NFR information relating to each of the one or more interacting applications and the one or more transactions of the one or more interacting applications. Thereafter, the one or more NFRs of the one or more interacting applications are calculated. The computation of the one or more NFRs includes calculating the direct load and the indirect load on each of the one or more interacting applications. The direct load is based on the one or more direct transactions of each of the one or more interacting applications; the indirect load on the one or more indirect transactions of each of the one or more interacting applications. Calculating an NFR entails the use of performance- engineering laws such as the Forced Flow Law and the Flow Balance Assumption. These one or more interacting applications are tracked for throughput requirements by using the performance-engineering laws. Further, realistic and achievable Service Level Agreements (SLAs) are set up to calculate the response time of one or more transactions in a system.
FIG. 1a, 1b and 1c illustrates an environment 100 in which various embodiments of the present invention may be practiced. In FIG. 1a, environment 100 includes a plurality of users such as user 102a, 102b and 102c, and one or more interacting applications such as applications 104,106,108 and 110. Environment 100 also includes one or more direct transactions such as direct transactions 112, 114,116,118 and 120, which are depicted by the solid arrows in FIG. 1a, 1b and 1c. Furthermore, environment 100 includes one or more indirect transactions such as indirect transactions 122,124,126,128 and 130, which are depicted by the dotted arrows in FIG. 1a, 1b and 1c.
In various embodiments of the present invention, users such as users 102a, 102b and 102c initiate direct transactions such as direct transactions 112,114,116, 118 and 120 on one or more interacting applications 104,106,108 and 110. Direct transactions 112,114,116,118 and 120 result in the initiation of one or more indirect transactions 122, 124, 126, 128 and 130. FIG 1b illustrates a direct transaction such as a new order 112, and indirect transactions such as a new order-verify and fetch- customer information 122, a new order-authorize card 124 and a new order-send confirmation 124, related to the direct transaction of new order 112. Indirect transactions new order-verify and fetch-customer information 122, new order- authorize card 124 and new order-send confirmation 124 are initiated when interacting application order-management application 104 interfaces with other applications such as a customer-service application 106, a credit card system 108 and a communication system 110, to complete a direct transaction such as new order 112.
The one or more indirect transactions occur in a synchronous or asynchronous manner with respect to the one or more direct transactions. Each of the interacting applications comprises information pertaining to the NFRs of the transactions occurring on each application. An example of NFR information includes, but is not limited to, processing time. This processing time relates to the transactions on an application, excluding all the indirect transactions generated by the direct transactions when the transaction is a direct one. This NFR information is used to calculate the NFR of the interacting applications. An example of an NFR includes, but is not limited to, the throughput requirement of the interacting applications, the expected response time of the transactions occurring on the interacting applications, and the like.
The NFR is calculated by using the Forced Flow Law which states:
Xk = (Vk)*(X) (1)
where,
Xk = Throughput of a transaction at an application Vk = Visit count of a transaction at an application X = Throughput of a transaction
FIG. 1c illustrates environment 100, in accordance with another embodiment of the present invention. Environment 100 includes a manager 102a, a customer 102b, a customer service agent 102c, and one or more interacting applications such as order- management application 104, customer-service application 106, credit card system 108 and communication system 110. Further, environment 100 includes one or more direct transactions such as new order 112, a search order 114, a customer data-management 116, a customer registration 118 and an inquire customer-credit history 120. Furthermore, environment 100 includes one or more indirect transactions such as new order-verify and fetch-customer information 122, new order-authorize card 124, new order-send confirmation 126, a search order-verify and fetch customer information 128, an inquire customer credit history-alerts and notifications 130, and a customer registration-send confirmation 132.
In accordance with an embodiment of the invention, Table 1 presents the NFR information relating to order-management application 104. The NFR information includes information relating to a direct transaction such as new order 112 and search order 114. Table 1 also includes the processing time specified in the SLA of the one or more transactions, and other applications such as customer-service application 106, credit-card system 108 and communication system 110 interacting or interfacing with order-management application 104. The processing time of the direct transactions shown in Table 1 does not include the processing time of the indirect transactions generated that relate to the direct transactions under consideration.



transactions is the sum of the response time of the direct transactions and response time of the corresponding indirect transactions generated. An example illustrating this has been explained in conjunction with FIG. 1b.
In various embodiments of the present invention, the response time of the indirect transactions generated, corresponding to the direct transactions, is calculated by using the Forced Flow Law, which states:
Xr = (Vk) * (X) (1)
where,
Xk is the throughput or response time of a transaction at an application Vk is the visit count of a transaction at an application and X is the throughput or expected response time of a transaction
Therefore, the expected response time corresponding to one or more direct transactions is the expected response time of a transaction = (processing time SLA of the direct transaction) + (visit count * processing time SLA) of ail the indirect transactions corresponding to the direct transaction. For example, the throughput requirement of new order 112 is equal to 200 (as shown in Table 5).
The response time of the new order 112 corresponding to the order- management application 104 is calculated as follows:
The expected response time of the new order 112 = (processing time SLA of new order transaction 112) + ((visit count of new order-verify and fetch customer information 122) * (processing time SLA of new order-verify and fetch customer information 122)) + ((visit count of new order-authorize card 124) * ((processing time SLA of new order-authorize card 124)) + ((visit count of new order-send confirmation 126) * (processing time SLA of new order-send confirmation 126))
(3)
Substituting the values of the variables from the Table 1 to 4:
The expected response time of the new order 112 = (1000) + ((2) * (500)) + ((2) * (2000)) + (0) = 6000 ms


The expected response time of the new order 112 = (processing time SLA of new order transaction 112) + ((visit count of new order-verify and fetch customer information 122) * (processing time SLA of new order-verify and fetch customer information 122)) + ((visit count of new order-authorize card 124) * (processing time SLA of new order-authorize card 124)) + ((visit count of new order-send confirmation 126) * (processing time SLA of new order-send confirmation 126)) (3)
Substituting the values of the variables from the Tables 1 to 4:
Expected response time of the new order 112 = (1000) + ((2) * (500)) + ((2) * (2000)) + (0) = 6000
The product, (visit count of new order-send confirmation 126) * (processing time SLA of new order-send confirmation 126)) is equal to zero, since the transaction of the new order-send confirmation is asynchronous and does not occur in sync with the other transactions. Therefore, in various embodiments of the present invention, the response time with respect to all asynchronous transactions is equal to zero.
Thus, the expected response time of the new-order transaction is equal to 6000 ms, which is 1000 more than the response time (5000) mentioned in the SLA (Table 5). Therefore, the response time of the new order 112 mentioned in the SLA is not achievable practically.
Feedback module 308 provides feedback relating to a change in the NFR corresponding to the one or more interacting applications. Further, feedback is provided on the addition of the one or more new transactions to the one or more interacting applications, and the addition of one or more new applications in the enterprise.
FIG. 3 is a flowchart for calculating the NFR corresponding to the one or more interacting applications such as application 104,106,108 and 110 in an enterprise, in accordance with an embodiment of the present invention. At step 302, one or more NFR information corresponding to each of the one or more interacting applications is collected. At step 304, the collected NFR information is maintained on the basis of feedback relating to any change in either of the one or more interacting applications and the corresponding one or more transactions. In an embodiment of the present invention, the maintenance of the collected NFR information is illustrated
from Table 1 to Table 4. In various embodiments of the present invention, these tables can be maintained in any database-management system.
Subsequently, at step 306, the one or more NFRs corresponding to the one or more interacting applications are calculated. The calculation of the one or more NFRs is based on the direct load and the indirect load on each of the one or more interacting applications. The direct load is based on the one or more direct transactions, such as direct transactions 112,114,116,118 and 120, on each of the one or more interacting applications. The indirect load is based on the one or more indirect transactions, such as indirect transactions 122,124, 126,128 and 130, which correspond to each of the one or more direct transactions.
FIG. 4 is a flowchart showing the sub-steps for calculating the NFR corresponding to the one or more interacting applications, such as application 104, 106,108 and 110, in accordance with an embodiment of the invention. At step 402, the direct load on each of the one or more interacting applications is calculated. This direct load is the load corresponding to the one or more transactions corresponding to each of the one or more interacting applications. Thereafter, at step 404, the indirect load on each of the one or more interacting applications is calculated. The indirect load is based on the one or more indirect transactions corresponding to the one or more direct transactions. Finally, at step 406, the Forced Flow law, as detailed in the description relating to FIG. 1b, is used to calculate the indirect load corresponding to the one or more indirect transactions.
^ In an embodiment of the invention, one or more NFRs are the expected
response time corresponding to the one or more transactions. For example, the expected response time of new order 112 transaction is the sum of the response time of direct transaction new order 114 transaction and the one or more indirect transactions generated that correspond to new order 112. The response time of the one or more indirect transactions is calculated by using the forced flow law. The calculation of the present example has been illustrated in the description of FIG. 1 b.
The present invention described above has a number of advantages. The invention provides a method and system for calculating the one or more NFRs of the one or more interacting applicant applications and the one or more transactions in an enterprise. The present invention overcomes the problem relating to the lack of NFR
linkages between the one or more interacting applications. Further, the present invention handles the dependencies of a large number of NFRs of the one or more interacting applications at the same time and is less prone to human errors. Furthermore, the method is capable of tracing the one or more NFRs across various applications that interact with each other.
The present invention can be implemented in a variety of computer languages such as Java, C, C++, Perl, Python, LISP, BASIC, assembly, etc. The implementation of the present invention does not require any specific platform. Any platform that can provide a means of support for simple arrays and associative arrays may be used. Some examples of such platforms include Windows™, Linux and Unix™.
The computer program product of the invention can be executed on a computer system, causing the computer system to perform a method for video encoding that includes a motion-estimation method of the present invention. The computer system includes a microprocessor, an input device, a display unit and an interface to the Internet. The microprocessor is connected to a communication bus. The computer also includes a memory. The memory may include Random Access Memory (RAM) and Read Only Memory (ROM). Moreover, the computer system comprises a storage device. The storage device can be a hard disk drive or a removable storage drive such as a floppy disk drive, an optical disk drive, etc. The storage device can also be other similar means for loading computer programs or other instructions into the computer system. The computer system includes a communication unit. The communication unit enables the computer to connect to other databases and the Internet through an I/O interface. The communication unit also enables the transfer and reception of data to and from other databases. The communication unit may include a modem, an Ethernet card, or any similar device that enables the computer system to connect to databases and networks such as LAN, MAN, WAN and the Internet. The computer system facilitates inputs from a user through an input device that is accessible to the system through an I/O interface.
The computer system executes a set of instructions that is stored in one or more storage elements, to process input data. The set of instructions may be a
program instruction means. The storage elements may also hold data or other information, as desired. The storage element may be in the form of an information source or a physical memory element present in the processing machine.
The set of instructions may include various commands that instruct the processing machine to perform specific tasks such as the steps that constitute the method of the present invention. The set of instructions may be in the form of a software program. Further, the software may be in the form of a collection of separate programs, a program module with a larger program or a portion of a program module, as in the present invention. The software may also include modular programming in the form of object-oriented programming. The processing of input data by the processing machine may be in response to user commands, the result of previous processing or a request made by another processing machine.
While the preferred embodiments of the invention have been illustrated and described, it will be clear that the invention is not limited to these embodiments only. Numerous modifications, changes, variations, substitutions and equivalents will be apparent to those skilled in the art, without departing from the spirit and scope of the invention, as described in the claims.

■ claim:
1. A method for calculating one or more non-functional requirements (NFR) of one or more interacting applications in an enterprise, the one or more interacting applications having one or more direct transactions and one or more indirect transactions, the calculation of the one or more NFR being based on the one or more direct transactions and the one or more indirect transactions, the method comprising:
a. collecting one or more NFR information corresponding to each of the one or more interacting applications and the corresponding one or more transactions;
b. maintaining the collected one or more NFR information; and
c. calculating the one or more NFR of the one or more interacting applications comprising:
i. calculating direct load on each of the one or more interacting applications, the direct load being based on the one or more direct transactions on each of the one or more interacting applications; and
ii. calculating indirect load on each of the one or more interacting applications, the indirect load being based on the one or more indirect transactions on each of the one or more interacting applications.
2. The method according to claim 1 further comprises providing a feedback corresponding to a change in the NFR corresponding to the one or more interacting applications.
3. The method according to claim 2, wherein the feedback is provided on addition of one or more new transactions to the one or more interacting applications.
4. The method according to claim 2, wherein the feedback is provided on addition of one or more new applications in the enterprise.
5. The method according to claim 1, wherein the one or more NFR is the throughput requirement of the one or more interacting applications.
6. The method according to claim 5, wherein the throughput requirement is calculated using the forced flow law.
7. The method according to claim 1, wherein the one or more NFR is a response time corresponding to the one or more direct and the one or more indirect transactions corresponding to each of the one or more interacting applications.
8. The method according to claim 7, wherein the response time is calculated using forced flow law.
9. A system for calculating one or more non-functional requirements (NFR) of one or more interacting applications in an enterprise, the one or more interacting applications having one or more direct transactions and one or more indirect transactions, the calculation of the one or more NFR being based on the one or more direct transactions and the one or more indirect transactions, the system comprising:
a. collecting module for collecting one or more NFR information
corresponding to each of the one or more interacting applications and the corresponding one or more transactions;
b. maintaining module for maintaining module maintaining the collected one or more NFR information; and
c. calculating module for calculating the one or more NFR of the one or more interacting applications, wherein the calculating module calculates direct load and indirect load on each of the one or more interacting applications, the direct load being based on the one or more direct transactions on each of the one or more interacting applications, the indirect load being based on the one or more indirect transactions on each of the one or more interacting applications.
10. The system according to claim 9 further comprising a feedback module for providing feedback corresponding to a change in the NFR corresponding to the one or more interacting applications.
11. The system according to claim 10, wherein the feedback module provides feedback on addition of one or more new transactions to the one or more interacting applications.
12. The system according to claim 10, wherein the feedback module provides feedback on addition of one or new applications in the enterprise.
13. A computer program product for use with a computer, the computer program product comprising a computer usable medium having a computer readable program code embodied therein for calculating one or more non-functional requirements (NFR) of one or more interacting applications in an enterprise, the one or more interacting applications having one or more direct transactions and one or more indirect transactions, the calculation of the one or more NFR being based on the one or more direct transactions and the one

or more indirect transactions, the computer program code performing the steps of:
a. collecting one or more NFR information corresponding to the one or more interacting applications and the corresponding one or more transactions;
b. maintaining the collected one or more NFR information; and
rv
c. calculating the one or more NFR of the one or more interacting applications comprising:
i. calculating direct load on each of the one or more interacting
applications, the direct load being based on the one or more direct transactions on each of the one or more interacting applications; and
ii. calculating indirect load on each of the one or more interacting applications, the indirect load being based on the one or more indirect transactions on each of the one or more interacting applications.

MANISHA SINGH NAD Agent foAthe Applicant [IJg/1 LEX ORBIS
bcdut ft** ^ ^^
Intellectual Property Practice 709 / 710, Tolstoy House, 15-17, Tolstoy Marg, New Delhi-110 001